What started as TNO-ESI research into analyzing and transforming sprawling software codebases has grown into a commercial software modernization offering from Capgemini. Generative AI is now opening up new opportunities.
“Software modernization usually isn’t a core activity for high-tech companies,” notes Niels Brouwers, solution architect for augmented software engineering at Capgemini. “Their core activity is to create new microscopes, new wafer scanners or new image-guided therapy systems.” Keeping decades-old software up to date is essential, but as Brouwers puts it, “software modernization often is just a burden for them.”
That problem was the starting point for Renaissance, technology developed at TNO-ESI to analyze large software systems and perform automated transformations. Early work included a project at Thermo Fisher Scientific aimed at untangling build dependencies. Later projects with other ESI research partners, including Philips and VDL ETG, broadened its use from analysis to large-scale code cleanup, refactoring and architectural checks.
At the heart of Renaissance are parsers, static analysis and a configurable graph-based representation that integrates software information across multiple abstraction levels. “This ranges from directories, files, classes and functions to libraries, executables, interfaces and architectural components,” explains Rosilde Corvino, senior research fellow at TNO-ESI and technical lead of several projects based on the technology. “Every night, Renaissance extracts this information and combines it in a graph representing the software system.”
This system view not only provides better insight, but it also speeds up analysis and enables automated software transformations. Engineers can identify a recurring pattern in the graph and use Renaissance to locate and transform occurrences throughout a codebase. The economics become particularly attractive when a relatively simple modification has to be repeated hundreds or thousands of times.
VDL ETG provided an early example. The company’s software stack contained support for hardware that was no longer present, creating unnecessary maintenance work. Renaissance was used to investigate cleaning up the code and to address large numbers of warnings reported by Tiobe tooling. “You have to clean up the code then in hundreds, maybe thousands of files, which is typically very effort-intensive if you want to do that manually,” says Jos Hegge, who represents TNO-ESI’s tooling in bringing research results into industrial applications and also manages several of its projects.
Progressive automation
Industrial experience also exposed a weakness: Renaissance was powerful but difficult to use. “Engineers had to understand its database schema, its query language and the internal representation produced by its parsers,” Corvino illustrates. “There was a very steep learning curve.” TNO-ESI and its partners experimented with training developers and architects to use the technology themselves. The conclusion was that specialist teams could make more economic sense.
Capgemini reached a similar verdict from its industrial work. “Pushing these technologies doesn’t work,” adds Brouwers. “They’re too complicated, too generic. They need too much tailoring to the customer’s environment.” Renaissance also pays off primarily when transformations can be performed at sufficient scale to outweigh the investment in setting them up.
That insight helped shape the Genie team at Philips’ Image Guided Therapy Systems organization. Instead of turning every engineer there into a Renaissance expert, a small group from Capgemini specialized in software modernization. One of its first assignments was replacing Philips’ proprietary test framework with the industry-standard Google Test.
The scale was considerable: More than 9,000 test cases had to be migrated. The team built on automated transformations developed by TNO-ESI, processing the test migrations in batches and progressively improving the automation as new corner cases appeared. “You start with an initial automation that covers a subset of the automation capabilities that you need,” explains Brouwers. “Then, using those automations, you take the first batches of test cases to migrate, after which you gradually increase the automation.”
At some point, further development stops making economic sense, Brouwers goes on to clarify. “Sometimes, it’s just better to do it by hand. When it’s cheaper and if it isn’t a repeatable pattern that you expect in the future, you can leave out the automation and do it manually.” For the Philips test migration, Brouwers estimates 90-95 percent was automated.
The work at Philips subsequently expanded from one-off migrations to continuously checking and repairing code as developers change it. The company’s codebase was already being analyzed with tools including Tiobe’s TICS and Coverity. But finding a violation and fixing it are separate steps. Traditionally, Brouwers notes, issues may be detected in a quality build after the software has been delivered, creating a longer feedback loop before the finding reaches the responsible developer.
For a subset of the coding and software quality rules checked by TICS and Coverity, the team therefore developed automated fixes based on Renaissance technology and moved them into the pull request process. When the build detects a supported violation in newly submitted code, it doesn’t merely report what’s wrong; it also generates a suggested code change for the developer to review. “If we have a fix, we can automatically propose it,” elaborates Brouwers. “The developer gets a code suggestion and can interactively accept or reject it.”
The approach shifts remediation left, bringing it closer to the moment at which code is written rather than treating quality issues as a later cleanup exercise. By integrating both detection and suggested fixes into the pull request, selected violations can be resolved as part of the regular delivery workflow. Brouwers: “Moreover, we have automated fixing of violations in the IDE, which is a shift even further to the left.”
Renaissance is also used for architectural checks. The underlying code graph can be refreshed from the latest software so that dependencies and architecture can be analyzed. That allows engineers, for example, to detect unused dependencies or verify whether software layers obey rules specifying which layers may call which others.
Modernizing the modernizer
As an implementation partner of TNO-ESI, Capgemini is responsible for transferring the applied research to the industry. Under the name Reborn, it has built on Renaissance with elements such as an IDE, CI/CD integration and domain-specific tooling.
The relationship has now evolved into a commercial agreement. Capgemini provides three services based on Renaissance technology, reflecting the successful transfer of applied research into industrial practice. One offering focuses on fixing TICS issues in bulk across complete code repositories. A second turns the automated repair approach developed in industrial projects into a “refactor bot” that can be installed in a customer’s IDE or CI/CD environment. When supported violations are introduced, developers receive both the warning and a proposed code change, which they can accept or reject before merging their work.
The third offering is a flexible “Debtzero” team for broader and more evolved software architecture and technology rejuvenation assignments. It enters a company, investigates a modernization problem with resident experts, configures the appropriate technology and demonstrates the approach on part of the codebase. “We’re not pushing technologies; we’re delivering a service,” says Brouwers. “The value is that we unburden companies from doing those software modernization tasks themselves. Our approach is also faster and delivers better quality compared to doing everything manually.”
The arrangement between TNO-ESI and Capgemini is more than a conventional technology license. Improvements made during industrialization flow back into the core technology. Conversely, problems encountered in customer projects can become topics for new applied research. “In a shared-code fashion, we develop both Renaissance, but also the parts that Capgemini built on top of it,” ESI’s Hegge points out.
Renaissance hasn’t escaped the challenge it was created to address. “Actually, we got hit ourselves by the legacy problem,” says Corvino. The original implementation relied on Eclipse’s CDT parser, which wasn’t keeping pace with newer C++ versions. TNO-ESI and Capgemini therefore started developing Renaissance.Py, a Python-based successor designed to make it easier to add and replace parsers.
Clang was chosen to provide C++ parsing, while the partners have also explored Tree-sitter, which supports many programming languages, and added Python support. “How do we get rid of the legacy and how do we make it so our tool is more easily adaptable to new environments and new languages?” Corvino summarizes the effort. Multi-language analysis remains a research topic, particularly for understanding relationships crossing language boundaries in large systems.
Cooperation with LLMs
Meanwhile, the rise of generative AI has changed the context in which Renaissance operates. When large language models emerged as coding tools, an obvious question was whether they were going to replace the parser technology in code analysis and refactoring. Corvino: “The answer we found was: not yet.”
Instead, TNO-ESI found that Renaissance could provide factual system information to an LLM. A model can explain a function or reason about code placed in its context, but questions about an entire industrial software system can require reliable information spanning repositories and abstraction levels. “We can use static analysis and specifically the Renaissance code graph to ground answers that LLMs can give about the code,” says Corvino.
The difference becomes particularly clear with quantitative or system-level questions. “For instance, determining which function is called by the largest number of other functions requires counting incoming call relations in the code graph,” Corvino explains. Renaissance can retrieve that information deterministically, after which an LLM can elaborate on what the function does and how it’s used.
Brouwers points to a recent industrial project in which Renaissance data was fed into agentic AI for architectural analysis and restructuring. The difference, he says, was the grounding provided by the code graph. “If you don’t have this data, the generative AI will do a lot more hallucination and produce incorrect outcomes. If you feed it the right information from the knowledge base, the graph, you see that it gives very good results.”
TNO-ESI is also investigating how information extracted from the Renaissance code graph, combined with execution trace analysis, can support reconstructing selected SysML views of existing software systems. These can then be linked to an LLM-based assistant, allowing engineers to query the system architecture and explore potential design improvements.
Generative AI could lower Renaissance’s usability barrier. Building and tailoring an accurate code graph for a particular industrial system remains specialized work. “However, once that foundation is in place, engineers could increasingly interact with the underlying knowledge through natural language instead of learning a specialized query language and database schema,” Corvino notes.
The arrival of generative AI hasn’t displaced the foundation. Instead, it has created another possible interface to the structured software knowledge Renaissance has accumulated. “They don’t compete; they gain from each other,” concludes Hegge. “We really see the cooperation between LLMs and Renaissance as a major strong point.”
This article was written in close collaboration with TNO-ESI and Capgemini Engineering.
