Передовые модели сейчас действительно хорошо пишут код — лучше, чем справляются с большинством других задач. Работа с агентами ощущается как взгляд из будущего: полигон для проверки того, насколько далеко можно зайти с агентными возможностями. Это заряжает, даёт результат и при этом — откровенно странно ощущается.
Я веду список советов по агентному кодингу: правила и ориентиры для тех, кто только начинает работать с Codex, Claude Code, Pi или любым другим агентом. Каждый пункт — обобщённая рекомендация, применимая к агентному программированию в целом. Хочется, чтобы уроки оставались актуальными по мере того, как улучшаются модели и инструменты.
Ниже — текущий список: 10 уроков агентного кодинга. Десять — красивое круглое число, хороший повод опубликовать.
Оговорюсь: я лишь отточил и систематизировал эти принципы. Как сказал мне сегодня Кшетраджна Рагхаван: «Это безумно — как все мы независимо приходим к одним и тем же выводам».
(Если считаете, что что-то упущено — напишите.)
Реализуй, чтобы понять. Можно далеко уйти с Spec-Driven Development, но сам процесс написания кода выявляет решения, о которых вы не думали, и делает спецификацию лучше. Когда код стоит крайне дешево — реализуй, чтобы узнать больше.
Пересобирай часто. Собирай сборки как можно чаще, чтобы узнавать больше. Форкай и переписывай свои самые сумасшедшие мысленные эксперименты. Проверяй, докуда можно довести фичу. Конечно, итерации и накопление работ никто не отменял — но дешёвый код позволяет разведывать и переизобретать так, как раньше было невозможно.
Вкладывайся в end-to-end тесты. Когда код можно пересобрать дёшево, стоит тратить время на тесты, которые измеряют функции продукта, а не способ их реализации. Нужны поведенческие контракты, дающие свободу перестраивать и переписывать.
Документируй намерение. Тесты описывают цели, код — методы, но ни то ни другое не отвечает на вопрос зачем. Намерение стоит за решениями, и если зафиксировать его рядом с кодом, это помогает вам и агенту двигаться в одном направлении.
Держи спецификации актуальными. Обновляй spec-файлы — markdown-документы с целями и планами — по мере продвижения кода и тестов. Если относиться к спецификации как к замороженному артефакту, написанному до начала работы, упустишь всё, что узнал в процессе. Актуальная спецификация постоянно направляет ваши решения и решения агента, а частые сборки становятся проще.
Ищи сложное. Поработав над проектом достаточно долго, начинаешь упираться в реально трудные вещи: интуитивный дизайн, производительность, безопасность, отказоустойчивость, системную архитектуру. Лёгкое вайбкодить может каждый. Ценность — в сложном. Найди его и копай.
Автоматизируй всё простое. Чтобы больше времени тратить на сложное, минимизируй время на лёгкое. Упаковывай знания в Skills, создавай Hooks, автоматизируй code review, давай инструментам накапливать работу.
Развивай вкус. Когда код появляется быстро, а обратная связь — нет, единственный источник фидбека, который успевает за темпом, — это ты сам. Чем лучше знаешь свою область, пользователей и их проблемы, тем дальше можешь зайти без остановок на проверку.
Агенты усиливают опыт. Опытные разработчики недооценивают, сколько интуиции они вкладывают в промпты: правильные термины, правильный фрейминг, правильный уровень конкретики. Знание своего стека экономит множество циклов при реализации и отладке, сокращает лишнее хождение агента по кругу. Техническая экспертиза в связке с хорошим вкусом — трудно бить такую комбинацию.
Код дешевый, но поддержка, сопровождение и безопасность — нет. Агентный код бесплатен в том смысле, в каком бесплатен, например, щенок. Поддержка стоит дорого, и безопасность тоже. Строй быстро, но отдавай себе отчёт в том, что берёшь на обслуживание.
Русскоязычное сообщество про AI в разработке

Друзья! Перевод этой статьи подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-агентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
Комментарии (6)

Actek92
05.05.2026 17:20Ключевая проблема агентного кодинга — не в том, чтобы код был написан, а в том, чтобы он был написан правильно и поддерживаемый.
Основной совет: не доверяй агентам слепо, проверяй результат. Лучше потратить 10 минут на review кода, чем потом месяц дебажить.
Агенты отлично подходят для прототипирования и генерации boilerplate — но для production-кода нужны чёткие критерии качества. Код должен быть читаемым, а не просто рабочим. Если агент сгенерировал сложный кусок кода — проверь его логику вручную. Для защиты системной безопасности стоит посмотреть на open-source WAF "SeptumCore" на GitHub — он лёгкий, без магии и ставится за 5 минут.

Dhwtj
05.05.2026 17:20Этого мало
Код должен
Соответствовать намерениям (требованиям, ограничениям, ценностям, приоритетам)
Low coupling - Изоляция, изменения требований должны менять только свой кусок кода
High cohesion - Локальность, логика дожна быть сконцентрированной в одном месте, читаемой, проверяемой
Прозрачность. Насколько видно, что система делает и где это выражено. Неявные правила, магия порядка вызовов, скрытые побочки, всё это бьёт сюда.
Гибкость, эволюционируемость
Все эти архитектурные свойства сильно страдают в легаси. Да и LLM они плохо поддаются потому что он не знает намерений, планов развития, имеет только формальное понимание читаемости и прозрачности.
Если огрубить и обобщить то водораздел: свойства, требующие удержания глобального или трудно формализуемого контекста и намерений (гибкость, адекватность) это слабое место и легаси, и LLM. Свойства локальные и формализуемые сильное.

Bardakan
05.05.2026 17:20Вкладывайся в end-to-end тесты. Когда код можно пересобрать дёшево, стоит тратить время на тесты, которые измеряют функции продукта, а не способ их реализации. Нужны поведенческие контракты, дающие свободу перестраивать и переписывать.
странно. В 90% компаний, где я работал, тесты не писались в принципе - на них просто никто не выделял времени. И до сих пор не выделяют - даже с появлением ИИ.
Dhwtj
Однозначно согласен только с 4 и 10 пунктом
Вкратце:
Насмотренность на хороших примерах, но необоснованно принятых в вашем проекте, скорее вынесет вам мозг раньше чем вы накопите опыт. Особенно, если вам придётся возвращаться и менять потому что выбор оказался не верным. Или если есть десятки решений, локально оптимальных. Выбор между ними превращается в игры разума если не остановиться
Быстрая проверка гипотез работает только если есть слабо формализуемые хотелки, например вкусовщина по визуалу. Ещё проверка A/B гипотез. Эффективность обоих так себе.
E2E тесты важные и гибкие, но дорогие в проверке. Важность юнит тестов никуда не делась
Спецификации верхнего уровня не зависят от кода. Их меняют при изменении требований и приоритетов, а не кода. А уровнем ниже если программа написана хорошо то спецификации явно видны из типов данных и сигнатур функций.
Остальные пункты сводятся к этим
ToniDoni
Наверное автор намекал на то что обычно юнита всё-таки пишут, а е2е нет, хотя соответствие продукта требованиям проверяют именно последние.