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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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 [...]
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.
35 comments
[ 3.9 ms ] story [ 56.2 ms ] threadhttps://www.joelonsoftware.com/2000/04/06/things-you-should-...
Maybe the LLM will catch and reproduce all corner cases... maybe not...
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.
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.
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.
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.
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.
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.
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/
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.
It's not just garbage — it's AI slop garbage.
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.