Как собрать инженерную команду нового типа: AI-native SDLC по версии OpenAI
OpenAI опубликовали гайд о том, как AI-агенты перестраивают каждую фазу SDLC и что инженерному лиду делать уже сегодня, чтобы запустить AI-native команду. Коротко и по делу — разбираем основные идеи, цифры и чек-листы.
Контекст: от автокомплита к агентам
В августе 2025 METR замерили, что frontier-модели выдают 2 часа 17 минут устойчивой работы с ~50% confidence на корректный результат. Длина задачи удваивается примерно каждые 7 месяцев — ещё недавно пределом были 30 секунд на одну подсказку кода. Это значит, что под AI-агентов попадает весь цикл разработки: планирование, дизайн, разработка, тестирование, ревью, деплой.
В OpenAI циклы разработки сжались с недель до дней. Рутинные задачи — документирование нового кода, поиск релевантных тестов, поддержка зависимостей, чистка feature-флагов — отданы Codex целиком. При этом ответственность за код по-прежнему на инженерах: новые или неоднозначные задачи требуют человеческого суждения.
Ключевые capability, которые делают это возможным:
| Возможность | Что даёт |
|---|---|
| Unified context | Единая модель читает код, конфигурацию и телеметрию |
| Structured tool execution | Агент вызывает компиляторы, тесты, сканеры и получает верифицируемый результат |
| Persistent project memory | Длинный контекст и compaction позволяют вести фичу от предложения до деплоя |
| Evaluation loops | Модель тестируется автотестами, бенчмарками и style-guides |
1. Plan
Планирование тормозит согласование между продактом и инженерами: нужно понять фичабельность, сроки, затронутые системы.
Как помогают агенты. AI coding agents дают code-aware инсайты прямо в момент планирования. Можно собрать workflow, который читает спецификацию из issue-трекера, сверяется с кодовой базой, флагирует неоднозначности, разбивает работу на подзадачи и оценивает сложность. Агенты мгновенно трассируют код-пути, показывая, какие сервисы задействованы — то, что раньше требовало часов или дней ручного копания.
Что делают инженеры. Команды тратят время на core-фичи, а не на митинги по скоупу. Зависимости и edge-cases выявляются заранее.
| Делегировать | Первый проход по фичабельности и архитектурному анализу: чтение спеки, маппинг на код, флагирование неоднозначностей |
| Ревьюить | Проверка точности, полноты, корректности оценок |
| Овнерить | Приоритизация, долгосрочное направление, трейдоффы |
Чек-лист старта: процессы согласования фичи ↔ код; базовые workflow (тегирование, дедупликация тикетов); более сложные — автогенерация подзадач по описанию; запуск агента, когда тикет достигает нужной стадии.
2. Design
Дизайн-фазу тормозит boilerplate, интеграция design system и переработка UI-компонентов.
Как помогают агенты. Мультимодальные coding agents принимают текст и картинки, скаффолдят проект, генерируют дизайн-токены и компоненты по конвенциям команды. Дизайн → код напрямую, подсказки по accessibility, анализ user-flow и edge-cases. Прототипы в high-fidelity за часы, а не дни.
Что делают инженеры. Сфокусированы на core-логике, архитектурных паттернах и качестве. Дизайнеры оценивают user-flow и альтернативы.
| Делегировать | Скаффолдинг, boilerplate, перевод мокапов в компоненты, дизайн-токены |
| Ревьюить | Соответствие конвенциям, качество, accessibility, интеграция |
| Овнерить | Design system, UX-паттерны, архитектурные решения |
Чек-лист старта: мультимодальный агент с текстом и изображениями; интеграция дизайн-инструментов через MCP; библиотека компонентов как MCP; workflow дизайн → компоненты → имплементация; типизированные языки (TypeScript) для валидации пропсов.
3. Build
Самая тяжёлая фаза: трансляция спеки в код, дублирование паттернов, boilerplate. В больших monorepo инженеры тратят больше времени на поиск «правильного пути», чем на саму фичу.
Как помогают агенты. Coding agents в IDE и CLI берут multi-step задачи целиком: драфтят фичи по спецификации, модифицируют десятки файлов с сохранением конвенций, генерируют boilerplate (обработка ошибок, телеметрия, security-обёртки), фиксят build-ошибки на лету, пишут тесты параллельно с кодом, готовят diff-ready changesets с PR-сообщениями.
Что делают инженеры. Уточнение продуктового поведения, ревью архитектурных последствий AI-кода, рефайн бизнес-логики, дизайн паттернов и guardrails.
| Делегировать | Первый проход: скаффолд, CRUD, wiring, рефакторинги, тесты |
| Ревьюить | Дизайн-решения, перф, безопасность, миграционные риски, доменное соответствие |
| Овнерить | Новые абстракции, cross-cutting изменения, неоднозначные требования, долгосрочные трейдоффы |
Cloudwalk использует Codex ежедневно: от скриптов и fraud-правил до полноценных микросервисов, поставленных за минуты.
Чек-лист старта: начинать с хорошо специфицированных задач; заставить агента использовать planning tool через MCP или PLAN.md; проверить, что команды агента выполняются успешно; итерировать AGENTS.md для автономных циклов (тесты, линтеры, фидбэк).
4. Test
Разработчики экономят на тестах ради скорости, а потом страдают от brittle и flaky сьюютов.
Как помогают агенты. Подсказывают test-cases по спецификации и feature-коду — особенно хороши для edge-cases и failure modes, которые разработчик мог упустить. Поддерживают тесты в актуальном состоянии при рефакторинге, устраняя friction от устаревших тестов.
Что делают инженеры. Тесты становятся источником истины — агенты могут их запускать и итерировать по результату, поэтому высокое качество тестов = возможность агенту собрать фичу. Инженеры фокусируются на паттернах покрытия, оспаривают выбор edge-cases, проверяют intent.
| Делегировать | Первый проход по генерации test-cases; часто в отдельной сессии от имплементации |
| Ревьюить | Что модель не сделала stub-тесты, что агенту доступны нужные permissions и context о test suites |
| Овнерить | Выравнивание покрытия со спекой и UX-ожиданиями, adversarial thinking |
Чек-лист старта: тесты — отдельным шагом с проверкой, что новые тесты падают до фичи; гайдлайны покрытия в AGENTS.md; конкретные примеры coverage-инструментов, доступных агенту.
5. Review
Разработчики тратят 2–5 часов в неделю на code review. Выбор между глубоким ревью и быстрым «good enough» — типичная боль.
Как помогают агенты. AI-ревью масштабируется так, что каждый PR получает стабильный baseline внимания. В отличие от линтеров, агенты выполняют код, интерпретируют runtime-поведение и трассируют логику между файлами и сервисами. Эффективно, когда модель специально натренирована на P0/P1-баги и настроена на короткие, высокосигнальные комментарии.
Что делают инженеры. AI code review даёт больше уверенности, что major-баги не уедут в прод. Часто ревью ловит проблемы, которые автор может исправить до привлечения коллеги. Финальный review и merge всё равно на человеке.
| Делегировать | Первичный code review агенту — может происходить несколько раз до ready-for-review |
| Ревьюить | Архитектурное соответствие: composable-паттерны, конвенции, соответствие требованиям |
| Овнерить | Код, который едет в прод: надёжность и соответствие требованиям |
Sansan использует Codex review для race conditions и database relations — того, что люди часто пропускают. Codex также ловит хардкод и предсказывает проблемы масштабируемости.
Чек-лист старта: курировать примеры gold-standard PR (код + комментарии) как eval-set; выбрать продукт с моделью specifically trained на code review — generalized модели дают много шума; определить метрики качества ревью (например, реакции на комментарии в PR); стартовать small, rollout быстро после уверенности.
6. Document
Документация отстаёт, потому что её обновление отвлекает от продукта, а документационные спринты дают одноразовый эффект.
Как помогают агенты. Хорошо суммаризируют кодовую базу, генерируют mermaid-диаграммы, обновляются по промпту. Через AGENTS.md инструкция «обновить документацию» автоматически добавляется к каждому промпту. Через SDK агенты встраиваются в release workflow: например, анализ коммитов в релизе и summary изменений.
Что делают инженеры. Решают, как организована документация, добавляют важное «почему», задают стандарты и шаблоны, ревьюят критичные и customer-facing части.
| Делегировать | First-pass summaries файлов и модулей, описания I/O, dependency lists, summary PR-изменений |
| Ревьюить | Обзоры core-сервисов, public API и SDK docs, runbooks, architecture pages |
| Овнерить | Стратегия документации, стандарты, external-facing и safety-critical документы (legal, regulatory, brand) |
Чек-лист старта: эксперимент с генерацией документации через агента; guidelines в AGENTS.md; workflow (release cycles), где документация генерируется автоматически; ревью качества и корректности.
7. Deploy and Maintain
Во время инцидентов инженеры переключаются между логами, деплоями и инфрой — теряя критичные минуты.
Как помогают агенты. Доступ к logging tools через MCP-серверы + контекст кодовой базы = один workflow: промпт «посмотри ошибки для endpoint X», агент трассирует код и находит релевантные баги или проблемы перфа. CLI-доступ к git history позволяет идентифицировать изменения, которые могли вызвать проблемы из логов.
Что делают инженеры. Происходит сдвиг от ручного разбора к анализу и принятию решений.
| Делегировать | Трассировка ошибок до кода, идентификация подозрительных git-изменений, сбор контекста для runbook'ов |
| Ревьюить | Корректность выводов агента, приоритизация гипотез, валидация предложенного фикса |
| Овнерить | Production-решения: rollback, миграции, on-call решения |
Чек-лист старта: logging tools как MCP-серверы; git history доступен агенту; workflow для инцидентов, где агент собирает initial triage за минуты.
Что это значит для лида
Гайд OpenAI не про «заменить инженеров агентами». Он про перераспределение: агенты берут первый проход везде, где это воспроизводимо (boilerplate, тесты, ревью, документация, разбор логов), а инженеры фокусируются на том, что требует человеческого суждения — приоритизация, дизайн, архитектура, edge-cases, ownership production-кода.
Три практических вывода:
- Стартовать с конкретной фазы SDLC, не пытаться покрыть всё сразу. Самые понятные точки входа — Test и Document, потому что у них низкий риск и быстрый feedback loop.
AGENTS.md— главный артефакт команды. В него сводятся guidelines, planning workflow, требования к тестам, правила документации. Без него агенты работают в вакууме.- Метрики качества важнее скорости. PR-ревью оценивается по реакциям, документация — по факту использования, тесты — по отсутствию flaky. Без метрик AI-native процесс быстро превратится в накопление техдолга.
Длинный хвост работы — адаптация процессов найма, онбординга и performance review к новому распределению труда. Но технический фундамент уже есть: агенты могут взять первый проход по каждой фазе SDLC, а инженеры — направить их и взять ответственность за финальный продукт.