Отгружаем код со скоростью инференса

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

Невероятно, как далеко продвинулся «вайб-кодинг» в этом году. Если примерно в мае я удивлялся тому, что некоторые промпты выдавали код, работающий из коробки, то теперь это моё ожидание по умолчанию. Сейчас я могу отгружать код с такой скоростью, которая кажется нереальной. С тех пор я сжёг кучу токенов. Пора написать апдейт.

Забавно, как работают эти агенты. Несколько недель назад был спор о том, что нужно писать код самому, чтобы чувствовать плохую архитектуру, и что использование агентов создаёт отключённость от процесса — и я категорически не согласен. Когда проводишь достаточно времени с агентами, точно знаешь, сколько что-то должно занять, и когда codex возвращается, не решив задачу с первого раза, у меня уже появляются подозрения.

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

Настоящий прорыв в строительстве как на конвейере случился с GPT 5. Мне понадобилось несколько недель после релиза, чтобы это увидеть — и чтобы codex подтянулся по фичам, которые были у claude code, и немного времени, чтобы изучить и понять различия, но потом я стал доверять модели всё больше и больше. Сейчас я не особо читаю код. Я слежу за потоком и иногда смотрю на ключевые части, но, честно говоря, большую часть кода я не читаю. Я знаю, где какие компоненты находятся, как устроена структура и как спроектирована общая система, и обычно этого достаточно.

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

Тем, кто делает штуки для Mac или iOS: вам больше не особо нужен Xcode. Я даже не использую файлы xcodeproj. Инфраструктура сборки Swift достаточно хороша для большинства задач в наши дни. codex знает, как запускать iOS-приложения и как работать с Симулятором. Никаких особых штук или MCP не нужно.

Я пишу этот пост, пока codex перемалывает огромный многочасовой рефакторинг и расхлёбывает старые грехи Opus 4.0. Люди в Твиттере часто спрашивают меня, в чём большая разница между Opus и codex и зачем это вообще важно, если бенчмарки так близки. По-моему, становится всё сложнее доверять бенчмаркам — нужно попробовать оба, чтобы по-настоящему понять. Что бы OpenAI ни сделала в пост-тренинге, codex был натренирован читать МНОГО кода перед тем, как начинать.

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

