The business wants to migrate to microservices, but nobody knows how it actually works.

The standard advice is: "Just ask ChatGPT to rewrite it." And if you've ever tried that, you know it usually ends in disaster. The AI tries to copy the old paradigms into a new language, produces non-compilable code, and hallucinates missing dependencies.

So I built a different approach into my open-source project, tommylang: the --decompile flag.

The Idea: Architecture-as-a-Filter

Instead of asking the AI to translate old C# directly to modern Rust or Go, we use tommylang as an intermediate architectural layer.

The workflow looks like this: Legacy C# -> LLM Analysis -> Clean .ty Blueprint -> Modern Code

By forcing the AI to generate a .ty blueprint first, we strip away all the legacy technical debt. The blueprint doesn't care about Task, var, or old DI attributes. It only cares about the architectural intent.

How it works in practice

Let's say you have a legacy file called PaymentService.cs.

You run this command in your terminal:

tommycli PaymentService.cs --decompile --target csharp

Notice the --decompile flag. When tommycli sees this, it completely changes its behavior. It skips the standard AST validation (since the input is C#, not .ty), and sends a specific instruction to the LLM:

"You are a Legacy Code Analyst. Read the provided C# code and extract the pure architectural intent into a .ty blueprint. Remove all language-specific boilerplate. If you see Kafka, add [Kafka]. If you see DB calls, use @db.query."

What the output looks like

The AI will analyze the 500-line spaghetti file and spit out a 20-line Tommy blueprint.

It might look something like this:

[Saga]
[Outbox]
[REST('/api/payments')]
[Auth(oauth2 = 'client_credentials')]
process_payment (@payment_dto request) {
    // AI strips away manual SQL and infers the intent
    @db.query('INSERT INTO payments ...', { id = request.id })
    
    // AI recognizes the event publishing pattern
    [Kafka(topic = 'payment_events')].publish({ id = request.id })
    
    <= ok('Processed')
}

Suddenly, the technical debt is gone. You are left with a clean, language-agnostic architectural blueprint.

The "Killer" Benefit

Once you have this .ty blueprint, the real magic begins.

You can now transpile this clean blueprint into any modern language with a single command:

tommycli payment_service.ty --target rust

Or generate Docker and Kubernetes manifests for it. Or generate compliance traces to prove to auditors that GDPR rules are being followed.

You've essentially used AI to reverse-engineer a legacy system into a modern, maintainable architecture.

Try it out

The --decompile feature is available right now in tommylang. If you are dealing with legacy code and want to see what your architecture actually looks like under the hood, give it a try.

• GitHub: https://github.com/vitalybarkov/tommylang
• VS Code Theme: TommyColor

Let me know in the comments if you've tried reverse-engineering legacy code with AI. What were the biggest challenges?

You spend hours reviewing it, fixing missing dependencies, wiring up DI, and realizing it wrote an insecure SQL query.

I got so frustrated with this that I started asking a different question: What if I don't ask the AI to write code, but ask it to compile a strict architectural blueprint?

That's how tommylang was born.

🏛 What is tommylang?

It's an AI-native DSL with a custom file extension (.ty). You don't write public class UserService or async Task. You write pure intent.

Here is an example of a payment endpoint in Tommy:

[Saga]
[Outbox]
[Idempotent(key = 'order_id')]
[REST('/api/payments')]
[Auth(oauth2 = 'client_credentials')]
create_payment (@order_dto order) {
    ? order.amount <== 0.0 {
        <= bad_request('Amount must be greater than zero')
    }
    
    @db.query('INSERT INTO payments ...', { id = order.id })
    [Event('payment_created')].publish({ id = order.id })
    
    <= created('Payment processed')
}

When you run our CLI (tommycli), it sends this to GPT-4o with a strict System Prompt. The AI doesn't just write code; it generates a <pre-flight> architecture plan, UML diagrams, and idiomatic C#, Rust, or Python.

🚀 The Coolest Features

Here is what makes tommylang different from "just a prompt":

1. Semantic Typography (TommyColor) We designed a custom VS Code theme where color represents architecture, not just syntax. Purple is for logic (if, return), Green is for Classes/Interfaces, Blue is for Functions, and White is for Variables. Code reviews become 10x faster.

2. Built-in Enterprise Patterns You don't need to explain to the AI what a Saga or Circuit Breaker is. You just use [Saga] or [CircuitBreaker]. The prompt forces the AI to generate the exact framework implementations (e.g., MassTransit for C#, or Polly).

3. Polyglot by Design Write once, compile anywhere. Tommy targets C#, Python, Rust, Go, PHP, and TypeScript. Because the blueprint is abstract, the AI doesn't carry over C#-specific boilerplate into Rust.

4. OS-Level & AI-Agents It's not just for web dev. We have annotations for [Ring(0)] (bare-metal Rust #![no_std]) and [Agent] (LangChain / CrewAI integration).

🧠 How it works under the hood

Tommy uses the "prompt-as-compiler" approach. The entire logic lives in a single System Prompt (COMPILER_PROMPT.md). It enforces strict rules: snake_case for functions, = for all data, and : only for logic. If the AI hallucinates, the prompt forces it to fail the AST dry-run.

🛠 Try it out

The project is in early Alpha, but you can test the VS Code theme and the CLI right now.

• VS Code Theme: tommycolor
• GitHub Repo: tommylang

I'd love to hear your thoughts. Is this something you would use for your next microservice, or is it overengineering? Let me know in the comments!

This article was originally published on Dev.to