Разработка после разработчиков. Что оставит AI?

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

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

Эксперимент: делаем сложный продукт с нуля

Сначала немного про сам эксперимент. Цели эксперимента две:

1. Создать что-то сложное и прикладное, что не умрет как 90% всего что пишут с AI

2. Расковырять весь процесс AI-assisted кодописания и поделать выводы

В качестве инструмента я взял Claude Code Max за $200/мес, сделал ему максимальный трейсовый обвес на каждое действие и взялся за дело. В качестве продукта — то, что так хотел себе уже давно — универсальную оценивалку LLM под любой проект: конструктор evals, генератор в них данных через разные LLM, оценка через кастом и deepeval, дашборды и вот это все классное и полезное.

То есть, это такой Evals-Runner для любого LLM-based проекта в промышленных масштабах. Штука достаточно сложная, чтобы и снять хорошую телеметрию для оценки и чтобы без кожаного погонщика здесь с одного промпта ничего не получилось. И достаточно прикладная, чтобы это не стало еще одной бесполезной MVP-игрулькой.

«С нуля» — здесь именно реализация, потому что экспертиза в evals у меня есть, а наработок вокруг них много. Мне нужно было собрать это воедино и превратить в нечто финальное, что можно смело отдать другим пользователям уже завтра.

И да — код писать руками не будем, я хотел на него даже не смотреть (но не вышло). Будем учиться жить в новой парадигме.

Здесь хочу сделать отступление. Я научился профессионально писать код с помощью LLM и мне безумно не нравится устоявшийся термин «вайб-кодинг». Сравнивать просто голожопый вайб-кодинг и профессиональный Agentic SDLC — это примерно как сравнивать драку бомжей на вокзале и битву мастеров спорта по боксу на ринге. Дерутся и те и другие, но некоторая разница в подходах все же имеется.

Готовим Claude Code: телеметрия

Как любой уважающий себя технарь, я решил пилить свой велосипед специально под эксперимент. Это локальный observability-стек: все события Claude Code я хукаю и сохраняю их трейсы — сначала как сырые JSONL по дням, проектам и сессиям. Потом это конвертится в Parquet, дальше DuckDB для витрин и визуализация в дашборде.

Эта штука позволяет мне оцифровать ВЕСЬ процесс: видно какие промпты я писал, сколько было вызовов тулов, какие bash-команды выполнялись, вся внутренняя коммуникация агентов и прочее. Это coding workflow telemetry — в любой момент можно ответить на главный вопрос: сколько стоила конкретная фича, можно ли сделать ее лучше и можно ли сделать вообще без меня (про это будет моя следующая статья).

##### Первичная структура хранения, сейчас оно подтюнено под потребности ##### В сессиях еще есть разделение на main-agent и subagent data/ ├── raw/ │ └── date=YYYY-MM-DD/ │ └── project=<project_id>/ │ └── <session_id>.jsonl ├── parquet/ │ └── events/ │ └── date=YYYY-MM-DD/ │ └── project=<project_id>/ │ └── part-<timestamp>-0.parquet ├── state/ ├── dashboards/ ├── logs/ ├── sql/ ├── services/Пример трейса на внутренний tool-use (поиск по коду)

А на выходе можно собирать шикарные вещи типа таких:

И потом еще более крутых (но именно про экономику разработки конкретных фич и всей разработки я напишу позже):

Но просто наличие телеметрии не переводит вайб-кодинг в профессиональную лигу. Телеметрию нужно анализировать, код — проверять тестами, sanity/health чеками и потом еще и логически (чтобы агенты не решили вдруг выпилить весь постгрес из проекта). Все это называется harness — промышленная обвязка вокруг процесса, но ее построение не являлось целью статьи.

Давайте уже писать код. И да, все делалось через Opus 4.6 на high effort. Я считаю, что флоу важнее конкретных моделей, но фиксируем для чистоты эксперимента.

Часть 1. Сборка продукта

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

Дальше — отзывчивость. Хочу, чтобы каждое действие в UI имело моментальный отклик и уведомление о каждом действии на бэкенде. «Проверь что UX отзывчивый, если ты не сделал SSE (server-sent events), то сделай именно его». И снова вжух — готово.

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

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

Я знаком с похожим функционалом, и в прошлой эпохе сложный UI-генератор требовал десятки часов фронтендера плюс обязательный синк с бэком. Сейчас у меня ушло 2 часа, НО! Я очень хорошо знал, чего хотел, и такие штуки на платформах в целом делать умею.

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

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

Но проверять именно смысловую реализацию, а не то что код разломался и не собирается — все это достаточно неплохо автоматизируется и отличает ai-разработчика от случайного вайб-кодера. В истории «да у меня тут 300 агентов сами друг за другом исправляют и ващеее» я пока промышленно не верю, но эксперименты прикольные.

Грепософия как культ

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

