Slow Down, Human

AI coding is addictive. Velocity is a drug. The fix isn’t faster prompts — it’s better ones.

I ran /insights on my Claude Code usage last week. 122 sessions, 1,282 hours, 541 commits in a month. The report was fascinating. But the part that stuck wasn't a number — it was the interaction style analysis.

It described my pattern as "delegation with high expectations — assign complex goals and expect end-to-end execution, intervene sharply when things go wrong."

That's accurate. And it made me think about something I hadn't examined: how I work with AI matters more than how much I work with AI. And right now, most of us — myself included — are doing it wrong.

The Addiction

Let's start with the uncomfortable part.

AI coding is addictive. Seeing a complex function appear in seconds triggers the brain's reward system. A feature that would take a day materializes in minutes. You feel productive. You feel powerful. You want more.

So you move faster. Your prompts get shorter. Your specifications get vaguer. You stop reading the output carefully because the last ten outputs were fine. You're chasing velocity — and velocity is the drug.

I noticed this in my own sessions. Early in a project, my prompts are careful, detailed, well-structured. By week two, they're one-liners. "Fix the bug." "Add the feature." "Handle the edge case." And then I spend three rounds correcting what a proper prompt would have gotten right the first time.

The research confirms this isn't just me. A METR study put 16 experienced developers on their own repositories — projects they'd worked on for years. With AI tools, they were 19% slower. But they believed they were 20% faster. A 39-point perception gap between felt productivity and actual productivity.

That's not a tool problem. That's a human problem.

Velocity Is Just One Metric

There are two things that matter when working with an AI agent: velocity and quality. Most of us optimize exclusively for velocity.

But velocity without quality is technical debt at machine speed. Teams with high AI code generation experience 91% longer review times and 9% higher bug rates. Security researchers found 322% more privilege escalation paths in AI-generated code. One CTO described the output as "archaeology — incomprehensible without understanding the original intent."

The phrase that captures it: AI-generated legacy code. Code that is minutes old but functionally legacy because no human understands its inner workings.

So the real insight isn't "slow down Claude." It's slow down, human.

The Prompt Is the Spec

Here's what I realized: when you hand off work to an AI agent, your prompt is the specification. It's not a casual message. It's not a chat. It's a contract for what you want built.

And we already know the fundamental equation: quality of input determines quality of output. Write a sharp spec, and the agent ships something close to production-ready. Write a vague one, and you get technically correct code that solves the wrong problem.

The back-and-forth correction cycles that eat your time? Those are the cost of a specification you didn't write. Every "no, not that" and "I meant this instead" is a spec revision that should have been a spec line.

This doesn't mean every prompt needs to be a 200-line PRD. It means being intentional about what you're asking for. The difference between "add auth" and "add JWT-based auth with refresh tokens, 15-minute access token expiry, httpOnly cookies, and a /me endpoint that returns the current user" is thirty seconds of thinking. But it's the difference between one round and five.

Four Styles of Working with AI

Thinking about my own patterns — and studying how other practitioners work — I see four distinct styles. Each has its place. The mistake is using only one.

1. The Handoff

You write a detailed prompt. Claude executes. You review the result. This is my default mode — delegation. It works brilliantly when the spec is clear and the task is well-scoped. It falls apart when the spec is vague or the problem space is ambiguous.

Best for: well-defined tasks, repetitive work, implementation where the architecture is already decided.

Risk: prompt degradation over time. You get sloppy because the last ten handoffs worked.

2. The Conversation

You don't hand off a finished spec. You build the spec together with Claude, in small chunks, through conversation. You ask questions. Claude asks questions back. You iterate on the approach before any code is written.

This is slower. But it produces better specs — because Claude optimizes them for its own execution. And you learn more, because you're present for every decision. The spec isn't just a document; it's shared understanding.

Best for: complex problems, unfamiliar domains, architecture decisions, anything where you're not sure what "done" looks like.

Risk: it requires your sustained attention. You can't hand off and walk away.

3. The Ping-Pong

Small, rapid iterations. You give a tiny task. Claude does it. You give the next. Fast feedback loops, high control, minimal risk per step. Like pair programming but with an AI that types faster than you.

Best for: debugging, refactoring, exploring a new codebase, anything where the next step depends on the result of this step.

Risk: context accumulation. After 50 ping-pong rounds, your session is full of micro-decisions and Claude starts losing the thread.

4. The Marathon

Sessions that run for days. Even weeks. You keep the context alive across multiple work sessions, building on previous results, referencing earlier decisions. The session becomes a living workspace.

Best for: large projects where continuity matters, complex systems where context is expensive to rebuild.

Risk: context degradation. Research shows signal-to-noise ratio drops to 2.5% by the fifth step. At 100K tokens, 10 billion pairwise relationships compete for attention. Performance follows a U-shaped curve — strong at the start and end, 30% lower in the middle. After 35 minutes of continuous work, all agents' success rates decline. Doubling task duration quadruples failure rate.

When to Reset

The marathon style raises a real question: how long should a session live?

The data says: shorter than you think.

Context rot is real and measurable. Every message adds noise alongside signal. Failed approaches pollute future attempts — Claude remembers what didn't work and still references it. Corrections clutter the context window with negative examples that confuse more than they help.

Practical guidelines I've landed on:

Switch tasks? New session. Don't carry blog publishing context into a database migration.
Corrected Claude twice on the same thing? Clear and rewrite a better initial prompt. The context is already poisoned with failed approaches.
Session feels sluggish or Claude starts repeating mistakes? That's context degradation. Start fresh.
Big task completed? Commit, then new session for the next task. Don't chain unrelated work.
Multi-day project? Keep the session for continuity, but use /compact regularly to compress context. And accept that quality degrades over days — plan periodic fresh starts.

The counterintuitive truth: starting fresh is usually faster than continuing. A clean context with a good prompt beats a bloated context with accumulated corrections.

Both Roads Lead to the Same Place

Whether you hand off with a detailed spec or build the spec conversationally — the goal is identical: arrive at a clear definition of what "done" looks like before the agent starts building.

The method doesn't matter as much as the discipline. Handoff works if you invest the time upfront in the prompt. Conversation works if you invest the time in the back-and-forth. The expensive path is neither — firing off a vague prompt and then spending five rounds correcting the result.

The best practitioners I've studied do this naturally. They treat every interaction with an AI agent as either "defining the work" or "doing the work" — and they never confuse the two. The defining phase gets full attention, full detail, full thinking. The doing phase is delegated.

The Real Skill

The 2026 version of engineering skill isn't writing code. It's knowing which style to use when, how much spec is enough, when to hand off vs collaborate, and when to throw away a session and start clean.

It's context architecture — what you load matters more than what you type. It's verification discipline — always giving Claude a way to check its own work. It's session hygiene — knowing when the context is helping and when it's hurting.

And above all, it's the willingness to slow down. Not because the AI needs you to go slower. Because you need to go slower. The AI will go exactly as fast as you let it. The question is whether you're building something real or generating code-shaped artifacts that nobody understands.

Slow down, human. The spec is worth the thirty seconds.

Slow Down, Human

The Addiction

Velocity Is Just One Metric

The Prompt Is the Spec