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

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

Четыре слоя компетентности выполняют разные функции

Фундаментальные знания, предметная специализация, программирование и AI не образуют четыре конкурирующие корзины учебного времени. Они отвечают на разные вопросы.

Фундаментальные знания дают модели, через которые специалист объясняет поведение системы: причинно-следственные связи, ограничения, инварианты, способы измерения и характерные режимы отказа. Знать фундамент глубоко – не значит помнить все формулы и API. Это значит уметь восстановить рассуждение и заметить результат, противоречащий устройству системы.

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

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

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

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

Глубина обучения определяется не престижем темы, а ценой непонимания

Рационально учиться глубже там, где собственное понимание требуется для постановки задачи или обнаружения ошибки. Практически можно выделить три уровня.

Требуемый уровень Когда он нужен Что должен уметь специалист
Глубокое владение Ошибка скрыта, последствия велики, требования неоднозначны или решение задаёт архитектуру Объяснить модель и ограничения, вывести критерии корректности, предсказать режимы отказа, провести предметную проверку
Владение на уровне проверки Задача стандартизирована, но результат влияет на рабочую систему Читать и критиковать решение, проверять предпосылки, запускать независимые проверки, локализовать ошибку
Операционное знакомство Работа обратима, ущерб ограничен, а корректность дёшево проверяется Правильно сформулировать запрос, сопоставить результат с эталоном и безопасно откатить изменение

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

Хорошая проверка собственной компетентности – спросить не «смогу ли я получить работающий результат?», а «смогу ли я объяснить, почему он должен работать, при каких условиях перестанет и какие наблюдения это покажут?» Если для самостоятельной проверки ответ зависит от повторного обращения к тому же AI, независимого понимания, вероятно, пока недостаточно.

Граница делегирования проходит по риску и проверяемости

В управлении рисками AI риск обычно рассматривают через вероятность неблагоприятного события и тяжесть его последствий. На практике эти величины часто оцениваются качественно, а не вычисляются как точные числа. NIST AI RMF рекомендует связывать использование AI с явным управлением рисками, измерением и документированным надзором, а не считать наличие человека достаточной мерой само по себе (NIST AI RMF 1.0, AI RMF Playbook). Поэтому вместо притворно точной числовой оценки здесь полезно начать с качественного чек-листа:

Перед делегированием полезно оценить семь свойств задачи:

  • Обратимость. Можно ли безопасно отменить результат?
  • Радиус ущерба. Сколько пользователей, данных и систем затронет ошибка?
  • Наблюдаемость. Ошибка проявится сразу или останется незаметной месяцами?
  • Стоимость независимой проверки. Есть ли тест, эталон, формальная проверка или компетентный рецензент?
  • Предметная неопределённость. Однозначны ли требования и известны ли исключения?
  • Чувствительность данных. Допустимо ли передавать используемый контекст выбранному инструменту?
  • Возможность безопасного отката. Существует ли проверенная процедура восстановления, а не только теоретическая кнопка rollback?

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

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

Скорость генерации не равна производительности или обучению

Эмпирические результаты использования AI в разработке неоднородны. Это ожидаемо: исследования различаются по инструментам, опыту участников, типам задач и выбранным метрикам.

В объединённой оценке трёх полевых экспериментов с 4 867 разработчиками доступ к AI-помощнику был связан примерно с 26%-ным ростом числа завершённых задач (оценка 26,08%; стандартная ошибка 10,3 процентного пункта). Менее опытные разработчики чаще использовали инструмент и получили больший прирост (The Effects of Generative AI on High-Skilled Work). Это результат в конкретных организационных условиях, а не универсальная оценка влияния AI на качество архитектуры, число дефектов или любую другую команду.

В другом рандомизированном исследовании 16 опытных разработчиков выполняли 246 задач в знакомых им крупных open-source-репозиториях. С инструментами начала 2025 года они в среднем работали на 19 % дольше, хотя субъективно ожидали ускорения (исследование METR). Малый состав участников и конкретный сценарий не позволяют распространить результат на всю разработку, но показывают важную вещь: ощущение скорости ненадёжно.

Поэтому команде лучше измерять эффект на собственном потоке работы. Время набора кода – лишь часть стоимости. Следует учитывать время на постановку задачи, чтение сгенерированного решения, исправления, ревью, интеграцию и последующие дефекты.

