Как работать с ИИ-агентом в коде и не разучиться программировать: 9 практик

Двадцать лет в коде — PHP, Drupal, TypeScript, облачная инфраструктура, а теперь ещё и обслуживание LLM для агентной IDE. За год ежедневной работы с кодинг-агентами разработчики, судя по этому опыту, разошлись на две группы. Одни стали острее: держат в голове больше языков, увереннее принимают архитектурные решения, быстрее читают чужой код. Другие заржавели — кода выходит больше, чем когда-либо, но половину его они не объяснят без открытого агента рядом.

Инструмент у обеих групп одинаковый. Разница в том, что именно они делегируют машине.

Ловушка: делегировать мышление

Цикл по умолчанию выглядит так: промпт → принять → запустить → «работает» → в прод. Ощущается продуктивно, и на коротком отрезке так оно и есть. Тренирует такой цикл ровно один навык — писать промпты. Результат вы получаете, умение — нет. Через полгода вы быстрее производите код и медленнее понимаете его.

Отказываться от агентов ради этого не нужно — меняется роль. Полезно держать в голове три сразу:

• старший напарник, который спорит с вашими решениями;
• резиновая утка, которая умеет отвечать, когда вы думаете вслух;
• студент, чью работу надо проверять и править.

Что отдавать агенту, а что держать у себя

1. Сначала дизайн — и пусть агент с вами спорит

До первой строки кода попросите не реализацию, а варианты. Например, для мультитенантности в сервисе: не пиши код, дай три архитектурных подхода — общая схема, схема на тенанта, база на тенанта — с компромиссами по стоимости, изоляции, миграциям и операционной сложности. Потом спроси, какой вариант выберу я и почему.

Выбираете вы — и записываете, почему именно так. Это и есть самое ценное умение в профессии: принимать архитектурные решения в условиях компромисса, имея под рукой эксперта, доступного круглосуточно. Бонус: сохраните рассуждение как ADR (Architecture Decision Record). Будущий вы и будущие агенты скажут спасибо.

2. «Сначала попытка» — для всего, что хотите освоить

Код, который просто нужен, пусть пишет агент. Код в области, которую вы хотите освоить, пишите сами — и уже потом просите ревью: вот моя реализация, отревьюй как строгий сеньор, укажи баги, неидиоматичные места, проблемы с производительностью и пропущенные краевые случаи. Не переписывай — объясни каждую проблему, а исправлю я сам.

Фраза «не переписывай» тут ключевая. Если агент всё поправит сам, вы не запомните ничего. Если правите вы — запомните.

3. Правило «объясни своими словами»

Перед мержем любого сгенерированного кода действует условие: я должен уметь объяснить каждую строку. Не могу — это не повод доверять агенту, это дырка в моих знаниях. Наткнулись на такую строку — переверните роли: не объясняй мне код, устрой квиз. Задай пять вопросов о том, что делает функция, почему она написана именно так и что сломается, если её изменить, и скажи, где я ответил неверно.

Квиз вскрывает пробелы заметно быстрее, чем чтение объяснения.

4. Новый язык — переносом кода, который вы уже понимаете

Возьмите небольшой модуль на своём основном языке (скажем, PHP) и сами перепишите его на целевом — Go, Rust, что угодно. Дальше запрос: сравни обе версии и покажи, где мой код — это «PHP, записанный синтаксисом Go». Для каждого случая дай идиоматичный вариант и объясни концепцию языка за ним: интерфейсы, обработку ошибок, владение, конкурентность.

Логику домена вы знаете, поэтому всё внимание уходит на сам язык — его идиомы, систему типов, способ работы с ошибками. Учитесь на собственных ошибках, а не на примерах из туториала.

5. Спрашивайте «почему» и просите проверяемый источник

Агенты уверены в себе даже когда ошибаются. Из этого можно сделать привычку: почему это правильный подход, дай ссылку на раздел документации, RFC или спецификацию языка, чтобы я мог проверить. И потом действительно откройте источник. В половине случаев узнаете то, о чём агент умолчал. В другой половине поймаете его на ошибке — и это научит ещё больше.

6. Ломайте нарочно

Любимый пункт. Закажите агенту упражнение по отладке из вашей же кодовой базы: внеси одну неочевидную ошибку — такую, что пройдёт быстрый ревью и упадёт в проде: гонка, off-by-one, часовой пояс, обработка null. Не говори где. Дай только симптом, который заметит пользователь.

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

7. Архитектурные каты: агент — хаотичный стейкхолдер

Проект выглядит отлично, пока требования не поменялись. Смоделируйте это: вот мой дизайн системы заказов. Играй роль продакта, который меняет требования каждый раунд, и выдавай по одному новому — мультивалютность, частичные возвраты, десятикратный трафик, удаление данных по GDPR. После каждого спрашивай, что поменяется в моём дизайне, и говори, когда он начинает трещать.

Раундов через пять видно, где именно схема хрупкая, и заодно становится понятно, откуда взялись event sourcing, CQRS и гексагональная архитектура. Это знание из опыта, а не из статьи.

8. Ревью агента как джуна плюс журнал ошибок

Каждый PR от агента — как пул-реквест от талантливого джуна: прочитать, задать вопросы, попросить правки. И заведите простой журнал ошибок.

Через месяц такой журнал превращается в личный список анти-паттернов. Ошибки агента становятся вашей экспертизой.

9. Запишите свои стандарты — это заставит их сформулировать

Почти все агентные инструменты умеют читать файл правил проекта — AGENTS.md, CLAUDE.md или аналог. Там описывают конвенции, архитектуру, границы.

Написать такой файл на удивление трудно. Приходится словами оформить то, что вы только «чувствовали»: почему доменный слой отделён от инфраструктурного, когда нужна очередь, а когда синхронный вызов, что вообще значит «готово» в этой кодовой базе. Не получается описать архитектуру внятно — значит, вы её пока не понимаете. Агент просто дал повод разобраться.

Недельный режим

• Каждый день: правило «объясни своими словами» к каждому смерженному PR.
• Дважды в неделю: одну фичу пишете сами, потом отдаёте на ревью агенту.
• Раз в неделю: либо охота на подброшенный баг, либо архитектурная ката.
• Раз в месяц: перечитать журнал ошибок и обновить файл правил.

Это плюс два-три часа в неделю. Взамен вы растёте как инженер, а не просто быстрее набираете промпты.

Как понять, вы учитесь или арендуете навык

Спросите себя честно:

• Собрал бы я фичу прошлой недели без агента, пусть и дольше?
• Ловлю ли я ошибки агента чаще, чем три месяца назад?
• Объясню ли я компромиссы, на которых стоит текущая архитектура?
• Читаю ли я спокойно код на языке, которого не знал полгода назад?

Если везде «да» — агент делает вас сильнее. Если «нет» — вы арендуете навык вместо того, чтобы его построить.

Агенты никуда не денутся и будут становиться лучше. Выиграют те, кто тянет знание из каждого взаимодействия и сохраняет ясную голову, когда агент ошибается. Индикатор простой: если через три месяца вы чаще замечаете промахи агента и можете объяснить больше строк своего кода — вектор правильный.