makedream
10:22Maximilian Schwarzmüller
Log in to leave a comment
No posts yet
Недавно сообщество разработчиков всколыхнула новость о том, что армия ИИ-агентов всего за одну неделю создала браузер, состоящий из 3 миллионов строк кода. Сами по себе цифры впечатляют. Однако результат под названием FastRender на деле оказался скорее цифровым мусором, который невозможно даже нормально скомпилировать.
Скорость была революционной, но продукт не работал. Этот провал заставляет нас задать важный вопрос: если ИИ может выдавать код со скоростью света, почему мы до сих пор не видим продуктов, за которые стоило бы платить? Ответ кроется в ограниченности «вайб-кодинга» (vibe coding) — интуитивного подхода без технической глубины.
В разработке программного обеспечения действует закон 80/20. ИИ в мгновение ока справляется с 80% проекта: стандартными вызовами API и повторяющимся шаблонным кодом. Однако суть, определяющая ценность продукта для пользователя и возможность его коммерциализации, заключается в оставшихся 20%.
Обработка пограничных случаев (edge cases), таких как непредвиденный ввод пользователя или сетевые ошибки, архитектура безопасности для предотвращения утечек данных и согласованность миллионов строк кода без конфликтов — вот где начинаются сложности. ИИ лишь генерирует вероятностно правдоподобный код, но не несет ответственности за логическую целостность всей системы. Эксперимент с 3 миллионами строк кода провалился из-за ошибок сборки именно потому, что в нем отсутствовал инженерный замысел.
«Вайб-кодинг», о котором упоминал Андрей Карпатый, подразумевает метод разработки, при котором программист может не знать деталей логики, а полагаться лишь на «вайб» общения с ИИ. Это полезно для быстрой визуализации идей, но становится смертельным ядом при создании коммерческих продуктов.
Главная проблема — взрывной рост технического долга. Проекты, использующие ИИ-помощников, поначалу демонстрируют резкий скачок производительности, но со временем сложность кода возрастает до неуправляемых масштабов. Затраты на исправление логических дефектов на этапе эксплуатации, которые ИИ наплодил еще на стадии проектирования, растут в геометрической прогрессии. Возникает парадокс: риск-затраты на последующий вылов багов оказываются гораздо выше времени, сэкономленного на старте.
Настало время дисциплины, а не просто интуиции. Агентная инженерия — это модель, где ИИ используется не как простой «машинист», а как агент с четко определенными зонами ответственности, в то время как человек выступает в роли дирижера-оркестратора.
Для этого эксперты предлагают использовать фреймворк SPARC:
Один из примеров в авиационной отрасли: вместо того чтобы заставлять ИИ писать код напрямую, компания использовала его для генерации тысяч сценариев пограничных случаев, чтобы доказать безопасность ПО. Это инновационный пример того, как можно радикально сократить цикл контроля качества (Quality Engineering).
В то время как все штампуют низкокачественный код с помощью ИИ, разработчик, выпускающий безупречные продукты, приобретает на рынке колоссальную ценность. Вот необходимый чек-лист для перехода к агентной модели:
| Этап | Содержание активности | Ожидаемый эффект |
|---|---|---|
| Настройка | Создание файлов с рекомендациями (guidelines) | Предотвращение галлюцинаций ИИ |
| Ревью | Ручная проверка сгенерированного кода | Минимизация технического долга |
| Разделение | Применение фреймворков по типам логики | Баланс между скоростью и качеством |
| Автоматизация | Интеграция анализа качества в CI/CD | Упреждающее блокирование уязвимостей |
Урок эксперимента с браузером на 3 миллиона строк очевиден: истинная ценность программного обеспечения заключается не в объеме кода, а в его надежности. Победителем 2026 года станет не тот, кто больше всех использует ИИ, а тот, кто лучше всех его контролирует для проектирования безотказных систем. Развивайтесь как архитектор, способный координировать системы, а не просто исполнитель. Неуклонное стремление к качеству — это единственный ключ, способный превратить горы сгенерированного кода в ценный бизнес-актив.