How to Work and Compound with AI

eugeneyan

eugeneyan

Начните здесь Статьи Выступления Прототипы Обо мне

How to Work and Compound with AI

Как работать с ИИ и получать накопительный эффект

[ ai productivity mechanism ] · 13 min read

[ ai productivity mechanism ] · 13 мин. чтения

How can we work effectively with AI? What’s the workflow, how does it scale, and how do we improve our systems over time? And ideally, it should compound. Every finished artifact—code, docs, analysis, decisions—becomes context for the next session. And each correction updates a config that reduces future errors. While I’m still learning, I’ve repeated my answers often enough that I’m writing it here so the next time I’m asked I can share a link instead.

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

If you use AI regularly, you likely already apply many of these practices. Nonetheless, I believe the underlying principles apply broadly: provide good context, encode your taste as config, make verification easy, delegate bigger tasks, and close the loop. If a practice does not fit, adapt the principle and invent your own. Also notice, as you read, that none of this is specific to AI. It’s simply how you onboard and work with any new collaborator.

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

• • •

• • •

Context as infrastructure

Контекст как инфраструктура

Help models nagivate your context. For example, all my code lives in ~/src and all my knowledge work lives in ~/vault (organized into projects/, notes/, kb/ and so on). When our work is organized, it makes it easier for the model to retrieve context using grep or glob. And by having a clean directory tree, it’s more straightforward to navigate the directory, and find and lean on prior code, project docs, analysis, etc. to improve the work being done.

Помогайте моделям ориентироваться в вашем контексте. Например, весь мой код живёт в ~/src, а вся интеллектуальная работа — в ~/vault (организована в projects/, notes/, kb/ и т. д.). Когда работа организована, модели проще извлекать контекст с помощью grep или glob. А чистое дерево каталогов упрощает навигацию, поиск и использование предыдущего кода, проектных документов, аналитики и т. д. для улучшения текущей работы.

Connect models to your organization’s context. Models can benefit from organizational knowledge which likely lives in Slack, Drive, Mail, etc. Most have MCPs for Claude Code, Cowork, Claude.ai. On top of these, I also maintain a INDEX.md per project. It’s an annotated index of the relevant docs and channels, and each entry includes the URL, owner, and a brief paragraph explaining what’s inside and when to read it. The annotation helps a lot. A bare list of URLs forces the model to open every link to figure out what’s relevant, wasting time and context. By annotating upfront, we do the heavy lifting once and store it in the index.

Подключайте модели к контексту вашей организации. Модели могут извлекать пользу из организационных знаний, которые, скорее всего, хранятся в Slack, Drive, Mail и т. д. Для большинства из них существуют MCP для Claude Code, Cowork, Claude.ai. Помимо этого, я веду INDEX.md для каждого проекта. Это аннотированный указатель релевантных документов и каналов: каждая запись включает URL, владельца и краткий абзац, объясняющий содержание и когда стоит читать. Аннотации очень помогают. Голый список URL заставляет модель открывать каждую ссылку, чтобы понять, что релевантно, — это трата времени и контекста. Аннотируя заранее, мы выполняем тяжёлую работу один раз и сохраняем её в индексе.

Onboard each new session like a new hire. With each new session, the model starts with a blank slate. Thus, it helps to treat the per-project CLAUDE.md like the onboarding doc we’d hand to a new teammate on day one. Claude scanned my per-project CLAUDE.md files and highlighted that they included glossaries for acronyms, project code names, and teammates with the same first name. I also have a suggested reading order in the CLAUDE.md, like telling the model to skim INDEX.md first, then TODOS.md, and finally specific topic notes.

Вводите каждую новую сессию в курс дела как нового сотрудника. С каждой новой сессией модель начинает с чистого листа. Поэтому полезно относиться к проектному CLAUDE.md как к документу для онбординга, который мы вручили бы новому коллеге в первый день. Claude просканировал мои проектные CLAUDE.md-файлы и отметил, что они включают глоссарии аббревиатур, кодовые названия проектов и коллег с одинаковыми именами. Также у меня есть рекомендуемый порядок чтения в CLAUDE.md — например, сначала просмотреть INDEX.md, потом TODOS.md, и наконец конкретные тематические заметки.

