Женя, расскажи про AI

Как LLM навсегда изменили тестирование

Если вы читали хотя бы одну статью про тестирование IT-продуктов, то наверняка где-то близко к началу была фраза вроде: «Пишите поведенческие тесты».

Возможно, вы даже слышали золотое: «Write tests. Not too many. Mostly integration». Как же эта фраза переворачивала мировоззрение разработчиков всего пару лет назад! 🥹

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

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

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

Ну, значит, всё-таки ограничиваем LLM? Нет.

У LLM есть одна особенность: они не страдают от нашей слабости «наверное, опять ложное срабатывание». Даже если LLM посчитает, что тест «просто не проходит», то в большинстве случаев она оставит этот тест и скажет вам, что он падает. Так что если ваша LLM хочет протестировать, насколько пикселей скруглен элемент, — пускай дерзает! Если ей вдруг приспичит обратиться к элементу по классу — разрешите! Она решила протестировать сценарии, которые вы не планировали покрывать тестами? Вам же лучше!

Так в чём польза? Дело в том, что тесты деталей реализации помогают LLM. Она запустит их, увидит, что они падают, и пойдёт разбираться почему. Если она поймёт, что это сделано по запросу пользователя, то изменит или удалит тест, а если нет — исправит код.

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

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

Вы скажете: «А как же скриншотные тесты?». На что я отвечу, что это не панацея. Они тоже нужны, но уже для нас. Для LLM они не помощник: слишком долго дожидаться результата, а даже если модель дождётся, то на чтение скриншотов уйдёт весь контекст (я проверял). При этом скриншотные тесты не теряют своей пользы — мы всё также можем убедиться, что с интерфейсом всё в порядке своей парой глаз.

Ну и вообще, не боритесь с LLM. Бороться с LLM — изначально глупая затея. Вы поставите ей правило, она придумает, как его обойти; вы улучшите правило, она придумает, как его перепрыгнуть; вы сделаете правило пуленепробиваемым, она принесёт динамит. Это как биться головой об стену — рано или поздно стена победит.

Примите правила игры. Перестаньте ограничивать LLM. Направляйте её.

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

Дальше пусть разбирается сама — написала фигню? Её искусственной голове болеть по этому поводу. Ваша реальная голова только выиграет от ещё одной проверки.

Они сделали это!!!

Всего пару недель назад я писал пост о том, как у меня горит с Playwright MCP. Что ж, видимо, ребята из Microsoft меня читают, потому что они представили убийцу Playwright MCP — Playwright CLI.

Я искренне не понимаю, почему создание этого инструмента заняло столько времени, ведь он, по сути, делает всё то же самое, что и Playwright MCP, но с помощью терминальных команд вместо обращения к LLM. Кажется, что чуваки и мой пост «MCP вам не бро» прочитали, ведь работа над ошибками началась через неделю после того, как он вышел 😁

Шутки шутками, но факт в том, что теперь Playwright CLI — лучшее решение, чтобы дать вашему агенту доступ к браузеру. И я уверен, что оно станет стандартом рынка на долгие годы вперёд.

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

npm install -g @playwright/cli@latest
playwright-cli install --skills

Главный прорыв, конечно, в том, что они ушли от набившего оскомину MCP. В своём видеоанонсе они показывают, что одну и ту же задачу Playwright MCP решил, использовав 114к токенов, а Playwright CLI понадобилось всего 27к. В четыре раза меньше! Лучшего подтверждения моим словам из более ранних постов и не придумаешь.

Также, если вы помните, у MCP было второе ограничение, о котором я писал: в нём доступны не все инструменты. Причина всё та же — контекст. Ребята просто не могли запихнуть в Playwright MCP все инструменты, так как они заняли бы очень много места. Угадаете, для чего контекст почти не тратится? Верно, для того, чтобы рассказать агентам, какие команды доступны в терминале. Причём провернули они это элегантно, просто создав пачку скиллов.

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

Таким образом, Playwright CLI — это идеальный инструмент: стабильный, быстрый, не пытающийся сожрать все ваши токены и позволяющий делать в браузере всё то, что там делаем мы. У меня от этой недели такое ощущение, что на улице LLM перевернулась фура с крутыми релизами))

Oh, shit... Here we go again

Эти чертяги опять это сделали. Они опять поменялись местами.

Честно, в последние месяцы у меня было ощущение, что мы потеряли OpenAI: Anthropic обогнали их по инструментам для рабочих задач и разработки, GLM-4.7 допинала уже поваленный на землю GPT-5.2 Codex в кодинге, Gemini забрала на себя общение и генерацию картинок, а ролевики вообще сидят на копеечных китайских моделях. Такое чувство, что на всём этом празднике жизни ChatGPT просто не осталось места. Только и осталось психозы с GPT-4o вызывать.

Рынок подумал так же, поэтому как из рога изобилия посыпались новости о том, что Nvidia передумала давать ClosedAI $100 миллиардов. Затем OpenAI запустила рекламу на бесплатном и новом $8 тарифе. В ChatGPT перестал работать режим мышления, и модель стала всегда выдавать мгновенные ответы. И даже этого OpenAI было мало, так что они продолжили себя закапывать, предложив платить комиссию за открытия, совершённые с использованием их LLM. По итогу всех этих событий я и ещё несколько людей, которых я знаю, отменили подписку на ChatGPT.

