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

Обычно спорят о том, заменит ли машина программиста. Спор бессмысленный, потому что задан не в тех терминах. Правильный вопрос звучит иначе: если конечный артефакт можно воспроизвести из описания за минуты, то что именно остаётся редким? Ответ неприятен для тех, кто гордится скоростью набора, и ещё неприятнее для тех, кто думает, что достаточно научиться формулировать просьбы.

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

Лёд, который никто больше не пилит

В девятнадцатом веке существовала целая индустрия, которая зимой выпиливала лёд из замёрзших озёр, хранила его в опилках и развозила по городам. Это был настоящий бизнес с флотом, складами, логистикой и династиями. Потом появился компрессорный холодильник, и лёд не подорожал, не подешевел, а просто перестал быть товаром: он стал побочным продуктом устройства, которое стоит на кухне. Люди, чьим активом был лёд, обнаружили, что владеют не сокровищем, а растаявшей лужей.

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

Здесь важно не спутать дорогое с ценным. Лёд был дорогим, потому что его добыча требовала труда, а не потому, что в нём было что-то незаменимое. Ровно так же строка кода была дорогой из-за стоимости её производства. Уберите стоимость производства — и цена схлопнется, обнажив вопрос, который раньше был закрыт этой ценой: а что, собственно, мы хотели получить?

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

Что на самом деле лежит в вашем репозитории

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

Индустрия придумала для этого честное слово — технический долг, — а потом сделала вид, что это метафора для оправданий перед менеджментом. Но слово точное, бухгалтерски точное. Долг — это то, что стоит в пассиве, а не в активе. Каждая строка требует обслуживания, обновления зависимостей, реакции на уязвимости и внимания живого человека, который держит её в голове.

Забавно, что legacy-код мы называем наследством, хотя ведём себя с ним как с проклятым домом: боимся заходить в подвал, не трогаем несущие стены и надеемся, что оно продержится ещё год. Настоящее наследство не вызывает страха при попытке им воспользоваться. Если ваш главный аргумент против переписывания системы — «мы вложили в неё десять лет», вы описываете не актив, а невозвратные издержки.

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

Спецификация: скучное слово, за которым пряталась вся работа

Главная трудность программирования никогда не заключалась в наборе символов. Она заключалась в переводе мутного человеческого желания в форму, настолько однозначную, что её можно выполнить механически, не переспрашивая. Именно поэтому опытный инженер отличается от новичка не скоростью печати, а количеством вопросов, которые он задаёт до начала работы.

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

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

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

Проверка: единственное место, где живёт правда

Если код одноразовый, то что отличает удачную генерацию от катастрофической? Только проверка. И вот здесь начинается самое интересное, потому что проверка дешевеет гораздо медленнее, чем производство.

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

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

Оракула нельзя сгенерировать из того же источника, что и решение. Иначе получается замкнутый круг: система пишет код, сама придумывает критерий успеха и сама себя хвалит. Это не инженерия, это самогипноз. Человек, который умеет сформулировать критерий независимо от решения, становится редчайшим ресурсом.

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

Вкус — слово, от которого инженерам неловко

Есть третья вещь, которую генерировать не получается, и её стесняются называть вслух, потому что она звучит несерьёзно. Вкус. Способность отличить хорошее решение от просто работающего.

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

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

Вкус нельзя объяснить в промпте, потому что он не сформулирован даже у его носителя. Он вырастает из шрамов — из систем, которые ты сам довёл до состояния, когда их страшно трогать.

Юристы, аналитики и учёные почувствуют то же самое

Программисты просто оказались первыми в очереди, а не избранными. Их артефакт — текст со строгой грамматикой и мгновенной проверкой на работоспособность, поэтому обвал начался здесь. Дальше по списку идут все, чей продукт — структурированный текст.

Договор на сорок страниц перестанет быть результатом дорогой работы и станет тем, что генерируется за пять минут. Ценность юриста переедет туда, где она, честно говоря, всегда и была: в понимание, какие риски вы вообще хотите закрыть, и в способность увидеть в идеально выглядящем документе пункт, который через год похоронит компанию. Финансовая модель на двести формул превратится в расходник, а вопрос, какие допущения в неё заложены, останется единственным содержательным.

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

Здесь же прячется главная опасность. Критерий тоже можно подделать, причём гораздо изящнее, чем результат, и заметить это будет некому.

Что стоит хранить

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

Из этого следует практический вывод, неудобный для привычек индустрии. Хранить надо не код. Хранить надо спецификации, тесты, записи о принятых решениях и причинах отказа от альтернатив — то есть ровно то, что мы всегда выбрасывали первым, потому что оно не компилируется и не показывается заказчику.

Есть, впрочем, вопрос, на который у меня нет ответа. Вкус вырастает из опыта ручной работы: из тех самых лет, когда ты писал плохо, отлаживал ночами и научился заранее чуять, где рванёт. Если следующее поколение никогда не будет писать руками, откуда у него возьмётся то, за что мы предлагаем ему платить?