ИИ пишет код, а кто инженерит ИИ?

Аннотация.
SE for AI и AI for SE решают разные инженерные задачи. SE for AI проектирует, проверяет и сопровождает системы, где ИИ работает как компонент продукта. AI for SE использует ИИ внутри разработки: для кода, тестов, ремонта, миграции, анализа требований и работы с репозиторием. К июню 2026 года граница между направлениями сместилась к агентным системам: coding agent автоматизирует программную инженерию и одновременно сам становится AI-системой, для которой нужны архитектурные ограничения, авторизация, мониторинг и доказательная приемка результатов. В статье сравниваются объект, артефакты, контур качества, риски и зрелость практик двух направлений.

1. Проблема и метод
SE for AI и AI for SE часто смешивают из-за общей лексики: модели, данные, тесты, пайплайны, качество, эксплуатация. Но объект исследования у них разный. В SE for AI инженер строит систему с ИИ-компонентом. В AI for SE ИИ становится исполнителем или соисполнителем инженерной работы.

Сравнение в этой статье выполнено по характеристикам, а не как рейтинг. Не выбирается «лучшее» направление. Сопоставляются разные пространства признаков. Для SE for AI существенны риск, мониторинг, жизненный цикл, валидация поведения и ответственность. Для AI for SE существенны корректность артефакта, работа с репозиторием, тестовая приемка, права доступа агента и стоимость ошибки.

Материалом служат базовые и свежие публикации: работа о техническом долге ML-систем Sculley et al., 2015, обзор SE for AI-based systems Martínez-Fernández et al., 2021/2022, статья о MLOps Kreuzberger et al., 2022, обзор LLM4SE Fan et al., 2023, SWE-bench Jimenez et al., 2023/2024, SWE-agent Yang et al., 2024, а также работы 2026 года по SWE-Chain, SWE-Bench Mobile, RustPrint, protocol-driven development, production LLM agents и least-privilege authorization.

2. SE for AI: инженерия систем с ИИ-компонентом
SE for AI выросла из наблюдения, что ML-система создает не только программный, но и модельный, дата-зависимый и эксплуатационный долг. Sculley et al. описали boundary erosion, hidden feedback loops, undeclared consumers, data dependencies и configuration issues как типичные источники долга в ML-системах. Это не дефекты модели отдельно от системы. Это дефекты связей.

Обзор Martínez-Fernández et al. показывает, что SE for AI концентрируется вокруг dependability, safety, testing, software quality и data-related issues. Maintenance долго оставался менее проработанным участком. MLOps закрыл часть этого разрыва: Kreuzberger et al. описывают MLOps как набор принципов, ролей, архитектур и рабочих процессов для вывода ML-продуктов в production и их эксплуатации.

К 2026 году SE for AI уже нельзя свести к MLOps. LLM-агенты соединяют стохастические ответы модели с детерминированными системами: файловой системой, CI, CRM, базами данных, платежами, календарями, кодовыми репозиториями. Работа Srinivasan о production LLM agents вводит stochastic-deterministic boundary: контракт между proposer, verifier, commit step и reject signal, который определяет, как выход модели становится действием системы Srinivasan, 2026. Эта рамка фиксирует новую инженерную проблему: контролировать нужно не только модельный ответ, но и момент, когда ответ превращается в действие.

Нормативный слой стал плотнее. NIST AI RMF ориентирует организации на управление рисками при проектировании, разработке, использовании и оценке AI-систем; в 2024 году вышел профиль для generative AI, а 7 апреля 2026 года NIST опубликовал concept note для критической инфраструктуры NIST AI RMF. ISO/IEC 42001:2023 задает требования к AI management system: политикам, процессам и постоянному улучшению управления ИИ ISO/IEC 42001. EU AI Act, опубликованный в Official Journal 12 июля 2024 года как Regulation (EU) 2024/1689, переводит часть инженерных практик в режим юридически значимой документации и контроля EU AI Act.

