Karpathy coined vibe coding in Feb 2025: describe it, accept what the model returns. A year later he called that era over. The professional default now is agentic engineering: you write a spec, an agent builds against it, you review the output, not every keystroke.
One prompt, accept the result. Great for throwaway prototypes. Falls apart at production scale.
Spec is the source of truth. Agent plans, edits, runs tests, loops on failure. You are the reviewer.
Thinking, requirements, review criteria. The skill shifts from typing to specifying and judging.
The agent that writes your code and the agent inside the product you ship are the same architecture: a model wrapped in a harness, steered by its instructions. Learn it once, point at it twice.
Colour = role. Teal is the instructions you write, amber is the harness mechanics, violet is the model.
The model is the intelligence. The harness is everything that is not the model: the loop, the tools, context management, memory, guardrails. Anthropic describes the loop itself as "dumb", all the smarts live in the model. Two analogies that land:
Model = CPU. Context window = RAM. Harness = the OS. The agent = the application. Run without an OS and you rebuild scheduling, memory and I/O yourself.
A smart hire with a vague brief and no oversight underdelivers. Give them a clear task, the right tools, success criteria and a review process, and they perform.
Why bother? Ask an agent to fix a failing test. Without a harness it writes a plausible fix but cannot run the tests, read the real error, or confirm it passes. The harness closes that loop, and that is the whole game.
Agents add latency, cost and non-determinism. Reach for the simplest thing that works. Anthropic's guidance: start with workflows, add agency only when the task genuinely needs it.
Predefined code paths. You decide the steps; the model fills the blanks. Patterns: chaining, routing, parallelization, evaluator-optimizer. Predictable, cheap, testable.
The model directs itself. It chooses tools and steps to reach a goal. Right for open-ended work where the path isn't known upfront.
Both read your repo, edit files, run commands and loop until done. They differ in who owns the model and how open the harness is. Tap to compare.
Anthropic's agent, model co-trained with its harness. Most polished, fastest to productive. Runs in terminal, VS Code, JetBrains, desktop, web and iOS.
Your daily driver on Claude. Deep IDE workflows, headless automation in CI, the richest extension surface (skills, subagents, hooks, MCP, plugins).
Open-source, model-agnostic agent (Go TUI + JS server). 75+ providers, switch mid-session, run fully local via Ollama. MIT-licensed, 160k+ GitHub stars.
Non-Claude or local models, private/regulated code that can't leave your machine, cost control, and reading an open harness to learn how one works.
Open-source and model-agnostic. It runs Claude via your own Anthropic API key, plus 75+ providers and local models. What broke in 2026: routing a Claude Pro/Max subscription through it (Anthropic blocked third-party subscription auth). API-key billing is the supported path.
75+, switchable mid-session. GPT, Gemini, Claude (API key), and more.
Ollama / LM Studio. Code never leaves the box, zero per-token cost.
AGENTS.md (preferred when present), the cross-tool instruction file.
Subagent-style agents, Plan and Build modes via Tab.
Per-tool allow / ask / deny, so the agent can't act without your say-so.
Custom slash commands and skills, the same composition idea as Claude Code.
Clean division: Claude Code is where your Claude subscription works and the harness is co-tuned. OpenCode is multi-provider, local, and bring-your-own-key. src opencode.ai/docs
# recommended: native install, auto-updates itself
curl -fsSL https://claude.ai/install.sh | bash # mac / Linux / WSL
# Windows: irm https://claude.ai/install.ps1 | iex · winget install Anthropic.ClaudeCode
# start in your project, auth in browser (Pro / Max / Team / Enterprise)
cd your-project
claude
# sanity check
claude doctornpm i -g @anthropic-ai/claude-code still works (needs Node 18+). claude -p "..." runs headless in CI. Also via Bedrock, Vertex, Foundry.
# one-line install
curl -fsSL https://opencode.ai/install | bash
# launch in your project
cd your-project
opencode
# pick a provider / model
/model openai gpt-5.4
/model ollama llama3 # fully localTab toggles Plan and Build modes. /init writes an AGENTS.md for the repo.
The highest-leverage habit. A short markdown file, loaded every session, carrying your stack, conventions and non-negotiables. Commit it so the team shares one context.
# CLAUDE.md — Claude Code reads this, not AGENTS.md
@AGENTS.md # bridge an existing cross-tool file
## Rules
- Write tests before saying done.
- Never edit /legacy. Never commit secrets.
## Commands
- test: pnpm test · build: pnpm buildCLAUDE.md, not AGENTS.md. If your repo already has an AGENTS.md (OpenCode, Codex), bridge it: put @AGENTS.md at the top, then add Claude-only notes. OpenCode prefers AGENTS.md..claude/rules/, long playbooks in skills./memory.Used as fancy autocomplete, it's a Tesla you only use for the radio. These layers turn it into a coworker that knows your project.
Standing instructions you write, plus auto memory Claude keeps itself.
e.g. your stack, the test command, and @AGENTS.md so every tool reads one file.
Reusable workflows in .claude/skills/<name>/SKILL.md, invoked on demand.
e.g. Anthropic's docx / pptx / pdf skills that output real Office files.
A helper in fresh context that returns only a summary. Saves your main context.
e.g. a test-runner or code-reviewer subagent, so verbose output never fills your thread.
Scripts on events. They run code, so they can't hallucinate. The real rule layer.
e.g. a PreToolUse hook that runs your formatter, or trims test output to failures.
MCP lets the agent act; skills are knowledge, MCP is action. Plugins bundle skills, subagents, hooks and MCP into one installable unit.
MCP e.g. Context7 (live docs), Playwright (a browser), GitHub / Sentry (issues, errors). Plugin e.g. Superpowers (obra), a whole TDD-and-planning workflow as auto-triggering skills + hooks.
LSP plugins give precise symbol navigation and type errors after edits. Agent teams (experimental, opt-in) spawn multiple Claude instances to parallelize.
e.g. a TypeScript or Python LSP plugin for go-to-definition; an agent team to split a big refactor.
Context is a finite resource. Good context engineering finds the smallest set of high-signal tokens that get the outcome you want. Three rules practitioners agree on:
This is exactly Layer B work too: the system prompt for your product agent follows the same discipline.
Every exchange has two layers. The system prompt is the standing brief, set once and applied on every turn. The user prompt is the specific task for this turn. Think job description versus today's work order.
Role, standing rules, conventions. In a raw API call it's the system parameter. In Claude Code the closest thing is your CLAUDE.md, loaded every turn as context (technically a user message, not the literal system prompt); --append-system-prompt is the true lever. It shapes behaviour, it doesn't enforce, that's hooks.
The actual request you type right now. Specific, scoped, with a definition of done. It changes every message; the standing instructions do not.
# SYSTEM PROMPT — set once, applies to every turn
You are a senior TypeScript engineer on our Next.js app.
Write tests first. Never edit /legacy. Use <Card> from src/ui.
If unsure, ask one question.
# USER PROMPT — the task for this turn
Add a CSV export button to the reports page.Rule of thumb: durable rules go in the standing layer (don't restate them every message), the specific ask goes in the user turn (don't bury it under rules). CLAUDE.md guides, it doesn't enforce, use a hook for that. In your products (Layer B) you write the real system prompt; your end user writes the user prompt.
The agentic loop in practice. You stay the orchestrator and reviewer; the agent does the typing.
Use Plan mode. The agent proposes an approach before touching code. You correct the plan, not 200 lines of wrong code.
Approve, and it scaffolds, edits, and runs tests, looping on failures until green.
A code-reviewer subagent gives a second pass with fresh eyes. A hook blocks anything risky.
You review the diff, not every keystroke. claude -p runs the same review in CI on every PR.
Claude watches the PR a prior session opened and shepherds it to green in CI on its own, so the person who owns the PR never sees a red X. That's the loop, fully automated.
Don't hand-build it: the Superpowers plugin (obra) wires this whole loop, brainstorm → plan → TDD → review, as skills that trigger automatically.
By default the agent codes blind: it writes UI changes it can't see. The Playwright MCP server (Microsoft's official @playwright/mcp) hands it a real browser, so it can open your running app, click, type, read the page, and screenshot to verify its own work. It closes the build → see → fix loop.
# give Claude Code a browser
claude mcp add playwright npx @playwright/mcp@latest
# confirm the tools loaded
/mcp # browser_navigate, browser_click, browser_take_screenshot ...
# then just ask, in plain language:
"Open localhost:3000, add two todos, screenshot the list,
and confirm both render and the input clears.""Verify my latest changes" and it navigates, interacts, screenshots, and reports what it actually sees.
Say "the form looks too narrow" and it sees the same form you do. UI quality jumps.
It can emit Playwright specs grounded in the live DOM, runnable on every PR in CI.
Playwright drives the browser (click, type, screenshot). To debug rather than click, add Google's Chrome DevTools MCP for the console, network and performance traces.
Two surfaces. Claude Design for visual exploration and your design system; Claude Code for production frontend wired to the real backend. Prove the look in Design, then build in Code against your actual component library. The shift that matters: design in Claude Code, iterating in conversation, instead of throwing it a finished mockup.
Paste a mockup or screenshot and say "match this". A picture removes the ambiguity a paragraph of description leaves behind.
It builds, then Playwright MCP screenshots the running app and compares to the target, looping until they line up.
"Make the chat white, move the grey onto the messages." Each turn is real, committable code, not a throwaway mock.
# point at a target, name the system, define done
"Rebuild the dashboard header to match header-mock.png (attached).
Use our <Card> and <Button> from src/ui, do not invent new ones.
Keep our spacing tokens. Then run the app, screenshot it with
Playwright, and compare to the mock until they match."Beat the generic AI look: give Claude your design system (brand assets, screenshots, or the existing component library) and name components so they don't drift, e.g. point it at a real library like shadcn/ui instead of letting it invent one. Reuse the mockup's vocabulary ("glass cards", "gradient text") as class names. Figma's Dev Mode MCP round-trips between your design source of truth and code. ref Claude Code best practices
| Problem | Reach for | How |
|---|---|---|
| Understand an unfamiliar codebase | Claude Code | Run claude, ask "explain how auth works", @-mention files. |
| Ship a feature from a ticket | Plan → Build | Plan mode to outline, approve, build, let it run the tests. |
| "Never commit secrets / always test" | Hook | A PreToolUse hook that blocks the action. Deterministic. |
| Review every PR consistently | Subagent + CI | A code-reviewer subagent, plus claude -p headless in CI. |
| Repeat a workflow (release notes, deploy) | Skill | Write it once in SKILL.md, invoke as /release. |
| Act on Jira / DB / Slack | MCP | Wire the MCP server; the agent calls the real tools. |
| Work on sensitive, private code | OpenCode + Ollama | Local model; code never leaves the machine. |
| Cut model cost / avoid lock-in | OpenCode | Switch GPT / Gemini / local per task, mid-session. |
Say you want an internal "room cost estimator" web tool. Spec-first beats vibing every time.
What it does, the inputs/outputs, and 3 acceptance criteria. This is the source of truth.
Stack, conventions, "write tests first", commands. Commit it.
Let the agent propose the structure. Fix the plan before any code is written.
It scaffolds, implements, runs the tests, and loops until they pass.
A hook blocks risky commands; Playwright MCP lets it screenshot the UI and confirm it matches the spec.
You read the output, not every keystroke. To change behaviour, refine the spec, not the code.
Treat the agent like a sharp new hire with zero context. Golden rule: if a colleague would be confused by your prompt, so is the model. Be specific, hand it the context, and say what "done" looks like.
"What would you improve in this file? @src/auth/session.ts"
Why: for fresh eyes, a loose prompt lets it surface issues you didn't know to ask about. Not every prompt has to be specific.
"Add CSV export to the reports page. Plan first, no code yet. Done = an Export button that downloads the filtered rows, plus a passing test."
Why: names the goal, forces a plan, and defines verification, so you don't get plausible-but-unchecked code.
"[screenshot] The list double-renders on refresh. Repro: open /items, reload. Find the cause, then fix."
Why: an image plus an exact repro kills the guesswork. "Cause, then fix" stops it patching the symptom.
"Always use our date util, never raw Date(), because timezones broke us in prod. @src/lib/date.ts"
Why: a rule with a reason generalizes. The model applies the spirit, not just the letter.
Also: reference files with @, paste screenshots, give doc URLs, pipe data (cat error.log | claude), and use Plan mode for anything non-trivial. One good example beats five adjectives.
Most disappointing output traces to the prompt, not the model. Five traps and the counter-move for each.
| Vague / broken | Why it fails | Better |
|---|---|---|
| "Make the app better." | No scope, no definition of done. You get generic churn. | "Fix the checkout page on mobile: the total overflows and the tap targets are tiny. Done = no horizontal scroll at 375px." |
| "Build a dashboard with auth, billing, settings and dark mode." | Too big for one pass. Context fills, concerns tangle, quality drops. | "Plan the dashboard. We build one page per session, starting with the layout shell." |
| "Fix the bug." | No repro, so it guesses, you correct, repeat. Slow and wrong. | Paste the error + screenshot + exact steps to reproduce, then "find the cause, then fix." |
| One blob mixing context, rules and format. | It can't tell rules from prose, so it follows them unreliably. | Structure it: Goal / Constraints / Output, plus "if unsure, ask one question." |
| "Don't break anything." | A negative with no check. It can't verify "anything". | "Keep the existing tests green and add one for the new path." |
For anything non-trivial, fill this shape. It forces the two things vague prompts skip: context and a way to verify. Same idea works for Claude Code and OpenCode.
Goal: what success looks like
Context: @file refs, the pattern to follow
Constraints: what NOT to change or add
Verification: the test that proves it works
Permission: what it may touch / must not
Output: format, or "open a PR"
Plan first, wait for approval before editing.
Ask one question if a missing detail changes the build.Add CSV export to the reports page.
Context:
- filter state: @src/reports/useFilters.ts
- button pattern: @src/ui/Button.tsx
Constraints:
- no new CSV lib unless native is insufficient
- preserve current table behaviour
Verification:
- add/update one test for filtered export
- run pnpm test for the reports package
- downloaded rows == visible filtered rows
Plan first. Don't edit until I approve.Agentic engineering produces software people rely on, which means the boring disciplines matter more, not less.
Define verification criteria up front. "Did the tests pass" beats "looks done". Without it, later runs declare false victory.
Hooks for the non-negotiables. Human-in-the-loop interrupts for anything that sends, deletes, or spends.
Every tool call passes through the harness, so log and trace there. You cannot fix what you cannot see.
/usage breaks spend down by skill, subagent and MCP server; set workspace spend limits and watch Console reporting. Budget ~$13/dev/active day on average. Agent teams (multiple Claude instances) can hit ~7× tokens in plan mode, so keep teams small.
Block reads of secrets. For sensitive code, local model via OpenCode so nothing leaves the box. (See the lethal trifecta, next.)
For work spanning sessions, use an initializer + progress file so the next run knows what's done.
The moment an agent can read private data, ingest untrusted content, and communicate externally, you've built a data-exfiltration path. Simon Willison's framing: an agent with all three is exploitable via prompt injection regardless of how aligned the model is, because the attack just needs the model to follow instructions. MCP plus a browser tool make it easy to assemble all three by accident.
Reads your repo, database, emails, file system, the things that shouldn't go public.
A web page via Playwright, an email, a PR description, an issue, a shared doc. Any of it can carry hidden instructions.
An HTTP request, an image URL, a generated link, an API call. Almost any outbound action can leak data.
read Willison · the lethal trifecta · MCP security best practices
Agents fail in recognizable ways. Name them so the team catches them early instead of shipping them.
Quality drops as the window fills (the "dumb zone" past ~40%). Fix: compact, scope subagents, start fresh.
Retries the same failing action forever. Fix: cap iterations, add a stop condition.
Declares done without verifying. Fix: demand a passing test, not "looks done".
Untrusted content takes over the agent. Fix: break the trifecta, see prior slide.
The fix for most of these is the same discipline: tight context, real verification, and system-level guardrails.
/usage and Console reporting, set workspace spend limits, and keep agent teams small (they're the ~7x case).| You want to... | Use |
|---|---|
| Make a rule the agent always obeys | CLAUDE.md / AGENTS.md |
| Reuse a multi-step workflow | a Skill (/command) |
| Do heavy research without polluting context | a Subagent |
| Enforce something deterministically | a Hook |
| Let the agent touch external systems | an MCP server |
| Let the agent see and verify a UI | Playwright MCP |
| Run a model that isn't Claude, or stay local | OpenCode |
| Decide agent vs workflow | workflow unless the path is genuinely unknown |
Remember: agent = model + harness. Skills are knowledge, MCP is action, hooks are guarantees, subagents are clean context.
Pi (by Mario Zechner) is a minimal, hackable terminal coding harness. The pitch: adapt the tool to your workflow, not the reverse. It's the clearest living example of agent = model + harness, because the whole product is a small harness you can read and reshape.
A tiny core, four tools (read, write, edit, bash) plus a slim TUI. Everything else (sub-agents, plan mode, permissions, MCP, context rules) is composed as TypeScript extensions, skills and prompt templates, bundled into shareable "Pi packages" via npm or git.
Provider-agnostic and bring-your-own-key across 15+ providers. It was the harness under OpenClaw and now shows up alongside OpenCode in the OpenAI / Codex ecosystem. Reach for it when you want to own and shape your agent's behaviour.
ref pi.dev · npm i -g @mariozechner/pi-coding-agent
Claude Code, OpenCode and Pi are session-based coding harnesses you drive. Hermes (Nous Research, open-source, MIT) is a different animal: a self-hosted, always-on, self-improving agent that lives on your own infrastructure.
Long-running ops or personal agents, private/local deployments, or as a memory and RL-trajectory platform. Not your daily code-shipping driver, that stays Claude Code or OpenCode. ref hermes-agent.org
The highest-signal talks, from Anthropic, the researchers who named these patterns, and the OpenCode team itself.
Horthy's two rules to take away: don't use prompts for control flow, and your agents are software, treat them as such.
Spec first. Plan before build. Systems over prompts. Review the output, not the keystrokes.
Pick one real workflow, write the spec, let the agent loop, and review the output like a product owner.
Agentic engineering deck · 2600th.com