Представляю себе офис Anthropic на фоне новостей. Как они открывают бутылочку игристого, и тут музыка глохнет...

Opus 4.6 получился, мягко говоря, сомнительным. Да, в System Card они рассказывают о том, насколько модель получилась великолепной, как она опережает Opus 4.5 почти во всех аспектах... но по факту разницы я не заметил: модель как тупила на одних задачах (например, использовала неправильные команды в терминале, которые вообще не объявлены в проекте), так и продолжила это делать. Из реально интересных фич показали только 1М контекста, но, как вы уже знаете, это просто маркетинговая фишка.

И вот в попытках увидеть разницу между моделями я всё-таки заметил одно такое небольшоооое отличие: МОДЕЛЬ СТАЛА КАПЕЦ ДОРОГОЙ. Anthropic, по всей видимости, поняли, что установили слишком щедрые лимиты в своих подписках и нажали кнопку «oh, shit go back». Я за пару часов спокойной работы умудрился сжечь 30% недельных лимитов в $200 подписке, которую раньше сам же называл «бесконечной». Притом, что в прошлом году я запускал 10 сессий по 10 сабагентов в каждой из сессий параллельно и сжигал лимиты примерно с такой же скоростью. Что ж, это объясняет, для чего появилась эта модель и какие изменения в ней на самом деле произошли.

И я думаю, что Anthropic это сошло бы с рук, но кажется, что они недооценили противника. OpenAI под насмешки выпустили GPT-5.3 Codex и перевернули игру. Посмотрите на график, приложенный к посту. Вот это реальная, немаркетинговая революция.

На графике вы можете увидеть, что GPT-5.3 Codex не стала лучше решать задачи, при этом ей нужно в 4.5 раза меньше токенов, чтобы добиться того же результата. А это значит, что вы потратите в 4.5 раза меньше времени и денег на решение задачи, просто сменив модель. И вы не поверите, но это даже не главное достижение.

Помните, я рассказывал про то, как работает контекст? Так вот: GPT-5.3 Codex не нужно быть умнее, чтобы стать умнее. Она становится умнее за счёт того, что медленнее тупеет.

OpenAI буквально сказали: «Если мы не можем решить проблему с нашими финансами, context rot и скоростью ответов, давайте просто решим проблему с тем, насколько эффективно наши модели генерируют токены, а это решит все остальные наши проблемы». И они, чёрт возьми, справились.

И самое смешное во всей этой истории, что на поверхности ситуация выглядит так, будто именно Anthropic выпустили модель с 1М контекста, в то время как на деле она вышла у OpenAI. Причём вы вообще заценили, как элегантно они совершили этот квантовый прыжок?

Ну и учитывая то, что модели Anthropic в целом генерируют сильно больше токенов (у меня вообще Opus 4.6 работает исключительно как оркестратор сабагентов), то GPT-5.3 Codex ускакала настолько вперёд, что её будет ну очень сложно догнать. Даже как-то грустно за OpenAI: вроде совершили революцию, а вроде никому об этом и не расскажешь (вспоминается тот мем с чуваком в углу на вечеринке).

Anyway, гонка продолжается! Запасаемся попкорном и ждём, когда на сцене появится 1.5 миллиарда китайцев DeepSeek.

Инсайты от Claude Code

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

Ну и иногда во мне просыпается простое человеческое любопытство: сколько сообщений я отправил агенту? Сколько строк кода написал? Какие фичи делал? Какие баги фиксил?

В Anthropic решили помочь с этим и создали команду /insights. Она анализирует ваше общение с агентом за последние пять дней и выдаёт разбор полётов: что было круто, где можно расти и какие лайфхаки вы упустили.

Что в инсайтах:
1. Фичи и статистика — краткое саммари работы за последние пять дней + различные интересные циферки использования.
2. Паттерны использования — как вы вообще взаимодействуете с Claude Code.
3. Продвинутые техники — какие фичи из арсенала пауэр-юзеров вы уже используете.
4. Слабые места — где ваш воркфлоу проседает: повторяющиеся ручные операции, недостаток автоматизации, игнорирование полезных команд.
5. Конкретные рекомендации — чем дополнить CLAUDE.md, какие скиллы стоит создать, какие хуки прикрутить к проекту.
6. Следующие шаги — что ещё есть в Claude Code, что вы не используете.

Самое полезное, что я вынес из своих инсайтов, — это то, что Claude Code можно запускать через GitHub Actions с правами на создание пулл-реквестов. Я в эту сторону даже не смотрел, так как не видел пользы для своего воркфлоу, но после прочтения меня осенило: можно же настроить action на проверку пушей в мастер, чтобы быть уверенным, что последние изменения ничего не сломали. С оповещением на почту или в Telegram и автоматическим созданием PR.

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

Также Rob Zolkos в деталях описал как работают /insights.

Посмотрим, что он расскажет мне ещё через пять дней, но первые впечатления положительные:)

Почему 1М контекста в Opus 4.6 — маркетинговый трюк

Наверняка вы уже слышали, что Anthropic выпустили Opus 4.6, а OpenAI свою GPT-5.3 Codex почти одновременно.

