Купить уроки

Альманах

Версия 2026-07-28

Сухарев / ЙЙ / альманах

Версия: 2026-07-28.

Прикладной альманах по работе с Codex и Claude Code: как ставить задачи, вести разработку, ревьюить, рефакторить и доводить проект до продакшена.

Основано на постах и сообщениях из источников. Внешние ссылки сохранены как указатели оригинальных материалов.

Быстрый индекс

1. Базовые принципы

Codex и Claude Code часто достаточны без обвязок

На старте не стоит подключать дополнительные обвязки «на всякий случай», типа MCP или скиллы какие-то. Сначала достаточно Codex или Claude Code без дополнительной обвязки; если часто используете какой-то промт — оберните его в скилл сами. Просто попросите Codex или Claude Code сделать скилл из промта.

Материалы: чат, #11, #102.

Код и точный поиск важнее Obsidian/RAG/graph-обвязки

Вот это уже надоело. Самый частый вопрос был — про экономию токенов и какую-то там пятую память в обсидиане — это всё чушь. Код сам является документацией всех реализаций. Модели ищут его и читают, как программисты, смотрят структуру проекта, имена функций и т. д.; RAG/graph-подходы не заменяют ripgrep/grep для кода. Токены экономить без ущерба качеству никак нельзя, только покупать подписку дороже.

Материалы: #57, #75, #99.

Минимальная продуктовая документация полезна

README.md стоит вести коротко с продуктовой точки зрения: что продукт умеет и какую проблему решает, без пересказа всех реализаций.

Материалы: #80.

Codex и Claude Code ускоряют исполнение, но вкус остается у человека

Не нужно мерить свой workflow по воображаемому Сан-Франциско, где у всех уже работают автономные рои агентов. Агент действительно может читать production-логи, находить проблему, готовить fix и участвовать в релизе, но это не отменяет человеческого контроля.

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

Материалы: #209.

«Кодинг» дешевеет, программирование остается фундаментом

Зубрежка синтаксиса языка и методов библиотек теряет ценность: Codex и Claude Code знают синтаксис, а актуальный API могут проверить по документации. Но программирование не сводится к набору кода. Сильный инженер понимает, как устроен компьютер и память, а также как компьютер исполняет программу — вплоть до опыта написания компилятора или интерпретатора.

SICP — «Структура и интерпретация компьютерных программ» дает именно такой фундамент: абстракции, модели вычислений и построение интерпретатора. Курс сложный и ретро-классический, в оригинале использует Scheme, но этот опыт помогает видеть языки как разные формы одних вычислительных идей. Есть русский перевод видеолекций.

Материалы: #198.

2. PRD и постановка задачи

PRD-интервью

Хороший старт — не код сразу, а ТЗ по продукту текстом (PRD.md, Product Requirements Document).

Давай сделаем ТЗ продукта X. Идея в Y и Z.
Задавай мне вопросы по одному с вариантами ответа.
Я буду отвечать. Когда вопросов не останется, сделай PRD.md в корне проекта.
В PRD.md не должно быть размышлений и открытых вопросов: только четкое ТЗ.

После этого в новом контексте: проверить PRD на открытые вопросы и обновить документ.

Материалы: чат, #102, #126.

Папка tasks/ и техническое обсуждение

После PRD агент разбивает работу на этапы и задачи в папку tasks/: одна задача — один отдельный .md-файл. Перед реализацией выбранной задачи нужно обсудить подводные камни, углы, другие проблемы и варианты их решений; пользователь отвечает с продуктовой точки зрения, агент предлагает техническое решение. Затем в этом же окне включается Plan Mode (режим планирования) и пишется план реализации.

Материалы: #102, #103.

Spec-kit (можно попробовать)

github/spec-kit можно попробовать для создания ТЗ, но в целом ТЗ и без этих всех скилов спокойно делается. Процесс такой: ЙЙ задаёт вам вопросы про продукт, вы отвечаете, ЙЙ создаёт ТЗ, потом в отдельном окне делаете независимую проверку PRD и ещё в одном отдельном окне разбиваете его на задачи. Потом реализуете по одной задаче.

Ссылка из источника: https://github.com/github/spec-kit

Материалы: #126.

3. Рабочий цикл разработки с Codex и Claude Code

Маленькие шаги

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

Материалы: чат, #103.

Длинный прогон по tasks/

Для длинной очереди можно дать агенту брать первый незакрытый .md-файл из tasks/. Перед задачей — запустите саб-агента на риски и возможные углы; после задачи — саб-агенты на code review с оценкой. Это требует заранее подготовленных PRD и tasks/ с достаточными лимитами (за $20 никак не хватит, чтобы полностью сделать большую задачу идеально).

