DEV Community: Marc Newstead

Using AI to Map Legacy Code Without Rewriting Everything

Marc Newstead — Wed, 13 May 2026 16:46:44 +0000

Using AI to Map Legacy Code Without Rewriting Everything

If you've ever inherited a fifteen-year-old Java monolith or been asked to "modernise" a COBOL system that's been running since before you were born, you know the real problem isn't the code itself — it's understanding what the hell it actually does.

The business logic is tribal knowledge. The original developers have long since moved on. The documentation, if it exists at all, is either outdated or actively misleading. And yet, this code is mission-critical.

This is where AI tooling is starting to show genuine value — not by magically rewriting everything (please don't), but by making legacy systems legible enough to modernise incrementally.

The Documentation Gap Is What Actually Kills You

Let's be honest: the blocker on most legacy migrations isn't technical complexity. It's the fact that nobody knows what the code is supposed to do.

You've got thousands of lines of procedural COBOL or deeply nested Java that's been patched and extended for decades. Business rules are embedded in the code itself. There are no tests. The person who understood the invoice calculation logic retired in 2012.

Traditionally, you'd need to:

Reverse-engineer the business logic by reading code
Interview subject matter experts (if they still exist)
Run the system with test data and observe outputs
Document everything manually

This takes months. And it's boring, error-prone work that nobody wants to do.

Enter AI-Assisted Mapping

Modern LLMs (GPT-4, Claude, even specialised models) can:

Parse legacy code and generate plain-English summaries of what functions do
Trace data flows across modules
Identify dependencies and side effects
Suggest which components are safe to decouple

Here's a simple example. You've got a 500-line stored procedure that calculates something financial. You feed it to an LLM:

-- Legacy stored procedure from 2005
CREATE PROCEDURE calculate_customer_discount
  @customer_id INT,
  @order_total DECIMAL(10,2)
AS
BEGIN
  -- 500 lines of nested IF statements
  -- and undocumented business rules
END

You prompt:

"Summarise what this procedure does, list all business rules, and identify external dependencies."

The output won't be perfect, but it gives you a starting point that would've taken hours of manual analysis. You can then:

Validate the summary with a domain expert
Use it as documentation for the replacement service
Identify edge cases that need testing

This approach is already being used across UK enterprises — financial services and public sector teams are documenting legacy systems at a pace that simply wasn't feasible before. For a broader view on how organisations are tackling this, see this pragmatic guide for UK enterprises.

Strangler-Fig with AI: Incremental Wins

The strangler-fig pattern is still the safest way to modernise: you build new services alongside the old system, gradually routing traffic over, until the legacy code can be retired.

AI tools can act as a co-pilot here:

Identify bounded contexts — which chunks of the monolith can be safely extracted?
Generate interface contracts — what inputs and outputs does this component expect?
Scaffold replacement services — create boilerplate for new microservices based on analysed legacy behaviour
Compare outputs — run both old and new implementations in parallel and flag discrepancies

You're not trusting the AI to do the work unsupervised. You're using it to speed up the tedious parts so you can focus on the hard decisions: architecture, trade-offs, risk.

Where AI Breaks Down (and You Still Need Humans)

Let's be clear: LLMs don't understand your business logic. They pattern-match. They hallucinate. They'll confidently give you plausible-sounding nonsense.

Don't use AI for:

Final architectural decisions — a human needs to own that
Validating business-critical logic — always verify with domain experts
Security-sensitive code — treat AI output as untrusted input
Anything without code review — hallucinations are real and dangerous

AI is a documentation accelerator and a mapping tool. It's not a replacement for engineering judgement.

Practical Takeaways

If you're staring down a legacy modernisation project:

Start with documentation, not code replacement — use AI to map what exists before you change anything
Validate everything — treat AI output as a first draft, not gospel
Focus on knowledge capture — the real value is making implicit knowledge explicit
Use AI for boring, repetitive analysis — free up your team to solve actual problems

Legacy systems aren't going away. But with the right tooling and a pragmatic approach, you can make them understandable — and that's half the battle.

If your team is exploring how AI fits into modernisation work, agencies specialising in AI automation and software development can help structure these programmes without the hype.

What's your experience with legacy code and AI tooling? Have you used LLMs to document or analyse old systems? Let's hear it in the comments.

Your AI Copilot Is Steering Your Tech Stack (And You Might Not Have Noticed)

Marc Newstead — Wed, 13 May 2026 16:31:29 +0000

Your AI Copilot Is Steering Your Tech Stack (And You Might Not Have Noticed)

Let's talk about something that's been happening on development teams everywhere, but hardly anyone's discussing openly: AI coding assistants are influencing which languages and frameworks we choose. Not through recommendations or warnings, but through something far more subtle — better autocomplete suggestions.

If you've noticed your team gravitating toward TypeScript over JavaScript, or reaching for well-documented frameworks more often, there's a good chance your AI assistant is quietly pushing you in that direction. Here's what's actually happening and why you should care.

The Autocomplete Bias

AI coding assistants aren't neutral tools. They're trained on massive datasets of public code, and they perform measurably better with some languages than others. TypeScript over JavaScript. Go over Ruby. Frameworks with extensive documentation over newer alternatives.

This isn't about one language being objectively "better" — it's about which languages AI can parse and predict more reliably.

Think about your own experience. When you're working in TypeScript, your AI assistant probably feels almost telepathic — completing entire functions, suggesting the exact pattern you were about to write. Switch to a dynamically-typed language or a less-documented framework, and suddenly it feels… duller. More generic. Less helpful.

That difference in experience creates a feedback loop:

Better suggestions → faster development → positive reinforcement
Weaker suggestions → more manual typing → subtle frustration
Over time, the path of least resistance shifts toward AI-friendly choices

When AI Preferences Become Architectural Decisions

This influence doesn't stop at language choice. It cascades:

Language → Framework → Architecture

When your AI assistant excels at TypeScript, you'll naturally get better suggestions for TypeScript-first frameworks like Next.js or NestJS. The autocomplete for configuration, routing patterns, and common operations will be sharper. You'll ship faster.

Meanwhile, that interesting new framework with sparse documentation? Your AI assistant will be nearly useless. You'll feel like you're coding with one hand tied behind your back.

The result: teams drift toward a narrower range of technologies, not because of deliberate technical evaluation, but because of tooling friction.

The Real Risk Isn't Technical

Here's the uncomfortable bit: for many projects, TypeScript probably is the right choice. The static typing, improved tooling, and reduced runtime errors are genuine benefits.

The risk isn't that AI is quietly deciding your tech stack poorly — it's that you're not deciding at all.

When was the last time your team had a proper discussion about language choice? Can you honestly say you evaluated the trade-offs, or did TypeScript just become the default because "everyone's using it" and it felt better with Copilot?

What You Can Actually Do About It

This isn't a call to abandon AI assistants or reject TypeScript. It's a nudge to make technology decisions deliberately.

Here's what that looks like in practice:

1. Name the Influence

In your next tech stack discussion, explicitly ask: "How much of this preference is driven by better AI assistant support?" Just acknowledging it changes the conversation.

2. Separate Evaluation from Implementation

When assessing a new library or framework, spend time with the documentation and community before diving into code. Don't let autocomplete quality be the primary signal.

3. Track Your Technology Radar

Keep a lightweight register of your tech choices and why you made them. Review it quarterly. Are you actually evaluating alternatives, or has your stack ossified around what your AI assistant knows best?

4. Test Drive Without Assistance

Occasionally try prototyping in a new language or framework with AI assistance disabled. It's uncomfortable, but it recalibrates your sense of what's genuinely difficult versus what just has weak AI support.

The Bigger Picture

For teams working on AI automation and software development, this is doubly important. If you're building AI-assisted tools, you're both influenced by and influencing these patterns.

The future probably involves AI assistants becoming even more capable and more opinionated. That's not inherently bad — but it makes intentional technical decision-making more valuable, not less.

Your Move

Next time you're starting a new project or choosing a framework, pause before reaching for the obvious choice. Ask yourself:

Are we choosing this because it's the best fit for our problem?
Or because our AI assistant makes it feel effortless?

Both can be valid reasons. But you should know which one you're acting on.

The tools are meant to serve your decisions, not make them for you. Keep it that way.