can you provide some ballpark idea of how much guidance Claude required to understand and ultimately write the compiler pieces?
I know you didn't say it, but let me put it out there:
I don't use "vibe coding," and I’m not a fan of the term. I rather use AI guided programming and use it as a pair-programmer. I do the architecting and design. I use AI to review my plans and reason through both sides—the pros and the cons. I play to AI’s strengths, as it can analyse faster than any human and play through various scenarios.
Not everything was written by AI, either. The parser and tokeniser code both came from the fpGUI IDE project I previously wrote, which I adapted with minimal effort for the Blaise Compiler. AI implemented the thin C wrapper to bootstrap the System and RTL units, as well as the QBE backend.
I have my own Claude skills and rules defined, but I also lean heavily on Garry Tan's `gstack` skills (
https://github.com/garrytan/gstack). It’s a set of 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA. It’s invaluable in getting things right.
AI will pump out code faster than any human, but it is currently weak at software design. I believe humans still have the upper hand there, based on our years of experience and wider context. I also love TDD (Test-Driven Development), but it's not always the most fun thing to write. With AI, there is no excuse not to practice TDD, as it can do the grunt work for you. Without TDD, AI often implements something and then writes tests to prove what it just built. If it interpreted your problem incorrectly, those tests are false positives. I force the AI to write tests first. This gives me a chance to get a feel for how a new API will work and verify that the correct problem is being addressed before anything is implemented.
I’m purposely the bottleneck in the development process because I want to review every line of code. Without this, I’d lose the context of what’s going into the product—which creates a whole new set of problems. I’ve spent a huge amount of AI sessions simply on design and self-learning long before a single line of code was written. A compiler is a different beast entirely. AI also suggested implementing a QBE backend before an LLVM backend. After some research, I realised it was right—the QBE backend is much simpler and helped Blaise reach a self-hosting state much faster. It was about 10% of the effort for 70% of the performance of LLVM (numbers from the QBE website).
AI is also not a "get-everything-done-instantly" button—at least not for a compiler project. About half of my coding sessions so far have been spent hunting down bugs causing the compiler to crash. Each fix often required 30–45 minutes of deep debugging, only to uncover the next crash further down the line. Self-hosting a compiler is no easy feat, and AI doesn't change that fact.
When I say self-hosting, I mean it can compile itself and produce byte-for-byte exact output, but it's still far from a "turnkey" solution. I still require GCC to bootstrap the System unit and RTL C code, and I need FPC to bootstrap the stage-1 compiler so it can build the stage-2 version. Right now, I’m busy stripping out FPC-specific parts from the source so the stage-2 compiler can build purely Blaise-native code. Even then, linking the QBE and assembler code into a final binary is still a manual process. It’s crazy how much I’ve learned in such a short period.
In short, Claude required constant, high-level guidance. It didn't 'build' the compiler; it acted as a highly efficient junior partner that followed my architectural blueprints. By offloading the boilerplate and using it as a sounding board for design decisions, I’ve been able to move at a pace that simply wouldn't have been possible alone—all while keeping full control over the quality of the final binary.
Recent
