27 プログラミング言語間でコードを翻訳する AI を 1 人でゼロコストで構築した話

すべての開発者はこの壁に直面したことがあるでしょう。 あなたが作成したコードは完璧に動作しますが、それは間違った言語である可能性があります。Python サービスを Go に移行しているかもしれません。クライアントが TypeScript へのリファクタリングを求めているかもしれません。あるいは、PHP コードベースを引き継ぎ、チーム全員が乗り換えたいのかもしれません。 そこで、あなたは ChatGPT にコピーして翻訳を依頼します。それはある程度機能しますが——近視くと、インポートが間違っている、エラーハンドリングが抜けている、そしてコードレビューを生き残ることはありません——というのを理解します。 その挫折感から、私は transpiler.us を構築することになりました。 transpiler.us は、この特定の課題のために構築された AI ドライバされたコード翻訳ツールです。単に翻訳プロンプトを結合した一般的なチャットボットではなく、27 のプログラミング言語間でプロダクション品質の出力を生成するために地から建てられたツールです。 つまり、本物のインポート。本物のエラーハンドリング。そしてターゲット言語にふさわしいパターン、単なる構文交換されたソースコードではなく。 翻訳を超えて、このプラットフォームには以下の機能が含まれています： AI コードレビュー——バグ、セキュリティ、パフォーマンス、スタイルを網羅した構造化されたフィードバック GitHub インテグレーション——OAuth を使用して、いかなるリポジトリにも直接翻訳とプッシュ JSON/YAML フォーマッター——検証、フォーマット化、形式間の変換 Regex テスター——ネームドグループサポート付きのライブパターン一致 CLI ツール——npm 上の code-translator-ai でターミナルとパイプライン用途 私が 1 人で構築しているため、シンプルさを保ちました： フロントエンド：React + Vite + TailwindCSS、Vercel でデプロイ バックエンド：Express + TypeScript、Railway でデプロイ AI モデル：Together AI API を介した Llama 3.3 70B 決済：Stripe（クレジットパック＋月額$20 の Pro サブスクリプション） 認証：リポジトリ統合用の GitHub OAuth AI の選択は故意でした。私はいくつかのモデルをテストし、Llama 3.3 70B は特に Rust から Zig や COBOL から Java へのように一般的な言語ペアの翻訳において、最もクリーンな翻訳を一致させました。 直感に頼るアプローチは：コードを LLM に送り、結果を返すことです。それは 30% の頻度でゴミを生み出します。 実際には機能するのは、ターゲット言語における「良い」ということについて非常に具体的にするプロンプトを与え、出力を構造化してそれが信頼してパースされるようにすることです。ここで翻訳機で使用されている実際のプロンプトシステムが示されています： function buildSystemPrompt( source: Language, target: Language, preserveComments: boolean, addExplanations: boolean ): string { return `あなたは専門的なコード翻訳者です。${source.name} から${target.name} に正確にコードを翻訳してください。 ルール: 1. 忠実に翻訳——すべてのロジックと動作を保持 2. ${target.name} の習慣的なパターンを使用 3. ${target.name} の標準ライブラリの等価物を使用 4. ${preserveComments ? "すべてのコメントを保持する" : "重要なもの以外のコメントを削除する"} 5. ${addExplanations ? "直感的でない翻訳について簡潔なインラインコメントを追加する" : "出力をクリーンに保つ"} 6. 出力は翻訳されたコードのみ——マークダウンの囲み、またはその前後の説明なし 7. 直接翻訳できないことがあれば、その理由を説明するコメントを追加 コードの後に、新しい行で"NOTES:"と書かれ、その後、重要なメモを続けてください。 その後、"WARNINGS:"と書かれ、潜在的問題を続けてください。`; } そして、コード、メモ、警告をクリーンに抽出するレスポンスパーサーが示されています： 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 .re

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. 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 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. 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.`; } 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 }; } 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." 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 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. 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. 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. 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. 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. If you've ever spent an afternoon manually porting code from one language to another, transpiler.us is built for you. Web app: transpiler.us CLI: npm install -g code-translator-ai GitHub: Jeah84/transpiler-app 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.