Всем привет! Меня зовут Дина, я Java‑разработчик, около шести лет в энтерпрайзе. С апреля начала делать пет‑проект вместе с ИИ‑агентом: он писал код, я ставила задачи и смотрела на тесты. Всё шло хорошо: тесты были зелёными, сценарии закрывались, а потом я открыла проект и поняла, что чётко не осознаю, как в нём устроен главный сценарий: от запроса до готового видео. Эта статья о том, как я возвращала себе понимание собственного кода.
С приходом ИИ‑агентов в разработку, кода стало больше, а вместе с ним и шума. Пулреквесты растут, держать агента в рамках задачи становится сложнее, а через голову человека проходит всё больше кода. Ревью превращается в основную нагрузку и зелёные цифры добавленных строк в заголовке начинают напрягать ещё до того, как его откроешь.
Типичная картина: пулреквест на небольшую фичу, а в нём правки в десятке файлов, которые к задаче не относятся. По отдельности они могут быть полезными, но вместе они превращают пулреквест в солянку.
Привет! Я фулстек‑разработчик в TravelLine. Мы делаем единую систему для гостиничного предприятия, которая помогает отелям, санаториям и другим средствам размещения автоматизировать свои бизнес‑процессы. В этой статье я расскажу о том, как мы внедрили ИИ для генерации описаний PR/MR.
У нас два хостинга репозиториев и столько же билд‑серверов: одни команды живут в GitLab со сборкой в GitLab CI, другие — в Bitbucket Server (в компании его до сих пор зовут Stash) со сборкой в Jenkins. Общее у них одно: поле описания merge/pull request зачастую пустое или содержит только список commit messages.
В одной из проверок 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 зелёный. Покрытие почти сто процентов. Фичи выкатываются быстрее, чем раньше. А теперь подойдите к любому и попросите у доски объяснить, как вообще устроена система: где границы модулей, почему контракты именно такие, что рванёт, если потянуть вот за этот сервис. И окажется, что целиком этого не знает никто. Код есть, он работает, и его никто не понимает.
