Вайбкодинг и качество Ещё в прошлом году вайбкодинг мне казался лишь игрушкой. Круто, конечно, что можно что-то там сказать компьютеру, и он сделает. Но результат будет держаться на соплях и сойдёт разве что как прототип. Чтобы сделать качественную, надёжную вещь, нужно держать весь код под контролем. Можно писать его с нейросетями, но нужно понимать, из каких абстракций он состоит, как они связаны, какие события как обрабатываются, что где хранится и так далее. Но сейчас я разрабатываю одну программу под Мак — посложнее, чем Колокол Тарта — и прихожу уже к противоположному выводу. Разрабатывать я её взялся потому, что все существующие, написанные настоящими программистами аналоги, меня не устраивают из-за низкого качества. И даже то, что мне написал Кодекс за первый день (после недели ленивых диалогов для написания первичной спецификации), уже работает быстрее и чётче, чем все аналоги. При этом я вижу много направлений для улучшения: https://ilyabirman.ru/meanwhile/all/tart-bell-mac/ Я вижу, что требуемый мне уровень качества просто недостижим в классическом программировании. Если бы я сам умел такое программировать, у меня бы просто не хватило терпения всё вылизывать. Если бы рядом со мной был опытный программист, у него бы тем более не хватило терпения слушать мои придирки к неидеальности того, что видно только при покадровом просмотре скринкаста. По моим наблюдениям, большинство программистов просто не замечают многие нюансы или не считают их значимыми. Но даже если представить, что мне бы попался один из тех, кто замечает и считает, я бы сам постеснялся просить его попробовать переписать вообще всё по-другому только чтобы проверить, не станет ли чуточку приятнее — это же живой человек, всё-таки! А те редкие программисты, у которых такой же высокий собственный уровень требований к качеству, вряд ли сидят и ждут, что я буду ими командовать — у них своих задумок полно. Короче, теперь мне уже кажется, что высокое качество достижимо только при вайб-кодинге.

MCP → CLI Я только собирался написать, почему CLI сосут, и на что их заменять, как понял, что у меня даже нет поста, почему сосут MCP (от которых мы и ушли к CLI). Исправляю! Сначала напомню в двух словах зачем эти ребята нам вообще нужны:

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

Нужно его к ним как-то коннектить. И на заре агентных систем ребята придумали подсовывать ему новые инструменты как tools (то, что агент может вызывать в цикле перед тем как дать итоговый ответ). Назвали это MCP (model-context-protocol) У стандарта MCP было много исторических болячек: невнятная аутентификация, загромождение контекста всеми методами всех mcp'шек, , отсутствие строгого следования схеме, stateful логика 🥴 Сейчас они по большей части вылечены. Но есть одна главная проблема – это все еще лишний слой абстракции поверх обычного API. И он требует модель возвращать вызов инструмента в перегруженном JSON формате. То есть, вместо вместо того, чтобы сразу дернуть API нашего условного гитхаба, обвязка нашего агента (она выполняет роль MCP клиента) отправляет это в какой-то MCP сервер (в случае с гитхаб он удаленный, но может быть и локальным), а он уже отправляет это в API Любой агент, у которого есть вызов терминала может либо написать скрипт, который будет обращаться к API напрямую, либо просто вызвать уже сто лет существующую команду gh с нужными параметрами. Всё! И вот какие у этого плюсы: 1. Жрет меньше токенов (потому что не verbose json) 2. Можно стакать вызовы команд в любой последовательности 3. Не обязательно засирать контекст модели всем выводом. Перенаправляем и фильтруем вывод терминальной команды как душе угодно 4. Обычно сильно больше комбинаций параметров 5. Если какой-то функции или параметра нет, агент все так же может написать кастомный скрипт, который сходит в API и сделает то, что нужно Но надо признать, кое-где MCP все-таки нужны – когда у вас есть эфимерная сессия + нужна авторизация. Короче, во всех облачных чатах и коворках. CLI там не подходит по одной причине – авторизация происходит внутри сэндбокса и на каждый новый чат придется делать ее заново Пример: gh отлично работает у вас на ноуте, но в ChatGPT Work вы задолбаетесь каждый раз проходить авторизацию, а вот GitHub MCP подключите один раз и он будет работать всегда В разговорах слышал еще такие аргументы за MCP (но мне они не нравятся): 1. Проще раскатывать на команду и обновлять (хз, автообновление cli делается тривиально) 2. MCP сразу поддерживает инструкции, а про CLI тул агент еще должен как-то узнать (скиллы наш бро) 3. В MCP есть функции, которых нет в API (это вообще извращение, не делайте так. но если пользуетесь чужим сервисом таким, то да, тут придется страдать) А у вас в команде используют MCP? Почему? (напоминаю, что скоро будет пост о том, почему CLI тоже не самый лучший выбор) @ai_grably

