Продолжаем кидаться помидорами в ИИшечку. Хотя, если честно, живого разработчика я бы своими запросами, наверное, тоже уже довёл до нервного тика. 😁
История простая. У меня есть собственная операционная система для управления проектами и публикациями, построенная вокруг Codex. И есть небольшая проблема: Codex не всегда может нормально работать через браузер с некоторыми российскими соцсетями.
Ну и я, естественно, начал пытаться это исправить. Давай попробуем так, давай через планировщик, давай другой маршрут, давай ещё что-нибудь придумаем. В общем, долго и упорно бодались с агентом, пока я не полез смотреть, что он там в итоге написал.
А там меня ждало прекрасное:
export function requireDzen1002Action(operation: Dzen1002Action): void {
if (!['inventory', 'publish', 'readback'].includes(operation))
throw new Error('[DZEN1002_ACTION_INVALID]');
throw new Error(
`[DZEN1002_ACTION_SCOPE_UNRESOLVED] Local applicability to ${operation} is unresolved; recorded refusal concerns opening task1045 article. No native action attempted.`
);
}
Вы только вдумайтесь.
Агент создал отдельную функцию, в названии которой зашиты конкретная платформа и номер задачи публикации. Причём не номер задачи на разработку функциональности, а идентификатор конкретной публикации, с которой у нас возникли проблемы.
И самое прекрасное — функция вообще ничего полезного не делает. Она проверяет допустимость операции, после чего в любом случае выбрасывает исключение.
То есть вместо решения общей проблемы с интеграцией мы получили персональный памятник одной неудачной попытке. Практически мемориальную табличку прямо в кодовой базе. 😁
И ладно бы это был единственный такой случай. Но, покопавшись дальше, я нашёл ещё несколько похожих решений.
А ведь у меня уже есть спецификации, архитектурные правила, тесты, отдельные агенты для проверки и вся остальная обвязка, которой я регулярно хвастаюсь.
И всё равно подобная шляпа каким-то образом просочилась в код.
Справедливости ради, сама по себе функция может быть следствием попытки безопасно заблокировать неподтверждённое действие. Но даже в таком случае непонятно, зачем превращать временную проблему конкретной публикации в постоянную часть архитектуры.
Для меня это очередное напоминание, что наличие harness и quality gates ещё не гарантирует качество инженерных решений. Можно прекрасно проходить формальные проверки и одновременно постепенно превращать кодовую базу в музей локальных костылей.
Так что теперь добавляю ещё один пункт в свои регулярные архитектурные ревью: проверять, не начали ли агенты превращать идентификаторы задач, временные ограничения и разовые исключения в постоянную бизнес-логику.
Потому что сегодня это requireDzen1002Action, а завтра, глядишь, появится pleaseDoNotBreakProductionAgainFinalV3. 😁
А вам агенты уже оставляли подобные архитектурные сувениры? Делитесь, хочется понять, насколько богатую коллекцию можно собрать.
Дискуссия