— Но если ты не разбираешься в теме, то у тебя всё упадёт и ничего не заработает!
Эту фразу противники AI пишут как под копирку по любой теме. Так часто и так одинаково, словно им всем раздали одни и те же луддистские методички. Меняются заголовки, спикеры, поводы — аргумент не меняется никогда. Один и тот же рефлекс: раз ты не читаешь код руками, управлять его созданием ты не имеешь права.
И хочется спросить: дурачок, а как раньше-то заказчики и менеджеры управляли разработкой, не разбираясь в вашем рукописном коде?
А ведь они как-то справлялись.
Водораздел, который луддиты не замечают
Сюрприз-сюрприз: умение управлять тем, в чём ты не разбираешься, — базовый скилл менеджмента. Без этого ты лишь обычный hands-on, инженер, которому дали пару руководящих функций. Именно по этой линии пролегает водораздел — менеджер — участник команды или внешний мультипликатор её усилий.
Искусство управлять тем, что не умеешь делать руками, отделяет ремесленника от управленца. Если бы управленец был вынужден во всём разбираться сам, он моментально стал бы боттлнеком всего процесса. Вся команда упёрлась бы в пропускную способность одной его головы, и никакого мультипликатора не вышло бы — вышло бы горлышко бутылки с зарплатой руководителя.
Ставка тут не абстрактная. Тот, кто требует от менеджера лично разбираться в каждой строке, требует по факту вернуть организацию в состояние, где скорость всей разработки равна скорости самого занятого эксперта. Это встроенный потолок роста, который платит деньгами, сроками и упущенными проектами.
Поэтому сейчас эти гуманитарии самостоятельно строят агентские пайплайны — и у них всё получается. Не потому что они внезапно выучили ассемблер, а потому что у них всегда был другой навык: управлять результатом, которого сам руками не сделаешь.
Валидация не спрашивает, откуда взялся результат
Чтобы понять, почему луддитская страшилка не работает, надо посмотреть, как менеджер и заказчик обходились с живыми исполнителями. Не в теории — в той самой рутине, которая была всегда.
Модель написала непонятное ТЗ? Никаких проблем — живые исполнители раньше тоже писали непонятные ТЗ, есть процедура валидации. Ты её гоняешь годами: уточняющие вопросы, критерии приёмки, разбор постановки по косточкам до того, как что-то ушло в работу.
Модель приняла неверные архитектурные решения, которые ты не можешь проверить глазами? Никаких проблем — живые архитекторы тоже балаболили птичьим языком, и у тебя есть процедура конвертации их болтовни в понятный тебе язык цифр и рисков. Не «красиво ли это на диаграмме», а сколько стоит, что ломается, где хвост длиной в годы.
Модель написала плохой код? Никаких проблем — у тебя живые подрядчики такое дырявое говно писали, что ты давно встроил линтеры, UAT и хард-гейты по инфобезу. Не на доверии всё держится, а на воротах, через которые чужой результат обязан пройти, кто бы его ни родил.
Заказчик это уже делал — с живыми людьми
Это не гипотеза «а вдруг сработает». Это ровно то, что уже стоит в enterprise-контурах и работает не первый год.
В Askona техническая валидация подрядчиков до входа в работу была регулярной задачей — компания постоянно привлекала подрядчиков, и каждого прогоняли через проверку компетентности до того, как он касался продакшена. Провалы вендоров — некомпетентность, срывы сроков, интеграционные проблемы — фиксировались и шли в копилку для будущих архитектурных решений. Заказчик систематически оценивал качество работы исполнителей, которых он не заменял собой и код которых не писал за них.
Когда AI-инструменты получили доступ к боевым данным, вокруг них встали ровно те же ворота: read-only доступ к БД, валидация имён таблиц и колонок. Не «доверимся модели», а guardrails — та же логика, по которой ограничивают права любого нового исполнителя в чувствительном контуре.
В другом крупном системном интеграторе под управляемость поставки закладывались автотесты — phpunit, cypress — и рост release reliability, а отношения с субподрядчиками держались на критериях отбора, воротах качества и договорной ответственности. Результат живых подрядчиков фильтруется автоматикой и процедурой, а не персональным чтением каждой строки директором по производству. Смысл governance ровно в том, чтобы снять зависимость исхода от ручного героизма одного человека.
А там, где под бизнес-задачу не было ни инженерного ресурса, ни бюджета, ни сроков, менеджеров учили самим собирать нужное решение — вычислительный механизм, микросервис, дашборд. Гуманитарий, который собирает себе рабочий инструмент, не разбираясь в его кишках, — не новость эпохи агентов. Давно наблюдаемая практика.
Какая разница, откуда взялось ТЗ
И вот теперь заказчик всё то же самое делает с агентами. Какая разница, откуда взялось ТЗ, архитектура или код, если процедура валидации результата — одна и та же?
Никакой.
Вот в чём вся соль, которую луддиты проскакивают: их аргумент бьёт не по AI. Он бьёт по самому институту менеджмента, который всю дорогу управлял тем, что не делал руками. Агент на входе конвейера ничего в этой схеме не сломал — он занял место очередного исполнителя, чей результат и так проходил через приёмку. Ворота стояли до него, стоят при нём и не заметят, если завтра исполнителя снова сменят.
Поэтому заказчики хер клали на ваши страшилки. Для них валидировать результат работы модели — банальная, известная и простая рутина, которую абсолютно понятно как делать без участия человека-эксперта. Они не «рискуют, не разбираясь». Они применяют процедуру, отлаженную на живых подрядчиках, к новому источнику того же самого результата.
Кто на самом деле кричит «всё упадёт»
Из этого следует вполне практический вывод — и он неудобный для целого класса людей.
Тот, кто искренне уверен, что без личного чтения кода управлять разработкой нельзя, выдаёт себя с головой. Он описывает не ограничение технологии — он описывает собственный потолок. Для него управление и есть личное делание, потому что другого способа он не знает и другой роли никогда не занимал. Он проецирует на весь менеджмент устройство своей головы, где начальник обязан быть самым сильным исполнителем в комнате.
НИКОГДА недостаток знаний в программировании не был препятствием для управления разработкой. Заказчики строили софт чужими руками десятилетиями и строят агентскими руками сейчас — по той же самой процедуре приёмки, потому что менять пришлось не её, а лишь имя на входе конвейера.
Каждый, кто утверждает обратное, — типичный рутинный исполнитель. Не слушайте их.