First up: my talk Softwaremodernisierung mit GenAI – The Good, the Bad, the Unexpected, given at SIBB // Digitalverband Berlin-Brandenburg in May 2025.

Where do you even begin measuring productivity gains from using Large Language Models (LLMs) in software development? For this short analysis, I’m drawing on data from the talk Does AI Actually Boost Developer Productivity? (Stanford 100k Devs Study) by Yegor Denisov-Blanch. In the study, 136 teams from 27 countries were asked whether they see productivity improvements from using AI (more precisely: LLM-assisted software development).

The following charts are relevant to my exploration of the “what actually matters” factor. I show and interpret them here in this short article.

1. The Context Brake

One of the most interesting findings from the talk is a 2×2 matrix that shows in which situations AI assistance actually delivers a productivity benefit for software developers. Rather than making blanket claims about AI productivity, the matrix breaks the question down along two dimensions: how mature the codebase is, and how complex the task at hand is. The results are more nuanced than the usual promises on the glossy brochures (or websites) of various AI tool vendors would suggest.

My interpretation

The matrix shows that AI productivity gains are highest in greenfield projects with low task complexity, where study participants report a 35–40% increase. The reason is obvious to me: low-complexity tasks are often repetitive and clearly defined, so AI can reliably generate boilerplate-heavy code with minimal risk of error. On top of that, I think we’re in the league of to-do list apps here: programmed a thousand times, and a thousand times nothing further came of it.

However, gains diminish significantly as project maturity increases and/or task complexity rises (i.e., once things get serious):

• In brownfield and legacy projects, gains drop to 15–20% even for simple maintenance tasks, as outdated code and intricate dependencies constrain what AI can safely contribute.
• For high-complexity tasks in systems that already resemble a Big Ball of Mud, gains shrink to just 0–10%, because the AI struggles to reason about tangled architectures, unclear implemented ideas, and deeply nested logic.

This is hardly surprising to me at this point: the underlying training data comes in large part from publicly accessible code repositories. There’s a clear bias in what gets shared: code you wouldn’t be embarrassed about in public (at least that’s how it is for me). The actual mass of code that follows other ideals remains locked away in the closed software systems of enterprises. The first encounter with this kind of code can therefore be disorienting for an LLM, making it harder to adapt familiar patterns from its training data to the existing codebase. Or as Ludwig Wittgenstein said over a hundred years ago:

The limits of my language mean the limits of my world.

But even in ideal greenfield environments, high-complexity work limits AI’s impact to 10–15%, because such tasks demand deeper human judgment that mechanical automation cannot replace. AI can assist, but it cannot yet replace the architectural thinking and contextual judgment that complex engineering and domain knowledge require. This is also related to the limited amount of available context capacity (see also my assessment in “Agentic Software Modernization: Chances and Traps”).

TL;DR: AI delivers the most when the problem is well-scoped and the codebase is clean. High task complexity and legacy code are the two primary productivity killers when using AI — especially in combination (which is likely the reality for most of us).

2. The Niche Penalty

The second chart shifts the lens from project maturity to programming language choice. It turns out that the popularity of the language you work in has a substantial impact on how much an LLM can actually help, driven primarily by how much training data exists for that language.

My interpretation

In popular languages (e.g., Python, Java), LLMs deliver their highest value: productivity gains of 20–25% on simple tasks thanks to abundant training data (e.g., through Reinforcement Learning on thousands of simple question-and-answer pairs), and 10–15% on complex ones. LLMs can still provide good support here, thanks to vast amounts of diverse training data in the respective popular programming language. But even in this best case, complex tasks still require human judgment, meaning AI acts as an accelerator rather than a replacement.

Conversely, niche languages (e.g., COBOL — though that’s already mainstream to me personally) see negligible gains of 0–5% for simple work due to limited training data. For high-complexity tasks, the situation deteriorates further: productivity can actually drop to as low as -5%, as the AI enters a hallucination-prone zone where it confidently produces plausible but incorrect output. This illustrates that without sufficient training data, AI tools can become a liability rather than an asset for complex engineering work. Personally, I don’t see this changing positively in the near future either. It’s also becoming apparent that even actively soliciting code in niche programming languages doesn’t lead to acquiring decent training data (and let’s be honest: which insurance company wants to put its COBOL-written calculation engine on GitHub?).

