Как писать код с ИИ. Мнение сообщества
Кажется, у меня начинает складываться ответ на вопрос «как писать код с ИИ».
Я вчера спросил у вас, как вы это делаете на практике. И если убрать названия тулов, то картина на удивление цельная.
Главная мысль:
ИИ не заменяет разработку. Он делает быстрее цикл: ресерч -> план -> реализация -> ревью -> доработки.
То есть выигрывают не те, кто «дал царь промпт и пошёл пить кофе», а те, кто встроил ИИ в нормальный инженерный процесс.
Основные инсайты, которые я бы выделил.
1. Сначала не код, а понимание
Люди сначала просят ИИ исследовать кодовую базу, тикет, логи, репозиторий, иногда даже приложение через playwright.
Всё это для того чтобы ИИ он сразу не полез править файлы, а чтобы собрать контекст и помочь сложить картину в голове.
Это, кстати, важный паттерн.
Многих кто входит в тему разработки ИИ откровенно раздражает, что агент сразу бежит что-то менять. В ответ появился почти универсальный закон:
сначала план, потом код.
2. Лучший режим работы — пошаговая стратегия
Типовой цикл у большинства выглядит примерно так:
— дать задачу
— попросить исследовать кодовую базу
— собрать верхнеуровневый план
— провалидировать его своей головой
— заставить расписать какие-то куски подробнее, ещё раз провалидировать, этот цикл может быть несколько раз
— только потом реализовать
— потом отдельно натравить на это ревьюера
— потом ещё раз посмотреть самому
То есть ИИ хорошо работает не как «магический программист», а как очень быстрый джун/мидл/команда мидлов, которых ты всё равно контролируешь.
3. Артефакты решают
Многие пишут, что складывают контекст в .md-файлы: описание тикета, контекст, ожидаемое решение, план, документацию по итогам.
Условно: у вас не просто чатик с агентом, а внешняя память.
Часто встречаются такие штуки:
— CLAUDE.md / AGENTS.md как онбординг для агента
— вложенные AGENTS.md по подпапкам (backend, frontend, infra)
— skills / commands под типовые режимы работы (/new-feature, /fix-bug, /do-review)
— rules / workspace / project-specific skills
По сути, люди постепенно цифровизируют инженерную экспертизу команды: логи задач, как думать, как проверять, как запускать тесты, как оформлять изменения.
4. Большие задачи почти никто не делает одним заходом
Для крупных задач подход тоже довольно единый:
— сначала совместное планирование
— потом декомпозиция на маленькие задачи
— потом прогон по одной (см уже п.1)
— потом отдельный цикл ревью и тестов
Это, кстати, очень похоже на нормальную разработку без ИИ.
Просто теперь часть ролей можно отдать агентам: архитектор, QA, ревьюер, техпис, иногда даже «тимлид», который раскладывает работу.
5. ИИ уже используют не только для кода
Из ответов видно, что код — это только часть истории.
Ему отдают ещё и:
— написание архитектурной спеки
— продуктовую спецификацию
— тест-кейсы
— автотесты
— документацию
— ревью
— ручные тесты там, где нет автоматики
То есть реальный сценарий — это не «напиши мне функцию», а скорее «помоги прогнать весь delivery-цикл быстрее».
6. Человек никуда не делся
Во всех хороших примерах человек остаётся в нескольких критических местах:
— подтверждает план
— смотрит диффы
— ревьюит результат
— ограничивает число итераций
— эскалирует на себя, если агент застрял
И это, кажется, очень здравая модель.
Не «я не пишу код, за меня пишет ИИ», а «я управляю системой, в которой ИИ делает много рутины».
Отдельно понравилась мысль:
лайфхаки живут две недели, а нормальный процесс живёт дольше.
И, кажется, это вообще главный вывод.
Не так важно, Claude это, Cursor, Codex, CLI, субагенты, skills, commands или что-то ещё.
Рабочая схема почти везде одна и та же:
ресерч -> план -> реализация -> ревью -> доработки
То есть писать код с ИИ — это не про «наконец-то можно не думать».
Это про то, что думать всё ещё надо, но теперь можно сильно быстрее проходить инженерный delivery цикл.
И, честно говоря, именно это выглядит самым реалистичным сценарием 2026 года.
