Я больше не пишу код руками. Работать стало тяжелее

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

Закончил я через два месяца.

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

Два месяца вместо выходных

Давайте я просто перечислю, на что ушло время, — так понятнее любого рассуждения.

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

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

Проект в итоге никуда не полетел, и по причине скучной: я не стал заниматься продвижением. Со мной так регулярно, я про это уже писал^[1] — довожу до прототипа, доказываю себе, что работает, и остываю. Но как замер эти два месяца получились на редкость чистыми: видно, что именно ускорилось, а что осталось ровно таким же, каким было. В этом смысле проект свою работу сделал, даже если продуктом не стал.

Вывод. До генерации надо ответить на вопросы, на которые агент за вас не ответит: для кого продукт, что он обещает и что делать, когда обещание не выполнено.

Где вайб-кодинг на своём месте

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

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

Забавно, что Андрей Карпаты уже в первом посте про «вайб-кодинг» оговорился: для одноразовых проектов на выходные — «не так уж и плохо»^[2]. Саймон Уиллисон позже сказал жёстче: довайбкодиться до продакшена — плохая идея, потому что основная работа инженера состоит в развитии уже существующих систем, где понятность кода критична^[3].

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

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

Почему «это ненастоящая разработка» я слышу не впервые

Главное возражение, которое я слышу: то, что сделано с ИИ, — ненастоящая разработка. У этого возражения длинная родословная.

С Delphi и Visual Basic кнопку на форме стало можно просто нарисовать мышкой. Теперь это выглядит нормальным. Electron сделал похожий размен уровнем выше: вместо нативного интерфейса приложение встраивает в бинарник Chromium и Node.js^[4].

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

Но у этой истории есть вторая половина, и её вспоминают реже. Фред Брукс сорок лет назад разделил сложность в разработке надвое: сущностная заложена в самой задаче, привнесённая возникает только из-за того, как мы сегодня работаем. Про языки он написал прямо: самое большее, что высокоуровневый язык может сделать, — это дать программисту все конструкции, которые тот уже придумал в абстрактной программе^[5]. То есть язык снимает ручной труд и не отменяет необходимости придумать программу.

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

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

Вывод. Генерация снимает ручную работу ненадёжно: выигрыш в скорости сразу создаёт счёт за проверку.

Что подешевело, а что нет

Тут мне очень помогла книга, которую я сейчас читаю, — «Regenerative Software» Чада Фаулера. Она пока выходит у O’Reilly в раннем доступе, но основные идеи Фаулер параллельно публикует в открытой серии эссе. Он начинает с экономики, и это объяснение происходящего мне ближе всего.

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

Генерация бьёт ровно по этой статье расходов. Фаулер формулирует сдвиг проще: проблема уже не в том, чтобы произвести код, а в том, чтобы безопасно его заменить^[6]. Раньше от соблазна переписать модуль нас берегла дороговизна — десять раз подумаешь, прежде чем лезть. Теперь не подумаешь ни разу, потому что дёшево. А риск никуда не делся.

Аналогию он берёт из инфраструктуры, и она хорошая. Сервер когда-то был питомцем, которого лечат; потом мы научились пересоздавать его из описания и перестали привязываться. Вастрик перенёс ту же логику на код: 99% написанного разработчиками кода будет просто выброшено на свалку, и если принять это за норму, жить становится сильно проще^[7]. Фаулер предлагает довести мысль до конца. Хорошо, пусть реализация будет скотом. Но тогда всё, ради чего она вообще существует, надо вынести из неё: что система обязана делать, какие инварианты сохранять, какие границы не нарушать.

Вывод. Подешевело производство реализации. Знание о том, что система обязана сохранять при её замене, — нет.

Работа переехала в спецификацию

Если код генерируется быстро, задача «написать код» становится тривиальной — при условии, что есть спецификация. Отсюда и весь нынешний интерес к spec-driven development. GitHub, выпуская свой инструмент, описал проблему одной фразой: вы описываете цель, получаете блок кода, и часто он выглядит правильным, но работает не совсем^[8]. Лечение предлагают очевидное — сделать спецификацию главным артефактом, а код производным от неё.

И тут выясняется, что мы вернулись к Бруксу. У него написано: трудная часть создания софта — это спецификация, проектирование и тестирование концептуальной конструкции, а не труд по её представлению и проверке точности этого представления^[9]. Сорок лет это читалось как красивое замечание, потому что «труд по представлению» съедал почти весь бюджет. Теперь не съедает, и фраза читается как инструкция к применению.

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

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

