Component scaffolding is where Claude Code earns its keep. When I'm building a new UI component, I give it: the component name, its TypeScript interface, the CSS custom properties from our token system, and the visual spec in plain language. The output is usually 80% correct — the structure is right, the types are clean, and it respects the token constraints. The remaining 20% is mine: the micro-interactions, the edge cases in responsive behavior, and the visual judgment that only resolves in context.
The prompt pattern that actually works
What I call "spec-first, not design-first" is the pattern that consistently produces usable output. Instead of "make a card component that looks like X," I describe: the data it renders, the states it needs (default, hover, disabled, loading), the token constraints it must respect, and the output format I want — named export, TypeScript interfaces inline, no inline styles, no magic numbers. The structure comes back sound. I modify the visual treatment in context.
The failure mode is asking for components without giving token context. Without it, Claude Code invents values — hardcoded hex codes, arbitrary spacing, font sizes that don't fit the scale. Every time I've tried to shortcut the context, I've paid for it in cleanup. I now keep a TOKENS.md reference file in the project root and paste it into any styling prompt. The overhead is four seconds; the output improvement is significant.
The refactor case
Refactoring is the other high-value use case. When a function has grown to 80 lines and clearly needs splitting, describing the intent and asking for a refactored version is faster than doing it manually. The key is telling it what not to do: "no new abstractions I haven't asked for, no changing the external interface, no adding types I don't already have." Left to itself, AI will overengineer. Constrained, it's useful.
I also use it for naming. When I have a function that does something specific but I can't find the right name, describing the behavior and asking for three options plus the reasoning takes 10 seconds. I don't always use what it suggests, but the process unsticks me.
Debugging is the place where Claude Code is least useful. When I paste an error, it often suggests the obvious fix I've already tried, or it invents causes that don't apply to my codebase because it doesn't have the full context. For debugging, I read the stack trace myself, trace the call chain, and use Claude Code only to understand an unfamiliar library function or an error message I haven't seen before.
Where judgment stays with me
Logic that technically works but is architecturally wrong is Claude Code's consistent failure mode. It produces working code that doesn't fit the existing patterns — a different state management approach than everything else, error handling that diverges from the rest of the app. The code runs. It's still debt.
My rule: AI handles structure, I handle judgment. For scaffolding, refactoring, and the repetitive parts of a data layer — AI is faster. For deciding what a component should do, how it interacts with the wider system, whether an abstraction is premature — that stays with me.
The sessions that go wrong are the ones where I'm hoping AI will figure out what I haven't resolved. It won't. Design judgment has to live somewhere. It lives with me. Claude Code helps me move faster once that judgment is made.
Across a typical week: roughly 40% of component work is scaffolded with Claude Code, 20% is refactored with its help, and the rest is written directly because the context is too specific or the pattern too bespoke to brief efficiently. That ratio has been stable across the last three months of building the Datamotive production site and this portfolio.
Discussion
Loading comments...