2020 год. Представьте: вы самый опытный человек в команде, отвечаете за качество кода и архитектуру. Вы выстроили здоровые инженерные практики, тщательно ревьюите PR от менее опытных коллег и прикладываете усилия, чтобы кодовая база оставалась в порядке.
В какой-то момент вы уходите в отпуск. Возвращаетесь — а кодовая база превратилась в хаос. Все мержили PR друг друга, не особо вникая в детали, кто-то добавил кучу новых таблиц в базу данных, чтобы денормализовать её — просто потому что так было проще, — а ещё кто-то приткнул в стек serverless или Kafka без каких-либо весомых оснований.
Ничего страшного. Это можно исправить.
Перенесёмся в 2026 год. В отпуск вы не уходили. Обычное утро понедельника. Вы завариваете кофе, открываете ноутбук — и обнаруживаете 7 PR на ревью. Открываете первый: +24506
-3938 строк, сопровождаемые сгенерированным ИИ описанием того, что там якобы должно происходить. Почему-то ваша команда внесла больше изменений с пятницы, чем раньше делала за несколько недель вашего отсутствия.
ИИ убрал ограничение скорости
ИИ заставляет проекты со слабой инженерной культурой рушиться намного быстрее.
Раньше люди садились и обсуждали, как что-то реализовать. Теперь можно просто несколько часов промптить агента и открыть PR.
Самое трагичное в таком подходе — то, что неопытному взгляду кажется, будто он работает.
Если вытянуть ветку и протестировать её, скорее всего, получится что-то более-менее рабочее. И что дальше? Продолжают в том же духе. Снова и снова. Пока проект не доходит до точки, где никто уже не понимает, как всё устроено.
Это похоже на покупку новой роскошной машины в кредит. Долга не видно. Видна только машина, которая отлично выглядит.
А затем пользователи начинают жаловаться на странный баг. Это уже четвёртая попытка команды его исправить. Точнее — попытка попросить ИИ его исправить. К сожалению, похоже, даже Fable не может разобраться, в чём дело.
Вы идёте разговаривать с человеком, который работал над этой фичей.
- «Так откуда берутся эти данные?»
- «Хм... вообще-то не знаю. Сейчас спрошу у Клода».
Вы садитесь рядом и наблюдаете, как на экране бесконечной стеной появляется текст. Ни один из вас понятия не имеет, правда ли всё это, но Клод выглядит очень уверенно.
«Давай просто включим ultracode и попросим перепроверить?»
Это займёт время. Вы начинаете обсуждать последнюю драму в X.
Наконец приходит ответ.
- «Тебе это хоть как-то понятно?»
- «Не уверен».
- «Разве ты не делал это... на прошлой неделе?»
Молчание.
Проект стал настолько запутанным, с таким количеством слоёв и сервисов, что никто в команде уже не в состоянии разобраться, что происходит.
Так что же делать?
Исправление потребует настолько колоссального объёма работы, что даже начинать обосновывать это перед менеджментом бессмысленно.
Да и о чём вообще думать — через пару месяцев всё равно вернётся к тому же самому состоянию.
- «Давай просто попросим Клода это исправить».
- «Ладно. Настрою цикл и цель, чтобы он не останавливался, пока не проверит, что всё работает».
- «Звучит неплохо».
- «Вообще-то у меня закончился лимит Fable на сегодня, так что запущу завтра».
Вы берёте ещё кофе и возвращаетесь к компьютеру. Осталось 13 PR на ревью. Видите что-то не совсем понятное и пишете автору кода.
- «Почему мы делаем это здесь?»
В ответ приходит ссылка. Это переписка с Клодом.
Где-то в этой переписке, между тем как Клод уверенно рекомендует одну архитектуру, извиняется, меняет мнение, коллега просит пересмотреть решение ещё раз, и ещё пятнадцатью раундами правок, якобы и скрывается обоснование архитектурного решения этого куска кода.
- «Какую часть читать?»
- «Наверное, всю».
Знакомая картина?
Стоит завести разговор об этом, как обязательно находится тот, кто скажет: никто никогда полностью не понимал крупные системы. И это правда.
От вас никогда не ожидали понимания каждого сервиса и каждой базы данных. Но хотя бы кто-то понимал и мог объяснить это остальным.
Теперь спрашивают у LLM, потому что сами толком не знают.
Плохих инженеров больше нельзя себе позволить
В любой команде есть компетентные люди, благодаря которым проект вообще возможен. Есть и те, кто по сути усложняет жизнь остальным. И теперь любой способен произвести за день больше кода, чем раньше производил за год.
В истории выше терпят неудачу все:
- Инженер, открывший PR на 25 000 строк, должен был остановить агента задолго до этого момента. Следовало понимать, что тот делает, разбивать работу на небольшие части и подвергать сомнению каждую новую абстракцию, которую он вводил.
- Ревьюер должен был отказаться проверять настолько большой PR вместо того, чтобы уступить.
- Тот, кто добавил Kafka, должен был уметь чётко объяснить, зачем она нужна.
- Автор фичи должен был суметь объяснить, откуда берутся данные, не отправляя ссылку на переписку с Клодом.
Так в чём же проблема? Просто попросить ИИ всё исправить. На деле не так просто...
Прежде чем возражать: технический долг не всегда зло. Важно лишь осознавать, что это именно короткий путь, а не полноценное решение.
В любом случае откатить плохое решение — тяжело. Очень тяжело.
Например, сколько времени понадобится LLM, чтобы добавить в базу данных кучу таблиц и колонок? 10 минут?
Но как только данные начинают там храниться, просто удалить их уже нельзя. Нужен план миграции, нужно убедиться, что система не сломается, ведь люди платят за использование продукта каждый день. Нужно продумать план на случай, если миграция провалится. Убедиться, что не останется осиротевших внешних ключей. Исправить это настолько сложнее — даже с лучшей из доступных моделей.
И пока идёт исправление, продолжают поступать новые PR. Больше кода, больше абстракций, больше решений. Человек способен сгенерировать 20 000 строк кода за вечер, но кто-то всё равно должен сесть и разобраться, что эти строки на самом деле делают.
К тому моменту, когда одно плохое решение распутано, успевают влиться ещё пять новых.
Новая экономика ИИ
Разумеется, плохие инженеры всегда были обузой.
Так было десятилетиями, задолго до появления OpenAI или Anthropic. Плохие решения накапливались, ненужная сложность росла, команды в итоге поддерживали системы, которые никто толком не понимал.
Разница в том, что раньше существовал предел скорости, с которой это могло происходить.
Сегодня реализация стоит дёшево. Платят за принятие хороших решений — за создание софта, который будет масштабироваться при управляемой сложности.
Стоит задаться вопросом: почему компании вообще платят шестизначные зарплаты инженерам в Лондоне или Сан-Франциско?
Если всё, что требовалось — это человек, способный превратить спецификацию в рабочий код, зачем платить так много, если то же самое можно получить дешевле в другом месте?
Почему технологические компании, заявляющие, что «разработка софта решена», продолжают платить топовые зарплаты, чтобы привлечь лучших специалистов?
Ставка в том, что ИИ ещё сильнее разведёт зарплаты в разные стороны. Чтобы быть востребованным, нужно преодолеть планку, а эта планка — это то, что умеет лучшая модель на текущий момент.
Хорошие инженеры стали ценнее, потому что ИИ позволяет им двигаться намного быстрее. Им больше не нужно столько людей вокруг только для реализации.
При этом плохих инженеров стало гораздо дороже нанимать.
Об этом уже говорилось ранее — в материале о том, что карьерный путь vibe-кодера обречён.
Нужно приносить пользу сверх того, что и так получает каждый, кто просто даёт агенту промпт.
Если не хватает суждения, чтобы оценить рекомендацию LLM, запрос на «больше суждения» проблему не решает.
В какой-то момент кто-то всё равно должен понимать, что происходит. И именно этот человек становится самым ценным в команде.
Те, кто не понимает, станут значительно дешевле для найма или вовсе будут заменены, пока деньги стекаются к всё меньшему числу людей, которым действительно можно доверять.
Едва ли это ограничится только разработкой ПО. То же самое, вероятно, произойдёт в большей части интеллектуального труда. ИИ сделает лучших специалистов намного продуктивнее, а плохих — практически невозможными к найму. Раньше был неплохой шанс, что кто-то заметит чужое плохое решение до того, как оно зайдёт слишком далеко. Теперь изменения вносятся быстрее, чем окружающие реально способны их проверить или понять.