DEV Community

jason rauch
jason rauch

Posted on

How I Built an AI That Translates Code Between 27 Languages (Solo, No Budget)

#buildinpublic #opensource #ai #webdev

Every developer has hit this wall.

You have working code. It does exactly what you need. But it's in the wrong language. Maybe you're migrating a Python service to Go. Maybe a client needs a JavaScript utility rewritten in TypeScript. Maybe you inherited a PHP codebase and the whole team wants out.

So you copy it into ChatGPT and ask it to translate. And it kind of works — until you look closer and realize the imports are wrong, the error handling is missing, and the output would never survive a code review.

That frustration is what led me to build transpiler.us.

What I Actually Built

Transpiler.us is an AI-powered code translator built specifically for this problem. Not a general-purpose chatbot with a translation prompt bolted on — a tool built from the ground up to produce production-quality output across 27 programming languages.

That means real imports. Real error handling. Idiomatic patterns for the target language, not just syntax-swapped source code.

Beyond translation, the platform includes:

  • AI Code Reviewer — structured feedback covering bugs, security, performance, and style
  • GitHub Integration — translate and push directly to any repository via OAuth
  • JSON/YAML Formatter — validate, format, and convert between formats
  • Regex Tester — live pattern matching with named group support
  • CLI Tool — code-translator-ai on npm for terminal and pipeline use

The Stack

I kept it simple because I was building alone:

  • Frontend: React + Vite + TailwindCSS, deployed on Vercel
  • Backend: Express + TypeScript, deployed on Railway
  • AI Model: Llama 3.3 70B via Together AI API
  • Payments: Stripe (credit packs + $20/month Pro subscription)
  • Auth: GitHub OAuth for the repo integration

The AI choice was deliberate. I tested several models and Llama 3.3 70B consistently produced the cleanest translations — especially for less common language pairs like Rust to Zig or COBOL to Java.

What Actually Goes Into a Good Translation

The naive approach is: send the code to an LLM, return the result. That produces garbage 30% of the time.

What actually works is being very specific in the prompt about what "good" means in the target language, and structuring the output so it can be parsed reliably. Here's the actual system prompt used in the translator:

function buildSystemPrompt(
  source: Language,
  target: Language,
  preserveComments: boolean,
  addExplanations: boolean
): string {
  return `You are an expert code translator. Translate code from ${source.name} to ${target.name} accurately.

Rules:
1. Translate faithfully — preserve all logic and behavior
2. Use idiomatic ${target.name} patterns
3. Use appropriate ${target.name} standard library equivalents
4. ${preserveComments ? "Preserve all comments" : "Remove comments unless critical"}
5. ${addExplanations ? "Add brief inline comments explaining non-obvious translations" : "Keep output clean"}
6. Output ONLY the translated code — no markdown fences, no explanations before or after
7. If something cannot be directly translated, add a comment explaining why

After the code, on a new line write "NOTES:" followed by any important notes.
After that, write "WARNINGS:" followed by any potential issues.`;
}
Enter fullscreen mode Exit fullscreen mode

And the response parser that extracts the code, notes, and warnings cleanly:

function parseResponse(rawText: string): TranslationResult {
  const notesSplit = rawText.split(/^NOTES:/m);
  const codeSection = notesSplit[0].trim();
  let notes: string[] = [];
  let warnings: string[] = [];

  if (notesSplit.length > 1) {
    const warnSplit = notesSplit[1].split(/^WARNINGS:/m);
    const notesText = warnSplit[0].trim();
    const warningsText = warnSplit[1]?.trim() ?? "";

    if (notesText && notesText.toLowerCase() !== "none") {
      notes = notesText.split("\n")
        .map((l) => l.replace(/^[-*•]\s*/, "").trim())
        .filter(Boolean);
    }
    if (warningsText && warningsText.toLowerCase() !== "none") {
      warnings = warningsText.split("\n")
        .map((l) => l.replace(/^[-*•]\s*/, "").trim())
        .filter(Boolean);
    }
  }

  const cleaned = codeSection
    .replace(/^```
{% endraw %}
[\w]*\n?/m, "")
    .replace(/\n?
{% raw %}
```$/m, "")
    .trim();

  return { translatedCode: cleaned, notes, warnings };
}
Enter fullscreen mode Exit fullscreen mode

The model runs at temperature: 0.1 — low creativity, high consistency. The structured NOTES/WARNINGS format means the UI can surface important information separately from the code itself without any guesswork.

The difference between a naive "translate this" prompt and this approach is enormous. Output goes from "this kind of works" to "I'd actually commit this."

Building the CLI

One of the best decisions I made was publishing a CLI alongside the web app.

npm install -g code-translator-ai

translate file app.py --from python --to go
Enter fullscreen mode Exit fullscreen mode

Developers spend most of their time in the terminal. A CLI means the tool fits into their existing workflow instead of requiring a context switch to a browser. It also drives organic discovery through npm and developer communities.

The CLI supports batch translation of entire directories, code review, JSON/YAML formatting, and regex testing — the full feature set, accessible from the terminal or piped into a build script.

I licensed it MIT with Commons Clause, which means free to use and modify but not to resell as a commercial service. That keeps it open for developers while protecting the commercial side of the platform.

The GitHub Integration

This was the feature that took the most work but made the biggest difference in how the product felt.

Without GitHub integration, the workflow is: translate on the web → copy the output → switch to your editor → paste → commit. That's four steps where one would do.

With it: translate → select your repo and branch → push. Done.

Getting the OAuth flow right, handling different repo structures, and making the push feel instant took real effort. But developers who try it don't want to go back to copying and pasting.

Revenue Model

Three tiers, all live:

  • Free — 10 translations to try it, no card required
  • Credit packs — one-time purchases for casual users (Starter, Builder, Power)
  • Pro — $20/month for unlimited access to everything

The free tier exists to get people in the door. The credit packs serve developers who need translation occasionally. Pro is for teams and power users who are using it regularly.

What I'd Do Differently

Start with one language pair. I built support for 27 languages on launch. In hindsight, Python → TypeScript alone would have been enough to validate the idea, and I could have added languages based on what users actually asked for.

Ship the CLI earlier. The npm package drives more genuine interest than anything else I've done for distribution. Developers trust tools that live in their terminal.

Don't underestimate the prompt engineering. The quality difference between a naive prompt and a carefully engineered one is significant. I spent more time on prompts than on any other single part of the codebase.

What's Next

The individual developer use case is the wedge. The real opportunity is enterprise code modernization — companies running legacy COBOL, PHP, or Python 2 codebases that need to migrate at scale.

On the roadmap: VS Code extension, team plans, CI/CD integration, and a validation engine that compile-checks translated output.

Try It

If you've ever spent an afternoon manually porting code from one language to another, transpiler.us is built for you.

Free tier includes 10 translations — no card required. Break it, tell me what's wrong, and I'll fix it.

Building in public. Happy to answer anything in the comments.

Top comments (0)