К пятому заданиюагент знает ваш кодхуже, чем к первому.

Перед первой задачей ИИ-агенты прочитали 83,6% нужного кода проекта.

Перед пятой — 35,4%.

Мне эта цифра понравилась сразу.

Это исследование вышло 28 сентября. Агентам давали задачи в настоящих репозиториях по одной, как в жизни: сначала одно требование, потом следующее. Четыре модели, две обвязки, три тысячи ходов. К пятому ходу в половине цепочек агент заново написал то, что в проекте уже было. Даже собственный код, написанный ходом раньше, он брал всё реже.

Потому что с людьми обычно наоборот.

Новичок в понедельник открывает всё подряд, спрашивает, где лежит функция для дат и кто вообще писал модуль оплаты.

К пятнице уже ориентируется.

У агента получается забавная карьера.

В первом задании он прилежный стажёр.

К пятому — тот самый старожил, который «да я помню», ничего не открывает и потом пишет четвёртую версию функции formatDate.

Самое неприятное: тесты при этом проходят. Доля пройденных проверок, пишут авторы, почти не менялась.

То есть агент не обязательно пишет неработающий код.

Он пишет работающий код, который уже был.

Это хуже видно.

И иногда дороже.

Представьте три папки.

В каждой своя функция форматирования даты.

Все три зелёные.

Все три покрыты тестами.

Все три делают примерно одно и то же.

Это уже не кодовая база, а местный фольклор. В каждой деревне своя версия легенды.

Поменяли формат даты.

В двух местах поправили.

Про третье забыли.

Через месяц кто-нибудь ещё раз «решит проблему» и добавит четвёртую.

В масштабе отрасли картина та же. GitClear разобрал 623 миллиона изменений кода. В 2022 году перенесённый код составлял 21% изменённых строк, с начала 2026-го — 3,8%. А повторяющихся блоков на миллион изменённых строк стало на 81% больше, чем в 2023-м. Перенос — это и есть рефакторинг: общее выносят в одно место. Код всё чаще дописывают и всё реже перекладывают.

Обычно, когда обсуждают ИИ-код, спорят, что он пишет слишком много.

Мне кажется, проблема ещё проще.

Он мало читает.

Если перед задачей не посмотреть, что уже есть, новый код почти неизбежно кажется отличной идеей.

Это, кстати, не только проблема моделей.

Просто человек обычно получает по голове от коллег на ревью и постепенно учится сначала искать.

Модель новый день начинает свежей.

Поэтому я бы поменял сам порядок просьбы.

Не:

«Напиши функцию, которая делает X».

А:

«Найди, где X уже делается в проекте. Покажи мне. Если такого нет — только тогда предложи реализацию».

Разница вроде косметическая.

Но поиск занимает секунды.

Дубль потом живёт годами.

На ревью я бы тоже смотрел чуть иначе.

Новая helper-функция от агента — не повод сразу проверять, правильно ли она написана.

Первый вопрос:

а почему она вообще новая?

Где ты искал существующую?

Что нашёл?

Почему не переиспользовал?

И ещё я бы не держал одну агентную сессию весь день, если задачи сильно меняются.

Большой контекст почему-то создаёт приятную иллюзию: модель «уже всё знает».

А потом выясняется, что знает она как человек, который три часа был на созвоне и к концу уверенно кивает, хотя уже давно думает про обед.

Иногда свежая сессия плюс короткая карта проекта полезнее огромной истории переписки.

В прототипе дубли не страшны.

Прототип всё равно выбросят. Где граница между прототипом и продуктом, я разбирал в справочнике про вайбкодинг.

А в продукте каждый дубль — это ещё одно место, которое завтра забудут поправить.

В заметке о вайбкодинге самой полезной строкой у меня был return null. Здесь лучший ответ агента иногда вообще не код.

А:

«Это уже есть. Вот здесь».