State of Product 2027 Всем кто «запутался» — читать отчет от Atlassian среди 1000 продактов Ключевые поинты: 1️⃣ 80% PM говорят, что AI помогает шипить быстрее, но клиенты не получают ценность раньше. 2️⃣ 61% отмечают рост тех.долга от AI, при этом мало команд выделяют время на его погашение. 3️⃣ 67% согласны, что сложно чётко определить свою роль — границы с Engineering и Design размылись 4️⃣ 76% обеспокоены тем, что их продукт не добьется успеха на рынке 5️⃣ 89% обеспокоены конкуренцией со стороны компаний, изначально разрабатывающих ИИ 6️⃣ 99% продуктовых команд полностью интегрировали ИИ хотя бы в один рабочий процесс, а 96% утверждают, что как минимум в одной области он работает на уровне человека или лучше. 7️⃣ 77% считают что интуиция руководителей регулярно перевешивает данные 8️⃣ 33% продакт-менеджеров используют ИИ для приоритизации 9️⃣ 82% говорят, что участники команд регулярно создают с помощью ИИ работу низкого качества, не прикладывая особых усилий, а затем дорабатывают её по обратной связи. Примерно 50% тратят время на проверку результатов работы агентов и на то, чтобы удерживать их в рамках задачи === classic 🚬

Постоянная рубрика "блекпилл недели по AI коду." После предыдущего болезненного опыта, где я обнаружил, что агенты ужасно пишут код и за ними потом надо неделями разгребать слоп, я задумался как быть. Это новая реальность разработки софта и мне как СТО нужно придумать как существовать в новом мире. Изучая, что придумали более умные люди, я понял: ничего. Никто не знает как жить в новом мире, когда один разработчик производит столько кода, сколько в прошлом мог производить целый отдел. За пределами твиттера проблема известная (т.е. большие компании вроде Cloudflare и GitLab уже написали блог-посты), но решения никто не нашел. На основе своего и чужого опыта придумал гайдлайны по AI разработке для нашей команды. Основные предположения: 1. Код важен. Код это то, что действительно исполняется, а значит единственный источник истины. Все спеки это в лучшем случае искаженные описания кода, а чаще всего просто слоп-эссе на тему. 2. AI агенты это мультипликаторы скорости генерации кода. При наивном применении они перекладывают работу с автора кода на меинтейнера. 3. Главный ограничивающий ресурс это понимание кодовой базы разработчиками. 4. Деградация кода неизбежна и поддержание его качества это необходимая работа. 5. Агенты для кода ненадежны и непостоянны. Результат зависит от множества постоянно меняющихся факторов: модели меняются, сетап у всех разный, и так далее. Если что-то работает сейчас, нельзя гарантировать, что оно будет так же работать завтра. 6. Агенты для кода быстро производят техдолг и не могут самостоятельно его уменьшать. Отсюда следующие принципы того, как может работать адекватная система: 1. Необходимо перенести работу по поддержанию качества назад с мейнтейнера на автора. 2. Люди отвечают за дизайн и архитектуру. 3. Люди отвечают за систему верификации: pre-commit, CI чеки, документация и принципы. Только люди редактируют AGENTS.md и постоянные доки. 4. Все правила, которые можно, нужно превращать в механические чеки, потому что промптинг не гарантирует, что агенты будут их соблюдать. 5. Борьба со слопом закладывается в бюджет. 6. Минимизируем человеческие затраты на ревью, максимально автоматизируем проверки и контроль качества. Первый пункт самый главный: можно вайбкодить как угодно, если в результате у тебя рабочий код который ты понимаешь. И конкретные практики: 1. Каждый PR не более +2к строк кода. Эмпирически найдено, что больше отревьюить невозможно. 2. Автор каждого PR сам пишет его описание по шаблону и указывает какие сущности за что отвечают. 3. Очень жесткие pre-commit и CI чеки. 4. Кастомный код-ревью бот в CI, который отсматривает каждый дифф и весь PR в целом с целью доказать, что он сломан. Промптится логом прошлых инцидентов, который пополняется только людьми. 5. Люди дизайнят скелет своих изменений в AI-assisted режиме, агенты заполняют пропуски. 6. Доки пишутся людьми, агентам запрещено их редактировать. 7. Разгребание слопа закладывается в планирование. Всю карьеру (в эру кожаного кодинга) я считал pre-commit чеки очень бесячими и не особо полезными. Теперь же у нас самые жесткие чеки и линтеры в моей жизни. Там как базовые вещи вроде ruff и black, так и кастомные правила import linter, и многое другое. Я постоянно завожу что-то новое. Например, недавно добавил проверки на вложенность и цикломатическую сложность функций из SlopCodeBench. На днях появилась проверка всех диффов с помощью Jev. Это более-менее сработало. Pre-commit с механически забитыми правилами позволяет видеть не совсем слоп на этапе ревью. Очень жесткий CI обеспечивает то, что слоп обнаруживается до мержа, а не после. Но появились новые проблемы. Самая главная: актор с критиком могут очень долго итерироваться над PR без видимого прогресса. Агент делает изменения, ревьюер находит блокирующие проблемы, агент делает заплатку, ревьюер находит следующую дыру и так далее. Я видел как это происходило буквально днями, до тех пор, пока я не погружусь и не разберусь: в чем же корень проблемы? Ни одна модель (вклюбчая Fable и Astra) пока ни разу не смогла сама выбраться из этой спирали. Вытекающая проблема: медленно. Теперь беклог PR разгребается гораздо медленнее, чем пополняется. У агентов как будто появляется новый инструмент: защита (своего кода) заебыванием. Когда ревьюер в десятый раз находит ошибку в каком-то PR возникает очень сильное желание вмержить его, чтобы просто больше не видеть. Что иронично: ускорение от вайбкода как будто целиком компенсируется или замедлением на этапе ревью, или, если вы на вайбах, разгребанием проблем в проде спустя пару недель.