codex также позволил мне разучить кучу ритуалов, которые были необходимы с Claude Code. Вместо «план-режима» я просто начинаю разговор с моделью, задаю вопрос, даю ей погуглить, исследовать код, вместе составляю план, и когда мне нравится то, что я вижу, пишу «build» или «write plan to docs/*.md and build this». План-режим ощущается как хак, который был необходим для старых поколений моделей, не очень хорошо следовавших промптам, поэтому нам приходилось забирать у них инструменты редактирования. Есть мой сильно неправильно понятый твит, который до сих пор ходит по кругу и показал мне, что большинство людей не понимают, что план-режим — это не магия.

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

Теперь, когда вышел GPT 5.2, у меня гораздо меньше ситуаций, где это нужно. Я сам иногда использую Pro для исследований, но случаи, когда я просил модель «спросить оракула», сократились с нескольких раз в день до нескольких раз в неделю. Я не расстроен — строить oracle было супер весело, и я многому научился про автоматизацию браузера, Windows и наконец уделил время навыкам (skills), отмахиваясь от этой идеи довольно долго. Что это показывает — насколько лучше стал 5.2 для многих реальных задач кодинга. Он решает почти всё, что я ему кидаю, с первого раза.

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

Чтобы дать ещё один пример того, как далеко продвинулись модели. Один из моих ранних интенсивных проектов — VibeTunnel. Терминальный мультиплексор, чтобы можно было кодить на ходу. Я вкладывал в него практически всё своё время ранее в этом году, и через 2 месяца он стал настолько хорош, что я ловил себя на том, что кожу с телефона, гуляя с друзьями… и решил, что это нужно прекратить, скорее ради ментального здоровья, чем по какой-либо другой причине. Тогда я пытался переписать ключевую часть мультиплексора с TypeScript, и старые модели раз за разом меня подводили. Я пробовал Rust, Go… боже упаси, даже zig. Конечно, я мог бы закончить этот рефакторинг, но это потребовало бы кучу ручной работы, так что я так и не добрался до завершения, прежде чем отложил проект. На прошлой неделе я стряхнул с него пыль и дал codex промпт в два предложения — конвертировать всю систему форвардинга в zig, и он работал больше 5 часов и несколько компакций и выдал работающую конверсию с первого раза.

Зачем я вообще стряхнул с него пыль, спросите вы? Мой текущий фокус — Clawdis, ИИ-ассистент, который имеет полный доступ ко всему на всех моих компьютерах, сообщениям, почте, домашней автоматизации, камерам, свету, музыке, чёрт возьми, он даже может контролировать температуру моей кровати. Разумеется, у него также свой голос, CLI для твитов и собственный clawd.bot.

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

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

Мой рабочий процесс не сильно изменился с моего последнего описания в октябре.

Обычно я работаю над несколькими проектами одновременно. В зависимости от сложности это может быть от 3 до 8. Переключение контекста может утомлять, я реально могу это делать только когда работаю дома, в тишине и с концентрацией. Это много ментальных моделей, которые нужно жонглировать. К счастью, большая часть софта скучная. Создание CLI для проверки доставки еды не требует много размышлений. Обычно мой фокус на одном большом проекте и сателлитных проектах, которые пыхтят параллельно. Когда достаточно занимаешься агентной инженерией, развиваешь чутьё на то, что будет легко, а где модель, скорее всего, споткнётся, поэтому часто я просто вбиваю промпт, codex пыхтит минут 30, и у меня есть то, что нужно. Иногда требуется немного подкрутить или проявить креативность, но часто всё просто.

Я активно пользуюсь функцией очереди в codex — как только приходит новая идея, добавляю её в конвейер. Я вижу, как многие экспериментируют с различными системами мультиагентной оркестрации, имейлами или автоматическим управлением задачами — пока я не вижу в этом большой нужды — обычно узкое место — это я сам. Мой подход к созданию софта очень итеративный. Я строю что-то, играю с этим, смотрю, как оно «ощущается», и потом приходят новые идеи для доработки. Редко когда у меня в голове есть полная картина того, что я хочу. Конечно, есть примерное представление, но часто оно кардинально меняется по мере исследования предметной области. Поэтому системы, которые берут полную идею на вход и потом выдают результат, не работали бы для меня. Мне нужно поиграть с этим, потрогать, почувствовать, увидеть — так я это развиваю.

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

Я просто коммичу в main. Иногда codex решает, что слишком грязно, и автоматически создаёт worktree, а потом мёрджит изменения обратно, но это редкость, и я прошу об этом только в исключительных случаях. Дополнительная когнитивная нагрузка от необходимости думать о разных состояниях в проектах мне кажется ненужной, и я предпочитаю развивать их линейно. Большие задачи я оставляю на моменты, когда отвлечён — например, пока пишу этот текст, у меня крутятся рефакторинги на 4 проектах, каждый из которых займёт примерно 1–2 часа. Конечно, я мог бы делать это в worktree, но это просто вызвало бы кучу конфликтов слияния и субоптимальные рефакторинги. Оговорка: я обычно работаю один, если вы работаете в большой команде, такой подход, очевидно, не прокатит.

Я уже упоминал свой способ планирования фичи. Я постоянно перекрёстно ссылаюсь между проектами, особенно если знаю, что уже решил что-то где-то ещё, я прошу codex посмотреть в ../project-folder, и этого обычно достаточно, чтобы он по контексту понял, куда смотреть. Это крайне полезно для экономии промптов. Я могу просто написать «look at ../vibetunnel and do the same for Sparkle changelogs», потому что это уже решено там, и с 99% гарантией он правильно скопирует и адаптирует к новому проекту. Так же я скаффолдю новые проекты.

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

Кстати о контексте. Раньше я был очень дисциплинирован в перезапуске сессии для новых задач. С GPT 5.2 это больше не нужно. Производительность остаётся отличной даже при заполненном контексте, и часто это помогает со скоростью, поскольку модель работает быстрее, когда она уже загрузила много файлов. Очевидно, это хорошо работает только когда вы сериализуете задачи или держите изменения настолько далеко друг от друга, что две сессии почти не пересекаются. У codex нет системных событий «этот файл изменился», в отличие от claude code, поэтому нужно быть осторожнее — с другой стороны, codex НАМНОГО лучше управляет контекстом, я чувствую, что делаю в 5 раз больше за одну сессию codex, чем с claude. Это больше, чем просто объективно больший размер контекста, тут работает что-то ещё. Моя догадка — codex внутренне думает очень сжато, чтобы экономить токены, тогда как Opus очень многословен. Иногда модель лажает, и её внутренний поток мышления утекает к пользователю, так что я видел это довольно много раз. Реально, у codex такой способ выражаться, который я нахожу странно занимательным.

Промпты. Раньше я писал длинные, подробные промпты через голосовой ввод. С codex мои промпты стали гораздо короче, я часто снова печатаю, и много раз добавляю изображения, особенно при итерации над UI (или текстовыми интерфейсами CLI). Если показать модели, что не так, достаточно нескольких слов, чтобы она сделала то, что нужно. Да, я тот самый человек, который закидывает обрезанное изображение какого-нибудь UI-компонента с «fix padding» или «redesign», и во многих случаях это либо решает мою проблему, либо продвигает достаточно далеко. Раньше я ссылался на markdown-файлы, но с моим скриптом docs:list это больше не нужно.

Маркдауны. Часто я пишу «write docs to docs/*.md» и просто позволяю модели выбрать имя файла. Чем очевиднее вы проектируете структуру под то, на чём модель обучена, тем легче будет ваша работа. В конце концов, я проектирую кодовые базы не для того, чтобы мне было легко в них ориентироваться, а чтобы агенты могли в них эффективно работать. Бороться с моделью — часто пустая трата времени и токенов.

Что всё ещё сложно? Выбор правильной зависимости и фреймворка — это то, во что я инвестирую довольно много времени. Хорошо ли это поддерживается? Как с транзитивными зависимостями? Популярно ли это = будет ли достаточно мирового знания, чтобы агентам было легко? Так же и с проектированием системы. Будем общаться через веб-сокеты? HTML? Что положить на сервер, а что на клиент? Как и какие данные куда текут? Часто это вещи, которые чуть сложнее объяснить модели и где исследование и обдумывание окупаются.

Поскольку я управляю множеством проектов, часто я просто запускаю агента в папке проекта, и когда нахожу новый паттерн, прошу его «find all my recent go projects and implement this change there too + update changelog». У каждого из моих проектов есть увеличенная патч-версия в этом файле, и когда я возвращаюсь к нему, некоторые улучшения уже ждут меня для тестирования.

Разумеется, я автоматизирую всё. Есть навык (skill) для регистрации доменов и смены DNS. Один для написания хороших фронтендов. Есть заметка в моём файле AGENTS о моей сети tailscale, так что я могу просто сказать «go to my mac studio and update xxx».

Кстати о нескольких Маках. Обычно я работаю на двух Маках. Мой MacBook Pro на большом экране и сессия Jump Desktop к моему Mac Studio на другом экране. Некоторые проекты варятся там, некоторые — тут. Иногда я редактирую разные части одного и того же проекта на каждой машине и синхронизирую через git. Проще, чем worktree, потому что расхождения на main легко примирить. Дополнительное преимущество в том, что всё, что требует UI или автоматизации браузера, я могу переместить на Studio, и оно не будет раздражать меня всплывающими окнами. (Да, у Playwright есть headless-режим, но хватает ситуаций, где он не работает)

Ещё одно преимущество — задачи продолжают крутиться там, так что когда я путешествую, удалённая машина становится моей основной рабочей станцией, и задачи просто продолжают работать, даже если я закрою свой Мак. Я экспериментировал с настоящими асинхронными агентами, такими как codex или Cursor web, в прошлом, но мне не хватает управляемости, и в итоге работа заканчивается как пул-реквест, что снова добавляет сложности к моей конфигурации. Мне гораздо больше нравится простота терминала.

Раньше я игрался со слэш-командами, но так и не нашёл их особо полезными. Навыки (skills) заменили часть из них, а для остального я продолжаю писать «commit/push», потому что это занимает столько же времени, сколько /commit, и всегда работает.

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

Я пробовал Linear или другие трекеры задач, но ничего не прижилось. Важные идеи я пробую сразу, а всё остальное я либо запомню, либо это не было важным. Конечно, у меня есть публичные баг-трекеры для людей, использующих мой open source код, но когда я нахожу баг, я тут же пишу промпт — гораздо быстрее, чем записывать и потом переключать контекст обратно.

Что бы вы ни строили, начинайте с модели и 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 # Leave room for native compaction near the 272–273k context window. # Formula: 273000 - (tool_output_token_limit + 15000) # With 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 и мой старый скрипт-раннер, остальное тоже полезно. И не бойтесь компакции — с тех пор как OpenAI переключился на новый эндпоинт /compact, это работает достаточно хорошо, чтобы задачи могли проходить через множество компакций и завершаться. Это замедлит работу, но часто действует как ревью, и модель находит баги, когда смотрит на код снова.

Оригинал тут.