Skip to content

Field Notes from Vibe Coding

I've been vibe coding recently. Along the way I've built a few small projects — a price tracker and a Rednote MCP — and used the building as an excuse to try out the tooling: Claude Code, skills, writing my own skills and agents, and both subagents and agent teams.

A few learnings.

Don't micromanage the agent

You can micromanage an agent, but it kneecaps its effectiveness. Describe the workflow and the rules, then let it operate inside them.

There's a name for the line you're walking. Anthropic's context-engineering writeup calls it the right altitude: system prompts should present ideas at the "right altitude for the agent," the Goldilocks zone between hardcoding "complex, brittle logic" and giving "vague, high-level guidance" (Effective context engineering, Anthropic). Dictating steps is the brittle-logic failure mode. It also fights the grain of what an agent is: Anthropic draws the line between workflows, "where LLMs and tools are orchestrated through predefined code paths," and agents, "where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks" (Building Effective AI Agents, Anthropic). Micromanaging is forcing a workflow onto something you chose to run as an agent.

Agent teams are usually overkill (for coding)

An agent team might be powerful, but it also burns something like 10x (?) the tokens — overkill for simple tasks, and I consider coding a simple task. I haven't measured that multiplier; treat it as a vibe, not a benchmark.

Subagents are already enough. You can spawn multiple IC agents to parallelize work, and you don't expect those ICs to talk to each other. That's the textbook subagent pattern: Anthropic describes specialized sub-agents that "handle focused tasks with clean context windows" and return "only a condensed, distilled summary of its work (often 1,000-2,000 tokens)" to a coordinator (Effective context engineering, Anthropic). Clean context in, distilled summary out, no N-to-N chatter. It also fits Anthropic's general advice to reach for "simple, composable patterns" before complex frameworks, and to remember that agentic systems "often trade latency and cost for better task performance" — so the extra spend has to earn its keep (Building Effective AI Agents, Anthropic).

The real case for an agent team is a scenario that benefits from multiple agents of different characteristics communicating freely, in an N-to-N pattern. But even the typical product-design-architect setup is overkill, because the participants are so limited that you can just codify the communication flow. Google's ADK arrives at the same place from the other direction: instead of free-form N-to-N chat, it reduces all multi-agent interaction to two fixed patterns — "Agents as Tools" and "Agent Transfer (Hierarchy)" — and scopes what each sub-agent sees by default. The reason they bother is the failure mode you avoid by codifying: pass full history down the chain and you trigger a "context explosion" (Architecting a context-aware multi-agent framework, Google). A fixed comms graph for a known, small cast beats an open team.

Complexity breeds regressions

The agent gets noticeably dumber as a project gets more complicated — regressions start piling up. My leading suspects are poor testing skill, low test coverage, and bloated context from a long session.

The bloat suspicion isn't just a feeling. Chroma's Context Rot study measured it: "even under these minimal conditions, model performance degrades as input length increases, often in surprising and non-uniform ways" (Context Rot, Chroma). LangChain frames the same effect at the harness level — Context Rot "describes how models become worse at reasoning and completing tasks as their context window fills up" (The Anatomy of an Agent Harness, LangChain). So a long, accreting session plausibly degrades the agent the same way a stuffed context window does.

The testing suspicion has a sharper shape than I'd guessed, too. LangChain's deep-agents eval work found that "Regressions often occur at individual decision points rather than across full execution sequences," and recommends single-step evaluation — interrupting the agent after a single tool call to inspect the output — to catch them early (Evaluating Deep Agents, LangChain). That turns my vague write-more-tests instinct into something concrete: unit-test the agent's decisions, not just its end-to-end runs.

Here's the part I keep turning over. My hunch is that a snapshot technique — compressing the context between phases — might be the real fix. I haven't tested this, and I want to engage the strongest objection to it, because it cuts against my instinct.

My intuition already has a name and a production form. Anthropic calls it compaction: "taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary," alongside structured note-taking (Effective context engineering, Anthropic). So far, so encouraging. But the same company's Managed Agents work pushes back hard on the lossy version: "irreversible decisions to selectively retain or discard context can lead to failures. It is difficult to know which tokens the future turns will need." Their fix is the opposite of compression — keep everything in a durable session log and slice it on demand via getEvents() (Scaling Managed Agents, Anthropic). That's the catch with my snapshot idea: the moment you compress, you've bet on what the future won't need, and you can't take it back.