Материалы: #103.

Новый контекст там, где нужна независимость

Новое окно нужно, чтобы был чистый контекст. Например, для секьюрити-аудита нужно повторять проверку несколько раз в новых окнах, пока ЙЙ не перестанет находить уязвимости.

Материалы: #102, #129.

Imagegen как дизайн-черновик перед реализацией

Для визуальной задачи полезно разделить дизайн и код: сначала попросить Codex с помощью imagegen нарисовать, что он собирается реализовать, показать результат и дождаться правок. После утверждения визуального направления можно переходить к реализации. Референс заметно повышает качество результата.

Используй imagegen skill для дизайна этой реализации.
Сначала покажи мне дизайн и дождись моих правок,
а к реализации переходи только после утверждения.
Ориентируйся на приложенный референс.

Материалы: #195.

Автотесты главных сценариев

Если приложение уже тяжело проверять руками, основные сценарии нужно покрывать e2e и интеграционными тестами; unit-тесты добавлять там, где они действительно фиксируют локальную инварианту. Начинать стоит с глубокого ревью продукта: разделить приложение на фичи и закрывать их по одной, чтобы тесты не превратились в шум.

Практический цикл: выбрать одну фичу, обсудить с сильным саб-агентом, какие сценарии и уровни тестов нужны, написать тесты, отдать другому независимому саб-агенту на review с оценкой «можно ли этим тестам верить», затем коммитить и переходить к следующей фиче. Инструменты выбирать популярные и привычные для текущего стека, а не изобретать свой тестовый фреймворк.

TDD — нормальный базовый режим для нетривиального поведения: сначала зафиксировать ожидаемый результат тестом, затем сделать минимальную реализацию и только потом рефакторить при зеленой проверке.

Материалы: #149.

4. Code review и саб-агенты

Review после каждой задачи

Код ревью — обязательная часть цикла. Так было всегда, программисты тоже всегда делали (и делают) код ревью друг другу. Лимиты лучше тратить на ревью, чем на следующую фичу, потому что модели часто пропускают ошибки в первой реализации, и нужно дожимать код на ревью.

Материалы: #121, #106, #89.

Саб-агенты для ревью

Полезные роли саб-агентов: регрессии, лишний код и абстракции, возможные баги, best practices/security, проверка «можно ли сделать меньше кода», общая элегантность решения. После ревью основной агент формирует план доработок и принимает только подтвержденные замечания.

Материалы: #28, #106, #121.

Serious bugs review prompt

Адаптация по источникам:

Сделай глубокое code review активных изменений. Работай read-only, ничего не меняй.
Задача — найти серьезные баги, которые в проде бы лопнули: регрессии, ошибки логики,
проблемы безопасности/приватности, потерю данных и места, где не хватает важных тестов.
Проверь не только diff, но и связанные места по цепочке:
route/guard -> handler/service -> API contract -> persistence/external services.
Верни только подтвержденные проблемы: severity, file:line, доказательство по коду, риск,
минимальный fix и какой тест это должен поймать.

Материалы: #28, #41, #85, #106, #121.

Loop-code-review skill

Review-процесс удобно оформить в skill и гонять до оценки 9.5/10 или до отсутствия actionable comments, чтобы не зацикливаться на формальной оценке без реальных правок. Ест много токенов, но что делать, не говорить же ему: «Ой, не надо эти гайки дотягивать, пусть болтаются, токенов жалко».

Материалы: #106, #89.

5. Рефакторинг и DX

Care-refactoring

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

Применять: время от времени, примерно раз в две недели или когда накопилась боль в DX/поддержке.

Материалы: #116, #122, чат.

Если проект уже в продакшене

Refactoring в продакшене должен быть особенно аккуратным и обязательно защищаться e2e, интеграционными или unit-тестами.

UI-refactoring

ЙЙ часто превращает UI код в вермишель. Правило: визуальные стили компонента живут внутри компонента; снаружи остается layout/composition, а не хаотичные style/className overrides.

Материалы: #34, #119.

6. Безопасность и данные

Security audit перед продом

Перед продом нужен многократный глубокий аудит безопасности с фокусом на реальные баги и слабые места.

Адаптация короткого промпта:

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

Материалы: #129, #81, #85.

IDOR: доступ к чужим объектам по id

IDOR (Insecure Direct Object Reference) — это уязвимость, при которой пользователь может получить или изменить чужие данные, просто подставив другой идентификатор объекта: например, заменить /document/123 на /document/124. Если фронтенд по ошибке отправил чужой id, а backend вернул объект без проверки владельца или прав, это всё равно ошибка backend: клиентским данным доверять нельзя.

