Стандартный вопрос найма: AI у всех пишет код — покажите, что вы применяли его на каждой фазе SDLC, а не только в IDE. Ниже — список практик по фазам SDLC с артефактами. Разбор сгруппирован по Planning, Requirements, Design, Implementation, Testing, Deployment, Maintenance и отдельному блоку delivery management. Для каждой фазы — конкретная практика, коммерческий контекст, цифры результата и публичный артефакт, который можно проверить по ссылке или репозиторию.
AI используется как инструмент для подготовки артефактов на этапах SDLC: от сбора требований до мониторинга и самовосстановления в production.
Сводная таблица: фаза → практика → эффект → артефакт
| Фаза SDLC | AI-практика | Цифра / эффект | Публичный артефакт |
|---|---|---|---|
| Planning | Spec-Driven Development; constitution-as-memory; git log как датасет | Askona: эффект оценивался по операционным метрикам в первые 2 года | ytrader-bybit; git-log-as-dataset |
| Requirements | Clarify-гейт в Jira; AI-валидация постановки задач | метрики цикла согласования не снимались; наблюдаемый эффект — меньше ручных итераций по уточнению требований | jira-requirements-elicitation; jira-clarify-bot |
| Design | Агентное согласование контрактов; A2A поверх Git; RAG-архитектура | FB 105k просмотров / 203 комментария; миллионы событий/день | bots-discuss-spec; a2a-file-bus; book-as-context |
| Implementation | AI-assisted coding как командная практика; next best offer; бот для read-only запросов к data lake через NL→SQL; воспроизводимые workflow; enterprise code bastion | в типовом сценарии получение ответа на вопрос к данным сокращалось с ожидания задачи в Jira до интерактивного NL→SQL-запроса; десятки сессий × 100–200 человек | agent learns; ai-n8n-workflow-builder; enterprise-code-bastion |
| Testing | Eval-harness как release-gate (3 слоя); self-healing UI harness | UMI: SDLC-фундамент без AI — дефекты 5–10/день → ≤5/неделю; eval-harness — AI-слой поверх | eval-harness-agent-drift; blog/2246 |
| Deployment | Guardrails harness; code review как гейт; Kafka = 2PC | UMI: delivery без AI → +50% выручки; AI guardrails — Askona и текущие проекты | guardrails; code review; kafka-2pc |
| Maintenance | LLM как consumer событий; Grafana observability; ML lifecycle (warm-up → online learning → intelligent); потоковое переобучение ML | 199M+ профилей (PersonaClick); Telegram run report; ytrader-bybit | кейс PersonaClick; ytrader-bybit; этот проект |
| Сквозной: управление delivery | Project intelligence; автономная агентная организация (Strategy/Sense/Act/Guard) | ~2 мес., 2 проекта; fail-closed + Guardian veto | кейс project-intelligence; agents-org |
Planning — планирование как артефакт
Планирование веду через Spec-Driven Development: последовательность specify → clarify → plan → tasks → implement. Изменения начинаются со спецификации; код пишется после clarify/plan/tasks. AI-агент не строит структуру заново на каждом запросе, а наследует шаблоны из зафиксированной памяти проекта (.specify/memory/). Это снижает риск ситуации: «один промпт → агент сразу пишет код». В таких задачах быстро теряется структура решения, а откат становится трудозатратным.
Расширение паттерна — constitution-as-memory: утверждённый документ с архитектурными правилами с версией (constitution.md) фиксирует архитектурные принципы (microservices, shared DB, testing discipline, observability). Агент наследует его при каждой задаче — не переспрашивает архитектуру заново, не предлагает решения, противоречащие зафиксированным правилам без явного изменения constitution.md. Принципы версионируются и амендируются явно, с обоснованием и планом миграции.
Отдельный инструмент — git log как датасет: детерминированные метрики (churn, co-change matrix, переломные коммиты) плюс LLM-интерпретация поверх них. Для архитектурного ретроанализа каждое утверждение в отчёте сопровождается SHA коммита или числовой метрикой.
Коммерческий контекст. Enterprise-трансформация Askona ($680M+ выручки, 15M клиентов, 9000+ сотрудников, 20+ распределённых команд, 40+ сервисов). Планирование изменений по принципу поэтапной смены правил, а не «большого взрыва» — эффект оценивался по операционным метрикам в первые 2 года.
Артефакты:
- Howto «Spec Kit workflow» — reference trace:
github.com/dobryakov/ytrader-bybit. - Howto «Git log как датасет»: <https://www.dobryakov.com/howto/git-log-as-dataset.html> · репозиторий
git-evolution-audit.
Requirements Analysis — clarify-гейт до разработки
AI-агент ведёт структурированный диалог с заказчиком прямо в Jira: задаёт вопросы по осям (scope, акторы, данные, NFR, зависимости, acceptance criteria) и не пускает задачу в разработку, пока постановка не созрела. С project context (bible + corpus + история похожих задач) вопросы заземлены под конкретный проект. На выходе — зрелый тикет с проверяемыми AC.
Коммерческий контекст. AI использовался в управленческом контуре: уточнение требований, постановка задач, согласование между стейкхолдерами — в enterprise-роли, до перехода на coding. Валидация требований и согласование scope, acceptance criteria, зависимостей и NFR между стейкхолдерами в интеграции с Jira — отсюда и вырос фокус «AI в слое менеджмента, а не только в разработке».
Паттерн переносится и в личные проекты: в ytrader-bybit clarify Q&A сессия зафиксирована прямо в spec.md каждой фичи (формат «Q: … → A: …»). Задача не уходит в план, пока открытые вопросы не закрыты. Инструмент другой — Cursor вместо Jira, — но принцип тот же: clarify-gate до разработки.
Цифры/эффект. Метрики цикла согласования не снимались; наблюдаемый эффект — меньше ручных итераций по уточнению требований.
Артефакты:
- Howto «Clarify gate в Jira»: <https://www.dobryakov.com/howto/jira-requirements-elicitation.html> · репозиторий
github.com/dobryakov/jira-clarify-bot(FastAPI, Docker, контракт вебхуков).
Design — агентное согласование контрактов
Два уровня.
Проектирование контракта. Два AI-агента — по одному от каждой стороны интеграции — самостоятельно проводят переговоры и согласовывают контракт. Продукт: openspec.yaml (OpenAPI) + транскрипт переговоров + git-история пошагового формирования контракта. Архитектурный принцип: граница организации пересекается только контрактом (POST /orders), а не внутренними данными. Ownership операций явно закреплён в endpoint'е. Транспорт между организациями — Google A2A поверх Git (shared-repo как production-ready канал).
Проектирование с опорой на знание. Book-as-context: RAG поверх книги (Таненбаум) + wiki-граф, чтобы архитектурные решения опирались на канон, а не на память модели.
Коммерческий контекст. В Askona сформирована и закреплена как корпоративный стандарт архитектура асинхронной событийной интеграции (Kafka/RabbitMQ/API) — де-факто multi-party integration layer для десятков сервисов и команд с разными владельцами. Масштаб — миллионы событий в день по 40+ сервисам. AI-практики проектирования (агентное согласование контрактов, A2A поверх Git, Spec Kit) применялись в Askona и оформлены в публичные howto. Эта архитектура поддержала маркетплейс/B2B2C, омниканальность и географическую экспансию.
Цифры/охват. Пост book-as-context — 105k просмотров и 203 комментария на Facebook (прокси публичного спроса на design-контент).
Артефакты:
- Howto «Cross-org agent negotiation»:
github.com/dobryakov/bots-discuss-spec. - Howto «A2A поверх Git»: <https://www.dobryakov.com/howto/a2a-file-bus.html> · репозиторий
a2a-example. - Book-as-context: <https://www.dobryakov.com/blog/2206/> · howto <https://www.dobryakov.com/howto/book-as-context.html>.
Implementation / Coding — AI как командная практика
AI-assisted coding применялся командно: практики были оформлены в правила, workflow и обучающие сессии. В enterprise-контуре собраны реальные production-микросервисы через AI-assisted coding в ходе обучения команд:
- next best offer — ML-модель на исторической статистике заказов; сервис прогнозирует следующий вероятный товар для корзины и email;
- трекер событийных таймстампов — end-to-end отметки по жизненному циклу заказа для аналитики узких мест;
- proxy-микросервис георезолвинга — координаты ↔ адрес для интеграционных сценариев;
- бот для read-only запросов к data lake через NL→SQL — conversational-доступ бизнеса к данным заказов; вопрос на естественном языке автоматически превращается в SQL и возвращает человекочитаемый и машиночитаемый результат; guardrails: read-only и валидация имён таблиц/колонок. В типовом сценарии получение ответа на вопрос к данным сокращалось с ожидания задачи в Jira до интерактивного NL→SQL-запроса в регулярном использовании.
Отдельный слой — воспроизводимость агентной автоматизации: агент производит персистентные версионируемые артефакты (dual-file pattern: .workflow.json + .meta.md), а не эфемерные ответы. Повторяющаяся задача переиспользует проверенный workflow, а не регенерирует его заново.
Ошибки фиксируются в отдельный файл/правила, которые затем подмешиваются в контекст следующих запусков агента.
Governance. Два слоя:
- Enterprise code bastion — для контуров, где нельзя давать LLM доступ к файлам и шеллу: Claude работает через
--tools "", MCP-only, фильтрация команд, исполнение в изолированном контейнере. - Cursor rules как версионируемый governance — правила в
.cursor/rules/*.mdcзафиксированы в git и наследуются всей командой; AI-ассистент получает контекстуальные, проектно-специфичные инструкции при каждой задаче, а не «помнит» договорённости из чата. Онбординг нового инженера — clone + symlink, правила наследуются автоматически. Верифицируемый артефакт:github.com/dobryakov/cursor-rules(2★).
Масштаб. Практики AI-assisted coding масштабированы через обучение: несколько десятков сессий на аудиторию 100–200 человек.
Артефакты:
- Howto «Воспроизводимая агент-автоматизация»: репозиторий
ai-n8n-workflow-builder. - «Агент учится на ошибках»: <https://www.dobryakov.com/blog/2266/> (RU) · <https://www.dobryakov.net/blog/92/> (EN).
- Howto «Enterprise code bastion»: <https://www.dobryakov.com/howto/enterprise-code-bastion.html> · репозиторий
enterprise-code-bastion.
Testing — eval-harness как release-критерий
AI-фича, проверенная только на demo-наборе, может деградировать на реальных входах из-за demo-grade eval: те же входы, что на питче; длинный хвост реального трафика не прогонялся. Решение — eval-harness как release-gate из трёх слоёв:
- Layer 1 — Regression: фиксированный набор кейсов из реальных инцидентов (не из демо); любой новый фейл блокирует релиз.
- Layer 2 — Distribution check: 20–50 свежих реальных входов, diff против снапшота прошлого релиза.
- Layer 3 — Human spot-check: обязателен перед первым прод-деплоем нового вида вывода.
Один человек подписывает sign-off; если владелец sign-off не назначен, релиз-гейт считается неполным. Отдельно — самовосстанавливающийся browser-harness для UI-проверок.
Коммерческий контекст. SDLC-фундамент я строил без AI — раньше, в UMI.CMS/UMI.RU (65k коммерческих пользователей, команда 10–15 человек): QA-практики, нормальный баг-трекинг, CI/CD, распределённая тестовая ферма. Результат: поток новых дефектов снижен с 5–10 в день до не более 5 в неделю, релизы — с «раз в несколько месяцев» до еженедельных. Eval-harness как AI-специфичный release-gate — практика следующего периода (Askona и позже), когда в SDLC появился AI-вывод, требующий отдельного слоя контроля дрейфа.
Отдельный слой — contract-тесты как изолированный уровень проверки межсервисных контрактов (feature-service/tests/contract/), тесты внутри Docker-контейнеров (NON-NEGOTIABLE в constitution: тесты никогда не на хосте). Верифицируемый артефакт: github.com/dobryakov/ytrader-bybit.
Артефакты:
- Howto «Eval как release-критерий»: <https://www.dobryakov.com/blog/2246/> · <https://www.dobryakov.net/howto/eval-harness-agent-drift.html> · репозиторий
eval-harness.
Deployment — релиз с guardrails
На границе релиза AI работает как контур контроля:
- Guardrails harness — проверки, которые не дают выпустить небезопасный или несоответствующий вывод: prompt injection defense, data isolation, human-in-the-loop checkpoints.
- Code review с проверяемыми критериями блокировки релиза — code review часто превращается в ритуал; AI-ревью проверяет заданные классы дефектов и блокирует merge при нарушении правил.
- Надёжная доставка в шину — отправка в Kafka трактуется как 2PC (two-phase commit): это снижает риск потери события между записью бизнес-состояния и публикацией сообщения.
- Fail-closed + единый Publisher (из
agents-org): необратимые публичные действия совершает ровно один агент — Publisher — и только после явной санкции владельца. При неоднозначности, ошибке инструмента или срабатывании guardrail агент останавливается и эскалирует, а не «додумывает и действует». Guardian — независимый контур с правом вето; вынесен из операционной линии и подчинён владельцу напрямую (как внутренний аудит подчиняется совету директоров, а не менеджменту). Сужение права на необратимое до одной точки — одна точка контроля.
Коммерческий контекст. Предсказуемый delivery строился без AI: в UMI переход на управляемые релизы снял страх клиентов обновляться и дал рост выручки на 50%; платформа стала частью M&A-ценности актива. AI-слой на deployment (guardrails harness, AI code review как гейт) — практика Askona и текущих проектов, где в production уходит AI-вывод с нетривиальными рисками небезопасного или несоответствующего поведения.
Артефакты:
- «AI guardrails harness»: <https://www.dobryakov.com/blog/2282/> (RU) · <https://www.dobryakov.net/blog/106/> (EN).
- «Code review theater»: <https://www.dobryakov.com/blog/2262/> (RU) · <https://www.dobryakov.net/blog/88/> (EN).
- Howto «Отправка в Kafka — это 2PC»: <https://www.dobryakov.com/howto/kafka-two-phase-commit.html> (YouTube-разбор, ~3600 просмотров).
Maintenance — LLM в production-эксплуатации
В эксплуатации AI — consumer событийного потока (Kafka, webhooks, monitoring): разбор портянок логов, подсветка аномалий, автоматический root cause анализ. Практика применяется в production-сценариях: обработка логов, аномалии, RCA.
Личная практика — два верифицируемых репозитория:
- marketing-pipeline (этот проект): агент читает события каждого прогона — вакансии, матчи, сигналы по компаниям — синтезирует операционный run report и доставляет в Telegram. Паттерн: LLM как consumer структурированного лога, а не человек, читающий вывод в терминале.
- ytrader-bybit (
github.com/dobryakov/ytrader-bybit): Grafana с кастомными дашбордами для observability торгового пайплайна (trading signals, model quality, execution flow). ML model service с явными режимами эксплуатации: warm-up (эвристики пока нет обученной модели) → online learning (переобучение по execution feedback) → intelligent mode (model-based signals). Сервис автоматически переключает режимы ML lifecycle по заданному quality threshold.
- agents-org (
github.com/dobryakov/agents-org): Self-Audit — агент, направленный внутрь: проверяет консистентность бренд-поверхностей (сайт, профили, материалы), выявляет протухшие ссылки, устаревшие факты, битые воронки. Cost Analyst — аналитика расхода агентов: estimate vs actual по классу задачи и классу агента, питает unit-экономику и бюджетное планирование. Оба агента работают в maintenance-режиме — автономно, только чтение, выводы в org state.
Производственный кейс:
- Потоковое переобучение ML (PersonaClick, платформа персонализации, 199M+ профилей): миграция ML-пайплайна с медленного пакетного переобучения на инкрементальное/потоковое — устранение устаревания рекомендаций, которое ослабляло сетевой эффект. Плюс диагностика и исправление повреждений данных и рассинхронизации профилей. Итог — эффект оценивался по cash flow и удержанию клиентов, устойчивость платформы под международной нагрузкой.
Артефакты:
- Кейс PersonaClick — ML/предиктивная аналитика в production на 199M+ профилей.
- Кейс Askona — event-driven observability.
Сквозной слой: AI в управлении delivery
Отдельно от семи фаз — AI использовался для управленческих задач: обработка коммуникаций, контроль обязательств, выявление расхождений в документах. Два уровня зрелости.
Уровень 1 — project intelligence система (solo, с нуля): набор скиллов для Claude + несколько скриптов, работала на живых проектах.
Что делает:
- поглощает звонки/транскрипты, почту, корпоративные чаты (M365) и документы клиента;
- формирует базу фактов с источником, timestamp, уровнем достоверности и открытыми вопросами: факты с provenance (источник + таймстамп до секунды), уровень достоверности, открытые вопросы, обязательства;
- взвешивает факты по легитимности источника (заявление финансового менеджера про финансы весомее, чем про финансы от тестировщика);
- автоматически находит расхождения между письмами, SOW, сметами и обязательствами: обещали клиенту за X, в смете 2X; клиент две недели ждёт ответа; две версии SOW с разными датами; зреющий scope creep до отправки клиенту.
KPI системы: scope compliance, commitment tracking, возраст открытых вопросов; они связаны с риском потери маржи.
Эффект (~2 месяца на двух проектах): несколько раз находила ошибки в сметах, пропущенные ответы клиенту и противоречия между документами. Разработчики говорили, что глазами не могут ничего извлечь из клиентских документов — система вытаскивала существенно больше.
Уровень 2 — автономная агентная организация (github.com/dobryakov/agents-org): AI-агенты выполняют часть операционных ролей; владелец утверждает необратимые действия. Спроектирована как набор ролей, общих state-файлов, guardrails и журналов для автономного ведения проектов.
Ключевые архитектурные решения:
- Все агенты читают общее состояние, но права на действия различаются по ролям — общее состояние видно всем агентам; координация без лишних звонков.
- Разделение властей — Strategy (задаёт цель), Act (исполняет), Guard (контролирует) разведены; тот, кто проверяет, не инициирует.
- Ограничения реализованы технически: deny-list/allow-list, обязательные проверки, fail-closed поведение — ограничения реализованы как технические guardrails (нельзя обойти), не как инструкции («должен помнить»).
- Fail-closed — при неоднозначности агент останавливается и эскалирует, не додумывает.
- Каждый агент пишет структурированный лог; по нему считаются качество, стоимость и частота срабатывания guardrails — качество агентов и здоровье организации измеряются постоянно.
Домены: Strategy (портфельное управление), Sense (Opportunity Scout, Audience Analyst, Reputation Monitor, Self-Audit, Cost Analyst), Act (Content Producer, Publisher), Guard (Guardian с правом вето), Conduct (Chief of Staff + Orchestrator).
Как использовать этот документ
Короткий ответ (1 абзац) для HR-экрана: «AI применяю не как автодополнение, а на каждой фазе SDLC — от clarify-гейта требований в Jira и агентного согласования контрактов до eval-harness как release-критерия и LLM-мониторинга событий в проде. Всё это — документированные практики с публичными репозиториями и статьями, плюс отдельный слой: AI над самим управлением delivery. Сводный разбор: dobryakov.com/blog/2256/ (RU) и dobryakov.net/blog/82/ (EN).»
Развёрнутый ответ: сводная таблица выше плюс блоки по фазам.
Под конкретную роль:
- Платформа / SRE — акцент на фазах Deployment и Maintenance.
- Продукт с AI / ML — Implementation + кейс PersonaClick.
- Turnaround инженерной функции — Testing / Deployment (UMI) и сквозной слой (project intelligence).
- Engineering leadership / CTO — сквозной слой и Design (масштаб Askona).
Проверяемость обеспечивается ссылками на репозитории, howto и публичные статьи.
https://www.dobryakov.com/lead-magnets/ai-sdlc-hr-proof.html?utm_source=None&utm_medium=None&utm_campaign=ai-sdlc-hr-proof