У Фаулера для проверок есть отдельное слово, evaluations: проверки, которые живут дольше конкретной реализации — инварианты, контракты, требования к задержкам, случаи из реальных инцидентов. В пятой главе книги он разбирает собственный провал с образовательной системой для старших классов: новый стек, разработка через тесты, стопроцентное покрытие — и пользователи, которые после выкладки взбунтовались. Систему откатили, забросили и повторно выпускать не пытались. Покрытие показывало, сколько кода выполнилось, но не отвечало на вопрос, поймали ли они то, что нужно учителю утром во вторник^[10]. Все тесты были зелёными. Проверяли просто не то.

Вывод. Зелёные тесты говорят только о том, что вы догадались проверить.

Главное возражение против spec-driven

У spec-driven хватает скептиков, и возражение у них по делу. Спецификация почти никогда не содержит всего, что нужно для генерации. Особенно если репозиторий начат не вчера: в коде сидят решения, которых в спецификации нет и никогда не было. Ретрай именно с таким лимитом. Валидация, зачем-то продублированная в двух местах. Вот этот шаг, который почему-то синхронный. Человек, который это написал, давно ушёл, причина нигде не записана. Сгенерируйте по спецификации новую версию — и вы аккуратно выкинете всё, что система узнала за годы работы.

Возражение верное. Вывод из него делают неправильный.

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

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

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

Из чего тогда состоит рабочая спецификация? Из поведения — но не только. В ней должны быть бизнес-решения с обоснованием: почему сделали именно так, какие варианты рассматривали и почему от них отказались. Отсюда и ценность ADR. Я долго считал их бюрократией для галочки, а это единственное место, где живёт «почему». Плюс документ с открытыми вопросами и ответами на них: вопрос возник, ответ получили, записали. И железное правило: поменялось продуктовое поведение — значит, это попало в спецификацию, даже если в коде изменение уместилось в одну строчку.

Вывод. Нашли в коде знание, которого нет в спецификации, — сначала верните его в спецификацию. Иначе она быстро станет ещё одним устаревшим документом.

Где генерация промахивается и зачем тут человек

«Выглядит правильным, но работает не совсем» — это не абстракция, у этого есть вполне конкретные места. Назову два, которые ловлю у себя постоянно.

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

Путь пользователя. В моих проектах агент сам не проверяет happy path. Он проверит, что функция вернула правильное значение, что тесты зелёные, что сборка прошла. А потом вы запускаете и обнаруживаете, что пройти сценарий от начала до конца нельзя: тут не хватает перехода, там форма не отправляется, а после успешной оплаты попасть некуда. Код правильный, продукта нет.

И это дорогой режим отказа — почти-правда. В опросе Stack Overflow 2025 среди пользователей ИИ-инструментов самым частым раздражителем стали решения, которые почти правильные, но не совсем: этот вариант выбрали 66% респондентов^[12]. Явно сломанный код ловится за секунду. Код, который выглядит правильным, проходит тесты и разваливается на границе, ловит только человек, понимающий, что вообще должно было произойти.

Насколько самооценка расходится с измерениями, показал METR. В первой части исследования, на инструментах начала 2025 года, шестнадцать опытных контрибьюторов крупных open-source-проектов решили 246 реальных задач из своих репозиториев. С доступом к ИИ они работали на 19% дольше, хотя до начала ждали ускорения на 24%, а после всё равно считали, что ИИ ускорил их на 20%^[13]. Но эти цифры нельзя переносить на всех и тем более выдавать за состояние инструментов в 2026 году: сам METR теперь помечает результат как устаревший. В продолжении у части тех же разработчиков вышло уже ускорение на 18%, но с широким доверительным интервалом и сильным эффектом отбора. Надёжный вывод здесь скромнее: ощущения скорости недостаточно, её надо измерять.

Поэтому усиливается не каждый. По моему опыту, больше всего выигрывает тот, кто способен отличить правдоподобное от правильного, а для этого нужна глубина хотя бы в одном направлении — та самая база, по которой видно, что модель поехала не туда, — и достаточная ширина вокруг, чтобы дойти от идеи до эксплуатации. Это развитие старой идеи T-shaped-специалиста: глубина в одной области и рабочие знания в смежных^[14]. Теперь появился инструмент, с которым такой человек может в одиночку пройти гораздо дальше. Но это условие необходимое, не достаточное: опытные участники METR знали свои репозитории лучше всех и всё равно в первой части исследования замедлились.

Вывод. Не проверяйте работу агента по ощущениям. Пройдите путь пользователя и измерьте то, что он должен был улучшить.