Инкрементные идентификаторы упрощают перебор. UUID делает идентификаторы менее предсказуемыми, но сам по себе не устраняет IDOR: каждый endpoint должен проверять право текущего пользователя на конкретный объект и при отсутствии доступа возвращать 403 Forbidden либо намеренно не раскрывающий существование объекта 404 Not Found. Если backend по корректному id находит не тот объект из-за ошибки в запросе или связях, это другой баг, а не IDOR.

Проверять такие endpoint'ы лучше последовательно: сначала составить полный список маршрутов, где id указывает на пользовательские данные; затем отдать список независимому саб-агенту на поиск пропусков; после этого по одному запускать отдельное code review каждого endpoint'а. Для найденной уязвимости сначала зафиксировать запрещённый межпользовательский доступ тестом, затем исправить проверку прав на backend и повторить ревью.

Проверь, что у нас в endpoint'ах нет Insecure Direct Object Reference (IDOR).

Сначала найди и выпиши все endpoint'ы, где нужно проверить, что данные одного
пользователя нельзя получить или изменить, подставив другой id в запросе.
Запусти независимого саб-агента, чтобы он перепроверил список и нашёл пропуски.

Затем проверяй endpoint'ы по одному: для каждого запускай отдельного саб-агента
на code review, оценку и комментарии. Если IDOR подтверждён, исправляй его через
TDD: сначала тест на запрещённый доступ, затем минимальный backend-fix.
После проверки переходи к следующему endpoint'у, пока список не закончится.

Материалы: #250, #85, #81.

Rate limiting и защита входа от перебора паролей

У backend нужны две связанные, но разные защиты: общий rate limiter ограничивает частоту запросов к API, а защита входа отдельно ограничивает число неуспешных попыток для одного email. Для одного экземпляра приложения достаточно минимальной реализации в памяти; для нескольких экземпляров нужен общий счётчик в Redis/Valkey, если такой сервис уже есть в инфраструктуре.

Лимит по email не стоит заменять одним ограничением по IP: общий IP бывает у офиса, мобильного оператора или VPN, а атакующий может менять адреса. При этом ответы и задержки не должны позволять определить, зарегистрирован ли email. Порог, окно, время блокировки и поведение после успешного входа нужно зафиксировать тестами.

Проверь, что у нас настроен rate limiter для ограничения количества запросов
в секунду к backend. Реализация может хранить состояние в памяти без
синхронизации между экземплярами либо использовать Redis/Valkey, если они уже
есть в инфраструктуре.

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

CAPTCHA — дополнительный слой, а не замена серверным ограничениям. Если она действительно нужна, сначала стоит глубоко изучить точки риска во всём приложении и выбрать минимальный набор форм, где CAPTCHA не ломает обычный сценарий. Для Cloudflare Turnstile или другого выбранного провайдера перед реализацией нужно проверить актуальную официальную документацию, серверную валидацию токена и поведение для пользователей с VPN.

Материалы: #242.

Read-only prod DB checks

Для подтверждения странных состояний данных и багов агенту можно давать строго read-only доступ к продовой БД. Пример для Яндекс Облака: подключение через yc managed-postgresql connect <cluster_name_or_ID> --db <DB_name> и проверочные SQL-запросы.

Supply-chain audit

При новостях о взломе npm-пакетов: сначала read-only инвентаризация по всем репозиториям, проверка затронутых версий, lockfiles и зависимостей. Если проект затронут — pin безопасной версии, убрать ^, ~ и т. д., не ставить latest, финально вывести список изменений. Для множества репозиториев подходят быстрые параллельные саб-агенты.

Материалы: #15, #94.

Приватность AI-настроек

Для приватных репозиториев нужно проверять настройки Copilot/AI features и политику использования кода.

Ссылка из источника: https://github.com/settings/copilot/features

Материалы: #26.

7. Стек и шаблоны

Практический стек

Рекомендованный стек из поста: backend на TypeScript + Hono + Bun; mobile на Expo + React Native; web на клиентском React/Vite; desktop на Electron; база — Managed Postgres, ORM — Prisma; storage — нативный storage облака (или можно Tigris, это CDN + Storage сразу). Стартовую нагрузку проектировать под 10k пользователей, без микросервисов и Kubernetes на раннем этапе. Для данных под 152-ФЗ — Яндекс Облако.

Материалы: #40.

di-sukharev/vibe

Шаблон для быстрого старта web/mobile: backend, auth, frontend, mobile, Postgres и deployment docs. Удобно, когда нужен уверенный старт и хороший стек, а не сборка инфраструктуры с нуля.

Ссылки из источников:

Материалы: #96, #104, #109, #128, чат.