Отдельная проблема возникает, когда AI используется не для производства, а для обучения. В эксперименте с освоением новой Python-библиотеки группа с AI в среднем получила 50 % за проверку понимания против 67 % у группы ручного программирования, то есть на 17 процентных пунктов меньше. При этом ускорение выполнения не достигло статистической значимости, а результат зависел от способа взаимодействия с помощником (How AI assistance impacts the formation of coding skills). Это ограниченный учебный сценарий, а не доказательство вреда любого AI. Но он поддерживает разумную предосторожность: при изучении нового материала нельзя делегировать именно ту умственную операцию, которую требуется освоить.

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

Что именно можно передавать AI

В задачах с ограниченным риском AI хорошо подходит для механической и черновой работы:

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

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

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

Проверять нужно результат, а не уверенность генератора

Профиль NIST SP 800-218A для генеративного AI не разделяет исходный код на «человеческий» и «созданный AI»: в нём предполагается, что любой исходный код до использования должен быть проверен на уязвимости и другие проблемы (NIST SP 800-218A). Происхождение кода может влиять на характер дополнительного внимания, но не заменяет обычную инженерную приёмку.

Минимальный контур проверки состоит из нескольких разных источников свидетельств:

  1. Зафиксировать требования до генерации. Иначе легко принять красивое решение за правильную постановку задачи.
  2. Проверить предпосылки. Версии библиотек, модель данных, ограничения среды, права и ожидаемую нагрузку.
  3. Прочитать изменение. Не только итоговый файл, но и diff, новые зависимости, обработку ошибок и удалённые проверки.
  4. Запустить независимые проверки. Тесты, статический анализ, сканирование зависимостей и проверки безопасности, соразмерные риску.
  5. Провести предметную проверку. Технически корректная реализация должна соответствовать смыслу данных и бизнес-правилам.
  6. Определить наблюдение после внедрения. Метрики, журналы, сигнал ошибки и процедуру отката.

Ни один пункт не доказывает абсолютную корректность. Тесты проверяют только заданные случаи; статический анализ не видит всех архитектурных ошибок; code review зависит от компетентности и доступного времени. Сила контура возникает из сочетания независимых методов.

Просьба к той же модели «проверь собственный ответ» может быть полезной для поиска очевидных недочётов, но не считается независимой проверкой. Модель способна повторить исходное неверное предположение в иной формулировке.

Формально назначенный человек в контуре может ничего не изменить

Человеческий надзор эффективен только тогда, когда назначенный человек:

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

Такое понимание надзора отражено и в рекомендациях NIST по взаимодействию человека с AI (AI RMF, приложение C). Требования к человеческому надзору для отдельных высокорисковых систем формализованы, например, в статье 14 EU AI Act, но их нельзя автоматически переносить на любую систему или юрисдикцию (официальный текст Regulation (EU) 2024/1689).

Особую опасность представляет automation bias – склонность принять автоматическую рекомендацию без достаточной проверки. Систематический обзор связывает этот эффект с доверием к системе, опытом пользователя, нагрузкой и сложностью верификации (Automation bias and verification complexity). Поэтому кнопка подтверждения не создаёт содержательного контроля. Иногда она лишь переносит подпись на человека, не давая ему реальной возможности проверить решение.

Ответственность следует закреплять по решениям

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

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

Один специалист может совмещать несколько ролей, особенно в небольшой команде. Важно не количество людей, а отсутствие бесхозных решений. NIST AI RMF прямо связывает управление рисками с ясными ролями, полномочиями и линиями коммуникации (AI RMF Core). Это организационная ответственность; конкретная юридическая ответственность зависит от законодательства, договора и структуры организации.

Пример: AI пишет миграцию данных

Предположим, инженер готовит миграцию, которая объединяет дублирующиеся записи клиентов.

AI можно поручить черновик SQL, создание синтетических тестовых данных и варианты проверки количества строк. Но специалисту необходимо самому определить:

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

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

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

Практический алгоритм выбора

Для новой задачи достаточно пройти короткую последовательность:

  1. Сформулировать цель и последствия неверного результата без помощи AI.
  2. Оценить обратимость, радиус ущерба, наблюдаемость, чувствительность данных и стоимость проверки.
  3. Определить, какие знания нужны для постановки задачи и распознавания скрытой ошибки. Их следует изучать глубоко.
  4. Выделить механические операции, результат которых можно независимо и дёшево проверить. Их можно автоматизировать программой или передать AI.
  5. Заранее задать критерии приёмки, проверки и откат – до получения убедительно выглядящего результата.
  6. Назвать человека или команду, принимающих финальное решение и реагирующих на последствия.

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