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

За последний месяц отдельные разработчики Anthropic с помощью Claude Fable 5, Claude Opus 4.8 и dynamic workflows перенесли десять проектов объемом от десятков до сотен тысяч строк кода. В этой статье мы разберем два примера и лучшие практики, сформировавшиеся в ходе этих проектов.

Джарред Самнер, сооснователь Bun и технический специалист Anthropic, использовал Claude Code, чтобы перенести Bun с Zig на Rust. Менее чем за две недели было создано миллион строк кода. До слияния ветки 100% существующих тестов Bun проходили в CI. После слияния обнаружилось 19 регрессий, все они уже исправлены. В июне версия на Rust вошла в состав Claude Code.

Майк Кригер, один из руководителей Anthropic Labs, за выходные перенес кодовую базу на Python в 165 000 строк TypeScript. В процессе работали сотни агентов, использовались восемь контрольных этапов, три раунда состязательного ревью и финальная проверка, которая сравнивала вывод каждой команды с результатом оригинальной версии на Python.

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

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

Но когда вы отправляете Claude сообщение, сам промпт составляет лишь небольшую часть получаемого моделью контекста. Значительная его часть собирается из системного промпта, навыков, файлов CLAUDE.md, памяти и других источников. Мы называем это контекстной инженерией. От нее во многом зависит результат работы с Claude Code и собственными агентами.

В отличие от промпта, контекст используется сразу во множестве запросов, поэтому он не может быть настолько же конкретным. Как создавать общие инструкции и рекомендации для Claude, особенно если заранее неизвестно, с каким запросом придет пользователь?

По мере развития возможностей Claude эта задача неожиданно усложняется. Недавно мы заметили серьезные изменения в том, как следует составлять инструкции для нового поколения моделей. Мы удалили более 80% системного промпта Claude Code для Claude Opus 5 и Claude Fable 5, при этом наши тесты по программированию не показали измеримого ухудшения результатов.

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

Claude Code даёт две настройки, которые обе как бы «улучшают ответ»: модель и уровень усилий (effort). Но что они на самом деле делают с результатом? И как понять, когда нужно менять модель, а когда — просто уровень усилий?

Легко предположить, что модель побольше, например Fable, даёт умнее результат, чем Sonnet, а более высокий уровень усилий значит просто «Claude думает дольше перед ответом».

Первое предположение верно. Наши крупнейшие модели действительно более способны — по отраслевым бенчмаркам.

А вот усилия значат больше, чем «время на размышление». Effort определяет, сколько работы Claude выполняет над вашим запросом в целом. Сюда входит и то, сколько он думает, но также:
– сколько файлов он читает;
– сколько он всё проверяет;
– как далеко он продвигается в многошаговой задаче, прежде чем вернуться к вам за уточнением.

При высоком уровне усилий Claude совершает больше таких действий (читает файлы, гоняет тесты, перепроверяет), прежде чем вернуться с ответом. При низком уровне он скорее спросит у вас больше контекста, чем будет сам разбираться, потратив на это токены.

Работа с Claude Fable 5 раз за разом напоминает мне старую истину: карта — не территория.

Карта — это представление предстоящей работы: мои промпты, скиллы и контекст, всё, что я передаю Claude. Территория — это то, где работа реально происходит: кодовая база, реальный мир, его настоящие ограничения.

Разницу между картой и территорией я называю неизвестными. Когда Claude наталкивается на неизвестное, ему приходится принимать решение на основе наилучшей догадки о том, чего я хочу. Чем больше объём работы, тем больше неизвестных может встретиться Claude по пути.

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

Два года работа c AI-агентами для написания кода выглядели одинаково: написать промпт, передать контекст, прочитать дифф, написать следующий промпт. Агент был инструментом, человек держал его за руку от начала до конца. Эта схема устаревает.

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

Материал собран из инженерной документации Anthropic, эссе Эдди Османи (Addy Osmani) о loop engineering и недавних замеров продуктивности.

