[drzaiusx11]

Even before the advent of LLMs, I have personally (and largely successfully) translated several production systems from one language to another. I've learned it's best to start with a mechanical translation, literally bug for bug, leaving shit exactly as I found it (just in another language.)

I've done Perl to Java, Java to Kotlin, Python to Ruby, Ruby to Java, C to Swift, you name it.

It's only when you change behavior during the rewrite that it becomes an intractable problem. If you ship a 1:1 translation, THEN you can start going through the list of "bugs" you found along the way. Tread carefully when it comes to this, however, as I can almost guarantee that within your non-trivial codebase there will be some code that implicitly _depends_ on a "bug" to function at all. This where shit hits the fan.

[inamorty]

"Load bearing bugs"

[drzaiusx11]

It really is incredible how frequently these occur in everyday codebases of sufficient size.

[svieira]

We actually have a constant in our codebase to mark such bugs. You found one? Put it inside an:

    if (PREFER_EXISTING_BUGS_TO_NEW_ONES) { theOldBehavior(); }
    else { theNewBehavior(); }

Then, if we ever go to do a v2 of the thing, we can review these existing "load bearing bugs" and see if they make sense to change.

[drzaiusx11]

We do this via feature flags as well whenever "fixing" a non-trivial bug