3. AI for SE: ИИ как участник разработки
AI for SE прошла путь от анализа дефектов и автодополнения до агентов, работающих в репозитории. HumanEval и похожие наборы проверяли функциональную корректность небольших программ. SWE-bench изменил объект оценки: модель получает реальный GitHub issue и должна изменить кодовую базу. В исходной статье SWE-bench включал 2 294 задачи из 12 Python-репозиториев и показал, что даже сильные модели решали только простые случаи.

SWE-agent добавил другой вывод: результат зависит не только от модели, но и от agent-computer interface. Интерфейс, через который агент читает файлы, редактирует код, навигирует по репозиторию и запускает тесты, становится частью метода AI for SE. Это сближает направление с HCI и инструментальной программной инженерией.

Свежие бенчмарки 2026 года показывают сдвиг от разового patch к длительному сопровождению. SWE-Bench Mobile оценивает агентов на задачах из production iOS-кода: PRD, Figma, Swift/Objective-C, тестовые наборы. В оценке 22 agent-model configurations лучший результат составил 12% task success rate Tian et al., 2026. SWE-Chain переносит оценку к chained release-level package upgrades: 12 upgrade chains, 9 Python-пакетов, 155 version transitions, 1 660 grounded upgrade requirements. Средний resolving rate по девяти frontier-конфигурациям составил 44,8%; лучший результат: 60,8% resolving Lam et al., 2026.

Появились и более специализированные линии. RustPrint использует документацию как архитектурный blueprint для миграции C-репозиториев в Rust; по заявлению авторов, на восьми C-репозиториях от 11K до 84K LoC система добилась компиляции всех целей и превысила agentic Claude Code baseline по feature preservation и cross-evaluation test pass rate Le-Anh et al., 2026. Это уже не генерация кода по запросу. Это агентная миграция репозитория с архитектурной памятью и обратной связью от тестов.

4. Сравнение

Различие можно сформулировать короче. SE for AI отвечает за управляемость ИИ-системы. AI for SE отвечает за производительность и качество инженерного действия, которое выполняет ИИ. Когда появляется coding agent с shell-доступом, эти задачи соединяются.

5. Зона сходимости: агентная программная инженерия
Protocol-Driven Development предлагает считать главным артефактом не код, а machine-enforceable protocol: структурные, поведенческие и операционные инварианты, а также Evidence Chain для допуска реализации He and Yu, 2026. Эта идея хорошо описывает сходимость SE for AI и AI for SE. Генератор может менять код, но право на приемку принадлежит протоколу, verifier и evidence ledger.

Работа Yan et al. о least-privilege authorization показывает другой предел автономии. Coding agents получают доступ к shell, репозиториям и пользовательским файлам. AuthBench на 120 realistic terminal tasks показывает, что frontier-модели одновременно пропускают нужные разрешения и выдают лишние или чувствительные доступы; увеличение reasoning-time не устраняет проблему Yan et al., 2026. Значит, агенту нельзя доверять вывод собственной границы полномочий. Ее нужно проектировать как системный контур.

Позиционная статья Cao от 4 июня 2026 года радикально формулирует сдвиг: в agentic systems код становится ephemeral tooling для LLM-driven reasoning loop, а Agentic Engineering претендует на отдельный объект изучения Cao, 2026. Этот тезис полезен как гипотеза, но его нельзя читать как отмену программной инженерии. Свежие бенчмарки показывают не исчезновение SE, а рост требований к интерфейсам, ограничениям, тестам, протоколам и правам доступа.

6. Вывод
AI for SE без SE for AI производит быстрые, но плохо управляемые изменения. SE for AI без AI for SE остается рамкой контроля, которая не использует новый источник инженерной производительности. Рабочая формула 2026 года: агент может писать, мигрировать и чинить код, но система должна задавать границы действия, проверять результат и хранить доказательства допуска. Центр тяжести сместился от «модель генерирует код» к «агент действует в инженерной среде под протоколом, тестами, правами и наблюдением».