5 ms·

AI changes the economics of software rewrites

103 points by cinooo 3mo ago

lazy_dev_1_to_9 3mo ago
This certainly does. If we think from this angle, it really begs the question of what language/tech stack to use if a company wants to start a new project. On one hand, if company uses a very well tech stack, development and rewrites will be faster due to AI having way more examples to draw from. In certain cases, AI will handle some edge cases which are difficult to come by/replicate under strictest test procedures. Overall, that results in faster workflow. On the other hand, if this company choose a newer stack which may be better better than older popular frameworks, development time will increase (along with rewrite time)but the product might be better. we have to see how companies handle this in the future, given this is also affected by how cheap/expensive token consumption becomes. Using something pretrained vs training and then using an AI has cost implications when done in a large scale. It will be interesting to see what directions companies go to, faster workflows and delivery using AI or potentially a better product using more manually written proprietary code with lesser AI involvement.
- protocolture 3mo ago
  >if company uses a very well tech stack, development and rewrites will be faster due to AI having way more examples to draw from. Eh maybe not. Stuff that has a lot of deprecated features is honestly burdensome on AI. It keeps rediscovering the deprecated features as the understanding that they are deprecated fall outside of the context window. What you need is something that either never deprecates syntax, or is <10 years old with minimal changes over that time.
- apsurd 3mo ago
  I don't think that holds. Internal docs for bespoke frameworks, with examples, are effective at steering AI. The main thing is that both the API and the docs are well written. Easier said than done, but you can ask AI how to write effective documentation for AI.
nottorp 3mo ago
Does it really change the whys of rewriting? https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Maybe the LLM will catch and reproduce all corner cases... maybe not...
- Quarrelsome 3mo ago
  Joel is right, but he's also wrong. I've been on the other side of a timid engineering culture that commerical rides roughshod over and its this depressing immeasurable decline. The company stagnates and slowly tailspins around an unmaintainable product until a competitor steals their lunch in a way that that further obscures cause and effect. 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.
  - bojan 3mo ago
    The LLM might change the economy of this, but I doubt it. 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.
    - yurishimo 3mo ago
      Actively trying to fight against this now. Crazy huge amount of tech debt with 3 separate rewrites inside one unified monolith repository. Management could only be convinced to let engineering move forward with features on a new platform so now we have periods of code for each rewrite that contain certain features. 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).
bad_username 3mo ago
It also changes the economics of buy vs build.
- bonzini 3mo ago
  Much less if you consider buy vs build+maintain.
  - jdlshore 3mo ago
    I think your underlying point is correct, but "buy" is also "buy+maintain." There's a real cost to keeping up with dependency upgrades, especially for big frameworks that like to change their fundamental public-facing API every few years.
- jillesvangurp 3mo ago
  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 get it wrong. It helps if you know what you are doing rather than just vibe coding things. But for rewrites, the sunk cost fallacy becomes a lot cheaper. So, that changes how you deal with stuff that clearly isn't living up to expectations. Unceremoniously replacing what wasn't that expensive to begin with might be the cheaper option relative to fixing it.
  - TheOtherHobbes 3mo ago
    They also do it because there's someone to blame, and - more importantly - because they know the people who are selling it from their golf dates.
  - sublinear 3mo ago
    An efficient business focuses on their core competencies. Increasing the surface area of things to worry about is not what most businesses want to do. There is no such thing as maintenance-free software, even as the end user.
feverzsj 3mo ago
The problem is always maintainability. Who's gonna fix new bugs? Who's gonna add new features?
- bboozzoo 3mo ago
  Why, LLMs of course. Isn't that obvious by now?
- esafak 3mo ago
  An economics article that completely ignores the cost of bugs!
