Мой процесс разработки с помощью ИИ

Маттео Барберо описывает структурированный процесс разработки с помощью ИИ, построенный вокруг одного принципа: настоящая работа происходит до того, как написан хоть какой-то код. ИИ ускоряет производство; за проверку отвечает человек.

Проблема

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

Дилемма: как получить скорость ИИ, не потеряв ясность и поддерживаемость?

Ответ: думать до реализации

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

Этот рабочий процесс заставляет продумать всё до появления кода, а затем использует ИИ для проверки этих мыслей на прочность, а не для отказа от них.

Семь шагов

1. Свободный план (Free-form plan) - опишите проблему, ограничения и неопределённости простым языком. Никакой структуры не требуется. Это личные размышления, а не отчётный документ. Качество на этом этапе определяет качество всего, что идёт дальше.

2. PRD через write-a-prd - навык ИИ исследует кодовую базу, а затем методично расспрашивает вас. "Как это работает, когда пользователь не авторизован?", "Что произойдёт, если эта операция выполнится частично?" Необходимость отвечать на конкретные вопросы показывает, где вы махнули рукой на детали. На выходе: структурированный PRD с описанием проблемы, пользовательскими историями, решениями по реализации и списком того, что остаётся за рамками задачи.

3. Issue через prd-to-issues - PRD превращается в issue по вертикальным срезам (tracer bullets сквозь все слои, а не горизонтальные архитектурные срезы). Каждое issue классифицируется:

• AFK - ИИ может реализовать и смерджить без участия человека
• HITL - требует решения человека в процессе реализации

Issue содержат описание сквозного поведения, шаги проверки, критерии приёмки Given/When/Then, блокирующие факторы и ссылки обратно на пользовательские истории.

4. Задачи через issues-to-tasks - каждое issue разбивается на упорядоченные задачи, рассчитанные ровно на одну сессию с ИИ. Ограничение намеренное: если задачу нельзя завершить за одну сессию, она слишком велика. В задачах указываются файлы для изменения, используемые шаблоны и то, как выглядит готовый результат. Описывается намерение, а не реализация.

5. Передача в реализацию (Implementation handoff) - описание каждой задачи представляет собой самодостаточный промпт. Открываем чистую сессию, вставляем задачу + родительское issue. Чистый контекст для каждой задачи сделан намеренно: длинные сессии приводят к уходу в сторону, поскольку модель начинает принимать решения на основе накопленного контекста, а не требований задачи. Для задач с HITL - останавливаемся, принимаем решение, фиксируем его в файле задачи и продолжаем.

6. Ревью кода через code-review - структурированное ревью в шесть проходов: логические ошибки, порядок операций, плохие практики, безопасность, магические значения, согласованность шаблонов. Порядок операций заслуживает отдельного внимания - ИИ склонен выдавать код, который делает правильные вещи в неправильной последовательности (отправка уведомления до коммита, логирование после действия, мутация до валидации).

7. Финальный аудит через final-audit - сквозной анализ после того, как функциональность полностью готова. Не поиск отдельных багов (их отлавливают в каждом PR), а системные проблемы: несогласованность модулей, некорректно воспроизведённые шаблоны, предположения о безопасности, которые ломаются на всей совокупной площади системы.

Принципы проектирования

У каждого шага одна и та же структура: ИИ генерирует, человек с полным контекстом проверяет, и только после этого результат фиксируется. Этот процесс гарантирует, что вам всегда есть с чем сверяться: PRD для issue, issue для задач, критерии приёмки для кода.

Подход разменивает время на подготовку на глубину понимания. Он окупается только в том случае, если вы считаете, что время на обдумывание до написания кода обходится дешевле, чем отладка после.

Чем это не является

Это не даёт быстрого старта - составление PRD и планирование требуют реального времени. Это не замена собственному суждению - ИИ будет предлагать разумные вещи, которые не подойдут именно в вашей ситуации. Контрольные точки ревью существуют потому, что результаты работы ИИ требуют проверки на соответствие командным соглашениям, поведению пользователей и скрытой сложности кодовой базы.

Связь с другими подходами

Это дисциплинированная противоположность чистому vibe coding'у. У этого подхода общая ДНК с дисциплинированным переписыванием Маганти - в обоих случаях ИИ рассматривается как ускоритель реализации, а не замена мышлению. Классификация AFK/HITL напрямую сопоставляется с паттернами human-in-the-loop. Принцип чистого контекста на каждую задачу отражает грамотный context-engineering - он не даёт накопленным допущениям искажать принимаемые решения.

Навыки доступны на github.com/maiobarbero/my-ai-workflow и адаптированы из фреймворка Мэтта Покока (pocock-software-fundamentals).