Build your memory layer. By default, models don’t remember what happened in the last session, so anything worth persisting should be written to disk. I split my memory layer into two buckets. ~/vault holds facts such as project state, artifacts, and domain knowledge; ~/.claude (along with its CLAUDE.md, skills/, guides/) contains my preferences, workflows, and personal taste. The former provides context while the latter provides configuration.

Создайте свой слой памяти. По умолчанию модели не помнят, что происходило в прошлой сессии, поэтому всё ценное нужно записывать на диск. Мой слой памяти разделён на два сегмента. ~/vault хранит факты: состояние проекта, артефакты и доменные знания; ~/.claude (вместе с CLAUDE.md, skills/, guides/) содержит мои предпочтения, рабочие процессы и личный вкус. Первое обеспечивает контекст, второе — конфигурацию.

Taste as configuration

Вкус как конфигурация

Start with ~/.claude/CLAUDE.md. Claude reads this at the start of every session. I think of it as a behavioral contract. My CLAUDE.md contains preferences like how direct to be, when to push back, how to handle mistakes, what to teach me, etc. Here’s a trimmed version:

Начните с ~/.claude/CLAUDE.md. Claude читает этот файл в начале каждой сессии. Я воспринимаю его как поведенческий контракт. Мой CLAUDE.md содержит предпочтения: насколько прямолинейным быть, когда возражать, как обрабатывать ошибки, чему меня учить и т. д. Вот сокращённая версия:

<behavior> - Be direct and push back when you disagree; if my approach has problems, say so. - When unsure about something, say you're unsure rather than guessing confidently. - When something fails, investigate the root cause before retrying. - Keep diffs scoped to the task: no drive-by reformats or unrelated refactors. ... </behavior> <teaching> I'm always picking up new systems and domains. When a key term surfaces that I likely haven't internalized, explain it in 1-2 sentences and then move on. Format: > 💡 followed by 1 - 2 sentence explanation ... </teaching>

- Говори прямо и возражай, если не согласен; если в моём подходе есть проблемы, скажи об этом. - Когда не уверен в чём-то, скажи, что не уверен, а не отвечай уверенно наугад. - Когда что-то не работает, разберись в причине, прежде чем пробовать снова. - Держи диффы в рамках задачи: никаких попутных переформатирований и несвязанных рефакторингов. ... Я постоянно осваиваю новые системы и области. Когда всплывает ключевой термин, который я, вероятно, ещё не усвоил, объясни его в 1–2 предложениях и двигайся дальше. Формат: > 💡 затем объяснение в 1–2 предложения ...

Scope it by directory: global, then repo, then project. Put preferences that apply everywhere (e.g., behavior, long-term goals, teaching) in ~/.claude/CLAUDE.md. Put conventions for a specific a repo (e.g., linting, naming, pull requests) in the repo’s root. Put project-specific context (i.e., directory layout, domain knowledge) in the project directory. When you start Claude Code in a subdirectory, it walks up the tree and loads each CLAUDE.md. And when the model navigates into a subdirectory mid-session, the model picks up that directory’s CLAUDE.md too. More in the docs.

Задавайте область действия по каталогам: глобальная, затем репозиторий, затем проект. Предпочтения, которые действуют везде (поведение, долгосрочные цели, обучение), кладите в ~/.claude/CLAUDE.md. Конвенции для конкретного репозитория (линтинг, именование, пулл-реквесты) — в корень репозитория. Проектный контекст (структура каталогов, доменные знания) — в каталог проекта. Когда вы запускаете Claude Code в подкаталоге, он поднимается по дереву и загружает каждый CLAUDE.md. А когда модель переходит в подкаталог в процессе сессии, она подхватывает и его CLAUDE.md. Подробнее в документации.