Boeing ведёт статистику авиационных происшествий с 1950-х. Одна цифра там не меняется уже несколько десятилетий: около 80% катастроф связаны исключительно с человеческим фактором. При этом сами самолёты за это время стали в разы надёжнее, а автопилоты в разы умнее. Парадокс в том, что эти два факта связаны между собой.

Модели класса Mythos (такие как Claude Fable 5) изменили рабочий процесс многих из нас в Anthropic. Хочу поделиться двумя советами, как работать с этим классом моделей эффективнее.

У меня был ранний доступ к первой публично доступной модели класса Mythos — Claude 5 Fable. Большинство обсуждений вокруг Mythos сосредоточено на кибербезопасности, но я тестировал модель на всём остальном (ограничения Fable фактически блокируют её использование в этой области).

Мой вывод: это реальный скачок относительно всех моделей, с которыми я работал раньше. И, что важнее, он говорит о фундаментальных изменениях в том, как мы взаимодействуем с AI.

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

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

Опираясь на публичные бенчмарки и ранее не публиковавшиеся внутренние данные Anthropic, The Anthropic Institute показывает: ИИ уже ускоряет разработку ИИ-систем. Один из примеров: сегодня инженеры Anthropic в среднем коммитят в 8 раз больше кода в квартал, чем в 2021–2025 годах.

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

На прошлой неделе мы выпустили динамические воркфлоу в Claude Code. Теперь Claude может на лету писать собственную обвязку (harness) под конкретную задачу.

Стандартная обвязка Claude Code создавалась для кода — но она также полезна для многих других типов задач, поскольку, как выясняется, многие задачи напоминают задачи по написанию кода. Тем не менее есть определённые классы задач, под которые нам приходилось строить кастомные обвязки поверх Claude Code для достижения максимальной производительности: исследования, анализ безопасности, командные агенты или ревью кода.

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

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

Каждая AI‑лаборатория прямо сейчас работает себе в убыток, обслуживая вашу компанию. Они это знают. И делают это намеренно.

OpenAI, Anthropic, Google и остальные реализуют отраслевую программу субсидирования в масштабах, не имеющих прецедента. Они продают предприятиям вычислительные мощности по ценам ниже себестоимости, называя это бизнес‑моделью. Разрыв между тем, что ваша компания платит за AI‑подписки, и тем, во что реально обходится их обслуживание, — это не погрешность округления, а пропасть. И любая организация, выстроившая рабочие процессы, продукты или целые бизнес‑подразделения на основе субсидированных цен, стоит прямо на её краю.

Это должно быть в приоритете для каждого CTO, CFO и операционного директора. Когда цены скорректируются — а они скорректируются — компании, воспринимавшие AI как вечно дешёвую коммунальную услугу, получат счета, перед которыми их текущие расходы на SaaS покажутся мелочью.

Markdown стал стандартным форматом для общения агентов с разработчиком. Простой, портативный, поддерживает базовое форматирование, легко редактируется. Claude даже научился делать ASCII-диаграммы внутри markdown-файлов.

Но по мере того, как агенты становятся мощнее, markdown начинает ощущаться тесным. Файл длиннее ста строк уже трудно читать. Хочется нормальных визуализаций, цвета, диаграмм — и возможности легко поделиться результатом.

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

Я перешёл на HTML как основной выходной формат. Вот почему.

