95% of code written by AI, personal productivity doubled, quality maintained. Those are the numbers Haskell developer Matt Parsons reports after a month of daily Claude Code usage. The catch? He had to spend that month teaching Claude to do less.
Parsons' core argument flips the typical AI coding narrative. Claude's value isn't speed - it's substituting human attention. A task that takes Claude 6 hours but only 3 hours manually is still a win if you're doing other work while Claude runs. The metric that matters isn't "how fast did the AI finish" but "how much of my attention did it consume."
Claude's Default Problem: It Tries Too Hard
Out of the box, Claude Code over-researches, over-engineers, and generally does too much. Parsons puts it bluntly: "You have to tell Claude to stop doing stuff or to do stuff more efficiently." Humans naturally take shortcuts and find the laziest path to a working solution. Claude has no such instinct - it needs explicit permission to be efficient.
The fix is tight scoping. Vague, big-picture prompts produce vague, bloated results. Instead, Parsons feeds Claude narrowly defined issues backed by tests and examples. Each session starts supervised and exploratory, then progresses to mostly unsupervised as Claude builds up reusable tools and CLI scripts. The goal is replacing non-deterministic LLM work (where Claude guesses at solutions) with deterministic automation (where Claude runs scripts it previously created).
Concrete Results: 30% Faster Build Times
Two examples stand out. First, a Template Haskell debugging session took Claude 6 hours - roughly double what Parsons estimated for manual work. But he was productive on other tasks the entire time, making it a net positive.
Second, and more impressive: Claude analyzed timing logs for the Cabal package solver (a dependency resolution tool in Haskell), identified bottlenecks, and implemented fixes that produced a 30% improvement in solver times. That shaved 2 seconds off every cabal repl invocation - the kind of optimization that compounds across hundreds of daily runs.
The Technique Worth Stealing
One approach from the post deserves wider adoption: persona-based code review. Instead of asking Claude for a generic review, Parsons asks it to review code as specific well-known developers in the Haskell community. The reviews are noticeably more pointed and useful than generic "please review this" prompts.
The broader pattern here is that Claude Code rewards investment in your CLAUDE.md configuration file (a project-level instruction file that shapes Claude's behavior). The more specific your constraints, the better the output. Parsons treats it as a living document, updating it as Claude learns new project-specific techniques.
The honest limitation: Claude still lacks taste, judgment, and vision. It cannot make subjective design decisions well, and it struggles with poorly-defined problems. The developer who gets the most from it is the one who already knows what good looks like and can break large goals into small, testable pieces. Claude handles the mechanical execution. You keep the steering wheel.