This is a tech blog post from HackerNews that was introduced on GeekNews. I thought it would be helpful for those doing coding with vibe, so I got permission from the original author and uploaded the translation. The initial translation was done by Opus 4.7, and I refined it a bit.

Eugene Yan is currently a Member of Technical Staff at Anthropic, connecting the field with cutting-edge research. Previously, he was a Principal Applied Scientist at Amazon, building LLM/AI systems for Kindle book series summaries, translations, and Q&A, and led ML for Southeast Asian e-commerce at Alibaba/Lazada. He regularly writes about LLMs, recommendation systems, and engineering on his personal blog eugeneyan.com, and also manages applyingml.com and applied-llms.org.

Original: How to Work and Compound with AI by Eugene Yan (May 3, 2026) Translation: By a passerby, blog.d9ng.co.kr - Translated with the author's permission.

How can you work effectively with AI? What is a workflow, how do you scale it, and how do you improve your system over time? And ideally, work should compound. All completed artifacts—code, documents, analyses, decisions—should become context for the next session, and every modification should be reflected in configurations that reduce future errors. I'm still learning myself, but since I repeat the same answers so often, I'm organizing them here so I can answer with a single link the next time someone asks.

If you use AI frequently, you're probably already applying many of these approaches. Still, I think these foundational principles apply broadly. It's about providing good context, encoding your taste as configuration, making verification easy, delegating larger tasks, and closing the loop. If an approach doesn't work for you, take the principles and adapt them to your own style. And as you read, you'll realize this isn't just about AI. It's simply how you guide a new collaborator as you work with them.

• • •

Context is infrastructure (Context as infrastructure)

Help the model navigate your context well. For example, all my code is in ~/src, and all my knowledge work is in ~/vault (organized into projects/, notes/, kb/, etc.). When work is well-organized, the model can easily find context with grep or glob. A clean directory tree is easy to navigate, and it's intuitive to find and reuse previous code, project documents, and analyses for current work.

Connect the model to your organization's context. Models can leverage knowledge within the organization, but that knowledge is usually scattered across Slack, Drive, Mail, and similar places. Most have MCP set up for Claude Code, Cowork, and Claude.ai. On top of that, I maintain a separate INDEX.md for each project. It's an index of relevant documents and channels with annotations, with each item containing a URL, owner, and a short paragraph explaining what's inside and when to look at it. These annotations help tremendously. If only URLs are listed, the model has to open every link each time to check what's relevant, wasting time and context. By annotating in advance, you do this heavy lifting once and save it in the index.

Start each new session as if onboarding a new employee. Each time a new session starts, the model begins with no information. So it's helpful to treat project-specific CLAUDE.md files like onboarding documents a new team member receives on their first day. When I had Claude review my project CLAUDE.md files, it pointed out they contained things like abbreviation glossaries, project code names, and distinctions between same-named team members. I also add recommended reading order to CLAUDE.md. I tell the model to first review INDEX.md, then TODOS.md, and finally specific topic notes.

Create a memory layer. By default, models don't remember what happened in previous sessions. So anything worth preserving should be written to disk. I split my memory layer two ways. In ~/vault, I keep facts like project state, artifacts, and domain knowledge, and in ~/.claude (along with CLAUDE.md, skills/, guides/) I keep my preferences, workflows, and personal taste. The former provides context, the latter provides configuration.

Taste is configuration (Taste as configuration)

Start with ~/.claude/CLAUDE.md. Claude reads this file at the start of every session. I think of it as a convention that specifies how to behave. My CLAUDE.md contains preferences like how direct to be, when to push back, how to handle mistakes, and what to teach me. Here's a simplified version:

- Be direct, and push back if you disagree. If there's a problem with my approach, say so.
- If you're unsure about something, don't guess confidently—say you don't know.
- If something fails, investigate the root cause before retrying.
- Keep diffs scoped to the task. Don't fix formatting or refactor unrelated code in passing.
...



I'm always learning new systems and domains. When key terms I'm likely unfamiliar with come up,
explain them in 1-2 sentences and move on. Format:

> 💡 1-2 sentence explanation

...

Set scope by directory. Global, then repo, then project. Place preferences that apply anywhere (e.g., behavior, long-term goals, teaching) in ~/.claude/CLAUDE.md. Place conventions specific to a repo (e.g., linting, naming, PR) at the repo root. Place project-specific context (e.g., directory structure, domain knowledge) in the project directory. When you start Claude Code in a subdirectory, it loads each CLAUDE.md as it walks up the tree. If the model enters a subdirectory during a session, it also loads that directory's CLAUDE.md. Check the official documentation for details.

