Эволюция разработки ПО с ИИ
За последние три месяца я не написал ни одной строчки кода, но сделал функционал намного больше, чем за последние несколько лет. Это стало возможным благодаря системе, которую покажу на практике в этом видео. Речь не про вайп-кодинг — это предыдущая фаза разработки с помощью ИИ, которая осталась в прошлом. Вайп-кодинг хорошо подходит для прототипов и маленьких приложений, но не подходит для серьезной инженерной дисциплины с большим количеством бизнес-требований.
Для тех, кто со мной не знаком: меня Владилен Минин, я больше 13 лет в разработке, начинал как фронтенд-разработчик, 7 лет занимаюсь YouTube. Благодаря технологиям ИИ я с диким кайфом возвращаюсь в разработку — теперь не нужно писать маленькие строчки кода, я занимаюсь именно проектированием системы.
SDLC — Software Developer Life Cycle
Есть схема SDLC (Software Developer Life Cycle), которая описывает 6 этапов создания продукта (инженерного, ПО, приложения).
Как работало до ИИ
- Requirements — сбор требований проекта. Обычно работает product manager, бизнес-аналитик, выясняют требования у заказчика.
- Design — дизайн системы (не UI/UX). Работает разработчик, архитектор: выбор технического стека, архитектурных решений.
- Implementation — фаза разработки, когда разработчик пишет код.
- Testing (QA) — специалист проверяет написанное. Есть циклы перекидывания задачи: тестировщик нашел баг → перекинул разработчику.
- Deployment — инженер DevOps заливает проект.
- Maintenance — поддержка проекта, внесение правок.
Работа Software Developer — это не только написание кода (программист). Код — всего лишь одна из шести фаз. Настоящий разработчик должен понимать или поддерживать все шесть фаз.
Фаза вайп-кодинга (2024–2025)
Терминологию вайп-кодинг придумал Андрей Карпатый по фану, как мем, в марте 2025 года. Это подход, когда создаешь ПО и пишешь код с помощью ИИ. В диаграмме SDLC вайп-кодинг заменяет фазу implementation: ИИ пишет код и частично тестирует его (например, внедряет TDD-практики). Остальные этапы (requirements, design, deployment, maintenance) выполнял человек. Разработчик переходил в роль архитектора.
Фаза агентской разработки (2026 год)
Сейчас мы находимся на фазе полноценной агентской разработки, проектирования агентских систем — agent orchestration. Существует много проектов, фреймворков, инструментов, парадигм для этого. В видео рассматриваются конкретно GetShitDone (GSD) и Superpowers — я использую их в своей практике для создания B2B продуктов, в консалтинге и собственных приложениях.
При агентской оркестрации все фазы SDLC закрываются с помощью агентов ИИ. Человек выполняет роль оператора, который направляет разработку. Полный цикл создания ПО теперь делается с помощью ИИ, если правильно его применять.
Проблемы вайп-кодинга для больших проектов
При создании больших приложений с помощью вайп-кодинга: первый промт работает отлично, но когда нужно поддерживать проект, архитектуры становится больше, файлов больше — начинается каша, превращающая код в неподдерживаемый кусок программы. При агентской оркестрации с помощью фреймворков эта проблема решается. Например, код терял контекст — теперь он проработан в контекст. Superpowers и GSD создают долгосрочную память и четкий pipeline, которым нейронка...
Агентская оркестрация и инструменты разработки
На этапе вайп-кодинга было невозможно поддерживать большие проекты: при первом промте нейронки (например, Codex) справляются отлично, но когда проект разрастается (больше архитектуры, больше файлов), начинается «каша», превращающая код в неподдерживаемый кусок программы.
Агентская оркестрация с помощью фреймворков решает эту проблему. Например, Codex теперь проработан в контекст. Инструменты вроде superpowers или GSD создают долгосрочную память и четкий pipeline, по которому нейронка ориентируется без багов, галлюцинаций и без знания архитектуры со стороны оператора (разработчика).
Инструменты
- getgedone — open-source проект, описан как «lightweight, powerful, meta-prompting, context engineering and spec-driven development system for cloud-code». Это полноценно реализованный spec-driven development, содержащий все необходимые агенты и инструменты для полного покрытия SDLC.
- Superpowers — похожий инструмент, построенный на скиллах (набор навыков для нужных ситуаций). Работает на основе TDD (можно брейнштормить, проектировать, отдавать роботу, делать код-ревью, писать тесты). Поддерживает паттерны TDD, YAGNI, DRY. Подходит для проектов меньшего уровня.
- GSD — более комплексная, тяжеловесная система для проектов enterprise-уровня. Требует четкого дробления, ест больше токенов, но более надежная.
Для обеих методологий (superpowers и GSD) создана отдельная шпаргалка (ссылка в Telegram-канале).
Этапы SDLC (при работе с GSD)
- Создание нового проекта
- Фаза проектирования: создание roadmap, обсуждение решений
- Планирование: разделение на маленькие задачи
- Исполнение
- Фаза тестирования
- Фаза шиппинга (вывод)
Практика и инструментарий
Планируется создать два проекта: первый на GSD, второй на Superpowers (возможно, совмещение). Используется пустой проект с помощью Codex.
Модель: Opus 4.7 с миллионным контекстом (на момент записи — 10 мая 26 года — топовый агент). Также неплох GPT 5.5 с высоким уровнем мышления — они конкурируют за первое место. Актуальные модели публикуются в Telegram-канале.
Установка: командой npx get-shit-done (копируется в консоль). После перезапуска навыки доступны в редакторе.
Редактор: WinServe с плагином Codex (более приятный визуальный интерфейс, адаптирован под агентскую разработку, неплохая индексация). Выбор редактора (Cursor, Antigravity, VS Code) не имеет особого значения.
Проект «Build or Kill»
Спецификация (файл spec.md) описывает SaaS-продукт на основе ИИ, помогающий фаундерам, разработчикам и креаторам быстро реализовывать идеи и понимать их нужность. Пользователь закидывает идею, и группа агентов (роли: product-стратег, CTO, growth-маркетер, скептик, инвестор, бизнес-ревьюер) обсуждает её с разных сторон.
MVP-features и stack: Next + VIT + React, TypeScript, Tailwind, немного бэкенда и UI. В спецификации есть suggested GSD roadmap для дозирования информации. Планируется две фазы.
Инициализация проекта через GSD-агента
Для оценки идеи собирается консилиум специалистов: product-стратег, CTO, growth-маркетер, скептик, инвестор, бизнес-ревьюер — разные роли с разных сторон.
План на ролик
- MVP-features присутствуют.
- Stack: Next + VIT + React, TypeScript, Tailwind, немного бэкенда, немного UI.
- Есть suggested GSD roadmap — он нужен, чтобы не захлебнуться в информации, дозировать её.
Две фазы
- Фаза 1 — продукт как общая оболочка и анализ на основе mock-данных; ничего интересного с точки зрения AI-разработки.
- Фаза 2 — интеграция реального искусственного интеллекта и доведение до MVP.
Инициализация проекта
Обращаемся к навыку GSD (get shit done). Команда: gsd new project. Можно отправить в пустой проект — запустится визард, но у нас есть готовая спека, поэтому инициализируем через неё.
Выбор модели
- Opus (подписка ~100 долларов / 8000 рублей) — для жёсткой автоматизации это копейки, хватает на 2-3 проекта одновременно.
- Opus используется для проектирования проекта.
- Sonnet — для реализации, токены экономятся.
- Haiku — для мелких правок, можно и руками внести.
Настройка фаз
Агент рекомендовал 3-5 фаз и 1-3 плана каждая. Вносим изменения: нужно 2 фазы для данного MVP, без переусложнения. Не соглашаемся со всем, что говорит агент — направляем его.
- Запускать ли фазы в параллелях? — нет.
- Гидтрекинг — включаем (нейронке доверяем, но проверяем).
- Research before planning each phase — Yes (подключает контекст, проверяет актуальность документации, инструментов, API).
- Verify plans were achieved — да, проверять.
- Verify work satisfies requirements after each phase — да.
Стадия инициализации
Сейчас мы на фазе инициализации: агент собирает вопросы, исследования, требования и конкретный roadmap перед сборкой. Кода пока нет — создаются системные файлы.
- project.md — описывает core values, requirements, расширенный список to-do (например, hero landing section, out of scope — то, что не нужно, типа autosignification, payment billing, database). Учтён двухфазный roadmap.
- research — агент делает web search по SDK, AI-платформам, Next, собирает актуальную информацию для production-проекта.
- Появляются файлы: architecture — нейронка справляется с архитектурой.
Agentic-разработка: фаза инициализации проекта
Процесс инициализации проекта занимает время — роботы работают не моментально. Агент выполняет web search, уходит на SDK, AI-платформы, Next, Proparsial. Он собирает актуальную, не устаревшую информацию для получения полностью готового production-проекта на текущий момент.
Пару лет назад в роликах говорилось, что это устаревшая тема. Теперь это agentic-разработка, где всё по-серьезному.
Созданные файлы
В первую очередь появился файл architecture. В нём описывается research по архитектуре, которая потребуется. Проект тестовый — это YouTube, делается MVP. Есть client-браузер, идея закидывается в пост. Чтение будет через local storage для клиентской части, экспорт в Markdown. На сервере описана архитектура серверной части, запросы к OpenAI, Anthropic. Будет использоваться DeepSeq (четвертой версии), скорее всего Flash или Pro — соизмеряя цену и качество, Pro хорош.
В Component Responsibilities описаны все компоненты с точки зрения структуры архитектуры. Есть ZOT-схемы для валидации, шаблончики для бэкэнда. Это фаза ресерча — к написанию кода ещё не приступали.
Этапы SDLC
Сейчас мы находимся на этапе requirements. Requirements самостоятельно собираются под нас.
Файл features описывает вещи, которые должны быть в проекте: сохранение истории. Это работа бизнес-аналитика, который анализирует, что нужно для проекта: edge-кейсы, развернутые сценарии, pipeline, MVP definition, фазы.
Файл pitfalls переводится как «подводные камни» — описывает, что может пойти не так. Это объемное исследование.
Файл stack показывает актуальные версии: Next.js — на текущий момент 16.2.6, TypeScript, React 19, Tilewind, Shred and CUI, TVAnimate CSS, AI Structured Output. SDK ещё не готов — будет переделываться. Form Handling.
Обычно в компании создание такой документации заняло бы около 2 недель. Для нейронки это делается быстро благодаря классному поиску по файлам, по конкретным местам, что создает точечный контекст и позволяет удерживать долгосрочную память.
Завершение инициализации
Фаза инициализации проекта заняла порядка 20 минут. Получен Get Your Done Project Initialization Finished. Агент переключился на Disqus.
Для многих людей это боль по токенам, но для разработчиков — автоматизация. Руками ничего не трогалось.
Полученные файлы
- Research — всё четко, с источниками
- Project
- Requirements — четко описаны для проекта
- Roadmap — показывает конкретный pipeline создания приложения, крайне важен для долгосрочного ведения
- State — показывает текущее состояние проекта
- Продвинутые хуки (всего 70)
- Скилл gsd-status — показывает, где мы находимся, фазу проекта
Дальнейшая работа
Фаза 1 валидна. Анализируются серые зоны, применяется авторежим. Появились новые тудушки, описывающие research конкретных фаз. В проекте ещё нет файлов кода — мы на первом этапе SDLC.
Появилась первая фаза ProductShellMockAnalysis из спеки. Разработка дробится на фазы, которые поэтапно исполняются. Для каждой фазы существует большое количество спецификаций.
Фаза 1: сделать runtime, конфигурации, схемы, mock-данные (на первой фазе работаем с mock, не с id), API, формы, loading state, results layout. Руками ничего не писалось. Есть scope — с чем связаны файлы, как они перелинкованы.
Вторая фаза: Discussion log (аргументация), UISPEC для конкретного UI — полное описание: spacing, typography, color. Фронтендеры и UXеры должны это понимать, но нейроночка для общих вещей уже прекрасно справляется.
Автоматическое планирование
Прошло около часа с момента первой команды. Агент автоматически ввел команду gsd plan new phase, что дало планирование фазы 1 с большим количеством файлов. Это произошло из-за режима bypass permissions — Клод может делать всё, что ему захочется.
Сначала была команда gsd new project. После инициализации проекта наступает фаза gsd discuss phase 1.
Автономная работа агента и фазы GSD
Агент продолжил работать автономно спустя около часа после первой команды. В какой-то момент он автоматически ввел команду gsd plan new phase, что привело к планированию фазы 1.
Причина автономности
Это произошло из-за режима bypass permissions — в этом режиме «Клод может делать все, что ему захочется».
Последовательность действий агента
После команды gsd new project и инициализации проекта обычно наступает фаза gsd discuss phase 1. В проекте описаны две фазы (фаза 1 и фаза 2). Агент автоматически запустил discuss phase 1, затем ввел gsd plan phase 1, а после — gsd execute phase 1.
- Discuss phase — вызывается скилл gsd discuss phase, куда параметром передается реализуемая фаза.
- Plan phase — агент задает вопросы, после чего запускает конкретную реализацию.
- Execute phase — на этой фазе пишется код.
Содержание фазы 1
В фазе 1 есть три этапа. Создана объемная документация: клиентский код, обрывки компонентов, сниппеты, требования, связки с другими элементами, указано, где лежат элементы для контекста. Много markdown-файлов. Также присутствует Research на тысячу строк, относящийся к первой фазе.
Результаты работы
Агент реализовал задачи, запустил фазу Self-Check, где проверил реализованное:
- 12 ключевых файлов верифицированы и реализованы.
- 6 задач закоммичены и реализованы.
- Осталось сделать environment-переменные.
Финализирует Metacommit, относящийся к инфраструктуре долгосрочной памяти, которая дается к лод-коду.
Волны (waves) выполнения
- Wave 1 завершена, запущена wave 2.
- В плане 02 агент должен построить субагентов для регистрации.
- Агент находится в режиме execute (режим исполнения, поле implementation в SDLC).
- Затем наступила wave 3 — execute wave 3.
Дальнейшие шаги
После завершения волн агент запустит фазу code review. Можно было бы подключить superpowers для TDD или code review, но агент запускает свой внутренний. Также запускается verify work и code verifier (отдельный агент для code review). После этого первая фаза завершится, и агент перейдет ко второй фазе.
Наблюдения
- Агент работает автономно около полутора часов.
- «Современная разработка» — задача человека: грамотно декомпозировать и собрать требования.
- На MPP-проекте в YouTube все просто, бизнес-заказчик адекватен. В реальных проектах — «каша полная всего», задача человека — стать оператором-архитектором.
- Аргумент, что «ИИ галлюцинирует, ИИ не напишет код», ничтожен — человек ручками ничего не делает, все создается автоматически.
- Параллелизация агентов в Codex нравится больше, чем в код-коде. Возможно, с Superpowers будет разрабатываться разнообразие.
- По бенчмаркам и пользовательскому опыту на 10 мая 26 года Codex обошел код-код впервые. С высокими требованиями к интеллектуальным способностям GPT 5.5 делает лучше, но код-код — «сердечки».
Итог фазы 1
Фаза 1 завершена. Написаны summary о том, что реализовано: три волны, есть end-point, back-end. Все добавлено в планинг и фазы. Например, human verification.
Фаза 2: обсуждение провайдера и мульти-рядного промптинга
Завершение фазы 1 и переход к фазе 2
Первая фаза завершена. Реализованы end-point, back-end, UI и human verification. В проекте есть mock-response-data. UI можно улучшить с помощью Frontend Skills или Verso React Best Practices. Также можно экспортировать Markdown.
Для перехода ко второй фазе делаем clear conversation и переходим к обсуждению фазы 2. Cloud Code с GSD анализирует текущее состояние, загружает контекст и начинает новую сессию. Долгосрочная память сохраняется.
Расход токенов
Первая фаза длилась около 2 часов. Лимит израсходован на 67%. Лимит обновляется через 50 минут, поэтому должно хватить.
Обсуждение фазы 2
Загружен контекст фазы 2. Нужно реализовать AI-интеграцию + Polish. Выделено 6 серых зон, из них выбираем 4 опции для обсуждения.
Выбранные области
- Провайдер + модель + своп
- Multi-row prompting (как будут работать агенты)
Не выбраны: AI-ошибки, ретраилогирование (перебор для MDP) и Polish scope.
Решения по провайдеру
- Дефолтный провайдер: other
- Используем API и SDK OpenAI
- Основная модель: DeepSeq
- Выносим в env переменные
base_urlиmodel_nameдля настройки