Проверять оказалось дороже, чем писать

А вот теперь то, что удивило меня сильнее всего. Написать тест гораздо сложнее, чем написать код, который этот тест проверяет.

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

И вот здесь генерация почти не помогает. Местами даже мешает.

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

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

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

Но и тут та же ловушка, просто этажом выше. Если мутационную проверку пишет агент с той же оптимизацией, он привяжет её к конкретной реализации. Сломал строчку — проверка упала, всё сошлось, формально он кругом прав. Только проверяет она теперь способ, которым написан код. Про то, делает ли продукт то, ради чего затевался, она молчит. Замените реализацию — проверка развалится, хотя ни одного обещания система не нарушила. Фаулер предлагает простой критерий: если переписывание сервиса на другом языке делает тесты бесполезными, они стоят не на той границе^[15].

Проверки стали разом и гораздо важнее, и гораздо дороже. Это единственное место в разработке, где ИИ мне скорее мешает и требует постоянного присмотра, — и ровно то место, на котором теперь держится всё остальное.

Вывод. Новое правило должно один раз упасть на намеренно сломанном примере. Иначе вы не знаете, ловит ли проверка хоть что-нибудь.

Когнитивная нагрузка выросла

Про это почти не говорят, а для меня это самое заметное изменение в рабочей неделе. Раньше дорогим был ввод текста, зато голова была занята одной задачей. Сейчас ввод текста бесплатный, а голова занята пятью задачами сразу.

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

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

Вывод. Освободившееся от набора кода время уходит на решения и переключение контекста. Свободным оно не становится.

Зачем я пишу свои скиллы

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

Сначала мне казалось, что проблема в памяти. Я перебрал с десяток систем, сделал про это отдельную статью^[16] и доклад. Память помогает, но проблему не закрывает: агент может прекрасно помнить договорённость и всё равно не сделать того, что из неё следует.

Потом я перепробовал готовые процессные наборы: Spec Kit, OpenSpec, superpowers и ещё пару. Все они заточены под конкретный процесс, и этот процесс не сошёлся с моей картиной мира. Spec Kit и superpowers оказались для меня слишком тяжёлыми — ритуала больше, чем работы. Лёгкие наборы приятнее, но у них зеркальная беда: совет можно вызвать, а можно не вызвать. Если никто не позвал нужный скилл, никакого процесса нет, есть текст в репозитории.

Отсюда и вырос мой набор^[17]. Основная мысль простая: рекомендации и гарантии должны жить отдельно. Рекомендация — это текст в SKILL.md; модель может его прочитать, а может переопределить локальными инструкциями проекта. Гарантия — это проверка, которая роняет коммит. Поэтому заполненный markdown-файл сам по себе ничего не доказывает: набор проверяет связи между требованием, задачей и доказательством, допустимость переходов в жизненном цикле задачи и принадлежность каждого коммита конкретной задаче.

Живая эксплуатация быстро убрала из этой схемы красоту. Обязательная проверка документов после обновления набора заблокировала работу на несколько сессий подряд: формально правильно, практически невыносимо. Пришлось разделить «установка работает» и «документы в порядке». А доказательства прогона тестов по-прежнему приносит сам агент со своей машины. Без серверного CI они честные, но ничем не защищены от подделки. Если проверку выполняет тот же, кого проверяют, это ещё не проверка.

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

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

Почему многие не могут начать

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

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

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

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

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

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

Поменять картину мира сейчас труднее, чем выучить что-то с нуля. Новичку нечего ломать, он просто учится. Человеку с двадцатью годами опыта надо сначала признать, что часть этого опыта перестала быть преимуществом, а это работа куда более неприятная.

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

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

Вывод. Перестроить процесс труднее, чем поставить ещё один инструмент: вместо вопроса «как написать» приходится отвечать «что должно получиться и как я это проверю».

Так кто такой продуктовый инженер

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

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

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

У Чада Фаулера это сформулировано без романтики: работа инженера переезжает из набора кода в описание намерения и проверку результата^[18].

Вывод. Продуктовый инженер отвечает за обещания системы; сегодняшняя реализация этих обещаний может быть заменена, и это нормально.

Что я из этого вынес

Сведу к тому, что я у себя реально поменял.

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

Я перестал спорить о том, настоящая ли это разработка. Спор был бессмысленным во времена Delphi, бессмысленен и сейчас. Интереснее другой вопрос: что человек обязан уметь, чтобы результат можно было выпускать. Мой ответ — уметь сказать, что система обязана сохранять, и уметь это проверить. Всё остальное генерируется.

