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

Я веду список советов по агентному кодингу: правила и ориентиры для тех, кто только начинает работать с Codex, Claude Code, Pi или любым другим агентом. Каждый пункт — обобщённая рекомендация, применимая к агентному программированию в целом. Хочется, чтобы уроки оставались актуальными по мере того, как улучшаются модели и инструменты.

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

Оговорюсь: я лишь отточил и систематизировал эти принципы. Как сказал мне сегодня Кшетраджна Рагхаван: «Это безумно — как все мы независимо приходим к одним и тем же выводам».

(Если считаете, что что-то упущено — напишите.)


  1. Реализуй, чтобы понять. Можно далеко уйти с Spec-Driven Development, но сам процесс написания кода выявляет решения, о которых вы не думали, и делает спецификацию лучше. Когда код стоит крайне дешево — реализуй, чтобы узнать больше.

  2. Пересобирай часто. Собирай сборки как можно чаще, чтобы узнавать больше. Форкай и переписывай свои самые сумасшедшие мысленные эксперименты. Проверяй, докуда можно довести фичу. Конечно, итерации и накопление работ никто не отменял — но дешёвый код позволяет разведывать и переизобретать так, как раньше было невозможно.

  3. Вкладывайся в end-to-end тесты. Когда код можно пересобрать дёшево, стоит тратить время на тесты, которые измеряют функции продукта, а не способ их реализации. Нужны поведенческие контракты, дающие свободу перестраивать и переписывать.

  4. Документируй намерение. Тесты описывают цели, код — методы, но ни то ни другое не отвечает на вопрос зачем. Намерение стоит за решениями, и если зафиксировать его рядом с кодом, это помогает вам и агенту двигаться в одном направлении.

  5. Держи спецификации актуальными. Обновляй spec-файлы — markdown-документы с целями и планами — по мере продвижения кода и тестов. Если относиться к спецификации как к замороженному артефакту, написанному до начала работы, упустишь всё, что узнал в процессе. Актуальная спецификация постоянно направляет ваши решения и решения агента, а частые сборки становятся проще.

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

  7. Автоматизируй всё простое. Чтобы больше времени тратить на сложное, минимизируй время на лёгкое. Упаковывай знания в Skills, создавай Hooks, автоматизируй code review, давай инструментам накапливать работу.

  8. Развивай вкус. Когда код появляется быстро, а обратная связь — нет, единственный источник фидбека, который успевает за темпом, — это ты сам. Чем лучше знаешь свою область, пользователей и их проблемы, тем дальше можешь зайти без остановок на проверку.

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

  10. Код дешевый, но поддержка, сопровождение и безопасность — нет. Агентный код бесплатен в том смысле, в каком бесплатен, например, щенок. Поддержка стоит дорого, и безопасность тоже. Строй быстро, но отдавай себе отчёт в том, что берёшь на обслуживание.

Русскоязычное сообщество про AI в разработке

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

Комментарии (6)


  1. Dhwtj
    05.05.2026 17:20

    Однозначно согласен только с 4 и 10 пунктом

    Вкратце:

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

    Быстрая проверка гипотез работает только если есть слабо формализуемые хотелки, например вкусовщина по визуалу. Ещё проверка A/B гипотез. Эффективность обоих так себе.

    E2E тесты важные и гибкие, но дорогие в проверке. Важность юнит тестов никуда не делась

    Спецификации верхнего уровня не зависят от кода. Их меняют при изменении требований и приоритетов, а не кода. А уровнем ниже если программа написана хорошо то спецификации явно видны из типов данных и сигнатур функций.

    Остальные пункты сводятся к этим


    1. ToniDoni
      05.05.2026 17:20

      E2E тесты важные и гибкие, но дорогие в проверке. Важность юнит тестов никуда не делась

      Наверное автор намекал на то что обычно юнита всё-таки пишут, а е2е нет, хотя соответствие продукта требованиям проверяют именно последние.


  1. Actek92
    05.05.2026 17:20

    Ключевая проблема агентного кодинга — не в том, чтобы код был написан, а в том, чтобы он был написан правильно и поддерживаемый.

    Основной совет: не доверяй агентам слепо, проверяй результат. Лучше потратить 10 минут на review кода, чем потом месяц дебажить.

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


    1. Dhwtj
      05.05.2026 17:20

      Этого мало

      Код должен

      • Соответствовать намерениям (требованиям, ограничениям, ценностям, приоритетам)

      • Low coupling - Изоляция, изменения требований должны менять только свой кусок кода

      • High cohesion - Локальность, логика дожна быть сконцентрированной в одном месте, читаемой, проверяемой

      • Прозрачность. Насколько видно, что система делает и где это выражено. Неявные правила, магия порядка вызовов, скрытые побочки, всё это бьёт сюда.

      • Гибкость, эволюционируемость

      Все эти архитектурные свойства сильно страдают в легаси. Да и LLM они плохо поддаются потому что он не знает намерений, планов развития, имеет только формальное понимание читаемости и прозрачности.

      Если огрубить и обобщить то водораздел: свойства, требующие удержания глобального или трудно формализуемого контекста и намерений (гибкость, адекватность) это слабое место и легаси, и LLM. Свойства локальные и формализуемые сильное.


  1. Bardakan
    05.05.2026 17:20

    Вкладывайся в end-to-end тесты. Когда код можно пересобрать дёшево, стоит тратить время на тесты, которые измеряют функции продукта, а не способ их реализации. Нужны поведенческие контракты, дающие свободу перестраивать и переписывать.

    странно. В 90% компаний, где я работал, тесты не писались в принципе - на них просто никто не выделял времени. И до сих пор не выделяют - даже с появлением ИИ.


    1. ToniDoni
      05.05.2026 17:20

      Ошибка выжившего