Почему мы не стали выпускать продукт быстрее, несмотря на AI

Это то, о чём Брукс размышлял ещё в «Мифическом человеко-месяце»:

«Иногда в газетах пишут о том, как два программиста в переоборудованном гараже создали важную программу, превзошедшую лучшие усилия больших команд. И каждый программист готов верить в такие истории, ведь он знает, что мог бы написать любую программу гораздо быстрее, чем 1000 операторов в год, о которых сообщают для промышленных команд. Почему же тогда все промышленные команды программистов не были заменены преданными делу гаражными дуэтами? Нужно посмотреть на то, что производится».

Брукс утверждает, что код, написанный в гараже, — это лишь часть того, что нужно для конечного продукта:

«Это стоит в девять раз дороже. Но это по-настоящему полезный объект, предполагаемый продукт большинства усилий по системному программированию».

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

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

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

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

Я думаю, AI определённо заставляет нас писать код быстрее, но сколько времени на самом деле освобождается теперь, когда писать код дешевле? У меня складывается впечатление, что мы часто просто находим другие дела, чтобы заполнить это освободившееся время, и возросшая сложность дизайна — одно из них.

Больше тикетов и тикеты крупнее, полные миграции, которые раньше занимали 4 недели с координацией трёх команд, теперь — один PR, сделанный за день.

edit: если вы видите замедление в PR, скорее всего, это потому, что 10 из ваших 10x'еров строчат код в 3-4 с лишним аккаунтах codex на стороне во время своей смены на 8 стартапах.

Ажиотаж вокруг LLM был связан с производительностью инженеров, а не с качеством проектов. Традиционно у нас есть узкие места на этапах ревью и QA для новой работы, и многие организации открывают шлюз для потока нового кода, не устраняя эти узкие места.

Если хочешь ехать на высокой скорости, сначала нужно построить шоссе.

У меня такое чувство, что я схожу с ума от всех этих людей, ставящих под сомнение влияние AI на разработку ПО.

Мне кажется, люди уже забыли, насколько долгой и изнурительной была разработка ПО всего несколько лет назад.

Сейчас самое большое узкое место — это CI/CD/экспериментирование с точки зрения инженерии и согласование продукта с точки зрения бизнеса.

Так и есть. Месяц работы превратился в один день.