Video summary

AI митап - Где заканчивается вайбкодинг и начинается инженерная AI-разработка

Main summary

Key takeaways

Technology

Технологическая идея видео

Обсуждение того, как перейти от “vibe-кодинга” (когда LLM/агенты пишут код “как получится”) к инженерной AI-разработке — воспроизводимому процессу, где:

  • намерения/спецификации и качество закрепляются артефактами,
  • важны планирование и тестирование,
  • в компании это масштабируется через стандарты SDLC/PDLC, роли и инфраструктуру.

Ключевой тезис: инженерная AI-разработка — это не “умнее агент”, а “управляемость процесса”.

Основной доклад (Edgar): SD/agent-based процесс, намерения и спецификации (OpenAPI Spec и аналоги)

1) Почему “одного чата” недостаточно

В обычных agent-подходах “намерение” и контекст теряются между шагами/агентами: чат не является надежным хранилищем архитектурных решений и требований.

Большой контекст (“впихнуть все в окно”) не решает проблему:

  • дорого по токенам,
  • не гарантирует качество (в середине контекст забывается),
  • возможны галлюцинации из-за “несущего контекста” и границ диалога.

Вывод: нужна внешняя память/артефакты намерений, которые переживают сессию и доступны разным агентам.

2) Попытка решить это через Plan/Planmod (план в рамках сессии)

Идея: планирование как отдельный артефакт внутри сессии. Процесс обычно такой:

  • агент исследует репозиторий,
  • задаёт вопросы,
  • строит план (часто “out loud”),
  • затем код пишется после согласования плана.

Коммуникационный цикл:

  1. план
  2. review
  3. правки плана
  4. согласование
  5. реализация
  6. commit

Проблема: план оказывается локальным артефактом агента (часто в Markdown/внутри окружения диалога), который:

  • “невидим”/не живет как часть репозитория,
  • легко забывается/стирается при завершении сессии,
  • не является “инженерным контрактом системы”, а скорее “памяткой по шагам”.

3) Что дает SD (spec-driven / contract-first) через OpenSpec

SD описываются как эволюция: спецификация как версияционный артефакт, из которого генерируется код.

Аналогии: стандарты вроде OpenAPI и схожие spec-подходы (упоминаются аналоги на GitHub и под разные экосистемы).

Ключевая структура OpenSpec:

  • Specs/ — “как система ведет себя” (текущая модель поведения, авторизация, платежи, правила и связи с кодом)

  • Changes/ — изменения/дельты требований (почему меняется, на базе чего, какие требования/ограничения добавляются)

Эффект:

  • система становится само-документируемой,
  • спецификации проще ревьюить,
  • код — результат “компиляции” документации.

Ревью упрощается: сначала читается спецификация, затем — при необходимости — код.

4) Важные оговорки/недостатки

  • SD не всегда оправдан: для простых задач это может стать оверкиллом (например, вместо ~10 строк кода — огромная документация).

  • Упоминаются риски/недостатки, включая security.

  • SD описывают как механизм, особенно закрывающий ~20% самых сложных бизнес-челенджей; остальное можно закрывать более легкими агентными/плановыми подходами.

Тезис: инженерная AI-разработка — это не “умнее агент”, а “управляемость процесса”: артефакты и воспроизводимость сохраняются в Git/контракте, а агент действует в рамках намерений.

Доклад (Gleb): почему TDD нужен агентам (TDD-ориентированный agent workflow)

1) Проблема “работает в конце, но качество плохое”

Типичный сценарий:

  • агент пишет код,
  • авто-тесты/проверки “проходят”,
  • затем всплывают регрессии и реальные дефекты.

Попытка “встроить тесты” через LLM:

  • агент генерирует тесты так, чтобы они проходили,
  • тесты могут быть “левой” природы: “вроде бы покрывают”, но проверяют не то.

2) Главная причина: priming (priming effect)

Если агент пишет тест после того, как код уже есть в контексте, возникает priming:

  • модель подстраивает тест под текущий код так, будто тест “должен пройти”,
  • агент “видит код глазами” и фактически перестает думать как тестировщик реального сценария.

Следствие: тесты становятся “подгонкой”, а не проверкой логики относительно требований/поведения.

3) Решение: TDD как “тесты сначала”

Переход к TDD-потоку:

  • сначала писать тесты по бизнес-ожиданию,
  • затем писать код, который удовлетворяет тестам.

Однако одного “тесты → код” недостаточно: нужен feedback loop и контроль качества.

4) Агентный feedback loop с reviewer/subagent

Рекомендуемый процесс:

  1. Main agent генерирует тесты по бизнес-функциональности.
  2. Reviewer/subagent анализирует тесты и специально “оценивает ошибки тестов” (другой ролью/промптом/критериями).
  3. После ревью генерируется/уточняется код.
  4. Код тоже проверяется/ревьюится.

Плюс: использование другой модели/подагента повышает шанс найти дефекты — модели критикуют реализацию друг друга.

5) Минимальная формализация в “skills/agent rules”

Идею закрепляют в rules/skills:

  • “First: write tests.”
  • отдельная skill может выполнять reviewer-проверку после тестов.

