Экспертиза в предметной области всегда была настоящим рвом

Сложная часть в написании программного обеспечения никогда не заключалась в самом написании. Она заключалась в том, чтобы сначала построить в голове рабочую модель предметной области. Прежде чем выпустить систему расчёта зарплаты, нужно было понять, что такое удержания по исполнительным листам и вычеты до налогообложения и что происходит, когда чей-то расчётный период приходится на смену ставки. Прежде чем выпустить транспортное приложение, нужно было узнать, что такое GTFS-фид, почему рейс (trip) и маршрут (route) — не одно и то же и как автобус, идущий «по расписанию», всё равно может быть неправ. Код был транскрипцией этого понимания. Само понимание и было работой.

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

Стандартная точка зрения, включая мою собственную год назад, состоит в том, что эти инструменты усиливают опытных разработчиков, потому что у опытных разработчиков есть рассудительность. Это верно, но неполно. То, что я наблюдал с тех пор, более конкретно и более интересно: связывающее ограничение сместилось с можешь ли ты это построить на можешь ли ты определить, правильно ли это.

Подумайте о том, кто на самом деле может хорошо пользоваться одним из этих инструментов. Представьте двух человек.

Первый — эксперт в предметной области без какого-либо реального бэкграунда в разработке. Логист-диспетчер, медицинский кодировщик, актуарий. Они не умеют читать стектрейс и не смогли бы объяснить разницу между хеш-таблицей и списком. Но они могут взглянуть на расписание, которое сгенерировал агент, и мгновенно понять, что ни один водитель не может легально отработать такую смену, или что страховое требование с такими кодами никогда не будет оплачено. Они знают правильные выходные данные для заданного набора входных, потому что десять лет прожили внутри этих входных и выходных данных. Дайте им агента — и они окажутся поразительно эффективны, потому что то, чего им не хватает, — способность производить код — это ровно то, что предоставляет агент. То, что приносят они, — это то, чего агент не может: достоверную истину (ground truth).

Второй — сильный инженер-универсал, который никогда не работал в этой предметной области. Он может спроектировать что угодно, он разбирается в надёжности, в тестировании и в том, как не дать системе рухнуть в 2 часа ночи. Но помести его в медицинское кодирование — и он не сможет отличить правдоподобно выглядящий неправильный ответ от правильного. Агент с радостью сгенерирует правило биллинга, которое компилируется, проходит тесты, что инженер додумался написать, и при этом тонко и дорого неверно. У инженера нет оракула. Он может проверить, что софт хорошо построен. Он не может проверить, что софт корректен, потому что корректность здесь определяется целиком той предметной областью, которой он не держит в голове.

Обратите внимание, в какую сторону это режет. До агентов у инженера был путь, которого не было у диспетчера: он мог пойти и выучить предметную область. Медленно, мучительно — следуя за экспертами, читая спецификации и ошибаясь в продакшене — он выстроил бы ментальную модель и тогда смог бы построить систему. Этот путь во многих сферах и был всей карьерной лестницей. У эксперта в предметной области не было эквивалентного пути, потому что обучение созданию надёжного ПО — это годы работы, которые он никогда не стал бы проделывать.

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

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

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