Active client engagement: porting a Perl/Mojolicious WebLogic admin platform to Python. Derek project. The survey and approach notes below were written at proposal stage (2026-05) and remain valid as a reference, but the project has moved beyond that.
Project is active. Detailed project notes (setup guide, auth config, T3S setup, WebLogic connection details) were lost when noodle (Singapore production server — notes system, web server) was wrongly terminated; replaced by gravlax (Stockholm). The survey/approach/model-comparison/timeline notes below survive. WebLogic lab can be rebuilt from the ansible playbooks — see ansible/playbooks (deploy_weblogic_ldap.yml) and weblogic/config-xml-admin-port for the reference config.xml generated 2026-06-18.
• Perl/Mojolicious web UI fronting WebLogic management API (likely WLST/JMX/REST)
• Manages grouped application servers; possibly extensible to JBoss/WildFly
• Driver for migration: shrinking pool of Perl developers, especially those fluent in both Mojolicious and enterprise Java middleware
Two-phase, spec-as-pivot rather than direct Perl→Python translation:
1. Extract a detailed semantic specification from the Perl codebase (intent, not mechanism)
2. Generate idiomatic Python from the spec, treating it as a fresh implementation
This decouples comprehension from generation and forces abstraction past Mojolicious idioms. The spec is also a durable, model-agnostic artefact — re-generation with a better model in 12 months remains viable.
Crucially: discard the Perl wrappers around WebLogic JMX. Call WebLogic's REST management API (or official Java client) directly from the new system.
• pp-rewrite/approach — Why spec-as-pivot works; what a good Mojolicious semantic spec looks like; pitfalls in the comprehension and generation phases
• pp-rewrite/model-comparison — Claude vs Gemini today: context window vs code quality vs agentic tooling; realistic success rates per phase
• pp-rewrite/timeline-projection — What changes in 1–2 years: context utilisation, agentic workflows, verification as the new bottleneck
Today (mid-2026): Workable with strong human oversight. Spec extraction ~80–90% useful, spec→Python ~70–80% useful. Realistic productivity multiplier 2–3× over a manual port. Gemini mandate is fine — model choice is ~20% of the outcome; process quality (specs, characterisation tests, strangler-fig rollout) dominates.
1 year (mid-2027): 5–10× multiplier becomes plausible as long-context utilisation and agentic tooling mature. Spec-driven workflows become standard tooling rather than bespoke prompting.
2 years (mid-2028): Speculative. End-to-end migration with AI-driven verification (behavioural equivalence checking, generated test suites) becomes plausible for codebases of this size. Verification, not generation, is the binding constraint.
Honest caveat: AI does not turn this into a weekend job today and probably not in two years either. It compresses a 6–18 month project into a smaller window, but a senior engineer must own the architecture and review every PR.
• Use Claude (or whichever model iterates fastest for you) to draft the semantic spec; refine against the Perl source
• Generate Python with Gemini per company mandate
• Generate characterisation tests against the existing Perl behaviour before any port begins
• Use Claude Code or Gemini CLI for iterative test-driven porting of business logic
• Strangler-fig rollout: stand the new service alongside the Perl one, route endpoints across one at a time
• Choose a target framework deliberately — FastAPI (modern, async, OpenAPI-native) or Flask (simpler, larger pool) are the obvious candidates