Rebuilding Kakaku.com's 30-Year-Old Code With 71 AI Agents

About 8 million lines in C#, plus about 1.6 million lines in Classic ASP. Roughly 9.6 million lines of code in total. 752 repositories (code storehouses), 13,210 database tables, and 1,353 screens. Around 30 years since the company was founded, kept running without a fundamental rebuild.

That is the scale of the system behind Kakaku.com, Japan's largest price-comparison site. The numbers were made public in a talk by Kakaku.com CTO Takayuki Kyowa. And right now, the company is having AI rewrite that 30-year-old giant. The project is called "DODAI" — Debt Of Decades + AI. A name that already signals resolve.

Honestly, the first surprise was that the stack was C# on Windows. They supported a service the size of Kakaku.com for 30 years with their own Windows system, not a pile of SaaS. And then the scale numbers surprised me again. This is debt big enough to justify a decision. Stepping into a full rewrite is the right call.

But the more I read the deck, the more I found both decisions I admired and spots where I thought, "what would I have done here?" I am not trying to criticize. If anything, it is interesting enough that I want to help. So as one working engineer, let me write down what caught my eye.

Rebuilding a 30-year-old system without stopping the service

The first thing to keep in mind is that this is not building new on empty land. Kakaku.com is running at this very moment; there are users, and revenue is coming in. You can't stop it. To use a house analogy, it's like rebuilding while you still live there. There are more constraints than building from scratch, and to swallow those constraints, you sometimes have to add complexity on purpose.

In that light, the decision to keep the existing database (the foundation for the data) as is felt right to me. Rebuild the foundation all at once and the whole house tilts. Keep the foundation, fix the structure on top. A solid order.

On the other hand, keeping the current DB is a choice that's dramatically heavier than "build the ideal from zero." Those 13,210 tables hold 30 years of circumstances. Treating them as the source of truth while only cleaning up the code, and getting to an ideally clean state, is hard work just to imagine. That's exactly why closing the design cleanly in later phases — the deck's Vertical Slices Architecture (a design that slices code vertically by feature; abbreviated VSA) — struck me as a sensible landing.

I've written before about why IT migration in Japan is so hard, in a piece breaking the failures of the Patent Office and Glico into five patterns. Rebuilding a giant system you can't stop is a chain of judgment calls before it is a technical problem. Kakaku.com added a new variable to that: AI.

Why Python? And why did the tied candidates lose?

The new stack is Python, FastAPI (a lightweight Python web framework), and htmx (a way to drive the screen with almost no JavaScript, using HTML). The reasons given are type safety via Pydantic (a Python library that validates data types automatically), good compatibility with AI code generation, and a "just enough" simplicity.

I agree with the selection itself. I feel FastAPI's merits in my own work, and htmx isn't bad either. Keeping the front end light should pay off when you generate code with AI. The weapon they picked is a weapon that lands.

But one thing genuinely nags at me. The deck explains "why we adopted this," but barely touches "why we did not adopt the others." Anyone who has chosen a stack knows the truly interesting column in the comparison table sits next to the winner: "the technology that lost, and how it lost."

Take the backend language. "Python can solve it" implies other options were on the table too. Type safety, async handling of large volumes of simultaneous requests, and compatibility with a layered design like VSA. On those axes alone, Go is quite strong. Concurrency is built into the language, and the typing is firm. I even wrote about choosing Go as my next main language in "Don't pick a language by the 'strongest weapon ranking'", so Go's fit in this area is something I feel in my bones.

Of course, this isn't to say Go was the right answer. If analytics and data work are tightly woven into the service, Python's library ecosystem is overwhelmingly strong. In that case, you could split services physically by responsibility into microservices (small parts that connect to each other) — Python for data, another language for high-load APIs. Precisely because this is the age of AI-written code, if the parts are physically separated and humans nail down the contracts at the seams, you might be able to develop in parallel while keeping quality high. Just off the top of my head, several options seem worth putting on the comparison table.

Handing it to 71 AI agents: the scariest part