Claude Code делает сборку контекста через планирование и большое количество комбинаций вокруг grep/glob. Пришел запрос на фичу X — составляется карта слов этой фичи, накидывается план поиска, затем оно все ловко нагрепывается и умело собирается в контекст:

Скриншотик, показывающий насколько там все ловко-смело и умело:

А вот очень плохой пример. Я заказал совсем крошечную фичу, а оно вызвало под 80 инструментов и моментально сожгло 60 тысяч токенов. Что произошло? Я всего лишь попросил подправить логику кнопки с группами пользователей.

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

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

Метрика спасения

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

И в один момент график джойнов резко пополз вверх и пришлось делать пост-мортем.

Часть 2. Сломанная архитектура

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

И произошло страшное: мы там разъехались с опусом в интерпретациях. Изначально я запланировал «проекты», но по мере обрастания функционалом понял, что хочу «рабочее пространство» (workspace) — аналогичную сущность, но со своими настройками. Я ожидал, что проекты органично переделаются в пространство. А Claude Code решил, что это новая сущность — и добавил ее, попутно переписав кучу кода и наклепав новых джойнов.

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

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

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

Промежуточные выводы эксперимента

В итоге за несколько дней я сделал шикарный инструмент с хорошим UI, полным функционалом, всеми видами тестов — e2e/функциональными/киберсек, и готовым к разворачиванию с хельм-чартами и прочим важным — и это было prod-ready решение. И хватило одной месячной подписки, я не выбился за лимиты.

Пример из дашборда где-то под финал проекта (токены out здесь это именно out, без внутренних thinking и planning):

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

Что мы имеем?

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

Вывод 2: AI принимает архитектурно/продуктово правильные решения — но для задачи, которую он понял, а не той, которую вы имели в виду. Критически важно синхронизировать смысл и следить за тем, что делается, но без экспертизы такие расхождения почти невозможно отловить

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

Часть 3. Эпоха универсалов и тишейпов

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

Да, многое смежное я руками делаю сильно хуже, чем профильный спец, но это все было ДО. Сейчас именно широта умений или универсальность (которую еще называют T-shape) — это прям настоящая новая суперсила.

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

Но я на примере себя пишу не про себя. У меня здесь эксперимент. Я пишу про первый мир.

Мир первый: технари

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

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

Мир второй: нетехнари

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

У одних хороший код и средние продукты, у других хорошие продукты и плохой код, но генерят продукты оба лагеря. И все это приводит нас к интересному явлению, которого не было до этого.

Софт как шаурма

Эти два мира будут сильнее разъезжаться: будет создаваться большое количество ситуативных продуктов — примерно как шаурма на районе, которая кормит лишь определенный круг людей вокруг и немного случайных прохожих. Маленькие, крафтовые, быстрые, почти персональные и уютные. Такого микрософта (хаха) под себя или точечно под нескольких клиентов будет становиться все больше.

Но технологии сложнее. Почти всегда технологию можно выразить как «вы получаете 60% хотелок из коробки и экспоненциальную сложность улучшения следующих процентов». Да, кому-то хватит и 60%. Кому-то хватит кривых поделок, решающих их задачу. Кто-то будет рад платить 3х за Low-Code/No-code, создающий им ценность. Это новые рынки и новая занятость.

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

Грандиозные идеи и легаси

Для чего-то грандиозного эти миры снова будут вынуждены сойтись, но уже гораздо меньшими (но более звездными!) командами — потому что непонятно, зачем нужно 20 человек там, где можно справиться втроем с разными core-компетенциями.

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

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

Куда еще мы можем свернуть

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

Одноразовый софт (UI on-demand): сверхбыстрый инференс (на чипах вроде Cerebras) позволит собирать интерфейс за миллисекунды под конкретный запрос — решил задачу, закрыл, забыл, софт исчез. Хорошо зайдет для аналитики и дашбордов, но мышечная память и когнитивная нагрузка от постоянно меняющихся UI не дадут этому захватить все.

LLM as UI: LLM становится новым браузером, все остальное — его tools/skills. Браузер кардинально изменил потребление софта и его разработку, но приложения в телефоне никуда не делись — специфика беспощадна. Попробуйте неделю вызывать голосом такси без карты — это травмирующий опыт, во многих задачах нам нужен визуальный контроль.

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

Скорее всего нас ждет комбо: что можно не показывать — показываться не будет, под сиюминутные штуки сгодится одноразовость, а что заменить нельзя — останется как есть (на дворе 2026 год, а на рынке до сих пор есть вакансии по Delphi).

Финал

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

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

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

AI изменит многое, но ответственность за смысл, качество и масштабирование все еще за людьми.

Спасибо!

Мой крафтовый тг-канальчик Agentic World (подписывайтесь!) и другие статьи:

• Когда лопнет пузырь AI?

• Как я делаю своего голосового AI-ассистента: роботы пишут код и работают, когда я отдыхаю