Hacker News new | ask | show | jobs
by Semaphor 20 days ago
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.
2 comments

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.

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

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.
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.

> 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.

That sounds nice. I hope once I have secured my legal status in my new country (few more years to go) that I can take such a risk. Not everyone is in the same position to take that sort of risk.
I think everyone is right on this question :) I have certainly worked in places where there were enormous code bases written in dead languages going back to the 1970s and I was part of the collective belief that nothing could be done about it and our job in the 2000s was to put lipstick on the pig by burying it behind a web portal, if you remember that short-lived fad. In that kind of environment I would have _loved_ an exact port to a modern tech stack from which we could begin the very slow and careful evolution. Speaking to people who work there, AI has indeed changed at least their perception of what is possible and they have traction on porting it that was considered impossible for decades. Whether it works for some definition of “works” remains to be seen, but it might be self-fulfilling because the belief that it can be done will mean it is tried more often and some of those tries will probably succeed.

With that said, I’ve also recently done a rewrite in a completely different sense, taking what used to be a web app and rebuilding from the ground up as a desktop app instead. Having the original code base for core concept reference, but rethinking the whole UI more than a decade on was IMHO a much better approach in that case.

LLMs/agents are a great way to create a test harness for something like that.
This was my approach to a large rewrite I'm working on. First create the multiple layers of test suite to map out existing behavior at the unit, API, and integration level (something that should have been done incrementally over the 20 years this software has existed), then predicate the new code on the tests. It's been remarkably effective.
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.
To start the transition you can build your own tooling, in this case maybe start with the whole app stack including browser in an emulator, emulator controlled over a socket (write a harness that exposes all the inner debuggers, framebuffer, snapshotting, etc). Then generate a component inventory and likely failures for each, and generate pixel-perfection + internal state checks for each. Then migrate one component out (this may be quite a large project due to all the glue you'll need to make this possible). Then do the rest one at a time.

The big problem with doing it this way is you end up with something structurally the same as what you started with, but potentially more code if you e.g. end up carrying your own reimplementation of Web Forms.

Tell the agent to work on it and then give you summaries of code coverage, progress, and so on. It doesn't need to take up much of your time.