В одной из проверок VECTA агент получил практически пустой проект. При этом в исходной папке файлы были. Пользователь видел их, мог открыть в редакторе и ожидал, что агент начнёт с ними работать.
Причина оказалась прозаичнее проблем с моделью: в репозитории был пустой начальный коммит, а файлы ещё не попали в Git. Мы создавали рабочую копию задачи из HEAD. С точки зрения Git всё происходило правильно. С точки зрения пользователя инструмент потерял проект.
Год назад мой типичный пулл‑реквест писался руками часа три и ревьюился минут двадцать. Сейчас четыреста строк агент выдаёт за минуту, а ревью того же дифа занимает час: приходится вычитывать уверенно написанный чужой код, в котором ошибка выглядит ровно так же убедительно, как правильное решение. Узкое место переехало с набора кода на его проверку, и усилием воли оно не расширяется.
В августе у Google вышел текст о том, почему Go хорошо подходит для разработки с агентамиЧитать полностью »
Сначала нам советовали подробно задавать правила в промпте. Промпты росли и постепенно превращались в:
Ты опытный программист. Пиши хороший код. Плохой код не пиши.
Потом появился следующий рецепт: сначала подготовьте подробную документацию, а уже затем поручите агенту писать код. В результате люди начали сначала генерировать агентом документацию, а потом тем же агентом — код по этой документации. Между человеком и кодом просто появился ещё один слой сгенерированного текста.
“AI agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole…”
«AI-агенты создают отдельные изменения, которые хорошо выглядят сами по себе. Они согласованы внутри себя и соответствуют вашему запросу. Но целостность всей системы при этом остаётся без внимания».
— Mo Bitar, создатель Standard Notes, после двух лет активной разработки с AI
Представьте свою команду через пару лет после того, как все в ней дружно подсели на ИИ. CI зелёный. Покрытие почти сто процентов. Фичи выкатываются быстрее, чем раньше. А теперь подойдите к любому и попросите у доски объяснить, как вообще устроена система: где границы модулей, почему контракты именно такие, что рванёт, если потянуть вот за этот сервис. И окажется, что целиком этого не знает никто. Код есть, он работает, и его никто не понимает.
Привет!
Я фрилансер! ТГ-боты, бэкенды, AI-интеграции, с недавних пор embedded. В прошлой статье я показывал, как биржу залило вайб-кодерами и как просели цены на базовые проекты. Но там я говорил про цену. А есть вопрос следующий: а код-то у них рабочий? В смысле — рабочий по-настоящему, а не «вроде запускается».
Сразу дисклеймер: я каждый день работаю через Claude Code, я на них построил весь свой процесс. Именно поэтому мне интересно где у них системный предел.
И я внутри этого рынка, объективности не обещаю.
Сразу разведём понятия, потому что на этом стоит вся статья.
Я больше года не пишу код руками — всё пишет ИИ. При этом я не вайбкодер. Скромно называю себя ИИ-инженером.
Материал подготовлен на основе выступления Фионы Фунг (Fiona Fung), главного инженера команды Claude Code. Ссылка на публикацию.
Сегодня я наткнулся на кое-что, что показалось мне весьма ценным.
Это довольно редко встречается — AI-компании вроде Claude действительно делятся мыслями и размышлениями об организационной структуре.
Boeing ведёт статистику авиационных происшествий с 1950-х. Одна цифра там не меняется уже несколько десятилетий: около 80% катастроф связаны исключительно с человеческим фактором. При этом сами самолёты за это время стали в разы надёжнее, а автопилоты в разы умнее. Парадокс в том, что эти два факта связаны между собой.
