Построение систем, пригодных для агентов

Image generated by Google Gemini

Если ИИ-агент сломал ваше приложение при рефакторинге, если вы хотите превратить legacy-системы в среду, где ИИ может работать, если хотите перенаправить бюджеты Fortune 500 с обслуживания legacy на бюджеты трансформации — эта статья и есть дорожная карта.

Запертая память

В эпоху пузыря доткомов корпорации начали накапливать цифровые активы. Код, базы данных, спецификации, документы, API — корпоративная память, копившаяся десятилетиями.

Эта память была заперта. Недоступна для поиска, непроверяема, недостижима (unreachable). Единственный способ — человек читает, человек понимает, человек правит вручную. Поэтому 60–80% IT-бюджетов Fortune 500 тратится на поддержание этой запертой памяти. Открыть не могут — просто охраняют.

Сейчас мы в разгаре того, что называют пузырём ИИ. Настоящий смысл этой эпохи не в том, что модели становятся умнее. Долго запертая legacy-память корпораций начинает переходить в достижимое (reachable) состояние.

Но пока ещё нет. 2026 год, ИИ-агенты пишут код. Один сжигает миллионы токенов за 68 минут, завершает рефакторинг. Приложение полностью сломано. Такие истории появляются в X каждый день.

Почему это повторяется?

Не потому что агент глуп. Потому что среда не приспособлена для работы агентов. Нельзя ставить робота в человеческий офис. Нужно построить фабрику, где робот сможет работать.

Чтобы открыть запертую память, она сначала должна принять форму, которую можно открыть. Это не только проблема кода. Базы данных, спецификации, документы, API — все цифровые активы предприятия непрозрачны для агентов.

Что такое Agent-Operable

Чтобы агент работал автономно, нужны три условия:

1. Должно быть читаемо — без шума

Чтобы найти одну функцию в файле на 2 000 строк, 1 950 строк — шум. Чтобы найти данные клиента в ненормализованной БД, нужно джойнить три таблицы. Бизнес-правила, спрятанные в Excel, для агента невидимы.

Читаемо — не значит человек может прочитать. Значит машина может структурно распарсить.

2. Должно быть верифицируемо — детерминированно

Если агент не может определить, что сломалось после изменения, он попадает в doom loop. Коду нужны тесты. Базам данных нужны ограничения. API нужна schema validation. Спецификациям нужна перекрёстная проверка.

Когда LLM проверяет LLM — это как спрашивать пьяного друга: «Я пьяный?» go test не галлюцинирует. Ограничение CHECK не врёт. JSON Schema не дрейфует.

3. Состояние должно сохраняться — даже когда агент умирает

Агенты обязательно падают. Лимит токенов, сетевые ошибки, обрыв сессии. Если прогресс не сохраняется, каждый запуск начинается с нуля.

Когда Агент A обработал до функции #200 и умер, Агент B должен продолжить с #201. Агенты одноразовые. Прогресс должен накапливаться.

Шаг ноль: заморозьте баги

Три условия — это пункт назначения. Точка старта другая. Нет документации, нет тестов, 300 файлов по 2 000 строк. Это точка старта.

Скажите агенту «отрефактори это» в таком состоянии — что произойдёт? Он «починит» десятилетний баг. Проблема в том, что этот баг — не баг.

Hyrum’s Law: у каждого наблюдаемого поведения достаточно старого API есть кто-то, кто от него зависит. Ошибка округления, оставленная на десять лет, привязана к платёжной логике VIP-клиента. Баг парсинга дат породил Excel-макрос, на котором держится весь бухгалтерский отдел. Старые баги — это неявные бизнес-спецификации.

Первая задача агента — не чинить код. А заморозить текущее поведение.

Ткнуть API. Записать ответ. Зафиксировать этот ответ как Hurl-тест. Странный баг или намеренное поведение — без различия. Заморозить как есть. Это первый зубец ratchet — он блокирует агенту возможность «улучшать» что-либо самовольно.

Изменения решает только тот, кто владеет спецификацией. Агент — исполнитель. Не судья.

Когда заморозка завершена, начинается переход к трём условиям — читаемость, верифицируемость, персистентность.

Не только код

«Agent-operable codebase» — это отправная точка. Цифровые активы корпорации — это не только код.

По отдельности каждая строка выглядит как «надо бы навести порядок». Вместе — это система.

Symbolic Feedback Loop

Есть общая структура, делающая этот переход возможным.

LLM генерирует → детерминированный инструмент судит → результат возвращается LLM → повтор

В коде, в тестах, в спецификациях, в данных — работает один и тот же цикл:

Структура кода:      filefunc validate → фидбек о нарушении → LLM исправляет → повтор
Тесты:               go test + coverage → фидбек о непокрытых строках → LLM дополняет → повтор
Консистентность:     yongol check → фидбек о drift → LLM исправляет → повтор
Пользовательские правила: rulecat evaluate → фидбек о нарушении → LLM исправляет → повтор

LLM участвует только в генерации. Что исправлять, прошло ли, что дальше, закончено ли — всё решают машины. LLM не получает права принимать решения.

Это не изобретение. C. elegans выделяет 60 из 302 нейронов (20%) на сенсорный вход. На верификацию, а не на генерацию. Пятьсот миллионов лет эволюции пришли к выводу: повышение качества обратной связи выгоднее для выживания, чем наращивание нейронов.

Индустрия делает поезд (модель) быстрее. Модели больше, агенты умнее, промпты лучше. Но чем быстрее поезд, тем важнее рельсы.

80/20

В конечном состоянии система делится на два слоя.

SSOT (80–90%)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── Генерируется из спецификаций. Drift устранён в источнике. Агенты модифицируют свободно.

Custom (10–20%)
├── Бизнес-правила, доменная логика, юридические/политические расчёты
└── Структурировано filefunc, протестировано tsma. Ревью — людьми.

Код, за которым людям действительно нужно следить, сжимается до 10–20%. Остальное генерируется агентами по спецификациям, верифицируется машинами.

60% Fortune 500

60–80% IT-бюджетов Fortune 500 тратится на поддержку legacy. 42% времени разработчиков уходит на технический долг. 70% ручных legacy-миграций проваливаются.

Этот бюджет уже тратится. Новый бюджет не нужен. Достаточно сменить направление. Превратить бюджет на поддержку в бюджет на трансформацию.

Загрузите legacy целиком — на выходе agent-operable система. Это обещание Building Agent-Operable Systems.

Почему Big Tech этого не делает

Anthropic и OpenAI строят модели общего назначения. Улучши модель на 10% — это применимо ко всем клиентам. Но сделай Go test feedback loop — и это только для Go-разработчиков. Сделай инструмент coverage для Python — и это только для Python-проектов.

Символическая верификация по своей природе доменно-специфична. Каждый язык, каждый фреймворк, каждая спецификация требует свой верификатор. Нет универсальности — значит не вписывается в ROI Big Tech.

Поэтому это место пустует. Те, кто строит поезд, и те, кто прокладывает рельсы, — не конкуренты. Они дополняют друг друга.

Вопросы

Ваш агент пишет код. Но кто проверяет, правильный ли этот код?

Другой агент? Или go test?

Ваш LLM действительно читает все 100 000 строк?

Или делает вид?

Эпохе агентов нужны не более умные агенты. Нужны системы, в которых агенты могут работать.

Sources

• Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
• Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
• McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
• Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
• Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
• White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
• Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
• METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
• GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
• Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks