AI уже способен за несколько секунд создать функцию, SQL-запрос, набор тестов, конфигурацию развёртывания, описание API или черновик эксплуатационной инструкции. Но скорость производства текста не равна скорости создания работающей системы.

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

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

Артефакт ещё не является решением

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

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

Функция может компилироваться и успешно проходить тесты, но нарушать архитектурный инвариант. SQL-запрос может выполняться, но отвечать не на тот бизнес-вопрос. Runbook может быть написан ясно, но предлагать операцию, недопустимую в конкретной среде. Во всех трёх случаях артефакт выглядит законченным, а решение остаётся неправильным.

В системной инженерии это различие выражают понятия verification и validation. Verification отвечает на вопрос, соответствует ли реализованный продукт установленным требованиям. Validation проверяет, пригоден ли продукт для предполагаемого применения в предполагаемой среде и отвечает ли он ожиданиям заинтересованных сторон. Это разные задачи, и успешная верификация не заменяет валидацию (NASA Systems Engineering Handbook).

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

Что именно автоматизируется

Генеративные инструменты особенно сильны там, где вход и выход можно представить как локальное преобразование: описание в код, схему в типы, интерфейс в документацию, пример в тестовую заготовку. Чем больше результат зависит от неявного организационного или предметного контекста, тем меньше ценность одной лишь генерации.

Артефакт Что удобно поручать AI Что остаётся предметом инженерной проверки
Код Черновая реализация, шаблоны, преобразование API, рефакторинг локального фрагмента Семантика, архитектурные ограничения, безопасность, конкурентность, ресурсные пределы, обработка отказов
SQL Построение запроса по описанию, перевод между диалектами, объяснение плана Бизнес-смысл, схема, права, кардинальности, стоимость выполнения, пустые и необычные данные, риск изменения или раскрытия данных
Тесты Генерация примеров, фикстур, mock-объектов, граничных вариантов Полнота относительно требований и рисков, независимость источника ожидаемых результатов (test oracle), реалистичность среды
Конфигурации Шаблоны CI/CD, контейнеров, политик и инфраструктуры Секреты, права, совместимость версий, масштаб последствий, стратегия развёртывания и отката
Требования Черновая структура, унификация языка, поиск двусмысленностей Намерение заинтересованных сторон, достижимость, непротиворечивость, проверяемость, приоритеты и исключения
Архитектурные описания Перечень вариантов, диаграммы, фиксация принятого решения Границы компонентов, инварианты, компромиссы, модель отказов и долгосрочная эволюция
Runbooks и технические тексты Черновик, резюме, преобразование формата, выравнивание терминологии Фактическая точность, применимость к среде, безопасный порядок действий, актуальность

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

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

Разработка программы не ограничивается написанием кода: до выпуска нужно определить требования, спроектировать взаимодействия и интегрировать компоненты; после выпуска систему предстоит эксплуатировать, сопровождать и в итоге выводить из эксплуатации. ISO/IEC/IEEE 12207 задаёт общую рамку процессов полного жизненного цикла программных систем от замысла до вывода из эксплуатации. Генерация артефакта ускоряет часть работы, но не устанавливает его пригодность для всей системы.

Постановка задачи становится частью механизма контроля

Фраза «сделай отчёт об активных клиентах» понятна человеку только потому, что тот достраивает контекст. Что означает «активный»: хотя бы одна покупка, действующий договор, вход за последние 30 дней или отсутствие просроченной задолженности? На какую дату строится отчёт? Как учитывать возвраты, тестовые аккаунты и объединённые профили?

LLM тоже достраивает отсутствующие детали, но правдоподобное дополнение не обязательно совпадает с правилами организации. Исследования галлюцинаций в сгенерированном коде показывают, что модели могут придумывать API, зависимости и факты либо неверно связывать доступный контекст; это систематический класс отказов, хотя он и не означает ошибочность каждого результата (Exploring Hallucinations in LLM-Generated Code).

Поэтому постановка задачи должна преобразовать намерение заинтересованных сторон в требования, которые можно реализовать и проверить. Полезное требование не просто звучит разумно. Оно должно быть достаточно однозначным, технически корректным, достижимым, непротиворечивым и связанным с методом проверки. Эти свойства и трассируемость требований рассматриваются в NASA Systems Engineering Handbook.

Для отчёта об активных клиентах формализация может определить:

  • точное условие активности и временную зону;
  • источники данных и правила устранения дублей;
  • допустимую задержку обновления;
  • правила обработки удалённых и заблокированных записей;
  • права на просмотр персональных данных;
  • контрольные примеры и ожидаемые итоги;
  • предел времени выполнения запроса.

После этого AI получает проверяемую спецификацию, по которой можно оценить результат независимо от генератора. Разница принципиальна: промпт управляет генерацией, тогда как спецификация позволяет судить о результате независимо от генератора.

Выбор механизма решения нельзя сводить к выбору модели

Не всякая задача, сформулированная на естественном языке, требует LLM или иной ML-модели. Инженер выбирает между обычной программой, запросом к базе данных, правилом, алгоритмом оптимизации, конечным автоматом, симуляцией, статистической моделью и агентом с доступом к инструментам.

Выбор определяется свойствами задачи:

  • нужна ли воспроизводимость одного и того же ответа;
  • существуют ли точные алгоритмические правила;
  • допустима ли вероятностная ошибка;
  • насколько важны задержка и стоимость вычислений;
  • можно ли передавать данные внешнему сервису;
  • требуется ли объяснить или воспроизвести решение;
  • можно ли независимо проверить результат;
  • что произойдёт при недоступности модели или внешнего инструмента.

Например, расчёт налога по зафиксированному набору правил концептуально отличается от классификации свободного текста. LLM может помочь перевести правила в код или объяснить их. Исполнение формализованных правил должно опираться на зафиксированную версию правил и независимые проверки; сгенерированную реализацию можно применять, когда её корректность подтверждена с учётом риска.

То же относится к агентам. Возможность вызвать базу данных, изменить файл и запустить deployment увеличивает полезность, но одновременно расширяет последствия ошибки. Тогда объектом проектирования становится не только модель, а весь контур: разрешённые инструменты, права, лимиты, журналирование, подтверждения, тайм-ауты, повторные попытки и аварийная остановка.

Инженер задаёт пространство допустимых состояний

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

Такие свойства часто выражаются как инварианты:

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

Математика и алгоритмы здесь нужны не ради ручного решения упражнений. Они дают язык для определения свойств: пред- и постусловий, инвариантов, графов переходов, вероятностей отказа, ограничений ресурсов, сложности алгоритмов. Формализация не обязательно означает полное математическое доказательство. Для одного компонента достаточно типов и контрактов, для другого нужны тестирование на основе свойств (property-based testing), проверка моделей (model checking) или формальная верификация отдельных критических свойств.

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

Пример: правильный SQL с неправильным смыслом

Предположим, существуют таблицы customers, orders и payments. Требуется вывести число клиентов, «совершивших покупку в прошлом месяце». AI предлагает запрос в синтаксисе PostgreSQL:

SELECT COUNT(DISTINCT customer_id)
FROM orders
WHERE created_at >= date_trunc('month', current_date) - interval '1 month'
  AND created_at <  date_trunc('month', current_date);

Запрос синтаксически корректен и, вероятно, выполнится. Но он не отвечает на несколько существенных вопросов:

  • считается ли покупкой созданный заказ или только оплаченный;
  • исключаются ли отменённые заказы и возвраты;
  • в какой временной зоне определяются границы месяца;
  • относится ли customer_id к человеку, аккаунту или организации;
  • может ли один заказ иметь несколько платежей;
  • допустимо ли читать все строки таблицы в рабочей базе;
  • отражает ли created_at момент оформления или фиксации события после задержки.

Даже execution accuracy, то есть совпадение результата выполнения с эталоном на конкретном наборе данных, не полностью решает проблему: два семантически разных запроса могут случайно вернуть одинаковый результат. Exact match сопоставляет запрос с эталонным SQL по правилам конкретного бенчмарка, а не обязательно посимвольно. Он может отвергнуть эквивалентные запросы; ошибки реализации способны, наоборот, засчитать как совпадающие запросы с разной семантикой. Ни одна из этих метрик сама по себе не устанавливает, правильно ли определено бизнес-событие «покупка» (анализ метрик Text-to-SQL).

Корректное решение потребует определить бизнес-событие «покупка», связать его со схемой, проверить права, исследовать план выполнения и испытать запрос на характерных граничных данных. Генерация SQL составляет лишь один шаг.

Проверка должна быть независимой и соразмерной риску

TEVV – testing, evaluation, verification and validation – объединяет тестирование, оценивание, верификацию и валидацию. Это не один финальный барьер, а набор способов получить свидетельства о поведении системы до развёртывания и во время эксплуатации. NIST AI RMF рекомендует явно определять роли, ограничения, методы измерения и мониторинга, документировать результаты оценки и управлять риском на протяжении жизненного цикла (AI RMF 1.0). Рамочная модель добровольна и сама по себе не устанавливает обязательный уровень контроля для каждой системы.

Разные методы отвечают на разные вопросы:

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

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

Проход тестов также не равен приемлемому изменению. В исследовании METR четыре сопровождающих трёх репозиториев рассмотрели сгенерированные AI pull requests для 95 задач SWE-bench Verified. По оценке авторов, примерно половина изменений, прошедших автоматический grader, не получила бы одобрения сопровождающих даже с поправкой на вариативность их решений: тесты не выявляют всех проблем с функциональностью, влиянием на другой код и качеством реализации. Исследование охватывало только три из двенадцати репозиториев бенчмарка; рассмотрение проходило без обычного CI, а агентам не давали дорабатывать изменения после замечаний. Вывод относится к этому эксперименту и не измеряет пригодность всех AI-изменений в обычном итеративном процессе разработки (Many SWE-bench-Passing PRs Would Not Be Merged into Main).

Для безопасности AI-сгенерированный код следует включать в обычный защищённый жизненный цикл разработки, а не считать особой категорией, свободной от принятых проверок. NIST SSDF связывает снижение риска уязвимостей с практиками подготовки организации, защиты программного обеспечения, производства защищённых выпусков и реагирования на уязвимости (NIST SP 800-218).

Цена ошибки определяет границу делегирования

Сложность синтаксиса – плохой критерий автономности. Однострочное изменение политики доступа может быть опаснее тысячи строк изолированного прототипа. Полезнее оценивать четыре свойства:

  1. Проверяемость. Можно ли независимо определить правильность результата?
  2. Обратимость. Можно ли быстро и надёжно отменить действие?
  3. Наблюдаемость. Будет ли ошибка обнаружена до существенного ущерба?
  4. Масштаб последствий. Насколько широко распространятся ошибка, утечка или простой?

Из них следует рабочая матрица делегирования. Это инженерная рекомендация, а не универсальный стандарт.

Условия Допустимый режим Необходимые свидетельства и ограничения
Результат локален, обратим и легко проверяется Автоматическая генерация; автоматическое применение только после обязательных автоматических проверок, блокирующих применение при отказе Тесты, статический анализ, журнал изменений, ограниченные права и проверенный откат
Требуется значительный контекст, но ошибка обнаружима и откат надёжен Генерация с автоматическими проверками; обязательный просмотр изменений, затрагивающих интерфейсы, данные или права, выборочный просмотр изолированных изменений Трассировка к требованиям, интеграционные тесты, проверка совместимости, план отката
Ошибка затрагивает данные, безопасность, доступность или многих пользователей AI предлагает, уполномоченный человек или независимый контур утверждает Анализ риска, разделение полномочий, испытание в изолированной среде, мониторинг, staged rollout
Последствия трудно обнаружить, локализовать или компенсировать Автономное применение обычно неприемлемо без специально спроектированного защитного контура Формализованные ограничения, независимая верификация, fail-safe-поведение, право остановки, аудит

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

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

Интеграция и эксплуатация возвращают системный контекст

Локальная генерация обычно видит не всю систему. Между правильным фрагментом и работающим выпуском остаются:

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

Технический долг (technical debt) здесь означает будущую стоимость упрощений и несогласованностей: дублированной логики, размытых интерфейсов, хрупких тестов, скрытых зависимостей. AI способен как уменьшать его через последовательный рефакторинг, так и накапливать через множество локально разумных, но архитектурно несовместимых изменений.

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

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

Скорость генерации не равна производительности системы разработки

Исследования AI-ассистентов дают разные результаты, потому что измеряют разные задачи, группы разработчиков и рабочие условия. В рандомизированном контролируемом эксперименте 95 профессиональных разработчиков распределили между группой с GitHub Copilot и контрольной группой и предложили реализовать HTTP-сервер на JavaScript. В этих конкретных условиях среднее время выполнения задачи в группе с Copilot было на 55,8% меньше; приведённый авторами 95%-ный доверительный интервал для сокращения времени составлял от 21% до 89% (The Impact of AI on Developer Productivity).

В другом рандомизированном исследовании METR участвовали 16 опытных разработчиков, выполнявших 246 задач в знакомых им зрелых open source-репозиториях. При использовании доступных в начале 2025 года AI-инструментов оценочное время выполнения задач оказалось на 19% больше, с 95%-ным доверительным интервалом от 2% до 39% увеличения времени (исследование METR; последующее уточнение авторов).

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

Поэтому оценивать автоматизацию только по числу сгенерированных строк, закрытых тикетов или времени до первого патча недостаточно. Для системы важны также:

  • функциональная корректность;
  • стоимость review и повторной работы;
  • дефекты и инциденты после выпуска;
  • безопасность и производительность;
  • интеграционные сбои;
  • сопровождаемость изменения;
  • время восстановления;
  • накопление технического долга.

Инструмент может ускорить написание первой версии и одновременно увеличить объём проверки. В другом контексте он способен сократить обе величины. Вывод следует делать по полному потоку работ, а не по скорости печати артефакта.

Как меняется инженерная функция

Когда производство артефактов дешевеет, ценность инженера всё меньше определяется скоростью создания синтаксически правильного текста. Важнее сохранить причинно-следственную цепочку от потребности до наблюдаемого поведения системы. Для этого нужно:

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

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

AI может быть автором значительной части артефактов и участником проверки. Но ответственность требует явных ролей: кто утверждает требования, кто разрешает исключение, кто принимает выпуск, кто может остановить систему и кто расследует инцидент. NIST AI RMF рассматривает такие роли, измерение риска и управление им как организационные функции, а не как свойства одного инструмента.

Итоговая граница проходит не по линии «человек пишет, машина подсказывает». Она проходит между генерацией возможного результата и обоснованным решением о его применимости. Пока система должна служить определённой цели, оставаться в допустимых состояниях и выдерживать последствия ошибок, инженер отвечает не за объём написанного текста, а за связность модели проблемы, реализации, доказательств и эксплуатации.