Графики красивые, хайпа много, но что на самом деле стоит за ними? Давайте разбираться.

Сразу спойлер: никакой революции не произошло (впрочем, как и с 1M контекста в Sonnet'ах), но мы постепенно движемся в правильном направлении.

Что нам расказали Anthropic?
1. Opus 4.6 показала лучшие результаты в тесте 8-NIAH, набрав целых 76% точности. Значительно обгоняя Sonnet 4.5 (18.5%) и Gemini 3 Pro (26.3%).
2. Начинания с 200к токенов контекстного окна новая модель будет тарифицироваться по «премиальному прайсингу»: $10 за миллион входных токенов и $37.50 за тот же миллион, но на выходе… Да, c фразой для описания стоимости ребята не ошиблись.

Что это значит нормальным языком?
1. Opus 4.6 на самом деле не умеет работать с большим контекстом. В другом посте я уже рассказывал про тест Needle-In-A-Haystack. 8-NIAH — это тоже самое, но вместо одного кусочка данных по тексту разбросаны уже 8 одинаковых кусочков данных, каждый из которых модели нужно найти. Да, Opus 4.6 стала справляться с этой задачей гораздо лучше остальных моделей... но думаю, что и без моих объяснений понятно, что тест синтетический, нежели, чем практический. А других тестов нам и не показали, следовательно ситуация там плачевная. Для референса: все топовые модели с поиском одной иголки справляются в 100% случаев, вне зависимости от размера контекстного окна.
2. Opus 4.6 никак не решает проблему с ростом стоимости контекста. Во всех моделях, за исключением DeepSeek-V3.2, цена за токен линейно растёт вместе с ростом контекстного окна. Так, если первая тысяча токенов стоит $0.001, то вторая будет стоить уже $0.002, третья $0.003 и так далее. Таким образом, в диапазоне от 200к до 1М контекста стоимость токенов будет составлять от $0.20 до $1.00 за тысячу. Получается, что первые 200к токенов обойдутся вам в $20.00, а следующие 800к в $480.00. То есть относительная цена увеличится в 6 раз. В AI-лабах об этом прекрасно знают в связи с чем сильно задирают ценник на большие контекстные окна.

Собственно, это и есть две причины почему компании ограничивают контекстное окно в районе ~200к токенов: стремительная деградация ответов и взрывной рост стоимости. И да, Opus 4.6, как я и сказал ранее ни одну из этих проблем не решает, а после 200к токенов модель становится настолько дорогой, что всё равно никто не узнает как она тупит на огромных контекстах, ведь никто ей не будет пользоваться. Великолепно разыгранная партия, Anthropic!

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

Чувствую, что в ближайшие пару месяцев китайский кит поразит нас громким релизом DeepSeek-V4.

Я создал редактор для вайб-кодинга

Я устал от современных редакторов кода. Они просто не подходят для написания кода агентами.

Лично у меня есть три проблемы с ними:
1. Воркфлоу для работы с агентами в существующих редакторах — боль. Постоянное переключение между окнами без горячих клавиш, попытки уместить всё на один экран, странное поведение самих редакторов и куча багов в интерфейсах агентов.
2. Несколько проектов = несколько окон VS Code, и между ними приходится прыгать как сумасшедшему. Я так и не придумал, как можно удобно переключаться между ними, как и не нашёл уже готовых решений.
3. Прожорливость. На макбуке с 36 гигабайтами три-четыре VS Code с Claude Code вылетают или начинают свопиться. Мой макбук стабильно по несколько раз в день приходится перезагружать из-за утечек памяти в софте от MicroSlop и Anthropic. 90 гигабайт оперативки на три инстанса VS Code — это нормально в 2026?


Мне это надоело, и я создал Ghost Tab, который решил все мои проблемы и, возможно, решит ваши.

Вот чем он хорош:
1. Две панели в Ghostty. Слева — Git, файловая система, терминал. Справа — Claude Code. Можно менять размеры как удобно и разворачивать любое из окон на весь экран.
2. Проекты живут во вкладках. Настроил путь один раз — потом просто выбираешь из списка при создании новой вкладки. Переключаешься стандартными хоткеями Ghostty, всё мгновенно, никаких танцев с окнами.
3. Дополнительные хоткеи. Помимо того, что предоставляет Ghostty, в редакторе есть свои горячие клавиши, которые ещё сильнее упрощают работу с несколькими проектами.
4. Нет утечек памяти. Терминальный Claude Code любит оставлять зомби-процессы. Мой редактор прибивает всё принудительно, как бы ты ни вышел.
5. Легковесный. Ну, тут даже, кажется, объяснять не нужно: нет прожорливой Electron-обёртки, нет проблем с оперативной памятью.
6. Расширяемость. Вы можете взять за основу мой редактор и изменить его как вашей душе угодно. Хотите заменить Claude Code на Codex или Copilot CLI? Хотите добавить новые горячие клавиши? Убрать какие-то панели? Одна команда вашему агенту, и вы получите редактор, настроенный под вас. Любую часть вы можете поменять и повернуть так, чтобы было удобно именно вам.

Помимо этого, вы можете поставить себе Raycast. Он позволит вам навесить хоткеи для переключения между приложениями. Лично я настроил его так: vibecode-editor открывается через CMD+G, Chrome для просмотра изменений через CMD+H и Arc для всего остального через CMD+J. Это небольшое изменение, но по ощущениям жизнь улучшает не меньше, чем переезд на новый редактор.

Ставьте себе Ghost Tab, и жду вашего фидбека здесь или на GitHub:)

