🔺 Как устроен Codex

Перевел полный пост Gergely Orosz с деталями того, как в OpenAI делают и используют Codex. Есть интересные инсайты и рассуждения от команды:

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

🟢 Почему выбрали Rust, а не TypeScript. Как его используют смежные команды.

🟢 У коллег реакция разная: «Одни говорят: "Это лучшее, что могло случиться. ... Впереди большое светлое будущее!". Другие: "Чувствую, что теряю навыки и начинаю терять связь с кодовой базой. Если не пишу код, мне сложнее понимать, что происходит".

🟢 Сегодня 50–90% кода (в разных командах по разному) в OpenAI генерируется Codex.

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

🟢 Некоторые инженеры используют «правило 30/70»: 30% кода пишут руками, а 70% генерят. 30% — осознанный выбор, потому что это заставляет думать, сохранять связь с кодовой базой и тренировать инженерное чутьё.

🟢 «Инженерный вкус» становится ключевым навыком. Все интервьюеры независимо называют "вкус" самым важным качеством для инженера-программиста в новой реальности. Объясняют почему и что имеется в виду.

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

🟢 Причины, по которым человек всё ещё планирует лучше Codex.

🟢 "Проблеск будущего ПО, создаваемого ИИ: валидация может стать важнее самого сгенерированного кода."

🟢 Исходники Codex'а

👉 https://habr.com/ru/companies/ods/articles/1001012/

@doomgrad

🔺 get-shit-done

Изучаю подходы к разработке через спеки, когда происходит детальное описание новой фичи, её взаимодействия с другими компонентами, контракты и т.д. (по сути это роль аналитика, составляющего ТЗ). По этим спецификациям дальше идёт поэтапная разработка. Подход для традиционной разработки стандартный, плюсы тут налицо — зафиксировали требования, делаем.

Подход этот постепенно перетекает в разработку с ИИ-агентами, которая формализируется на наших глазах. Несколько набирающих популярность фреймворков на эту тему уже есть, один из них это get-shit-done (нейминг от бога).

Как устроено?

🟢 По сути, это набор скиллов (структурированные инструкции и шаблоны). Есть для Claude Code, Codex, Gemini, OpenCode. В случае с CC, в папке .claude/get-shit-done появятся все инструкции и описания пайплайнов, которые будут выполняться.

Ставим в папку с проектом (не забываем делать ветку), запускаем агент, видим, что появилась куча новых команд, типа /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase.

🟢 Если пишем не с нуля, то запускаем /gsd:map-codebase. Агенты в параллель изучаю код и откладывают артефакты в папку .planning. Доки получаются весьма полезные, описывается архитектура и структура проекта, стек, стиль кодирования и т.д. Читаем документы и правим. Особенно полезен CONCERNS.md, потенциальные проблемы и "запахи", которые нашлись, пишутся туда.

Если даже не использовать GSD по прямому назначению, то как минимум такое описание сделать полезно, а ссылки на него добавить в AGENTS.md.

После этого можно запускать /gsd:new-project. Описываем подробно, что хотим сделать, отвечаем на вопросы, в итоге формулируется разбитый на 3-4 фазы план.

На каждый чих составляются пишется и коммитится документация, потерять что-то из этого будет трудно. После каждой команды можно смело очищать контекст (/clear). Документацию читаем (разработка через чтение), правим.

С фазами работаем командами /gsd:plan-phase 1 и /gsd:execute-phase 1, прошли все фазы, проверили, делаем /gsd:complete-milestone. Документация обновляется, детали идут в архив, создается тег релиза. Повторяем со следующей фичей.

Concerns

🟢 Не надо использовать для простых задач, типа каких-то одношаговых интеграций, рефакторинга табличек или кода в пределах нескольких файлов и т.д. Оно разобьет вам сердце всё на 4 фазы и каждую фазу будет 5 минут планировать и 15 минут делать.

🟢 Штука очень прожорливая, по 20 раз все перепроверяет и пишет кучу доков. Обычной подписки точно не хватит, если использовать как подход к разработке. Если одну-две фичи сделать за пару дней, то норм.

Попробую ещё присмотреться насколько это эффективней чем без всех этих обвесов с фазами делать, но подход мне нравится. Думаю, что будет набирать популярность дальше.

👉 https://github.com/gsd-build/get-shit-done

🤟 Claude Code + telegram

В Claude Code добавили channels. Теперь можно общаться с открытым терминалом через чат пока рубишься в контру.

Настраиваем

🟢 Нужна версия v2.1.80+, делаем claude —update

🟢 Если не подключен официальный репозиторий со скиллами, то подключаем — /plugin marketplace add anthropics/claude-plugins-official

🟢 Устанавливаем плагин /plugin install telegram@claude-plugins-official

🟢 В @BotFather создаем себе бота, получаем токен, прикапываем в .env — /telegram:configure <token>

🟢 Перезапускаем с флагом —channels (если не хотим, чтобы клод слушал канал, то в следующий раз этот флаг не ставим) — claude --channels plugin:telegram@claude-plugins-official

🟢 Видим, что не работает (❎ telegram MCP failed, проверяем в '/plugin' → Installed), ставим bun — npm install -g bun. Перезапускаем с --channels.

🟢 Пишем в бота что-нибудь, получаем pairing code, пишем в терминал /telegram:access pair <code>. Наш телеграм аккаунт добавляется в allowlist.

🟢 Лочим, чтобы никого кроме нас не слушал — /telegram:access policy allowlist

Ограничения

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

В режиме плана, соответственно, тоже. В консоли опции для выбора отрисовывает, в телеграм слать не умеет.

Всё остальное — распараллеливание, написание доков, agent teams и т.д. работает.

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

Всё это пока в research preview, так что тестируем.