Ещё пару лет назад идея написать десятки тысяч строк рабочего кода с помощью нейросетей звучала как шутка. Сегодня это начинает становиться реальностью. Разработчик Ставрос описал свой рабочий процесс, где LLM-модели выступают полноценной командой инженеров — архитектором, разработчиком и ревьюерами.
Самое интересное здесь даже не то, что ИИ пишет код. Важнее другое: роль человека в разработке меняется. Программист постепенно превращается из «того, кто пишет строки» в того, кто проектирует систему и управляет процессом разработки.
И, честно говоря, это выглядит как логичная эволюция профессии.
Когда код пишет ИИ, а человек проектирует
Ставрос начинает с неожиданного признания: оказывается, ему нравилось не столько программирование, сколько создание вещей.
Когда LLM стали достаточно хороши в коде, он понял, что может сосредоточиться именно на этом — на создании продукта.
Результат оказался неожиданным:
🧠 проекты на десятки тысяч строк кода
🧠 дефектов меньше, чем при ручном программировании
🧠 изменения остаются поддерживаемыми даже спустя недели разработки
Это довольно сильное утверждение. Но оно логично, если понять, как устроен его процесс работы.
Главная идея: ИИ не работает один. Он работает как команда.
Архитектура команды ИИ
Ставрос использует несколько моделей одновременно. Каждая играет свою роль.
⚙️ архитектор
Самая сильная модель (например Claude Opus). Она обсуждает с человеком архитектуру, ограничения и решения.
⚙️ разработчик
Более дешёвая и быстрая модель (например Claude Sonnet). Она просто реализует задачи.
⚙️ ревьюеры
Другие модели (например Codex или Gemini), которые проверяют код.
Получается настоящая инженерная команда, только вместо людей — LLM.
И это работает по простой причине: разные модели думают по-разному.
Одна может быть педантичной.
Другая — креативной.
Третья — хорошо ловить ошибки.
Ставрос сравнивает это с обычным код-ревью: вторая пара глаз всегда улучшает результат.
Как выглядит реальный процесс разработки
Рабочий процесс делится на несколько этапов.
Архитектура
Человек общается с моделью-архитектором.
Они обсуждают:
🧩 цель фичи
🧩 ограничения системы
🧩 возможные архитектурные решения
🧩 выбор оптимального решения с учётом ограничений
Иногда это занимает до получаса диалога.
На выходе получается подробный план реализации.
Например:
⚙️ изменить конкретные файлы
⚙️ добавить функции
⚙️ изменить обработку ошибок
⚙️ обновить конфигурацию
Важно: архитектор не приступает к реализации, пока человек явно не подтвердит план словом «одобрено».
Это защита от «переусердствующих» моделей.
Реализация
Дальше работу получает модель-разработчик.
Её задача максимально простая:
⚙️ следовать плану
⚙️ реализовать изменения
⚙️ сформировать diff — список изменений в коде
Она не принимает архитектурных решений.
Это ключевой момент: архитектура уже определена человеком.
Ревью
После реализации код отправляется на проверку другим моделям.
Каждый ревьюер:
🔍 читает план
🔍 анализирует diff
🔍 пишет замечания
Затем разработчик либо вносит исправления, либо передаёт спорный момент архитектору.
Это почти точная копия процесса в обычных компаниях.
Реальный пример: добавление email-поддержки
Ставрос показывает реальную сессию разработки.
Задача: добавить поддержку email в бота.
LLM-архитектор начинает с анализа существующей системы и задаёт вопросы:
📩 как будут приходить письма
📩 как отправлять ответы
📩 нужно ли поддерживать цепочки переписки (email threading)
📩 как обрабатывать вложения
Человек отвечает, уточняет и корректирует архитектуру.
Например, решение выглядит так:
⚙️ входящие письма через webhook
⚙️ SMTP для отправки
⚙️ MIME-парсинг через mailparser
⚙️ вложения сохраняются как файлы
LLM предлагает конкретную архитектуру:
📂 src/email.ts — webhook и парсинг писем
📂 src/email-api.ts — SMTP отправка
📂 agent.ts — новый инструмент send_email
После утверждения план превращается в задачи.
Дальше разработчик реализует всё автоматически.
Где человек всё ещё нужен
Несмотря на впечатляющий результат, автор подчёркивает одну важную вещь.
LLM хорошо работают только там, где человек понимает технологию.
Если разработчик не знает стек, происходит типичный сценарий:
❌ модель делает плохое архитектурное решение
❌ следующее изменение строится поверх него
❌ система превращается в хаос
Это одна из главных причин провалов при работе с ИИ.
Поэтому главный навык разработчика смещается:
📐 системное проектирование
📐 понимание архитектуры
📐 постановка задач
А не написание синтаксиса.
Новая профессия: дирижёр разработки
Читая этот материал, я поймал себя на мысли: профессия программиста начинает напоминать дирижёра оркестра.
Он не играет на каждом инструменте.
Но именно он:
🎼 задаёт структуру
🎼 управляет исполнителями
🎼 слышит ошибки
🎼 корректирует результат
ИИ становится инструментом исполнения.
Человек — архитектором системы.
Почему этот подход действительно работает
Есть несколько причин, почему такой подход к работе даёт хорошие результаты.
⚙️ разные модели дают независимое мнение
⚙️ архитектура фиксируется до начала кодинга
⚙️ ревью происходит автоматически
⚙️ разработчик не тратит время на синтаксис
Это почти идеальный CI/CD-pipeline для кода.
По сути, мы получаем мини-команду разработчиков внутри одной IDE.
Куда всё это движется
Сам Ставрос делает интересное наблюдение.
Раньше разработчик проверял:
🔎 каждую строку кода
Потом:
🔎 каждую функцию
Теперь:
🔎 архитектуру системы
Следующий шаг вполне очевиден.
Через несколько лет человек может контролировать только продуктовые решения, а архитектуру будут проектировать сами модели.
Итог
История Ставроса показывает важный момент.
ИИ не заменяет программистов.
Он меняет их роль.
Разработчик будущего — это не человек, печатающий код.
Это человек, который:
🧠 формулирует задачи
🧠 проектирует систему
🧠 управляет командой ИИ
И если честно, звучит это даже интереснее, чем писать очередной CRUD-сервис.