Moonshot AI предлагает скидку на подписку на Kimi

Загвоздка в том, что вам нужно убедить Kimi, что вы на самом деле хотите эту подписку.

Как? Общайтесь с ней, рассказывайте истории, удивляйте. Чем более безумную историю вы расскажете, тем охотнее Kimi будет снижать цену.

Базово, за то, что вы начнёте общаться с Kimi, вы получите подписку за $11.99, а вот получится ли у вас дойти до минимальной цены — $0.99, — уже всецело зависит от вас.

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

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

10/10. Было весело! Акция, кстати, доступна только в мобильном приложении.

Это ваще как?

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

Позавчера вышла Genie 3. И, честно, модельки для генерации музыки/картинок/видео меня обычно не цепляют. Из этой категории за последнее время реально запомнились только Nano Banana Pro и до этого Nano Banana. До них, ощущение, что всё было «ну такое».

При этом Nano Banana тоже скорее игрушка, чем инструмент. Да, иногда можно ваншотом выбить шедевр. Но если тебе нужно сделать серию картинок в одном стиле — удачи.

Почему так? Потому что у этих моделей нет «исходников». Ты можешь нагенерить результат (иногда очень крутой), но, чтобы удержать консистентность, приходится изворачиваться. С кодом проще: модель сразу пишет исходный текст, его можно править, хранить, сравнивать, переиспользовать. А вот когда у нас появится нормальный «язык описания» для изображений/видео/музыки будет совсем другой разговор. С музыкой, кстати, особенно странно: почему мы до сих пор не пришли к чему-то вроде партитуры для нейросетей?

И нет, Genie 3 такую революцию не совершила. Так почему сегодня речь о ней?

Потому что она умеет генерировать целые МИРЫ. Пока по ним в основном можно только ходить, но они выглядят пугающе живо: люди идут, машины едут, что-то происходит, всё шевелится. Если вы помните, на что была способна Genie 2 (она вышла чуть больше года назад), то это прям скачок через пролёт. По ощущениям даже мем «Уилл Смит и спагетти» сделал меньший рывок.

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

И вот когда появится способ вытаскивать сцены наружу, хоть в сыром виде, хоть через промежуточный язык описания, тогда индустрию реально тряхнёт. Разрыв будет не тогда, когда модель научится делать ещё на 3% красивее, а когда разработчикам дадут доступ к внутренностям: геометрии, материалам, объектам, их связям и логике. Тогда начнётся нормальная работа, не с картинкой-результатом, а с тем, из чего эта картинка вообще собрана.

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

И да, рынок уже отреагировал так, будто этот переход случился. После выхода Genie 3 акции некоторых компаний (вроде CD Projekt SA, Take-Two Interactive и Roblox Corp) просели. Это хороший пример того, как люди, которые не понимают, что именно показали, начинают паниковать и нажимать "sell". Потом обычно приходит отрезвление, и резкие движения сейчас скорее симптом того, что всем ясно: что-то назревает.

Главное, что даёт вайб-кодинг, — это не скорость

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

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

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

Вот тут модели и раскрываются. Они существенно сокращают время на реализацию и дают тебе суперсилы там, где у тебя есть только общее понимание того, как система должна работать.

За три часа работы я полностью перелопатил сайт:
• обновил дизайн
• добавил анимации на загрузку, поиск и взаимодействия
• сделал поддержку английского и русского
• добавил светлую и тёмную темы
• сделал сохранение состояния поиска
• реализовал fuzzy search (учёт опечаток)
• добавил фильтры
• добавил звуки при копировании
• сделал клавиатурную навигацию и a11y
• добавил обработку пустых состояний
• адаптировал сайт под все размеры экранов
• по пути починил гору мелких багов и микровзаимодействий

Всё — в одной сессии, без остановок. И пока я занимался им, почерпнул для себя несколько инсайтов о том, как работать с дизайном через модели.

Во-первых, лучшая связка — Opus 4.5 со скиллом /frontend-design. Она позволяет получить дизайн в нужном стиле и избежать стандартного AI-slop вида. Плюс, сам Opus 4.5 из коробки выдаёт приличный UX.

Во-вторых, если вы сами не до конца понимаете, как хотите, чтобы выглядело приложение, сначала нужно выбрать визуальное направление, которое вам реально нравится. Не хватайте первый же вариант, который сгенерирует модель. Попросите её накидать несколько концептов, смело отбрасывайте неудачные. Если в голове уже есть референс, просто опишите его словами. Плюс, полезно «прожаривать» дизайн через /brainstorming из superpowers. Этот шаг также важен, как и первый, так как после него модель зафиксирует дизайн и будет придерживаться его.

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

