Summary
The core conversion logic in logic_translator.py is entirely template-based — regex pattern matching, string replacement, and hardcoded templates. The LLM is not used for any actual code translation, only for CrewAI orchestration/planning.
This is the single highest-impact improvement opportunity in the codebase.
Current State
translate_java_code() (line ~927) returns hardcoded mock output with a static success_rate: 0.85convert_java_body_to_javascript() (line ~1306) does simple string replacements like java_body.replace("System.out.println", "console.log")translate_java_method_with_ast() (line ~1290) returns mock output despite having AST access via javalangentity_converter.py, recipe_converter.py, and block_item_generator.py contain zero LLM calls
Proposed Solution
Implement a two-step AST → NL → Target translation pipeline based on current research ("NL in the Middle" approach, 2025):
- Parse Java source with
javalang (already imported) to get the AST
- Step 1 — AST + NL Summary: LLM generates a natural language description of what the code does, using the AST structure as guidance
- Step 2 — NL → Bedrock JS/JSON: LLM generates Bedrock-compatible output from the NL summary, using existing templates and knowledge base patterns as few-shot examples
Research Backing
- Chain-of-Thought with NL intermediates achieves 13.8% improvement on CodeNet benchmarks vs zero-shot translation
- K³Trans (triple knowledge augmentation) shows 135.9% relative improvement on Pass@1 metrics
- Compositional translation (Berkeley EECS 2025) confirms breaking into smaller units (which our agent pipeline does) is the right approach
- Recommended temperature: 0.2 for code generation tasks
Implementation Plan
- Start with blocks and items (simplest conversion targets)
- Expand to recipes
- Then entities (most complex)
- Use existing
knowledge/patterns/ as few-shot examples
Priority
🔴 P0 — Critical | Estimated effort: 2-3 weeks
Impact
This directly addresses the core product value proposition — actually using AI to do the conversion work rather than just orchestrating template-based transformations.
Summary
The core conversion logic in
logic_translator.pyis entirely template-based — regex pattern matching, string replacement, and hardcoded templates. The LLM is not used for any actual code translation, only for CrewAI orchestration/planning.This is the single highest-impact improvement opportunity in the codebase.
Current State
translate_java_code()(line ~927) returns hardcoded mock output with a staticsuccess_rate: 0.85convert_java_body_to_javascript()(line ~1306) does simple string replacements likejava_body.replace("System.out.println", "console.log")translate_java_method_with_ast()(line ~1290) returns mock output despite having AST access viajavalangentity_converter.py,recipe_converter.py, andblock_item_generator.pycontain zero LLM callsProposed Solution
Implement a two-step AST → NL → Target translation pipeline based on current research ("NL in the Middle" approach, 2025):
javalang(already imported) to get the ASTResearch Backing
Implementation Plan
knowledge/patterns/as few-shot examplesPriority
🔴 P0 — Critical | Estimated effort: 2-3 weeks
Impact
This directly addresses the core product value proposition — actually using AI to do the conversion work rather than just orchestrating template-based transformations.