Of coarse the requirement of using more Ai came from management.
AI changes the economics of software rewrites
71–80 of 113 posts
Re: AI changes the economics of software rewrites
#72Re: AI changes the economics of software rewrites
#73Re: AI changes the economics of software rewrites
#74What's the point of the rewrite if it doesn't fix the underlying issues, though? A rewrite being a good idea often hinges on the ability to simplify. After a decade or more, it's now apparent what the application should and shouldn't do, so one can build it with those learnings and shed all tech debt from how it grew organically. Aka preserving all behavior is not what I would want from a rewrite. The point would be…
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.
Re: AI changes the economics of software rewrites
#75It also changes the economics of buy vs build.
Re: AI changes the economics of software rewrites
#76Earlier quoted context omitted.
Would putting that in black and white in the comments around then controller help?
I feel like there are a lot "you are holding it wrong" arguments flying around. Like, when somebody says that AI wasn't able to accomplish something, people tend to assume it's an User problem. Meanwhile, I have a hard time to believe people don't encounter problems with AI solutions on a regular basis (I do).
Re: AI changes the economics of software rewrites
#77> A fast car doesn't win races — a driver does
> the gap is not just speed - it's output quality
> A rewrite isn't just an opportunity to modernise your technology stack - it's an opportunity [...]
Garbage.
Re: AI changes the economics of software rewrites
#78Earlier quoted context omitted.
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
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.
If I didn't work on such a team, I would last exactly as long as it took me to find such a team.
Re: AI changes the economics of software rewrites
#79It also changes the economics of buy vs build.
That's very true. People put up with the many limitations of off the shelf software because it's cheaper, not because it's better. Developing bespoke software solutions is now a lot cheaper than it used to be. So, there are a lot of cases where that now becomes the better option. Doing in days what used to take months, is a bit of a game changer. Like with past cost reductions, people will underestimate the work and…
There is no such thing as maintenance-free software, even as the end user.
Re: AI changes the economics of software rewrites
#80Does it really change the whys of rewriting? https://www.joelonsoftware.com/2000/04/06/things-you-should-... Maybe the LLM will catch and reproduce all corner cases... maybe not...
In both cases I more-or-less ended up lining up the rewritten code and the original code right next to each other and trying to ensure that I could figure out where every line of code in the original ended up in the rewrite. That's much less of a pain than it sounds since they tend to bunch together. One of the rewrites was much harder because the very reason I wanted the rewrite was that the original was very hard to understand due to a combination of way more indirection than was necessary and the pervasive use of associative maps instead of structures, even though the data was structured. The AIs get confused just as the humans do. I did some work in creating unit tests that drew from a data source that both code bases could test against, since this was an HTTP API there was a relatively clean cut point for both codebases there.
AI makes these rewrites way, way easier than they used to be, but you do need to keep an eye on what they're doing, cross-check the final output by hand or by those shared unit tests, and not just assume you can fire the project off Friday evening and take whatever it made by Monday because that end product is probably missing quite a few of the original features.