Смотреть уроки

Альманах

Версия 2026-06-06

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

Версия: 2026-06-06.

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

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

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

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

Голый Codex/Claude Code часто достаточен

На старте не стоит подключать дополнительные обвязки “на всякий случай”, типа MCP или скиллы какие-то. Сначала достаточно обычного кодекса или клод-кода; если часто используете какой-то промт — оберните его в скилл сами. просто попросите клод/кодекс сделать скилл из промта.

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

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

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

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

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

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

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

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

PRD-интервью

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

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

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

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

TASKS.md и техническое обсуждение

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

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

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

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

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

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

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

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

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

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

Длинный прогон по tasks.md

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

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

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

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

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

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.

Endpoint ID enumeration

Отдельно проверять, нельзя ли перебрать id в backend endpoints и получить или изменить чужие данные.

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

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, спросить свой клод-код.

Материалы: #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 automation

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

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

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

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

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

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

  1. Сформулировать проблему.
  2. Провести PRD-интервью.
  3. Проверить PRD в новом окне с чистым контекстом.
  4. Разбить PRD на TASKS.md.
  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 минут о всех принципах разработки, чтобы вайбкодинг перестал быть магией. Автор на практике показывает, как вайбкодить веб и мобильное приложение, не читая код.

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