6 советов от практиков AI coding

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

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

Старые практики уже не работают и нам просто жизненно необходимо подготавливать соломку для этих агентов (настроенные тесты, линтеры и автоматизировать ручные процессы), научиться делегировать им задачи, а потом ещё и не утонуть потом на этапе код ревью.

За 2025-й год я перепробовал много различных практик написания кода с AI. Примерно, начиная с лета, эти практики уже устаканились, к концу года скорректировались и вот, мы уже можем говорить о best practices, которые точно работают в AI coding.

Об этих best practices говорят и в OpenAI и в Anthropic, в Spotify и других гигантах, но с опозданием на несколько месяцев.

Я (Тимур Хахалев, эксперт в AI coding) попросил моего коллегу Дениса Киселева (AI SOLO предприниматель и AI-SWE эксперт) собрать актуальные best practices по AI coding, а сам упаковал это в статью.

Эти простые советы сэкономят вам несколько месяцев времени наступлений на грабли.

1. Ошибки агента это ваша ответственность

Первое и самое сложное — отпустить вожжи. Теперь не вы пишете код. Теперь вы организуете работу того, кто пишет код.

Уходите от узкого мышления "агенты пишут плохой код" – как минимум, для фронтирных моделей и распространенных стеков это точно не так, уровень моделей это уверенный мидл.

Да, агенты ошибаются, но почти всегда, это проблема процесса и скорее на верхнем уровне.

Перестаньте думать: "Агент написал плохой код, AI плохой".

Начните думать: "Я дал плохие инструкции или кривой контекст, раз мидл-разработчик (а современные модели это уверенный мидл) не справился".

Если агент ошибается, это почти всегда проблема процесса:

• Контекст: не собран, противоречив или содержит мусор.

• Инструкции: их мало, они не директивные, слишком абстрактные или, наоборот, перегруженные деталями.

• Критерии: нет автотестов, вы не объяснили, что такое "хороший результат".

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

Если ваш стек редкий, придётся работать техничнее: с примерами, с образцами, с поиском в интернете для конкретных кейсов.

2. Контекст — это топливо

Агент не телепат. Он не знает ваш проект так, как вы.

• Принцип "Сверху-вниз": Перед стартом любой задачи дайте агенту изучить проект. Пусть пройдет от архитектуры к подсистемам. Не кидайте его сразу в бой с багом в 500-й строке непонятного файла.

• Прогрев: Идеально, если у вас есть Memory Bank (файлы с описанием архитектуры и правил проекта). Если нет — попросите его исследовать ваш проект сверху вниз, от общей конструкции к подсистемам: какие подсистемы существуют в проекте, как они взаимодействуют, для чего предназначены.

Узкий фокус: Когда общее понимание есть, задавайте вопрос по более узкой теме, касающейся вашей доработки. "Подготовься к задачам по модулю аутентификации"*. Пусть агент подтянет в контекст только релевантные файлы и связи.

3. Планирование

Никогда не начинайте реализацию без утвержденного плана.

1. Автономность

Агент должен включить в план всё, что требуется для его реализации:

• указать тонкие моменты, которые имеются;

• сослаться на стандарты/нормы/правила проекта;

• учесть правильное взаимодействие подсистем;

• использовать принятые в проекте зависимости;

• избегать оверинжиниринга;

• решать проблемы максимально простым способом с сохранением полной функциональности.

2. Закрытие пробелов

Сформировав план, попросите агента:

• перепроверить его;

• дополнить тем, что было забыто;

• прояснить и задать вопросы по всем непонятным темам;

• закрыть оставшиеся непроработанными gaps.

Только когда у агента нету вопросов, можно считать план доработанным.

Всегда делайте финальную полную версию плана единым текстом.

3. Фиксация

Всегда сохраняйте оригинальный план в .md файл, чтобы на него можно было ориентироваться.

Даже если ваш агент здорово управляется с контекстом (как Codex CLI) – это все равно абсолютно необходимый шаг.

4. Реализация плана – самая простая вещь!

Просите агента сделать пункты плана и ведите его до полной его реализации.

4. Приемка: Тесты вместо Code Review

Вычитывать тысячи строк кода за AI утомительно и опасно — глаз "замыливается". Измените подход к приемке.

Больше думайте о критериях качества работы:

• какие тесты сделать;

• какие приемочные сценарии прогнать, чтобы убедиться, что всё ок.

Обратная связь должна быть доступна агенту – критерий оформлен тестом и агент его может запускать для самопроверки, а не просто "эстетичный экран корзины в интернет магазине".

Очень важно дать агентам критерий качества.

Прорабатывая фичу, сразу обсуждайте, как будете её тестировать.

Самый важный тест это e2e сценарий использования фичи. Агент должен делать интеграционный e2e тест.

Все остальные тесты хоть и полезны, но менее важны!

Но вам нужен критерий проверки фичи. Остальной код и тесты служат лишь тому чтобы фича работала как надо.

5. Верификация: Сверка с реальностью

Очень важный шаг в конце. Это нужно даже очень внимательным агентам, как Codex.

А "творческими" натурам как Claude, без верификации можно недосчитаться реализации части пунктов.

Просите агента взать оригинальный .md файл плана, и систематично по пунктам сверить реализацию плана с конкретными файлами кода, документации и тестов. Просить проверить каждую деталь и дать вам отчет.

На базе отчета составьте план доработки при необходимости и доработайте.

• Финальный этап: когда агент говорит "Готово", не верьте.

• Процедура: попросите его открыть файл с планом и пройтись по каждому пункту, сверяя его с реальным кодом.

• Отчет: пусть выдаст отчет: "Пункт 1 — сделано (файл А), Пункт 2 — сделано (тест Б)". Это спасает от 80% недоделок.

6. Git-гигиена: Сохраняйтесь!

Используйте git

Сформировали план? *Commit.**

Реализовали пункт плана? *Commit.**

Прошли тесты? *Commit.**

Git — это ваш единственный способ отменить "инициативу" агента, которая пошла не туда.

---

Если вам было полезно, то подписывайтесь на наши телеграм каналы:

• Тимур Хахалев про AI coding

• DEKSDEN Notes про AI разработку и технологии

И вот ещё бонусом список дополнительных материалов на темы, о которых мы рассказали в этой статье:

• Мифы Vibe Coding и "охотничьи рассказы"

• Почему модель не справляется (это вы виноваты)

Про контекст:

• Как документация и правила экономят сотни часов

• Что такое Memory Bank

• Прайминг контекста, если нет Memory Bank

• Реверс-проектирование существующих проектов для агентов

• Основные проблемы контекста

Про планирование:

• Планирование с агентом: работа после прайминга

• Протокол #DeksdenFlow: Этап фиксации плана

Про приемку:

• Про инструменты для e2e тестов

• Тестирование в эпоху AI агентов

• Бизнес-процессы и E2E тестирование

Про верификацию:

• Коротко о верификации

• Схема работы "Критик"

Про git:

• Git Flow при работе с агентами

• #DeksdenFlow: Git и worktree

Источник