Агенты писали плохой код: разработчик нашёл причину в устройстве проекта
Агенты писали плохой код: разработчик нашёл причину в устройстве проекта Разработчик Кайра Берк Тунчер рассказывает, что у команды стало всё труднее писать код с помощью ИИ: проект разрастался, а агенты вроде Cursor и Claude Code — инструменты, которые сами правят код по запросу, — при простой правке интерфейса делали её «не как у всех» в проекте. Автор приводит пример: агент по-своему управлял состоянием страницы, копировал уже существующие вспомогательные функции, добавлял случайную стороннюю библиотеку и игнорировал правила оформления, принятые в команде. Сначала автор, как и многие вокруг, винил саму модель — «модель A плохая, модель B дорогая». Но, по словам автора, проблема оказалась не в модели и не в маленьком «контексте» — объёме информации, которую агент видит за раз, — а в устройстве самого проекта. Человек, который сам строил архитектуру, знает, что где лежит; агент этого не знает, а если дать ему прочитать весь код, контекст разбухает и качество его рассуждений падает. Вывод автора: одними улучшенными подсказками и ожиданием новой модели проблему не решить — проект нужно изначально делать удобным для ИИ-агентов. Первое изменение — перевести всё в монорепозиторий (единое хранилище кода вместо многих отдельных) на связке Turborepo и pnpm — менеджера пакетов, который ставит нужные библиотеки. Раньше, когда части продукта лежали в разных репозиториях, агенту для простой задачи приходилось скачивать и держать в контексте несколько проектов — терялось время и деньги на токены (кусочки текста, которыми модель измеряет объём), а иногда результата не было вовсе. Теперь весь код в одном месте, и, прося агента поработать над модулем заказов, автор даёт ему доступ только к нужным общим пакетам, а не ко всему проекту. Второе — жёсткие границы между модулями. Модули не могут обращаться друг к другу напрямую, только через общие пакеты и «оболочку» приложения. Плюс приём с версиями: когда общий пакет обновляется, один модуль переходит на новую версию сразу, а остальные — только по явному решению команды, чтобы одно изменение не сломало всё разом. Для ИИ это ещё и защита: если сказать агенту «работай только внутри модуля заказов», он физически не может что-то сломать в модуле каталога — пути для этого просто нет. Третье — правила для агента, разбитые по уровням. Без явных правил агент пишет «усреднённый» код из своих обучающих данных: например, прямые запросы к сети вместо принятого в команде обёрточного решения. Файл правил AGENTS.md решает это, но автор предупреждает: нельзя вываливать все правила сразу — по его ссылке на исследования, после примерно 3000 токенов загруженных правил качество рассуждений модели заметно падает. Поэтому общие правила грузятся всегда, а правила конкретного модуля — только когда агент его правит. Правило нужно записывать сразу, как только появился новый шаблон в коде, а не через полгода, и подкреплять автоматическими проверками, чтобы агент сразу видел нарушение. В итоге, по словам автора, подсказки для агента стали короткими: достаточно указать модуль, задачу и путь к нужным правилам. Главный вывод материала: узкое место чаще не модель, а запутанный проект, и выгоду от ИИ-инструментов даёт хорошо продуманная среда. Цифр экономии или ускорения автор не приводит — это мнение и личный опыт, а не измеренный кейс. В конце статьи автор упоминает свой сторонний сервис для выбора технологического стека — это отдельный проект, не часть описанного подхода. Источник: https://hackernoon.com/your-architecture-is-why-your-coding-agent-keeps-writing-bad-code