Дальше подкрутите /frontend-design под себя. Модели обожают вставлять эмодзи в интерфейс; для меня это выглядит как дизайнерская импотенция, поэтому я сразу добавил правило: «никаких эмодзи». Конкретно Opus 4.5 ещё любит вешать анимации и градиенты на неинтерактивные элементы, так что я добавил отдельную инструкцию, чтобы избежать этого. В целом полезно фиксировать, что именно вас раздражает в сгенерированных интерфейсах, и сразу это вырезать. Это и продукт улучшает, и вкус тренирует.

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

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

Очеловечиваем тексты после LLM

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

Это скилл для агентов (при желании можете закинуть в ChatGPT или Gemini — работает не хуже), который превращает статью из Википедии про грехи признаки AI-текста в инструкцию к действию.

Из основного он:
• удаляет эмодзи из текста;
• заменяет длинные тире на запятые и точки, где они уместнее;
• уменьшает использование жирного текста;
• вместо конструкции «Это не просто это, а вот это» доносит мысль прямо;
• убирает артефакты по типу «Отличный вопрос!...» и «Дайте знать, если хотите, чтобы я...».

Другими словами, скилл убирает из текста все конструкции, за которые мы так «любим» тексты, написанные LLM. У него больше инструкций, чем я описал, — все можете прочитать в документации.

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

Ну и если перед вами стоит задача именно перевода интерфейсов, то можете взять за основу мои translation guidelines. Я написал их для перевода интерфейса Blok, и они заточены именно под него, так что, прежде чем использовать их в своём проекте, попросите агента адаптировать гайдлайны под ваш проект.

*При написании поста ни одна LLM не пострадала была использована

Point-and-Copy: упрощаем агентам работу с интерфейсами

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

Лично я испробовал и до сих пор использую следующие подходы:
• Описываю компонент словами и говорю, где примерно он находится («кнопка "выйти" в шапке документации»);
• Описываю компонент по его уникальным идентификаторам из разметки («футер/api-sidebar/etc»);
• Скидываю скриншот и описываю, что с элементом нужно сделать («уменьши отступы в компоненте с изображения»);
• Запускаю браузерный MCP, чтобы тот нашёл нужный элемент и получил больше контекста по нему («перейди на *сайт* и разберись почему кнопка добавления пользователя не нажимается»).

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

И здесь на сцену выходит react-grab — новая утилита от создателя популярных и крутых react-scan и million.js.

Принцип работы у неё до смешного простой: наводишься на элемент, копируешь его данные и вставляешь в контекст агента. Агент сразу понимает, куда смотреть, и не забивает себе контекст ненужными данными. Профит!

Ставится всё буквально одной командой, которую нужно запустить из корневой папки: npx -y grab@latest init.

Удивительно, но об этой штуке не трубит весь интернет, хотя она сейчас полезна как никогда в связи с тем, что прекрасная и копеечная GLM-4.7 не умеет обрабатывать изображения, из-за чего её очень сложно использовать для разработки интерфейсов, так как ты лишаешься 2 из 4 способов показать элемент модели (в связи с тем, что браузерные MCP делают скриншоты, чтобы найти элемент и это ломает модель).

P.S. На скриншоте к посту спойлер к предстоящему анонсу 😍

Настоящие лимиты Claude Code

Девушка провела расследование и разобралась сколько на самом деле лимитов в различных подписках на Claude Code.

Anthropic предлагают три варианта подписки:
• $20 — 1x
• $100 — 5x
• $200 — 20x

Смотря на множители, которые предоставляют подписки невольно хочется сделать вывод, что нужно брать $200 подписку, но не спешите.

По факту 20-и кратный множитель распространяется только на 5-и часовые лимиты, а с недельными лимитами дела обстоят так:
• $20 — 1x или $163
• $100 — 8.33x или $1354
• $200 — 16.67× или $2708

То есть даже на самом дешёвом плане вы получаете 8-и кратную выгоду, а на более дорогих планах 13.5-кратную выгоду, относительно цены тарифа. Да, фактически Anthropic несколько лукавят с 20-и кратным тарифом, зато пользователи 5-и кратного тарифа на самом деле получают 8-и кратную выгоду.

Но самое интересное тут как она это выяснила. Оказалось, что Anthropic на вкладке использования лимитов моделей отдают точное число (double float) для создания прогресс-бара.

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

То есть она просто поймала слишком точные float’ы, восстановила из них исходные дроби и по сути раскрыла внутреннюю систему биллинга Anthropic — случайно утёкшую через фронт.

Как подмечает сама автор, Anthropic точно не ожидали, что их данные утекут через слишком точные float'ы:)

Почему AGI не за углом 2/2

Представляю вам The Next Big Thing в дообучении LLM: сочетание RL и LoRA.

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

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

Что это означает на практике?
1. Стоимость обучения снижается, потому что не нужно трогать гигантскую базовую модель.
2. Скорость обучения увеличивается, потому что LoRA-модули маленькие.
3. Гибкость возрастает: reasoning можно подключать как модуль, а не жёстко вшивать.
4. Интеллект модели растёт за счёт того, что она использует ровно те навыки, которые нужны сейчас, а не полный мешок всех параметров.

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

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

Почему AGI не за углом 1/2

Дисклеймер: аналогии, приведенные в посте, лишь упрощенно описывают, как устроены LLM.

Грустно это осознавать, но в ближайшие годы мы не увидим никакого AGI (Artificial General Intelligence). Вполне вероятно, что мы увидим что-то очень близкое, почти неотличимое от AGI, но не более.

