My experience is that Claude Code, when used appropriately, can produce work better than most programmers. "when used appropriately" means: - Setting up guard

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.