# Блекпилл по поводу агентов Я раз в пару месяцев осциллирую по поводу 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 и такой режим на время.

Что случилось с Cursor? Он стал непопулярен? Разбираем 👇 Если коротко, то: нет, скорее изменилась сама экосистема AI-инструментов. В 2024–2025 годах Cursor был практически синонимом AI-кодинга. Если человек хотел попробовать «вайбкодинг», чаще всего он устанавливал именно Cursor. Но за последний год рынок сильно изменился. Во-первых, появился и стремительно вырос Claude Code. Многие разработчики перешли на него из-за более сильных агентных возможностей и удобной работы с большими проектами. Во-вторых, OpenAI активно развивает Codex, GitHub Copilot продолжает занимать корпоративный сегмент, а также появились Windsurf, Kiro, Jules и десятки других решений. Сегодня разработчики уже выбирают не один инструмент, а собирают собственный стек под разные задачи. При этом говорить, что Cursor непопулярен будет тоже некорректно. Многие компании продолжают использовать его параллельно с Claude Code. Например, недавно стало известно, что Disney оставляет Cursor среди основных инструментов разработки наряду с Claude Enterprise, несмотря на отказ от GitHub Copilot. Почему тогда создается ощущение, что про Cursor стали говорить меньше? В 2026 год сменился тренд. Суть тренда в том, что мы выбираем не конкретный редактор, а AI-агента или подборку агентов. Уже не столь важно, где вы будете писать код, поэтому конкретно Cursor обсуждают не так активно. Кстати никогда не спрашивала вас: А вы использовали Cursor?

А нам точно нужны code agents? Фича маленькая, а дифф прилетает на +1500 −1400. Через пару дней запрос на следующую фичу в тот же модуль, и агент снова перелопачивает всё, снова 1500 строк на ревью. Прочитать такие объёмы в таком темпе невозможно физически, и после нескольких итераций ты перестаёшь понимать сервис, в котором ещё вчера свободно чинил баги на лету. Когнитивная нагрузка взлетает до небес, хотя разработчик должен был бороться со сложностью, а не плодить её. На возражения обычно отвечают, что агент это как команда из десяти сеньоров. Только команда несёт ответственность и становится предсказуемой, а модель забывает контекст, повторяет те же ошибки и десять раз за час соглашается с любым «вы правы». Обсудим, где проходит граница между LLM как вторым мнением и LLM как автором кодовой базы.

SWE-Bench Pro умер и больше не подходит для измерения моделей, – расследование OpenAI Некоторое время назад OpenAI выпустили статью, в которой заявили, что один из самых популярных бенчмарков для оценки способностй моделей в кодинге – SWE-bench Verified – больше не работает. Они нашли в нем кучу проблем, сказали, что результаты на нем мало чего стоят, и призвали всех переходить на SWE-Bench Pro. Подробности вот: t.me/data_secrets/8779. Это было в конце февраля, менее 5 месяцев назад. И угадайте, что? Сейчас OpenAI объявили, что провели аналогичный тест для SWE-Bench Pro, и он... тоже оказался сломан. В случае с SWE-bench Verified основная проблема состояла в том, что модели воспроизводят решения "по памяти" из-за утечек задач в обучающие датасеты. Здесь же проблема скорее в самих задачах. Дело в том, что issues и PR из опенсорсных репозиториев изначально создавались для человеческого сотрудничества через долгие переписки и уточнения, а вовсе не как изолированные, чистые задачи для оценки моделей. В частности, всплыли такие проблемы: – Слишком строгие тесты, которые навязывают конкретные детали реализации, не указанные в условии задачи, из-за чего множество функционально корректных решений отбраковываются. – Тесты с низким покрытием, которые, наоборот, недостаточно проверяют запрошенную функциональность, из-за чего неполные решения все равно проходят. – Вводящие в заблуждение условия, которые направляют модель к неверному поведению или прямо противоречат тому, что требуют тесты. OpenAI оценивает, что примерно 30% задач SWE-Bench Pro сломаны (автоматический пайплайн проверки пометил как испорченные 200 задач, а кампания ручной аннотации людьми – 249 задач, то есть 34,1%). Когда 1/3 задач бенчмарка – с такими ошибками в условиях, доверять ему сложно, поэтому OpenAI формально отзывает свою прежнюю рекомендацию использовать SWE-Bench Pro и "надеется, что сообщество разработает новые бенчмарки, созданные специально для тестирования возможностей моделей". openai.com/index/separating-signal-from-noise-coding-evaluations/