upvote
I work on a codebase from the early 2000s, a lot of it using webforms, a long abandoned .NET technology. A rewrite preserving all behavior and making no observable changes whatsoever would be amazing. But it’s also tested exactly as well as you’d expect from something like that so I’d rather not let AI go wild.
reply
Good example. Transitioning from an outdated framework to a modern (or sometimes "slightly less outdated") one is probably one of the few situations where you do not want to change semantics at all.

And in my experience, these are _dangerous_. People go into "while we're at it..." mode, and it quickly turns into a big 2.0 kind of thing that takes forever.

I would argue that LLMs can speed this kind of thing up, but not by an order of magnitude or anything, just a bit. Unless there's high risk appetite.

reply
It still kind of blows me away that almost any LLM usage for coding isn't viewed as "high risk appetite"

Building products that no one really knows the internals of is crazy to me, and the methods people have of trying to mitigate that problem seem half assed at best

reply
As someone who currently automates the payroll flow generated by someone who doesn’t actually know what it does, I can confirm I am going crazy. My boss will do nothing about it because her boss can’t get finance to let us hire more people. I plan a strongly written resignation letter whenever I find something else.
reply
Sounds like you might work on a team with some agency to say no to management.

We have some and sometimes marketing comes back with some extra revenue from a partner if we build out feature X Y or Z for their new product launch. The contracts are signed so engineering has to do it or we’re blamed for lost revenue.

A few of those a year and you eventually end up in a similar situation.

reply
> Sounds like you might work on a team with some agency to say no to management.

If I didn't work on such a team, I would last exactly as long as it took me to find such a team.

reply
LLMs/agents are a great way to create a test harness for something like that.
reply
I plan to eventually get there, just need to find the time. It’s a lot of code, and a lot of it is not set up for testability.
reply
Using a better tech stack also provides opportunities to simplify.
reply
> What's the point of the rewrite if it doesn't fix the underlying issues, though?

Depends on what you mean by underlying issues. If you're in a regulated environment, it may be such a mountain of red tape to change behavior that it's not worth it, even if you know it's not ideal.

But if the underlying issues are tech debt, bad design, and other things invisible to the outside world, that's different.

reply
One obvious target might be rewriting from an unsupported, broken, and/or obsolete target to something that still works. Or moving a project from a platform that no other system in the company uses to the same setup that all the others use.

Of course it won't quite work, but I can definitely see why some people would want that.

reply
Make the fix easy. Then, make the easy fix.
reply
Say I rewrite a large codebase from python to C++, preserving all behavior. That's up to a 50x speed up.
reply
Not a good example i'd say given Python's position as pretty much the ultimate glue language :) You'd more likely keep the python shell (and faster developer iteration speed) and push measured hotspots down into c++/rust/c/whatever.

Incidentally, Whenever i've done this in the past it's had a pleasant side effect of improving architecture. You end up forcing something akin to "push for's down and pull if's up" because crossing the ffi boundary is not free. It can be quite magical, as in leading to comically unbelievably speed ups when you also take advantage of vector intrinsics.

reply
On the other hand: you don't need glue when you 3d print the whole thing. Keep it simple with a single language.
reply