Когда код можно заменить: что сохраняет систему

AI-инструменты уже распространены, но пользование ассистентом и автономная работа агента — разные вещи. Поломодов сопоставляет исследования, в которых рост числа изменений соседствует с ухудшением надёжности. Из них нельзя выбрать один универсальный множитель продуктивности: инструменты, выборки и способы измерения различаются. Если агент создаёт больше кода, чем команда успевает проверить, ограничение просто перемещается в чтение и приёмку. С другой стороны растёт потребность в подготовленных, действительно ценных задачах.

В прежней компании автора платформа складывалась из модельного шлюза, инструментального шлюза и труднее всего растущего реестра возможностей. Обернуть внутренние API в MCP недостаточно. Чтобы ответить, что происходило с сервисами за последний час, агенту нужны сведения о команде, сервисах, телеметрии, обязательствах и дежурствах. Без готовой возможности он заново собирает эту логику из разрозненных систем. Измерение тоже имеет три слоя: использование инструментов; поток и сэкономленные часы на инженерных задачах; экономический эффект. До измерения последнего на описываемом этапе ещё не дошли.

Центральная идея взята из Regenerative Software Чада Фаулера: если код становится дешёвым и регулярно заменяется, он перестаёт быть достаточным хранилищем знаний о системе. Намерение превращается в спецификацию и проверки, агент создаёт реализацию, а эксплуатация показывает, выполнено ли обещание. Проверка самой концепции проста: можно ли удалить компонент и восстановить его так, чтобы система сохранила нужное поведение? Речь идёт об ограниченной замене, для которой заранее определены границы и критерии.

Поломодов разбирает семь примитивов: намерение, компиляцию, оценки поведения, историю происхождения решений, темп изменений, удаление и упрощение. Компиляцию он интерпретирует через архитектуру: правила, по которым агент превращает замысел в систему. Остальные примитивы также опираются на знакомые практики. Их сочетание переносит идентичность системы из исходного кода в явно описанные обещания, ограничения и свидетельства того, что они выполнены.

Намерение описывает ожидаемый результат, область действия и причину требования. Например, деньги нельзя списывать за отсутствующий товар; платёж возможен после подтверждения остатков. Инструкция вызвать определённый метод скрывает это обещание за механизмом. В примере миграции старой системы в облачную платформу требование «соединение не должно рваться» оказалось связано с денежными операциями без идемпотентности. После обрыва нельзя было безопасно повторить запрос. Пока эта зависимость не была названа, спор о балансировщиках не затрагивал причину проблемы.

Архитектура фиксирует границы ответственности и допустимые связи, чтобы реализацию можно было менять предсказуемо. Название фреймворка этих решений не заменяет. Автор вспоминает систему, где микросервисы нарезали по сущностям домена: обычное изменение превратилось в распределённую транзакцию, а под нагрузкой решение быстро перестало работать. При генерации кода такие ошибки никуда не исчезают. Ограниченные контексты, архитектурные решения и проверяемые ограничения становятся условиями дальнейшей замены компонентов.

При миграции платформы A/B-тестирования переписали разделение трафика и расчёт результатов. Команда долго пыталась свести ответы новой и старой систем один в один. Сначала нашлись различия точности вычислений, затем выяснилось, что старые результаты сами менялись после пересборки витрин. Цель сравнения оказалась движущейся: точное совпадение с ней нельзя было гарантировать.

Приёмка потребовала согласовать достаточную точность и проверить контракты, инварианты, известные регрессии, скорость, отказы и безопасность; затем проверить изменение на ограниченной доле трафика. Юнит-тесты полезны для алгоритмов и структур данных, но не описывают всё обещанное системой поведение. Для заменяемой реализации нужны проверки, которые останутся осмысленными после переписывания внутренних деталей. Иначе новый код оценивается по случайным свойствам предшественника.

RFC, ADR, проектные документы и разборы инцидентов сохраняют причины выбора, альтернативы и контекст. По ним можно восстановить эволюцию системы и понять, какие прежние ограничения уже изменились. Для сгенерированного компонента полезна и цепочка происхождения: модель, запрос, спецификация и результаты проверок. Наличие этой информации помогает следующему изменению опираться на решения команды.

Документ, написанный агентом, всё равно требует содержательной проверки. Поломодов приводит пример инструкций, предлагающих автоматически создавать архитектурные диаграммы без шага проверки результата. Если автор не понимает стрелки и связи, аккуратное оформление превращает ADR в формальность. Агент ускоряет запись понятого решения; ответственность за смысл остаётся у инженера.

Эксперименты интерфейса и инфраструктура не должны обновляться с одинаковой скоростью. Поломодов связывает темп с зависимостями и обратимостью решения. Дешёвый откат позволяет быстро проверять гипотезы; изменение нижнего слоя с множеством потребителей требует более осторожной подготовки.

Пример — обновление Aerospike в системе аутентификации и авторизации. Совместимость проверяли, но при сетевом разделении новое поведение индексов привело к серьёзному сбою. Разбор инцидента затем помог обосновать изменение архитектуры. Дешевизна генерации кода не удешевляет автоматически проверку всех режимов отказа и последствий для зависимых систем.

Миграция завершена после вывода старого решения из эксплуатации. Новый сервис рядом со старым оставляет обязательства, данные и зависимости в двух местах. В одном примере CRM, созданная для замены Siebel, сама была заменена следующим решением, пока Siebel продолжал жить. Зависимости бывают и человеческими: после ухода сотрудника может выясниться, что только он знал обязательный шаг закрытия месяца.

Седьмой примитив, упрощение, удерживает систему понятной после нескольких циклов замены. Нужно сокращать устаревшие интерфейсы, конфигурации, флаги и зависимости, поддерживать актуальные проверки и понятия предметной области. Обсуждение замены Oracle на Cassandra показывает цену пропущенной работы: выбрать другую базу недостаточно, пока неизвестны обещания потребителям и реальные запросы. Иначе новые слои накапливаются, а команда теряет способность объяснить собственную систему.

Успешные команды превращали требования в контракты для агента, готовили контекст и использовали инструменты проверки. Простая передача номера задачи без изменения процесса давала гораздо менее убедительный результат. В рабочем дне становится больше формулирования намерения, критериев приёмки, координации параллельных агентов и проверки результата. Человек отвечает за поставку изменения и возможность развивать систему дальше.

Регенерация требует устойчивых границ, независимых проверок поведения и понятных ответственных. Перегенерировать всё приложение или просить «сделай такой же код, только лучше», не извлекая обещания системы, — антипаттерны. В финальном ответе на вопрос автор предполагает дальнейшее разделение труда: часть специалистов продолжит создавать сложные платформенные механизмы, большинство сможет работать ближе к продукту. Это прогноз, а не обещание исчезновения потребности в технической глубине.