AMA-сессия #3 про AI-Assisted Engineering

Корпоративные правила, список разрешённых инструментов и шлюз к моделям дают инфраструктуру, но не меняют способ работы сами по себе. Система появляется, когда рядом есть доверенные практики, способные показать пример, а задача получает явный контракт: входные данные, ожидаемый результат и обязательные проверки. Наблюдение за pull request показывает реальное поведение. Если одна команда меняет восемь тысяч строк, а другая сорок тысяч для похожей цели, искать причину стоит и в постановке, режиме делегирования и критериях завершения, а не только в модели.

Shadow AI в таком контуре служит диагностическим сигналом: разработчикам может не хватать подходящей модели, бюджета или прав на полезный инструмент. Вместо одной лишь борьбы с обходами нужно понять потребность и по возможности легализовать безопасный путь. Requirement ledger может дополнительно фиксировать исходные и уточнённые требования, их реализацию, проверку и забытые пункты. Однако он пересекается с функциональными требованиями, NFR и ADR, поэтому для зрелой обвязки независимый проверяющий агент, запускаемый по событию или расписанию, может оказаться полезнее ещё одного постоянного документа.

Токены, объём кода, лицензии и скорость инженера не доказывают отдачу. Оценивать нужно команду и продукт: lead time, cycle time и time-to-market вместе с DORA-сигналами качества и долей переделок. Среднее скрывает неравномерность: AI ускоряет команды по-разному, поэтому важны распределения. Алексей отмечает, что ему часто встречается статистика примерно на сорок процентов большего числа возвратов из QA; в одном аудите он видел больше возвратов и более долгие исправления. Это диагностические наблюдения, а не универсальный отраслевой норматив.

Освободившееся время ещё не является экономией. Оно должно перейти либо в дополнительную ценную поставку, которая быстрее приносит выручку или рост, либо в способность поддерживать тот же сервис с меньшей базой затрат. Только тогда эффект доходит до P&L; в крупной компании внутренние стимулы нередко мешают такому перенаправлению. Поэтому AI-native operating model стоит продавать через стратегическую срочность. Традиционному бизнесу может хватить точечных помощников, новому GenAI-продукту скорость нужна для выживания, а комфортный лидер рынка способен признать идею и всё равно утопить её в комитетах.

GitHub Spec Kit и OpenSpec отвечают на разные формы работы. Spec Kit ведёт новую или изолированную функцию через constitution, specification, clarification, plan, tasks и implementation; в долгоживущей связной системе его приходится заметно адаптировать. OpenSpec организует изменение существующей базы через исследование, предложение, применение и проверку, поэтому ближе к brownfield-разработке и дельтам. Ни один подход не стоит превращать в обязательную религию: методологии образуют набор инструментов, который команда комбинирует под домен и задачу. Сравнение нескольких методов помогает увидеть варианты, о существовании которых нельзя догадаться по одному уверенному ответу LLM.

В greenfield-проекте контур начинается с инженерных свидетельств: ADR, архитектурного каркаса, CI/CD, тестов, линтеров, fitness functions и других детерминированных проверок. Недетерминированные evals добавляются поверх них, а человек сначала просматривает отчёты и предлагаемые исправления. Чем больше автономность, тем важнее зафиксированные бизнес-инварианты. Фоновый агент однажды «починил» сломанную рассылку, просто выключив её feature flag, и пропажа обнаружилась через две недели. В production безопаснее ограниченные изменения конфигурации через GitOps, проверяемые pull request и контроллер развёртывания, чем широкие административные права для агента.