Но почему? Иронично, но причина в том же, почему у нас есть настолько продвинутые модели — RL (Reinforcement Learning).

Вся суть RL сводится к тому, что LLM пробует случайные действия и смотрит, как они влияют на конечный результат. За правильные действия она получает награду, за неправильные — штраф. Таким образом LLM со временем меняет стратегию так, чтобы максимизировать суммарную награду.

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

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

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

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

Но что, если выкинуть из AGI ту часть, где система становится автономной? Тогда мы получим действительно мощную модель, способную выполнять широкий спектр задач по указанию человека. Казалось бы, отличная перспектива! Однако и здесь всё упирается в ограничения RL.

RL лежит в основе финальной доводки модели, но вместе с этим делает модель менее обобщённой. RL постепенно приучает её к безопасным, «правильным» паттернам, которые мы от неё ожидаем. Чем точнее мы задаём рамки поведения, тем точнее модель держится этих рамок. Но есть и оборотная сторона: с каждой новой итерацией корректировки снижается способность к неожиданным выводам. Модель становится аккуратнее, но менее гибкой. Вы можете увидеть это на примере GPT-5: она умнее, но одновременно заметно более «консервативна» в своих ответах. Она реже выходит за пределы ожидаемого, реже предлагает нестандартные ходы и гораздо осторожнее обращается с неопределённостью.

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

MCP вам не бро 2/2

А теперь вернёмся к тому, с чего начали: MCP. Добавляя в своего агента MCP, который занимает 25 000 токенов (то есть примерно 10% от контекста таких моделей, как GPT-5, Opus 4.5, GLM 4.7), вы кардинально снижаете вероятность того, что модель даст правильный ответ. Если вы добавите MCP на 50 000 токенов (~20% контекста), то вы просто задушите модель.

И думаю, что вы уже обратили внимание на картинку. На ней «голый» агент без всяких MCP и других приколов, которые потребляют контекст, только парочка «слушателей» для скиллов, и он УЖЕ занимает 18 000 токенов. Прибавить к этому ещё хотя бы 15 000 токенов в виде MCP — и вот агент уже задыхается в попытках построить логические цепочки между сущностями. у Anthropic даже есть видосик на эту тему.

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

Ну, и что смешно: вся эта история с кривым MCP выглядит как саботаж со стороны Anthropic, так как 24 ноября 2025 года они с гордостью представили решение для проблемы, которую сами же и создали. Они называют это Advanced Tool Use. Я называю это нормальный, работающий MCP. Всё, что они сделали, — добавили поиск по тулам.

Теперь вместо того, чтобы загружать огромный MCP, вы загружаете только инструмент для поиска по тулам, и уже он позволяет подгрузить нужные MCP-тулы в моменте. Но работает эта фича только если вы используете модели от Anthropic. Все остальные провайдеры по-прежнему будут подгружать вам тонну бесполезного контекста. Скорее всего, вся эта история с MCP — просто ряд неправильных решений принятых при создании протокола, но в душе хочется верить, что Anthropic играет в 4D-шахматы и таким образом саботирует весь остальной рынок.

Так что мой совет: посмотрите на MCP, которые подключены у вас в проекте, и задайте себе вопрос: нужны ли они вам на самом деле или можно обойтись без них? Ну, и вообще будьте осторожнее с ними, так как большинство написаны левой пяткой и бесполезны, либо вообще вредны для вашего проекта (да, Serena, я на тебя смотрю).

MCP вам не бро 1/2

В посте про dev-browser я ругался на Model Context Protocol (MCP), но правда ли он такая проблема? Спойлер: да, правда, и, вероятно, бóльшая, чем вы могли себе представить.

Посмотрите на картинку. На ней видно, как GPT-5 справляется с задачами поиска вхождений при разном количестве контекста.

Давайте разберём, что каждая из задач значит.

1. S-NIAH (Single-Needle in a Haystack)

Простыми словами: в этой задаче модели передаётся длинный текст (стог сена),и в нём есть ОДНА нужная фраза (иголка). Нужно просто найти её и повторить.

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

Как вы можете видеть на графике, вне зависимости от количества и типа контекста, GPT-5, как, впрочем, и большинство современных моделей, ответят вам на такой вопрос правильно со 100% вероятностью.

2. OOLONG

Простыми словами: в этой задаче модели нужно собрать статистику по всему тексту.

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

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

Если говорить на языке разработки, то мы даём модели задачу: «Найди все места в коде, где используется тип "any", и выведи их количество».

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

Это прекрасно видно на графике: даже при 8 000 токенов (где-то 20 страниц текста или одна глава книги) модель с 10% вероятностью пропустит хотя бы одно вхождение, а если забить все 262 000 токенов контекстом (примерно одна книга), то вероятность ошибки увеличится до 70%.

3. OOLONG-Pairs

Простыми словами: это усложнённая версия OOLONG, в которой модели важно не просто "прочитать всё", а найти логически связанные пары.

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

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

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

Если мы посмотрим на график, то при 8 000 токенов контекста вероятность ошибки составляет 20%. На 16 000 токенов контекста вероятность ошибки уже 40%, а на 33 000 токенах так и вовсе — 95% 🤯.

