Claude Design shipped two weeks ago. Text in, Figma out. Twenty seconds. The Product Management subreddit had a 500-engagement thread inside a day, every reply some version of "what survives of my job in 24 months." The narrative locked in fast: frontend goes first, then design, then everything visible follows.
The narrative is wrong about which half of the stack is actually cooked.
I build agent systems for a living. Last week I shipped a draft-renewal mission in nanika, the orchestrator I work on; the Go phases took two prompts and the test suite caught the one regression I missed. The same week I redid a card component on my own site and the model gave me eight passing tests around a layout that read wrong in three browsers. That's the pattern, and it isn't subtle. The model is dramatically better at backend work, the kind that's pure text, strict types, and has tests as feedback. The model is much weaker at frontend, the kind that needs taste, visual correctness, and an eye that can tell when a button's padding is two pixels off. Nobody talks about this because backend doesn't demo. You can't tweet a screenshot of a clean migration script.
What the model is actually good at
Pure text with strict types is the model's home turf. You give it a Go file, it gives you back a Go file. The compiler tells it whether the types line up. The test runner tells it whether the behaviour is right. The feedback loop is short, machine-readable, and unambiguous. When Claude Code edits a function in nanika and breaks the build, I know in two seconds. When it fixes the build, I also know in two seconds. The model can iterate against that signal without me in the loop at all.
This isn't what frontend feedback looks like. Frontend feedback is "does it look right." That's a human eye, every time. The model can write JSX that compiles and tests that pass and Storybook stories that render, and the resulting page can still be ugly, off-brand, or visually broken. The card I just mentioned: right heading size, wrong type ramp on the body, button styled in the brand secondary instead of primary, hover state pointing at a colour token that didn't exist on light mode. The component compiled. The Storybook test passed. It just looked wrong. The check passing is the bug. The thing that needed to be checked was something the model couldn't see.
So when people say "frontend is cooked," what they mean is the model can produce something that looks like a frontend very quickly. That's true. What they're missing is the second step. Producing something that's actually correct as a frontend requires a human looking at it. Producing something that's actually correct as a backend requires types and tests, and the model can run those itself.
Backend is the part of the job where the model is the most autonomous. Frontend is the part where the model is the least autonomous. The cooked half is the autonomous one.
The Reddit audit nobody connected to this
There's a post going around r/webdev right now. Five-dev team, full-stack mix of React and Node, adopted Copilot and Claude aggressively last October. Velocity went up immediately. Sprint metrics looked great. Then in March they got asked to do a quality audit because production kept hitting weird bugs nobody could reproduce locally.
The auditor went through 340 PRs. The findings:
Plausible-looking code that technically works but is structured in ways no human would choose. A try-catch around a console.log. A utility function that was 40 lines of enterprise-grade typescript doing exactly what Array.prototype.map already does. Variable names that sound right but dont match what the variable actually holds, like a thing called userPreferences that was actually a session token.
The auditor didn't break the findings down by stack. But re-read the examples. The forty-line reimplementation of Array.prototype.map is the most clearly backend-shaped one. It's a TypeScript utility that the type system signed off on, and it's exactly the kind of thing the model produces when it has a tight test loop and no human pushing back on the shape. The misnamed userPreferences variable holding a session token is the same shape: types pass, semantics are wrong, no test catches it because no test was looking at the meaning of the name. These got past five experienced devs and a typecheck and a test suite anyway.
Which means the model isn't failing on the backend. It's succeeding. It's writing code that compiles, passes tests, looks like backend code, and has the same shape as forty other PRs in the same week. The auditor's actual phrase is the giveaway: "every PR started looking the same." That's the story. Uniform output. The model has a backend voice now. It has voiced a senior dev's PRs into something his teammate described as "a very polite stranger who approximated his job description."
You don't get that uniformity on frontend. Frontend output from the model is wildly inconsistent in a different shape than the audit found. The same prompt, twice, gives me two different layouts, two different colour choices, and two different opinions about whether the call-to-action belongs above or below the fold. The reason is the same thing that makes the model strong on backend: backend has a tight feedback loop the model can run by itself. Frontend doesn't.
Demoability is doing all the work
Claude Design is the cleanest example of the demoability trap. The demo is genuinely impressive. Type a sentence, get a wireframe. Type another sentence, get a pitch deck. The artifact viewer is a design tool now and the gap between "AI coding assistant" and "design surface" closed in one release.
But ship that wireframe. The token cost is brutal. One HN comment in the launch thread was "burned through an entire week of tokens in 25 minutes." I tried it on a deck that needed to use a terracotta brand colour and a 48pt heading scale and it produced a generic blue-and-serif deck I had to manually replace every heading on. The design system my company has spent two years building isn't in there at all, and a Bluesky post by kevin122-06 named the trade plainly: AI can churn sites fast, but the design system is what keeps the output sharp.
Now compare that to a backend demo. There isn't one. Nobody screenshots Claude writing a migration. Nobody films a 20-second video of a passing test suite. The work the model is best at is also the least demoable. Which means the discourse runs on the visible artifacts, and the visible artifacts come from the half of the stack the model is weaker at. Frontend gets the hype because frontend gets the screenshots. Backend gets the hype-free reality of "yeah, it does this all day now and we don't really notice."
That asymmetry is what creates the "frontend is cooked" narrative. It's not about capability. It's about what demos well. And what demos well is also what fails most visibly, because frontend correctness is a thing humans evaluate in milliseconds.
What still needs a backend dev
Time to walk the title back.
The model is great at the typing of backend work: function bodies, type signatures, test scaffolds, JSON shape transforms, REST handlers that follow a pattern, migrations against a known schema. That's the part of the job that's pure transcription from a description into code. It always was the most mechanical part of the job. Last week I let Claude Code rebuild the chunk-dedupe layer in nanika's dream pipeline. Three rounds. All gates green. I never opened the file. That's the new normal for the transcription part of backend, and it's the part the loud takes are responding to.
But there's a second half of backend work that the model is bad at. It's the half that doesn't show up in the test suite.
- Schema decisions. Picking the right shape for the data model is a judgment call about how the system will evolve over the next two years. Tests can't validate it. The model picks the shape that matches the most common pattern, which is often wrong for your specific case.
- Distributed correctness. What happens when two replicas race. What happens when a queue is replayed. What happens when the network partitions for thirty seconds. The model can write the code for the happy path and pass the tests. The tests don't cover the cases that actually break.
- The on-call layer. Running a thing in production for two years, understanding the four ways it has historically failed, knowing which logs are noise and which are the canary. None of this is in the codebase. None of it is in the model.
- What not to build. The most expensive backend mistake is the abstraction that you didn't need. The model is biased toward generating more abstraction, not less. It will give you the polite-stranger version of senior judgment.
So the title is a provocation. The honest version: the transcription layer of backend is cooked, the judgment layer is not. The same is roughly true on frontend. The typing of components is cookable, the visual taste isn't, but the ratio is reversed. Try it: the Go function that parses a webhook event into a typed struct is two prompts away. The CSS that lines up a three-column card grid at three breakpoints, with a sticky header, an empty state, and brand-correct hover, is still my afternoon. The model eats more of the backend job, and what's left over is a smaller, more senior remainder.
Honest limitations
I'm a fullstack dev. I write both halves. So the asymmetry I'm describing isn't a backend dev guessing at frontend, it's the same person shipping both and watching the model behave differently on each side. There are three confounds I should still name before anyone takes this and runs.
First, the systems I lean on most as evidence are the ones I've actually shipped end-to-end: nanika, agent orchestrators, CLI tools, scheduler daemons, plus the React and Next.js work that sits on top of them. That's a stack where I write the tests myself and I know which feedback loops are tight. A fullstack dev embedded in a design-system-heavy team with a great Figma library and a strong design partner is a different shape. The model might be much better in that environment than I'm giving it credit for.
Second, the visual blind spot is solvable. The pieces are already in flight: Anthropic's computer use for screenshot-grounded agents, Playwright-driven visual checks wired into Claude Code as a skill, and design-system-aware codegen surfaces like Vercel's v0. The current state of "the model can't see" is the current state, not the permanent state. If those pieces glue together into a real screenshot-correction loop in the next twelve months, the asymmetry I'm describing flips.
Third, "tests as feedback" is doing a lot of work in this argument and it's only as good as the tests are. Most teams don't write the tests that would actually catch the model's bad outputs. The audit in r/webdev is the proof. The tests passed and the code was still slop. If your backend tests are bad, the model's autonomy on backend is also bad. The advantage I'm describing is conditional on the team writing tests at the level the model needs.
Where this lands
Frontend isn't cooked. Backend isn't cooked either. What's cooked, on both sides, is the transcription layer. The part of either job where the work is "describe what you want, write the code that does it." The model eats that layer cleanly because the loop is tight and the artifacts are text.
What's not cooked is judgment. Schema choices, visual taste, distributed correctness, knowing when not to build. These stay human. The two roles are differently exposed because the ratio of transcription to judgment is different. Frontend has more visible judgment per line of code. Backend has more transcription per line of code. So the model takes a bigger chunk of the backend job, and what's left is a smaller, more senior role.
The "frontend is cooked" crowd is reading the demos and missing the asymmetry. The demos are visible because frontend is the harder half for the model. If the model could ship a production frontend the way it ships a production migration, there'd be nothing to demo.
Open question I don't have an answer to: in twelve months, when the screenshot-feedback loop is mature and the model can actually see, does the asymmetry collapse? Or does taste turn out to be a deeper moat than tests-as-feedback? I genuinely don't know. I'd watch for the first design system that the model can read, write, and self-correct against without a human in the loop. That's the moment frontend's moat starts to thin.
Until then: the cooked half is the quiet one. And the loudest narrative is reading the screenshots.