Владение кодом в эпоху AI

Иногда пропадает интернет. Иногда становится недоступным Claude Code. И вот тогда, наблюдая толпящихся на офисной кухне разработчиков, задумываешься о том, владеешь ли ты сейчас своим кодом.

TL;DR

У вас два стула и табуреточка.

На первом стуле вас удовлетворяет код, выдаваемый AI, но вы больше не владеете своим кодом.

На втором стуле вы владеете своим кодом, но тогда вам нет смысла использовать AI.

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

А так-то неплохо понять, хотите ли вы владеть кодом и во сколько вам это обходится.

Ante scriptum

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

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

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

Что такое владение?

При желании можно начать с Википедии, но мои три кита Азимова такие:

1. Я понимаю, какая последовательность выполнения кода привела к тому результату, что я наблюдаю.
2. Я знаю, что и где мне нужно изменить в коде, чтобы получить нужный мне результат.
3. Я искренне чувствую, что накосячил, когда в коде обнаруживаются баги (собственно, psychological ownership).

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

Что будет, если у тебя отобрать интернет и начать задавать вопросы? Что ты скажешь, обнаружив, что при нажатии на кнопку сохранения текста удаляется таблица с пользователями?

Всё чаще слышу «блин, снова Клод фигню написал» — снятие ответственности за код с себя. Сам ты уже понятия не имеешь, что под капотом.

И это нормально

В разработке весь этот ажиотаж развивался из-за того, что бизнес сел за счёты и у него получилось, что на каком-то промежутке разработчик с AI сделает в разы больше, выпустит продукт раньше, а продукт этот начнёт прибыль приносить тоже раньше, потому в целом всё это очень выгодно.

Второй причиной стало и то, что для ряда задач уже не требуется senior оператор, местами так и вовсе бухгалтера хватит (знаю историю, в которой бухгалтер с помощью консультаций разработчика под боком едва не за выходные навайбкодила нужный ей калькулятор), что снова про деньги. Говорите, я могу платить ветку разработчику и сто монет за AI вместо мешка золотых за R&D отдел?! Ооо! Это точно не сон?

Следствия тоже не могут не радовать.

Раньше эксперимент обходился в две недели работы полной команды? Окей, сейчас за $20 и день чая с плюшками ты получишь прототип, на котором продакт менеджеры могут уже завтра опробовать свои странные фантазии об удобстве и пользе. Сделай так десять раз, выбери лучшее, отправь на рынок, едь в Монако отдыхать.

Раньше рутина могла отжать 80% спринта? Окей, сейчас вы можете отправить Claude сгенерировать десяток админок, до которых не доходили руки, а сами занимайтесь более полезным.

Раньше фаза исследования баги могла занять 50%? Сейчас натравливаешь AI и уже через 10..20 минут читаешь отчёт. Сюда же онбординг и документация. Вчера я получил грубоватый, но User guide на весь проект. Если бы сказали писать такое руками, затребовал бы пару недель (уже потому, что в некоторых модулях проекта не особо разбираюсь, сначала пришлось бы копаться).

Раньше даже маленькие компании вынуждены были платить тыщи тыщ за различные сервисы, т.к. не могли позволить себе разработку внутренних аналогов? Сейчас продолжается волна ухода компаний от SaaS, т.к. с помощью AI разработать свой сервис и захостить его себе стало в разы дешевле, чем пользоваться чем-то внешним (у этого уже и название своё есть: SaaSpocalypse). Тут тоже не всё просто, но всё-таки.

Короче говоря, вопреки скептикам и хейтерам AI это работает. Подозреваю, в разных странах картина разная, но в Израиле уже есть компании, собеседование в которое заменяется секцией работы с AI. Вы садитесь, тебе дают ноутбук, задачу, того же Claude, ну и включают таймер. Через два часа задача должна быть решена. Смотрят на то, что делаешь, как работаешь, как проверяешь, всё такое. О том, что даже в небольших компаниях разработке оплачивают хоть $20 подписки, уже и говорить поздно, давно такое.

Важно тут зафиксировать вот это: AI значительно сокращает время и стоимость разработки… если качество кода не является частью продукта. Давайте отойдём немного в сторону от темы и поговорим (я поговорю) о том, что такое код и зачем он.

Лирическое отступление

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

Так нафига коду быть качественным? Ну… вообще нафиг надо. Слово удобное, но за ним стоит лишь удобство споров о качестве. Решение должно отвечать задаче.

Максимально заточенный под производительность код обычно читать невозможно, а поддерживать ещё труднее даже автору спустя квартал. Тем не менее, он решает задачу — молотит числа, например.

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

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

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

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