Вот пример - пришла отбивка, что модуль готов, можно идти заниматься своими делами

🚀 Lock-Screen Preparation Complete

✅ Новый скилл: /founder-lock-screen (поддерживает профили default-evolution и mvp) создан.

✅ Blueprint: Подробный архитектурный план implementation_plan_mvp_lockscreen.md сохранен. Он описывает как будут развернуты Cloudflare Workers, Zaraz, и D1 без затрагивания GKE монолита.

✅ OSINT Research: Фоновый сбор best-practices 2026 года для Cloudflare Workers и Zaraz запущен через Model Council.

Уводите компьютер в Lock-Screen режим! Я начну выполнять шаги из Blueprint'а и раз в 5 минут буду слать heartbeat обновления.

Зачем компаниям строить собственный AI и как это делать? Ответу на этот вопрос Sequoia Capital посвятила отдельное видео для фаундеров и AI-команд. Речь в нем о sovereign AI - подходе, при котором компания сама развивает AI под свой продукт, а не подключает его к внешним моделям (GPT/Claude). Как пример: берет открытую базовую модель и адаптирует ее под свои данные, задачи и контекст. Sequoia по шагам разбирает, кому и зачем нужен собственный AI, что стоит оставить внешним провайдерам, а что развивать внутри и как к этому подойти технически и организационно. Короткое, но очень полезное видео, если вы, вдруг, еще об этом не задумались! Перевели с командой все основные шаги и собрали в пошаговую инструкцию. Надеюсь вам будет полезно 🙂

Про современные облачные сервисы. Шуршит у меня парсер вакансий в PersMarket, и вот он нарыл интересный вариант. Вакансия нового поколения в сервисе нового поколения, можно сказать. Сам сервис, SaaS, занимается привлечением клиентов. Но делают это по-новому, ИИ-агентами. Пишут, что

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

В команде 7 человек, но код пишут весь через ИИ. На семерых у них 60 подписок Claude Max.

разработка в 70–90 параллельных тредах прямо в Slack: 200+ PR в неделю, 15–20 релизов в день

Также агенты закупают рекламу, назначают и разбирают юзер-интервью, формируют беклог, дизайн, A/B-тесты, саппорт и найм. Ну и собственно, кого ищут - AI-native Developer с продуктовым мышлением. Нужно уметь работать с агентами, строить свой харнесс, при этом понимать продуктовые метрики и закрывать зоны ответственности end-to-end. То есть простые программисты уже не нужны, нужен универсал, человек-швейцарский нож, усиленный ИИ. Ну и денег обещают за это $10–12k в месяц за фуллтайм на удаленке. #ai

comfyui-mcp MCP-сервер для комфи от подписчика @Aleks_101 Подключает любого ИИ-агента к локальному ComfyUI. Не только через API, а напрямую к рабочему процессу, открытому во вкладке браузера. Официальный mcp от ComfyUI только облачный, аналоги завязаны на ключи и Copilot - тут всё своё, локально. • 45 инструментов для LLM: статус, воркфлоу, логи, канвас, запуск, скачивание моделей • Чтение и правка живого графа - виджеты, связи, лейблы, layout, undo • Запуск воркфлоу с прогрессом и отдачей результата • Скачивание моделей в нужные директории без ручной загрузки • Диагностика по логам ComfyUI и консоли браузера • Сборка воркфлоу с нуля или починка нерабочего графа • Перевод подписей графа на другой язык одним вызовом • Конфиги готовы под Claude Code, Cursor, Kilo Code, OpenCode, LM Studio, Cherry Studio, MiMo Code, OpenClaw, Hermes, Codex, llama.cpp • Белый список хостов для загрузки моделей #comfyui #mcp