Итог: “hyper-stable” unit/integration тесты и более надежное поведение системы при LLM-генерации.

Доклад (Zhenya): как внедрить AI+агентов в бизнес-процесс (масштабирование и PDLC)

1) Ошибка раннего масштабирования: “просто выдать инструменты”

В пилоте несколько команд получали эффект скорости. При масштабировании “всем дали инструменты” эффект стал нулевым или отрицательным из‑за:

  • отсутствия единого подхода/методологии внедрения,
  • смещения bottleneck’а: ускорили код → уперлись в тестирование/приемку и согласования,
  • роста времени на review/approval из-за новизны подходов у людей.

2) Обучение “с рынка” не работает как стратегия

Проблемы:

  • дорого,
  • плохо встраивается в рутину,
  • быстро устаревает.

Подход “амбассадоров” тоже давал сбой:

  • энтузиасты не всегда эксперты по домену,
  • у них не было полномочий навязывать процесс.

Вывод: нужна внутренняя модель распространения компетенций через лидов доменов.

3) Новая стратегия: Domain Competence Leads (“лиды компетенций”)

Компания ввела роли экспертов доменов (competence leads):

  • их легче обучать (они знают процесс),
  • они обучают других внутри компании,
  • это не “пилот ради пилота”, а встроенное изменение процесса.

Параллельно руководство проходит обучение через понимание процесса (тестировали на себе): доверие к экспертам вместо веры “из презентаций”.

4) Обновление форматов артефактов (вход в AI-разработку)

Раньше использовались “старые” корпоративные форматы (например, документы в Confluence). Их заменили на более подходящие AI входные артефакты (например, JSON/use cases как эффективнее для AI).

Принцип: формат артефакта задает человек, который “передает эстафету” дальше — из‑за изменения способа работы с информацией.

5) Инфраструктура и безопасность: controlled internal contour

Переход от практики “люди запускают агентов у себя на машине”.

Построили контролируемый контур:

  • агенты запускаются внутри изолированной инфраструктуры (упоминаются VM → Kubernetes),
  • логирование действий агентов,
  • ограничение и контроль доступа.

Внешние агенты возможны для “нечувствительных” задач (например, код без уязвимостей), но данные/секреты — внутри.

6) Выстраивание PDLC/SDLC стандартов

Стандарты компании начали формировать как PDLC (упоминается эволюция SDLC и процесс с учетом AI).

Стандарты должны учитывать работу и агента, и человека.

7) Метрики: “ускорение инструмента ≠ ускорение бизнеса”

Пилоты мерили локально → казалось “быстро”. В масштабе начали мерить end-to-end:

  • время от начала до поставки ценности для бизнеса сократилось в среднем примерно до 50% (диапазон зависит от стека),
  • стоимость и число людей не обязательно уменьшаются, но меняются роли.

Важно оптимизировать не “цикл разработки” сам по себе, а time to market.

8) Идея о KPIs/стоимости и будущих ограничениях

  • При росте цен на API/токены возможен стресс по стоимости (сейчас подписка “субсидирует”).
  • Обсуждается локальный inference и железо: компромиссы по цене/безопасности/контролю.
  • Прагматичный подход: часть задач можно делать локально/на более маленьких моделях, но корпоративная безопасность ограничивает “полную свободу”.

Финальная часть: практические препятствия и ответы на вопросы

  • Самый трудный компонент — не “инструменты”, а change management людей:
    • сопротивление не всегда “луддиты”, но аргумент часто “у нас и так 20 лет работало” + страх отключения интернета/необходимости нового процесса.
  • Были препятствия с доступами со стороны админов/контроля доступа (вплоть до необходимости “подписаний”).
  • Подчеркивается: обязательность testing/инженерных практик — вопрос инженерии, а не “веры”.
  • Про IT-замещение: при переходе на AI массовых сокращений не было; роли скорее меняются:
    • из “писателя кода” в “уточняющего требования/процесс” и “думающего”.

Ключевые продукты/подходы, упомянутые в тексте

  • OpenSpec/Specs & Changes: версияционный контракт + “компиляция” в код; артефакты в Git.
  • Planmod (планирование до кода): итерации план → review → код, но план может быть сессионным артефактом.
  • TDD для агентов:
    • тесты до кода (против priming),
    • reviewer/subagent с другой ролью/промптом,
    • feedback loop в pipeline.
  • Agent workflow в компании:
    • controlled internal contour (VM/Kubernetes),
    • domain competence leads,
    • обновление входных форматов (JSON/use cases),
    • стандарты PDLC/SDLC.

Основные спикеры / источники

  1. Edgar Stipki — доклад про SD/спецификации, эволюцию от planmod к OpenSpec и проблему намерений/контекста.
  2. Gleb Kudryavtsev — доклад про TDD для агентной разработки и приминг-эффект.
  3. Zhenya Simonovich (Evgeny Simonovich) — внедрение AI/агентов в бизнес-процесс, метрики, безопасность, компетентностные лиды, PDLC/SDLC стандартизация.

Original video