Чтобы не стать заложником кода, написанного ИИ, нужно начать с изоляции архитектуры
TuBrief 편집팀
2026년 7월 7일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Скорость, с которой генеративный ИИ создает код, пугает. Однако настоящая проблема, с которой сталкиваются старшие инженеры и технические руководители, заключается в другом. Это когнитивная перегрузка, возникающая при попытке верифицировать код, созданный машиной за секунду, и интегрировать его в существующую систему. Отчет DORA 2025 от Google Cloud показывает, что внедрение ИИ увеличивает частоту развертывания, но вместе с тем повышает нестабильность системы. Это означает, что люди проводят ночи напролет, заделывая «синхолы», образовавшиеся из-за слепого копирования и вставки кода. Ручной метод, при котором человек поочередно читает и отлаживает код, не справляется с такой скоростью. Чтобы предотвратить превращение кода в «мусор», необходимо с самого начала создавать архитектурную среду, которая не доверяет логике, написанной ИИ, и автоматизировать процесс проверки.
Код, предложенный ИИ, не понимает бизнес-контекста. Даже если он выглядит безупречно, он часто нарушает тонкие правила предметной области. Поэтому к логике, написанной ИИ, следует относиться как к внешней системе, которая может выйти из строя в любой момент. Именно поэтому уже на этапе проектирования необходимо внедрять антикоррупционный уровень (Anti-Corruption Layer), определяющий четкие интерфейсы абстракции, чтобы предотвратить проникновение загрязнений в существующую доменную область.
Простого разделения программной архитектуры недостаточно. Существует постоянный риск того, что ИИ-код импортирует вредоносную библиотеку или нарушит работу локальной файловой системы. Кейс компании Stripe, которая при проектировании своей системы автономных агентов «Minions» изолировала процесс компиляции ИИ-кода внутри независимой виртуальной машины, отделенной от хоста, и заблокировала сетевой доступ на уровне протоколов, весьма показателен. Чтобы защитить производственную среду, необходимо внедрить средства контроля на уровне ядра внутри CI/CD-конвейера.
Необходимо построить среду выполнения с «нулевым доверием» (Zero Trust), которая не позволит недоверенному коду выйти за пределы контролируемой области. Эффект сокращения времени реагирования на сбои системы станет приятным дополнением.
Для разработчика опасно проверять сотни строк кода, выданных ИИ, собственными глазами. Когда мозг устает, срабатывает «предвзятость автоматизации», заставляющая просто пропускать код, который выглядит нормально. Дефекты в логике, созданной машиной, должны ловить не люди, а исполняемый тестовый код. Необходимо изменить последовательность действий: прежде чем давать ИИ команду написать код реализации, нужно заставить его создать тестовые случаи, определяющие спецификации работы. Это правило, требующее в первую очередь определить 5 категорий: нормальный поток, граничные условия, обработка исключений, ненормальный ввод и сценарии восстановления после сбоев.
Покрытие кода (line coverage), созданного с помощью ручного промптинга, обычно невысокое. Согласно операционным данным агентов DeepBlue, среднее покрытие тестами, полученное инженерами-людьми при общении с ИИ, составило всего 32%. Напротив, при использовании автоматизированных тестовых агентов, связывающих статический анализ исходного кода и сборку в рантайм-песочнице, без вмешательства человека удалось достичь 81% покрытия регрессионными тестами. Структура, в которой машина контролирует машину, работает гораздо эффективнее.
Для логики, где трудно провести сравнение выходных строк «один к одному» (например, результаты перевода естественного языка или динамические JSON-объекты), применяется техника LLM-as-a-Judge. В тестовую инфраструктуру внедряются фреймворки типа AgentProctor, а в модель оценки подаются шаблоны критериев. Если настроить модель оценки так, чтобы она количественно определяла, не нарушает ли возвращенный код ограничения безопасности, и установить «ограждения» (guardrails), блокирующие сборку при несоответствии стандартам, можно избавить людей от мучительного изучения «сырого» кода.
По мере роста объема кода, написанного машиной, в системе накапливается «когнитивный долг». Возникает странная ситуация: код работает, но никто не знает, почему именно так. ИИ-инструменты фокусируются только на решении локальных проблем, поэтому через несколько месяцев при рефакторинге всей системы выставляют огромный «счет». Чтобы сохранить проектный замысел, скрытый за кодовой базой, необходимо сделать процессом командного стандарта запись решений агента (Agent Decision Record). Это работа по фиксации в машиночитаемом формате причин выбора конкретной структуры и причин отказа от альтернатив.
Поскольку человеческой памяти доверять нельзя, в конвейер автоматизации нужно встроить фиксацию факта написания кода ИИ в историю коммитов. Использование инструментов типа библиотеки git-ai позволяет записывать примечания о вкладе агента в независимый метаданной путь refs/notes/ai, не загрязняя при этом тело сообщения коммита. Этапы построения Git-конвейера очевидны:
pre-commit hooks в локальной среде разработки и репозитории CI-сервера.AI-Footprint: model=gpt-4o, и информации о соавторе.Накопление метаданных таким образом позволяет в будущем в режиме реального времени получать статистику цепочки поставок: в какой версии ИИ-модели сконцентрированно создавались конкретные дефекты или уязвимости безопасности. Это предохранительное устройство, предотвращающее адскую ситуацию, когда из-за отсутствия документации по передаче дел приходится вручную разбирать десятки тысяч строк кода.
Если в очереди пулл-реквестов начинает скапливаться код, созданный без разбора, ручное ревью кода парализуется. Чтобы поддерживать продуктивность, процесс ревью нужно разделить на два потока: детерминированные шлюзы обратной связи, ориентированные на машину, и оценку структурного влияния, ориентированную на человека. Альтернативой является 3-уровневый шлюз обеспечения качества, работающий сразу после загрузки кода в среду CI.
Во-первых, устанавливается высокоскоростной «шлюз линтинга», который за 5 секунд определяет синтаксическую структуру и соответствие подсказкам типов. Если здесь обнаружены проблемы — немедленный отказ. Во-вторых, проводится «селективное тестирование влияния», при котором выполняются только модульные тесты, находящиеся в зоне влияния измененных файлов (около 2%). В-третьих, запускается цикл автоматизации «автономной коррекции», где в случае провала теста стек ошибок возвращается агенту в качестве контекста, позволяя ему исправить ошибку самостоятельно (максимум 2 попытки).
Только чистые фрагменты кода, прошедшие этот цикл автономной коррекции, появляются на экране старшего разработчика. Человек-рецензент больше не тратит время на поиск опечаток или указания на конвенции. Время старшего инженера должно использоваться только для макроконтроля: проверки того, не разрушились ли границы домена из-за прямой связи между компонентами; подтверждения того, что отражена ли защита (backpressure) для защиты нижележащего уровня персистентности при резком росте трафика; анализа структуры системы и экономической эффективности инфраструктуры, такой как накладные расходы на производительность SQL N+1. Это единственный способ защитить производственную систему в потоке кода, который льется как из прорвавшейся плотины.