AI-SDLC: язык спецификаций для границ между людьми и агентами

AI-агенты теперь работают как первоклассные члены команды в SDLC (software development lifecycle), но нет формального языка для описания границ между человеком и агентом, approval points и governance-констрейнтов. Существующие подходы кодируют процесс в промпты (дрейфует), нацелены на смежные области (workflow, BPMN) или адресуют фрагменты (access control). Авторы предложили DSL с формальной синтаксисом, условиями well-formedness, операционной семантикой и enforcement-инвариантами. Язык разделяет policy (декларативное намерение) от mechanism (структурное enforcement). Три результата: (1) структурное enforcement ограничивает failure rate произведением агента и валидатора; (2) паттерн "2+N team" (два человека in control + N специализированных агентов) формализует классическое Separation of Duties для AI-SDLC; (3) Kleene closure и рефлексивная протокол-валидация становятся свойствами дизайна, не ad-hoc конструктами.
Ключевые факты
- DSL для AI-SDLC с формальной синтаксисом, семантикой и enforcement инвариантами
- Разделяет policy (намерение) от mechanism (структурная гарантия)
- Failure rate ограничена произведением агент-rate × валидатор-rate при структурном enforcement
- Паттерн 2+N team: двое людей in control + N специализированных агентов (формализирует Separation of Duties)
- Kleene closure и reflexive validation возникают как свойства, не edge-cases
Почему это важно
По мере того как AI-агенты выполняют критичные шаги в разработке (code generation, deployment, security review), нужна формальная гарантия, что человек остаётся в контроле. Промпты дрейфуют, workflow-tools не дизайнены для AI. Эта работа впервые предлагает формальный язык с гарантиями, proof что можно гарантировать failure-rate через структуру, а не надежду на промпт.
Кому это важно
Авторам AI-agential фреймворков (Anthropic Agents, MetaGPT, CrewAI); Infra-инженерам, деплоящим CI/CD с AI-агентами; компаниям, требующим SOC2/ISO27001 compliance; исследователям AI safety и alignment.
Как это применить
Если вы разрабатываете систему, где AI-агент принимает решения (deployment, security review, code commit), используйте DSL описать процесс: какие действия требуют human-approval, какие могут делать агенты, какие validation-шаги. Проверяйте инварианты (failure-rate ограничена). Для open-source инструментов: интегрируйте синтаксис AI-SDLC в Terraform, GitHub Actions или собственные CI-системы. Паттерн 2+N: всегда имейте двух людей для critical decisions, остальное может быть automated.
Можно ли доверять
arXiv-статья с formalization (formal syntax, operational semantics, enforcement invariants), working implementation и анализом failure rates. Авторы позиционируют вклад как интеграцию primitives (validation tokens, capability boundaries), а не single innovation. Однако статья ещё не в конференции, empirical evaluation обозначена как future work.
Риски и подводные камни
DSL может быть сложен для быстрого adopt, require training. Enforcement инварианты предполагают, что агент и валидатор независимы, в реальности они могут иметь общие failure modes. Kleene closure и reflexive validation, абстрактные концепции, их practical implementation не ясна из статьи. Язык может быть over-engineered для simple cases ("агент пишет код, человек merge").
«Existing approaches encode process in agent prompts (subject to drift), target adjacent domains (workflow management, business processes), or address only fragments (access control, approval gates).»
— Авторы статьи