We Built an Entire Product with AI. 750+ Pull Requests. Zero Lines Written by a Human.

Seven hundred and fifty-three pull requests. Four programming languages. Forty-five days. Every single line of code written by AI. Not a demo. Not a prototype. A production app my entire engineering team uses daily.

I didn't write a single line. Not one function, not one component, not one config file. I directed AI agents, reviewed their output, and shipped a real product. Forty-five days from first commit to finished.

I've been building software for over twenty years. I co-founded KnowBe4, which became the world's largest cybersecurity awareness platform. We IPO'd in 2021. A year later, Vista Equity Partners acquired it for $4.6 billion. I've built products used by tens of thousands of organizations worldwide. So when I tell you AI just mass-shifted what one person can build, I'm not theorizing. I just did it.

It started with frustration. The AI coding tool I relied on wasn't evolving. Feedback went unanswered. Features I needed never materialized. So I did what engineers do when their tools fail them: I built my own.

But this story isn't about why I started. It's about what happened next.

What "100% AI-written" actually means

I want to be really precise here, because people hear "AI-built" and assume different things.

I didn't use AI as a coding assistant. I didn't pair-program with Claude. I didn't write functions and ask it to review them. I never opened a source file and typed code into it. Not once in forty-five days. Some people call this vibe coding -- directing AI agents instead of writing code yourself. But this wasn't vibes. This was architecture, product management, and code review at scale.

Every line of Go. Every React component. Every Rust module. Every TypeScript function. Every CSS rule, every test, every config file. Claude wrote all of it.

What did I do? I was the architect. The product manager. The reviewer. I described what I wanted built. I looked at what the agent produced. I approved or rejected pull requests. I pointed the next session at the next problem. My job was vision and judgment, not keystrokes.

The first commit landed on January 17th. Seven hundred and fifty-three pull requests later, ChatML is a real product: a native macOS app built with Tauri 2 instead of Electron, four programming languages deep, with real-time streaming, git worktree orchestration, encrypted credentials, GitHub integration, an AI code review system, and a skills framework. Every byte written by AI software development, shipped in forty-five days.

This isn't about replacing developers

If you read that last section and thought "so AI is coming for our jobs," you've missed the point entirely.

This is about what happens when an experienced engineer stops typing and starts directing. When you take two decades of architectural instincts, product sense, and hard-won judgment and channel it purely into decisions (reviewing, guiding, approving) rather than into keystrokes.

Claude's code isn't perfect. I've rejected PRs. I've sent plenty back for rewrites. I've killed entire approaches that were heading somewhere wrong. That's exactly the point. The agent makes mistakes the way a talented but inexperienced engineer makes mistakes. The difference? This particular engineer works twenty hours a day, never gets annoyed when you ask for a third revision, and can context-switch between Go, Rust, TypeScript, and React without batting an eye.

What matters now isn't whether you can write a function. It's whether you can evaluate one. Whether you can watch an architecture take shape across a dozen pull requests and sense that it's heading somewhere coherent, or that it isn't. Whether you can read a diff and catch the subtle issue the agent missed.

Honestly? That's always been what senior engineering is. The coding was just the delivery mechanism. Now the delivery mechanism has been automated.

What 45 days and 750 pull requests actually looks like

Here's how a typical day worked during the build.

I'd open ChatML (once it was far enough along to orchestrate its own development, yeah, ChatML built itself, more on that in a minute) and spin up sessions. "Implement the WebSocket streaming pipeline." "Add encrypted credential storage using the macOS keychain." "Build the diff visualization component." "Write the git worktree lifecycle manager."

Each session spins up a Claude agent in its own isolated git worktree, a completely separate copy of the working directory. The agent writes code, runs tests, iterates. When it's done, I review the PR. Sometimes I approve right away. Sometimes I push back with comments. Sometimes I throw out the whole approach and describe a different one.

Then I'd create more sessions. More tasks, more parallel streams. While three agents are building features, I'm reviewing the output of the two that just finished. It's a pipeline. I'm never blocked, never waiting. The bottleneck shifts from "the computer is working" to "how fast can I review."

On a good day I'd merge fifteen to twenty PRs. Some small: a bug fix, a styling tweak, a test. Some massive: the entire session orchestration layer, the real-time streaming architecture, the complete skills framework.

Add it up across forty-five days: 750+ merged pull requests. A complete product. Built by AI, directed by a human, and now used daily by my entire engineering team at Readingminds.ai.

The product AI built

Let me show you what came out the other side. Because the interesting thing about this experiment isn't just that AI wrote the code, it's what that code actually does.

Parallel sessions with isolated worktrees. This is the core. You create a session, ChatML creates a git worktree and a dedicated branch, and a Claude agent starts working inside it. Create another session: another worktree, another branch, another agent. They run simultaneously and can't interfere with each other. It's how teams of human engineers already work, applied to AI agents.

