XI.AI at work · August 2026
Claude Code made me a front-end developer. A very, very junior one.
The LinkedIn version is: describe it, ship it, post the screenshot. The real version has a front-end engineer in it, explaining why the thing that works is still wrong.
By Gisella Famà · 5 min read · AI at work
There is a version of this story that does very well on LinkedIn. Designer opens terminal, types a sentence, ships a feature, posts a screenshot with the caption "the gap between design and engineering is gone". I have lived the other version, which is slower, more useful, and involves someone who actually knows the codebase telling me why my beautiful working solution is wrong.
Both versions start the same way. That's the confusing part. Claude Code genuinely does get you to something that runs, on a real product, in a real repo, faster than you expect. The difference is what happens in the twenty minutes after it runs.
"Getting to something that works is easy now. Getting to something that should exist in your codebase is the entire job."
The influencer version
Give the machine the problem. Accept the output. Open the PR. Declare that roles are dissolving. It's a nice story because it's tidy, and because nobody in the screenshot is asking what happens to that code in six months.
It also isn't a lie, exactly. That workflow does produce working software. It just optimises for the wrong thing: the demo, not the product.
The version I actually use
Work the problem with Claude Code. Get it running locally, in the real app, with the real data. This part is genuinely fast.
Then get a front-end engineer to review it — properly, not a thumbs up. Ask them not just "is this fine" but "is this how we'd do it here".
Listen to why it's wrong. Not "wrong" as in broken. Wrong as in: it doesn't match where the architecture is going.
Go back into the code and redo it the right way, with the context I now have. That second pass is where I actually learn something.
What "wrong but working" looks like
The most common note I get is that Claude reached for an extra library when the information was already available somewhere else in the product. It didn't see that. It couldn't — it was solving my prompt, not maintaining our system. So it did the reasonable local thing and added a dependency we don't need.
The other regular one is extra code. State that duplicates state we already hold. A helper that quietly re-implements something in our utils folder. A component that doesn't compose with the ones around it. Each of these individually is small. Collectively they make the product harder to reason about, harder to change, and sometimes slower — and none of that shows up in the screenshot I was about to post.
"Claude optimises for making my prompt true. An engineer optimises for the codebase still being good in a year. Those are not the same instruction."
Why the review is the valuable bit
I used to think the review was the tax I paid for being allowed near the repo. It's the opposite. The review is the part where I learn the shape of the system — why we hold data where we hold it, which patterns we're moving away from, what "performant" means in our specific context rather than in general.
You cannot get that from a model, because it isn't in the code yet. It's in the heads of the people who decided it last quarter. Claude can read our repo; it can't read our roadmap or the three arguments we had about it.
So what am I, exactly
Here is the honest self-assessment. Designers like me know a fair amount. We read code comfortably, we understand components and state and why a re-render is expensive. Put that together with Claude Code and it feels, for about a week, like we've levelled up into engineers.
We haven't. We are very, very junior front-end developers. Arguably not even junior — junior developers have been taught to think about the system. We are people who can produce plausible front-end code and pretend to be junior developers, which is a genuinely useful thing to be, as long as we're clear-eyed that that's what it is.
That framing is what makes it work. If I show up thinking I'm an engineer, I defend the code. If I show up knowing I'm the most junior person in the conversation, I ask why, I get taught, and the thing that eventually merges is better than what either of us would have produced alone.
The useful takeaway
Use Claude Code to get to something real, fast — that advantage is genuine and it's not going away. Then treat the output as a first draft written by someone extremely capable who has never attended one of your architecture discussions. Get it reviewed by someone who has. Rewrite it properly. Take the notes personally in the good way.
That loop is slower than the LinkedIn version. It's also the only one that leaves the product better than you found it, and the only one that leaves you knowing more than you did on Monday.
Disagree? That's the point. Tell me why.
← Back to all thoughts