My experience is that Claude Code, when used appropriately, can produce work better than most programmers.

"when used appropriately" means:

- Setting up guardrails: use a statically typed language, linters, CLAUDE.md/skills for best practices.

- Told to do research when making technical decisions, e.g. "look online for prior art" or "do research and compare libraries for X"

- Told to prioritize quality and maintainability over speed. Saying we have no deadline, no budget, etc.

- Given extensive documentation for any libraries/APIs it is using. Usually I will do this as a pre-processing step, e.g. "look at 50 pages of docs for Y and distill it into a skill"

- Given feedback loops to check its work

- Has external systems constraining it from making shortcuts, e.g. "ratchet" checks to make sure it can't add lint suppressions, `unsafe` blocks, etc.

And, the most important things:

- An operator who knows how to write good code. You aren't going to get a good UI/app unless you can tell it what that means. E.g. telling it to prioritize native HTML/CSS over JS, avoiding complexity like Redux, adding animations but focus on usability, make sure the UI is accessible, etc.

- An operator who is steering it to produce a good plan. Not only to make sure that you are building the right thing, but also you are explaining how to test it, other properties it should have (monitoring/observability, latency, availability, etc.)

A lot of this comes down to "put the right things in the context/plan". If you aren't doing that, then of course you're going to get bad output from an LLM. Just like you would get bad output from a dev if you said "build me X" without further elaboration.