Real-time diff visualization. You can watch every file change as it happens. Not after the agent finishes, but while it's working. You see what it's writing, what it's deleting, what it's modifying, live. If something looks wrong, you catch it immediately instead of discovering it in review.

AI code review with inline comments. Point the agent at a diff or a PR and it gives you line-by-line feedback. Not generic stuff. It reads the context, understands the intent, and leaves comments where they actually matter. We have three review depths: quick, deep, and security-focused.

Built-in terminal per session. Every session has its own terminal scoped to its worktree. Run tests, install dependencies, inspect output, all without leaving the app or accidentally running commands in the wrong directory.

PR workflow. Review diffs, approve changes, create pull requests, all from inside ChatML. Connect your GitHub account once and you stop bouncing between browser tabs. The whole flow from "agent finished" to "PR opened" takes seconds.

Keyboard-first interface. Command palette, customizable shortcuts, fast navigation between sessions. If you're the kind of person who hates reaching for the mouse, this was built for you.

All of this, every component, every backend service, every pixel, was written by Claude agents running inside ChatML sessions. The tool built itself.

ChatML built ChatML

The irony isn't lost on me. I built an AI coding orchestrator using AI coding.

About fifty pull requests in, the core session management and worktree isolation were solid enough to use. So I started using ChatML as the primary development environment for... ChatML. The tool was building itself, bootstrapping its own features.

That recursion was more than philosophically interesting. It was the tightest product feedback loop I've ever experienced. Every friction point, every missing feature, every UX annoyance, I felt it immediately because I was living inside the product eight hours a day. No customer interviews needed. No user research surveys. Just me, using the thing, knowing exactly what it needed next.

In twenty years of building software, this was the most effective product development cycle I've experienced. And I wasn't writing code. I was reviewing it.

Why I open-sourced it

I could have kept this proprietary. The code works. The product ships. A VC pitch deck that says "750 PRs, 100% AI-written, built by the co-founder of a $4.6B company" would generate meetings.

But think about why ChatML exists in the first place. I built it because the tool I depended on failed me. Because a closed-source product with no accountability ghosted its users. If I turn around and build another closed-source product with the same dynamics, I've become the thing I was frustrated with.

Developers deserve tools they can inspect, modify, and fix themselves. Tools where, if the maintainer goes silent, you can fork the repo and keep going. That's not a nice-to-have. That's table stakes.

ChatML is GPL-3.0 licensed. The entire codebase. No enterprise tier. No features behind a paywall. No asterisks. Copyleft means it stays that way. Nobody can take the community's work, close the source, and sell it back to you.

My entire team at Readingminds.ai uses this tool every day to build a real product. It's good enough for your team too.

What forty-five days taught me

Here's what I know after building a complete product without writing a line of code:

AI can build production software. Not weekend projects. Not demos. Production software that a team relies on daily. The code is reviewable, testable, and maintainable. If you're still skeptical, I have 750+ pull requests you can read for yourself.

The architect role is where the leverage is. The most valuable position in software development is shifting from "who writes the best code" to "who decomposes problems the best, evaluates output the fastest, and steers direction the clearest." This is what staff and principal engineers have always done. The difference is that now the team they're directing includes agents that work around the clock.

Parallel changes everything. Sequential AI development (one task, wait, review, repeat) is painfully slow. Running four or five sessions at once, reviewing as they complete, spinning up the next batch? Completely different experience. Not a percentage improvement. A category change. We documented the five workflows that actually work if you want to see what this looks like in practice.

Open source is non-negotiable. If the tool you depend on can go dark, go proprietary, or just stop answering emails, your workflow is hostage. Real open source with copyleft protection is the only honest answer for developer tools.

Unanswered emails create competitors. The tool I was using had every advantage. Existing product, existing users, head start. They lost a user and gained a GPL-3.0 licensed competitor because nobody replied to a feedback email. Let that sink in.

The ask

I'm not here to sell you anything. I'm not raising a round. ChatML is free, open source, and built in the open.

What I need is visibility.

ChatML is on GitHub. If you believe AI-built, open-source developer tools are the future, if any part of this story resonates, go to the repo and hit the star button. One click.

Stars are how open source projects get discovered. How engineers find tools. How a project goes from "some repo" to "something worth paying attention to." Every star tells the next developer this project is worth their time.

I'm not asking you to trust me. I'm asking you to look at the code. Read the commit history. See what 750+ AI-authored pull requests produce. Then decide for yourself.

If you've ever sat waiting for a coding agent to finish so you could start your next task, download ChatML and try it on a real project. Break it. File issues. Tell us what sucks.

And if the story of one engineer, frustrated by silence, who built an entire product with AI in forty-five days and open-sourced it on principle, if that's worth sharing, then share it.

The code is open. The code stays open.

Star ChatML on GitHub →