(примеры можно посмотреть здесь: https://thariqs.github.io/html-effectiveness — возвращайтесь читать дальше)

Две недели назад мы объявили, что с помощью Claude Mythos Preview и других AI-моделей нашли и исправили рекордное количество скрытых уязвимостей в Firefox. В этой статье подробности о подходе, результатах и советы для других проектов, которые хотят применять эти техники.

6 мая 2026 года в Сан-Франциско прошла вторая конференция Anthropic для разработчиков — Code with Claude. Площадку для мероприятия в этот раз расширили: в этот раз взяли бывший автосалон SVN West, так как спрос оказался выше.

Следующие 2 конференции пройдут в Лондоне и Токио (19 мая и 10 июня), а записи всех докладов должны опубликовать в ближайшее время на YouTube канале Claude Code.

Для тех, кто хочет посмотреть все доклады уже сейчас, опубликовал полную запись в ТГК (5+ часов видео).

Ниже пройдемся по всем докладам и отметим самое важное.

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

Я веду список советов по агентному кодингу: правила и ориентиры для тех, кто только начинает работать с Codex, Claude Code, Pi или любым другим агентом. Каждый пункт — обобщённая рекомендация, применимая к агентному программированию в целом. Хочется, чтобы уроки оставались актуальными по мере того, как улучшаются модели и инструменты.

Ниже — текущий список: 10 уроков агентного кодинга. Десять — красивое круглое число, хороший повод опубликовать.

На прошлой неделе мы писали о том, как скармливали терабайты CI-логов LLM. Большинство вопросов на Hacker News касались не самих логов — спрашивали про агента: какие модели, как они взаимодействуют и во сколько всё это обходится.

Сейчас мы работаем на Opus 4.6 и платим меньше, чем когда всё крутилось на Sonnet 4.0.

Причина в основном в том, чего Opus не делает: 80% сбоев до него не доходят, а когда доходят — он не читает ни одной строки лога.

Архитектура выглядит так...

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

Меня зовут Джер Крейн, я основатель PocketOS. Мы делаем ПО для прокатного бизнеса — в первую очередь для аренды автомобилей: бронирования, платежи, управление клиентами, отслеживание транспортных средств. Некоторые наши клиенты с нами уже больше 5 лет и они буквально не могут работать без нас.

Вчера днём ИИ‑агент на базе Cursor с Claude Opus 4.6 от Anthropic удалил нашу продакшн‑базу данных и все резервные копии на уровне тома одним API‑вызовом к Railway, нашему инфраструктурному провайдеру.

На это ушло 9 секунд.

Затем агент, когда его попросили объяснить произошедшее, написал признание — с перечнем конкретных правил безопасности, которые он нарушил.

DeepSeek V4 Pro — это 1,6 триллиона параметров, mixture of experts (MoE), 49 млрд активных параметров и контекст в 1 миллион токенов. V4 Flash — рабочая лошадка: 284 млрд параметров суммарно, 13 млрд активных. Обе модели обучены примерно на 33 трлн токенов. На агентских бенчмарках кода, MMLU Pro, GPQA Diamond, SWE-bench Verified — V4 рядом с Opus 4.7 и GPT-5.5. Немного отстаёт, но совсем немного.

Вот в чём дело.

Большинству задач не нужен абсолютный frontier. Компании не решают сложнейшие научные задачи — они ведут бизнес. Представьте: вы CEO, смотрите на GPT-5.5 по $30 за миллион выходных токенов, на Opus 4.7 по похожей цене — и тут DeepSeek в разы дешевле, open source, его можно дообучать, хостить где угодно, контролировать точечно. Математика очевидна.

Здесь и начинается проблема.

В гайде по миграции для Claude Opus 4.7 написано: новый токенайзер использует «примерно в 1.0–1.35 раза больше токенов», чем 4.6. Я замерил и получил 1.47x на технической документации, и 1.45x на реальном CLAUDE.md-файле.

Цены те же. Квоты те же. Токенов в промпте больше. Max-план сгорает быстрее. Кешированный префикс стоит дороже за каждую итерацию. Рейтлимит наступает раньше.

Значит, Anthropic что-то получили в обмен. Что именно — и стоит ли оно того?

Я провёл два эксперимента: первый измерил стоимость, второй проверил заявленные преимущества. Вот что получилось.

В последних разговорах с пользователями Claude Code постоянно всплывает одна тема: контекстное окно в 1М токенов — палка о двух концах.

С одной стороны, Claude Code дольше работает автономно и надёжнее справляется со сложными задачами. С другой — если не следить за сессиями, контекст быстро засоряется.

Управление сессиями сейчас важнее, чем когда-либо, и вопросов вокруг него много. Держать одну или две долгосрочные сессии в терминале? Начинать новую с каждым промптом? Когда использовать compact, rewind или subagents? Что приводит к плохой компактизации или плохой сессии?

Всё это неожиданно сильно влияет на опыт работы с Claude Code, и почти всё сводится к управлению контекстным окном.