When CLAUDE.md gets too long, split it out. A long CLAUDE.md can become a context tax. It loads everything every session even if the session doesn’t need it. To fix this, refactor chunks into guides that load lazily. Don’t @import them (because that just inlines them). Instead, tell your CLAUDE.md to read them when relevant. This way, a session that’s building evals skips the guide on writing docs. Here’s an example guide section:

Когда CLAUDE.md становится слишком длинным, выносите части наружу. Длинный CLAUDE.md может стать налогом на контекст. Он загружает всё в каждую сессию, даже если сессии это не нужно. Решение — рефакторинг фрагментов в гайды, которые загружаются лениво. Не используйте @import (потому что это просто инлайнит содержимое). Вместо этого укажите в CLAUDE.md, чтобы модель читала их по мере необходимости. Так сессия, в которой вы строите эвалы, пропустит гайд по написанию документации. Пример секции гайдов:

<guides> - Docs, 1-pagers, any writing: ~/.claude/guides/writing.md - Eval building and reports: ~/.claude/guides/evals.md - Dashboards: ~/.claude/guides/dashboards.md ... </guides>

- Документация, одностраничники, любые тексты: ~/.claude/guides/writing.md - Создание и отчёты по эвалам: ~/.claude/guides/evals.md - Дашборды: ~/.claude/guides/dashboards.md ...

If you do something ≥ once a week, make it a skill. A skill is a markdown file with a name, trigger, and procedure that the model loads on demand. Think of skills as workflows written in markdown. They can include logic. For example, my /polish skill looks at the artifact diff. If it produces a metric, it runs the associated eval. If it renders in a browser, it checks the output via Claude in Chrome. If neither, it runs the code and reads the output or error. Skills encode both the steps and the judgment of which steps apply. A few I have include:

Если вы делаете что-то ≥ раза в неделю, сделайте это навыком. Навык (skill) — это markdown-файл с именем, триггером и процедурой, который модель загружает по требованию. Думайте о навыках как о рабочих процессах, написанных на markdown. Они могут включать логику. Например, мой навык /polish смотрит на дифф артефакта. Если он выдаёт метрику — запускает соответствующий эвал. Если рендерится в браузере — проверяет вывод через Claude in Chrome. Если ни то, ни другое — запускает код и читает вывод или ошибку. Навыки кодируют и шаги, и суждение о том, какие шаги применять. Вот несколько моих:

/polish: проверяет на баги, упрощает код, верифицирует вывод (через эвалы, Claude in Chrome или другим способом), итерирует, пока не останется критических замечаний, создаёт черновик PR /write: берёт у меня интервью для плана, запускает исследовательских субагентов, пишет черновик, даёт обратную связь через adversarial-критика, итерирует до отсутствия критических замечаний /daily: читает мой календарь, Slack, PR-ы, вчерашний лог и т. д. и составляет приоритеты на сегодня

I tend to keep SKILL.md small and focused on the workflow and routing. The knowledge, like templates and scripts, are separate files that the model reads and runs only when needed, just like lazy-loaded guides.

Я стараюсь держать SKILL.md компактным и сфокусированным на рабочем процессе и маршрутизации. Знания — шаблоны и скрипты — хранятся в отдельных файлах, которые модель читает и запускает только по необходимости, как и лениво загружаемые гайды.

Bootstrap skills by doing the task once and then asking the model to make it a skill. This is how I build most skills. First, I do the task once, interactively, in a normal session. Then, I ask the model to turn what we just did into a skill. Next, I run the skill on the same or similar task. Inevitably, I’ll need to correct the output, which I do in the same session so feedback is logged in the session transcript. Finally, I ask the model to update the skill based on the corrections and feedback. You can also seed a skill with exapmles of the desired output. Ask the model to extract the patterns, like how you organize your code, or the structure and tone of your docs.

