Доставка со скоростью инференса

Это перевод статьи Питера Штайнбергера (@steipete), того самого автора OpenClaw, которого недавно купили в OpenAI – “Shipping at Inference-Speed”. Этот пост, как мне кажется, спустя полгода после публикации читать только интереснее – потому что то, что он описывает как первые впечатления и вау-эффект от работы с агентами для производства кода, а так же методы для работы с ними – сейчас уже в мейнстриме. Если вы активно пользуетесь агенсткими системами в разработке, то многое из описанного для вас стало привычно; этот пост помогает освежить воспоминания о том, как все было в мае прошлого года – и как сильно все изменилось к декабрю.

Peter Steinberger · 28 декабря 2025

Почему я перестал читать код и стал наблюдать, как он стримится.

Что изменилось с мая

Просто невероятно, как далеко “вайбкодинг” ушел за этот год. Если еще мае меня удивляло, что иногда промпт заставляет модель выдавать код, который работает с первого раза, то сейчас это для меня базовое ожидание. Я выкатываю код со скоростью, которая еще недавно казалась нереальной. С мая я сжег овердофига токенов. Пора обновить информацию.

Забавно, как работают эти агенты. Пару недель назад был спор о том, что код надо писать руками, чтобы чувствовать плохую архитектуру, а использование агентов якобы создает разрыв – с этим я категорически не согласен. Когда проводишь с агентами достаточно времени, то точно знаешь, сколько что должно занимать, и когда Codex возвращается к тебе, так и не решив задачу с одного захода, я начинаю подозрительно прищуриваться.

Объем софта, который я могу создать, сейчас ограничен в основном временем инференса и временем на раздумья. И давайте по честному – над большей частью софта особенно думать не нужно. Большинство приложений перекладывают данные из одной формы в другую, может, где-то их хранят и потом как-то показывают пользователю. Самая простая форма – текст, поэтому по умолчанию все, что я хочу построить, начинается как CLI. Агенты могут вызывать его напрямую и проверять вывод – замыкая, таким образом, цикл.

Сдвиг моделей

Настоящим прорывом в фабричному производтству кода стало появление GPT-5. Несколько недель после релиза понадобилось мне, чтобы осознать это – Codex’у нужно было догнать Claude Code по фичам, а мне надо было разобраться в различиях между ними. Со временем я стал доверять модели все больше и больше. Сейчас я почти не читаю код. Смотрю на стрим, иногда заглядываю в ключевые места, но если честно – большую часть кода я не читаю. Я знаю, где какие компоненты лежат, как все структурировано и как спроектирована система в целом – обычно этого достаточно.

Важные решения сейчас – это язык/экосистема и зависимости. Мои дефолтные языки: TypeScript для веба, Go для CLI, Swift если надо лезть в macOS или нужен UI. Еще несколько месяцев назад я бы не подумал про Go ни на секунду, но в какой-то момент попробовал и обнаружил, что агенты прекрасно на нем пишут, а простая система типов делает линтинг быстрым.

Кто пигет под Mac или iOS: Xcode почти не нужен. Я даже xcodeproj не использую. Билд-инфраструктура Swift сейчас достаточно хороша для большинства задач. А Codex умеет запускать iOS-приложения и работать с симулятором. Никаких особых танцев или MCP-серверов не нужно.

Codex vs Opus

Пока я пишу этот пост, Codex прогрызается через гигантский многочасовой рефакторинг и расхлебывает старые преступления Opus 4.0. В Твиттере у меня часто спрашивают: в чем разница между Opus и Codex и почему она вообще важна, если бенчмарки почти одинаковые. ИМХО бенчмаркам все сложнее верить – сейчас нужно пробовать все, чтобы реально понять разницу. Что бы OpenAI ни сделали в пост-тренинге, codex научили читать ОЧЕНЬ много кода перед тем, как дать ему возможность его писать.

