Как работать с Claude Code, Antigravity и Codex в 2026: база вайбкодинга

[WhiteBehemoth]

Немного поработав с ко-пилотом, я сделал простой вывод - с ним также как со стажером - дай конкретное ТЗ, убедись, что тебя поняли - и получи результат, близкий к ожидаемому.

[Dandy_the_crocodile]

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

[globin_write]

На самом деле, заметил, что навык управления командой существенно повысился с того момента, как начал активно использовать агенты. Так тренажёр получается)

[fUS1ONd]

Это уже не вайбкодинг, а делегирование процесса разработки ии-агенту по упрощённой итеративно-инкрементальной модели. Сильно круче, качественнее и затратнее по токенам

[Coldless]

Все обсуждают - это кто?

[VitalyOborin]

Весь план проекта в начале вы не нарисуете потому что скорее всего вы сами не знаете, что хотите и как оно должно работать, если у вас проект чуть сложнее лендинга на 3 экрана.

Я для себя построил разработку с ИИ агентами как архитектор решения. Вот мои шаги:

1. Описать о чем проект максимально подробно. Я используй Obsidian, в нем завожу отдельную папку проекта, он создает md файлы на диске - их потом можно подключить в проект. ИИ модели очень хорошо работают с markdown. Чтобы сделать описание проекта лучше сразу идти в ChatGPT и другие чатики, обсуждать с ними что вы хотите. Они не сделают за вас описание, но подкинут деталей, идей, развития. В ChatGPT удобно завести отдельный проект и прикрепить в него сопутствующие файлы (описания, спецификации, документацию и т.д.). Всю важную итоговую информацию сохраняю в Obsidian как концепция.

2. Далее в том же ChatGPT можно проработать этапы реализации верхнеуровнево. Это по сути эпики. Каждый этап должен привносить в проект завершенную ценность - продуктовый подход. Это может быть MVP-0, MVP-1... Это может быть сначала killer фича, потом обвязка, как угодно. Всю информацию сохраняю в Obsidian как этапы реализации. На этом этапе в принципе уже понятны большие компоненты системы, микросервисы, приложения.

3. Далее берем MVP-0 как эпик и опять же в ChatGPT или подобных чатиках и предлагаем подобрать оптимальный стек и архитектуру решения. Чистая Архитектура + DDD - хорошо, но не универсально, архитектура и стек должны выбираться исходя из потребностей, а не "я это знаю и умею". Для каждого сервиса или приложения надо зафиксировать архитектурное решение - это можно в локальных AGENTS.md, правилах или в том же Obsidian описать. Архитектура описывается хотя бы названием (дорогая модель разберется), но лучше в виде ограничений и правил (домен, слои, зависимости, правила и т.д.). Стек тоже четко, с версиями, а лучше с детализацией до конкретных пакетов.

4. Имея один эпик в виде MVP-0, определенную ранее архитектуру и стек, делаем самое главное - предлагаем ChatGPT определить этапы реализации, при этом сразу указываем, что каждый этап должен быть логичным, завершенным, приносить ценность и не ломать функциональность, а длительность реализации этапа senior разработчиком должна быть 1-3 дня. Вы получите 10-15 шагов с четким описанием что на них надо сделать. Фиксируем как этапы реализации в Obsidian.

5. И вот только здесь идем в IDE, я пользуюсь Cursor. И скармливаем ему этап за этапом. Человеческий объем работы на 1-3 дня оптимально подходит под контекст работы большинства моделей. Чем более творческая и непонятная задача, тем дороже выбираем модель, Opus самый дорогой, но он за вас многое додумает.

6. Обычно после 1-3 реализованных этапов может потребоваться актуализация плана и последующих этапов реализации. Что-то поменялось, где-то отошли от первоначального плана - надо актуализировать дальнейшие шаги в контексте совершенной работы. Также после значимых изменений я всегда провожу рефакторинг реализации, это тоже где-то каждые 1-3 этапа. Это делать обязательно, пока в истории актуальный контекст, изменения в последних коммитах, ошибки на поверхности и на этих ошибках еще не построен дальнейший функционал. Сделать рефакторинг с агентом просто - "дай оценку текущему решению с точки зрения архитектуры и лучших практик". Обычно модель дает оценки по различным критериям и подсвечивает что лучше исправить.

В итоге вы идете по своим этапам разработки, регулярно делаете рефаторинг, оцениваете реализацию, это обычная петля разработки, она не прямолинейна. Важно сохранять маленький контекст приложений, микросервисы - идеально, выделенные сервисы в виде модулей в монолите - норм. Если модель теряется в контексте, значит архитектура приложения пошла не туда, размыты границы, нарушены зависимости, идем в рефакторинг. Всегда надо указывать модели контекст - директория, файлы, примеры, правила, не надеяться, что сама додумает. Сегодня со знанием архитектуры приложений можно пилить что угодно на чем угодно и в кратчайшие сроки.

[Kohler]

Поздравляю, автор описал идею spec-kit от github