Estimates are considerably longer, QA is much harder, integration is full of buckets and rakes, some "senior" devs are afraid to touch stale core code, innovation is stifled, devs are frustrated, hiring is harder, attrition bites. The most frustrating thing is that its very hard to communicate the issues as everyone experiences a fragment of the pain and none of it lines up in a spreadsheet for anyone to appreciate the whole cost. Everything just sucks.
LLMs changing the economy of this sounds great, especially if removes the essential issue with the ground up rewrite, which is the "ground up" part.
I tend to believe that the engineering culture you describe will end up producing similar or, as Joel postulates, an even worse result, just dressed up in a modern stack.
If the technical leadership remains the very same one that enabled such a culture, I don't see them being able to suddenly produce a genuinely better software product only because an LLM is in a picture - especially considering how easy it is to convince an LLM that your idea is the best one.
With more disciplined engineers we are slowly cleaning it up but it is taking years to realize because management won’t allow work to be stopped on feature development. If we’re lucky, we get two sprints a year to fix things, usually around holidays when half the team is afk anyway so not a huge chunk can be fixed. Then on top of all of that, if you break something when trying to Boy Scout rule improve things, you get chastised and management clamps down more on “scope creep”.
Add in LLMs and now engineering management is convinced that they will solve our problems. Except it can’t really because the project is so spread out and disjointed that it’s impossible to reason about. You’d spend tens of dollars just to have it follow all possible branches of our most critical user flows (and then with hallucinations on top!).
I’m not saying the bots aren’t useful, but they cannot comprehend a disaster zone architecture in anything more than extremely targeted chunks. Without being able to see the entire thing, having it reliably refactor is just not possible without weeks of manual testing or taking a risk and being prepared to rollback on short notice. Writing tests would also take many weeks and if the point is to rearchitect to something sane, a snapshot test is not really going to cut it.
It’s a pickle of a problem for sure… and I’m not sure I will survive at this company long enough to see the end (though I’ve been here years already).
These two technologies combined greatly simplified this specific product making it far easier to maintain. Performance on these services was not important so native code was carrying a lot of penalties without the benefits.
Having a well documented messenger like service bus with great SLAs removed several tools we had needed in the old implementation.
We were able to leverage the tests form the original product to define success and tmthus were able to solve a lot of the edge cases in the new code w before we even shipped.
However, the old code was perfectly fine code. If new technologies had not provided significant simplification of the service architecture, a rewrite would've been foolish. And without the very good previously existing tests, we would've run into a lot of issues as we released.
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.