This is an early draft. I am collecting notes as I go and will expand it with concrete examples, configs and screenshots later. For now it is a map of the terrain.

The way we work with coding agents has evolved fast, and the layers keep stacking. What began as typing a clever instruction into a box has turned into building external systems that manage the agent from the outside, and increasingly systems that let the agent manage itself. Here is the progression as I understand it, and the tooling I lean on.

The scaffolding stack

1. Vibe coding

The starting point: describe what you want in natural language and accept whatever comes out, steering by feel rather than by spec. Great for throwaway prototypes and getting unstuck. It falls apart the moment correctness, structure or maintenance matter, because there is no ground truth the agent is held to.

2. Prompt engineering

The foundational layer: you implicitly tell the agent what to do inside its context window. Perfect for self-contained reasoning, like a math question or a single well-scoped function. The whole task fits in one context, so a sharp prompt is enough.

3. Context engineering

When a prompt needs outside data, you give the agent autonomy to fill its own context: web search, reading files, querying MCP databases and tools. Powerful, but it starts to break on tasks longer than roughly ten minutes, because continuous context summarization gets leaky and quietly drops details that mattered.

4. Harness engineering

To beat the context limit, a harness manages the agent's context from the outside in. It decomposes a messy user requirement into a stable task list and has the agent iterate through it, so progress survives even when the raw conversation would have overflowed. This is what lets an agent clone a large, complex site without choking halfway. Claude Code is one such harness; there are others, each with different opinions about how much they hold versus how much they let the model roam.

5. Loop engineering

If a harness is a loop that iterates through tasks to finish one operation, loop engineering stacks another loop on top and removes the human from the driver's seat. It targets the human interaction layer: instead of a person prompting the agent, the scaffolding lets the agent prompt itself. Build a World Cup tracker with a harness; maintain it with a loop that schedules hourly score checks, triages user-reported bugs and ships fixes on its own.

Addy Osmani's framework (via the video below) names six components that make this real:

  • AutomationScheduled tasks and self-directed discovery.
  • WorktreesIsolated parallel environments so agents fix multiple things without contaminating each other's runtime.
  • SkillsCodified project knowledge the agent carries with it.
  • Plugins / connectorsIntegrations to external tools and knowledge bases.
  • Sub-agentsSpecialized agents spawned to ideate, verify or review.
  • StateTracking what is done and what still needs attention.

Loop engineering does not replace prompt, context or harness engineering. It builds on top of them and expands what an autonomous agent can manage over long stretches of time.

The tooling I use

The harness: Claude Code and friends

My daily driver is Claude Code, running in the terminal, but the same ideas port to other harnesses (IDE agents, web agents, CLI agents). What matters is that the harness owns task state, tool permissions and the edit loop, so the model can stay focused on one step at a time.

Hooks

Hooks are where the harness stops being generic and starts enforcing my rules. They fire on events (session start, before/after a tool call, on stop) and can inject context, block an action, or run a check. I use them for things like reminding the agent of house style, running a linter after edits, or gating risky commands. They are the difference between an agent that suggests and an agent that reliably follows a process.

Markdown files as search

Plain .md files double as a cheap, greppable knowledge base. A CLAUDE.md at the repo root carries standing instructions; a small memory index (one line per fact, pointing to a file) lets the agent recall project decisions across sessions without re-reading everything. Markdown is the substrate: human-readable, diffable, and trivially searchable by the agent.

Reading PDFs (use OCR, not raw text)

Handing a whole PDF to an agent burns an absurd number of tokens, and raw text extraction is usually garbled: multi-column layouts scramble, tables collapse, figures turn to noise, and scanned pages yield nothing useful at all. A vision OCR model is both cheaper and more faithful. It turns each page into clean markdown the agent can actually search, instead of dumping tens of thousands of noisy tokens into the context window.

This pairs directly with the markdown-as-search idea above: OCR the PDF once into markdown, then let the agent grep that. Two tools I am watching:

Skills

Skills are codified, reusable procedures the agent can invoke on demand instead of improvising. A few ecosystems I pull from:

  • superpowersA library of process skills (brainstorming, TDD, systematic debugging, writing plans, code review) that override default behavior with disciplined workflows.
  • caveman / cavecrewUltra-compressed communication and delegation skills that cut token usage while keeping technical substance, plus subagents whose output is compressed so the main context lasts longer.
  • claude-memPersistent cross-session memory: it captures observations as you work and injects the relevant ones back later, so the agent remembers past sessions.

Add worktrees for isolation and sub-agents for fan-out, and you have most of the loop-engineering components sitting right inside the harness.

Sources & further watching

Draft, to be expanded. Expect concrete configs, hook examples and a real loop I run on this site in a future update.