За последний год я перепробовал много всего: разные IDE, агентные надстройки, обвязки поверх Claude, эксперименты с автоматической генерацией фич, ревью, ветками, планированием. В какой-то момент я понял простую вещь: проблема не в том, что AI “плохо пишет код”, а в том, что большинство людей пытаются использовать его без нормального процесса.
Сейчас у меня есть система, которая работает заметно стабильнее всего, что я тестировал до этого. Она не магическая, не идеальная, но она дает главное: предсказуемость, скорость и меньше хаоса.
Вот как я работаю сейчас.
1. Сначала PRD, а не код
Первое, с чего я начинаю почти любой проект, — это не генерация кода, а продуктовая логика.
Для этого я использую Gemini: закидываю туда аудио от клиента, транскрибированный бриф, заметки, голосовые мысли — все, что может помочь собрать картину задачи. Дальше прошу оформить это как профессиональный product requirements document: без технической реализации, без преждевременной архитектуры, только продуктовая часть.
На этом этапе мне важно ответить на вопросы:
- что именно мы строим;
- для кого это делаем;
- какой пользовательский сценарий является основным;
- что пользователь нажимает;
- что он видит;
- какое действие приводит к какому результату;
- где есть узкие места, пограничные сценарии и неочевидные ветки.
Я давно пришел к выводу, что архитектура всегда важнее первой строчки кода. Если логика продукта не собрана, AI может очень быстро произвести много “правдоподобного” мусора. Внешне это будет выглядеть как прогресс, но по факту ты просто ускоряешь движение не туда.
2. Потом брейншторминг: вытаскиваю то, что сам не додумал
Когда продуктовая часть собрана, я переношу ее в рабочую среду и запускаю этап брейншторминга.
Здесь мне нравится подход, где AI не просто исполняет команду, а начинает задавать вопросы. Именно на этом этапе вылезают вещи, которые ты как разработчик или фаундер легко пропускаешь:
- нестыковки в сценариях;
- дыры в ролях и правах доступа;
- незаметные edge cases;
- конфликтующие требования;
- слабые места в UX;
- проблемы с данными и сущностями.
Мне нравится использовать такой режим как интеллектуальный препродакшн. Хороший AI-брейншторм не заменяет мышление, а наоборот — заставляет тебя мыслить точнее.
Если проект требует более сильного визуального уровня, подключаю Antygravity. Если задача проще, быстрее или больше про локальные правки, прототипирование и небольшие сборки — использую qoder.com. По сути, я не пытаюсь найти “один идеальный инструмент”. Я использую конкретный инструмент под конкретную фазу задачи.
Но при этом мой основной стек почти не меняется: React / Next.js + Postgres. Я намеренно не прыгаю между десятью экосистемами. Когда стек стабилен, AI тоже работает качественнее, потому что меньше хаоса в решениях и меньше случайных отклонений.
3. Планирование важнее автогенерации
Дальше начинается этап, на котором многие как раз совершают главную ошибку: слишком рано переходят в режим “сгенерируй мне приложение”.
Я так не делаю.
Сначала AI формирует план: этапы, зависимости, порядок реализации, состав фич, сущности, API-контракты, важные ограничения. И только после этого начинается имплементация.
В идеале процесс выглядит так:
- разбиваем работу на этапы;
- подтверждаем, что именно делаем в этом цикле;
- создаем отдельные ветки под блоки;
- реализуем фичи изолированно;
- прогоняем тесты и базовые проверки;
- объединяем результат обратно в общий проект.
На бумаге это звучит очень красиво. На практике, конечно, AI все равно регулярно что-то пропускает. Из условных 30 функций он может качественно собрать 15, еще 7 сделать наполовину, а про остальные забыть.
И это нормально.
Ключевая ошибка здесь — ждать от AI линейной, полностью завершенной реализации с первого прохода. Я к нему так не отношусь. Для меня это не “магический разработчик”, а очень быстрый исполнитель внутри правильно выстроенного цикла.
4. Разработка идет слоями, а не одним махом
Следующий важный принцип: я не жду, что проект соберется за один запуск.
Я работаю циклами.
После первой имплементации я сравниваю результат с исходным планом и задаю прямой вопрос:
“У нас был план. Что не сделано?”
Это один из самых полезных приемов вообще. Потому что AI умеет не только генерировать, но и находить собственные пропуски, если правильно поставить задачу.
Дальше снова идет цикл:
- поиск незакрытых пунктов;
- перепланирование;
- реализация;
- проверка;
- следующий проход.
Обычно в рамках одного рабочего дня я делаю 3–4 таких круга. В результате проект собирается не “целиком сразу”, а по слоям: сначала крупные блоки, потом средние, потом мелкие зазоры между ними.
Именно такой подход у меня дает лучшее соотношение скорости и качества.
5. Отдельный этап — жесткое код-ревью
Когда основа готова, я обязательно прогоняю проект через отдельный этап ревью.
Для этого я люблю использовать сильные модели в режиме критического анализа. Не в режиме “помоги написать красиво”, а именно в режиме придирчивого ревьюера, который ищет:
- усложнение без причины;
- хрупкие места;
- несогласованные интерфейсы;
- проблемы в архитектуре;
- плохую читаемость;
- потенциальные баги;
- избыточные абстракции;
- сомнительные решения по данным и состоянию.
Такой режим полезен, потому что после нескольких циклов генерации проект почти всегда начинает обрастать лишним. AI очень любит переусложнять, особенно когда контекст уже большой.
Поэтому я использую ревью не как финальную “галочку”, а как механизм возврата к простоте.
Иногда модель предлагает умные вещи. Иногда — типичное “горе от ума”, где решение становится хуже, чем было. Поэтому здесь главное правило простое: ничему не верить на слово, все перепроверять руками.
6. Обязательно прогоняю тесты через браузер
После ревью я не ограничиваюсь чтением кода. Обязательно гоняю smoke-тесты через браузер.
Это важный момент, который многие недооценивают: код может выглядеть нормально, тесты могут быть зелеными, но реальный пользовательский сценарий все равно ломается.
Поэтому я люблю быстрые браузерные проверки:
- открыть страницу;
- пройти основные маршруты;
- прожать ключевые кнопки;
- проверить формы;
- убедиться, что состояние обновляется как надо;
- проверить, не развалился ли интерфейс после правок.
Для меня это последний фильтр между “вроде работает” и “действительно можно отдавать дальше”.
7. Почему простота выигрывает почти всегда
Самый важный вывод, к которому я пришел за все это время: с AI побеждает не самый сложный процесс, а самый устойчивый.
Чем сложнее схема, тем быстрее она начинает ломаться:
- слишком много инструментов;
- слишком много агентов;
- слишком много магии;
- слишком много автопринятия решений без контроля;
- слишком много надежды на то, что “оно само додумается”.
Не додумается.
Рабочая система с AI — это не про “полностью убрать себя из разработки”. Это про то, чтобы оставить за собой роль архитектора, редактора и принимающего решения, а рутину, черновую сборку, декомпозицию и часть контроля отдать машине.
Именно поэтому я почти всегда выбираю максимально простое решение. Простота в AI-разработке — это не компромисс. Это форма инженерной устойчивости.
8. Где здесь место skills и no-code-подходу
Отдельно скажу про skills, потому что это сейчас одна из самых недооцененных тем.
Отдельно я бы выделил skills. Это штука, которую многие пока недооценивают. По сути, это не просто набор промптов, а готовые инструкции под типовые задачи: брейншторминг, дебаг, валидация, планирование, архитектура, продуктовая декомпозиция, даже маркетинговые или лендинговые сценарии. У Antigravity Skills как раз такая модель: installable-библиотека skills для разных AI-ассистентов и рабочих сценариев, где есть bundles, workflows и готовые стартовые наборы. Это особенно полезно на стыке разработки и no-code, когда тебе нужно не “написать код любой ценой”, а быстро собрать работающий слой продукта: MVP, лендинг, админку, прототип или интерфейс под тест гипотезы
Простой пример: если у тебя есть готовые skills на брейншторминг, UX-декомпозицию, генерацию лендингов, систематический дебаг, валидацию и планирование — ты можешь намного быстрее собирать проекты.
9. Мой итог
В итоге мой главный вывод очень простой: AI хорошо работает не там, где ты пытаешься убрать программиста из процесса, а там, где ты правильно выстраиваешь сам процесс.
То есть моя роль как разработчика никуда не исчезает. Я все так же отвечаю за архитектуру, решения, приоритеты, качество и простоту. Просто теперь у меня есть очень быстрый инструмент, который помогает думать, собирать, проверять и ускорять рутину.
И да — из всего, что я пробовал, именно этот подход пока дает мне лучший баланс скорости, качества и устойчивости.
Еще больше информации в нашем телеграмм канале. Шаблоны, практические советы, обучение.