Создавайте навыки по принципу «сделай задачу один раз, потом попроси модель превратить это в навык». Так я создаю большинство навыков. Сначала я выполняю задачу один раз, интерактивно, в обычной сессии. Потом прошу модель превратить то, что мы только что сделали, в навык. Затем запускаю навык на той же или аналогичной задаче. Неизбежно приходится корректировать вывод — я делаю это в той же сессии, чтобы обратная связь осталась в транскрипте. Наконец, прошу модель обновить навык на основе исправлений и обратной связи. Также можно заполнить навык примерами желаемого результата. Попросите модель извлечь паттерны — как вы организуете код, структуру и тон документации.

Refine skills via the transcript, not the file directly. The first version of the skill rarely works perfect because it overfits the original session. This is normal. When you run it and need to update the output, correct it within the session. Try not to open and edit SKILL.md directly. Providing feedback in the session gives the model before-and-after pairs which accumulate in the transcript—here’s what we did, here’s what I wanted, and why. Once the output is right, ask the model to merge the feedback into the skill. After a few rounds, the skill converges and you barely have to edit the final output.

Совершенствуйте навыки через транскрипт, а не редактируя файл напрямую. Первая версия навыка редко работает идеально, потому что она переобучена на исходную сессию. Это нормально. Когда вы запускаете навык и нужно поправить вывод — корректируйте прямо в сессии. Старайтесь не открывать и не редактировать SKILL.md напрямую. Обратная связь внутри сессии даёт модели пары «до и после», которые накапливаются в транскрипте — вот что мы сделали, вот чего я хотел и почему. Когда вывод станет правильным, попросите модель объединить обратную связь в навык. После нескольких раундов навык сходится, и вам почти не нужно редактировать финальный результат.

Nonetheless, not every task needs this context. For brainstorming, exploration, and rough drafts, I enjoy using simple mode (CLAUDE_CODE_SIMPLE=1 claude). Here, CLAUDE.md still loads but the agentic harness—hooks, skills, tool-heavy loops—doesn’t. This gets me closer to the model, which is what I want when I’m thinking out loud rather than shipping.

Тем не менее не каждой задаче нужен весь этот контекст. Для мозгового штурма, исследований и черновиков я люблю использовать простой режим (CLAUDE_CODE_SIMPLE=1 claude). Здесь CLAUDE.md по-прежнему загружается, но агентная обвязка — хуки, навыки, тяжёлые инструментальные циклы — нет. Так я оказываюсь ближе к модели, а это то, что нужно, когда думаешь вслух, а не отгружаешь готовое.

Verification for autonomy

Верификация ради автономии

Shift verification left; catch errors at write time. I think of verification as a ladder. The bottom is cheap and deterministic; the top is expensive and requires judgement. We want to address issues at the lowest possible rung. Near the bottom are post-edit hooks that run ruff format, ruff check --fix on files the model just updated. This happens deterministically and doesn’t cost tokens. Higher on the ladder are tests, evals, LLM reviews, etc.

Сдвигайте верификацию влево — ловите ошибки на этапе написания. Я представляю верификацию как лестницу. Внизу — дешёвые детерминированные проверки; наверху — дорогие, требующие суждения. Мы хотим устранять проблемы на как можно более низкой ступеньке. Ближе к основанию — post-edit хуки, которые запускают ruff format, ruff check --fix на файлах, которые модель только что обновила. Это происходит детерминированно и не стоит токенов. Выше по лестнице — тесты, эвалы, LLM-ревью и т. д.

Make it easy for the model to verify the work. Give the model feedback loops to improve its output. If the system produces a metric, let the model run the eval and optimize it. If the output renders in a browser, let the model inspect it via Claude in Chrome. If neither, let the model run it and read the error. For example, when building Docker images, I let the model build, read the error, edit the Dockerfile, and rebuild. If I’m tuning a harness, the model runs evals, reads the transcripts, and fixes failures. When building a dashboard, the model checks in Chrome that tooltips render, labels don’t overlap, and the narrative matches the numbers.

