Preface: four months of building, and why I'm open-sourcing now

Why a preface, and why now

Every other post in this series was written to explain a piece of the flow. This one isn't. This is the preface — the part that opens the series — and I'm writing it in the same hour I decided to stop and open-source what I have.

For the last couple of months my honest inner verdict, almost every day, was the same three words: not good enough yet. There was always one more rough edge to file down, one more corner I hadn't hardened, one more thing I told myself I should fix before anyone saw it. That instinct is not wrong — but taken far enough it becomes a way to never ship. So this preface is me letting go of that perfectionism on purpose. Not because the work is finished. Because I've decided that "keep it to myself until it's perfect" is a worse mistake than "open it now and let it get better in the open."

March 2026: the first attempt, and how astonishing it was

The story starts in March 2026. What I wanted to find out was simple to say and hard to do: could an AI drive an entire end-to-end IC-design flow using nothing but open-source EDA tools? Not a commercial toolchain — the open-source academic stack, essentially one package: an open-source EDA Docker image, the kind of toolkit that lives in university labs and OSS repos.

The very first time I put the whole open EDA toolkit in front of an AI, I stacked the deck in a fair way. I took a chip that had already been taped out — a real, finished design — and I started from a friend's complete original design documents. Then I let the AI drive it through the open-source EDA on its own, to see how far it could get.

It went astonishingly smoothly. Far smoother than I had any right to expect. It was smooth enough that I started to wonder whether AI could already do fully-automated, end-to-end IC design right now — whether the pieces were quietly already in place. I even wondered, half seriously, whether a model like Claude had already absorbed enough of this knowledge that its makers were about to ship an IC-design plugin of their own and make the whole question moot.

Then the cracks: "it all passed" — when nothing had been produced

That first impression did not survive contact with the details. As I went deeper — decomposing the flow step by step, learning exactly what each stage takes in and what it must hand out, wiring each one into the real open-source tools instead of a happy-path demo — problems kept surfacing, and they kept being the same kind of problem.

The AI would run all the way to the end and cheerfully report that everything passed — when in reality there was no output at all, or the AI had simply taken whatever the tool printed at face value and believed it. A stage would "succeed" with an empty hand. A gate would go green because nobody had actually checked the thing behind it. This is the single failure mode that shaped almost everything I built afterward, and it's why an entire post in this series is about exactly that: honesty as the real moat. An automated flow that will tell you it passed when it produced nothing is worse than no automation at all, because it costs you the one thing you were automating for — trust.

The philosophy came from the failures, not from a plan

Those endless small problems taught me the one thing I most needed to learn: I had been far, far too optimistic. So, in the fragments of spare time I had, I paved the road the hard way. First get the flow to run at all. Then make it solid — make it refuse to lie about its own output. Then perfect the front end, the part where a human describes what they want. Then the middle and the back end, where the design is actually converged into silicon.

I want to be exact about one thing, because it would be dishonest to present it as foresight: this development philosophy was not how I started. I did not sit down in March with a wise plan about building the flow first and hardening it second. The order emerged only after I hit the problems — the sequence is the scar tissue left by the failures, not a strategy I was clever enough to have in advance. The back-end convergence work, where most of that hardening lives, is its own post: Part 3, back-end convergence.

Why release now — and the Kimi coincidence

For the last month or two, I have often felt it was ready to release. And every single time, I found a new problem and put it off again. I kept struggling over when to open-source, and I kept dragging it out. If I'm honest, I might have dragged it out indefinitely.

Two days ago, Kimi announced something that lined up with exactly what I had set out to do back in March: they showed that open-source tools plus an open-source PDK can reach end to end. I want to be clear that I think this is a good thing. When a field gets attention, everyone in it benefits — more eyes, more tools, more people who care whether it works. Their announcement is the thing that finally pushed me off the fence. Since what I've built seems to go a good deal deeper, I realized I should seize this moment to open-source it and let more people join, instead of staying stuck forever in "not good enough."

Let me address the timing head-on, because I would suspect it too. Someone will look at the calendar and think: open-sourcing two days after Kimi's announcement — that's a suspiciously convenient coincidence. The honest answer is that I had been on the verge of releasing for a month or two already; Kimi simply gave me the push I hadn't been able to give myself. I only started using Kimi Code about three weeks ago, and then it published something that matched my own direction. It genuinely is a coincidence — and it happens to be the coincidence that made now the right time.

And I do want to thank Kimi properly. Three or four months ago, when I was first growing this whole IC-design flow, what I actually leaned on was the free Kimi Chat: I would take a flow that Claude had drafted and have Kimi Chat review it and push back. So in a real sense this flow was hammered out in a back-and-forth between me, Claude, Kimi Chat, and even ChatGPT — until it converged into something I would dare to call an industry-standard IC design flow. Through all of that I paid nothing, used the free tier, and it genuinely helped bring the flow to where it is today — I am truly grateful for that. As for Kimi Code, I only started using it three weeks ago, even on their API key; but just running the benchmarks burned a lot of tokens, and for the way I work the experience still was not as good as Claude. The fuller comparison is in the field notes on why I chose Claude.

The two honest caveats — the heart of this preface

Here is the part I most need to say plainly, with no hedging and no softening. If you take only one thing from this whole preface, take this section. There are two things about everything I've shown you that have not been proven.

1. No expert has reviewed it

Not one person with a real IC-design background has reviewed this. Not once. I have plenty of friends who are more than qualified to tear it apart — and I never asked them, for the least defensible reason imaginable: I was too self-conscious to show them. So everything the flow has produced — including a GDSII I've been willing to call "production-ready" — has never been looked at by a professional. That word "production-ready" has, so far, passed exactly no expert's desk.

2. No commercial EDA has cross-checked it

