Проблема кодинга с 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 — это ваш единственный способ отменить "инициативу" агента, которая пошла не туда.
Если вам было полезно, то подписывайтесь на наши телеграм каналы:
И вот ещё бонусом список дополнительных материалов на темы, о которых мы рассказали в этой статье:
Про контекст:
Про планирование:
Про приемку:
Про верификацию:
Про git:
Комментарии (37)
nikulin_krd
16.02.2026 12:28Такое впечатление, что статью написал не разработчик, а очередной «вайб-кодер». Во-первых, LLM это немного не ИИ. Во-вторых, текущие LLM - это джуны, а в некоторых случаях весьма дремучие джуны. В-третьих, LLM подвержены галлюцинациям, самодеятельности, забыванию контекста и игнорированию плана, вне зависимости от уровня подготовки задания. Opus 4.6 сейчас стал +- походить на какого-нибудь свежего мидла
timurkhakhalev Автор
16.02.2026 12:28>Во-первых, LLM это немного не ИИ
А тогда что такое LLM и что такое ИИ?))
>Во-вторых, текущие LLM - это джуны, а в некоторых случаях весьма дремучие джуныНу у кого как, но на мой взгляд, когда нечто довольно самостоятельно и может выполнить задачу по плану, то это вполне хороший миддл
> В-третьих, LLM подвержены галлюцинациям, самодеятельности, забыванию контекста и игнорированию плана, вне зависимости от уровня подготовки задания
Ага, работу с контекстом никто не отменял, но с современными моделями gpt этого требуется меньше, чем с моделями claude, даже с opus 4.6
Enuriru
16.02.2026 12:28разумеется это вайбкодинг :)
профессионал рассказал бы про belief state, позиционные кодировки, семантические разметки, автогенерацию многоуровневых доков, семантические графы приложений, да хотя бы про MCP-доступ к документациям фреймворков. В общем все то что позволяет агенту реально автономно работать с проектами из сотен файлов и сотен тысяч строк кода не теряя контекст.timurkhakhalev Автор
16.02.2026 12:28Ничего из этого не используется в реальной практике и в большинстве своем несёт ненужный оверхед.
Если человек разберется с базой, о которой написано в статье, то он может добавлять все эти модные слова по мере необходимости
deksden
16.02.2026 12:28Вы описываете какой то вымышленный флоу
Позиционные кодировки используют модели в работе с контекстом внутри, это не технология пользвоательского уровня.
Семантические графы - есть любители, но это один из подходов. Если вы не финтех со строгим регулированием и требованиями полной трассируемости кода и RLM, то смысла особого в графе нет.
MCP доступ к документации - возможно context7 можно упомянуть. Но его заменяет в грамотном флоу веб поиск в случае вопросов. Либо нормальная модель со свежим knowledge cutoff. К тому же отрасль движется от MCP к библиотекам Skills и обвязке CLI в скиллы. Так что это не для начинающих - это для продолжающихИ проект из сотен файлов и сотен тысяч строк кода - это не уровень начинающего. Не путайте целевую аудиторию.
deksden
16.02.2026 12:28Современное поколение моделей - начиная с gpt 5.2 и opus 4.5 - уже ни разу не джуны. В нормальном флоу и с нормальной подготовкой проекта к ИИ разработке все работает весьма толково.
Проблем с галлюцинациями в текущем поколении моделей на распространенных стеках нет от слова совсем.
Самодеятельность - зависит от качества промптинга. С гпт все просто, а вот для Опуса требуется некоторый навык и понимание его особенностей.
Забывание контекста в пределах свежей сесси до компакта отсутствует, а до компакта доводить ее непрофессионально.
План современными моделями не игнорируетсяВаше мнение построено или на устаревшей информации, или на работе со слабыми моделями. Текущий фронтир такими особенностями "давно" не обладает (уже пару релизов). И опус 4.6 - не вершина в кодинге.
nikulin_krd
16.02.2026 12:28То что вам в ваших задачах не попадались галлюцинации современных моделей, не означает что их нет. Это же как «ошибка выжившего»
Tzimie
16.02.2026 12:28Вычитывать тысячи строк кода за AI утомительно и опасно — глаз "замыливается".
Ой, все
vpgromov
16.02.2026 12:28Зачем вычитывать тысячи строк кода, когда можно открыть соседнее окно консоли и попросить его же сделать ревью)
deksden
16.02.2026 12:28Не только ревью
Если говорить о флоу, то сначала делаем чеки (lint/typecheck/build/test:unit/test:integration/test:e2e), потом - верификацию (сверим план с фактом), а потом - можно и ревью
Я в канале как раз последний эвал делал на ревью кодовой базы раными моделями. Тестили свежих китов против фронтира
Astrowalk
16.02.2026 12:28Это вайбкодинг. Признак, по которому его отличают от более здоровых практик – принципиальный отказ от человеческого ревью, просмотра специалистом сгенерированного кода.
Dhwtj
16.02.2026 12:28Точно.
Приемка: Тесты вместо Code Review
Тесты фигня. Даже golden tests фигня. Только отвлекают и рассеивают сознание.
Гораздо лучше делать правила, проверяемые компилятором.
ilyes-garif
16.02.2026 12:28Если агент ошибается, это почти всегда проблема процесса:
Контекст: не собран, противоречив или содержит мусор.
Инструкции: их мало, они не директивные, слишком абстрактные или, наоборот, перегруженные деталями.
Критерии: нет автотестов, вы не объяснили, что такое "хороший результат".
Если вот это все мешает мидлу решить задачу, то это не мидл ) мидл приходит с правильными вопросами
AndPronin
16.02.2026 12:28Быть может, стоит по TDD тогда писать, раз все равно надо про тесты думать?
Astrowalk
16.02.2026 12:28Вот да. Тут пропагандируют генерировать агентами и код, и тесты и ревью. Точка контроля размывается. Ну, может, и так можно сделать надёжную систему, посмотрим.
AndPronin
16.02.2026 12:28Интересно, сколько это в итоге будет обходиться. Магия вне Хогвартся не бесплатна
Astrowalk
16.02.2026 12:28Как раз сегодня был ответ: $118 за один запрос ☺
https://habr.com/ru/news/1000302/
Nic50
16.02.2026 12:28Круто! Но если нет денег на агента, можно воспользоваться схемой уменьшения контекста — это очень хорошо работает. Просто пишем задание, он его делает, а потом делаем прогрев из прошлой сессии или калибруем его прямо в чате и просим переписать задание под систему. Иногда можно обойтись и без этого, если написанная функция имеет достаточно большую автономию.Еще я заметил, что машина часто врет, говоря, что все готово. Если автотест написан ею же, она может сгенерировать код, который будет проходить только этот тест — так сказать, сделает именно то, что попросили. Поэтому, если есть возможность протестировать все вручную, это будет идеальным планом. Однако тут уже все индивидуально.Я бы сказал, что самое важное в работе с ИИ — точно понять, что должно быть в конце и как к этому нужно прийти. После этого это можно описать максимально декларативно и подправить углы. Если со второй попытки ничего не получится, то придется смириться и работать самостоятельно — так будет быстрее.
anshdo
16.02.2026 12:28У меня по прочтении всего этого возникает один вопрос. А не быстрее будет самому написать код, чем вот это всё? (в моей практике ОБЫЧНО получается быстрее).
AnyKey80lvl
16.02.2026 12:28Какой-нибудь скрипт интеграции средней сложности любая современная модель напишет Вам за минуту. А Вы - нет ) Причем он у нее заработает с первого раза.
anshdo
16.02.2026 12:28Вот только чтобы она его за минуту написала, мне придется сначала два дна собирать правильный контекст, писать вИдение, планы, правила, тесты ... а потом да, она за минуту напишет ... может быть.
cdriper
16.02.2026 12:28так все такого рода писули публикуют те, кто вообще ничего в программировании не понимает. и принципиально не хочет учиться.
поэтому ужасный недоджуновский код LLM для них это код мидлов )
M_AJ
А может быть не такая уж она и мидл, если мидлы всегда справлялись, а модель не справляется?
deksden
А не встречались в жизни с такой ситуацией: заказали команде какую то софтину, они приносят результат - а там ерунда какая то, которая заказчику не нравится и вообще он не то имел ввиду? По мне так распространенная ситуация
Только с агентами ситуация немного сложнее - они не все переспрашивают и уточняют. В план-модах некоторых агентов не даром добавили инструмент "задать вопросы польователю".
Поэтому - да. Агенты могут делать хорошо, но пока не волшебники, и не могут угадывать. И у них не такой промптинг чтобы отказываться делать, пока им самим задача не до конца ясна. Входите в ситуацию
nikulin_krd
А когда в плане все указано, а он берет и делает совсем другое?
deksden
так бывает крайне редко, я в последнее время такого не встречал. Раньше такое бывало с небольшими локальными кодинговыми моделями
У нынешнего поколения gpt моделей (и базовых, и -codex версий) весьма неплохо со следованием инструкциям. Клод тоже нормально слушается инструкций, только ему надо их немного строже ставить и верифицировать.
Поэтому я не встречался с такими кейсами - когда "берет и делает совсем другое". Бывало что в большом плане не все делает, но в моих влоу всегда есть этап верификации на такой случай.
А у вас с каким агентом и моделью такие случаи бывали?
Maslennikovig
Я бы даже сказал, что на последних моделях такого не бывает почти никогда. И в 99,9% случаев, если такое происходит, проблема в кожаном.
M_AJ
Может быть везло, но обычно больше всего сложностей с тем, чтобы получить внятные требования от заказчика, а вот в коммуникации между инженерами уже минимум таких проблем, так как есть некая общая база, а если они что-то не поняли, то попросят выражаться яснее. И это это одна из характеристик, которые отличают мидла от джуна – мидл лучше понимает, чего именно у него просят, и какие моменты лучше сразу уточнить, если они ему непонятны.
deksden
Ну вот ровно как с моделями сейчас - агенты уже в план-моде спрашивают у пользователя если им что то непонятно. Кодекс бывает спорит по решениям. Так что технологии развиваются. Я оцениваю их по поыту как уверенных мидлов, хотя еще несколько месяцев назад это были скорее джуны. Но уровень gpt 5.2/opus 4.6 какую то границу перешел.
LionMuzzle
Агент это не просто мидл, а мидл вышедший в 1 рабочий день на вашем проекте.
deksden
Зависит от системы работы с контекстом на вашем проекте.
В моих проектах с меморибанком и флоу агенты себя чувствуют "в теме". Для этого используем progressive disclosure на старте сессии, и "прогрев" сессии вопросами по теме работы (я называю этот процесс праймингом).
Всем советую! Рещультаты работы будут совсем другие
LionMuzzle
Все так. Я тоже в нашем большом проекте сначала по 2 часа составлял промпт, чтобы грамотно объяснить суть дела, и получал качественный результат. А потом появились rules)) и стало намного лучше.