light_hue_1 3mo ago
This kind of data-free opining reminds me of the Mythical Man-Month. Yeah, in theory adding more people to a project will speed it up. And all people are replaceable so I can hire 100 bodies for cheap and we'll be done with this project ASAP. Sounds great! Have you tried this? Did you see what went wrong? Otherwise this is just the same nonsense as always.
reinitctxoffset 3mo ago
The amount of armchair quarterback commentary in the software business as concerns people waxing eloquent a out difficult things safe atop a perch of the same easy things achieved multiple times has always been obnoxious, offensive to the thermodynamics of the situation as situated by Landauer. But this new "you're holding it wrong" series by people whose grasp of the system gets fuzzy somewhere in the v8 headers is a new land speed record for being vacuously correct and still an attractive nuisance for profit. Yes, the trend towards encoding hard-won domain knowledge as property and fuzz testing and sometimes even proof system was underway before ChatGPT, and yes, the economics of this approach bend sharply under a post terrawright world. But no, you haven't added anything except tinsel and chaff and some green css on mixpanel. Just stop with this shit. If you knew shit about AI you'd be too busy printing cash to teach the rest of us about it.
- Quothling 3mo ago
  I'm not sure there is any value in knowing shit about AI. I know quite a lot about enterprise organisation level AI, but really, you could just ask an AI and it'd guide you through the processes. Knowledge in general is going to become real cheap in the age of AI. I've been a data archtiect in the past, so I used Opus 4.8 as I would've used a consultant agency on how to do our data architecture for multiple standard systems which can't directly share data with eachother. After a couple of hours with it as a sparring partner, I had some pretty awesome powerpoint decision making slides, one for c-levels and one for it-management. Since our owners also own an IT consultant agency, I ran the same process through with one of our regular consultants who is an actual awesome data architect. The output was strikingly similar, well except that I/we didn't need to make the slides. I then had him run over the actual slides, and all we changed was adding a { between some arrows to make the source of the arrows more clear. We're still going to use real human consultants in the loop because they are readily and freely available, and because this is still new. I doubt we'd want to spend 100 consultant hours on something like this in 5 years though. I mean, we'd still do it for decisions where we'd want someone to blame.
apsurd 3mo ago
again with these linkedin "articles". · every sentence stands on its own because it's the most insightful soundbite of wisdom every constructed. · Aphorisms for the collective upgrade of consciousness. · delivered one tweet at a time. · (this comment adds to the discussion ironically by demonstrating how ridiculous it is to have to derive signal from this format. Please do what you need on Linkedin but take some semblance of effort to honor this community. Or don't. sigh)
- rodrodrod 3mo ago
  I once saw this style be called "broetry"[1], and it's unmistakably LinkedIn-voice. I get that it works because feed algorithms/engagement, but never understood why it seems largely confined to LinkedIn and not other social media sites. [1] https://fenwick.media/rewild/magazine/dead-broets-society-behind-the-strange-story https://fenwick.media/rewild/magazine/dead-broets-society-be...
2001zhaozhao 3mo ago
Somehow this article doesn't even mention the fact that AI makes software rewrites much, much faster than before and with higher confidence of backwards compatibility. Nowadays, a good AI harness can fairly reliably rewrite a medium complexity piece of software to an appropriate modern tech stack with pretty strong confidence of exactly preserving its behavior. The AI can pick up legacy details and keep them exactly the same as before in ways that a human rewriter would usually not bother with. After rewriting each feature it can then exhaustively smoke test all the happy paths and edge cases and ensure the code behaves exactly the same as before, which is another thing that human rewrites basically never do.
- deleted 3mo ago
  [deleted]
