Field Report ③: Architecture study done with a 2-day prototype + real measurements

AI case studies

When moving a legacy system to a new platform, the first step is the architecture study. Done the traditional way, it takes about a month with dedicated staff, and the deliverable is a desk-bound comparison table and rough estimates. The problem is that the correctness of that comparison tablecannot be confirmed by anyone until real development begins. "The architecture we chose didn't actually meet the performance requirements" is usually discovered around the time there is no turning back. For this project, we abandoned that approach.

Build a "working prototype" in 2 days and decide by measuring.

• 1. Analyzing the current system — With an AI agent (Claude Code) we swept through the current screens, features, and permissions, organizing them into a role-based matrix of 14 screens, 45 features, and 527 fields, plus an issue register of 46 items classified by how they'd be handled.
• 2. Building the prototype (2 working days) — Using the architecture under consideration exactly as-is, we built a working prototype of API + demo screens. Its size was about 66,000 lines (about 27,000 lines of API + about 39,000 lines of screens).
• 3. Loading data and measuring — We loaded 10,000 records and measured the response of every API and every screen. "This architecture delivers this speed at this scale" becomes a number.

Because we measured, both the slowdowns and the fixes could be discussed as "facts."

In the first measurement with 10,000 records loaded, some APIs took 22 seconds and screen rendering exceeded 90 seconds. In a desk-bound study you'd be back to square one here, but because we had the real thing, we couldpinpoint what was slow and fix it. From revising the index design to changing access patterns, we applied fixes in four stages and re-measured, with the result that —every API went from 22 seconds to under 3 seconds, and every screen from over 90 seconds to the low single-digit seconds. For single-record retrieval we measured a 600× improvement. Because we locked in the architecture together with these numbers, the worry that "performance might not hold up in production" was resolved along with it.

What "investigation" means is changing.

The essence of this approach is not speed itself.the basis for decisions changes from "guesswork" to "measurement". The desk-bound comparison table becomes a working prototype and measurement data; "it should probably hold up" becomes "this response time at this scale"; and the moment of discovery shifts from mid-development to mid-study (a stage where you can redo it as many times as you like). Prototypes can now be built at a cost you won't mind throwing away. So build first, then decide. The way architecture studies, technology selection, and PoCs are done has been rewritten from the ground up by the arrival of AI agents.

Are you facing the same situation?

"We can't settle on the architecture for the new system." "We can't judge whether the vendor's proposal is sound." "We don't want to spend months on a PoC." That study — why not run it withsomething that works + measured numbers?

Series: "Legacy to AI — Field Reports"

• Overview: 22 systems and 246,000 lines on a single PC — a measured record of 3.5 months of AI development
• Field Report ①: Fully modernizing 20-year-old Java in about a week
• Field Report ②: Adding a new entry point to a core system with zero lines of existing code changed
• Field Report ③: A month-scale architecture study, done with a 2-day prototype + real measurements (this article)

* The figures in this article are measured values as of the end of July 2026. Development outcomes vary depending on the state and requirements of the system.