Я десять лет писал красивый код. Выравнивал по полочкам, спорил о названиях переменных на код-ревью, защищал паттерны так, будто от них зависит, полетит ли самолёт. И я был в этом хорош. Поэтому мне и больно первым сказать вслух: почти всё, что мы называли «чистым кодом» — паттерны, правила именования, стройная архитектура — было не инженерной необходимостью. Это был налог. И платил его не я. Платил заказчик — а мы платили собой.
Меня за это готовы поднять на вилы, и я понимаю коллег: я сам стоял на тех же вилах ещё год назад. Но если вы хотите остаться полезным в разработке с AI-assisted workflow, придётся пересмотреть роль «чистого кода» в экономике разработки. В том числе про себя.
Кому на самом деле нужна была красота
Базовый факт: программное обеспечение почти всегда меняют после первого релиза. Программное обеспечение не пишется раз и навсегда. ПО обычно годами дорабатывают: меняют требования, интерфейсы, интеграции и бизнес-правила; его дорабатывают, меняют, им владеют как активом годами. Менеджеры и архитекторы enterprise-систем, которые внедряли ПО в энтерпрайзе, давно начали считать стоимость сопровождения, как сделать владение этим активом дешёвым.
Из этого выросла моральная защита практик, которые изначально были способом снизить стоимость сопровождения. Хорошо структурированные системы вызывают у большинства программистов удовольствие. Нам просто приятнее, когда всё выровнено, аккуратно разложено и логически связано — не потому что код от этого лучше работает, а потому что так приятнее держать его ментальную модель в голове. Я знаю это изнутри: стройная кодовая база давала мне почти физическое удовлетворение. Само по себе это не гарантировало, что пользовательский сценарий работает лучше.
При этом проверка пользовательского результата часто отодвигалась после обсуждений архитектуры и стиля. Сдвиг фокуса с реальной задачи на воображаемую «красоту» решения стал таким сильным, что индустрии пришлось вырастить целую отрасль тестировщиков. Получается такая схема: многие программисты хуже фокусируются в парадигме «если код решает задачу заказчика — неважно, какой он внутри». Поэтому в проект нанимают отдельных людей, которые в коде не разбираются и этой деформацией не заражены. Они-то и дают финальную отмашку, что продукт готов. QA-процесс компенсирует разрыв между внутренним качеством кода и проверкой пользовательского результата.
И показательный симптом. Писать тесты программисты не любят — я в том числе. Но когда появился ИИ, многие стали настаивать, что его код обязаны вычитывать глазами. Вроде логичнее было бы наоборот: рутину отдать машине, а глаза оставить на постановку. Это можно объяснить не только заботой о качестве, но и желанием сохранить зону контроля, которая давала нам ощущение контроля и мастерства.
Уютная петля, которую мы закрутили сами
Из этого management-практики вывели прагматичный принцип: довольный, счастливый программист — это резкое снижение total cost of ownership. Поэтому у нас сознательно забрали необходимость думать о результате и в менеджменте разработки закрепились практики, которые поддерживали у разработчиков ощущение контроля над кодовой базой. Такие книги можно читать не только как инженерные руководства, но и как описание культуры управления разработчиками: как создавать и удерживать уютную атмосферу «хорошего» кода.
Интерпретатору всё равно, как названа переменная — order_sum или x. Код отработает одинаково. А вот человеческие трудозатраты на поддержку несопоставимы. Поэтому мы пишем «хороший» код, который выглядит легко поддерживаемым, — и поэтому его действительно легко поддерживать. Возникает обратная связь: понятный код снижает тревогу разработчика, а снижение тревоги повышает готовность поддерживать этот код. Так цикл самоподдерживается: программист упивается стройностью ментальной модели, тестировщик пригибает его к результату, менеджер поддерживает уют — и все счастливы. Я много лет был счастливым звеном этой петли и искренне считал её инженерией.
Что сделал ИИ
Появление ИИ изменило экономику этой схемы.
Если принять, что модели 2026 года уже стабильно справляются с сопровождением кода, выяснилось: часть затрат на читабельность для человека становится менее обязательной. Если код проходит приёмочные критерии и его можно быстро исправить, внутренняя эстетика теряет часть экономической ценности. Сбой любого кода — рукописного или вайбкоженого — выглядит одинаково и приносит одинаковый ущерб. С точки зрения заказчика упавший вайбкод джуниора неотличим от упавшего идеального кода сеньора — ни по процессу, ни по последствиям. Внутренняя структура стала меньше влиять на стоимость следующего изменения ровно в тот момент, когда переписать плохо ведущий себя кусок стало стоить копейки и почти не требовать человека.
Стоимость сопровождения может резко снизиться в проектах, где ИИ действительно надёжно вносит изменения. Искусственному интеллекту всё равно, как названа переменная и сколько отступов, — он читает код не как человек. Да, аккуратные имена и стройная логика дают ему преимущество: это семантическая подсказка. Но не то критичное преимущество, ради которого человек либо отказался бы чинить чужой хаос, либо заломил тройную цену. ИИ может быстрее разобрать плохо структурированный участок, если есть тесты, контекст и понятные критерии результата.
Оговорюсь честно, потому что иначе это будет такая же самоуверенность, от которой я лечусь. У меня перед глазами один сильный кейс, а не статистический закон. Инженер в одиночку переписал легаси-базу, которой было около десяти лет; при 10–15 деплоях в день — ноль прод-инцидентов за полгода. Это один случай, и я не выдаю его за доказанную закономерность. Но он показывает, что возможный выигрыш может быть кратным, а не только маржинальным. В другом контуре, у крупного enterprise-заказчика — Askona, — AI-assisted разработка реальных микросервисов (next best offer, пересчёт складских остатков) идёт прямо внутри легаси-ландшафта: модернизация без «большого взрыва». Это пример применения в production-контексте, хотя по нему всё ещё нельзя делать общий вывод для всей индустрии.
Налог, который мы прятали двадцать лет
Отсюда следует неприятный для разработчиков вывод — мне самому было трудно с этим согласиться.
Основная часть работы программиста — и основная статья расходов заказчика — это значительная часть работы уходит на снижение стоимости будущих изменений. Не работа кода. Удобство его правки потом. Неважно, потребуется ли эта правка вообще; неважно, тот же человек будет её вносить или другой. Правилом хорошего тона считалось заранее обеспечить, чтобы через полгода внести изменение было комфортно и дёшево. За счёт заказчика, разумеется. Мы называли это профессионализмом. Часть этих затрат оплачивала не только бизнес-надёжность, но и комфорт разработчика при работе с кодом.
Если ИИ снижает стоимость будущих правок, часть этого налога становится необязательной. ИИ сам разберётся в своём коде или перепишет заново — ну, потратит чуть больше токенов. Никто больше не хочет оплачивать способность программиста строить в голове стройную ментальную модель: код всё чаще генерируется из неполных требований, которые уточняются в процессе, и та же машина по дороге прорабатывает требования, набрасывает архитектуру и пишет тесты. Роль инженера при этом не исчезает — она смещается. Не вычитывать чужой вывод глазами, а точно ставить задачу и формулировать критерии приёмки. Это, кстати, ровно то, чем хороший инженер всегда и был ценен, — с меньшим акцентом на эстетические нормы кода, если они не влияют на приёмку и сопровождение.
Неудивительно, что у разработчиков это вызывает сопротивление. У меня подгорало тоже — потому что признать это значит признать, что часть моего мастерства была не про машину, а про мой комфорт и мой статус. Лучше заранее пересмотреть свою ценность, чем столкнуться с этим через требования рынка.
Более востребованными станут инженеры, которые умеют формулировать задачу, критерии приёмки и ограничения, а не только поддерживать внутреннюю эстетику кода, когда красота внутри окончательно перестанет стоить денег.