Split up CLAUDE.md if it gets too long. Long CLAUDE.md can become a context tax. Unnecessary content gets loaded every session. The solution is to extract some chunks as guides so they load lazily. Don't use @import (it just inlines). Instead, let CLAUDE.md tell you to read when relevant. This way, sessions building evals skip the writing guide. Example guides section:

- Documentation, one-pagers, all writing: ~/.claude/guides/writing.md
- Building and reporting evals: ~/.claude/guides/evals.md
- Dashboards: ~/.claude/guides/dashboards.md
...

Turn tasks that repeat weekly or more into skills. Skills are markdown files containing a name, trigger, and procedure that load when the model needs them. Think of skills as workflows written in markdown. They can include logic too. For example, my /polish skill looks at the output diff. If it produces metrics, run the relevant eval; if it renders in a browser, check the output with Claude in Chrome; otherwise run the code and read the output or errors. Skills encode each step and the judgment of when each step applies. A few examples:

• /polish: Check for bugs, simplify code, validate output (via evals, Claude in Chrome, etc.), iterate until no critical feedback, draft PR
• /write: Interview for outline, spawn research subagents, draft, get feedback from adversarial critic, iterate until no critical feedback
• /daily: Read calendar, Slack, PRs, yesterday's logs, write today's priorities

I keep SKILL.md short and focused on workflows and routing. I keep knowledge (templates, scripts, etc.) in separate files that load and run only when needed. Same principle as lazy-loaded guides.

Do a task once yourself, then ask the model to turn it into a skill. I create most skills this way. First, I do the task once in a regular session. Then I ask the model to turn what I just did into a skill. The next time I have the same or similar task, I run that skill. The output will definitely need fixes, which I fix in the same session. This way, feedback is recorded in the session transcript. Finally, I ask the model to update the skill based on those fixes and feedback. You can also seed skills with examples of desired output. Just ask the model to extract the pattern. For example, how code is organized, document structure and tone, etc.

Don't edit skills by directly modifying the file; refine them through the transcript. The first version of a skill is normally tailored to just the original session and won't work well. When you run it and need to fix the output, do that fixing in the session. Don't open and edit SKILL.md directly. When you give feedback in the session, the model gets before/after pairs that accumulate in the transcript. A record builds up of what we did, what I wanted, and why. Once the output is correct, ask the model to merge the feedback into the skill. After a few rounds, the skill converges and the final output needs little touching up.

But not every task needs this much context. For brainstorming, exploration, and rough draft work, I often use simple mode (CLAUDE_CODE_SIMPLE=1 claude). Here, CLAUDE.md still loads but the agentic harness (hooks, skills, tool-first loop) doesn't run. This gets closer to the model, and that's exactly what I want when thinking out loud, not shipping.

Verification for autonomy (Verification for autonomy)

Shift verification left. Catch errors at write time. I think of verification as a ladder. The bottom rung is cheap and deterministic; the top is expensive and requires judgment. I want to catch problems at the lowest rung possible. Lower on the ladder are things like post-edit hooks that run ruff format, ruff check --fix on files the model just updated. They work deterministically and don't consume tokens. Higher up the ladder are tests, evals, and LLM reviews.

Make it easy for the model to verify its own work. Give the model a feedback loop to improve its output. If the system produces metrics, have the model run evals to optimize. If output renders in a browser, have it check with Claude in Chrome. Otherwise, just have it run and read the errors. For example, when building a Docker image, I let the model build, read errors, fix the Dockerfile, and rebuild. When tuning the harness, the model runs evals, reads the transcript, and fixes failures. When building dashboards, the model checks in Chrome that tooltips render, labels don't overlap, and the narrative matches the numbers.

For long-running work, let the model watch the model. Long sessions can drift as errors accumulate. One solution is to spawn a secondary session that reads the original spec and recent turns from the main session as new context. My minimal setup uses two tmux panels. One for primary development, the other for a pair programmer. Initial instructions and follow-up prompts are added to a shared file. Periodically, the pair programmer is activated to compare the main session's recent transcript against the spec, and if anything is misaligned, it provides corrective feedback.

