[Case Study Enthusiast] Vol. 1 Siemens — Modernizing hundreds of millions of lines of legacy code by "carving up the elephant" / Article score: 7.5/10

I am an old guy who usually writes case study articles. Because I am a creator, I cannot help but be curious about the case studies of other companies. From time to time, I will score them out of 10 points (Criteria → Vol. 0).

Today, for our first installment, we start with a big one, and it is a so-close-yet-so-far piece. Siemens (a global giant in industrial software). A case study that also used Claude Code, featured on the Google Cloud blog.

What was done in this case: Over 10 years and hundreds of millions of lines of legacy code, with the necessary knowledge scattered across the code itself, issue tickets, internal wikis, and PDF manuals scanned in the 2000s. No one can grasp the whole picture of where everything is anymore. Siemens reportedly conquered this monster with a "Knowledge Fabric."

The key point is the realization that code is not just text, but has a structure like a map.

Usually, when making AI read a large amount of documents, one uses a method of breaking everything into small pieces and "searching for things with similar meanings" (vector search). However, with this, the information about connections, such as "this class is in this file" or "this function is connected to that function," disappears.

So, Siemens rebuilt the code like a subway map (Spanner Graph). They mapped out "which code is related to which code" like a subway map. That is why they can accurately answer questions like "If I change the logic of this screen, which functions should I fix?", including the scope of impact.

Another ingenious approach is "carving up the elephant," which is also the eye-catcher. It seems AI is not good at large, vague orders like "rebuild this module entirely." Therefore, they broke down the parts that make up the giant elephant. They divided large tasks into smaller ones and assigned them to five specialized agents (research, requirements gathering, impact prediction, task decomposition, and implementation). And to ensure quality, they made sure humans were involved in every step of the process.

It is an amazing case study, but let's score it as an article.

First, the wonderful part is the technology. The insight that code has structure and is mutually related, making RAG (using it like a dictionary) insufficient, is something many engineers have likely felt vaguely, isn't it? Carving up the giant elephant is also beautiful.

So, why 7.5? The culprit is quantitative results. In this case, the description of the results is like this—"dependency analysis was significantly shortened from days," "coding work was reduced." ... How many days became how many hours? What percentage was reduced? There is not a single number. If it were Google, I would have wanted them to show indicators and quantitative evaluations. Since the scale and technology are both excellent, the missed opportunity is explosive.

Also, personally, I was curious about the combined use of Anthropic x Google, but I didn't quite understand how Claude Code was used. Well, it's a Google case study so it can't be helped, but as a Claude fan, I was curious.

Now, for those who want to create case study articles—everyone wants to talk about the greatness of the technology and the greatness of the service provided. In addition to that, if you show numerical values, the reader should feel more familiar with it. Instead of "significantly shortened," if it said "a few days became 30 minutes," the consideration for introducing that technology or service would likely take a step forward.

Modernizing legacy code is a job of moving a giant elephant. The Siemens case study even showed us how to carve up the elephant. I just wish they had measured and shown the weight and speed.

Next time, I will score a similar giant elephant case study that shows numerical values.

Related article "Let's create case study articles" series

The person writing this article is