Упрощайте модели верификацию работы. Давайте модели петли обратной связи для улучшения результата. Если система выдаёт метрику — дайте модели запустить эвал и оптимизировать её. Если вывод рендерится в браузере — дайте модели проверить его через Claude in Chrome. Если ни то, ни другое — дайте модели запустить код и прочитать ошибку. Например, при сборке Docker-образов я позволяю модели собрать, прочитать ошибку, отредактировать Dockerfile и пересобрать. Если я настраиваю обвязку, модель запускает эвалы, читает транскрипты и исправляет сбои. При создании дашборда модель проверяет в Chrome, что тултипы рендерятся, подписи не наезжают друг на друга, а нарратив соответствует числам.

For long-running tasks, have models watch models. Long sessions can drift as errors build up. One fix is to run a secondary session with fresh context to read the original spec and the recent turns of the primary session. My minimal setup uses two tmux panes, one for the primary dev, one for the pair programmer. Initial instructions and follow-up prompts are appended to a shared file. Periodically, the pair programmer spins up, checks the spec against the primary’s recent transcript, and if something’s off, provides feedback to course correct.

Для длительных задач пусть модели следят за моделями. Долгие сессии могут отклоняться по мере накопления ошибок. Одно из решений — запустить вторичную сессию со свежим контекстом, которая читает исходную спецификацию и последние ходы основной сессии. Мой минимальный сетап использует две панели tmux: одну для основного разработчика, вторую для парного программиста. Начальные инструкции и последующие промпты дописываются в общий файл. Периодически парный программист запускается, сверяет спецификацию с последним транскриптом основной сессии и, если что-то не так, даёт обратную связь для корректировки курса.

We can do this in various ways. For example, the pair programmer can watch for execution drift—is the model doing the task right? This is local and tactical, like ignoring an error, reporting a bad metric, or diverging from the spec. There’s also direction drift—is the model doing the right task? These are bigger picture and strategic, and occur when the model misinterprets the original intent and spends hours building the wrong thing. Check for execution drift often and direction drift occasionally.

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

Scaling via delegation

Масштабирование через делегирование

Delegate increasingly bigger chunks of work. Sometimes, we pair-program with models: short tasks, fast feedback, staying in the loop. This well works for fast iterations, exploratory analysis, and prototyping. But with increasingly stronger models, we should aim to delegate bigger tasks. Explain your intent, constraints, and success criteria upfront, then let the model work. You can’t delegate what you can’t verify, so this requires first defining success criteria and metrics. The shift is from giving instructions, one at a time, to fleshing out plans and letting the model execute them end to end:

Делегируйте всё более крупные блоки работы. Иногда мы программируем в паре с моделями: короткие задачи, быстрая обратная связь, постоянный контроль. Это хорошо работает для быстрых итераций, исследовательского анализа и прототипирования. Но с появлением всё более сильных моделей стоит стремиться к делегированию более крупных задач. Объясните свой замысел, ограничения и критерии успеха заранее, а потом дайте модели работать. Нельзя делегировать то, что нельзя верифицировать, поэтому сначала нужно определить критерии успеха и метрики. Суть сдвига — от пошаговых инструкций к проработке планов, которые модель выполняет от начала до конца:

“Given these eval suites, build isolated containers per suite and smoke-test that each builds. Then, do the full run, log the eval metrics and transcripts, and use subagents to read the transcripts and confirm the evals ran correctly. Run each eval n times for confidence intervals. Finally, generate the report, verify it follows the report guide, and slack me the results and report URL.”

«Имея эти наборы эвалов, собери изолированные контейнеры для каждого набора и проверь, что каждый собирается. Затем выполни полный запуск, запиши метрики эвалов и транскрипты, используй субагентов для чтения транскриптов и подтверждения корректности прогона. Запусти каждый эвал n раз для доверительных интервалов. Наконец, сгенерируй отчёт, проверь, что он соответствует гайду по отчётам, и отправь мне в Slack результаты и URL отчёта.»

Run sessions in parallel and find the bottleneck. Delegating bigger tasks means we can run more at once. Claude says I typically run three to six sessions simultaneously. The bottleneck has shifted from doing the work to writing clear specs and reviewing outputs fast enough to keep the pipeline moving—the middle is hollowing out. If parallel sessions share a repo, use git worktrees so each session gets its own checkout and don’t overwrite each other’s changes.

