検証可能なAIによるレガシーコード移植プラットフォーム
COBOL、Java、TS、Pythonなどのコード移植を、「それっぽい」ではなく機械的に検証された動作等価性の証明とともに出荷する。
Claude Code や Cursor などのコーディングエージェントにそのまま貼れる概要（英語）です。
総合6.5/10
課題の深刻さ7
支払い意欲7
タイミング7
市場の空白6
参入障壁6
実現性5
賛成
- 誰が払うか
- 大規模なレガシーコードベースを抱える企業（銀行、保険、100万行超のSaaSなど）のVP Engineering、またはプラットフォーム近代化の責任者。今はコンサルティング会社に流れている15万〜100万ドルの移行予算が対象。
- 議論での声 · 5
- フロンティアモデルは数日で大規模な言語移植ができるようになり、エコシステムにはすでに「slopfork」、忠実な移植版、TypeScriptの再設計版が存在する。差別化要因は忠実性である。 記事から ↗
- ヘビーユーザーのエージェント利用者は、コーディングエージェントが不健全なアーキテクチャ判断を下すため、AIの出力を依然として手動でレビューしている。また、大規模コードベースには既存ツールが対応しきれなくなると指摘している。 コメントを読む ↗
- AI支援によるTypeScriptの独立した移植版が3つ（tsrs、tsgo-rs、bun check）すでに存在し、移植需要と断片化を示している。 コメントを読む ↗
- コメント投稿者は同じAI移植アプローチがCPythonで試されたかどうかを問題にしており、TypeScript以外への関心があることを示している。 コメントを読む ↗
- ある個人開発者はAIを使ってTypeScriptをC#に約75ドルで移植した。移植コストが崩壊したことは示しているが、正しさの保証は付いていない。 コメントを読む ↗
議論の内容を要約したものです。元のコメントはリンクからどうぞ。
- 競合と空白
既存の参加者は、ルールベースの決定論的リファクタリングを行うか、人によるコンサルティング工数を売るかのどちらかである。モデルが生成した移植コードが元のコードと動作的に等価であることを示す、自動化された差分テスト／適合性の証拠を製品として提供する例はない。これはegonschiele氏が指摘する信頼のギャップそのものである。
- なぜ今か
- 過去12か月で、フロンティアモデルによる大規模な移植が数日で完了する水準に達した（本記事がその実例）。そのため、あらゆる移行のボトルネックは「コードを書くこと」から「コードを信頼すること」へ移った。
- 参入障壁 · 6/10
- 言語ペアごとの適合性テストスイート、意味差分の手法、そして各案件から得られる等価性の失敗データが蓄積していく。案件を重ねるほど次の移植が速く安全になり、乗り換えは蓄積された認証履歴を失うことを意味する。
反対
- レッドチーム
- 今年、フロンティアモデルが移植コストを大きく下げたことで、ボトルネックは実際に信頼へ移った。企業はすでに1移行あたり15万〜100万ドルを支払っている。Mechanical OrchardのCOBOL分野を除けば、モデル生成の移植に対して機械的に検証された動作等価性を製品化しているコンサルティング会社は見当たらない。
- 失敗するとしたら
- 有状態で副作用を持つ企業システムでは、動作等価性のテストそのものが移植と同じくらい難しいと判明する。あるいは、コストに関係なく買い手が既存のコンサルティング会社を選び続ける。
始め方
- 最初の3ステップ
- 言語ペアを1つ選ぶ（例：Java 8のモノリスから最新のJava/Kotlinへ、またはPython 2時代のサービスからPython 3へ）。移行元システムのトレースと型情報から動作等価性テストを自動生成する差分テストハーネスを構築する。
- 人間が介在するエージェントパイプラインを使い、2〜3件の有償パイロット移行を実施する。成果物として「等価性レポート」を公開する。
- レポートと回帰テストハーネスを、任意のチームが既存のエージェントワークフローに組み込める単独の検証サービスとして製品化する。
- 元の議論
- Tsrs: A Port of TypeScript to Rust ↗ 426 ポイントコメント 209 件投稿からリンク先の記事
英語からの翻訳です。 原文を読む