# Блекпилл по поводу агентов Я раз в пару месяцев осциллирую по поводу AI тулов для кодинга. Сегодняшняя итерация: я ошибался, вайбкодинг не работает для разработки чего-либо, чем надо пользоваться больше одного раза. И никогда не работал. Я думаю, что агенты (claude code/codex) производят технический долг быстрее полезного кода. При этом они не умеют его разгребать. Проект с агентами быстро слопизируется, но деслопизировать его агентами невозможно. Для продуктивности получается net negative: в конечном итоге тратишь больше времени на разгребание слопа, чем если бы делал работу руками, и получаешь результат хуже. Это речь про кодинг тулы которые вообще-то предполагают постоянное участие человека (но не работают даже с ним). Самоулучшающиеся харнессы, лупы и автономные агенты не работают совсем кроме как для хаканья бенчей. За лупы получают пользу и деньги только продавцы токенов. Редкие медийные случаи, где самоулучшающийся агент что-то сделал, я списываю на то, что миллион вайбкодеров что-то слопили и у одного что-то на чем-то выстрелило. Но это не обобщается и в целом гораздо сложнее и дороже, чем просто сделать самому. Я делаю такие выводы как лудик со справкой (у меня недавно были $200 подписки на кодекс и на клод) и своим скиллпаком. До недавних пор я думал, что всё неплохо работает, но за последние пару недель: - Дал Opus 5 статью, объяснил зачем она нужна, сказал реализовать и провести эксперимент, провел свой полный spec-driven workflow, тщательно ревьюил спеки и запускал актор критик луп, кросс-чекал план кодексом. Два дня итераций спустя стало понятно, что он реализовал не то, что в статье, а что-то наподобие, но назвал тем же именем. Все эксперименты были впустую. - При рефакторинге генератора синты, где надо было просто разложить файлы по папочкам, Codex выкинул 90% функционала. Но так, чтобы не было заметно. Это при том, что сначала я сделал тщательный план этого рефакторинга, валидировал его и результат свежими прогонами агентов. Потеря была замечена только когда репа уехала далеко вперед, поэтому возвращение функционала потребовало очень много работы Клода. - У меня был PR на который я более 10 раз запускал Fable с запросом "сделай код ревью, найди баги, поправь" и он каждый раз говорил, что все готово, но так же каждый раз находил новые баги. Но больше всего впечатлил другой случай. Архитектура нашей модели позволяет работать с видео с разными fps. Главное подать на вход какой таймстемп у какого фрейма. Так вот я случайно обнаружил, что в коде подготовки одного из видео датасетов настоящие таймстемпы фреймов выкидываются и вместо этого вычисляются из индекса фрейма и fps видео. Человек никогда не напишет такого ужаса. Дойдя до момента, когда надо откуда-то взять таймстемпы, он задумается откуда их взять. Потому что ему будет лень реализовывать целую новую логику, чтобы продвинуться. Агенту же не сложно написать любое количество новой логики. Для меня это доказательство: агенты делают не такие баги, как люди. Техдолг от агентов особый, агентский, и любой агентский код может быть полон очень сложных хаков которые не обнаруживаются тестами. И самое неприятное, что агенты не способны устранять агентский техдолг, потому что их правки содержат такой же слоп. Мне сначала показалось, что в нашем проекте стали происходить такие случаи, потому что мы перешли некую границу, после которой вайбкод не работает. Но потом я обнаружил слоп в нескольких старых местах, в которых я был уверен. Значит вайбкод никогда не работал, просто час расплаты был отложен тем, что агенты хорошо создают видимость работы. И хорошо формируют ошибочную ментальную модель проекта у пользователя. Я думаю поворот не туда произошёл когда мы решили, что в код можно больше не смотреть. Агенты недостаточно хороши, чтобы быть автономными. Они хорошие мультипликаторы усилий инженеров. Но мультипликатор плюс слепой инженер смотрящий только на объяснения самой модели это мультипликация слопа. Причём впервые это не выглядит как проблема слишком глупой модели. Почему-то работать с Sonnet 5 проще, чем с Fable, Opus 5 или GPT 5.6. Теперь чем умнее модели, тем более креативно они тебя обманывают. Парадоксальным образом быстрый Sonnet 5 в режиме ассистента в Zed, как в старые добрые, ощущается гораздо продуктивнее, чем медленный Fable который долго пыхтит и очень умно делает совсем не то. Возможно пик AI тулов для кодинга это всё ещё TAB автокомплит и задачи для агента уровня "напиши тест для этой функции." Попробую пересесть на Zed и такой режим на время.