Across these four months I have never once used commercial EDA. Partly because I'm an outsider with no license to one. And partly because the very thing I set out to prove was that open-source EDA alone can run the whole flow — bringing in a commercial tool would have quietly defeated the point of the experiment. Claude kept reminding me, correctly, that several stages' outputs really ought to be benchmarked against commercial EDA. It was right. I simply had no such tools, so I couldn't.

So I have to say it in one sentence, without flinching: nothing here has been cross-checked against commercial EDA, nor reviewed by an IC-design expert. Every "production-ready" claim in this entire series is a best-effort claim — the best I could do with what I had, not a verified fact. And this, precisely, is why I'm open-sourcing. So that experts can come in and find what I couldn't see. So that people with commercial EDA can cross-check the outputs I couldn't. So that this gets made genuinely better, together, in the open. The stance on how open and commercial tools should coexist and benchmark against each other is in the back-end convergence post.

I know its ceiling: advanced process

Beyond "not yet verified," there is a ceiling I am very clear about, and I should name it. On commercial EDA I actually ran a fairly complete analysis: I had Claude fill in as much as the open-source EDA tools can reach today, both in features and in how far they parallelize — and the solvable problems are, for the most part, solved. What is left is the deeper, harder work: large restructures, or new features I do not even know about yet, especially the ones aimed at advanced process nodes. On that, there is a very clear gap. Everything I have solved and every new feature I have added is already published in the EDA forks for anyone to inspect.

And one more thing I have to be plain about: this plugin knows its own limitation, clearly. Even when it produces what I am calling "production-ready," it is still a very long way from truly supporting advanced process nodes. A complex SoC is staggeringly complex — absolutely not something one person built in four months can hold up. That said, AI is of course still evolving fast; I believe the evolution of AI plus vibe-ic will be exponential, and in the foreseeable future it should be able to support advanced process and reach a level comparable to commercial EDA on the functional side.

Reproduce it yourself

I've tried to make this the opposite of a claim you have to take on faith. Everything the flow has run end to end is open-sourced, and wherever I can, I keep every stage's output open — especially for the open-benchmark ICs. (A handful of answers are simply too large to include, and those are the only gaps.)

The practical upshot: anyone who installs the vibe-ic plugin on their own Linux machine with Claude can re-run a benchmark IC and should reach the same tier of result I do — not 100% identical, since some steps are done by an AI and there's natural variation, but the same tier. If I can reach the "production-ready" bar I've claimed, you should be able to reach it locally, on your own bench, and check what I've said. That's the honest form of a claim like this: not "trust me," but "run it yourself and see."

An invitation to the industry — and a risk I have to name first

But first, one thing I have to say clearly, and say three times — and because it matters most, I'm putting it right up front, before the invitation itself:

Please, please, please do not, at this moment, take the GDSII that vibe-ic produces and send it to tape out.

That is an enormous risk. What I'm inviting is the opposite: use the tools to reproduce your own past chips first, and check whether they can produce something at the same tier as what you actually taped out. I'm sure there will be a gap — and closing that gap is exactly the direction I'm working in.

With that said, here is the invitation. If you work in the IC industry and you're willing to run a full end-to-end pass with Claude plus the vibe-ic plugin, I'd genuinely welcome it. The best way to try it: if you have a chip that has already been taped out, together with a complete set of design documents, feed those design documents in as the sole input and let the flow run from end to end. As it runs, cross-check each stage's output against your commercial EDA, and have your own IC-design experts review every stage. I believe that's the only way anyone truly earns the confidence to say whether what comes out is actually tape-out-able.

There is a whole AI-for-EDA scene — and I welcome it

Along the way I also surveyed the field people call "AI for EDA" fairly thoroughly. There are already players in this scene, and I have been following what they publish — ChipAgent, for one, gave me a lot to work with, including some benchmark resources. There is also a cluster of AI-for-EDA startups, most of them founded in just the last couple of years.

Here is what I want to say: what those companies are building does not conflict with what Vibe-IC is trying to be — an open platform. If anything, I genuinely welcome any such startup to become a participant in this ecosystem, in some specific domain or module — even to take this open source and enhance it. And of course, if there is a chance to interact and compare notes so this open flow gets better, that is the best outcome of all, and exactly what I am hoping for.

Feedback, and a project that never clocks off

If you do use it and you're up for it, please send feedback — reach me directly (on Telegram, or LinkedIn), or leave your details on the homepage. All of it is welcome.

This open-source project keeps going, and around the clock there are AI agents watching everyone's feedback and taking problems on themselves — whether it's a bug in an open-source EDA tool or in the vibe-ic plugin, an agent leads the fix. So I expect its progress to keep compounding: on one side the AI itself keeps getting stronger, on the other it's pushed forward by your contributions. An accelerating project that doesn't clock off.

Those tutorial videos were a byproduct of me learning IC design

One more thing worth mentioning. The tutorial videos I've been releasing aren't material I recorded after I'd figured it all out — they're more of an intermediate byproduct. What actually happened is this: Claude taught me, step by step, what IC design even is; as I asked and it explained what each step does and what that pile of acronyms means, I gradually came to understand the flow. The videos are just what that "being taught by an AI" process looked like, captured as it happened. So if you catch me hesitating, or asking a follow-up mid-way in a video, that isn't staged — it's a software person understanding IC design for the first time, through a conversation with an AI.

A short close — the invitation

That's the whole story: an experiment that started in March with more optimism than it deserved, got humbled by a hundred small failures, and turned into a flow I'm finally willing to open even though a quieter voice still says it isn't ready. This preface is me choosing open over perfect.

If you'd like to help make it real, here is where to start.

---

Further reading: the full pipeline is on the Flow page, and the hands-on details are in the Manual.