DODAI's internals are fascinating too. 71 sub-agents are placed across 5 phases (current-system analysis, design, detailed spec, implementation, acceptance testing) and run autonomously for long stretches. Rebuilding the insurance category reportedly generated about 36,000 lines in 134 hours for $6,921, along with 5,629 E2E tests (automated tests that reproduce a user's actions from start to finish). I tried running a 32-person-scale team with AI myself, so the nerve it takes to throw 71 agents at a real rewrite impresses me.

On top of that, I strongly hope one accident never happens: creating new debt inside a project meant to pay off technical debt. Generating debt while removing debt. It sounds like a joke, but lean on AI too much and it happens for real.

What's scary isn't the flashy failure. It's the moment the AI's suggestion looks plausible enough that you hit Enter with a casual "sure." Because the proposal looks sound, you skip the check. And later, it breaks on an edge case (an exceptional input or situation), and you realize the design is hard to roll back. The weak reversibility (being able to return to the previous state later) never crossed your mind until that moment. This really happens all the time.

More troubling is where knowledge lives. Every workplace has a black box: "only so-and-so understands this feature." Keep hitting Enter carelessly in AI-led development, and you create a state where not even that so-and-so exists. You mass-produce things whose spec is truly understood only by an AI session that no longer exists (the context of that conversation, gone when it closes). Handed down to no one, only the code remains. This is a new kind of debt.

AI's performance gains are genuinely staggering. The speed at which "plausibility" rises is frightening too. But the case where it merely looks like "a comprehensive, best choice was made" is still common. Looks like. So I don't fully buy the line "times have changed, just ship whatever AI writes after a quick check." That's probably the impression of someone whose work only goes that deep. Take it at face value and you'll have an accident. It's continuous with the question of who is responsible when AI-written code breaks.

The turning point may be right around the corner. Even so, for now we still need to not abandon decision-making and to insert human review. Below is the self-check list I use for myself. Even if you're nowhere near Kakaku.com's scale, I think it helps anyone doing AI-assisted development.

By the way, I learned this feel partly by going back to a waterfall-style process with AI once. I wrote about it in "How AI development sent me back to waterfall". DODAI placing 5 phases and quality-evaluation gates reads exactly like a guard against this "over-delegation accident," and that part made me nod.

"Envision optimistically, plan pessimistically, execute optimistically"

The thing in the deck that hit me hardest wasn't about technology. It was this one line, held up as the mindset running through the project.

"Envision optimistically, plan pessimistically, execute optimistically."

I run on exactly the same philosophy, so this resonated strongly. Dream big. Tighten the plan pessimistically, assuming the worst. But once you start moving, commit and proceed optimistically. Whether you can switch between those three modes completely changes the stamina of a long project.

The deck also lined up organizational and mental design: "place the cause in the system, not in people," "don't deny the past," "reviewed the materials nearly 10 times before kickoff." Plainer than the tech-selection talk, but it's exactly this kind of thing that slowly pays off over a long development cycle like rebuilding 30 years. While carrying raw challenges — a monthly AI bill of 4.4 million yen, a move from local to GCP (the cloud) — they're still building an organization that keeps moving forward.

Honestly, whoever designed this and is trying to see it through strikes me as an excellent person to lead an engineering organization. You can argue tech stacks endlessly, but this kind of mental foundation can't be built overnight.

I want to hear the story of the technology that lost — as encouragement

I've laid out honestly what caught my eye. Why did the candidates that looked tied lose? Won't leaning too hard on AI create new debt? But all of this is curiosity, not criticism. If anything, I think it's an interesting enough project that I'd want to help.

Rebuilding 30-year-old code, without stopping the service, together with AI. If this succeeds, it becomes a signpost for the many Japanese systems that "we want to rebuild but can't stop." All the more so since they reportedly have their eye on rolling it out beyond Kakaku.com.

Sources: Rebuilding Kakaku.com with AI-driven development (Takayuki Kyowa / Speaker Deck) / Kakaku.com rolls out the AI editor "Cursor" to all engineers (PR TIMES)