Написанный ИИ код остаётся вашим кодом

Короткое эссе с martiansoftware.com, построенное вокруг одного наблюдения, которое автор выделяет полужирным: "Нам никогда не приходилось рассматривать понимание собственного кода как отдельную статью расходов помимо его написания, потому что написание во многом вынуждало нас его понимать" ai-written-code-is-still-yours.

Разделение написания и понимания

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

Когда код пишут агенты, это понимание становится необязательным, и автор иронизирует над тем, к чему это ведёт: пусть агенты ещё и ревьюят код, и тестируют его, "и тогда мы сможем вообще избавиться от этих назойливых ментальных моделей!"

Владение не бывает опциональным

Автор ничего не имеет против, когда ставки невысоки. Он сам собрал таким способом несколько одноразовых утилит и пару развлекательных проектов - то, что иначе так и осталось бы в списке "когда-нибудь потом". Граница проходит по владению, и речь здесь не об интеллектуальной собственности: тот, кто создаёт программное обеспечение, берёт на себя ответственность за его качество и безопасность, за отладку, эксплуатацию, поддержку и развитие с течением времени. Вопрос, который он предлагает задавать, меняется с "Можем ли мы это сделать?" на "Хотим ли мы этим владеть?", и он хочет, чтобы это было осознанным решением, а не ответственностью, о которой узнают, когда код уже на руках.

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

Место в базе знаний

Текст краток и формулирует тезисы без опоры на данные, но сама постановка вопроса чётко выражает мысль, вокруг которой вращаются сразу несколько страниц. cognitive-debt представляет собой измеренную версию этого разделения: группа из MIT выяснила, что большинство авторов, писавших с помощью LLM, не могли процитировать собственное эссе, что наглядно показывает: понимание не возникает, когда написанием текста занимается кто-то другой. programming-as-theory-building содержит более старый тезис о том, что понимание всегда и было настоящим продуктом. disposable-code описывает случай с низкими ставками, который автор выносит за скобки: код настолько дёшев, что его проще выбросить, и понятие владения к нему едва ли применимо, а cheap-reverse-engineering служит конкретным примером такого подхода.

С противоположной стороны, в control-the-ideas-not-the-code утверждается, что построчное понимание кода от LLM - пустая трата сил, пока вы контролируете общую архитектуру. Это близко к авторской идее переключения масштаба, но с большим отказом от деталей. В not-understanding-your-codebase доказывается, что на больших масштабах частичное понимание и так является нормой. В writing-code-vs-building-software также утверждается, что релиз сгенерированного кода означает владение им, но владение там определяется как понимание и валидация каждой части, что строже, чем авторское переключение между уровнями. Обе позиции совместимы с его финальной мыслью, так как обе опираются на границы, позволяющие рассуждать об отдельной части без погружения во всё целое.

В refactoring-that-never-happens приводится вариант того же аргумента на уровне команды: раньше момент, когда человек терял нить в кодовой базе, служил триггером для рефакторинга; агенты же никогда не теряются, и поэтому структура, сохраняющая код понятным, перестаёт поддерживаться. peril-of-laziness-lost объясняет, почему тезис о "фабрике сложности" верен: агенту работа ничего не стоит, поэтому внутри агента ничто не подталкивает к сокращению объёма кода.