Для полноты картины важно понимать, что GPT-5 отлично работает с контекстом, и у других передовых моделей вы увидете похожие результаты.

В Telegram появился функционал для работы с плоскими (одноуровневыми) списками.

У них ушло 12 лет, чтобы реализовать кривую версию.
У меня ушло 12 минут и 1 промпт к Opus 4.5, чтобы реализовать версию для Blok, покрытую E2E-тестами и учитывающую edge-кейсы.

Не знаю как, но чуваки из Telegram умудрились затащить в эти простейшие списки баг: если нажать Shift+Enter на следующей строке после списка, то список создастся снова...

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

Это жутко бесит, потому что я буквально каждый день пользуюсь этим мессенджером, и он с каждым днём становится только хуже. Команда Telegram сфокусировалась на добавлении миллиона бесполезных фичей, вместо того, чтобы исправить баги, которые существуют в мессенджере по несколько лет.

Надеюсь, что поддержку таблиц и списки для телефонов мы всё-таки дождёмся.

Вы не представляете, как у меня горит с Playwright MCP

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

Но на самом деле эта проблема давно уже не проблема, и есть целых три варианта её решения:
1. Сделать скриншоты до и после. Подходит, чтобы показать модели, как должен выглядеть дизайн, какой-то визуальный баг или просто сказать «смотри сюда», чтобы долго и нудно не описывать, что конкретно модель должна увидеть.
2. Написать E2E-тест. Идеальный вариант, если нужно симулировать поведение в браузере, так как убивает двух зайцев одновременно: защищает от регрессии и позволяет автоматизированно, раз за разом проверять ваш сценарий без того, чтобы тратить контекст модели.
3. Дать доступ к браузеру. Это уже подключение тяжёлой артиллерии, и на самом деле зачастую этот подход совмещается с первым и/или вторым, чтобы дать браузеру ещё больше контекста. Также он может быть использован в отрыве от других подходов, чтобы, например, починить сломавшийся тест: гораздо проще дать модели понять, что сломалось самой, вместо того, чтобы объяснять ей что-то на пальцах.

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

У нас есть несколько вариантов, как мы можем научить модель общаться с браузером:
• Playwright MCP;
• MCP Chrome;
• Chrome DevTools MCP;
• Claude in Chrome MCP.

Если вы обратили внимание, то всё это MCP. Изначально сломанный протокол, который даже сами Anthropic (создатели MCP) признали таковым.

У MCP есть две фундаментальные проблемы:
1. Он всегда загружен в контекст, так что даже если вы его не вызываете, он будет занимать место в вашем контексте и ухудшать ответы;
2. Создатели MCP будто не знают о первой проблеме и добавляют десятки тулов в свои MCP, из-за чего многие MCP занимают 10-20% контекста, что безумно много.

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

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

И с другими инструментами из списка та же чехарда: они все работают примерно одинаково.

Меня вся эта ситуация так раздражала, что я уже собирался написать свой инструмент. Благо, я вовремя наткнулся на dev-browser. И, господи, мне даже смешно от того, насколько он просто и элегантно решает ту же самую проблему:
Во-первых, это скилл. А это значит, что в вашем контексте по умолчанию не будет жить слон, и вы сможете его вызывать тогда, когда сами посчитаете нужным;
Во-вторых, вместо того, чтобы на каждый чих иметь отдельный инструмент, dev-browser просто пишет Playwright-скрипты, которые тут же запускает в браузере. Это позволяет симулировать настоящее поведение пользователя, с чем Playwright MCP тоже очень сильно страдает, так как просто не успевает нажимать на всякие временные всплывающие окна или делать действия быстро, ведь он целую вечность раздумывает между действиями.

Так что, если вы используте Claude Code, Codex или Amp, рекомендую переехать на dev-browser — это топ!

The State of Agentic IDEs 5/5

Claude Code + GLM 4.7
Помните, в конце прошлого года я писал, что в 2026 году AI-гонка перевернётся с ног на голову? Большой пост об этом ещё пишется, а пока вы сами можете почувствовать эффект этого переворота на себе.

GLM 4.7 работает на уровне, близком к Opus 4.5, и в максимальном тире за $60 (первый месяц отдают за $30) предоставляет в три раза больше лимитов, чем Claude Code в $200-тире. То есть вы получаете в три раза большие лимиты, в три раза дешевле. И если $200-тир в Claude Code почти безлимитный, то $60-тир в GLM 4.7 —буквально безлимитный. И самое кайфовое, что GLM 4.7 можно использовать в Claude Code, и для этого даже не придётся танцевать с бубном. Ну, кайф же!

Да, GLM 4.7 несколько хуже, чем Opus 4.5:
• Она работает медленнее (по ощущениям, где-то в 1.5 раза);
• У неё меньше контекстное окно (256k vs 200k токенов), и GLM 4.7 в целом генерирует больше токенов, чем Opus 4.5, так что контекстное окно улетает заметно быстрее;
• При этом у GLM 4.7 хорошее следование, благодаря чему даже при большом количестве контекста (на котором она зачастую и оперирует, в связи прошлым пунктом) модель продолжает генерировать осмысленный код;
• Но я заметил, что при большом количестве контекста начинает страдать тул-кол, в связи с чем модель может просто упасть или уйти в бесконечный цикл (особенно если вы запустили много (10+) subagents), так что имейте это в виду;
• Также Opus 4.5 способен делать более зрелые архитектурные решения, но это уже чисто по ощущениям.

