Как я пишу программное обеспечение с помощью LLM: практический мультимодельный workflow

10 марта 2026 года Ставрос опубликовал, возможно, самое честное и практичное руководство по разработке ПО с помощью больших языковых моделей. Не хайповая статья. Реальный workflow, проверенный на нескольких реализованных проектах.

Отправная точка: делать вещи, а не программировать

Ставрос проводит различие, которое переосмысливает весь разговор. Ему не интересно программирование ради самого себя. Ему интересно делать вещи. LLM изменили уравнение, приблизив программирование к прямому конструированию.

Он использовал этот подход для создания и поддержки нескольких проектов: личный ассистент Stavrobot, устройство голосовых заметок, проект арт-часов и симуляция маленького городка Pine Town.

Трёхмодельная архитектура

1. Модель планирования (Архитектор)

Первая модель выступает в роли архитектора. Ставрос тратит до 30 минут на разговор с этой моделью до написания кода. Ключевая инструкция: не начинай реализацию, пока я явно не одобрю план.

Это ограничение критически важно. LLM стремятся генерировать код. Без жёсткого барьера разговор о планировании скатывается в реализацию до того, как дизайн утверждён.

2. Модель разработки (Реализатор)

После одобрения плана более дешёвая модель берёт на себя реализацию. Эта модель имеет ограниченные полномочия — выполняет план, а не переделывает его.

3. Модели ревью (Несколько проверяющих)

После реализации Ставрос прогоняет код через несколько моделей-ревьюеров. Использует Codex, Gemini и Opus. Разнообразие важно — разные модели ловят разные проблемы.

Человек пишет инструкции агента

Ставрос пишет инструкции агента вручную. Не просит LLM сгенерировать собственный файл навыков. Человек определяет ограничения; модели работают в этих рамках.

Где это хорошо работает

Мультимодельный workflow лучше всего работает, когда Ставрос уже понимает технологический стек. В этом контексте LLM выступают как мультипликатор продуктивности.

Где это ломается

На незнакомой территории workflow работает значительно хуже. Плохие решения накапливаются. Технический долг от непонятой архитектуры — самый дорогой в исправлении.

Практические выводы

Отделяйте планирование от реализации. Используйте разные модели для разных ролей. Диверсифицируйте ревьюеров. Пишите собственные инструкции. Оставайтесь на знакомой территории. Следите за кумулятивными ошибками.