Запускайте сессии параллельно и находите узкое место. Делегирование крупных задач означает, что можно запускать больше задач одновременно. Claude говорит, что я обычно веду от трёх до шести сессий параллельно. Узкое место сместилось от выполнения работы к написанию чётких спецификаций и достаточно быстрому ревью результатов, чтобы конвейер не простаивал — середина выхолащивается. Если параллельные сессии работают в одном репозитории, используйте git worktrees, чтобы каждая сессия получила свой checkout и не перезаписывала изменения других.

Make sessions easy to observe. When running multiple sessions, I need to know their state and which one needs attention. On my mac, a stop hook plays a sound when a session finishes (example below). My tmux window titles use a status emoji (⏳ working; 🟢 complete) and a short Haiku-generated label so I know what each pane is doing. The Claude Code status line shows context usage and the current mode. Together, the stop-hook sound signals a finished task, the tmux titles shows which one, and the status line provides the details.

Обеспечьте простоту наблюдения за сессиями. При запуске нескольких сессий мне нужно знать их состояние и какая из них требует внимания. На моём Mac stop-хук проигрывает звук при завершении сессии (пример ниже). Заголовки моих tmux-окон используют статусный эмодзи (⏳ в работе; 🟢 завершено) и короткую метку от Haiku, чтобы я знал, чем занята каждая панель. Строка статуса Claude Code показывает расход контекста и текущий режим. Всё вместе: звук stop-хука сигнализирует о завершении задачи, заголовок tmux показывает какой именно, а строка статуса даёт детали.

# Example stop hook alert "Stop": [ { "hooks": [ { "type": "command", "command": "if command -v afplay >/dev/null 2>&1; then afplay -v 1.0 /System/Library/Sounds/Glass.aiff; else tput bel; fi" } ] }

# Пример stop-хука alert "Stop": [ { "hooks": [ { "type": "command", "command": "if command -v afplay >/dev/null 2>&1; then afplay -v 1.0 /System/Library/Sounds/Glass.aiff; else tput bel; fi" } ] }

You can check in even if AFK. /remote-control in Claude Code makes this easy. While commuting or waiting in line, I open the code tab in the Claude app to see what’s running and what’s blocked, and if needed, unblock a stalled session with additional context or new instructions. This keeps sessions moving instead of sitting idle for hours. Only do this if there’s something urgent though, not when you’re trying to be present or touch grass.

Можно проверять прогресс, даже если вы не за компьютером. /remote-control в Claude Code делает это просто. По дороге на работу или в очереди я открываю вкладку кода в приложении Claude, чтобы увидеть, что запущено и что заблокировано, и при необходимости разблокировать застрявшую сессию дополнительным контекстом или новыми инструкциями. Это позволяет сессиям двигаться, а не простаивать часами. Но делайте это, только если есть что-то срочное — не когда стараетесь быть в моменте или вышли на прогулку.

Closing the loop

Замыкание цикла

Keep the context rich by working in the open. When we do our work in shared docs, repos, and channels, it makes it easier for everyone—including models—to retrieve and benefit from the context. What we share today becomes part of the org context tomorrow. Try this simple test: could a new teammate replicate your work from last week using only the shared context? If yes, you’re contributing well to the org context; if not, that precious context is stuck in your head. I automate this somewhat via instructions in my CLAUDE.md to post short updates in a worklog channel whenever I finish a substantial task, with links to the artifact PR or doc.

Поддерживайте богатство контекста, работая открыто. Когда мы ведём работу в общих документах, репозиториях и каналах, всем — включая модели — проще находить и извлекать пользу из контекста. То, чем мы делимся сегодня, завтра становится частью организационного контекста. Попробуйте простой тест: сможет ли новый коллега воспроизвести вашу работу за прошлую неделю, используя только общедоступный контекст? Если да — вы хорошо вносите вклад в контекст организации; если нет — ценный контекст застрял у вас в голове. Я частично автоматизирую это через инструкции в CLAUDE.md: публиковать короткие апдейты в канале рабочего журнала после завершения значительной задачи со ссылками на артефакт, PR или документ.