- oblio 3mo ago
  AI <<can>> do a lot of things, but does it actually do that without an exhaustive test suite (which legacy software generally doesn't have, and it can never be 100%, anyway)? Between context collapse and hallucinations, how likely is it that the end result isn't slightly polished slop that misses lots of crucial details?
DubiousPusher 3mo ago
What do your tests look like. Because rewriting by hand and rewriting via AI have the same load bearing on whether or not your tests cover your scenarios and your integrations well.
jdw64 3mo ago
The point where I truly feel that AI is a game changer is that these kinds of posts keep appearing. Tautological outcries keep going on both sides, pro and con, endlessly repeating circular logic. There's no real substance or evidence, and rather than discussing how things were actually applied, it's just an echo chamber for whatever group you belong to. In that sense, my homepage (https://www.makonea.com/en-US https://www.makonea.com/en-US) doesn't even make it to the HN front page—it's mostly in SHOWDEAD. Does that mean it has less value than this post? I'm feeling a sense of doubt about myself.
- apsurd 3mo ago
  this post is no good. It's a continual rehash of what's going on in the industry. That's how all social media is, it's entirely time sensitive, keep saying the the same things and be the one to say it so the discussion happens on your "content". OP is playing the game. The post literally says "from LinkedIn" so if you look, he has 500+ connections and 1400 followers. That's not nothing. Good for him, all advice points to this new attention economy we live in. I'm a bit aged out of all this. And I rode the 2010s wave so I can't give any advice in good conscience. I can only say that I see you and there's a whole world of silent majorities out there with no follow count and no broetry with our name on it. (search for that word in this thread, just learned it, it's great!)
  - jdw64 3mo ago
    Thank you. I'll do my best too. I appreciate your encouragement
matsemann 3mo ago
What'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 to make decisions on what behavior should be kept and what complexity can be removed. An AI can't do that. It can help with execution if the decisions are made, but they're made by being very intimate with the codebase and floating all cases and then talking with stakeholders.
- Semaphor 3mo 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.
  - fhd2 3mo ago
    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.
    - bluefirebrand 3mo ago
      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
akssri 3mo ago
Au contraire - LLMs are quite bad at large scale pattern fidelity. They'll even forget key details and constraints unless told over and over again. That's why AI-written code has the quality of a patch-on-patch-on-patch.
- gofreddygo 3mo ago
  [dead]
- karlkloss 3mo ago
  That's also true for humans.
  - dnikolovv 3mo ago
    Reductio ad absurdum.
  - fxtentacle 3mo ago
    Humans will typically learn after you have forced them to apologise for the same mistake for 20 times in a row. AI won’t.
    - AndrewThrowaway 3mo ago
      If you gave some junior dev a large codebase and just told to "refactor it" you would get a terrible result. If you gave junior dev exact tasks what to do where you will get better results. Just like with LLM.
      - al_borland 3mo ago
        That’s why junior devs generally aren’t give the responsibility of architecting a large scale refactor. Yet people seem to be trying to had these types of tasks over to LLMs.
        AndrewThrowaway 3mo ago
retinaros 3mo ago
First three paragraphs and I can tell its opus 4.8
- trollbridge 3mo ago
  You are a man of taste and refinement; I could tell it was an LLM, but didn't recognise it was Opus and certainly had no idea which version. (At least the author sprang for a $20 a month subscription.)
est 3mo ago
But can AI rewrite better over AI clop made by itself?
SunlightEdge 3mo ago
In my experience, LLM's can be both impressive and also totally wrong in their reasoning when doing a code re-write. I was involved in an api migration a while back and while at times the llms were able to re-write the code - they also had instances where their totally misunderstood the platform and their recommendations for solving the issue was almost dangerously wrong. an over reliance on them can also make people lazy at what are quite simple programming issues (but they can code things up a hell of a lot faster) - its a tool and the outputs need to be carefully reviewed (with a dose of critique when its an uncertain area).
crnkofe 3mo ago
I had an itch to rewrite every project after it got large enough and have rewritten some of them. The tragedy of rewriting stuff is that it often ends up becoming more of a duplicate than an improved original. Its hard to see all the edge cases when skimming codebase from afar. Maybe for prototyped code it could work. Not sure if feeding prototype AI slop into AI will produce results though. GIGO. Rewriting code is anyhow not the critical aspect. Its testing and QAing the result and legacy edge cases that's the most time consuming part and that isn't really covered by writing more code.
socketcluster 3mo ago
I agree that AI does well when the patterns in the code are predictable and consistent. That said it can work surprisingly well with custom frameworks and tools provided that they are predictable and consistent. For example, I created a platform with custom Web Components. Agents do a great job at using the components by reading the docs. I find it a lot easier and more succinct than React. I think it's because AI isn't as good with high level patterns when there are too many pieces involved and too many sub-patterns to apply, it gets so caught up in the details that it misses the forest for the trees. My SDK abstracts away a lot of low-level complexity so that agents are able to focus on higher-level architectural patterns. Also, it's very succinct so agents can fit a lot of context/functionality into its context window. It gets faster and better as the codebase grows. Here's the link if anyone wants to try: https://saasufy.com/ https://saasufy.com/
felixlu2026 3mo ago
[dead]
josefritzishere 3mo ago
AI will make software updates and maintenance much more expensive. Once you're trapped in an AI maintenance dependency, they're going to extract maximum revenue from their captured user base.
ganzsz 3mo ago
We sold a large rewrite to be able to use llms. Our code is such a mess that an llm has trouble implementing new features. (maintainability is still a must, even when vibe coding). So we got a green light to use clean patterns that a llm could extend easily. Of coarse the requirement of using more Ai came from management.
darepublic 3mo ago
Just going to chime in that a year ago chatgpt was really struggling with robot framework. O3 era. Even apart from ai's ability to write working code in it I hate that dsl pseudo semantic bullshit
ghost_pepper 3mo ago
This website has four articles, once daily, three of which being AI crap and doomsaying (the fourth arguably too, it just doesn't say so), all with lines like: > 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.
- graypegg 3mo ago
  The "Written by hand." in the footer hurts my brain. If it is written using real thoughts and ideas formed by themselves, they've fully imbued their brain with that AI stank I guess. It really does FEEL like unedited LLM output. You can find a few smoking guns or em a few dashes, whatever. But every sentence is emanating the stank.
  - Sivart13 3mo ago
    you don't need to be an LLM to have LinkedIn brain, but it helps
    - Bratmon 3mo ago
      LinkedIn brain honestly really disturbs me. I didn't believe in souls until I needed a word to describe what people with LinkedIn brain lacked. Fortunately, then LLMs came along and now if I see a worryingly-soulless LinkedIn-brained post, I can lie to myself and say it was made by a discount LLM.
  - Insanity 3mo ago
    They prompted the model by hand.
  - ghost_pepper 3mo ago
    That's the sign of a good product: when you have to lie that you don't use it.
  - graypegg 3mo ago
    Haha... well it's now changed to: "Written with AI. Curated by hand." Yesterday: https://web.archive.org/web/20260709105821/https://thetruthasiseeitnow.com/ai-slop-starts-with-the-codebase-itself/ https://web.archive.org/web/20260709105821/https://thetrutha...
devin 3mo ago
I don't think it does. (meaningfully change the economics of rewrites) Burning a sea of tokens to arrive at the equivalent functionality and having a small team of people oversee that process is rarely going to be the fix to the organizational problems that surround typical failed/stagnant software projects. Rewrites are rarely about the organization of the symbols and are more often about a change in the fundamental understanding of the organization about the problem they've solving. Remember: People change slowly. People are often too tied to the idea of "rewrite" as a replay of all current capabilities, but should instead be thinking about fundamentally different primitive capabilities of the system. It's not a "redo" if you're changing some of your fundamental assumptions about the problem space.
- onlyrealcuzzo 3mo ago
  I assumed LLMs should be able to rewrite a small amount of code ~5k dense LoC in Ruby to Rust. It could not. I suspect you'll see a wave of transpilers developed to mostly transpile code from one language to another. You can have an LLM generate a 1-2k or so LoC transpiler that can translate 50%+ of code in place from most languages to another. After doing that, it was able to actually get the job done relatively quickly. I'm working on self-hosting a programming language I've been developing. The transpiler from the original language to the host language is ~12k LoC and translates ~99% the original compiler's ~80k LoC cleanly. The total self-host looks like it might only take a couple of weeks and <$100... TBD.
  - metalspot 3mo ago
    An LLM can do this easily if you have a good test harness
llm_nerd 3mo ago
While the article is terrible, what they describe about AI knowing common stacks and frameworks is advice that holds for finding software developers to join your team. Like, 1-for-1. It has always been good advice unless you have a strong justification go in a different direction. Use standard tools, standard frameworks, standing patterns, standard protocols, and so on, and it's incredibly easy to find highly talented members to join your team, running on day one, and enjoy the progress of the industry. It's quite a different tale when you have some massive internal "framework" monstrosity, have weird patterns and standards, and so on, and these are the sorts of places where you usually find some half-baked terrible custom coding language and so on.
clickety_clack 3mo ago
Of course! Just take the code you've taken the time to understand and rewrite it so that it's in a form you have to grok all over again!
overgard 3mo ago
In my experience, most rewrites fall more into the realm of "it's easier to write code than it is to read it, and I don't want to read all this existing stuff!" That's kind of the fundamental motivation, and then people couch it in some very plausible sounding technical reasons. (I don't even think people are being dishonest when this happens -- it's easy to look at a codebase and think "this sucks!" because you don't understand the context behind the original decisions.. and writing new code is a lot more fun than maintaining old code) I'm not saying "never rewrite" things, there are valid cases where the original tech stack is no longer relevant or the accumulated tech debt really is too much, but I'm pretty skeptical of most rewrites at this point in my career.
- Pannoniae 3mo ago
  Well yeah, for example I'm working on a codebase written mostly in 2003. The assumptions in the original code are at best tangentially relevant (stuff like "LUTs are cheaper than using ALU" or "CPU power is cheap, GPU power is very expensive"). Despite that, a grand rewrite would have failed massively (even with agents...), replicating millions of lines of code to be functional again just sounds like an absolute nightmare. So I've been doing "targeted rewrites" instead - not sure, there's maybe a name for it? Basically do it concern by concern, module by module, so even if lots of code was touched, it only affects one logical feature at the same time.
newppc 3mo ago
Rewrite command and conquers generals for mac
mlinhares 3mo ago
The only economics that change is the full employment for engineers, as they'll be able to create infinite work rewriting systems every year. Its a win/win for the workers!
whateveracct 3mo ago
no it doesn't

103 points by cinooo 3mo ago

This certainly does. If we think from this angle, it really begs the question of what language/tech stack to use if a company wants to start a new project. On one hand, if company uses a very well tech stack, development and rewrites will be faster due to AI having way more examples to draw from. In certain cases, AI will handle some edge cases which are difficult to come by/replicate under strictest test procedures. Overall, that results in faster workflow. On the other hand, if this company choose a newer stack which may be better better than older popular frameworks, development time will increase (along with rewrite time)but the product might be better. we have to see how companies handle this in the future, given this is also affected by how cheap/expensive token consumption becomes. Using something pretrained vs training and then using an AI has cost implications when done in a large scale. It will be interesting to see what directions companies go to, faster workflows and delivery using AI or potentially a better product using more manually written proprietary code with lesser AI involvement.

protocolture 3mo ago
>if company uses a very well tech stack, development and rewrites will be faster due to AI having way more examples to draw from. Eh maybe not. Stuff that has a lot of deprecated features is honestly burdensome on AI. It keeps rediscovering the deprecated features as the understanding that they are deprecated fall outside of the context window. What you need is something that either never deprecates syntax, or is <10 years old with minimal changes over that time.
apsurd 3mo ago
I don't think that holds. Internal docs for bespoke frameworks, with examples, are effective at steering AI. The main thing is that both the API and the docs are well written. Easier said than done, but you can ask AI how to write effective documentation for AI.

nottorp 3mo ago

Does it really change the whys of rewriting? https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Maybe the LLM will catch and reproduce all corner cases... maybe not...

Quarrelsome 3mo ago
Joel is right, but he's also wrong. I've been on the other side of a timid engineering culture that commerical rides roughshod over and its this depressing immeasurable decline. The company stagnates and slowly tailspins around an unmaintainable product until a competitor steals their lunch in a way that that further obscures cause and effect. 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.
- bojan 3mo ago
  The LLM might change the economy of this, but I doubt it. 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.
  - yurishimo 3mo ago
    Actively trying to fight against this now. Crazy huge amount of tech debt with 3 separate rewrites inside one unified monolith repository. Management could only be convinced to let engineering move forward with features on a new platform so now we have periods of code for each rewrite that contain certain features. 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).

bad_username 3mo ago

It also changes the economics of buy vs build.

bonzini 3mo ago
Much less if you consider buy vs build+maintain.
- jdlshore 3mo ago
  I think your underlying point is correct, but "buy" is also "buy+maintain." There's a real cost to keeping up with dependency upgrades, especially for big frameworks that like to change their fundamental public-facing API every few years.
jillesvangurp 3mo ago
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 get it wrong. It helps if you know what you are doing rather than just vibe coding things. But for rewrites, the sunk cost fallacy becomes a lot cheaper. So, that changes how you deal with stuff that clearly isn't living up to expectations. Unceremoniously replacing what wasn't that expensive to begin with might be the cheaper option relative to fixing it.
- TheOtherHobbes 3mo ago
  They also do it because there's someone to blame, and - more importantly - because they know the people who are selling it from their golf dates.
- sublinear 3mo ago
  An efficient business focuses on their core competencies. Increasing the surface area of things to worry about is not what most businesses want to do. There is no such thing as maintenance-free software, even as the end user.

feverzsj 3mo ago

The problem is always maintainability. Who's gonna fix new bugs? Who's gonna add new features?

bboozzoo 3mo ago
Why, LLMs of course. Isn't that obvious by now?
esafak 3mo ago
An economics article that completely ignores the cost of bugs!

light_hue_1 3mo ago

This kind of data-free opining reminds me of the Mythical Man-Month. Yeah, in theory adding more people to a project will speed it up. And all people are replaceable so I can hire 100 bodies for cheap and we'll be done with this project ASAP. Sounds great! Have you tried this? Did you see what went wrong? Otherwise this is just the same nonsense as always.

reinitctxoffset 3mo ago

The amount of armchair quarterback commentary in the software business as concerns people waxing eloquent a out difficult things safe atop a perch of the same easy things achieved multiple times has always been obnoxious, offensive to the thermodynamics of the situation as situated by Landauer. But this new "you're holding it wrong" series by people whose grasp of the system gets fuzzy somewhere in the v8 headers is a new land speed record for being vacuously correct and still an attractive nuisance for profit. Yes, the trend towards encoding hard-won domain knowledge as property and fuzz testing and sometimes even proof system was underway before ChatGPT, and yes, the economics of this approach bend sharply under a post terrawright world. But no, you haven't added anything except tinsel and chaff and some green css on mixpanel. Just stop with this shit. If you knew shit about AI you'd be too busy printing cash to teach the rest of us about it.

Quothling 3mo ago
I'm not sure there is any value in knowing shit about AI. I know quite a lot about enterprise organisation level AI, but really, you could just ask an AI and it'd guide you through the processes. Knowledge in general is going to become real cheap in the age of AI. I've been a data archtiect in the past, so I used Opus 4.8 as I would've used a consultant agency on how to do our data architecture for multiple standard systems which can't directly share data with eachother. After a couple of hours with it as a sparring partner, I had some pretty awesome powerpoint decision making slides, one for c-levels and one for it-management. Since our owners also own an IT consultant agency, I ran the same process through with one of our regular consultants who is an actual awesome data architect. The output was strikingly similar, well except that I/we didn't need to make the slides. I then had him run over the actual slides, and all we changed was adding a { between some arrows to make the source of the arrows more clear. We're still going to use real human consultants in the loop because they are readily and freely available, and because this is still new. I doubt we'd want to spend 100 consultant hours on something like this in 5 years though. I mean, we'd still do it for decisions where we'd want someone to blame.

apsurd 3mo ago

again with these linkedin "articles". · every sentence stands on its own because it's the most insightful soundbite of wisdom every constructed. · Aphorisms for the collective upgrade of consciousness. · delivered one tweet at a time. · (this comment adds to the discussion ironically by demonstrating how ridiculous it is to have to derive signal from this format. Please do what you need on Linkedin but take some semblance of effort to honor this community. Or don't. sigh)

rodrodrod 3mo ago
I once saw this style be called "broetry"[1], and it's unmistakably LinkedIn-voice. I get that it works because feed algorithms/engagement, but never understood why it seems largely confined to LinkedIn and not other social media sites. [1] https://fenwick.media/rewild/magazine/dead-broets-society-behind-the-strange-story https://fenwick.media/rewild/magazine/dead-broets-society-be...

2001zhaozhao 3mo ago

Somehow this article doesn't even mention the fact that AI makes software rewrites much, much faster than before and with higher confidence of backwards compatibility. Nowadays, a good AI harness can fairly reliably rewrite a medium complexity piece of software to an appropriate modern tech stack with pretty strong confidence of exactly preserving its behavior. The AI can pick up legacy details and keep them exactly the same as before in ways that a human rewriter would usually not bother with. After rewriting each feature it can then exhaustively smoke test all the happy paths and edge cases and ensure the code behaves exactly the same as before, which is another thing that human rewrites basically never do.

deleted 3mo ago
[deleted]
oblio 3mo ago
AI <<can>> do a lot of things, but does it actually do that without an exhaustive test suite (which legacy software generally doesn't have, and it can never be 100%, anyway)? Between context collapse and hallucinations, how likely is it that the end result isn't slightly polished slop that misses lots of crucial details?

DubiousPusher 3mo ago

What do your tests look like. Because rewriting by hand and rewriting via AI have the same load bearing on whether or not your tests cover your scenarios and your integrations well.

jdw64 3mo ago

The point where I truly feel that AI is a game changer is that these kinds of posts keep appearing. Tautological outcries keep going on both sides, pro and con, endlessly repeating circular logic. There's no real substance or evidence, and rather than discussing how things were actually applied, it's just an echo chamber for whatever group you belong to. In that sense, my homepage (https://www.makonea.com/en-US https://www.makonea.com/en-US) doesn't even make it to the HN front page—it's mostly in SHOWDEAD. Does that mean it has less value than this post? I'm feeling a sense of doubt about myself.

apsurd 3mo ago
this post is no good. It's a continual rehash of what's going on in the industry. That's how all social media is, it's entirely time sensitive, keep saying the the same things and be the one to say it so the discussion happens on your "content". OP is playing the game. The post literally says "from LinkedIn" so if you look, he has 500+ connections and 1400 followers. That's not nothing. Good for him, all advice points to this new attention economy we live in. I'm a bit aged out of all this. And I rode the 2010s wave so I can't give any advice in good conscience. I can only say that I see you and there's a whole world of silent majorities out there with no follow count and no broetry with our name on it. (search for that word in this thread, just learned it, it's great!)
- jdw64 3mo ago
  Thank you. I'll do my best too. I appreciate your encouragement

matsemann 3mo ago

What'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 to make decisions on what behavior should be kept and what complexity can be removed. An AI can't do that. It can help with execution if the decisions are made, but they're made by being very intimate with the codebase and floating all cases and then talking with stakeholders.

Semaphor 3mo 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.
- fhd2 3mo ago
  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.
  - bluefirebrand 3mo ago
    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

akssri 3mo ago

Au contraire - LLMs are quite bad at large scale pattern fidelity. They'll even forget key details and constraints unless told over and over again. That's why AI-written code has the quality of a patch-on-patch-on-patch.

gofreddygo 3mo ago
[dead]
karlkloss 3mo ago
That's also true for humans.
- dnikolovv 3mo ago
  Reductio ad absurdum.
- fxtentacle 3mo ago
  Humans will typically learn after you have forced them to apologise for the same mistake for 20 times in a row. AI won’t.
  - AndrewThrowaway 3mo ago
    If you gave some junior dev a large codebase and just told to "refactor it" you would get a terrible result. If you gave junior dev exact tasks what to do where you will get better results. Just like with LLM.
    - al_borland 3mo ago
      That’s why junior devs generally aren’t give the responsibility of architecting a large scale refactor. Yet people seem to be trying to had these types of tasks over to LLMs.
      - AndrewThrowaway 3mo ago

retinaros 3mo ago

First three paragraphs and I can tell its opus 4.8

trollbridge 3mo ago
You are a man of taste and refinement; I could tell it was an LLM, but didn't recognise it was Opus and certainly had no idea which version. (At least the author sprang for a $20 a month subscription.)

est 3mo ago

But can AI rewrite better over AI clop made by itself?

SunlightEdge 3mo ago

In my experience, LLM's can be both impressive and also totally wrong in their reasoning when doing a code re-write. I was involved in an api migration a while back and while at times the llms were able to re-write the code - they also had instances where their totally misunderstood the platform and their recommendations for solving the issue was almost dangerously wrong. an over reliance on them can also make people lazy at what are quite simple programming issues (but they can code things up a hell of a lot faster) - its a tool and the outputs need to be carefully reviewed (with a dose of critique when its an uncertain area).

crnkofe 3mo ago

I had an itch to rewrite every project after it got large enough and have rewritten some of them. The tragedy of rewriting stuff is that it often ends up becoming more of a duplicate than an improved original. Its hard to see all the edge cases when skimming codebase from afar. Maybe for prototyped code it could work. Not sure if feeding prototype AI slop into AI will produce results though. GIGO. Rewriting code is anyhow not the critical aspect. Its testing and QAing the result and legacy edge cases that's the most time consuming part and that isn't really covered by writing more code.

socketcluster 3mo ago

I agree that AI does well when the patterns in the code are predictable and consistent. That said it can work surprisingly well with custom frameworks and tools provided that they are predictable and consistent. For example, I created a platform with custom Web Components. Agents do a great job at using the components by reading the docs. I find it a lot easier and more succinct than React. I think it's because AI isn't as good with high level patterns when there are too many pieces involved and too many sub-patterns to apply, it gets so caught up in the details that it misses the forest for the trees. My SDK abstracts away a lot of low-level complexity so that agents are able to focus on higher-level architectural patterns. Also, it's very succinct so agents can fit a lot of context/functionality into its context window. It gets faster and better as the codebase grows. Here's the link if anyone wants to try: https://saasufy.com/ https://saasufy.com/

felixlu2026 3mo ago

[dead]

josefritzishere 3mo ago

AI will make software updates and maintenance much more expensive. Once you're trapped in an AI maintenance dependency, they're going to extract maximum revenue from their captured user base.

ganzsz 3mo ago

We sold a large rewrite to be able to use llms. Our code is such a mess that an llm has trouble implementing new features. (maintainability is still a must, even when vibe coding). So we got a green light to use clean patterns that a llm could extend easily. Of coarse the requirement of using more Ai came from management.

darepublic 3mo ago

Just going to chime in that a year ago chatgpt was really struggling with robot framework. O3 era. Even apart from ai's ability to write working code in it I hate that dsl pseudo semantic bullshit

ghost_pepper 3mo ago

This website has four articles, once daily, three of which being AI crap and doomsaying (the fourth arguably too, it just doesn't say so), all with lines like: > 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.

graypegg 3mo ago
The "Written by hand." in the footer hurts my brain. If it is written using real thoughts and ideas formed by themselves, they've fully imbued their brain with that AI stank I guess. It really does FEEL like unedited LLM output. You can find a few smoking guns or em a few dashes, whatever. But every sentence is emanating the stank.
- Sivart13 3mo ago
  you don't need to be an LLM to have LinkedIn brain, but it helps
  - Bratmon 3mo ago
    LinkedIn brain honestly really disturbs me. I didn't believe in souls until I needed a word to describe what people with LinkedIn brain lacked. Fortunately, then LLMs came along and now if I see a worryingly-soulless LinkedIn-brained post, I can lie to myself and say it was made by a discount LLM.
- Insanity 3mo ago
  They prompted the model by hand.
- ghost_pepper 3mo ago
  That's the sign of a good product: when you have to lie that you don't use it.
- graypegg 3mo ago
  Haha... well it's now changed to: "Written with AI. Curated by hand." Yesterday: https://web.archive.org/web/20260709105821/https://thetruthasiseeitnow.com/ai-slop-starts-with-the-codebase-itself/ https://web.archive.org/web/20260709105821/https://thetrutha...

devin 3mo ago

I don't think it does. (meaningfully change the economics of rewrites) Burning a sea of tokens to arrive at the equivalent functionality and having a small team of people oversee that process is rarely going to be the fix to the organizational problems that surround typical failed/stagnant software projects. Rewrites are rarely about the organization of the symbols and are more often about a change in the fundamental understanding of the organization about the problem they've solving. Remember: People change slowly. People are often too tied to the idea of "rewrite" as a replay of all current capabilities, but should instead be thinking about fundamentally different primitive capabilities of the system. It's not a "redo" if you're changing some of your fundamental assumptions about the problem space.

onlyrealcuzzo 3mo ago
I assumed LLMs should be able to rewrite a small amount of code ~5k dense LoC in Ruby to Rust. It could not. I suspect you'll see a wave of transpilers developed to mostly transpile code from one language to another. You can have an LLM generate a 1-2k or so LoC transpiler that can translate 50%+ of code in place from most languages to another. After doing that, it was able to actually get the job done relatively quickly. I'm working on self-hosting a programming language I've been developing. The transpiler from the original language to the host language is ~12k LoC and translates ~99% the original compiler's ~80k LoC cleanly. The total self-host looks like it might only take a couple of weeks and <$100... TBD.
- metalspot 3mo ago
  An LLM can do this easily if you have a good test harness

llm_nerd 3mo ago

While the article is terrible, what they describe about AI knowing common stacks and frameworks is advice that holds for finding software developers to join your team. Like, 1-for-1. It has always been good advice unless you have a strong justification go in a different direction. Use standard tools, standard frameworks, standing patterns, standard protocols, and so on, and it's incredibly easy to find highly talented members to join your team, running on day one, and enjoy the progress of the industry. It's quite a different tale when you have some massive internal "framework" monstrosity, have weird patterns and standards, and so on, and these are the sorts of places where you usually find some half-baked terrible custom coding language and so on.

clickety_clack 3mo ago

Of course! Just take the code you've taken the time to understand and rewrite it so that it's in a form you have to grok all over again!

overgard 3mo ago

In my experience, most rewrites fall more into the realm of "it's easier to write code than it is to read it, and I don't want to read all this existing stuff!" That's kind of the fundamental motivation, and then people couch it in some very plausible sounding technical reasons. (I don't even think people are being dishonest when this happens -- it's easy to look at a codebase and think "this sucks!" because you don't understand the context behind the original decisions.. and writing new code is a lot more fun than maintaining old code) I'm not saying "never rewrite" things, there are valid cases where the original tech stack is no longer relevant or the accumulated tech debt really is too much, but I'm pretty skeptical of most rewrites at this point in my career.

Pannoniae 3mo ago
Well yeah, for example I'm working on a codebase written mostly in 2003. The assumptions in the original code are at best tangentially relevant (stuff like "LUTs are cheaper than using ALU" or "CPU power is cheap, GPU power is very expensive"). Despite that, a grand rewrite would have failed massively (even with agents...), replicating millions of lines of code to be functional again just sounds like an absolute nightmare. So I've been doing "targeted rewrites" instead - not sure, there's maybe a name for it? Basically do it concern by concern, module by module, so even if lots of code was touched, it only affects one logical feature at the same time.

newppc 3mo ago

Rewrite command and conquers generals for mac

mlinhares 3mo ago

The only economics that change is the full employment for engineers, as they'll be able to create infinite work rewriting systems every year. Its a win/win for the workers!

whateveracct 3mo ago

no it doesn't