I asked Claude Code to build its own replacement, and it took just 15 minutes

My 3 AM ideas are often a tad bit crazy. Sometimes, I'll randomly get the urge to run a 10K, completely reorganize my room (or buy an apartment), or convince myself that becoming a lawyer is what I'm actually meant to do. Lately, though, my 3 AM ideas have gone from relatively mundane life decisions to increasingly questionable experiments involving AI.

My latest one went something like this: Hey, if I can use Claude Code to build anything I want, I can surely use it to build a Claude Code alternative for me, right? The more I thought about it, the more realistic my initially ridiculous idea began to sound. After all, Claude Code can already build entire applications from a simple prompt, so what exactly was stopping it from building an application that does essentially the same thing? And if it could pull that off, how close would its creation come to the real deal?

So, rather than let this become yet another 3 AM idea I'd completely forget about the next morning, I decided to put it to the test.

Claude Code is already being used to build Claude Code

Claude Code has been building itself for a while now

The reason why I had a bit more faith that this experiment was going to go somewhat well was, ironically, because of the Claude Code team itself. The team, including Claude Code's creator, Boris Cherny, has previously been very vocal about how extensively they use Claude Code to develop the tool itself.

A figure that was previously thrown around a bunch was that Claude wrote approximately 90% of Claude Code's own code. Cherny revealed in December 2025 that 100% of his contributions to Claude Code over the preceding 30 days were written using Claude Code and Opus 4.5. We're talking 259 pull requests, 497 commits, and tens of thousands of lines of code.

In June 2026, in an interview with Fortune, he went on to state that he hadn't manually written code in approximately eight months. Claude Cowork was also reportedly built in just 10 days, though it relied on existing internal tools and prototypes rather than being developed entirely from scratch.

So, if the people behind Claude Code are already using it to build and improve Claude Code, surely asking it to build a competing coding agent couldn't be that far-fetched, right?

I started by giving Claude Code a very detailed prompt

One very detailed prompt to get things rolling

I've done a lot of experiments where I give the same coding agents the same prompts, and something I deliberately do in those tests is keep my starting prompt fairly vague. This helps me see the LLMs' potential, thinking process, and how they approach a task without me having to spell out every little detail.

In this case, though, I knew I had to be a lot more specific about what I wanted. For one, I didn't want Claude Cpde to simply build a wrapper around itself or use Anthropic's Claude Agent SDK to do all the heavy lifting. That would've pretty muych defeated the entire purpose of the experiment.

So, instead of my usual vague prompt, I gave Claude Code a fairly detailed set of requirements. I made it clear that I wasn't expecting a complete, one-to-one replacement for Claude Code. All I wanted was a functional, terminal-based coding agent that could read and modify files, execute commands, run tests, and fix errors on its own.

Beyond that, though, I deliberately left the technical decisions up to Claude Code. I didn't specify which programming language it should use, which libraries to install, or how to structure the application. That was entirely for it to figure out.

Claude Code built XDACode in just 15 minutes

15 minutes later, XDACode was born

For this experiment, I used Fable 5.1, which is Anthropic's most capable generally available model yet. Once I gave Claude Code my prompt, it got straight to work. The first thing it did was settle on the technology stack. It decided to build the entire thing using Python 3, with the official Anthropic SDK for communicating with Claude's models, and Rich and prompt_toolkit for the terminal interface.

More importantly, it decided to implement its own agentic loop instead of relying on an existing coding-agent framework. This is essentially what allows a coding agent to do more than just generate snippets of code. Rather than simply responding to a prompt with some Python code and calling it a day, XDACode can inspect a project, make changes to its files, run commands, check whether those changes worked, and go back and fix things if something goes wrong.

If you're familiar with all the CLI-based coding tools we use nowadays, like Codex, OpenCode, and, of course, Claude Code, that's essentially the core functionality that makes them coding agents rather than ordinary AI chatbots.

Claude Code also built eight tools into XDACode. Seven of these handle file operations, including reading, creating, editing, deleting, and searching through files, while the eighth allows it to execute terminal commands. It also implemented a permissions system, so users can approve or decline changes before they're applied, along with workspace restrictions designed to prevent the agent from modifying files outside the project it's working on.

Beyond that, XDACode came with its own interactive terminal interface, support for follow-up prompts within the same session, and automatic context compaction for longer conversations. The initial version used Anthropic's API to access Claude models, which meant it needed a separate API key rather than simply using my existing Claude subscription.

Claude Code also went the extra mile and also created an automated test suite, built a separate sample project to test XDACode against, and worked through several issues it encountered along the way. These included installation problems, an incorrect exit code during testing, and a couple of glitches with the terminal interface.

By the end of the initial development session, Claude Code reported that all 40 automated tests were passing. It had also demonstrated XDACode's tools against a deliberately buggy sample project, taking it from five failing tests to seven passing ones. Impressively, the entire initial development process took just 15 minutes and 12 seconds. I'm not kidding!

