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.
>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.
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.
I've done two rewrites now with AI. Neither of them particularly large, but still non-trivial; think in the low tens of thousands of lines of code. It's been a bit so I haven't tried it on the very latest models, but I can attest that at least Opus 4.5 does like to sand off the edges and drop use cases without necessarily drawing it to your attention. Based on my other experience with later models I doubt they've changed that much. Partially because in a rewrite, trying to sand off some of the rougher edges is itself a valid move sometimes; if you don't need the crazy complication from 15 years ago maybe you should try dropping it.
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.
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.
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.
If you extrapolate that to the logical conclusion, in the future will we buy software at all? Maybe your computer will just build whatever you need, whenever you need it.
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.
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.
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.
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.
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.
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?
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.
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) 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.
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 2004+ 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 will no follow count and no broetry with our name on it. (search for that word in this thread, just learned it, it's great!)
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.
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.
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
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.
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.
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.
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.
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.
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.
> 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.
Rewriting while changing features is the worst idea ever, which almost always leads to failure, and is the reason why "don't do rewrites" is a widespread rule.
Whether it is humans or AI, the correct way to do it is always a feature exact rewrite, so you can do comparative testing on both systems, and progressive rollout, and then you start adapting features.
Not sure I agree. Having a complete rewrite like you propose is a huge project, and a very scary flip. And I honestly don't see the value in doing it like that. So now you have the same mess as before, just re-written?
Best I've seen it done is to move module by module. So if you want to do "X", you now have to do it in the new system. And the big part of the rewrite of X is figuring out the specs and making it better along the way. Then people also actually want to move.
Moving module by module is definitely the safer way to do it, but at the module level you do the same thing. You have to have it feature exact so that you can replay test against the same interface and do progressive roll out. The difference with AI is that the module size you can one-shot goes way up compared to traditional human rewrite.
> same mess as before, just re-written
The likely path here is probably rewriting from node.js/ruby/python/etc to go/rust/c#/etc so a feature exact rewrite that passes all tests and can return identical responses for replayed production requests is not the same mess at all. You can do all sorts of refactoring, bug fixing, etc, while maintaining exact feature compatibility. The other major thing is back-filling exhaustive test coverage with AI, which then makes agentic coding much more accurate, because the feedback loop from failing tests provides the context for AI to self correct.
A test suite and code are two complimentary representations of the same logic, so using AI to grind test coverage to really high levels (90-95+) gives you two independent inference paths through a model, then the feedback signal from test failures gives you the mechanism to drive these two distinct generation paths to convergence.
A rewrite is like moving house. In the new house, it doesn't have things the way you had everything set up "just right" is the old house. But you now have an extra bedroom and bathroom and no longer have a black mold problem, and most importantly, the opportunity to do things in a new way with hindsight learned from the old house.
The move period has a lot of work ahead to get it back to livable, but also the opportunity to do better than just "livable".
The introduction of AI for rewrites is the equivalent of zero interest loans to housing, reducing the cost of a move. It doesn't mean "keep moving home", it means there is one less factor to worry about if you need to.
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.
It's true for lazy and cynical humans who don't care about the quality of their work, and there are more of those today than there were 10 years ago. It's also occassionally true for people with cognitive or psychological problems. Sometimes a bright youngster is simply green, and has to learn the hard way.
But it really is not "true for humans" the way it's true for LLMs. I've said this before: the most depressing thing about the 2020s AI boom is how certain tech folks explain away the lack of intelligence in LLMs by appealing to ignorant and misanthropic folk psychology.
Fully agree. I tried to refactor parts of a large code base with Fable+ultracode and it just keeps accidentally merging distinct concepts and making up explanations/reasonings that the code base did not contain.
For example, the code base contains a physical controller. It’s closed loop in that it can react in realtime to changes. But it’s a slightly untypical implementation because this one can even look into the future through simulations. But Fable does not understand that. Instead, I need to remind it every 30 minutes that this is closed loop. It keeps wrongly claiming that the controller was open loop and then based upon that it will make up constraints that don’t actually exist.
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).
mostly the problem with coding is the semantic ambiguation; coders like to reuse similar methods, variable names, copy/paste etc; so large code bases have so much out of context simularities that the LLM, regardless of size, isn't
"It is not LLMs fault but you not knowing how to write a prompt". I know I know. But just giving all codebase and saying "rewrite it" is a no go. If e.g. going one class after class LLM will be exceptionally good at keeping the patterns and logics.
I mean it is a tool and you need to understand how the tool works. When there is too little context, where there is so much context so that you are poisoning it, when you are allowing the tool to do patch-on-patch and etc.
The patch-on-patch-on-patch is exactly right, nice way to describe it. It feels like, and I think is, optimized to find the quickest answer not necessarily the right answer.
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).
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.
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.
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.
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.
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
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 [...]
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.
One caveat worth flagging: Your AI slop garbage radar won't work on food (no em-dashes, no "It's not X, it's Y" framing, just quiche). That's a real limitation, so calling it out matters. You weren't considering using it on food, but it's important to note that it won't work in order to burn more tokens. I mean provide you with a well rounded answer.
Want me to plan an app that detects food made from AI recipes?
I’m not an AI skeptic by any means. But I can easily recognize GPT generated output. It’s so formulaic. Of course you’d expect it to be formulaic given what it’s doing under the hood. But it does take the sheen off how impressive the written output looks the first time you see it. And I wonder if it points in the direction of limits on what it can ultimately do.
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.
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.
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.
90 comments
[ 2.9 ms ] story [ 66.8 ms ] threadEh 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.
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.
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.
There is no such thing as maintenance-free software, even as the end user.
Sounds great! Have you tried this? Did you see what went wrong? Otherwise this is just the same nonsense as always.
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.
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.
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.
[1] https://fenwick.media/rewild/magazine/dead-broets-society-be...
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.
Between context collapse and hallucinations, how likely is it that the end result isn't slightly polished slop that misses lots of crucial details?
In that sense, my homepage (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.
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 2004+ 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 will no follow count and no broetry with our name on it. (search for that word in this thread, just learned it, it's great!)
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.
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.
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
If I didn't work on such a team, I would last exactly as long as it took me to find such a team.
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.
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.
Of course it won't quite work, but I can definitely see why some people would want that.
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.
Whether it is humans or AI, the correct way to do it is always a feature exact rewrite, so you can do comparative testing on both systems, and progressive rollout, and then you start adapting features.
Best I've seen it done is to move module by module. So if you want to do "X", you now have to do it in the new system. And the big part of the rewrite of X is figuring out the specs and making it better along the way. Then people also actually want to move.
> same mess as before, just re-written
The likely path here is probably rewriting from node.js/ruby/python/etc to go/rust/c#/etc so a feature exact rewrite that passes all tests and can return identical responses for replayed production requests is not the same mess at all. You can do all sorts of refactoring, bug fixing, etc, while maintaining exact feature compatibility. The other major thing is back-filling exhaustive test coverage with AI, which then makes agentic coding much more accurate, because the feedback loop from failing tests provides the context for AI to self correct.
A test suite and code are two complimentary representations of the same logic, so using AI to grind test coverage to really high levels (90-95+) gives you two independent inference paths through a model, then the feedback signal from test failures gives you the mechanism to drive these two distinct generation paths to convergence.
The move period has a lot of work ahead to get it back to livable, but also the opportunity to do better than just "livable".
The introduction of AI for rewrites is the equivalent of zero interest loans to housing, reducing the cost of a move. It doesn't mean "keep moving home", it means there is one less factor to worry about if you need to.
But it really is not "true for humans" the way it's true for LLMs. I've said this before: the most depressing thing about the 2020s AI boom is how certain tech folks explain away the lack of intelligence in LLMs by appealing to ignorant and misanthropic folk psychology.
For example, the code base contains a physical controller. It’s closed loop in that it can react in realtime to changes. But it’s a slightly untypical implementation because this one can even look into the future through simulations. But Fable does not understand that. Instead, I need to remind it every 30 minutes that this is closed loop. It keeps wrongly claiming that the controller was open loop and then based upon that it will make up constraints that don’t actually exist.
Meanwhile, I have a hard time to believe people don't encounter problems with AI solutions on a regular basis (I do).
I mean it is a tool and you need to understand how the tool works. When there is too little context, where there is so much context so that you are poisoning it, when you are allowing the tool to do patch-on-patch and etc.
(At least the author sprang for a $20 a month subscription.)
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.
Of coarse the requirement of using more Ai came from management.
> 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.
You can find a few smoking guns or em a few dashes, whatever. But every sentence is emanating the stank.
"Written with AI. Curated by hand."
Yesterday: https://web.archive.org/web/20260709105821/https://thetrutha...
It's not just garbage — it's AI slop garbage.
And quite frankly, your AI slop garbage radar is not just an indicator of good taste — it's the essence of humanity that keeps you above it.
Want me to plan an app that detects food made from AI recipes?
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.
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.
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.