Пользуясь GLM 4.7, я вспоминаю, на что был готов идти, чтобы пользоваться поломанной Gemini 3 Pro из-за её (на тот момент) прорывного интеллекта. Так что описанные выше недостатки GLM 4.7 даже не выглядят проблемами модели, они скорее говорят о том, насколько Opus 4.5 прорывная.

Выйди GLM 4.7 на пару недель раньше Opus 4.5, а не на пару недель позже последнего, первая получила бы гораздо больше признания, которое она заслуживает, ведь GLM 4.7 буквально обгоняет все GPT-5.x и Gemini 3 Pro в агентском кодинге, уступая только Opus 4.5.

По итогу мой совет такой:
• Если вы умеете готовить код с LLM и у вас есть возможность потратить $200 на максимальный тир в Claude Code — дерзайте! Это кратно повысит вашу производительность и наслаждение от разработки.
• Если вы считаете, что $200 — это слишком дофига за подписку, но у вас есть возможность её оплатить, то советую начать со $100 тира Claude Code, а потом, при желании и необходимости, апгрейднуть подписку.
• Если вы хотите пользоваться крутой моделью внутри Claude Code, но у вас нет возможности оплатить подписку на Claude Code, то советую попробовать GLM 4.7. Самый дешёвый тир стоит всего $3 и, по заявлениям с официального сайта, лимиты в нём в три раза выше, чем в подписке на Claude Code за $20. Затем, при необходимости, вы всегда можете обновиться на более дорогие тарифы, не потеряв то, что уже заплатили. Если воспользуетесь моей реферальной ссылкой, то получите ещё 10% скидку сверху:)

The State of Agentic IDEs 4/5

Продолжаем с категорией «🔥 Вы хотите это использовать»

OpenCode
В нём есть буквально всё, что вы хотите от современного агента: плагины, SDK, скиллы, команды, subagents. А также OpenCode, в отличие от OpenAI, оправдывает своё название: проект реально open-source. Кайф.

Но даже это не главное. Самое крутое в OpenCode — то, что можно использовать ваши подписки на Codex, Claude Code и Gemini. Это как если бы у вас был Codex, но со всеми фичами современных агентов.

Впрочем, Anthropic уже увидели в OpenCode реального конкурента и обрезали им (да и всем остальным) доступ к использованию подписки на Claude Code. С этим была связана недавняя драма, но вместо того, чтобы сделать OpenCode менее популярным, это вызвало эффект Стрейзанд: количество звёзд в репозитории проекта за пару дней удвоилось.

Причём сам интерфейс OpenCode сильно уступает Claude Code: он не особо красивый и удобный. Ну, а также у OpenCode нет того уровня поддержки со стороны сообщества (в плане плагинов, скиллов и остального), которое есть у Claude Code, хотя и тут Anthropic подложили себе свинью, потому что многие репозитории добавили поддержку OpenCode после последних событий.

🙏 GODLIKE

Как в первой, так и в последней категории у нас всего один инструмент. И разрыв между первым и последним местами астрономических масштабов. По факту, разрыв настолько велик, что, попробовав Windsurf, вы можете не захотеть прикасаться к AI-разработке снова, а используя Claude Code, станете ярыми фанатами такого вида разработки.

Claude Code
А теперь предлагаю вспомнить всё то, чем хорош OpenCode, и вообразить, что у него хороший, удобный, красивый интерфейс — это и есть Claude Code. Причём удобен он как в CLI-версии, так и в качестве плагинов для VS Code (я именно так его и использую) и JetBrains IDEs. Последний вообще создали сами ребята из JetBrains в сотрудничестве с Anthropic.

Но этого было бы мало, чтобы выводить Claude Code в отдельную категорию.
Поэтому Claude Code, помимо всего прочего, это:
• Бесконечные плагины, туториалы и хаки от сообщества. Многие полезные плагины существуют исключительно для Claude Code;
• Маркетплейс, на котором можно найти LSP, MCP, плагины и скиллы, разработанные сообществом;
• Хуки, которые позволяют встраиваться в жизненный цикл запроса и выполнять скрипты, логировать данные, запускать тесты или проверки типов (в OpenCode есть схожая реализация, но она уступает той, что в Claude Code);
• Agents SDK, который позволяет создавать своих агентов.

Claude Code — лучший агент не просто так, и лучше всего он раскрывает себя в связке с Opus 4.5... И вот здесь кроется единственная проблема этого подхода — он слишком дорогой. За подписку с Opus 4.5 придётся заплатить либо $100 (5x), либо $200 (20x).

И я прекрасно понимаю, что это много, и тех, кто готов платить такую сумму за агента каждый месяц, немного. Но оно того стоит. Тариф за $200 даёт вам, по сути, безлимитный доступ к Opus 4.5, который в умелых руках многократно окупится.

Но для тех, кто всё-таки не готов так раскошеливаться ради агента, есть альтернативный вариант с идеальным балансом качества и цены!