What survives the objection is the version that doesn't actually compress. The Ralph Loop "reinjects the original prompt in a clean context window," but it "reads state from the previous iteration" off the filesystem (The Anatomy of an Agent Harness, LangChain). The context gets small again each phase, but nothing is discarded — the state lives durably on disk. So the refined claim is: snapshot to a durable external store and restart clean, rather than summarize-and-throw-away inline. Same instinct, minus the irreversible bet.

Files as memory — and its failure mode

I also want to try OpenClaw to iterate on my projects. The idea is straightforward: use files as long-term memory to improve the agent. OpenClaw is the clean version of this — the agent "updates its own configuration over time" through its SOUL.md, and runs an offline job over recent traces that OpenClaw calls "dreaming" to fold insights back into its files (Continual Learning for AI Agents, LangChain). The personality lives in files too: SOUL.md, AGENTS.md, and IDENTITY.md per agent (The Agency, msitarzewski).

But this potentially suffers from the same problem as the regression section — memory and personality pollution, the bloat-compress-shift cycle. Those personality files are exactly the surface that accumulates cruft. And the failure is worse than slow: it's quiet. memweave puts it plainly — "the stale-memory problem is silent. There is no error, no warning — just subtly outdated context fed to the model" (memweave, Towards Data Science). Their mitigation is a candidate fix for my cycle: temporal decay, weighting recent files over old ones so stale memory stops outranking fresh memory as the store grows. A file-as-memory system without something like that is a slow drift into confident wrongness.

Sandboxing an agent that holds your personal data

The other concern with OpenClaw is security, and the trade-off is brutal at both ends. Anthropic states it cleanly for Claude Code: a sandbox is "safe but high-maintenance," while --dangerously-skip-permissions is zero-maintenance and "unsafe in most situations" (Claude Code Auto mode, Anthropic). Loose permissions mean a security risk; tight permissions mean a useless agent. A lot of sandboxing solutions are built around OpenClaw, and my current thinking — a sketch, not a working system — is to break it into three agents split by data flow:

  • A filesystem agent. Sandboxed, with access to all personal data, but very strict on tool usage. It's the gatekeeper: it records and audits every file access and controls what leaves the sandbox.
  • A processing agent. No persistent storage — everything lives in temp storage and is destroyed when the agent goes idle. It's created on demand.
  • An outgoing-traffic agent. Similar to the filesystem agent, but focused on external traffic. It monitors and audits network activity and interactions with external filesystems, MCPs, and so on — making sure no unexpected data leaks out and no suspicious data is injected in.

I want to be clear this is a split nobody else in my reading makes, and I think that's a point in its favor rather than against it. The prior art splits the same problem along different axes:

  • By component lifecycle. Anthropic's Managed Agents separates brain, hands, and session, and gets credential isolation structurally: the "tokens are never reachable from the sandbox where Claude’s generated code runs," with credentials fetched through a dedicated proxy (Scaling Managed Agents, Anthropic). My filesystem-gatekeeper is chasing the same property — credentials and data unreachable except through an audited path — by role instead of by lifecycle.
  • By OS privilege tier. OpenAI's Codex-on-Windows sandbox runs the agent as a low-privilege user and uses "firewall rules that block all outbound network access for the CodexSandboxOffline user," reserving network for a separate online user (Codex on Windows sandbox, OpenAI). That's my outgoing-traffic agent, implemented as an OS user instead of a peer agent.
  • By defense layer. Claude Code's Auto mode slices it into an input prompt-injection probe and an output classifier that blocks actions which destroy or exfiltrate data or cross trust boundaries (Claude Code Auto mode, Anthropic). Those block rules are precisely my egress agent's job, done with a classifier instead of a dedicated agent.

Three teams converged on the same goals — credentials unreachable, egress controlled, blast radius small — and reached them along the axis that fit their system. Mine is the data-flow axis. Whether splitting by data flow actually beats splitting by lifecycle, privilege, or defense layer is the thing I'd have to build to find out.

Sources