Handing the whole chip-design flow to AI: one software person's end-to-end bet
I've done software for many years, but this is the first time I've properly gotten to grips with the entire chip-design flow. This series is the record of one software person's bet — that the whole flow, from a complete set of design documents to a chip, can be handed to AI to run end-to-end. Vibe-IC is what I built to test that bet.
Who I am: a software veteran, a novice at the IC flow
Let me get myself out of the way first, because this whole series rests on it.
I've spent many years in software. Over the years, the world I've known is APIs, databases, front-end and back-end, the cloud — taking a piece of requirements and turning it into a system that runs, ships, and gets used. To be clear: what I've always done is the software side.
I even spent nearly ten years at MediaTek. But here's the thing people tend to misread: in a company of tens of thousands, some people sit close to real silicon and some sit far from it — and I was always up in the "upper layer." I never actually went deep into the RTL→GDS flow. How RTL is written, what happens after synthesis, what DRC/LVS are really checking — I'd never studied any of it in detail, and I don't count myself fluent. So when it comes to the whole IC-design flow, I'm a genuine novice.
Why put this slightly awkward fact up front? Because the contrast itself — a software foundation plus unfamiliarity with the IC flow — is exactly what makes this whole thing possible. Precisely because I hadn't marinated in this field for decades, I never inherited the industry's built-in assumption that "this is just how it has to be done." When I look at IC design, I don't see a pile of sacred, untouchable craft; I see an information structure: clear inputs and outputs, every step checkable, and experience that can mostly be written down as rules. That structure looks eerily familiar to a software person.
What I'm betting on is "end-to-end"
Now the bet. Over this past year, if you also write code, you probably know what I mean: AI's ability to write software hasn't "improved a little" — it's jumped in steps. I happen to be standing in the front row of this tsunami. As for "after the software engineers in the front row, who's next" — that's the question I've been turning over this past half-year, and the next post is devoted to it, so I'll leave it there for now.
What I want to talk about here is the thing I chose to go and build once I'd understood the tsunami. My bet is very concrete: an entire chip-design flow — from a complete set of design documents to a layout that can be sent off to a fab — can be handed to AI agents to run all the way through, with no more large amounts of human hand-off in between.
That's what I mean by end-to-end, and it's what "AI-Native" means. Where's the difference? Most people use AI as an assistant that "fills in a snippet of code" for you, bolted onto the side of an existing flow; AI-Native means putting AI in the driver's seat from step one and letting it drive the whole flow forward. Those two are worlds apart.
The whole flow, laid out, is roughly these three stretches:
- Phase 1: turn a piece of natural language, or a stack of design documents, into a layered design spec.
- Phase 2: produce RTL from that spec, then lint, simulate, run formal, and verify it on an FPGA.
- Phase 3: synthesis, STA (timing analysis), place-and-route, DRC/LVS, and finally a GDS that can go to tape-out.
A complete set of design documents goes in; the seed of a chip comes out. This whole middle stretch used to take a full team and several months of back-and-forth — and what I'm betting is that AI can carry it all the way through.
Why end-to-end — and not just better tools for each role
Here's the part I care about most, and the real reason I bet on the whole flow instead of one slice of it. The old chip-design flow is a relay of roles — spec, RTL, verification, synthesis, timing, physical design, signoff — and every role is a person, or a department. The true bottleneck in that flow was never how fast any one person worked. It was the communication between them: person to person, team to team — the meetings, the hand-offs, the "wait, which version is this" that sits in every seam.
So the move that actually matters isn't making each role a little faster. It's letting AI run the roles themselves — turning each person-or-department, conceptually, into an agent, the point being to rebuild the roles as agents rather than bolt the old org chart onto AI unchanged — so the flow becomes one agent handing off to the next, and the next, all the way down. When the hand-offs are agent-to-agent instead of human-to-human, the seam that used to slow the whole thing down mostly disappears, and a person's job shrinks toward a single review at the very end instead of a hand-off at every step. That's where a real step-change becomes possible — the order-of-magnitude jump people mean when they say "ten times, a hundred times," not because any single step got a hundred times faster, but because the waiting between the steps got taken out.
And this is a different thing from each role picking up an AI to sharpen its own work — not a bigger version of the same thing. If it's only individual tools getting sharper, the bottleneck lands right back where it always was: the communication between people and between departments. That path can get you 10%, 20%, maybe 50% — it cannot get you to ten times, or a hundred. Only running the whole flow AI-native, agent-to-agent, even puts that number on the table — and, to be honest, that's a bet, not a finished result. But it's the one structure in which the big number is possible at all.
What Vibe-IC is
Vibe-IC is the thing I built to test that bet.
It's a Claude Code plugin, and on install it automatically registers an MCP EDA server that wires a whole set of EDA tools up as AI's "hands." You drive it in natural-language conversation — it's not an IDE extension, there's no syntax highlighting, and you don't need to know how to write Tcl. You just tell it "I want a chip that does this," and it takes care of pushing Phase 1/2/3 forward, one step at a time.
But I won't pitch it as a finished product that was written once and set in stone. It's more like a container that grows up alongside AI: whatever AI can do today, it can do today; when AI gets stronger tomorrow, the same flow gets pushed further. That, really, is the heart of the bet — I'm not betting on how perfect it is today, but on the fact that it stands where the wave keeps pushing it forward.
My stance in one line: open and commercial, both welcome
Finally, let me make this series' stance clear up front, because it runs through every post that follows: the point of this is that the flow itself is end-to-end — not that we're set against anyone.
EDA tools, open-source or commercial, are all usable here. If a commercial EDA vendor wants to plug in and become part of the ecosystem, we warmly welcome it — its users simply pay to use it, exactly like paying to use an IP block placed on the platform. I'm a software person and I believe in open source; but to me, "extending open source" means completing the open part of the flow so it reaches production / sign-off grade — not measuring myself against commercial tools. In an AI-Native, end-to-end flow, which tool sits underneath is the user's call; what the platform has to do is make all of those tools something AI can drive smoothly.
This is the first post in the series. From here I'll walk you, one post at a time, into IC design as this software newcomer sees it — what it actually does, why I dare to bet AI can run it, and how I built the whole flow up, piece by piece.
Next time, I want to start from the most fundamental place: why, from first principles, any work that is logical will eventually be done by AI — and why IC design is next in line.