Меня часто спрашивают, как я подхожу к разработке с AI, чтобы в проекте было меньше багов, меньше хаоса и меньше ощущения, что все держится на честном слове.
Я перепробовал много разных подходов: агентные IDE, обвязки поверх Claude, автогенерацию кода, сложные цепочки инструментов. В какой-то момент понял: чем больше магии, тем чаще все начинает сыпаться.
В итоге я пришел к простой системе, которая у меня реально работает.
Сначала я не пишу код вообще. Я собираю продуктовую часть: аудио от клиента, бриф, свои заметки, сырой поток мыслей — и прогоняю это через Gemini, чтобы получить нормальный PRD. Без технички, без premature optimization, без попытки сразу строить архитектуру. Мне важно сначала понять, что именно мы делаем как продукт: кто пользователь, что он видит, куда нажимает, что должно происходить в каждом сценарии.
После этого запускаю брейншторминг. Это один из самых недооцененных этапов. Хороший AI полезен не только тогда, когда пишет код, а тогда, когда начинает задавать неудобные вопросы. Именно здесь вылезают слабые места, неучтенные роли, забытые состояния, дыры в UX и логические конфликты. Для визуально сильных задач я могу подключать Antygravity, для быстрых правок или более простых сборок — qoder.com. Но основной стек почти не меняю: React / Next.js + Postgres. Я знаю этот стек хорошо и не хочу множить хаос без причины.
Дальше идет планирование. И это принципиально. Я не прошу AI “сделать приложение”. Я прошу разбить работу на этапы, определить зависимости, зафиксировать состав фич, потом отдельно пройтись по реализации. Обычно это работа через ветки, отдельные блоки, постепенную сборку и возврат к плану. С первого раза AI почти никогда не делает все как надо. Это нормально. Если из 30 функций он качественно сделал 15 — это уже рабочий черновик, а не провал.
Потом начинается то, что я считаю настоящей разработкой с AI: цикл доработок. Я возвращаюсь к плану и задаю прямой вопрос: что не сделано? Где расхождения? Что пропущено? После этого идет новый круг планирования и имплементации. За день можно сделать несколько таких циклов и собрать проект слоями: сначала каркас, потом крупные блоки, потом средние, потом шлифовка.
Когда база готова, я обязательно запускаю жесткое код-ревью. Здесь мне не нужен “дружелюбный помощник”. Мне нужен вредный, придирчивый ревьюер, который покажет, где архитектура стала хрупкой, где код переусложнен, где AI наплодил абстракций ради абстракций, а где решение выглядит умно, но по сути хуже простого. Такие проверки очень полезны, но их всегда нужно фильтровать, потому что сильные модели любят уходить в переусложнение.
После этого — обязательные smoke-тесты через браузер. Не только тесты, не только чтение кода, а реальное прожатие интерфейса. Потому что приложение может быть “идеальным” на бумаге и все равно ломаться в реальном сценарии пользователя.
Отдельно я бы выделил skills. Это штука, которую многие пока недооценивают. По сути, это не просто набор промптов, а готовые инструкции под типовые задачи: брейншторминг, дебаг, валидация, планирование, архитектура, продуктовая декомпозиция, даже маркетинговые или лендинговые сценарии. У Antigravity Skills как раз такая модель: installable-библиотека skills для разных AI-ассистентов и рабочих сценариев, где есть bundles, workflows и готовые стартовые наборы. Это особенно полезно на стыке разработки и no-code, когда тебе нужно не “написать код любой ценой”, а быстро собрать работающий слой продукта: MVP, лендинг, админку, прототип или интерфейс под тест гипотезы.
В итоге мой главный вывод очень простой: AI хорошо работает не там, где ты пытаешься убрать программиста из процесса, а там, где ты правильно выстраиваешь сам процесс.
То есть моя роль как разработчика никуда не исчезает. Я все так же отвечаю за архитектуру, решения, приоритеты, качество и простоту. Просто теперь у меня есть очень быстрый инструмент, который помогает думать, собирать, проверять и ускорять рутину.
И да — из всего, что я пробовал, именно этот подход пока дает мне лучший баланс скорости, качества и устойчивости.
