IX.AI at work · July 2026
My AI prototyping stack is just the same tools my engineers already use.
Visual Studio Code, Claude Code, GitHub. Not a designer sandbox, not a prototyping toy — the same environment my engineers work in every day, with all the friction that comes with it, and most of the reward too.
By Gisella Famà · 5 min read · AI at work
There is a version of AI prototyping that lives in a browser tab. You type a prompt, something appears, you screenshot it, you paste it into Figma, and you call the engineers over to look. It is a lovely demo. It is not what I do.
My stack is boring on purpose: Visual Studio Code, Claude Code, GitHub. The same three tools the front-end engineers on my team open every morning. There is no separate designer environment, no isolated playground, no clever export step. I work in the repo. Their repo. The one we ship from.
"The most useful AI prototyping stack for a designer is the one your engineers already have open."
Why the real environment matters
A prototype in a sandbox is a suggestion. A branch in the repo is a proposal. The difference is not vibes — it is context. In the repo, my prototype uses the real components, the real tokens, the real data shape, the real edge cases. When it breaks, it breaks in ways that would actually happen. That is what makes the feedback useful.
It also means the thing I hand back is not a screenshot. It is a branch. Sometimes a PR. Sometimes just a diff on a Loom. Engineers can read it, run it, argue with it, or merge it. The conversation moves faster because we are looking at the same object.
What the stack actually does for me
Visual Studio Code is where I read the code. Not write, at first — read. Open a file, follow an import, see how a component is composed of five smaller ones, and slowly build a picture of how the app actually fits together.
Claude Code is the patient colleague who explains what I'm looking at. "What does this hook do? Why is this wrapped in a memo? Where is this data coming from?" It answers, I check, I ask again. It is a tutor that never gets tired.
GitHub is where the etiquette lives. Branches, commits, PRs, reviews, comments, merges. Learning that workflow is half the value — because that is the workflow the rest of the company runs on, and once you're inside it, you stop being a bystander to the build.
E2e tests, which I used to treat as somebody else's problem, turn out to be a design tool. Every test I improve is a small contract about how the product is supposed to behave. Writing one is a very concrete way of saying "this is what I meant".
Learning while doing, with Claude beside you
The honest truth is I did not know most of this just a few months ago. What made it possible was using Claude Code at work not to skip the learning, but to compress it. I open a file I don't understand. I ask what it does. I ask how it connects to the file next to it. I ask what would break if I changed this line. I make the change. I see what happens. Then I ask again.
You do not become a front-end engineer this way. You do become a designer who can read a codebase, follow a data flow, and know roughly where your change will land. That is enough to be dangerous in the good way.
The unfair prerequisite
I should be honest about the thing that makes any of this work: you need something to build on. If your engineers have been shipping your designs for three months, there is enough of a codebase — components, patterns, a data layer, a routing structure — to poke at and learn from. If you're starting from a completely blank repo on your own, this stack is much harder to use well, because there is nothing to imitate and nothing to break.
So the version of this article that says "designers, install Claude Code today and start shipping" is the LinkedIn version. The real version is: wait until your team has built something. Then, quietly, start reading it. Then start prototyping inside it. Then start opening PRs. The stack is the last part. The context is the whole point.
"The tools are the easy part. The unfair advantage is having a real product to work inside, and a team that lets you."
What I get from working this way
Prototypes that are indistinguishable from the real thing, because they are made of the real thing. Bug fixes I can raise myself instead of filing a ticket. A running mental map of the codebase that means my next design is grounded in what is actually possible. And a working relationship with the engineers that has stopped being about handover and started being about co-editing.
I still do not know exactly what is happening inside every file I touch. I still ask Claude questions a real engineer would find charmingly basic or offensive. I still open PRs that get gently improved before they merge. But the environment I work in is the same one the product ships from, and that has quietly changed the job.
If you want a prototyping stack that will make you known on X, use something else. If you want one that will make you more useful on Wednesday, learn the tools your engineers already have open.
Disagree? That's the point. Tell me why.
← Back to all thoughts