Every AI coding tool promises to make you 10x faster. Here’s what they don’t tell you: the best ones change your rhythm entirely.

TL;DR: AI isn’t a typing accelerator. It’s a thinking accelerator. If you slow down to specify intent, clarify architecture, and add quality gates, you ship fewer regressions and make fewer reversals—net velocity goes up.

Use extended thinking for complex tasks: start prompts with “think”, “think hard”, or “ultrathink” to give the model more reasoning time.

The Uncomfortable Truth

I’ve been using Claude Code for personal projects and Cursor for work. I’m not coding slower overall—I’m spending time differently. Less typing, more thinking. Less debugging, more architecting.

That’s the point.

AI as a Mirror

When AI over-engineers a simple feature, it’s showing us something. I’ve seen it try adding database columns instead of fixing missing ORM relationships. Instead of addressing the real problem, it builds elaborate workarounds.

Sound familiar? That’s exactly what we do under deadline pressure.

When it generates 15 PHP tests that essentially test the same thing with slight variations, it’s mimicking common test-writing anxiety. More tests feel safer. But they’re not better.

The inefficiency isn’t random. It’s learned. From us.

The Rust Parallel

Rust makes you fight the borrow checker until you understand memory safety. AI makes you fight the prompt until you understand your problem.

// What I used to write:
function processUserData(data) {
  // 50 lines of implementation
}

// What AI forces me to articulate:
// "Process user data by validating email format,
// normalising phone numbers to E.164,
// handling missing fields gracefully,
// and returning a standardised user object"

That specification work? I should have been doing it anyway.

The Architecture Shift

Here’s what’s actually changing: We’re no longer thinking “how do I implement this?” We’re thinking “how do I architect this so AI can implement it?”

This shifts focus from implementation to architecture.

When you have to explain a system to AI, you discover:

• Module boundaries are unclear
• Naming is inconsistent
• Patterns aren’t actually patterns
• That “simple” feature touches 12 different concerns

Why Different is Better

The developers optimising for AI speed are missing the point. They’re using AI like a faster keyboard. But AI isn’t a typing accelerator. It’s a thinking accelerator.

The rhythm change comes from:

1. Better Problem Definition - You can’t prompt what you don’t understand
2. Clearer Architecture - AI struggles with your spaghetti too
3. Explicit Intentions - Vague requirements produce vague code
4. Quality Gates - You review AI code more carefully than your own

Each of these “inefficiencies” is something we should have been doing anyway.

A Practical Workflow: Slow First, Fast Later

1. Clarify intent
   • Write 3–7 bullet points describing the outcome, constraints, and what “done” means.
   • Note non-goals to prevent scope creep.
   • If using Claude Code, put this spec and your repo norms in CLAUDE.md so it auto-loads.
2. Shape architecture
   • Name modules, boundaries, and data flow in plain language.
   • Identify risks and edge cases you want guarded.
3. Delegate implementation to AI
   • Provide the intent and architecture; ask for code that fits your boundaries and naming.
   • Require tests or checks that target the risks you listed.
   • Optional TDD: write failing tests first, then implement; do not modify tests.
4. Review with quality gates
   • Run through a pre-commit checklist: naming, side effects, failure modes, idempotency, performance.
   • Reject diffs that add complexity without addressing the stated goal.
5. Tighten the loop
   • Capture gaps in the prompt; update your spec so the next iteration starts clearer.
   • Reset context between tasks (e.g., use /clear in Claude Code) to keep prompts focused.

This rhythm feels slower at first. It compounds.

When Slower Is The Wrong Move (And What To Do Instead)

• Small UI copy tweaks or one-off scripts: move fast; write a 1–2 line spec and ship.
• Spikes and throwaways: prioritise learning. Time-box and document what you learned.
• Local-only prototypes: cut quality gates, but summarise follow-up debt so it’s explicit.

The trick is to toggle intentionally: default to deliberate for production code; consciously opt into “fast mode” when risk is low and learning is the goal.

Paste-able Prompt Checklist

Goal:
- What problem are we solving?
- What is explicitly out of scope?

Architecture sketch:
- Modules and boundaries
- Data flow and states
- Known risks/edge cases

Requirements:
- Inputs/outputs with shapes
- Performance and constraints

Quality gates (must pass):
- Naming consistency and single responsibility
- Error handling and idempotency
- Minimal surface area for side effects
- Tests for the listed risks

The Real 10x

The 10x improvement isn’t in lines per minute. It’s in:

• Decisions that don’t need reverting
• Architecture that doesn’t need refactoring
• Code that doesn’t need debugging
• Features that actually solve the problem

Speed is a vanity metric. Velocity includes direction.

The Future Belongs to the Deliberate

In five years, the developers who survived will be the ones who learned this new rhythm. Who used AI as a forcing function for clarity. Who treated prompts like architecture documents.

The ones who chased speed? They’ll be debugging the mess they created at 10x velocity.

AI isn’t making us slower. It’s revealing that we were always too fast in the wrong places. The best code isn’t written quickly. It’s thought through slowly, then implemented at whatever speed makes sense.

Key Takeaways

• Clearer prompts are architecture documents in disguise.
• Define boundaries first; let AI fill in the interior.
• Add small, strict quality gates; they pay for themselves.
• Be explicit about when you’re optimising for learning vs. shipping.

That’s the paradox: AI changes your rhythm until you realise you’re actually faster. Not at typing. At building systems that last.

---

Adapting to AI’s rhythm. Thoughts? Find me on Twitter or LinkedIn.