Тут коллеги из Селектела запустили бесплатный курс по внедрению ИИ в бизнесе. Вдруг кому интересно будет. Понятно что это обычное промо для приучения клиентов к своей инфраструктре. Но все-таки по описанию мне курс видится полезным, тк там именно про практики внедрения.
https://study.selectel.ru/mlbusiness_course
https://study.selectel.ru/mlbusiness_course
study.selectel.ru
ИИ для бизнеса
👍5🔥3
В разработку тащат русский вайб.
На GitHub появился POHUY - режим идиоматического русского мата для AI-агентов.
Вместо:
> The deployment failed because the DATABASE_URL environment variable is empty…
Агент сразу объясняет по-человечески:
> Деплой наебнулся:
Одним словом можно обозначить критичность проблемы, характер поломки, степень раздражения и готовность немедленно всё исправить. Попробуйте так же ёмко перевести «наебнулось» на английский - получите абзац корпоративного текста.
Предусмотрены три калибра:
Установка для Claude Code, Cursor, Codex и Windsurf
Наконец-то в AI-разработку тащат не только англоязычные best practices.
Гитхаб: https://github.com/smixs/pohuy
На GitHub появился POHUY - режим идиоматического русского мата для AI-агентов.
Вместо:
> The deployment failed because the DATABASE_URL environment variable is empty…
Агент сразу объясняет по-человечески:
> Деплой наебнулся:
DATABASE_URL пустой. Хуйня вопрос, чиню.Одним словом можно обозначить критичность проблемы, характер поломки, степень раздражения и готовность немедленно всё исправить. Попробуйте так же ёмко перевести «наебнулось» на английский - получите абзац корпоративного текста.
Предусмотрены три калибра:
lite, full и ultra. При этом код, документация и коммиты остаются чистыми, мат направлен исключительно на баги, а не на пользователя.Установка для Claude Code, Cursor, Codex и Windsurf
Наконец-то в AI-разработку тащат не только англоязычные best practices.
Гитхаб: https://github.com/smixs/pohuy
GitHub
GitHub - smixs/pohuy: Режим идиоматического русского мата для AI-агентов. Короче, душевнее, эффективнее. 18+
Режим идиоматического русского мата для AI-агентов. Короче, душевнее, эффективнее. 18+ - smixs/pohuy
🔥3❤1😁1
Напоминалка - Fable скоро отключат…
"Note: We've extended this promotion through July 19, 2026 at 11:59:59 PM PT."
По московскому времени это 20 июля 2026 года, 09:59:59 МСК. В июле действует PDT (UTC−7), разница с Москвой — +10 часов.
(с) Перевод - GPT 🙂
"Note: We've extended this promotion through July 19, 2026 at 11:59:59 PM PT."
По московскому времени это 20 июля 2026 года, 09:59:59 МСК. В июле действует PDT (UTC−7), разница с Москвой — +10 часов.
(с) Перевод - GPT 🙂
Те же антропики тут же:
«Начиная с 20 июля Claude Fable 5 будет включён во все тарифы Max и Team Premium с лимитами в размере 50% от стандартных.
Пользователи тарифов Pro и Team Standard по-прежнему смогут пользоваться Fable за счёт кредитов на использование. Кроме того, им будет предоставлен единовременный кредит в размере 100 долларов.
Спрос на Fable оказалось сложно прогнозировать. Именно поэтому мы добавляли его в подписочные тарифы поэтапно и несколько раз продлевали доступ по мере того, как нам удавалось увеличивать доступные вычислительные мощности.»
Ну, годно. Но у меня его не будет в подписке. И фигсним 🙂
«Начиная с 20 июля Claude Fable 5 будет включён во все тарифы Max и Team Premium с лимитами в размере 50% от стандартных.
Пользователи тарифов Pro и Team Standard по-прежнему смогут пользоваться Fable за счёт кредитов на использование. Кроме того, им будет предоставлен единовременный кредит в размере 100 долларов.
Спрос на Fable оказалось сложно прогнозировать. Именно поэтому мы добавляли его в подписочные тарифы поэтапно и несколько раз продлевали доступ по мере того, как нам удавалось увеличивать доступные вычислительные мощности.»
Ну, годно. Но у меня его не будет в подписке. И фигсним 🙂
🎼 Оркестраторы для AI-агентов: чем заменить десяток терминалов
В чатике посоветовали cmux - терминал, специально сделанный для параллельной работы с Claude Code, Codex и другими coding-агентами.
https://cmux.com/ru
Выглядит о удобно: отдельные рабочие пространства, статусы агентов, уведомления, git-ветки и быстрые переключения. Но есть существенный недостаток: cmux работает только на macOS.
Оказалось, что альтернатив уже довольно много.
### Herdr
https://herdr.dev/
Терминальный мультиплексор для coding-агентов. Позволяет одновременно запускать Claude Code, Codex, Copilot CLI, Cursor Agent, OpenCode, Kimi и другие CLI-инструменты.
По сути, это специализированный аналог tmux: сессии продолжают работать в фоне, восстанавливаются после перезапуска, а управлять ими можно локально или удалённо.
Подходит для Linux, macOS и серверов.
### Orca
https://github.com/stablyai/orca
Полноценная среда для управления целым «флотом» агентов. Есть версии для Windows, Linux и macOS.
Каждому агенту можно выделить отдельный git worktree, ветку, терминал и задачу. Поддерживается огромное количество агентов: Claude Code, Codex, Gemini CLI, OpenCode, Cursor, Cline, Goose, Kimi, Qwen Code и другие.
Это уже ближе не к терминалу, а к IDE для параллельной агентной разработки.
### Warp
https://www.warp.dev/agents
Современный терминал со своей агентной платформой. Позволяет одновременно запускать Warp Agent, Claude Code, Codex и Gemini CLI, видеть их состояние, получать уведомления и проверять изменения в коде.
Работает на macOS, Linux и Windows.
Но Warp - это коммерческий облачный продукт, поэтому не совсем прямой аналог локального open-source-инструмента.
### Mux
https://mux.coder.com/
https://github.com/coder/mux
Десктопное и браузерное приложение для параллельной работы агентов в изолированных рабочих пространствах.
Можно запускать несколько задач на локальном компьютере или удалённом сервере. Для каждой задачи создаётся отдельное окружение, поэтому агенты не мешают друг другу изменениями в коде.
### Claude Squad
https://github.com/smtg-ai/claude-squad
Один из самых простых вариантов для терминала.
Запускает несколько Claude Code, Codex, Gemini CLI, Aider и других агентов в отдельных git worktree. Интерфейс текстовый, зависимостей немного, работает поверх tmux.
Подойдёт тем, кому не нужна отдельная красивая IDE.
### dmux
https://dmux.ai/
Ещё один лёгкий вариант на базе tmux + git worktrees.
Создаёт отдельные рабочие области для агентов и позволяет параллельно поручить одному написание кода, второму - тестирование, третьему - ревью.
### CLI Agent Orchestrator от AWS
https://github.com/awslabs/cli-agent-orchestrator
Это уже не просто оболочка для нескольких терминалов, а настоящий оркестратор.
Один управляющий агент может раздавать задания Claude Code, Codex, Gemini CLI, OpenCode, Copilot CLI, Amazon Q и другим исполнителям. Агенты работают в отдельных tmux-сессиях и взаимодействуют через MCP.
Поддерживаются последовательное выполнение, параллельная работа и swarm-режим.
### Agent Orchestrator
https://github.com/AgentWrapper/agent-orchestrator
Оркестратор более высокого уровня: получает задачи, создаёт отдельные worktree и ветки, запускает агентов, следит за CI, исправляет конфликты и готовит pull request.
Можно подключать разные агенты, среды выполнения и системы постановки задач — например GitHub или Linear.
---------------
Получается примерно такая шкала:
Нужно просто держать несколько агентов под контролем:
Herdr → Claude Squad → dmux → cmux → Warp
Нужны отдельные рабочие пространства и IDE:
Mux → Orca
Нужно, чтобы агенты сами распределяли работу между собой:
AWS CLI Agent Orchestrator → Agent Orchestrator
Похоже, мы постепенно переходим от модели:
> «Открыл Claude Code и дал ему задачу»
к модели:
> «Поставил задачу тимлиду, а он уже раздал её пяти агентам, запустил тесты, организовал ревью и подготовил PR».
В чатике посоветовали cmux - терминал, специально сделанный для параллельной работы с Claude Code, Codex и другими coding-агентами.
https://cmux.com/ru
Выглядит о удобно: отдельные рабочие пространства, статусы агентов, уведомления, git-ветки и быстрые переключения. Но есть существенный недостаток: cmux работает только на macOS.
Оказалось, что альтернатив уже довольно много.
### Herdr
https://herdr.dev/
Терминальный мультиплексор для coding-агентов. Позволяет одновременно запускать Claude Code, Codex, Copilot CLI, Cursor Agent, OpenCode, Kimi и другие CLI-инструменты.
По сути, это специализированный аналог tmux: сессии продолжают работать в фоне, восстанавливаются после перезапуска, а управлять ими можно локально или удалённо.
Подходит для Linux, macOS и серверов.
### Orca
https://github.com/stablyai/orca
Полноценная среда для управления целым «флотом» агентов. Есть версии для Windows, Linux и macOS.
Каждому агенту можно выделить отдельный git worktree, ветку, терминал и задачу. Поддерживается огромное количество агентов: Claude Code, Codex, Gemini CLI, OpenCode, Cursor, Cline, Goose, Kimi, Qwen Code и другие.
Это уже ближе не к терминалу, а к IDE для параллельной агентной разработки.
### Warp
https://www.warp.dev/agents
Современный терминал со своей агентной платформой. Позволяет одновременно запускать Warp Agent, Claude Code, Codex и Gemini CLI, видеть их состояние, получать уведомления и проверять изменения в коде.
Работает на macOS, Linux и Windows.
Но Warp - это коммерческий облачный продукт, поэтому не совсем прямой аналог локального open-source-инструмента.
### Mux
https://mux.coder.com/
https://github.com/coder/mux
Десктопное и браузерное приложение для параллельной работы агентов в изолированных рабочих пространствах.
Можно запускать несколько задач на локальном компьютере или удалённом сервере. Для каждой задачи создаётся отдельное окружение, поэтому агенты не мешают друг другу изменениями в коде.
### Claude Squad
https://github.com/smtg-ai/claude-squad
Один из самых простых вариантов для терминала.
Запускает несколько Claude Code, Codex, Gemini CLI, Aider и других агентов в отдельных git worktree. Интерфейс текстовый, зависимостей немного, работает поверх tmux.
Подойдёт тем, кому не нужна отдельная красивая IDE.
### dmux
https://dmux.ai/
Ещё один лёгкий вариант на базе tmux + git worktrees.
Создаёт отдельные рабочие области для агентов и позволяет параллельно поручить одному написание кода, второму - тестирование, третьему - ревью.
### CLI Agent Orchestrator от AWS
https://github.com/awslabs/cli-agent-orchestrator
Это уже не просто оболочка для нескольких терминалов, а настоящий оркестратор.
Один управляющий агент может раздавать задания Claude Code, Codex, Gemini CLI, OpenCode, Copilot CLI, Amazon Q и другим исполнителям. Агенты работают в отдельных tmux-сессиях и взаимодействуют через MCP.
Поддерживаются последовательное выполнение, параллельная работа и swarm-режим.
### Agent Orchestrator
https://github.com/AgentWrapper/agent-orchestrator
Оркестратор более высокого уровня: получает задачи, создаёт отдельные worktree и ветки, запускает агентов, следит за CI, исправляет конфликты и готовит pull request.
Можно подключать разные агенты, среды выполнения и системы постановки задач — например GitHub или Linear.
---------------
Получается примерно такая шкала:
Нужно просто держать несколько агентов под контролем:
Herdr → Claude Squad → dmux → cmux → Warp
Нужны отдельные рабочие пространства и IDE:
Mux → Orca
Нужно, чтобы агенты сами распределяли работу между собой:
AWS CLI Agent Orchestrator → Agent Orchestrator
Похоже, мы постепенно переходим от модели:
> «Открыл Claude Code и дал ему задачу»
к модели:
> «Поставил задачу тимлиду, а он уже раздал её пяти агентам, запустил тесты, организовал ревью и подготовил PR».
cmux
cmux — Терминал для многозадачности
cmux — AI-кодинг на macOS. Создано для AI-агентов программирования на macOS: вертикальные вкладки, уведомления, разделённые панели и автоматизация браузера.
🔥5❤1
Правда, вместе с производительностью примерно так же хорошо масштабируются расход токенов, конфликты между агентами и количество кода, который потом придётся проверять человеку. 🙂
cmux
cmux — Терминал для многозадачности
cmux — AI-кодинг на macOS. Создано для AI-агентов программирования на macOS: вертикальные вкладки, уведомления, разделённые панели и автоматизация браузера.
❤2
Вы не поверте, но таки да… Даже у меня может быть про санкции. Прямо про свеженький 21 пакет с пакетами. 🙂
«Кроме того, под новые европейские ограничения подпал петербургский хостинг-провайдер Beget.»
Однако, здравствуйте. Чем именно так БЕГЕТ-то выделился - есть идеи?
«Кроме того, под новые европейские ограничения подпал петербургский хостинг-провайдер Beget.»
Однако, здравствуйте. Чем именно так БЕГЕТ-то выделился - есть идеи?
Современный ИИ: от управления людьми к управлению агентами
Чем дальше я внедряю ИИ в разработку, тем сильнее ощущение: почти всё, что раньше применялось к коллективам программистов, теперь на 100% применимо к агентам.
Когда программистов становится 20+, CTO физически не может смотреть весь код. Если он продолжает лично проверять каждую строчку, то сам превращается в узкое горлышко, а система перестаёт масштабироваться.
Поэтому и появляются:
* тимлиды и иерархия управления;
* код-ревью;
* проверки pull request по диагонали;
* автоматические тесты;
* тестирование релиза перед продом;
* правила постановки и приёмки задач.
Ты не пытаешься контролировать каждое действие каждого программиста. Ты строишь систему, которая позволяет коллективу стабильно выдавать результат.
С ИИ-агентами происходит ровно то же самое. Просто теперь мы автоматизировали ещё и самих программистов.
Если агент сделал задачу "не так", первая реакция часто эмоциональная: агент тупой, сломался, опять полез не туда.
Но с сотрудниками ведь действует другое правило. Если человек сделал задачу неправильно, значит:
* ему были непонятны цели и вводные;
* критерии результата не были зафиксированы;
* не были обозначены ограничения;
* либо он выбрал решение, которое кажется неоптимальным именно тебе.
В любом из этих случаев это прежде всего проблема управления. Нужно не пинать исполнителя, а менять систему постановки, контроля и разбора задач.
Почему с агентами должно быть иначе?
У меня, например, прямо в
> Если решить проблему за три попытки не получилось - прекратить повторять тот же подход, пересмотреть исходные предположения и спроектировать решение заново.
Агенту не просто разрешено менять подход - ему это прямо предписано.
С программистами было так же: если задача рассчитана на три дня, но уже в первый день непонятно, как её решать, не нужно ещё два дня долбиться в стену. Нужно остановиться и подумать над другими способами.
Вообще, переход от людей к агентам - это не столько революция в программировании, сколько очередной этап развития управления разработкой.
Раньше мы строили процессы, которые позволяли масштабировать работу людей. Теперь строим процессы, которые позволяют масштабировать работу агентов:
* распределяем роли;
* отделяем планирование от исполнения;
* задаём правила эскалации;
* вводим контрольные точки;
* автоматизируем ревью и тестирование;
* фиксируем знания и инструкции;
* ограничиваем бесконечные попытки решить задачу одним способом.
Получилось ли ускориться в сотни раз? У меня пока нет. Возможно, такая цифра получится, если считать исключительно время написания чистого кода.
Но продуктовые задачи, которые раньше решались за спринт - то есть примерно за две недели, - сейчас нередко закрываются за пару рабочих дней.
Это уже не проценты ускорения. Это порядок величины.
Поэтому вопрос "внедрять ИИ или нет" фактически закрыт. Даже вопрос "в каком объёме внедрять" постепенно теряет смысл.
Проблема теперь в другом.
Есть компании и команды, которые уже встроили агентов в процессы и ускорили разработку в десятки раз. А значит, в десятки раз быстрее у них начинают проверяться продуктовые гипотезы, исправляться ошибки, запускаться новые функции и накапливаться опыт.
Они не просто работают быстрее. Они быстрее учатся.
И поэтому начинают убегать от тех, кто "пока присматривается", с постоянно растущей скоростью.
Сложно соревноваться с теми, кто уже вышел на старт на технологическом допинге.
Чем дальше я внедряю ИИ в разработку, тем сильнее ощущение: почти всё, что раньше применялось к коллективам программистов, теперь на 100% применимо к агентам.
Когда программистов становится 20+, CTO физически не может смотреть весь код. Если он продолжает лично проверять каждую строчку, то сам превращается в узкое горлышко, а система перестаёт масштабироваться.
Поэтому и появляются:
* тимлиды и иерархия управления;
* код-ревью;
* проверки pull request по диагонали;
* автоматические тесты;
* тестирование релиза перед продом;
* правила постановки и приёмки задач.
Ты не пытаешься контролировать каждое действие каждого программиста. Ты строишь систему, которая позволяет коллективу стабильно выдавать результат.
С ИИ-агентами происходит ровно то же самое. Просто теперь мы автоматизировали ещё и самих программистов.
Если агент сделал задачу "не так", первая реакция часто эмоциональная: агент тупой, сломался, опять полез не туда.
Но с сотрудниками ведь действует другое правило. Если человек сделал задачу неправильно, значит:
* ему были непонятны цели и вводные;
* критерии результата не были зафиксированы;
* не были обозначены ограничения;
* либо он выбрал решение, которое кажется неоптимальным именно тебе.
В любом из этих случаев это прежде всего проблема управления. Нужно не пинать исполнителя, а менять систему постановки, контроля и разбора задач.
Почему с агентами должно быть иначе?
У меня, например, прямо в
AGENTS.md записано примерно следующее:> Если решить проблему за три попытки не получилось - прекратить повторять тот же подход, пересмотреть исходные предположения и спроектировать решение заново.
Агенту не просто разрешено менять подход - ему это прямо предписано.
С программистами было так же: если задача рассчитана на три дня, но уже в первый день непонятно, как её решать, не нужно ещё два дня долбиться в стену. Нужно остановиться и подумать над другими способами.
Вообще, переход от людей к агентам - это не столько революция в программировании, сколько очередной этап развития управления разработкой.
Раньше мы строили процессы, которые позволяли масштабировать работу людей. Теперь строим процессы, которые позволяют масштабировать работу агентов:
* распределяем роли;
* отделяем планирование от исполнения;
* задаём правила эскалации;
* вводим контрольные точки;
* автоматизируем ревью и тестирование;
* фиксируем знания и инструкции;
* ограничиваем бесконечные попытки решить задачу одним способом.
Получилось ли ускориться в сотни раз? У меня пока нет. Возможно, такая цифра получится, если считать исключительно время написания чистого кода.
Но продуктовые задачи, которые раньше решались за спринт - то есть примерно за две недели, - сейчас нередко закрываются за пару рабочих дней.
Это уже не проценты ускорения. Это порядок величины.
Поэтому вопрос "внедрять ИИ или нет" фактически закрыт. Даже вопрос "в каком объёме внедрять" постепенно теряет смысл.
Проблема теперь в другом.
Есть компании и команды, которые уже встроили агентов в процессы и ускорили разработку в десятки раз. А значит, в десятки раз быстрее у них начинают проверяться продуктовые гипотезы, исправляться ошибки, запускаться новые функции и накапливаться опыт.
Они не просто работают быстрее. Они быстрее учатся.
И поэтому начинают убегать от тех, кто "пока присматривается", с постоянно растущей скоростью.
Сложно соревноваться с теми, кто уже вышел на старт на технологическом допинге.
❤6
Кусочек из анонса:
Работа с Claude Opus 5
Claude Opus 5 гораздо лучше умеет проверять свою работу и тщательно дорабатывать её до достижения успеха. В ходе оценок и тестирования на этапе раннего доступа мы вместе с пользователями обнаружили немало примеров целеустремлённости и основательности Opus 5:
* В одной из задач Frontier-Bench модели Opus 5 дали чертёж детали механизма и попросили написать код для воссоздания её в виде 3D-модели в FreeCAD. При этом в рамках задачи модель намеренно была лишена возможности напрямую просматривать изображение чертежа. Opus 5 в ответ на это самостоятельно написал собственный конвейер компьютерного зрения, чтобы извлечь геометрию из исходных пикселей, а затем воссоздал деталь целиком. Модели удавалось успешно справляться с этой задачей раз за разом; ни одна конкурирующая модель в тех же условиях не смогла решить её даже за пять попыток.
* Получив реальную ошибку в популярном пакетном менеджере с открытым исходным кодом, Opus 5 нашёл первопричину и исправил крайний случай, который патч сообщества упустил. Конкурирующая модель устранила лишь внешний симптом (а не основную причину), после чего заявила, что ошибка устранена.
* Инженер торговой компании с помощью Opus 5 создал канал рыночных данных для новой биржи за одну сессию. Предыдущие модели были не способны выполнить эту задачу вовсе, даже имея подробные планы от инженера. Не найдя живого потока данных для проверки, Opus 5 самостоятельно построил собственный тестовый стенд, чтобы убедиться, что его код корректно разбирает данные биржи.
Полный текст анонса:
https://www.anthropic.com/news/claude-opus-5
Работа с Claude Opus 5
Claude Opus 5 гораздо лучше умеет проверять свою работу и тщательно дорабатывать её до достижения успеха. В ходе оценок и тестирования на этапе раннего доступа мы вместе с пользователями обнаружили немало примеров целеустремлённости и основательности Opus 5:
* В одной из задач Frontier-Bench модели Opus 5 дали чертёж детали механизма и попросили написать код для воссоздания её в виде 3D-модели в FreeCAD. При этом в рамках задачи модель намеренно была лишена возможности напрямую просматривать изображение чертежа. Opus 5 в ответ на это самостоятельно написал собственный конвейер компьютерного зрения, чтобы извлечь геометрию из исходных пикселей, а затем воссоздал деталь целиком. Модели удавалось успешно справляться с этой задачей раз за разом; ни одна конкурирующая модель в тех же условиях не смогла решить её даже за пять попыток.
* Получив реальную ошибку в популярном пакетном менеджере с открытым исходным кодом, Opus 5 нашёл первопричину и исправил крайний случай, который патч сообщества упустил. Конкурирующая модель устранила лишь внешний симптом (а не основную причину), после чего заявила, что ошибка устранена.
* Инженер торговой компании с помощью Opus 5 создал канал рыночных данных для новой биржи за одну сессию. Предыдущие модели были не способны выполнить эту задачу вовсе, даже имея подробные планы от инженера. Не найдя живого потока данных для проверки, Opus 5 самостоятельно построил собственный тестовый стенд, чтобы убедиться, что его код корректно разбирает данные биржи.
Полный текст анонса:
https://www.anthropic.com/news/claude-opus-5
Anthropic
Introducing Claude Opus 5
Opus 5 is a step change improvement for the Opus tier powering long-running agents while delivering improvements in coding and professional work.
👍5
Вышла Claude Opus 5. А мне от этого что?
Я немного подустал от бесконечных новостей про очередную «самую умную модель» и решил сделать собственный бенчмарк. Не на той фантастике, на которой модели тестируют их создатели, а на моих реальных задачах.
У меня уже накопилось 37 репозиториев с кодом.
Из их истории можно собрать тесты разных типов:
* найти и исправить реальный баг
* дописать функцию по требованиям
* провести рефакторинг
* написать тесты
* разобраться в старом или чужом коде
* изменить несколько связанных файлов и ничего не сломать
* разобраться в проекте по неполной или устаревшей документации
Первая версия будет небольшой - пять калибровочных задач на основе реальных исторических изменений. Стенд будет локальным и воспроизводимым. Каждую задачу агент проходит один раз и полностью без моего участия. Для запуска создаётся отдельный снимок репозитория, поэтому оригинальный проект агент испортить не сможет.
Сравнивать планирую не модели, а связки:
Codex CLI + модель
Claude Code + модель
По каждой задаче буду смотреть:
* решила ли модель задачу вообще
* прошли ли тесты
* соблюдены ли требования и ограничения
* сколько потребовалось времени
* сколько было циклов работы
* сколько потрачено токенов
* сколько стоил запуск
Оценка будет складываться из автоматических проверок и заранее заданных критериев с весами. Эталонные патчи и скрытые проверки агент видеть не будет. Все запуски будут сохраняться вместе с версиями CLI, моделью и настройками. На выходе - сравнительная таблица и HTML-отчёт.
Потом можно будет расширить набор до 20, 50 или 80 задач, добавить многократные прогоны и посмотреть не только на средний результат, но и на стабильность моделей.
Потому что вот вышла Claude Opus 5. Наверняка прекрасная.
Но мне гораздо интереснее другое: есть ли от неё профит именно на конкретно моих задачах? Или я просто буду быстрее сжигать лимиты там, где предыдущая модель и так прекрасно справляется?
Нейронка уже шуршит по проектам и создаёт тесты 🙂
Я немного подустал от бесконечных новостей про очередную «самую умную модель» и решил сделать собственный бенчмарк. Не на той фантастике, на которой модели тестируют их создатели, а на моих реальных задачах.
У меня уже накопилось 37 репозиториев с кодом.
Из их истории можно собрать тесты разных типов:
* найти и исправить реальный баг
* дописать функцию по требованиям
* провести рефакторинг
* написать тесты
* разобраться в старом или чужом коде
* изменить несколько связанных файлов и ничего не сломать
* разобраться в проекте по неполной или устаревшей документации
Первая версия будет небольшой - пять калибровочных задач на основе реальных исторических изменений. Стенд будет локальным и воспроизводимым. Каждую задачу агент проходит один раз и полностью без моего участия. Для запуска создаётся отдельный снимок репозитория, поэтому оригинальный проект агент испортить не сможет.
Сравнивать планирую не модели, а связки:
Codex CLI + модель
Claude Code + модель
По каждой задаче буду смотреть:
* решила ли модель задачу вообще
* прошли ли тесты
* соблюдены ли требования и ограничения
* сколько потребовалось времени
* сколько было циклов работы
* сколько потрачено токенов
* сколько стоил запуск
Оценка будет складываться из автоматических проверок и заранее заданных критериев с весами. Эталонные патчи и скрытые проверки агент видеть не будет. Все запуски будут сохраняться вместе с версиями CLI, моделью и настройками. На выходе - сравнительная таблица и HTML-отчёт.
Потом можно будет расширить набор до 20, 50 или 80 задач, добавить многократные прогоны и посмотреть не только на средний результат, но и на стабильность моделей.
Потому что вот вышла Claude Opus 5. Наверняка прекрасная.
Но мне гораздо интереснее другое: есть ли от неё профит именно на конкретно моих задачах? Или я просто буду быстрее сжигать лимиты там, где предыдущая модель и так прекрасно справляется?
Нейронка уже шуршит по проектам и создаёт тесты 🙂
👍10
Ну что, готов первый проход тестов.
Я расширил количество тестов до 10 (больше не получается, тк один круг одной модели в Клое начинает вылезать за 5-часовой лимит)
Соответственно пока только 1 прогон - сбросятся лимиты, прогоню еще Опус 5 и добавлю к табличке.
10 тестовых задач из реальных проектов:
1. Свежесть напоминаний, Python/WordPress: пропускать свежие, учесть GMT.
2. Путь к кешу, PHP/Yii/W3TC: разбор URL, защита.
3. Даты комментариев, WordPress/PHP: ближайшее будущее, local time и GMT.
4. Очистка бэкапов, Bash: удалять дампы нужного проекта.
5. Onboarding-чеклист, vanilla JS: закрываемый блок в дашборде, стили, тесты.
6. Аномальный объём IMOEX, Python: многоминутная волна, cooldown, состояние.
7. MCP и Zod 4, JavaScript: свободные object-схемы в параметрах и request body.
8. Runtime-пути, Python/Docker: миграции, контракты, окружение, healthcheck.
9. Backup/restore, Bash/Docker: Compose-проект с overlays, пустые дампы.
10. VPN-маршрут, macOS/Bash: host route, fallback, идемпотентность.
Я расширил количество тестов до 10 (больше не получается, тк один круг одной модели в Клое начинает вылезать за 5-часовой лимит)
Соответственно пока только 1 прогон - сбросятся лимиты, прогоню еще Опус 5 и добавлю к табличке.
10 тестовых задач из реальных проектов:
1. Свежесть напоминаний, Python/WordPress: пропускать свежие, учесть GMT.
2. Путь к кешу, PHP/Yii/W3TC: разбор URL, защита.
3. Даты комментариев, WordPress/PHP: ближайшее будущее, local time и GMT.
4. Очистка бэкапов, Bash: удалять дампы нужного проекта.
5. Onboarding-чеклист, vanilla JS: закрываемый блок в дашборде, стили, тесты.
6. Аномальный объём IMOEX, Python: многоминутная волна, cooldown, состояние.
7. MCP и Zod 4, JavaScript: свободные object-схемы в параметрах и request body.
8. Runtime-пути, Python/Docker: миграции, контракты, окружение, healthcheck.
9. Backup/restore, Bash/Docker: Compose-проект с overlays, пустые дампы.
10. VPN-маршрут, macOS/Bash: host route, fallback, идемпотентность.
🔥5
Сбросились лимиты. Запустил тест на Opus 5 и добавил его в общую табличку.
На данный момент проверены два агента: Codex и Claude Code с 4 моделями (каждый со своими двумя).
В общем-то на цифрах получилось то, что и было по ощущениям.
Opus 4.8 лучше всех справляется с моими задачами (на которых и были построены тесты)
И при этом расходует меньше всего токенов.
Для задач «попроще» мне вполне подойдет gpt-5.6-sol.
Как более экономный вариант.
На данный момент проверены два агента: Codex и Claude Code с 4 моделями (каждый со своими двумя).
В общем-то на цифрах получилось то, что и было по ощущениям.
Opus 4.8 лучше всех справляется с моими задачами (на которых и были построены тесты)
И при этом расходует меньше всего токенов.
Для задач «попроще» мне вполне подойдет gpt-5.6-sol.
Как более экономный вариант.
🔥11👎2
Я вообще перестал читать код, который пишут мои ИИ-агенты.
Совсем.
Читать весь сгенерированный код - означает добровольно отказаться от главного преимущества агентов. Скорости.
Если после каждого вызова агента перепроверять код, то это не автоматизация. Тогда это просто очень быстрый джуниор, за которым нужен постоянный надзор.
Поэтому я контролирую не код. Я контролирую систему, внутри которой этот код создаётся.
Агент для написания кода получает жёсткие архитектурные ограничения, точное техническое задание, критерии приёмки, тесты, статический анализ, линтеры, проверки безопасности, граничные сценарии и запрет самовольно расширять задачу.
Он может написать что угодно. Но в прод попадёт только то, что прошло всю цепочку производства и проверок.
Мне не нужно верить агенту.
Мне не нужно доверять его рассуждениям.
Мне не нужно восхищаться качеством его кода.
Мне нужна система, в которой плохой код не выживает.
Главная ошибка сегодня - пытаться управлять агентами как людьми: объяснять им задачу обычными словами, давать свободу, а потом внимательно читать результат.
Агенты требуют не доверия. Они требуют жёстких рамок. Как и те же джуниоры. Им надо понимать куда ходить можно, а куда - нельзя.
И чем они становятся умнее и производительнее, тем меньше смысла читать каждую написанную ими строку - и тем важнее качество ограничений, тестов и процедур контроля. Но. Ограничивать и описывать важно только то, где они не справляются или косячат. Многие вещи они уже самостоятельно делают достаточно хорошо.
Я перестал читать код, потому что перестал полагаться чисто на доверие агенту. Я полагаюсь на свою цепочку производства.
Совсем.
Читать весь сгенерированный код - означает добровольно отказаться от главного преимущества агентов. Скорости.
Если после каждого вызова агента перепроверять код, то это не автоматизация. Тогда это просто очень быстрый джуниор, за которым нужен постоянный надзор.
Поэтому я контролирую не код. Я контролирую систему, внутри которой этот код создаётся.
Агент для написания кода получает жёсткие архитектурные ограничения, точное техническое задание, критерии приёмки, тесты, статический анализ, линтеры, проверки безопасности, граничные сценарии и запрет самовольно расширять задачу.
Он может написать что угодно. Но в прод попадёт только то, что прошло всю цепочку производства и проверок.
Мне не нужно верить агенту.
Мне не нужно доверять его рассуждениям.
Мне не нужно восхищаться качеством его кода.
Мне нужна система, в которой плохой код не выживает.
Главная ошибка сегодня - пытаться управлять агентами как людьми: объяснять им задачу обычными словами, давать свободу, а потом внимательно читать результат.
Агенты требуют не доверия. Они требуют жёстких рамок. Как и те же джуниоры. Им надо понимать куда ходить можно, а куда - нельзя.
И чем они становятся умнее и производительнее, тем меньше смысла читать каждую написанную ими строку - и тем важнее качество ограничений, тестов и процедур контроля. Но. Ограничивать и описывать важно только то, где они не справляются или косячат. Многие вещи они уже самостоятельно делают достаточно хорошо.
Я перестал читать код, потому что перестал полагаться чисто на доверие агенту. Я полагаюсь на свою цепочку производства.
🔥8❤4💯1
Ну что, текущий чарт на картинке. Никаких дополнений у меня нет.
Для 90% моих задач оптимальным является использование Opus 4.8 с efforrt=medium.
Совершенно однозначно. :-)
Я так-то его и использовал в основном. Но с выходом 5-ки было ощущение что я что-от упускаю. Не, все норм.
Теперь можно все новые модели заряжать на тест после выхода и смотреть как оно справляется с моим бенчмарком.
Есть у меня правда пара идей как можно подтянуть Опус 5 выше, чем он сейчас. Поэксперементирую в следующие выходные…
Другие модели пока использовать не хочу. Не вижу смысла.
Но GPT 5.5 я точно меняю на 5.6 SOL для более простых задач с которыми они тоже хорошо справляются.
Типа доработок мелких проектов/скриптов и админства серверов и тп.
Для 90% моих задач оптимальным является использование Opus 4.8 с efforrt=medium.
Совершенно однозначно. :-)
Я так-то его и использовал в основном. Но с выходом 5-ки было ощущение что я что-от упускаю. Не, все норм.
Теперь можно все новые модели заряжать на тест после выхода и смотреть как оно справляется с моим бенчмарком.
Есть у меня правда пара идей как можно подтянуть Опус 5 выше, чем он сейчас. Поэксперементирую в следующие выходные…
Другие модели пока использовать не хочу. Не вижу смысла.
Но GPT 5.5 я точно меняю на 5.6 SOL для более простых задач с которыми они тоже хорошо справляются.
Типа доработок мелких проектов/скриптов и админства серверов и тп.
🔥5