На картеСобрать настоящий софт, не понимая ни строчки кода, уже возможно, если подойти к этому как к инженерной дисциплине. Понадобятся ясное видение результата, внимательный разбор похожих инструментов и большая коллекция интерфейсных референсов. Дальше всё это превращается в план и именно от качества плана зависит — выигрываете вы или проигрываете.
Рабочая последовательность выглядит так:
- Соберите план с помощью плагина вроде Compound Engineering или приёма обратного промптинга (reverse prompting) Мэтта Покока: модель сама вытянет из вас требования вопросами.
- Покажите готовый план двум моделям и переписывайте его, пока он не станет цельным.
- Привяжите сборку к результату через функцию /goal.
- Дальше пусть работает фронтирная (самая сильная из доступных) модель-оркестратор: она режет работу на тикеты и ведёт их по одному, а слишком крупный тикет получает собственный маленький план. Так ни одна задача не стартует из расплывчатой формулировки.
- Разные части субагенты собирают параллельно в изолированных копиях репозитория (worktrees) и не мешают друг другу.
- Ваша роль во всём этом — оставаться в цикле: открывать приложение по ходу сборки, отправлять скриншоты и показывать, что именно не так.
Код из этой схемы никуда не делся: его по-прежнему кто-то пишет, просто теперь это агенты. Человек отвечает за другую часть работы: за качество плана и за глаза, которые смотрят на результат. Начните с этих двух вещей — их как раз нельзя делегировать.
Следующий шаг
Четыре принципа делегирования субагентам — как оркестратору и субагенту договориться о результате: проверяемый контракт, маршрутизация модели и минимум лишних прав.
Такая схема подходит не только для личных проектов: по ней можно собрать внутренний инструмент команды или первую версию своего продукта.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
