11–20 of 42 posts
I once needed to convert 2000 line excel formula to PHP but PHP linters sucks and are generally not helpful so I converted it to JS first and then I just added $ signs in front of variable names, few minor tweaks and it worked. It was easier than to go directly to PHP.
In this sense an LLM or hand crafted approach may win out.
Also API will likely be different.
I’d take a step back and get clarification on the scope of your task. See my comment other day about how you can use Claude to help with that. https://news.ycombinator.com/item?id=43163011
## Core Questions for Migration Scope Clarification
1. *What exactly needs to be preserved?* - Business outcomes only, or exact implementation details? - Current scheduling patterns or can they be optimized?
2. *What's the true scale?* - Number of workflows needing migration - Complexity spectrum of the JavaScript snippets - Frequency and criticality of each workflow
3. *What are the real constraints?* - Timeline requirements - Available expertise (JavaScript, Python, Airflow) - Downtime tolerance during transition
4. *What's the maintenance plan?* - Who will support the migrated workflows? - What documentation needs to be created? - How will knowledge transfer occur?
5. *What's the verification strategy?* - How will you validate correct migration? - What tests currently exist or need to be created? - What defines "successful" migration?
6. *What's unique to your environment?* - Custom integrations with other systems - Special CA Workflow features being utilized - Environmental dependencies
7. *What's the true purpose of this migration?* - Cost reduction, technical debt elimination, feature enhancement? - Part of larger modernization or standalone project? - Strategic importance versus tactical necessity
8. *What approaches have been eliminated and why?* - Complete Python rewrite - Containerized JavaScript execution - Hybrid approaches
9. *What would happen if this migration didn't occur?* - Business impact - Technical debt consequences - Opportunity costs
10. *Who are the true stakeholders?* - Who relies on these workflows? - Who can approve changes to functionality? - Who will determine "success"?
Answering these questions before diving into implementation details will save significant time and reduce the risk of misaligned expectations.
Then you write the short DAG description in Python but make the task executor launch the Docker containers.
And then you're done.
If they force an LLM on you, say that you are thrilled to use an LLM, give it a try and arrive at the conclusion that unfortunately LLMs are not up to the task. Bill the hours needed to arrive at that conclusion.
There's no need for software engineers to automate themselves away. Look at lawyers, they know how to bill and protect themselves.
Pitfalls to watch our for? Tons of them. Comparison is very different, modulus is different, .sort is different, object destructuring doesn't map nicely to python, lambda's won't map nicely to python, promises won't map to python. Labelled loops won't map nicely to python.
If your JS snippets are truly simple, just LLM translate and manually check. They're pretty good at the simple stuff.
If you have any async JS, that's going to seriously complicate things. Theres no AST mapping for that (python async is not the same). Pitfalls to watch our for? Tons of them. Comparison is very different, modulus is different, .sort is different, object destructuring doesn't map nicely to python, lambda's won't map nicely to python, promises won't map to python. Labelled loops won't map nicely to python. If your JS s…
> How much of an overkill that might be? It sounds like a complete waste of time. If you are talking about small code snippets then simply write new original Python to replace them.
Yep, I thought about that... Still, there's a few hundreds of workflows to migrate, so I was looking for a systematic approach
The hard work will be validating that the code they write for you is exactly right. You would have to do that if you wrote the code yourself, too. The LLMs will accelerate the writing-the-code part but the manual QA work will still be on you: https://simonwillison.net/2025/Mar/11/using-llms-for-code/#y...