Инженерия агентов в пяти уровнях: от спецификаций и параллельных агентов до правил и контроля
Карпаты назвал этот процесс кодированием атмосферы смены. Рассмотрим пять уровней инженерии агентов: спецификации, оркестрация, кодифицированные правила, человеческий аудит и возможность наблюдения, плюс план на неделю.
Подход вайб-кодинга имел успех. Андрей Карпати, человек, введший этот термин, заявил о завершении той эпохи; он не только определил проблему, но и нарисовал картину того, что может её заменить: агентное инжиниринг, при котором ИИ-агенты планируют, пишут, тестируют и выпускают код, в то время как человек осуществляет структурированный контроль. Человек задаёт цель, агенты её выполняют, а человек проверяет результат. Это профессиональный метод создания программ с использованием ИИ, а не просто его использование параллельно, и он сильно отличается от случайных запросов, сопровождаемых надеждами.
Ранние попытки внедрения подхода к разработке, основанного на спецификациях, то есть записи того, что должна делать система до того, как любой агент начнёт её создавать, оказались эффективными лишь для одного уровня этой дисциплины. С тех пор команды, работающие в производственных условиях, добавили ещё четыре уровня. Далее описаны все пять уровней, показано, как они выглядят на практике, и приведен план занятий продолжительностью в неделю для начинающих.
Почему важно название
Этот термин — это не просто брендинг. Он обозначает границу между двумя совершенно разными способами работы, и Карпати провёл эту границу с помощью пары вопросов. При подходе Vibe coding задаётся вопрос о том, можно ли заставить что-то работать. При подходе Agentic engineering задаётся вопрос о том, можно ли заставить что-то работать надёжно в масштабах, не создавая при этом уязвимостей.
Первый вопрос снимает ограничения. Теперь любой может создать прототип: человек, занимающийся разработкой в выходные, описывает свои требования, принимает полученный результат и в итоге получает рабочую демо-версию. Это действительно полезно для исследований. Второй вопрос устанавливает ограничения. Программное обеспечение, обрабатывающее платежи, управляющее медицинскими данными или обеспечивающее работу инфраструктуры, по-прежнему требует профессиональной дисциплины. Код может написать автомат, но человек должен спроектировать систему, определить её границы и проверить результаты работы.
Сам Карпати выразился прямо: инженерия агентов — это отдельная инженерная дисциплина, причем агенты являются нестабильными, стохастическими и чрезвычайно мощными, поэтому настоящая проблема заключается в координации их действий для ускорения без снижения качества. Эта проблема — скорость без жертвы качеством — сейчас является ключевым вопросом этой области. Это не только его мнение. IBM, Forrester и Anthropic каждая в том же квартале опубликовали формальные рамки для новой дисциплины, придя к этому независимо друг от друга. Когда организации, которые редко сходятся во мнениях, приходят к одному выводу в один и тот же момент, у идеи появляется весомость.
Этот термин закрепился, потому что инженерам нужно было название для работы, которую они уже выполняли: более структурированная, чем простое задание, более дисциплинированная, чем кодирование на основе атмосферы, но при этом отличающаяся от традиционной разработки. Дисциплина, которую он описывает, имеет пять уровней, причем каждый из них основан на уровне ниже. Если пропустить хотя бы один уровень, вся структура становится ненадежной.
Уровень 1: спецификация
Напишите спецификацию до того, как агент начнет генерировать код. Укажите, что система должна делать всегда, чего делать никогда не должна, как определить, что она работает, и как понять, что она остановилась. Все это следует поместить в один документ, постоянно обновлять его и оценивать все, что создает агент, по этим критериям.
В инженерии искусственного интеллекта это называют стратегическим планированием, определением целей или просто спецификацией. Название может различаться, но сам процесс остается прежним: необходимо знать, чего хотят, прежде чем просить агента это создать.
Есть один момент, который легко упустить. Техническое описание — это не документ, созданный в день запуска. Это динамический документ. Каждый раз, когда реализация выявляет что-то, чего не предусматривало описание, и такое обычно происходит, описание обновляется. Команды, чьи сотрудники постепенно отходят от первоначальных намерений, почти всегда — это те команды, которые написали описание с самого начала и больше никогда его не открывали.
Минимальный шаблон начинается с заголовка, в котором указывается, что данный документ является источником истины:
# Feature Spec: [Feature Name]
## Last updated: [Date] — this document is the source of truth
Затем следуют чек-листы поведения: раздел с требуемыми действиями и раздел с строгими ограничениями, например, запрет на обработку возвратов суммой свыше 500 долларов без одобрения человека:
## What this must always do
- [ ] [Behaviour 1 — specific, testable]
- [ ] [Behaviour 2 — specific, testable]## What this must never do
- [ ] [Boundary 1 — e.g. "Never process refund >$500 without human approval"]
- [ ] [Boundary 2 — e.g. "Never fabricate a citation"]## Success criteria (measurable)
- Context recall: >0.85
- Faithfulness: >0.90
- Cost per query: <$0.15
- Latency p95: <2s## Failure signals (alert if breached)
- Any metric drops >5% from 7-day baseline
- Cost per task exceeds 3x expected range
- User complaint rate exceeds 2% of sessions## Decomposition (for parallel agents)
- [ ] Task A: [scope] — can be delegated independently
- [ ] Task B: [scope] — depends on Task A output
- [ ] Task C: [scope] — can run parallel with Task A
Сохраняйте описание в пределах одной страницы. Если объем спецификации превышает этот лимит, функция слишком обширна и её следует разделить на части, чтобы каждая из них помещалась в одну страницу.
Даже идеальная спецификация, переданная одному инженеру, сталкивается с ограничениями по скорости обработки, поэтому и существует второй уровень.
Уровень 2: оркестрация
Рассмотрим функцию, которая влияет на схему базы данных, API, фронтенд и набор тестов. Традиционно один инженер работает над каждой частью по отдельности или команда координирует свои усилия в течение спринта. В подходе с агентами четыре агента одновременно занимаются всеми четырьмя аспектами: один пишет код миграции, другой — эндпоинты, третий — компоненты фронтенда, а четвертый пишет тесты и проверяет остальные части на наличие проблем с безопасностью. У каждого агента есть свой контекст и ограничения, а их результаты объединяются в единое целостное изменение.
Это не гипотетический пример. Stripe использует такую схему в реальных условиях: у них есть внутренняя система агентов, которая еженедельно генерирует более 1 000 объединённых запросов на внесение изменений, каждый из которых пишется агентом, проверяется человеком, проходит тестирование и внедряется. Результат — порядок величины, а не просто удвоение.
Этот процесс представляет собой цикл, повторяющийся для каждой функции: планирование, выполнение, проверка. Некоторые команды называют его циклом PEV.
- Планирование. Человек составляет спецификацию на основе первого уровня и делит работу на независимые задачи, которые можно поручить другим. Важное решение здесь — определить, какие задачи могут выполняться параллельно, поскольку они не зависят от результатов друг друга, а какие должны выполняться по порядку.
То, что раньше требовало двухнедельного срока, теперь решается за несколько часов или день сосредоточенной работы. Усилия человека в основном направлены на планирование и проверку, в то время как агенты выполняют основную работу между ними.
Чтобы освоить эту нюанс, требуется время: цель — полезный параллелизм, а не максимальный. Три агента на тесно связанных модулях приводят к конфликтам, решение которых стоит дороже, чем экономия от параллельной работы. Два агента на независимых модулях при участии третьего, контролирующего оба, дают согласованный результат. Секрет заключается в разбиении задач на части так, чтобы их можно было делегировать без последующих проблем с интеграцией.
Основной оркестратор может указать этот цикл в своем документировании:
class AgenticOrchestrator:
"""Plan → Execute (parallel) → Verify"""
и выполнять шаг планирования, при котором функция разделяется на задачи, которые можно поручить другим:
def plan(self, feature_spec: dict) -> dict:
"""Decompose feature into independently delegatable tasks."""
tasks = []
for component in feature_spec["decomposition"]:
tasks.append({
"id": component["id"],
"spec": component["scope"],
"constraints": feature_spec["must_never"] + component.get("local_rules", []),
"depends_on": component.get("depends_on", []),
"verification": component.get("success_criteria", []),
})
independent = [t for t in tasks if not t["depends_on"]]
sequential = [t for t in tasks if t["depends_on"]]
return {"parallel": independent, "sequential": sequential} async def execute(self, plan: dict):
"""Run independent tasks in parallel, sequential tasks in order."""
parallel_results = await asyncio.gather(*[
self.delegate_to_agent(task) for task in plan["parallel"]
])
for task in plan["sequential"]:
result = await self.delegate_to_agent(task, prior=parallel_results)
parallel_results.append(result)
return parallel_results def verify(self, results: list, spec: dict) -> dict:
"""Check all outputs against the spec — structural, not line-by-line."""
issues = []
for result in results:
if not self.satisfies_spec(result, spec):
issues.append(f"{result['id']}: does not satisfy spec")
if self.conflicts_with(result, results):
issues.append(f"{result['id']}: conflicts with another module")
return {"passed": len(issues) == 0, "issues": issues}
Основным принципом является строгое ограничение контекста. Каждый агент должен получать только свою секцию спецификации, файлы кода и правила. Загружение всей базы кода в каждое окно контекста тратит ресурсы, увеличивает затраты и снижает способность модели к концентрации.
Оркестрация обеспечивает высокую производительность, но производительность без единообразия приводит к хаосу. Каждый агент должен знать стандарты команды, архитектурные ограничения и политики безопасности, а также спецификации своей задачи. Следующий уровень обеспечивает предоставление этой информации.
Уровень 3: кодифицированные правила
У большинства инструментов уже существует аналог этого подхода. Claude Code загружает файл CLAUDE.md в начале каждой сессии, Cursor читает файл .cursorrules, а Codex — AGENTS.md. Концепция одинакова: файл в корне проекта, который указывает агенту, как ему действовать.
В 2026 году команды пошли ещё дальше и закодировали всю свою культуру разработки в виде ограничений, понятных агентам, выходя за рамки технологического стека. Такие специалисты, как Пол Дювалл, документируют шаблоны, возникающие в командах, работающих по принципам агентного инжиниринга, а InfoQ отслеживает уровень их зрелости. Четыре шаблона постоянно встречаются там, где применяется агентный инжиниринг:
- Разработка, основанная на спецификациях: спецификации определяют ход работы (уровень 1).
- Кодифицированные правила и архитектурные ограничения: конвенции, политики безопасности, шаблоны обработки ошибок, стандарты номенклатуры и процедуры развертывания — всё это хранится в файлах, которые агенты загружают перед началом работы.
- Атомарное разделение с использованием параллельных агентов: функции делятся на самые мелкие части, которые можно передавать для обработки независимо друг от друга (уровень 2).
Масштаб — вот где большинство команд сталкиваются с трудностями. Один файл CLAUDE.md хорошо подходит для прототипа из 1 000 строк. Базу кода из 100 000 строк невозможно описать в одном файле, и даже если бы это было возможно, правила заняли бы всё пространство для хранения контекста до того, как агент сможет выполнить реальную задачу.
Команды, которые решают эту проблему, создают иерархические системы правил, подобно тому как конфигурации ESLint наследуются от организационных настроек и могут быть переопределены для каждого проекта. Структура папок выглядит следующим образом:
your-company/
├── .ai-rules/
│ └── org-rules.md ← Company-wide: security, compliance, style
│
├── team-payments/
│ ├── .ai-rules/
│ │ └── team-rules.md ← Team-level: error handling, testing, deploys
│ │
│ ├── service-checkout/
│ │ ├── CLAUDE.md ← Repo-level: architecture, tech stack, builds
│ │ ├── src/
│ │ │ ├── auth/
│ │ │ │ └── .ai-rules.md ← Module: auth-specific constraints
│ │ │ └── payments/
│ │ │ └── .ai-rules.md ← Module: PCI compliance rules
В верхней части находится файл организации, загружаемый для каждого агента в каждом репозитории. В нем описаны такие правила, как запрет на сохранение секретов, требование аутентификации для публичных API и запрет на отображение стек-трейсов в ответах на ошибки:
# org-rules.md (loaded for every agent, every repo)
- Never commit secrets or credentials
- All public APIs require authentication
- Error responses must never expose stack traces
- Log every state-changing operation with user context
Под ним файл команды наследует эти правила и добавляет собственные, такие как использование шаблона Result вместо выбрасывания исключений, весь доступ к базе данных через слой репозитория, а также тесты, охватывающие успешный сценарий работы и по меньшей мере два сценария сбоя:
# team-rules.md (inherits org, adds team specifics)
- Use Result<T, E> pattern — never throw exceptions
- All database queries go through the repository layer
- Tests must cover the happy path + 2 failure modes minimum# CLAUDE.md (inherits team, adds repo specifics)
- This repo uses Express.js + Prisma + PostgreSQL
- Run `npm test` before suggesting any PR is ready
- Migrations are append-only — never modify applied migrations# module .ai-rules.md (inherits repo, adds module specifics)
- auth/: All token operations must use constant-time comparison
- payments/: PCI DSS requires field-level encryption on card data
Агент загружает организационные правила, правила команды, файл CLAUDE.md репозитория и правила модуля, с которым он работает. Это позволяет сохранять контекст в узких рамках и без избыточности. Агент, отвечающий за модуль оплат, получает правила соответствия стандартам PCI, тогда как агент фронтенда их не получает, поскольку эти правила лишь потребуют ресурсов контекста без какой-либо пользы.
Правила определяют, как следует работать, но для генерации результата всё равно требуется человеческое суждение. Код может соответствовать всем конвенциям, но при этом быть архитектурно ошибочным, решая поставленную проблему таким образом, что возникает ещё более серьезная проблема в другом месте. Именно поэтому следующий уровень не является опциональным.
Уровень 4: человеческий надзор
Три слова описывают сформировавшуюся модель работы: делегировать, проверять, нести ответственность.
Делегирование. Передайте агенту четко определенную задачу с ясными ограничениями и позвольте ему работать. Не следует микроменеджерить процесс выполнения и не стоит наблюдать за тем, как он печатает. Спецификация и правила существуют для того, чтобы можно было доверять агенту в соблюдении их.
Проверка. Рассматривайте возвращаемый результат как пул-риквест от компетентного, но младшего инженера: быстрого, квалифицированного, но склонного к тонким ошибкам, которые заметит только тот, кто понимает всю систему в целом. Проверьте соответствие архитектуре и крайние случаи. Убедитесь, что спецификация соблюдена, что означает выполнение поставленной цели, а не просто прохождение тестов.
Ответственность. Человек несет ответственность за конечное качество. Агент выполнил работу, человек дал одобрение, и отказ в производственной среде является его ответственностью. Именно эта ответственность отличает инжиниринг с использованием агентов от кодирования без четкой ответственности, при котором никто не несет ответственности за результат.
Проблема действительно существует. Агенты генерируют код быстрее, чем люди успевают его проверить, и возникает соблазн снизить стандарты, чтобы поспевать за темпом. Именно из-за этого соблазна возник метод vibe coding: разработчики принимали результаты, потому что они казались корректными, проходили тесты, а сроки приближались. Инженерия агентов существует для того, чтобы предотвратить повторение такой практики.
В отчете Anthropic о тенденциях агентного программирования описывается, как опытные инженеры с этим справляются. Они делегируют задачи, корректность которых легко проверить с первого взгляда или у которых низкие риски. Чем сложнее задача с концептуальной точки зрения или чем больше она зависит от дизайна, тем вероятнее, что инженер оставит ее себе или будет работать над ней совместно с агентом. Умение определить, что можно передать, а что оставить себе, становится новой ключевой компетенцией. Она развивается только благодаря практике, не существует ускорений от каких-либо фреймворков или инструментов, и именно она отличает инженера, который эффективно использует агентов, от того, кто создает впечатляющие результаты, которые рушатся при детальном анализе.
Чек-лист для проверки помогает перед тем, как что-либо, сгенерированное агентом, попадет в производственную среду. Его заголовок:
## Agent Output Review Checklist
а его структура состоит из разделов, начинающихся с проверки соответствия спецификации (реализованы ли все обязательные функции, соблюдаются ли ограничения, выполняются ли критерии успеха), а затем идут разделы, посвящённые архитектуре и деловой целесообразности:
### Spec alignment (does it do what was asked?)
- [ ] All "must always do" behaviours are implemented
- [ ] No "must never do" boundaries are violated
- [ ] Success criteria from the spec are met or tested### Architectural coherence (does it fit the system?)
- [ ] No new dependencies introduced without justification
- [ ] Consistent with naming, patterns, and structure of existing code
- [ ] No duplication of logic that exists elsewhere### Safety and edge cases
- [ ] Error handling covers the failure modes the spec anticipated
- [ ] No hardcoded credentials, keys, or environment-specific values
- [ ] Input validation present on all external-facing boundaries### What the agent cannot check for itself
- [ ] Does this make business sense? (not just technical correctness)
Стоит распечатать его и прикрепить рядом с монитором. Инструменты для проверки кода и системы непрерывной интеграции могут частично автоматизировать первые три раздела. Однако последний аспект — понимание бизнес-сути — требует участия человека.
Проверки помогают выявить проблемы перед выпуском. Медленное ухудшение качества, тонкие регрессии и повышение затрат, которые никто не замечает до поступления счета, проявляются лишь позже, и для их устранения требуется последний уровень контроля.
Уровень 5: наблюдаемое развитие
Мониторинг и наблюдаемое развитие звучат похоже, но выполняют разные функции. Мониторинг показывает, что система работает, имеет нормальную задержку, мало ошибок и зеленую панель управления. Наблюдаемое развитие показывает, что именно сделала система: какой агент выполнил какую задачу, согласно какой спецификации, с использованием каких инструментов, был создан какой код и соответствует ли результат первоначальным целям.
Разница проявляется в 2 часа ночи. При использовании только мониторинга становится ясно, что что-то не так, но причина остаётся неизвестной, поэтому всю ночь приходится тратить на анализ различий и догадки относительно проблемных модулей. При использовании системы отслеживания процесса развертывания видно, что агент номер 3 изменил процедуру аутентификации в соответствии со спецификацией, которая игнорировала одновременное обновление токенов. Это позволяет провести двенадцать минут целенаправленной диагностики вместо двух часов угадываний.
На практике всё сводится к трём привычкам:
- Каждая задача агента создаёт структурированный отчёт: спецификация, которую он получил, инструменты, которые он использовал, файлы, которые он изменил, версия модели, потреблённые токены и результат проверки. Когда через три дня появляется баг, отчёт показывает, что произошло, и никому не нужно ничего запоминать.
Минимальная настройка начинается с импорта данных для небольшого файла логов:
from dataclasses import dataclass, field
from datetime import datetime
и класс данных trace, применяемый к каждой делегированной задаче:
@dataclass
class AgentTrace:
"""Minimum trace for every agent-delegated task."""
task_id: str
agent_id: str
spec_given: str # What was the agent told to do?
tools_used: list[str] # Which tools did it invoke?
files_modified: list[str] # What did it change?
model_version: str # Which model, which version?
tokens_consumed: int # What did it cost?
started_at: datetime = field(default_factory=datetime.utcnow)
completed_at: datetime | None = None
verification_result: str = "" # pass / fail / needs_review
human_reviewer: str = "" # Who signed off?
issues_found: list[str] = field(default_factory=list)
Добавьте еженедельный обзор продолжительностью пятнадцать минут. Заголовок для него:
## Weekly Observable Development Review (15 minutes)
и связанные с ним вопросы: сколько задач было делегировано, сколько из них прошли проверку с первой попытки (цель — более 80%), в какой категории было больше всего проблем и каковы три основные проблемы:
1. How many agent tasks were delegated this week? ___
2. How many passed verification on first attempt? ___ (target: >80%)
3. Which task category had the most issues? ___
4. Top 3 issues found during review:
- ___
- ___
- ___
5. Which issues should become codified rules (Layer 3)? ___→ Update CLAUDE.md with any new rules from this week's observations.
Пятнадцать минут в неделю достаточно, чтобы завершить цикл. Наблюдения превращаются в правила, правила улучшают организацию работы, лучшая организация приводит к лучшим результатам, а эти результаты порождают новые наблюдения.
Доказательства эффективности
Выделяются два показателя. Более 1 000 объединённых запросов на пул-реквесты в неделю в Stripe создаются автоматически, проходят проверку людьми, успешно проходят тесты CI и используются в реальных условиях — это не просто эксперимент в среде тестирования. Такой объём работы был невозможен годом ранее. Другие исследования показывают другие цифры: опрос McKinsey указывает на снижение операционных затрат на 20–40 процентов, что позволяет превратить ИИ из инновационной инициативы в часть операционной инфраструктуры, чего требует не только технический директор, но и финансовый директор.
Что это значит для карьеры инженера
Роль инженеров меняется, но не исчезает. В 2026 году они пишут меньше базового кода и тратят больше времени на управление агентами, проектирование архитектуры, определение целей и ограничений, а также на проверку результатов работы. Основная навык смещается от синтаксиса к системному мышлению — от вопросов о том, как написать функцию, к вопросам о том, как спроектировать систему, в которой агенты смогут её правильно написать.
Карпати расширил эту концепцию на процесс найма: стоит пропустить вопросы на разумение логики и поручить сложный проект, например создание защищённой копии Twitter, после чего попросить агентов попытаться её взломать, одновременно наблюдая, как кандидат работает с инструментами, техническими спецификациями и процедурами контроля. Это проверяет дисциплину, а не скорость набора текста.
В разговорах с руководителями инженерных отделов неоднократно упоминаются три ключевых компетенции:
- Уверенность в формулировке спецификаций. Написание спецификации, достаточно точной для того, чтобы агент мог её выполнить без двусмысленностей, сложнее, чем написание кода. У кода есть компилятор, который выявляет ошибки, тогда как у спецификации есть только интерпретация агента. Если спецификация нечеткая, агент с уверенностью выберет определенное толкование, будет развивать его и представит результат как именно то, что было запрошено.
- Способность к организации выполнения задач. Умение определить, что можно делегировать, а что оставить себе, когда полупараллельная работа полезна, а когда связь между компонентами слишком тесная, и когда результат требует тщательного анализа вместо простой структурной проверки. Это навык, сформированный в процессе сотен делегаций задач, каждая из которых показывает, что работает эффективно, а что вызывает проблемы с интеграцией.
Гергей Орош точно сформулировал это: есть что-то гораздо более важное, чем просто программирование, что делает инженеров особенными, и это заслуживает развития. То, что отличает инженеров в 2026 году, — это системы, которые они проектируют, спецификации, которые они пишут, их способность принимать решения по делегированию задач и стандарт качества, который они отказываются снижать. Именно сейчас эти навыки имеют ещё большую ценность, поскольку механическая реализация уже автоматизирована.
Пятидневный план для начинающих
Пять упражнений за неделю, каждое из которых строится на предыдущем:
- Понедельник: кодируйте знания команды. Напишите файл CLAUDE.md или .cursorrules для текущего проекта. Не включайте список технологий, а зафиксируйте правила работы: как обрабатываются ошибки, как структурируются тесты, как называются элементы, а также неписаные правила, которые каждый новичок должен усвоить с первого дня.
- Вторник: определите задачи и делегируйте их. Выберите одну функцию из списка задач с отложенной реализацией и составьте для неё спецификацию по шаблону: что она должна делать, чего не должна делать, критерии успеха и сигналы сбоя. Полностью делегируйте её выполнение агенту и отметьте время, затраченное на составление спецификации и её проверку. Это соотношение покажет, куда на самом деле идут усилия.
Одна неделя не сделает кого-либо инженером-агентом. Однако она позволяет понять, как выглядит эта дисциплина, и становится ли переход от написания кода к организации работы агентов источником энергии или её истощением. Оба ответа валидны, но полезно знать, какой из них верен.
Почему подход, основанный только на спецификациях, недостаточен
Рассматривать спецификацию как единственный источник ответов — писать согласно ей, следовать ей и проверять работу по ней — необходимо, но этого недостаточно. Спецификация является входными данными для системы оркестрации, а не самостоятельной практикой. Идеальная спецификация, переданная одному исполнителю, обеспечивает хороший результат. Однако та же спецификация, распределенная между пятью параллельными исполнителями, каждый из которых руководствуется зафиксированными правилами, подвергается структурированному контролю и отслеживается на протяжении всего процесса разработки, позволяет получить примерно в десять раз больше результата при том же качестве.
Уровень 4 также легко недооценивать. Спецификация описывает цель, а человек решает, была ли эта цель достигнута. Спецификация сама по себе не обеспечивает соблюдения правил, и этап её проверки требует столь же строгого соблюдения правил, как и сам процесс написания. Именно при проверке, а не в модели, фреймворке или инструментах, большинство команд начинают экономить средства, когда приближаются сроки.
Что дальше
Видны два направления: одно более вероятное, другое — спекулятивное.
Более вероятным является то, что агентные методы инженерии станут стандартным подходом в профессиональном разработке программного обеспечения примерно через 18 месяцев, не потому что все о них узнают, а из-за неотразимой экономической выгоды. Трое инженеров, использующих эти методы при наличии четких спецификаций, параллельной организации работы и строгого контроля, могут создать столько же результатов, сколько двенадцать человек, работающих традиционным способом. Когда расчеты настолько очевидны, дискуссии прекращаются.
Спекулятивным направлением являются агентные сети: сети агентов, координирующих свои действия и выполняющих целые рабочие процессы или бизнес-функции с минимальным участием людей. Некоторые команды уже проводят эксперименты. Остается неизвестным, сможет ли это решение сохранить эффективность в крупных предприятиях с уровнем надежности, характерным для корпоративных систем, поэтому к нему следует относиться с осторожностью и скептицизмом.
Не является спекуляцией тот факт, что роль инженера уже изменилась. Вопрос заключается в том, формируются ли компетенции новой роли — спецификация, оркестрация и верификация, или же работа по-прежнему ведется так, как будто основной задачей является написание кода. Раньше основной работой было ввод кода. Теперь же задача заключается в проектировании системы, которая его генерирует, и подтверждении того, что получившийся результат корректен.