The underlying driver across all four quadrants is the same: the more training data available for a given language and task type, the more reliably AI can contribute. Language popularity is therefore not just a matter of personal preference but a direct indicator for the more productive use of LLM-assisted software development.

3. Heaven or Hell

For the third chart, I informally combine the mean productivity gains from the two previous 2×2 charts into a third perspective. This shows productivity gains broken down by programming language popularity and project maturity. This perspective is particularly interesting to me because I have a concrete reason for it: I’m partly involved in projects that use programming languages that don’t even make it into the top 50 of the most popular programming languages on the TIOBE Index (https://www.tiobe.com/tiobe-index/), as well as languages that will never appear there because they only exist within a single company. It goes without saying that these are decades-old, massive software systems that are now slowly wanting to be modernized.

Note: This combined view is not a formally validated model but rather a pragmatic thought experiment, blending two independent data sources through simple averaging. It is meant to provide orientation rather than serve as a precise prediction.

Note: I shared a previous version of this chart with numbers in the quadrants on LinkedIn. The numbers have been removed in this version as they could give a misleading impression of precision. I also missed the opportunity to use the right colors for heaven and hell.

My interpretation

When combining both dimensions — project maturity (greenfield vs. brownfield) and programming language popularity — four interesting quadrants emerge. The best-case scenario, “AI Heaven,” occurs when working in a popular language on a greenfield project, yielding the highest productivity gains. This is the ideal state: abundant training data meets a clean, unencumbered codebase. AI can operate at full potential. This is also why vibe coding and prototyping with languages like TypeScript and friends works so brilliantly.

Moving to brownfield projects in popular languages, gains drop noticeably. You’re now paying the bill for letting best practices around code hygiene slide (there’s also an excellent further talk by Yegor Denisov-Blanch on this: “Can you prove AI ROI in Software Eng?”). The LLM still understands the well-known programming language well, but the complexity and technical debt of the existing codebase limit its contribution.

Interestingly, niche languages on greenfield projects still yield meaningful gains, only marginally lower than the legacy code scenario. This suggests that a clean codebase can partially compensate for weaker training data, but the language barrier still sets a meaningful ceiling. My prejudice here is that it’s simply always easier to start on a green field, regardless of the programming language (I still remember the days when people used to say “with Scala / F# we’re just faster,” which even back then left me cold. It gets interesting when you have a mountain of code that goes beyond a to-do list).

The worst-case scenario is “AI Hell”: a niche language combined with a brownfield codebase, producing only minimal gains. Here, both obstacles compound each other. The AI lacks sufficient training data for the language and simultaneously struggles to reason about a tangled legacy codebase — the result is unreliable outputs and a high risk of doing more harm than good.

The key takeaway is that language popularity and project maturity are both independently significant, and their negative effects are additive: each dimension reduces AI productivity on its own, and facing both together pushes gains to the lowest tier. Teams working in niche languages on legacy systems should be especially cautious about over-relying on AI tooling (see for example my article “Software Analytics going crAIzy!”).

PS: Did I mention that I’m a follower of the Boring Software Manifesto and have been preaching for years that everyone should join it? I believe that in the age of agentic software modernization, the manifesto is becoming more relevant than ever before. 😉

If you are interested in the charts, here you can find the Jupyter Notebook that created the images based on the existing data from the talk.

I watched some videos on YouTube (see end of the article), reflected on those and my experience. I think my answer and the answer from experts conducting recent Stanford studies and leading AI engineering firms (such as OpenHands and HumanLayer) is a big YES, but not the way most people think about it.

Simply unleashing AI agents on an old codebase and hoping for a miracle is a recipe for disaster. Successful Agentic Software Modernization requires a fundamental shift in modernization workflows: away from vibe coding towards disciplined preparation and execution.

Based on current findings from the field, here are the essential Do’s and Don’ts for deploying AI agents in software modernization.

The Core Problem: The Context Bottleneck

Before diving into the topic, we must understand the central constraint. AI models (LLMs) are “stateless.” They only know what exists in their current context window.

In complex legacy systems, it is impossible to cram the entire context (millions of lines of code, dependencies, business logic) into this window. When the window becomes too full (according to Dex Horthy of HumanLayer, often above ~40% utilization), the model enters the ‘Dumb Zone’ where response quality degrades rapidly and hallucinations increase.

While approaches like Retrieval-Augmented Generation (RAG) and agentic search (essentially smart use of glob and grep) help with larger datasets, they face a more fundamental problem identified by recent Stanford studies: Entropy. When AI agents work within existing low-quality codebases, the produced code mirrors the low standards of the existing environment (leading to a death spiral).

Consequently, more and more harmful code is produced in a short amount of time, effectively automating the creation of technical debt. The art of Agentic Software Modernization, therefore, must not be about generating more legacy code faster, but about surgically managing the AI agent’s access to the right context to understand and improve the system.

Emerging Practices for Agentic Modernization Workflows

1. Implement a RPI Workflow (Research, Plan, Implement)

The biggest trap is letting the agent code immediately. Instead, the process should be divided into strict phases:

• Phase 1: Research (Understanding): The agent analyzes only the existing codebase to understand how a feature works. The output is not code, but a summary (e.g., a Markdown document) explaining where the relevant logic resides. This is also where you as a developer can participate. Using data-driven approaches like Software Analytics can help to have rigid Data Science Practices in place for analyzing software systems on a large scale. Also, you can enrich the codebase or the summary beforehand to guide an agent through it (e.g., signaling where outdated parts as well as no-go areas are and where code is that fits the current ideas of the software system).

• Phase 2: Plan (Intent Compression): Based on the research, the agent creates a detailed plan of which files need to be changed and how. This plan represents the “compressed intent” of the modification. Personal tip from me: Make sure you scope down those activities. Also: in the best case you can switch from agentic workloads towards rule-based search and replace workloads, letting an agent craft change recipes and execute those deterministically instead of in a non-deterministic way.

• Phase 3: Implement (Coding): Only now does the agent change or write code, based strictly on the approved plan or on your deterministic transformation rules.

Why should you do this? If the plan is non-existent, wrong or too vague, 1,000 lines of generated code are worthless and changed code is tedious to review because of plenty of sloppy code. Therefore, invest human intelligence in reviewing the research and planning steps to create AI and human alignment early on and not just at the end with reviewing the final code.

2. Use Iterative Refinement Techniques for Continuous Feedback

Never attempt a complex migration (e.g., a COBOL file to Java) in a single “One-Shot” prompt. The team at OpenHands demonstrated that this almost always leads to hallucinations.

Instead, use an iterative loop with specialized roles:

• Engineer Agent: Attempts to solve the task (e.g., migrating code).
• Critic Agent: A separate agent that only reads. It analyzes the generated code, runs tests, and provides harsh feedback (scores).

The process runs in loops: The Engineer delivers -> The Critic evaluates and sends feedback back -> The Engineer improves -> Repeat until a quality standard is met.

I’m personally interested in automating as much as possible by providing immediate feedback within the agentic loop. You want to leverage mechanisms like compilation errors, code duplication detection, and architectural violations as key levers to guide the agent mechanically.

3. Invest in “Codebase Hygiene” First

AI is not a magic wand that turns bad code into good code. The Stanford study by Yegor Denisov-Blanch shows a clear correlation: In clean environments (high test coverage, good modularity, typing), AI can autonomously drive a large share of sprint tasks.

In “dirty” environments (high entropy, technical debt), the AI struggles, produces more errors, and can actually accelerate technical debt (the “Rework” trap). Before scaling AI, you must clean up the foundation. This is what we developers have felt for decades: clean code amplified dev productivity, and now AI amplifies those gains.

Personally, I’m a big fan of enriching codebases with more semantic meaning. Renaming cryptic one-letter variables to reflect the actual technical or business domain is a high-leverage move and in many cases a no-brainer. Building out higher level concepts or refactoring towards well-known patterns or idioms is also something I’m very into. Most of those activities are safe refactorings, meaning they usually don’t break the code (unless you’re storing code or class names in the database or using reflection voodoo in Java).

4. Practice Active Context Compaction

When an agent strays off the path, the human impulse is often to correct it within the same chat (“No, do it differently,” “That was wrong”). This is a mistake. Every failed attempt clutters the context window with “noise.”

A better approach is active context compaction (or as I call it: context reset and starting over):

1. Have the agent summarize the current state and findings into a compact file (state.md or the like).
2. Start a completely new chat with a fresh context.
3. Feed only the summary in as the starting point.

This keeps the agent in the “Smart Zone” of its context window.

I actually need to do this for some side projects. There I’m using SOTA models from DeepSeek, Minimax or Moonshot with Claude Code. I find those really refreshing but they are limited regarding the context window. So my workflow needs to use active context compaction and rigid, external management of the current state and the next steps to get good results from these LLMs.

5. Maintain “Traceability Links”

When migrating legacy code (e.g., COBOL to Java), the connection to the original business logic must never be lost. OpenHands recommends that the agent insert comments in the new code that link exactly to the line numbers of the old code where that logic originated. This is essential for future debugging and audits.

When I use, e.g., graph analytics on the whole codebase or create flowcharts for interesting parts of code, I also want to make sure that those results are correct. For this, I use simple line numbers or identifiers or file names in the generated outputs so that I can do a quick check if they are not hallucinated and that I then have something I can work with.

Traps to Avoid

1. Falling into the “Vibe Coding” Trap

“Vibe Coding” describes the back-and-forth chatting with a model, guided more by feelings than by specifications (“Make that prettier,” “No, that feels wrong”). This leads to bloated context windows and confused models. AI Engineering in legacy system environments requires precision, not “vibes.”

So don’t get lost in trying to convince an AI agent to work on legacy code as if it were a greenfield project - the agent sees years of old habits manifested in code and needs different guidance.

2. Underestimating “Rework”

The Stanford studies (listed below) clearly show that while AI tools increase output (more Pull Requests), they often dramatically increase rework: the time developers spend repairing or rewriting AI-generated code. If you only look at speed/volume, you miss the massive cost of quality assurance.

As mentioned above, try to automate as much as possible to get rid of manual work.

3. Rely Blindly on Line-by-Line Code Reviews

In a world where an agent can generate 20,000 lines of TypeScript code in minutes, traditional human line-by-line review is no longer scalable.

Do not rely solely on reviewing the final product. The Hierarchy of Leverage from Dex Horthy states: 1 Bad Line of Plan == 100 Bad Lines of Code. Shift the focus of human review “left”, to the research results and the plan, before the code is even written.

I also like to even go a step further: in the research stage, take a look at how to systematically get to the refactoring spots. If you can then come up with rule-based changes, most of them are then structurally equal over the completed codebases. This means that you don’t have to review line-by-line, but change pattern by change pattern, which is very efficient to do in a short amount of time.

4. Expect Magic in Niche Languages

AI model performance depends heavily on training data. For popular languages (Python, Java, JS), they work excellently. For niche languages or very old dialects (specific COBOL variants, obscure DSLs, and my new favorite one: RPG), using AI can actually decrease productivity according to Stanford data, because the agent hallucinates and the human spends all their time correcting it.

To know beforehand how I have to approach a legacy modernization project, I like to take a look at the corresponding tags on StackOverflow and the TIOBE programming popularity index. Every language that was not under the top 10 in the last few years needs to take a different approach. Maybe a broader reverse engineering towards specs or tests is needed or you even want to use a more traditional transpiler approach that could get the niche language converted to a more popular programming language level that an AI agent then can work with.

Conclusion: From Coder to Architect of Intent

Agentic Software Modernization works, but it requires discipline. The role of the human developer is shifting. We are becoming less writers of syntax and more the architects of the intent.

How I like to look at the current situation regarding agentic coding is that, yes, you could look at AI agents in greenfield projects as overmotivated junior developers, but in legacy systems environments, I like to think of AI agents as new senior developers to your company that can do really amazing things but need decent onboarding: step-by-step introduction to the system, letting them know the background of the existing code and carefully introducing them to the nasty parts of the systems over time.

I think with this image of AI agents and the Do’s and Don’ts from above, we can expect fewer complete disasters using AI Agents to tame complex legacy systems. And remember: Those who just click “Refactor all this” will end up in chaos.

📚 Sources & Further Watching

• Calvin Smith / OpenHands: Refactoring COBOL to Java with Agentic AI with an Iterative Refinement Workflow
  • Topics: Iterative Refinement, Critic Agents, Traceability Links
• Dex Horthy (HumanLayer): Context Engineering SF: Advanced Context Engineering for Agents
  • Topics: Hierarchy of Leverage, 1 Bad Line of Plan vs Code
• Dex Horthy (HumanLayer): No Vibes Allowed: Solving Hard Problems in Complex Codebases
  • Topics: RPI Workflow (Research, Plan, Implement), Context Compaction
• Yegor Denisov-Blanch (Stanford): Can you prove AI ROI in Software Eng? (Stanford 120k Devs Study)
  • Topics: Measuring ROI, The danger of “Rework”, Entropy in codebases
• Yegor Denisov-Blanch (Stanford): Does AI Actually Boost Developer Productivity? (100k Devs Study)
  • Topics: Productivity stats, Niche vs. Popular languages, Codebase Hygiene

I’ve just published a new reference resource: Code Transformation Tools Landscape on GitHub.

What Is It?

A visual guide that maps the ecosystem of code transformation and refactoring tools across two key dimensions:

• Scale & Automation: How fast can we change things?
• Structural & Semantic Understanding: How well do we understand what we are changing?

Why This Matters

Instead of framing tools in a binary “human vs. AI” way, this landscape helps you find the right refactoring approach for your specific context. Whether you need quick text replacements, structural code search, AI-assisted transformations, or semantic refactoring—this guide shows where each tool fits.

Check it out at: github.com/feststelltaste/codetransformationtools

The Challenge

When modernizing large legacy codebases, one of the biggest questions is: where do we start? Monolithic systems can have thousands of programs with complex dependencies. Some code is tightly coupled to the entire system, while other parts might be surprisingly isolated—perfect candidates for incremental migration.

The Approach

RPG Island takes a graph-based approach to this problem:

1. Parse - Extracts dependencies from RPG/SQL source code (fixed-format, free-format, and mixed-mode)
2. Graph - Loads program-to-program calls and program-to-table accesses into Neo4j
3. Cluster - Runs Weakly Connected Components algorithms to find isolated subsystems
4. Summarize - Uses LLM analysis (DeepSeek API) to generate descriptive names and functionality summaries for each island by analyzing the actual source code
5. Explore - Provides interactive visualization and Cypher queries to analyze the results

The idea is simple: if a group of programs only talk to each other and don’t interact with the rest of the codebase, they form an “island” that can potentially be migrated independently. The LLM-powered summarization step helps teams quickly understand what each isolated component cluster is responsible for without manually reading through all the code.

Technology Stack

• Neo4j for graph database and clustering algorithms
• Python for parsing and data processing
• DeepSeek API for AI-powered island summarization and naming
• Jupyter Notebook for interactive analysis
• Docker/Dev Containers for reproducible environment

The tool tracks four relationship types: CALLS (program-to-program), ACCESSES (program-to-table), DEFINED_IN (program-to-file), and PART_OF (nodes-to-islands). Line numbers are captured for each dependency, enabling precise navigation back to the source code.

Current Status

This is a prototype—it uses regex-based parsing and may need customization for real-world codebases with dynamic calls, vendor-specific extensions, or complex ILE concepts. But it’s a starting point for teams looking to understand their legacy system structure before making migration decisions.

Next Steps

I’m interested in testing this approach on more diverse RPG codebases and refining the clustering logic. If you’re working with legacy RPG systems, I’d love to hear your thoughts!

Check out the project on GitHub: feststelltaste/rpgisland

Idiomatic Transpiling solves this by producing code that looks and behaves as if written by a language expert—prioritizing readability, maintainability, and language-specific conventions over strictly literal translation.

This isn’t just about aesthetics. It’s about creating maintainable code that development teams can actually work with long-term.

1. The Concepts Breakdown

To understand the term, it helps to separate the two words:

• Transpiling: The process of converting source code from one language to another (e.g., Java to Python) or one version to another (e.g., ES6 to ES5). Traditional transpilers follow a three-step architecture: parse the source into an Abstract Syntax Tree (AST), transform it to the target AST, and generate output code. Standard transpilers usually care only about functional equivalence—ensuring the code runs the same way, regardless of how the output looks.

• Idiomatic: Following the natural style, distinct grammar, and best practices of a specific language. Code idioms are more than syntax—they’re recognized patterns that experienced developers process as single “chunks,” reducing cognitive load. As research in cognitive science shows, our working memory can only handle 5-9 items simultaneously. Idioms compress complex constructs into single concepts, freeing mental capacity for higher-level problems.

Therefore, Idiomatic Transpiling is:

The automated translation of code where the output utilizes the unique features and “sugar” of the target language, rather than just simulating the logic of the source language. It employs a dual transformation strategy: recognizing and translating complete idioms first, then falling back to construct-by-construct mapping for unrecognized elements.

2. Literal vs. Idiomatic: A Comparison

Imagine you are translating a For Loop from Java to Python.

Source Code (Java)

List<String> names = Arrays.asList("Alice", "Bob");
for (int i = 0; i < names.size(); i++) {
    System.out.println(names.get(i));
}

❌ Literal Transpilation (Non-Idiomatic)

A standard transpiler might prioritize strict logic preservation. It creates code that works, but looks like “Java written in Python.”

# Technically works, but no Python developer writes this.
names = ["Alice", "Bob"]
i = 0
while i < len(names):
    print(names[i])
    i += 1

✅ Idiomatic Transpilation

An idiomatic transpiler understands the intent of the loop and utilizes Python’s iterator protocol.

# Clean, readable, and "Pythonic"
names = ["Alice", "Bob"]
for name in names:
    print(name)

3. Why Does This Matter?

Standard transpilation is often a one-time operation—you treat the output as a binary executable that you never touch. Idiomatic transpilation is different because the output is meant to be maintained by humans.

Code idioms serve two critical functions in modernization:

• Familiarization: Identifying and preserving idioms creates an “interpretation key” that helps developers navigate unfamiliar systems quickly. When migrating legacy code, understanding the original idioms is as important as the syntax.

• Quality Migrations: Without idiom awareness, transpilers produce “Frankenstein code”—mechanically translated output that doesn’t belong in its target language. This creates technical debt from day one.

Practical Benefits:

• Legacy Modernization: If you are migrating a million lines of COBOL to Java, you don’t want the resulting Java to look like COBOL. You want it to look like modern Java so your team can actually work on it.
• Debugging: It is significantly easier to debug code that follows standard conventions than code filled with generated wrapper functions and polyfills.
• Performance: Often, the “idiomatic” way of doing things is also the most optimized path in that specific language (e.g., using Rust’s ownership model correctly vs. trying to force garbage collection patterns into Rust).
• Objective Progress Tracking: By measuring coverage of recognized and translated idioms, teams can quantify migration progress and predict timelines more accurately.

4. Identifying and Translating Idioms

Historically, idiomatic transpiling was incredibly difficult to achieve with rule-based algorithms because it required understanding “intent” rather than just syntax.

Human-Centric Approaches:

• Expert Review: Experienced developers identify common patterns, though they may overlook everyday idioms they take for granted—similar to how native speakers don’t consciously analyze their own language idioms.
• Fresh Perspectives: Junior developers unfamiliar with a codebase can identify unexpected patterns that experts consider “obvious.”

Machine-Centric Approaches:

Algorithmic idiom mining analyzes Abstract Syntax Trees to identify recurring patterns. Modern approaches use:

• Fact-based clustering: Recording boolean properties of AST nodes (method naming conventions, parameter counts, return types), vectorizing them, and clustering to identify pattern families
• Sequence analysis: Identifying statistically significant combinations of statements that reveal idiomatic usage
• Iterative refinement: Treating discovered clusters as pseudo-types for deeper pattern discovery

The AI Revolution:

Generative AI (LLMs) has made idiomatic transpiling significantly more accessible. Modern AI coding assistants act as “Idiomatic Transpilers,” understanding context and intent rather than just syntax. They don’t just translate code—they swap out language-specific libraries for ecosystem alternatives and adjust coding style automatically.

However, AI has limitations in distinguishing between design patterns, code clones, and true idioms without extensive training data on idiom mining. Purpose-built algorithms often provide more reliable pattern recognition for systematic migration projects.

5. Challenges & Limitations

Idiomatic transpiling faces several inherent challenges:

• Context Loss: Complex business logic or domain-specific patterns may not translate perfectly. Idioms carry implicit assumptions about the runtime environment and ecosystem.
• Library Differences: Direct equivalents don’t always exist between ecosystems (e.g., Java’s Spring Framework vs. Node.js Express). Migration requires understanding the target ecosystem’s conventions.
• Testing Required: Transpiled code still needs comprehensive testing—functional equivalence isn’t guaranteed, especially when idioms are reinterpreted for the target language.
• Domain Knowledge: Both source and target language idioms must be understood, along with domain-specific patterns unique to your codebase.
• Pattern Recognition Noise: Algorithmic approaches generate thousands of potential patterns. Distinguishing meaningful idioms from coincidental code clusters requires sophisticated filtering and validation.
• Scale vs. Quality Trade-offs: Hybrid approaches balance idiom-to-idiom translation with construct-to-construct fallbacks to ensure comprehensive coverage while maintaining quality.

Summary Table

Key Takeaway

🎯 Idiomatic transpiling transforms code migration from a one-time conversion into a sustainable modernization strategy—because code that looks native to its language is code that teams can actually maintain.

The combination of algorithmic idiom mining and AI-powered translation creates a powerful toolkit for legacy modernization. By understanding the science behind code idioms—how they reduce cognitive load through chunking—and applying systematic transformation strategies, teams can produce migrations that are both comprehensive and genuinely maintainable.

References & Further Reading

This article draws on insights from:

• “Using Code Idioms to Define Idiomatic Migrations” by Federico Tomassetti (January 2025) - Explores the FactsVector algorithm for idiom mining, the JOBOL problem, and dual transformation strategies for transpilers. Read on tomassetti.me

• “RPG-Encoder: Research on idiomatic code translation and migration patterns” - Academic research on code migration approaches and pattern recognition. View project

The concept of “chunking” and cognitive load in programming is detailed in Felienne Hermans’ The Programmer’s Brain, while pioneering work on idiom mining appears in Allamanis et al.’s Mining Idioms from Source Code (2014).

What You Can Expect

I’ll be writing about:

• Software Analytics & Modernization: How to use data-driven approaches to understand and improve legacy systems
• AI-powered Development: Exploring how generative AI and agentic tools are transforming how we write and evolve software
• Architecture Evolution: Practical strategies for modernizing complex systems without the big rewrite
• Wardley Mapping: Using strategic thinking to guide software evolution decisions
• and many more.

Why an Update?

I moved to Jekyll under the hood which provides a perfect balance of simplicity and power. It allows me to:

• Write in Markdown (my preferred format)
• Version control everything with Git
• Keep the clean, minimal design I love
• Focus on content rather than infrastructure

This also enables me to co-create content using Claude Code on the command line. So hopefully you’ll see plenty of content here on this blog.

The Migration Journey

I started with a single index.html file live coded with Claude Code and then had Claude Code migrate it to Jekyll through some additional prompts.

Stay Tuned

I have several posts in the pipeline about:

• Using AI for legacy system analysis
• Practical patterns for agentic software modernization
• Lessons learned from consulting engagements in modernization projects

You can subscribe to the RSS feed to stay updated.

Thanks for reading!