by ghost_pepper
3 subcomments
- 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.
by matsemann
8 subcomments
- 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 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.
- Does it really change the whys of rewriting?
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Maybe the LLM will catch and reproduce all corner cases... maybe not...
- 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.
by clickety_clack
0 subcomment
- 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!
by SunlightEdge
0 subcomment
- 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).
- 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.
- 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!
by bad_username
3 subcomments
- It also changes the economics of buy vs build.
by socketcluster
0 subcomment
- 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/
by lazy_dev_1_to_9
2 subcomments
- 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.
- 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)
- The problem is always maintainability. Who's gonna fix new bugs? Who's gonna add new features?
by 2001zhaozhao
2 subcomments
- 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.
by light_hue_1
0 subcomment
- 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.
- Rewrite command and conquers generals for mac
- But can AI rewrite better over AI clop made by itself?
- 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.
- 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.
by darepublic
0 subcomment
- 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
- 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.
by whateveracct
0 subcomment
- no it doesn't
- 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.
by josefritzishere
0 subcomment
- 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.
by DubiousPusher
0 subcomment
- 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.
by retinaros
1 subcomments
- First three paragraphs and I can tell its opus 4.8
by reinitctxoffset
1 subcomments
- 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.
by felixlu2026
0 subcomment
- [dead]
Hacker News