Я перестал ждать, что станет легче. Не станет. Станет интереснее и тяжелее одновременно, и к этому стоит быть готовым. Вечера агенты не освобождают, они освобождают руки и загружают голову.

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

Чего у меня по-прежнему нет — правила, где заменяемость перестаёт окупаться. Хорошие проверки дорого делать. Фаулер пишет прямо: долговечные проверки сложнее кода, который они задают^[19]. Для внутреннего инструмента, который меняется раз в полгода, городить всё это бессмысленно. Для того, что меняется еженедельно, — обязательно. Между этими двумя случаями лежит вся реальная работа, и границу я пока определяю на глаз.

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

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

Если вы уже нашли границу, где заменяемость перестаёт окупаться, напишите. У меня она пока на глаз.

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

Выводы

1. До генерации ответьте, для кого продукт, что он обещает и что делать при отказе.

2. Проверка гипотезы и строительство системы — разные режимы работы.

3. Выигрыш от генерации сразу создаёт счёт за проверку.

4. Дешевле стала реализация, а не знание о том, что система обязана сохранять.

5. Зелёные тесты подтверждают только то, что вы догадались проверить.

6. Найденное в коде знание сначала возвращайте в спецификацию.

7. Проверяйте путь пользователя и измеряйте результат, а не ощущение скорости.

8. Новое правило должно упасть на намеренно сломанном примере.

9. Время от набора кода уходит на решения и переключение контекста.

10. Процесс существует ровно настолько, насколько проверяется механически.

11. Вместо «как написать» теперь важнее «что должно получиться и как я это проверю».

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

13. Беречь стоит границы, причины решений и проверки; реализацию можно заменить.

Источники

1. Архитектура ИИ-агента с желаниями или цифровой человек

2. Andrej Karpathy, пост от 2 февраля 2025 года — «fully give in to the vibes, embrace exponentials, and forget that the code even exists»; там же: «It’s not too bad for throwaway weekend projects».

3. Simon Willison, Will the future of software development run on vibes? — «Vibe coding your way to a production codebase is clearly a terrible idea. Most of the work we do as software engineers is about evolving existing systems…».

4. What is Electron? — «By embedding Chromium and Node.js into its binary, Electron allows you to maintain one JavaScript codebase and create cross-platform apps that work on Windows, macOS, and Linux — no native development experience required.»

5. Fred Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, Computer, 1987, DOI 10.1109/MC.1987.1663532 — «The most a high-level language can do is to furnish all the constructs that the programmer imagines in the abstract program.»

6. Chad Fowler, Compile to Architecture — «The problem is no longer producing code. The problem is replacing it safely.»

7. Pets vs. Cattle — «99% написанного разработчиками кода будет просто выброшено на свалку».

8. Spec-driven development with AI: Get started with a new open source toolkit — «you describe your goal, get a block of code back, and often… it looks right, but doesn’t quite work.»

9. Fred Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, Computer, 1987, DOI 10.1109/MC.1987.1663532 — «I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.»

10. Chad Fowler, Regenerative Software, глава 5 «Designing Evaluations», раздел «Where Evaluations Fail You», Early Release — «One hundred percent coverage told us how much of our code had run, never whether we had captured what a teacher needed on a Tuesday morning.»

11. Chad Fowler, Evaluations Are the Real Codebase — «The intent, the constraints, the behavioral requirements were all implicit in the implementation rather than explicit in artifacts that survive the implementation’s death.»

12. 2025 Stack Overflow Developer Survey: AI — «AI solutions that are almost right, but not quite» — 66%.

13. METR: исследование начала 2025 года — «When developers are allowed to use AI tools, they take 19% longer to complete issues»; обновление от февраля 2026 года — «For the subset of the original developers who participated in the later study, we now estimate a speedup of -18% with a confidence interval between -38% and +9%.»

14. T-shaped skills — «The vertical bar on the letter T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own.»

15. Chad Fowler, Evaluations Are the Real Codebase — «if reimplementing your service in a different language would invalidate your test suite, your tests are specified at the wrong boundary».

16. Память AI-агентов: что помнить, где хранить и как забывать

17. shady2k-skills — страница проекта, исходники на GitHub

18. Chad Fowler, Relocating Rigor — «The engineer’s job shifts from typing code to specifying intent and verifying outcomes.»

19. Chad Fowler, Evaluations Are the Real Codebase — «writing durable evaluations is hard. Genuinely hard. Harder than writing the code they specify.»