Мой батя ебашит вообще адовые АИ-решения. Ну такой вот примерно рецепт усредненный, потому что вариаций масса. Берется старый промпт, он не читается, читать — это не про моего батю. Он берет этот промпт, вываливает его в чат, сверху хуярит system message на три экрана и начинает докручивать. Добавляет туда огромное количество контекста, ролей, ограничений, few-shot примеров, chain-of-thought, JSON schema, temperature 1.2, RAG, векторку, агентность и КОСТЫЛИ! для стабильности, сверху еще “act as senior developer”. Все это гоняется по кругу, пока логи не начинают плеваться эксепшенами, а модель — уверенно нести хуйню. Потом батя снимает это с локалки и сразу выкатывает в прод. Потом заносит обратно, навесив сверху retry, regex-парсингом, костыльными валидациями и “ну у меня же работает”, начинает юзать. При этом дебажит прямо в проде, тыкая curl’ом по эндпоинтам. Сидит и приговаривает полушепотом: ух бля, GPT мощь. При этом у него на лбу аж пот выступает, потому что токены горят, контекст распух, а модель уже третий раз забыла, кто она и зачем живет. Любезно мне иногда предлагает заревьювить, но я отказываюсь. Надо ли говорить о том, какой дичайший техдолг потом? Наследие такое, что документация от репозитория отклеивается.

На мой взгляд видео уже устарело. Могу согласиться, что большинство моделей не могут в хорошую архитектуру. Но стоит попробовать новейшие модели - GLM-5.2 или топовые Клода, как понимаешь, что архитектуру он делает лучше, чем большинство разработчиков.

Это очень опасное заблуждение, которое возникает из-за того, что на уровне кода (одного приложения) ИИ может выдавать результат, который работатет (проходит тесты). Архитектура системы - это другой разговор. Первое: архитектура оценивается не в моменте, а на дистанции. Хорошая архитектура позволяет сопровождать и развивать систему в течение длительного времени. Проблема в том, что даже самые сильные ИИ-модели принимают решения, которые накапливают техдолг - неверные границы доменов, жесткое зацепление, слабая связность, дублирования и т.д. На дистанции 2–3 месяцев (без человеческих корректировок) внесение изменений в проект порождает эффект домино и кучу побочек. ИИ не "видит", какие части системы меняются синхронно, какие требуют унификации в виде общих интерфейсов и абстракций, часто LLM создаёт распределённый монолит, вместо микросервисов и т.д. Второй момент — есть разница между архитектурой приложения (архитектура на уровне кода) и системной архитектурой. По приложению довольно много типовых схем, которые ИИ может воспроизвести и под контролем человека даже более-менее сопровождать. Системная архитектура - это всегда компромисс между стоимостью, рисками и конкретными ограничениями: бюджетом инфраструктуры, легаси, требованиями регуляторов, реальной командой, которая будет это развивать. ИИ выдаёт архитектуру которая не учитывает нюансов, эта архитектура некая средняя температура по полате, которая получиалась из кучи схем, используемых в обучении, В результате решения не соответствуют конкретной ситуации и не решают проблем системы.