Иногда он молча читает файлы 10–15 минут, прежде чем что-то сделать. С одной стороны это бесит, с другой – это потрясающе, потому что сильно повышает шанс того, что он починит правильную вещь. Opus, наоборот, гораздо более резвый – отлично подходит для мелких правок, но не очень для крупных фич или рефакторинга: часто не дочитывает файл или пропускает куски, а потом выдает неэффективное решение или вообще что-то теряет. Я заметил, что хотя у Codex иногда занимает раза в 4 больше времени на сопоставимых задачах, с ним я все равно оказываюсь быстрее, потому что мне не приходится фиксить фикс – а это было нормой, пока я сидел на Claude Code.

Еще Codex позволил мне забыть кучу ритуалов, которые мне нужны были с Claude Code. Вместо “plan mode” я просто начинаю с моделью диалог, задаю вопрос, даю ей погуглить, поизучать код, мы вместе делаем план, и когда меня все устраивает, я пишу “build” или “сохрани план в docs/*.md и собирай”. Plan mode сейчас ощущается как костыль, который был нужен для старого поколения моделей, плохо слушавшихся инструкций, – поэтому приходилось отбирать у них инструменты редактирования. Этот мой сильно недопонятый твит все еще гуляет по сети и он показал мне, что большинство людей не понимает: plan mode – это не волшебство.

Oracle

Скачок от GPT-5/5.1 к 5.2 был огромным. Около месяца назад я собрал oracle 🧿 – CLI, который позволяет агенту запускать GPT-5 Pro, загружать файлы + промпт и управлять сессиями, чтобы ответы можно было получить позже. Я сделал это, потому что много раз, когда агенты застревали, я просил их записать все в markdown-файл, а потом делал запрос сам, и это казалось повторяющейся тратой времени – и возможностью замкнуть цикл. Инструкции лежат в моем глобальном AGENTS.MD, и модель иногда сама запускала oracle, когда застревала. Я использовал это по несколько раз в день. Это был масштабный прорыв. Pro безумно хорошо делает спидран по ~50 сайтам, а потом очень глубоко думает и почти всегда выдает точный ответ. Иногда быстро – за 10 минут, но бывали запуски дольше часа.

Теперь, когда вышел GPT-5.2, у меня гораздо меньше ситуаций, когда он нужен. Я иногда использую Pro сам для исследований, но случаи, когда я просил модель “спросить oracle”, сократились с нескольких раз в день до нескольких раз в неделю. Я не в обиде – собрать oracle было очень весело, я много узнал про браузерную автоматизацию, Windows и наконец-то уделил время навыкам, которые раньше отметал. Это показывает, насколько лучше стал 5.2 для многих реальных задач связанных с кодом. Он one-shot’ит почти все, что я ему задаю.

Еще один огромный плюс – дата отсечки знаний. GPT-5.2 знает до конца августа, в то время как Opus застрял в середине марта – что около 5 месяцев. И это существенная разница, если хочешь использовать самые свежие инструменты.

Конкретный пример: VibeTunnel

Чтобы дать вам понять, как далеко ушли модели. VibeTunnel, терминал-мультиплексор, чтобы кодить на ходу – один первых проектов, над которыми я интенсивно работал. Я вложил в него почти все свое время в начале этого года, и через 2 месяца он стал настолько хорош, что я стал ловить себя на том, что пишу код с телефона, когда тусуюсь с друзьями… и решил, что это надо заканчивать, при чем скорее из соображений ментального здоровья. Тогда я пытался переписать ядро мультиплексора с TypeScript на что-то другое, и старые модели меня постоянно подводили. Я пробовал Rust, Go… прости господи, даже zig. Я мог бы дожать рефакторинг, но это требовало уйму ручного труда, так что я с этим так и не закончил, и проект слег на полку. И на прошлой неделе я сдул с него пыль и дал Codex’у промпт из двух предложений чтобы конвертировать всю систему форвардинга в zig – он крутился пять с лишним часов, сделал несколько утрамбовок контекста, но выдал рабочую версию с одного захода.

А зачем я вообще снова в него полез? Мой текущий фокус – Clawdis, AI-ассистент, у которого полный доступ ко всему на всех моих компьютерах, а так же сообщениям, почте, умному дому, камерам, лампам, музыке, и он даже умеет управлять температурой моей кровати. Конечно, у него есть и свой голос, CLI для твитов и собственный clawd.bot.

Clawd видит и контролирует мой экран, иногда отпускает саркастические ремарки, и еще я захотел дать ему возможность приглядывать за другими моими агентами – а поток символов гораздо эффективнее, чем смотреть изображения… сработает ли – посмотрим!

Мой воркфлоу

Знаю… вы пришли сюда научиться строить быстрее, а я пишу маркетинговый питч за OpenAI. Надеюсь, Anthropic готовит у себя Opus 5 и с ним все опять поменяется. Конкуренция – это хорошо! При этом я обожаю Opus как general-purpose модель. Мой AI-агент не был бы и наполовину так весел на GPT-5. В Opus есть что-то особенное, с ним приятно работать. Я использую его для большинства задач компьютерной автоматизации, и, разумеется, он рулит на Clawd🦞.

Воркфлоу с октябрьского апдейта я почти не поменял.

• Я обычно работаю над несколькими проектами одновременно. От 3 до 8, в зависимости от сложности. Переключение контекста выматывает, я могу так только дома, в тишине, сконцентрировавшись. Это требует большого объема ментального жонглирования. К счастью, большинство моего софта – скучное. CLI для проверки доставки еды не требует напряжения. Обычно у меня один крупный проект в фокусе и проекты-спутники, которые просто крутятся рядом. Когда наработаешь хватку в agentic engineering, у тебя появляется чутье, что окажется легким, а где модель будет страдать – так что часто я просто кидаю промпт, Codex жует задачу минут 30 – и у меня все готово. Иногда необходимо бывает поковыряться или проявить смекалку, но чаще все довольно прямолинейно.

• Я активно пользую очередь промптов в Codex – приходит новая идея, кидаю в пайплайн. Я вижу, как многие экспериментируют с системами мульти-агентной оркестрации, почтой, автоматическим тасктрекингом – пока не вижу в этом смысда, ведь обычно бутылочное горлышко – это я сам. Мой подход к сборке софта – итеративный. Собрал -> погонял -> почувствовал вайб -> появились новые идеи. Редко у меня в голове сразу есть полная картина того, что я хочу. Грубая идея – есть всегда, но она часто радикально меняется по мере итерирования. Так что системы, которые принимают на вход полную идею и выдают готовый результат, мне не подходят. Мне надо потрогать, пощупать, поиграть – и так оно все эволюционирует.

• Я почти никогда не откатываюсь и не пользуюсь чекпоинтами. Если что пошло не так – прошу модель поменять как было. Codex иногда сбрасывает файл, но чаще просто откатывает или модифицирует свои правки сам – крайне редко приходится сбрасывать все полностью, обычно мы просто сворачиваем чуть в сторону. Сборка софта для меня – это как подъем в гору. Не идешь прямо вверх, ты обходишь ее, делаешь повороты, иногда уходишь с тропы и возвращаешься на нее. Не все проходит гладко, но в итоге ты приходишь куда надо.

• Я просто коммичу в main. Иногда Codex решает, что получилось слишком грязно, и сам делает worktree, а потом мержит обратно. Но это бывает редко, и специально я прошу это делать только в исключительных случаях. Когнитивная нагрузка от поддержки разных состояний проекта кажется мне лишней, я предпочитаю линейную эволюцию. Большие задачи я держу для моментов, когда отвлекся – например, пока я пишу этот пост, у меня здесь крутится рефакторинг для 4 проектов, каждый займет час-два. Можно было бы и в worktree, но это просто наплодит мерж-конфликтов и неоптимальных решений. Дисклеймер: обычно я работаю один, большой команде такой воркфлоу не пойдет.

• Способ планирования фичи я уже упомянул. Я постоянно кросс-референсю проекты, особенно если знаю, что что-то подобное уже решал в другом месте – прошу codex заглянуть в ../project-folder, и обычно этого хватает, чтобы он понял из контекста, куда смотреть. Это очень экономит время на инструкции. Можно просто написать “посмотри в ../vibetunnel и сделай то же самое для Sparkle changelogs”, потому что там эта проблема уже решена, и с вероятностью 99% агент корректно ее перенесет и адаптирует. Таким же образом я собираю и новые проекты.

• Я видел много систем для людей, которым надо ссылаться на прошлые сессии. Еще одна штука, которая мне не нужна. Я веду доки по подсистемам и фичам в папке docs в каждом проекте, и использую скрипт + инструкции в глобальном AGENTS, чтобы заставить модель читать доки по определенным темам. Этот подход тем полезнее, чем крупнее проект – так что я делаю это не везде. Но это очень помогает держать доки в свежем состоянии и проектировать лучший контекст для задач.

• Кстати о контексте. Раньше я аккуратно перезапускал сессию для новых задач. С GPT-5.2 это больше не нужно. Производительность отличная даже когда контекст забит – и часто это даже наоборот помогает скорости работы, потому что модель работает шустрее, когда в нее уже загружена пачка файлов. Очевидно, что это сработает только когда задачи сериализованы или изменения далеко друг от друга и две сессии почти не пересекаются. Но у Codex нет системных событий вроде “этот файл изменился”, в отличие от Claude Code, так что будьте аккуратнее. Зато Codex намного лучше в управлении контекстом – я чувствую, что в одной сессии с ним успеваю в 5 раз больше, чем с Claude. Это сильнее, чем просто больший контекст. Догадываюсь, что Codex внутри думает очень сжато, экономя токены, тогда как Opus многословен. Иногда модель косячит и ее внутренний поток мыслей утекает пользователю, я видел это не раз. При этом, у Codex есть своя манера речи, и она меня странно забавляет.

• Промпты. Раньше я писал длинные, расписанные промпты голосовой диктовкой. С Codex мои промпты сильно укоротились, я часто снова печатаю, часто добавляю изображения, особенно когда итерирую UI (или текстовые интерфейсы в CLI). Если показать модели, что не так – то хватит всего нескольких слов, чтобы добиться чего хочешь. Да, я тот человек, который перетаскивает скрин куска интерфейса с подписью “почини паддинги” или “редизайнь”, и это часто либо решает мою проблему, либо двигает меня близко к решению. Раньше я ссылался на markdown-файлы, но со скриптом docs:list это больше не нужно.

• Markdown. Часто я пишу “запиши доки в docs/*.md” и просто даю модели выбрать имя файла. Чем очевиднее ты проектируешь структуру под то, на чем модель тренировали, тем легче будет работать. В конце концов, я проектирую кодовые базы не для своего удобства, я проектирую их так, чтобы агенты могли в них эффективно работать. Бороться с моделью – пустая трата времени и токенов.

Тулинг и инфраструктура

• Что все еще дается сложно? Выбор правильных зависимостей и фреймворка – на это я трачу заметное время. Хорошо ли оно поддерживается? Какие peer dependencies? Популярно ли оно (считай, если будет много world knowledge = агенту будет легче работать)? Аналогично – system design. Будем общаться по веб-сокетам? HTML? Что кладем на сервер, что в клиент? Какие данные куда текут? Это часто сложнее объяснить модели, и тут окупается рисерч и вложенное на подумать время.

• Поскольку у меня куча проектов, я часто запускаю агента просто в папке с проектами, и когда вижу новый паттерн, прошу: “найди все мои свежие go-проекты и накати это изменение туда + обнови changelog”. В каждом проекте патч-версия инкрементируется, и когда я к этому проекту возвращаюсь, меня уже ждут улучшения, которые осталось только протестировать.

• Естественно, я автоматизирую все. Есть skill, который рекгистрирует домены и меняет DNS. Есть один который пишет хорошие фронтенды. В AGENTS есть заметка про мою tailscale-сеть, чтобы я мог просто сказать “сходи на mac studio и обнови xxx”.

• Кстати про несколько маков. Я обычно работаю на двух. MacBook Pro на большом экране и сессия Jump Desktop на Mac Studio на другом. Часть проектов вертится там, часть здесь. Иногда я редактирую разные куски одного и того же проекта на каждой машине и синкаюсь через git. Проще, чем worktree, потому что дрейф на main легко мержится. Плюс: все, что требует UI или browser automation, я могу перенести на Studio – оно не будет мне досаждать поп-апами. (Да, у Playwright есть headless, но ситуаций, где он не работает тоже хватает.)

• Еще бонус: задачи продолжают крутиться там, так что когда я уезжаю, удаленный комп становится основной рабочей станцией, и задачи продолжают идти, даже если я закрыл мак. Я экспериментировал с реально асинхронными агентами вроде Codex Web или Cursor Web в прошлом, но с ними мне не хватало управляемости – в итоге работа упаковывается в pull request, а это добавляет сложности в сетап. Я предпочитаю простоту терминала.

• Я игрался со слэш-командами, но они никогда мне не заходили. Часть заменили skills, на остальное я просто пишу “commit/push” – занимает столько же времени, сколько /commit, и работает всегда.

• Раньше я выделял отдельные дни на рефакторинг и уборку проектов, сейчас я это делаю скорее по факту. Как только промпты начинают долго работать или я вижу что-то уродливое в стриме кода – разбираюсь что происходит прямо на месте.

• Я пробовал Linear и другие issue трекеры, но ничего не прижилось. Важные идеи я пробую сразу, остальное – либо как вспомню, либо забиваю. Конечно, у меня есть публичные баг-трекеры для моего опенсорса, но когда я нахожу баг, я сразу его и фикшу – это быстрее, чем записывать и потом переключаться.

• Что бы вы ни строили, начинайте с модели и CLI. У меня давно крутилась в голове идея Chrome-расширения для саммари YouTube-видео. На прошлой неделе я начал с summarize – CLI тул, который конвертирует что угодно в markdown и скармливает модели для суммаризации. Сначала я довел до приличного состояния ядро, потом за день собрал само расширение. И я в него просто влюблен. Работает на локальных, бесплатных И платных моделях. Транскрибирует видео и аудио локально. Общается с локальным демоном – поэтому работает супер быстро. Поиграйтесь!

• Моя дефолтная модель — gpt-5.2-codex high. Снова – KISS. У xhigh почти нет плюсов кроме того, что он сильно медленнее, а я не хочу тратить ресурсы мозга на режимы и “ultrathink”. Так что у меня почти все крутится на high. GPT-5.2 и Codex достаточно близки, чтобы в замене не было смысла, так что я просто на них и сижу.

Мой конфиг

Вот мой ~/.codex/config.toml:

model = "gpt-5.2-codex"
model_reasoning_effort = "high"
tool_output_token_limit = 25000
# Оставляем место для нативной компакции у границы контекста 272–273k.
# Формула: 273000 - (tool_output_token_limit + 15000)
# При tool_output_token_limit=25000 ⇒ 273000 - (25000 + 15000) = 233000
model_auto_compact_token_limit = 233000
[features]
ghost_commit = false
unified_exec = true
apply_patch_freeform = true
web_search_request = true
skills = true
shell_snapshot = true
[projects."/Users/steipete/Projects"]
trust_level = "trusted"

Это позволяет модели читать больше за раз, дефолты немного маловаты и могут ограничивать то, что она видит. Она фейлит молча, что бесит, но когда-нибудь они это починят. Также веб-поиск все еще не включен по умолчанию? unified_exec заменил tmux и мой старый runner-скрипт, остальное тоже круто. И не бойтесь утрамбовки контекста – с тех пор как OpenAI переключился на новый /compact эндпоинт, она работает достаточно хорошо, чтобы задачи проходили много компактов и доживали до конца. Будет медленнее, но часто это работает как ревью – модель находит баги, когда смотрит на код заново.

На этом оригинальная статья заканчивается. От себя хочу сказать, что хоть в мае 2026 что-то новое почерпнуть для себя из нее сложно – как ретроспектива читается занимательно. Каждый раз, оглядываясь назад, становится немного не по себе от скорости развития этих новых инструментов. Хотя и есть подозрение, что такое изобилие скорости и качества за ту цену, которая есть сейчас, с нами будет не всегда.

А если же вы, видя очередной пост про разработку с агентами, снова думаете “ну и зачем это все” и “подсадили кроликов на подписку” – попробуйте сами, пока не поздно! Ну или не пробуйте, нам больше достанется.

Всем хорошей недели!