Forwarded from Раньше всех. Ну почти.
⚡️Путин подписал закон об административных штрафах до 700 тыс. рублей для владельцев российских сайтов за авторизацию с помощью зарубежных сервисов, в том числе иностранной электронной почты
😁3
Я тут почитал-поразбирался про новые штрафы за авторизацию через иностранные сервисы.
В целом логично: это не новый запрет с нуля, а штрафы к уже существующей норме, которую с 2023 года так никто и не уточнил «что есть что».
Речь про 149-ФЗ «Об информации, информационных технологиях и о защите информации».
В статье 8, части 10 написано, как владелец российского сайта может проводить авторизацию пользователей из РФ.
И вот там есть волшебный пункт 4. Прекрасная мутная формулировка, из которой обычному владельцу сайта нихрена непонятно 🙂
С моей точки зрения, получается - так:
Если на сайте стоит кнопка «Войти через Google» / «Войти через Gmail» — это, скорее всего, нарушение. Потому что в этом случае используется внешняя система авторизации, владелец которой не в РФ.
А если пользователь просто вводит
Потому что во втором случае Gmail не авторизует пользователя.
Авторизует его мой сайт, моя база, моя система логин-пароль.
А email используется просто как логин, то есть как информационная часть профиля пользователя.
Но если прилетит проверка или штраф, то, скорее всего, придётся бодаться и доказывать разницу между:
1. «авторизацией через иностранную систему»;
2. «собственной авторизацией, где email просто логин».
А разницу эту, боюсь, судья в 99% случаев с первого раза не поймёт 🙁
Вот в этом и главная проблема.
Все как всегда: закон написан юридическим языком, сайты работают технической логикой, а владельцу сайта между этим всем выкручиваться.
Если подробнее копать, мне вот это объяснение понравилось:
https://habr.com/ru/articles/1046183/comments/#comment_30098662
В целом логично: это не новый запрет с нуля, а штрафы к уже существующей норме, которую с 2023 года так никто и не уточнил «что есть что».
Речь про 149-ФЗ «Об информации, информационных технологиях и о защите информации».
В статье 8, части 10 написано, как владелец российского сайта может проводить авторизацию пользователей из РФ.
И вот там есть волшебный пункт 4. Прекрасная мутная формулировка, из которой обычному владельцу сайта нихрена непонятно 🙂
С моей точки зрения, получается - так:
Если на сайте стоит кнопка «Войти через Google» / «Войти через Gmail» — это, скорее всего, нарушение. Потому что в этом случае используется внешняя система авторизации, владелец которой не в РФ.
А если пользователь просто вводит
account@gmail.com как логин и пароль от аккаунта на моём сайте - это другая история.Потому что во втором случае Gmail не авторизует пользователя.
Авторизует его мой сайт, моя база, моя система логин-пароль.
А email используется просто как логин, то есть как информационная часть профиля пользователя.
Но если прилетит проверка или штраф, то, скорее всего, придётся бодаться и доказывать разницу между:
1. «авторизацией через иностранную систему»;
2. «собственной авторизацией, где email просто логин».
А разницу эту, боюсь, судья в 99% случаев с первого раза не поймёт 🙁
Вот в этом и главная проблема.
Все как всегда: закон написан юридическим языком, сайты работают технической логикой, а владельцу сайта между этим всем выкручиваться.
Если подробнее копать, мне вот это объяснение понравилось:
https://habr.com/ru/articles/1046183/comments/#comment_30098662
Хабр
👍6
Forwarded from Раньше всех. Ну почти.
❗️Владельцы российских сайтов обязаны прекратить использование иностранных систем авторизации для входа пользователей на сайты и в приложения, иначе им грозят штрафы до 700 тыс. рублей. Соответствующий закон вступил в силу 7 июля.
Мера распространится исключительно на владельцев сайтов, будь то юридические или физические лица, а не на самих пользователей.
Мера распространится исключительно на владельцев сайтов, будь то юридические или физические лица, а не на самих пользователей.
😐3
Тут коллеги из Селектела запустили бесплатный курс по внедрению ИИ в бизнесе. Вдруг кому интересно будет. Понятно что это обычное промо для приучения клиентов к своей инфраструктре. Но все-таки по описанию мне курс видится полезным, тк там именно про практики внедрения.
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