I also wanted XDACode to work with OpenAI

Why limit my coding agent to just Claude?

Now, there was one thing I wasn't particularly happy about with the initial version of XDACode: it only supported Anthropic's API. This meant I needed a separate API key and credits to actually use the tool, despite already having a Claude subscription. While I did run my initial tests using an API key, I didn't want to spend more money on API credits, especially when I was already paying for AI subscriptions.

So, I figured I'd take things a step further and see if I could get XDACode to work with my existing ChatGPT Pro subscription instead. After all, tools like OpenCode already support signing in with a ChatGPT subscription, so I didn't see why my own coding agent couldn't do the same.

So, I figured I'd take things a step further and see if I could get XDACode to work with my existing ChatGPT Pro subscription instead. After all, tools like OpenCode already support signing in with a ChatGPT subscription, so I didn't see why my own coding agent couldn't do the same.

Interestingly enough, Claude Code initially refused to do this. It insisted that using a ChatGPT subscription through a third-party tool was against OpenAI's terms, and instead went ahead and added support for OpenAI's API, which still meant paying separately for API credits.

But as it turns out, OpenAI actually has an official Sign in with ChatGPT integration for eligible open-source and locally hosted applications. So, I went back to Claude Code with a much more specific prompt, this time including links to OpenAI's official documentation and explicitly asking it to follow the supported authentication process.

Sure enough, that did the trick. Claude Code went through the documentation and implemented an OAuth-based authentication system, complete with browser sign-in, secure credential storage, automatic token refreshing, and model discovery. It also added a separate provider using OpenAI's Responses API, while keeping the existing Anthropic and OpenAI API integrations intact.

The entire process took another 10 minutes and 59 seconds, and Claude Code expanded the automated test suite from 40 to 54 passing tests. Admittedly, these were simulated authentication tests rather than a real ChatGPT sign-in, but the functionality was now implemented.

XDACode turned out better than I expected

Claude Code might have created its own competition

Though I did have some faith in myself and Claude Code, the end result ended up being even more impressive than I had anticipated. I began by testing XDACode's initial version with a fairly basic request. I asked it to write bubble sort code for me using Python, along with a few tests to make sure everything worked as intended.

It created a Python file containing the bubble sort function, wrote a separate file with five test cases, and ran the tests to verify that the code worked. All five tests passed, and the entire process required very little intervention from my end, apart from approving the changes it wanted to make.

Now, admittedly, asking a coding agent to write a bubble sort function isn't exactly the most challenging task in the world. But considering that I was using a coding agent that Claude Code had built from scratch in roughly 15 minutes, I was pretty impressed that it could actually write code, create files, and execute tests without running into any major issues.

Of course, I wasn't going to stop at something as basic as bubble sort. I wanted to see how XDACode would handle something a little more ambitious, so I decided to put it to work on a web-based Pomodoro app. I was doing this test in the same directory where XDACode had created the bubble sort files, so the tool's very first step was to read the existing files.

This meant that XDACode was actually examining the project it was working in before making any changes, rather than simply jumping straight into generating code. While the existing files had nothing to do with the Pomodoro app, this was a clear sign that it was working as a proper coding agent.

The Pomodoro timer XDACode ended up building was called Still, and it's exactly what I'd have expected to build with Codex or Claude Code. It had a great UI, did the job well, and was, as a whole, an impressive result. It came with focus, short-break, and long-break timers, customizable durations, a daily progress tracker, and even a task list that saved my progress. There were also smaller touches, like keyboard shortcuts, optional completion sounds, and a responsive layout.

Sure, the credit does go to the underlying model that actually generated the code, but the fact that XDACode was able to coordinate the entire process, create the necessary files, execute tests, and deliver a working application was impressive in its own right. After all, the model is only one part of what makes a coding agent useful. It's the agent's ability to interact with your files, execute commands, and keep working through a task that makes tools like Claude Code so powerful in the first place.

The fact that I was getting a similar experience from a coding agent that Claude Code itself had built in a matter of minutes made the entire experiment feel even more worthwhile.

So, where do we go now?

All in all, this was an incredibly fun experiment, and I'd say it ended up being a pretty successful one, too. I went into this wondering whether Claude Code could actually build a functional alternative to itself, and somehow ended up with a coding agent that I could see myself using.

What excites me even more is the potential this opens up. After all, XDACode is now my own coding agent, and I can essentially mold it to work exactly the way I want it to. If I don't particularly care about something like Plan Mode, I can leave it out entirely. If there's a feature I absolutely love in another coding agent, I can try implementing my own version of it. I could add persistent memory, customize the way it asks for permissions, introduce my own slash commands, or even build an entirely different interface for it!

Of course, that doesn't mean XDACode is suddenly going to replace Claude Code or Codex in my workflow. These are far more mature tools, and there's still plenty XDACode can't do. However, that's not really what I was trying to prove with this experiment in the first place.