Mine your transcripts for config updates. Have the model read past session transcripts to find gaps. When I scanned ~2,500 of my past user turns, a sizable percentage contained phrases like “can you also…“, “did you check…“, “still wrong”, etc. These suggest that the model should have done something unprompted, and I should update the CLAUDE.md or skill, or that a verification step is missing or broken. Hit counts show how often a correction happens and the transcripts show exactly what failed. This is why I make corrections within the session, so I can use the transcript as input for my next CLAUDE.md or skills update.

Добывайте обновления конфигурации из транскриптов. Пусть модель читает транскрипты прошлых сессий и находит пробелы. Когда я проанализировал ~2 500 своих прошлых реплик, заметная доля содержала фразы вроде «а можешь ещё…», «ты проверил…», «всё ещё неправильно» и т. д. Это говорит о том, что модель должна была сделать что-то без подсказки, и мне нужно обновить CLAUDE.md или навык, либо что шаг верификации отсутствует или сломан. Счётчики показывают, как часто происходит та или иная коррекция, а транскрипты — что именно пошло не так. Вот почему я вношу исправления внутри сессии — чтобы использовать транскрипт как входные данные для следующего обновления CLAUDE.md или навыков.

Refactor and prune periodically. As configs grow, they can overlap or conflict with each other. As a result, if the model ignores a rule, it can be because another rule contradicts it. Fix this by refactoring periodically. Each rule or preference should live in exactly one place (though critical instructions can be repeated in the main CLAUDE.md). I also check for stray directory-level settings.json and consolidate them back into ~/.claude.

Периодически рефакторьте и чистите. По мере роста конфигурации правила могут пересекаться или противоречить друг другу. Если модель игнорирует правило, причиной может быть другое правило, которое ему противоречит. Решение — периодический рефакторинг. Каждое правило или предпочтение должно жить ровно в одном месте (хотя критически важные инструкции можно дублировать в основном CLAUDE.md). Также я проверяю наличие случайных settings.json на уровне каталогов и консолидирую их обратно в ~/.claude.

• • •

• • •

While the specific setup will likely change as models get better, I think the principles will remain relevant: provide good context, encode your taste, make verification cheap, delegate more, and close the loop. What we’re doing is training a collaborator, one feedback at a time. And if you think about it, these principles apply to how we work with a human team too.

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

To get started, have your model read this SETUP.txt and help you apply it. Also, I’d love to learn what practices or principles you’ve found valuable—please comment below or reach out!

Чтобы начать, дайте модели прочитать этот SETUP.txt и помочь вам применить его. А ещё мне было бы интересно узнать, какие практики или принципы оказались ценными для вас — пишите в комментариях или свяжитесь со мной!

p.s. This isn’t just about personal tooling. It’s also how you’d design agent harnesses, set team norms, and build org infrastructure. Try reading it again with those layers in mind.

P.S. Это не только про персональные инструменты. Это также применимо к проектированию агентных обвязок, установлению командных норм и построению организационной инфраструктуры. Попробуйте перечитать с учётом этих уровней.

If you found this useful, please cite this write-up as:

Если материал оказался полезен, пожалуйста, цитируйте его так:

Yan, Ziyou. (May 2026). How to Work and Compound with AI. eugeneyan.com. https://eugeneyan.com/writing/working-with-ai/.

Yan, Ziyou. (May 2026). How to Work and Compound with AI. eugeneyan.com. https://eugeneyan.com/writing/working-with-ai/.

or

или

@article{yan2026default, title = {How to Work and Compound with AI}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2026}, month = {May}, url = {https://eugeneyan.com/writing/working-with-ai/} }

@article{yan2026default, title = {How to Work and Compound with AI}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2026}, month = {May}, url = {https://eugeneyan.com/writing/working-with-ai/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.