AI в SDLC: путь к 100% adoption и сквозному SDD

Вебпрактик — веб-интегратор для корпораций

Маршрут доклада

🙋 Вопросы залу про adoption

Поднимите руку, если это про вас:

• Кто тут тимлид и выше?
• У кого адопшен в разработчиков > 50%?
• У кого адопшен 100%?
• А у кого адопшен в аналитиков и QA > 50%?

Фаза 1Автокомплит и ассистент

Начало 2025

• Мы все очень любим JetBrains IDE — поэтому в первую очередь смотрели плагины именно под неё
• В то время гремел Windsurf: великолепный автокомплит и генерация небольших блоков кода
• Протестировали → увидели реальное контекстное ускорение
• К лету пересадили большинство разработчиков на этот инструментарий

Модели

• Anthropic через шлюз ИБ — контроль PII и секретов на выходе
• Для части заказчиков — модели в закрытом контуре

Как пересадить всех,
в т.ч. скептиков?

Трекеры

• За каждым инженером закрепили трекера
• Трекеры — это члены AI-клуба
• Раз в месяц собирали статистику по всем
• Большую часть трекинга взяли на себя руководители цехов и тимлиды — они сами были участниками клуба

Начало 2026

100%

adoption среди разработчиков

Важно при этом:

Вся ответственность за каждую строчку кода остаётся на том, кто его пишет.

Кейс удалёнщика

Наняли парня в ноябре — сразу с AI-майндсетом, удалёнка. Задачи вроде решал, но:

• Много ошибок на ревью — причём каждый раз новые, не повторялся
• В коммуникации начали проскакивать странные вещи

Руководитель предложил поработать в паре денёк.
(Предложение, от которого нельзя отказаться.)

Инженер должен понимать свой код

У разработчика оказался недостаточный инженерный уровень. По факту — прослойка к коду: всё пересылал в Claude и возвращал обратно, не понимая результата.

Справедливости ради — он хорошо работал с memory и натаскивал агента не ошибаться дважды.

Нам нужны инженеры, которые понимают свой код. Если ревью делает только другой человек — смысла в таком операторе нет.

Что делать
с глубиной?

Автономность снижает бас-фактор

Логика простая:

• Растёт продуктивность → команды потенциально уменьшаются в размере
• Меньше команда → выше риск завязки на конкретных людей
• Повышение уровня автономности процесса — то, что в том числе уменьшает бас-фактор

Кейс стратегической сессии

Попросили руководителей цехов нарисовать, как они видят выход на L3.

Нужен единый
фреймворк и платформа

База OpenSpec: два состояния контекста

• changes/ — логи изменений. Активные предложения: что и зачем меняем прямо сейчас
• specs/ — источник истины. Поддерживаемое описание того, как система работает сейчас

Change живёт, проходит ревью и реализацию → затем вливается в источник истины.

Базовые артефакты — структура папок

openspec/
├── specs/                # ИСТОЧНИК ИСТИНЫ (domains)
│   └── <domain>/
│       └── spec.md
└── changes/              # активные предложения
    └── <change-id>/
        ├── proposal.md   # смысл: зачем и что
        ├── design.md     # ADR / решения
        ├── tasks.md      # план реализации
        └── specs/        # дельта к источнику истины

Жизненный цикл change

Один и тот же артефакт ведёт задачу от смысла до прод-кода.

Flow: кто что делает агентом

1. Аналитик/продукт генерит весь change, фокус — на proposal (смысл)
2. Разработчик делает ADR + план реализации агентом на основе proposal
3. Разработчик делает реализацию агентом
4. Тесты:
   • v1: тестировщик пишет тесты и e2e
   • v2: e2e берёт на себя разработчик

План тестирования (test-plan.md)

• План тестов — часть change, рождается вместе с ним
• Генерируется агентом из proposal и спеки
• Покрытие на нескольких уровнях: юнит/интеграция, компонентный (на фронте) и e2e-сценарии
• Спеки дают проверяемый критерий: тест отвечает на пункт спеки

UseCase vs Gherkin

По умолчанию в OpenSpec — Gherkin.

• Попробовали заменить на UseCase по просьбе аналитиков — человеку он читается удобнее
• Получили деградацию качества автотестов: Gherkin точнее как приёмочные критерии
• Вернули Gherkin как основу
• Для некоторых элементов дополнительно генерируем UseCase — отдельным файлом в change OpenSpec

Документация для стейкхолдеров

Человекочитаемую доку собираем из спек отдельным скилом.

• Правим спеки → дока пересобирается скилом, без ручной синхронизации
• Не плодим параллельную доку, которая устаревает на второй день

Трассировка: от строки кода к смыслу

Каждый коммит подписан названием change, на основе которого вносился.

Связь «код ↔ change» восстанавливается локально, без похода в трекер.

change-центричная парадигма

• Жизненный цикл change видим в моменте: как менялся, какие коммиты привязаны, какие авторы над ним работали
• Change ≠ task: он начинается раньше — ещё на досках дискавери, и держит смыслы и дизайн
• Поэтому сделали свой сервис визуализации спек — spek: удобный поиск, статистика, связи, статус прогресса

SDD — фундамент нашего harness

Скилы — лишь часть нашего harness

Узкое место сместилось

• Не всегда и не у всех оно теперь в разработке
• Часто — в продакт-менеджменте: бэклог большой, но без DoR
• И в пути до прода — чтобы докатить изменение до продакшена

Выводы

1. Внедряйте AI в SDLC сквозным образом — единый процесс через всю цепочку
2. Внедряйте SDD — спеки как источник истины и общий язык для людей и агентов
3. Harness — это движок/ядро вашего производственного процесса. И на рельсах SDD оно едет гораздо увереннее.