У разработки есть свой налог на масштаб Платите вы его процессами, зависимостями и количеством людей, которых надо позвать на созвон 😉 DX выкатили свежие Core 4 бенчмарки по 500+ компаниям. Там есть интересный срез: как отличаются метрики у инженерных организаций разного размера. Не динамика во времени, а сравнение групп: — <100 инженеров — 100–500 — 500–2500 — 2500+ Иииии вот что видно. 1. Change Fail Rate растет с масштабом У tech-компаний: <100 инженеров - 4,0% 2500+ - 4,8% У non-tech: 3,95% → 5,26% То есть большие организации чаще выпускают некачественные решения. 2. Developer Experience начинает проседать Медианный DXI у tech-компаний: — <100: 66 — 100–500: 66 — 500–2500: 67 — 2500+: 64 До нескольких тысяч инженеров все примерно стабильно. А потом сложность начинает догонять. 3. PR на инженера тоже становится меньше — <100: 3,8 PR/неделю — 2500+: 3,35 Примерно минус 12%. PR, конечно, не productivity, но сигнал вполне понятный. И вот тут мне нравится термин: Налог на масштаб разработки Чем больше организация, тем больше ресурсов съедают: — зависимости; — согласования; — коммуникации; — legacy; — инфраструктурная сложность; — процессы управления процессами. Код мы научились производить быстрее, тут спасибище AI. А вот организация вокруг его производства быстрее пока не стала: все те же процессы, все те же команды, все те же люди. Поэтому одна из ключевых задач Developer Platform / DevEx - не просто ускорять написание кода, а снижать налог на масштаб. Иначе дадим каждому инженеру AI-агента… …а потом они оба будут три дня ждать ревью 😁

Задумался, какой самый полезный AI юзкейс у нас появился за последнее время. И ответ неожиданный - Claude Tag, интеграция Claude в Slack. Штука простая: подключаешь тулы которые есть в организации, у Claude своя память для каждого канала, и опционально можно задать кастомный промпт. Например, у нас есть канал куда падают алерты, когда что-то ломается. Часть из них - false alarms: трафик дернулся, провайдер прилег. Раньше кто-то из команды шел разбираться руками. Сейчас Claude сам проверяет статус-страницы, смотрит последние коммиты и за секунды говорит - реальная проблема или флейк. Но самое крутое оказалось с фидбеком. У нас есть канал куда из саппорта прилетают жалобы пользователей. Раньше большинство таких тикетов разбирали только когда их накапливалось много. Сейчас Claude берет user_id, идет проверяет логи, смотрит сессии на телефоне во время тьюторинга и сразу определяет - это наш баг или у чувака например были проблемы с интернетом. И если наш баг - сразу драфтит PR и дает разработчику на ревью. За месяц мы так уменьшили количество жалоб в два раза 😮 Я давно хотел такое запилить сам, еще когда настраивал нашу систему саппорта, но все руки не доходили. А тут Anthropic выпустили Claude Tag и оно сразу залетело! Поделитесь, где у вас ИИ-шка давала пользу за последнее время?

Запись второй части нашего стрима про сбегающих AI-агентов. Посмотреть на YouTube можно здесь. Таймкоды: 0:00:00 — Приветствие и обсуждение планов на стрим 0:02:13 — Архитектура проекта SECS и схема пайплайна 0:06:42 — Интеграция навыков для кодовых AI-агентов 0:10:00 — Локальный запуск модели Qwen и vLLM 0:18:05 — Ускорение инференса через спекулятивное декодирование 0:28:20 — Воспоминания о культовых играх и компьютерах 0:33:45 — Настройка контекстного окна и параметров модели 0:44:00 — Сравнение видеокарт для инференса нейросетей 0:50:40 — Обсуждение генерации музыки в нейросетях 1:08:05 — Тестирование AI-агента на тестовой виртуальной машине 1:23:45 — Автоматизированный анализ и поиск путей эскалации 1:54:30 — Подведение итогов стрима и завершение трансляции Каналы участников стрима, чтобы подписаться: Павел Рыков Константин Доронин