Mobile/IAP

Mobile-ветка шаблона — если проект требует мобильное приложение. Там уже есть: push уведомления, Apple/Google login и платежи App Store / Google Play. Если mobile не нужен, лишнюю логику лучше не тащить.

Материалы: #100, #104, #109, #128.

SSR только когда нужен SEO

Для закрытых web-app за логином SSR лишний; если SEO нет, берите клиентский React/Vite, это чище и проще. Для ecommerce/публичных SEO-страниц CSR не подойдет, берите SSR/SSG — TanStack Start или Astro, а точный вариант обсудите с Codex или Claude Code.

Материалы: #43.

8. Поиск, токены и документация

Поиск кода можно делегировать дешевой модели

Широкое чтение репозитория можно отдавать более дешевой/быстрой модели как read-only search subagent, а основную модель оставить для решений и реализации. Формат результата: path:line, symbol/route/component, короткий snippet/signature, почему это важно.

Материалы: #99.

Search discipline

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

Материалы: #57, #41.

RAG/Graphify не заменяют точный поиск кода

RAG/graph-инструменты могут быть полезны по заметкам, видео, аудио и картинкам, но для кода точность обычно уступает обычному поиску; модель все равно дожимает результаты через grep/ripgrep.

Материалы: #57, #75, #99.

9. Эксплуатация и мониторинг

Production logs через автоматизацию Codex

Автоматизация может раз в 30 минут смотреть production logs, фильтровать ошибки и сохранять actionable инциденты в errors/<error_name>.md с trace, контекстом и временем. Задача мониторинга — поймать и сохранить ошибку, а не искать root cause.

Разбор errors/ делать отдельно: раз в день смотреть накопленное, чинить ошибки по одной и удалять после фикса.

Материалы: #123.

Нагрузочное тестирование перед продакшеном

Перед продакшеном полезно поднять отдельный контур, максимально похожий на будущий production, и прогнать backend под реалистичной нагрузкой вместе с БД, внешними сервисами, кронами и воркерами. Если инфраструктура еще не выбрана, сначала сравнить подходящие облака и ограничения managed-сервисов; если уже выбрана — тестовый контур должен повторять ее, а не жить локально на ноутбуке.

Тест запускать с отдельной достаточно мощной VM в облаке и через популярный open-source инструмент нагрузочного тестирования. Сценарии фиксировать ступенями, например 1k, 3k, 5k и 10k RPS, но интерпретировать результат прагматично: если продукту на старте хватит 5k, не нужно покупать production-инфру под 10k «на всякий случай».

До запуска нагрузки агент сначала читает реализацию и выписывает очевидные bottleneck под 3-5k RPS: проблема, почему ее нужно исправить и как именно. Во время тестов нужно смотреть логи, сохранять найденные баги в notes/<note.md>, а потом разбирать их на задачи в tasks/<task.md>.

Финальная документация должна описать не максимальную, а минимально достаточную стартовую инфраструктуру: с какого tier managed Postgres начинать, как вертикально масштабировать БД при росте нагрузки и как горизонтально масштабировать backend, не переплачивая за запас, который продукт пока не использует.

Материалы: #148.

10. Адаптация под любой проект

Редакторская адаптация по источникам выше, краткая прикладная схема.

Новый продукт

  1. Сформулировать проблему.
  2. Провести PRD-интервью.
  3. Проверить PRD в новом окне с чистым контекстом.
  4. Разбить PRD на отдельные .md-задачи в tasks/.
  5. Выбрать стек/шаблон после PRD (лучше сразу https://github.com/di-sukharev/vibe).
  6. Перед задачей обсудить edge cases и план.
  7. После задачи запустить review.

Материалы: чат, #102, #103, #126, #121.

Существующий проект

  1. Начать с read-only анализа.
  2. Найти владельца поведения и связанные контракты.
  3. Выделить один безопасный change set.
  4. Покрыть рискованный behavior тестом, если это пропорционально.
  5. Прогнать targeted tests/checks.
  6. Запустить независимое code review.

Материалы: #41, #85, #106, #116, #121.

Проект в продакшене

  1. Любой refactoring — очень аккуратно.
  2. Обязательно e2e/integration/unit test по изменяемому поведению.
  3. Security audit перед крупными изменениями.
  4. Мониторинг логов после релиза.
  5. Ошибки сохранять отдельно и чинить по одной.

Материалы: чат, #123, #129.

Уроки вайб~кодинга

25+ видео по ~20 минут о всех принципах разработки, чтобы вайбкодинг перестал быть магией. Автор на практике показывает, как вайбкодить веб и мобильное приложение, не читая код.

Материалы: уроки

11. Границы источника

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