There are several approaches. For example, the pair programmer can watch for execution drift. Is the model doing the work correctly? This is local and tactical—cases where the model ignores errors, reports wrong metrics, or deviates from the spec. And there's direction drift too. Is the model doing the right work? This is the bigger picture, strategic—when the model misinterprets the original intent and spends hours building the wrong thing. Check for execution drift often, direction drift occasionally.

Scaling via delegation

Delegate increasingly larger units of work. Sometimes I pair-program with the model. Short tasks, fast feedback, staying in the loop. It works well for rapid iteration, exploratory analysis, and prototyping. But as the model gets stronger, we should aim to delegate larger tasks. Explain the intent, constraints, and success criteria up front, then let the model work. You can't delegate what you can't verify, so define success criteria and metrics first. The shift is from giving one instruction at a time to crafting a plan and having the model execute it through to completion:

"Given these eval suites, create isolated containers per suite and run a smoke test on each to see if they build. Then run a full pass, log the eval metrics and transcript, and have a subagent read the transcript to confirm the eval ran correctly. Run each eval n times to extract confidence intervals. Finally, generate a report, validate that it followed the report guidelines, and send the results and report URL to Slack."

Run sessions in parallel and find the bottleneck. When you delegate larger tasks, you can run more things concurrently. According to Claude, I usually run 3–6 sessions concurrently. The bottleneck has shifted from doing work to writing clear specs and rapidly reviewing output to keep the pipeline moving. The middle steps are disappearing. If parallel sessions share the same repo, use git worktree so each session has its own checkout and they don't overwrite each other.

Make sessions easy to observe. When running multiple sessions, you need to know the state of each and which ones need attention. On my Mac, when a session ends, a stop hook plays a sound (see example below). tmux window titles include a status emoji (⏳ working, 🟢 complete) and a short label generated by Haiku so you can see what each panel is doing. Claude Code's status line shows context usage and the current mode. Together, the stop hook sound signals work is done, the tmux title tells you which task, and the status line gives details.

# Stop hook alarm example
"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 when away. Claude Code's /remote-control makes this easy. During your commute or while waiting in line, open the code tab in Claude and check what's running and what's stuck, then unblock stalled sessions with additional context or new instructions if needed. This way sessions keep moving instead of sitting idle for hours. But only do this when it's really urgent. Not when you're trying to stay present or need a break outdoors.

Closing the loop

Work in an open environment to keep context rich. When work happens in shared docs, repos, and channels, everyone—including the model—can easily use the context. What you share today becomes tomorrow's organizational context. Try a simple test. Can a new teammate reproduce what you did last week using only the shared context? If yes, you're contributing well to organizational context. If not, that valuable context is trapped in your head. I automate some of this with instructions in CLAUDE.md. Whenever meaningful work completes, I post a short update to the worklog channel with links to the output PR or docs.

Mine transcripts to update your settings. Ask the model to read past session transcripts and find gaps. When I scanned about 2,500 past user turns, a significant fraction contained phrases like "Could you also…?", "Did you check…?", "That's still wrong." These phrases signal work the model should have done without asking—meaning I need to update CLAUDE.md or a skill, or a validation step is missing or broken. Frequency shows how often corrections happen, and transcripts show exactly what failed. So I make the fix in-session. That way I can use the transcript as input to the next CLAUDE.md or skill update.

Refactor and prune periodically. As configuration grows, rules can overlap or conflict. If the model ignores a rule, another rule might contradict it. Refactor periodically to fix this. Each rule or preference should live in exactly one place (important instructions can be repeated in main CLAUDE.md). Also check for scattered settings.json files across directories and consolidate them under ~/.claude.

• • •

The specific setup will certainly change as models improve, but I think the principles will still hold. Provide good context, encode your preferences, make validation cheap, delegate more, and close the loop. What we're doing is training a collaborator, one piece of feedback at a time. When you think about it, these principles apply equally to working with human teams.

To get started, ask the model to read and apply this SETUP.txt. And if you have any practices or principles that you find useful, please leave a comment or contact me.

p.s. This is not just about personal tools. It also applies to how to design agent harnesses, establish team norms, and build organizational infrastructure. Read it one more time on that layer.

If the original text was helpful, please cite it as follows:

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/}
}

This is a Korean translation of Eugene Yan's How to Work and Compound with AI (May 3, 2026). It is published on blog.d9ng.co.kr and Damoang with the author's permission. Copyright belongs to the author.