Так вот. В контексте этого эссе удобно считать, что качественный код — код, написанный в установленные сроки и без сбоев выполняющий свою задачу в заданных условиях. Тщательно вылизанный за десять лет код управления блоком АЭС и выстраданный за урок HelloWorld-однострочник первоклашки равны.

Продолжим

К чему вообще было про качество? К тому, что часть компаний сначала влетела своими R&D в AI, а потом вылетела. Какие ещё причины, если не упоминать legal issues и кейсы выбрасывания токенов в окно?

Причины:

1. С помощью AI они не могут достичь того качества кода, что им требуется.
2. Достижение того качества кода, что им требуется, обходится в такие расходы, что при сравнении с имеющейся командой выгода использования AI перестаёт быть выгодой.
3. Они не умеют пользоваться AI так, чтобы получить требуемое качество кода.

Тут нужно совместить предыдущее. Одна из проблем разработчиков та же, что у танковых заводов — если танки не выпускаются, заводчане потихоньку теряют умение выпускать танки. Разработчик, постоянно пишущий код с помощью Claude Code, теряет code ownership, без которого он теряет способность самостоятельность писать качественный код (который не про первоклашку, но про АЭС). Более того, он потихоньку теряет способность провалидировать то, что написал AI. Просто потому, что для этого нужно знать и понимать код, написанный ранее. А всё.

Для того, чтобы этого не происходило, разработчик должен тратить едва ли не столько же времени, сколько и без AI. Внимательно вникать в задачи. Вдумчиво транслировать их AI. Тщательно вычитывать то, что выдал AI. Квалифицированно ругаться с AI, поясняя ему, что не так. Обвешиваться тестами на любой писк комара, чтобы защитить себя от глюков AI (читаю вот уже второй день причудливые анекдоты, выдаваемые свежей GPT-5.6, здоровья погибшим, ага).

При этом на разработку наваливается очередной слой, которому нужно учиться: AI, агенты, MCP, плагины, оптимизации расхода токенов, всё подобное. И один фиг при каком-то косяке сидишь и гадаешь, это LLM ожидаемо сглючило или ты, о нет, не прописал что-то в CLAUDE.md типа «никогда не дропай базу без запроса оператору, тупая ты скотина!»

Потому AI сдвигается из создания боевого кода в более обслуживающую область. Кто-то им прототипирует, но и только. Многие используют для локального исследования кода (особенно актуально для legacy). Часто отлично генерируется техническая документация. Хорошо ещё заходит AI для code-review, иные проблемы не были найдены поколениями опытных разработчиков, а тут вдруг глупая железка нашла.

В целом это вся та же борьба за баланс в разработке, но теперь ещё вместе с AI. Менеджмент должен постоянно пересматривать то, что раньше было очевидным.

Перестараешься с AI — потеряешь в компетенции R&D. Они превратятся в опытных операторов AI, а и всё.

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

Твой R&D воет хором о том, что не может обеспечить качество — окей, а почему у Петрова такая же нога и не болит? Что такое качество в твоём продукте? Почему такое качество не получается?

Твой R&D поёт хором о том, как прекрасен AI и как они ща перевернут планету, если ты оплатишь им токены круче, чем это сделали в Uber — эти гики точно на твоей стороне? А как понять?

Совершенно особо теперь стоит вопрос прогнозирования сроков. Напомню, качество — это ещё и вовремя сделать нужное. Чтобы реалистично оценить выполнение задачи, люди годами опыт набирают. И планы работ корректируют по конкретным исполнителям. А теперь у нас Петров и его Claude Code. Он за пять минут сделает или за пять часов всё угробит? Нужно ли потратить больше времени на тесты? Можно ли эти тесты писать тем же AI, часто читерящим в свою пользу?

Бюджеты теперь тоже под вопросом. Окей, на каких-то задачах AI дешевле человека. Но если у тебя большая кодовая база, с которой нужно сделать что-то очень большое, не потеряв в качестве, у тебя может получиться Rewriting Bun in Rust. Оно и так почитать интересно, но для абзаца полезно «$165,000 at API pricing».

А что делать?

Понятия не имею. Как кажется, на рынке есть разные векторы.

Например, анализаторы кода, учитывающие код, созданный AI. Тут больше контролирующая задача. Начать можно отсюда: Best Enterprise AI Code Analysis Platforms for Leaders 2026

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

Например, втыкают человека в процесс. Давно назвали Human-in-the-loop, но сейчас это на практике означает, что человек всё-таки обязан всё контролировать, читать и подтверждать. Я с этим вполне согласен, к слову, но здесь начинается столкновение интересов бизнеса (выпусти фичу сегодня! нет, вчера! у нас сто тикетов, жопы горят!) и таки вдумчивого анализа того, что происходит на проекте.

А так… всем страшно, мы все умрём, зато теперь мы делаем это быстро и технологично.