Code always was, it's supposed to be malleable. It's why it's long been said that code is a liability, not an asset. It's the data you generate with that code that's your asset. You can always rewrite the code.
We, in general, are just very bad at letting code ossify, or for this metaphor, dry out and crumble. AI does not solve this problem and I fully expect to see situations where AI generated code becomes so hard to work with that even LLMs prefer to throw it away and start fresh again.
Code was malleable only to a developer with great code comprehension. In my experience, this was actually very rare. I think part of the reason is, you don't get any recognition for modifying a few lines of someone else's code compared to "I created this new library/app to solve this problem for our org!".
I romanticized even before, because there is a reason why society's view of developers shifted from geek losers to rich in the past 15 years. I remember when 15 years ago a girl told me that I'm different, because I'm not as looser as how she imagined developers.
Thats very true, calling coding craftmansship or considering oneself an amazing coder but only for new projects is obviously wrong.
A great coder loves legacy old projects because theyre challenging, unpredictable, undocumented, and if you figure out, you are like a God.
Starting the perfect greenfield project and writing amazing code the first week is a skill every freshmen student at a CS college has. That's not a problem area, its a solved thing.
But do it for 10 years straight after 5 acquisitions, different infrastructure, different industry, language, culture? You are a RARE BREED.
Or even simpler put, never measure yourself with easy things, only with the hard ones since then the easy things are a joke.
> But do it for 10 years straight after 5 acquisitions, different infrastructure, different industry, language, culture? You are a RARE BREED.
Been there done that, the problem is you will not get rewarded by your superiors. Keeping old shit alive is useful to keep your skills sharp, but it's bad in a culture utterly dominated by "resume driven development".
And often, it's not the code that is the issue. You understand the code perfectly fine and can edit it easily. The main issue is always finding out the "why" so you do not remove any Chesterton's fence while coding for a new change request.
Did the delivery work functionally as expected? If yes, then they understood what they need to understand to do that work on code. You don't need to understand the whole codebase, just the parts relevant to the work at hand.
Ive worked and work with people who I dont consider super talented but sure as hell they understand the code, maybe just some lines, maybe the method, maybe the class, maybe the module and further.
Unless you worked at the shittiest company in the world, lets try to not bring others down just because they weren't as amazing as we are. They might have other skills weve lacked.
E.g. like a journalist complaining that they colleagues didn't publish books... who cares? Thats not their job, they need to write clear good concluded articles. If they write their articles like books, nobody reads that shit.
Many people here are saying "code was always malleable", "code was always clay". But how many actually do their work in live interactive REPLs, which I'd say is the truer analogy?
I disagree. Code can be/was more malleable if it's designed well, especially with pure FP. People kept on moving away from messy abstractions and OOP and more towards this idea of pure functions and composition, creating more robust and malleable software.
Now instead of aiming for robust, malleable code, people are throwing up their hands and saying, "It was always a mess, let's just keep throwing more tokens at it."
Yeah, people said "I'll use javascript and python because it'll help my velocity to forget about types" and then went back and reinvented types and functional programming in both. And now they're so confounded by the pile of confusion that they're yielding to LLMs.
If a dev just followed public trends, then I guess I can see how they came to the conclusion that this is the best way out, because their baseline level of comprehension is so far in the floor. It's like circling around the entrance of a maze for days until finally an AI merchant shows up near the door, and they say "well clearly, the only way to get out of this maze is to pay the merchant for his fancy roomba to carry me out" instead of carefully mapping your way through.
From a selfish perspective, that's fine by me. I've built up skills that I don't think will be replaced in the near-term, and in that same period most people will end up de-skilling. The only downside is that I've had to shrink my circle that I collaborate with even further.
We tend to forget in tech-oriented forums that most of us are bound to those who pay our salaries, and for many developers that payment is to be focused on revenue-generating, or client-focused work.
Developing advanced comprehension and being able to use it for long-term system stability are unfortunately not always paired in the daily work.
The big trick always was to limit your scope. If you can't do that or if your tooling doesn't help you with that then very quickly you will run into the limits of what you can still keep in your head.
That sounds a bit extreme, to me, I think code was always malleable simply from good experienced devs. The "developer with great code comprehension" just did it better I guess but it wasn't a skill shared only by the holy Coder chosen by Destiny or something.
Also comprehension is one side, its "Consuming" code, but it doesnt say anything about theyre talent of producing great code.
The point is that previously, changing code in a major way might take months of refactoring. Large changes were simply not contemplated unless they were justified by similarly large additional profit. Once you designed your architecture, you were pretty much stuck with it.
Now, the kinds of changes that were simply unrealistic before are now entirely realistic. A refactor/migration that would have taken 6 months before, you can now get a working version done in a day, and another few days of QA. That's what this post means -- code is no longer stone, it's clay. You can change it quickly in ways that were previous unimaginable.
This has nothing to do with the concept of code being liability or asset -- that's a totally separate conversation.
I've been able to execute several highly niche, large scale refactors in a production system in the last 6 months, entirely enabled by AI tooling. The kinds of changes that individually by hand would have taken months and you would never get top down approval to do because it would take paid developer time away from client-focused work.
This has stabilised the system, fleshed out unfinished ideas, expanded testing capability, introduced new developer-experience oriented tools, and refactored sensitive systems to be more flexible for future use. Not to mention addressing the kinds of uber-niche tech debt that would take years to bite and months to fix.
It might depend on your use case. Life threatening bugs in a plane? Your argument holds up.
Letting an llm rewrite your internal todo tool, in another language, better design and up-to-date software stack. Yeah, this is absolutely not a fantasy anymore. We got rid of most SAAS tools in a month. Complete with Keycloak, behind wireguard, pocketbase backend, in our cooperate design with exactly the features we want. It works flawless since day one.
This is outdated news though. It's cope. People are out there telling themselves "well it's insecure". That was true. The AI models are better hackers then humans now though. Red teaming your own code with AI will produce a better penetration test then any developer trying to implement OIDC.
And frankly...have you tried configuring Keycloak? It is a gigantic "do everything app". The idea that it's going to have a narrower attack surface is basically fantasy.
Maybe for absolutely massive refactors? But if you've got a good test suite and a capable LLM, most refactors are ... almost enjoyable, now.
I think this is what TFA was getting at -- what was once hard or impossible, and an absolutely massive headache to conceptualise, is now surprisingly simple and straightforward.
Definitely fantasy esp "6 months to 1 day". That's just impossible physically.
Did they even sit and thought deeply before they wrote this comment or have people really just started putting out slop everywhere due too much usage of AI?
The code that was produced in 6 months before cant be even read in 1 day today so dont get me started on properly functionally producing it.
> The point is that previously, changing code in a major way might take months of refactoring.
> Now, the kinds of changes that were simply unrealistic before are now entirely realistic. A refactor/migration that would have taken 6 months before, you can now get a working version done in a day, and another few days of QA.
Significantly changing a system implementation is a function of understanding, not time.
Given a starting solution state being A and a desired functionality state of A', the tooling used to codify the A -> A` delta is largely irrelevant. Specifically, in order to successfully deliver major product realignment requires awareness of what exists currently and understanding of what needs to be.
Code is neither stone nor clay.
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
> Significantly changing a system implementation is a function of understanding, not time.
> Specifically, in order to successfully deliver major product realignment requires awareness of what exists currently and understanding of what needs to be.
And this is exactly what agentic coding brings to the table in spades.
Agentic coding does not create understanding in the people tasked with altering a product to provide significantly different functionality.
In order for agentic coding to be a net positive, the instructions given to the AI offering must be from people who understand what a system currently does as well as what functionality a product needs to provide in its future desired state.
Agentic coding does not solve these fundamental concerns.
I don't disagree with wanting people to understand the product they're altering.
But whether or not this is actually needed or not now, I'm not so sure. LLMs are very good at parsing a codebase, discovering what needs to be changed to provide different functionality, suggesting any architecture changes that would be needed to do so, and ultimately implementing those changes within the bounds of an existing test suite.
I sadly suspect that if it's a choice between throwing a person or an LLM on an existing large and complex codebase cold, it's now safer and faster to use an LLM in many instances. Much better still to have someone with knowledge and understanding of the codebase work with an LLM, of course. But we're getting to the point that you can do a lot with little to no human knowledge at all.
(LLMs are also very good at bringing you up to speed with a large and complex codebase. A model can absolutely help create understanding in the person overseeing these changes, provided that person deigns to ask for it.)
I was watching the most recent Rich Hickey talk[0] and at the start, he talks about correctness and the difference between the internal machinery of your software (which can be finely specified) and handling the external world (which will always be messy).
Good Architecture will try to isolate the two. You got the internal logic which is either the business domain abstracted away. And you got the highly volatile part (request from frontend, new integration, new drivers, deps update,....).
If you've done that, migration/refactoring, unless it entails some unlikely core changes, will not take that long. It's just a matter of dropping that part and replacing it (like changing a car's brake pads or steering wheel). But the actual core mechanism will hardly change over the years.
To go with the thread flow: It's a stone core wrapped by clay.
In regards to separation, one of the best example in mind is the OpenBSD kernel code. The OS concepts are in /kern, while each architecture lives in /arch. There's an horizontal separation between machine independent code (core idea of Unix) and machine dependent code (The hardware platform). It can also be found in the various subsystem like audio (the concept of a sound card) and implementation like uaudio (usb interface) and azalia (Intel's HD Audio).
Yes, well-designed code is malleable to an extent when coding by hand, but even then it's an order of magnitude more rigid than when working with agents (and real-world code often ossifies, as you pointed out). Malleability comes not only from the possibility of change but also from the speed.
> It's the data you generate with that code that's your asset. You can always rewrite the code.
I like that perspective, but "you can always rewrite the code" almost never happens in real life for complex projects, and when it does, it's a huge undertaking that takes many months or even years. Malleable code makes that much more feasible, I'd argue.
Rigid implies you are trying to change something into something else in a controlled way. Eg a refactoring that does nothing but enable for a future feature. Agents does not change code to refactor anything, they write code to solve the new feature directly. And if you are good at prompting they might overwrite code that exist so that the end result looks like a refactoring. But no clay was reshaped.
That is...not at all my experience of Opus 5.5, which has absolutely both spotted weird workarounds, then spotted the underlying bugs which were leading to the workaround, then spotted the race conditions which were masked by the workarounds.
It's hard to say because no one actually describes what and how they are doing to get AI to successfully refactor or operate in large code bases.
My experience is, slop on slop. Frontier models still can't handle even modest sized refactors without explicit hand holding. I still don't trust models with production scale refactors.
Apparently, everyone has the magic sauce and I'm blind. Or our definition of quality and production grade is very different.
Some misc advice. Your first task with ai is to use it to build constraints and guard rails for the ai.
That probably means a test suite that is at least twice the size of your code base. If you started there, great, but increase it to integration and benchies if you’re mostly holding units. It actually helps a bit if you can use a different language for this too but it depends on project, ymmv.
After that you have to either let go of certain style/idiom things or enforce ruthlessly with deterministic hooks everywhere.. no middle ground there and prompts will never work.
You also need to deliberately channel chain of thought with workflows rather than hoping for the best.. most of the generated product here shouldn’t be committed or preserved at all.. non-public doc flows and ticketing systems help.
Like people, an ai can easily create code that it cant actually maintain. It’s a matter of discipline now, same as before. Always using the smartest model is wrong, but double wrong on “wide” changes like a big refactor.. it leaves you no good options if you get into trouble.
> That probably means a test suite that is at least twice the size of your code base.
If you've got a test suite that's twice the size of the code base then those tests are almost certainly tied to implementation details and will make the code a lot less like clay.
Is this always true? I'm honestly not sure. For unit tests I completely agree with you, for integration tests I'm not so sure—validating permutations does not necessarily couple you to code, and may in fact be good discipline for user expectations.
Truly spoken as someone who has never worked with legacy code. You know, the kind that's still running Java 1.something when Java was already doing full numbered releases.
The kind that works, but everyone who knows why has left the company. The whole codebase is written in a way that makes automated testing either impossible or so time-consuming that the client will never pay for the required refactoring.
There is way too much code in the world we never were able to rewrite due to real-world concerns. There were people who had the skill, but a part of that skill came with knowing the risks of doing major refactoring to a money-generating system that is ancient, but still works.
Anecdote: I had to work with a system where the original coder (long gone) had rewritten Linked Lists with their custom solution that worked normally except the first X items were the sum, average and mean of the data. Fun times.
Maybe, but I think one of the points is that the marginal cost of both understanding that legacy code base and safely refactoring it are increasingly trending down thanks to agentic coding tools. It changed the value and risk tradeoff for legacy apps, if deployed properly. There's still a lot of work (too much) to get the harness in place to make high confidence changes to legacy, critical apps. If someone makes that more automated, we'll be in a very different place for legacy refactoring and it will look a lot more like the clay molding the article discusses.
As with anything LLM-related, I feel compelled to ask, is that actually what's happening, or are they just successfully convincing their users that's what's happening? I truly cannot tell.
I'm not using any LLMs directly (my workplace still bans them in-house) and my experience on the receiving end of contractors using them is quite poor. That includes one major, "we'll replace your ancient software with shiny new stuff"... with significantly reduced capability that in turn makes everything far more difficult than it was or ought to be. The UI appears much more user friendly, but really is just broken in multiple ways where the much-patched 1980s software it replaced was user-unfriendly but largely worked.
This all could be the result of poor coding, regardless of LLM use, of course.
> The UI appears much more user friendly, but really is just broken in multiple ways where the much-patched 1980s software it replaced was user-unfriendly but largely worked.
LLMs don't magic away the need for careful and extensive testing. Good code still takes a lot of time. But it's also a lot less time than before.
I suspect a lot of problems come from people trying to one-shot entire apps, or from those who do not have the relevant experience or knowledge to understand that close-with-a-nice-modern-GUI is not nearly good enough.
With this new-found capability, you can use an LLM to plan and execute some long-needed refactors, or use it to pile on new features even faster with no regard for tech debt management.
As others have said... it's a tool. A powerful tool in the hands of a wise and skilled wielder who makes planned, focused changes, or a slop-cannon in the hands of someone who is happy to churn out features with minimal understanding of context or system design.
I've been able to do relatively big refactors with great success, like porting thousands of lines of data transforms to drastically different data stores practically in one fell swoop. In the background. As I worked on other stuff.
The cost of experimenting is just mind mindbogglingly cheap now, it's really insane. Don't like the abstractions it comes up with, or think it generated a bunch of slop? Go again, who cares? With a little more steering, they'll often produce exactly what you want.
As for contracting firms, many of them were slop shops before AI, I imagine those kinds of firms are even worse slop shops now.
> I've been able to do relatively big refactors with great success, like porting thousands of lines of data transforms to drastically different data stores practically in one fell swoop. In the background. As I worked on other stuff.
This is a great use case, as you have ground truth to compare to. LLMs are phenomenal at this stuff. Where you don't have this is where they are less successful (in my experience).
We can fully solve 'code' in the sense we can model every single interaction and then use that specification to produce another program that does the exact same thing, and then based on inputs, it should be possible to cull that tree of possibilities even more.
That is my hope anyway, apart from that, I do think there is an inherent laziness in business to not mess with the machine that makes money.
> Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by the exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.... https://home.adelphi.edu/sbloch/class/adages/joy.html
> Code always was, it's supposed to be malleable. … You can always rewrite the code.
This isn’t capturing the spirit or the essence of the metaphor. chipping away at marble or whittling has this locality to it that’s keen but myopic. Molding with clay isn’t so detail oriented, you can literally close your eyes and focus on shape, same with turning on a lathe although I wouldn’t suggest closing your eyes.
there is such a thing as being precise without being detailed or local. Before LLMs you did this with test suites techniques maybe, and a few automated refactoring tools, CSTs and AST work, sometimes macros and other metaprogramming. Yeah it happened but fair to say it was rare and difficult. Everyone is/can be a sculptor now
It's not just about malleability. It's about specificity. A prototype has to specify certain details to run at all. This is not really true of sculpting in clay (former sculptor here). What the article describes of a sculptor working from big forms to smaller forms and so forth is in contrast to what it feels like to code by hand, which always requires some thought for the details even if the details are going to change dramatically as the program goes from prototype to hardened production software. The programmer always had to have their hands on the details even as they thought about architecture, but that's not the case now. Now we really can work from primary masses to increasingly specific details.
Working code that people pay to use is of course an asset. If it is a liability then just delete it all an have no source code an you just paid off a debt for free.
An expression that stuck with me from the Domain Driven Design book is "supple design". Achieving supple design (and thus supple code) is a goal, but it doesn't come for free - it requires a lot of work. I'm trying hard to get agents to create supple design - or at least not to make my own designs less supple - but it's not easy, because they have a tendency at overcomplicating and overengineering code.
This. Since forever was I told that the term "software" was coined because, contrary to hardware, it was easy to change, adapt, and mold into your needs.
I'm very surprised to hear people in this day and age claim it wasn't.
It's unclear what they'll be classified as and probably comes down to some negotiation and lawyering to decide how restricted they are. You can sell a lot of restricted hardware to US citizens that you can't sell internationally due to ITAR.
Cold gas thrusters are big pressure vessels that vent through nozzles. You can build one in your garage and propel yourself on an office chair. People put them on drones for fun.
I mean it's pretty clear that OpenAI does not want "safe" AI. That is far too much work and effort that's preventing them from moving fast and creating their computer God.
And OpenAI does not care who they hurt in the process (as long as it's not themselves).
I will accept the "bad things" if and only when Sam Altman exposes himself to those bad things first e.g., living next door to an AI data center, being subjected to 24/7 surveillance, and having everything he says and does scrutinized for illegal activity, ticketing and jailing him appropriately.
Until that happens, no. Sam Altman is here telling us to accept the cruelty of his actions and his company so that he can be more wealthy.
I don’t think he needs or wants any more money. These guys already have so much moolah that it is virtually meaningless to them. They want power. Remember when Zuck tried to run for president?
It is described in Sarah Wynn-Williams’ book. According to it, Zuck even battled to change the stock structure in order to take 2-year hiatus from CEO duties:
…without losing control of the company if his absence is “in connection with his serving in a government position or office.” I assume the two years would cover the period Mark would be taking on the—presumably time-consuming—endeavor of campaigning to be president of the United States.
Especially in a world that's been programmed to believe wholeheartedly that money is literally the most important thing in the entire universe, and these people who worship it as a god will never be satisfied with any amount of money; even when the last human alive owns all of it, they'll still want more. It's a form of mass-insanity. The Cult of Money.
The data center thing is a complete red herring. Of course you wouldn't want a data center literally next to your house. Neither would you want to live next to a manufacturing plant making automobiles or batteries or solar panels. This doesn't mean we should want to outlaw manufacturing plants.
The complaints about water consumption are even worse. Nationally, the amount of water consumed by golf courses is orders of magnitude larger than the water consumed by data centers.
I say this not to defend OpenAI or Sam Altman. I say this because I want the focus to be on the real dangers posed by AI:
* Power consumption (mitigated by building more power generation capacity, but this is a real impact, and there are legitimate environmental concerns)
* The disruption AI will have on people's careers and livelihoods
* The concentration of political power in the hands of a small cadre of billionaires
* The potential for truly dangerous destructive power if used by malicious groups - eg. bio-terrorism.
We should be concerned about the "bad things" posed by AI. A data center next to your house is very much a local issue, not a national issue.
> being subjected to 24/7 surveillance, and having everything he says and does scrutinized for illegal activity, ticketing and jailing him appropriately
That thing has been rising for decades - why should Sam Altman now become the culprit and scapegoat?
That of surveillance and the use of pattern matching is a legislative matter (not e.g. a matter of regulating RnD, which I understand as more relevant to this submission).
I think that there is something to what you are saying, but I don't think it is that simple. A new technology could change things by making previous abuses much more common. To give an extreme example, mass murder has always been possible; however, we restrict nuclear weapons because they make it so much more easy and therefore so much more ripe for abuse.
Similarly, there is a big difference between the police keeping a physical record book of mugshots, the police employing experts to maintain a database, and AI allowing nearly anyone to perform in depth surveilance.
> and AI allowing nearly anyone to perform in depth survei[l]lance
Which, as I have said:
-- is a field that has been developed for many decades - automated processing is classical AI. Why should it be now attributed to Sam Altman, whose company mainly does LLMs. If Sam Altman shouts "little risks much reaps", I would not think as surveillance as the first relevant rebuttal.
-- if the peoples do not want surveillance (what awakened them, a large number of places that were supposed to be civilized are cashless societies now), that would be a political matter, from which consequential legislation should be the goal.
Anthropic commits literal felonies by stealing millions of books and violating Copyright like it doesn't exist: no charge.
One unfortunate woman who happened to write the wrong thing in the wrong place is now having her life turned upside-down for perceived thought-crime.
To Anthropic, and all employees working there, your company's product and the result of your work is cruelty. You are enabling it and pushing it down everyone's throat. You can never again claim that you are the "ethical" AI company, for no such thing exists.
I saw a mention that the lack of hurricanes is going to itself be a big problem. Hurricanes are an important way to remove energy from the oceans. Without them, the Atlantic will get significantly warmer, and when storms do form, they are going to be massive beasts.
We are definitely in the "unknown, but it probably won't be good" territory.
> Anthropic said nearly a quarter of its revenue came from two customers last year, and as part of its risk factors, warned that many of its largest clients were not locked into long-term contracts and could cut or stop spending.
Why xAI? They have no market share and their own data centers are over 90% idle/rented out to the other AI shops, so it's more likely that the money flows in the opposite direction.
Is it possible those are cloud providers? Someone using Claude on google vertex might just switch to Claude on AWS or Anthropic. Also I don’t imagine cloud providers suddenly cutting the cord.
No-one has profited off of Bitcoin and crypto currencies as much as North Korea has. The absolute windfall of stealing literally billions of USD through this will be in history books for decades to come.
This is a strange statement because by definition the innocent don't need mercy. Mercy is forgiveness for wrongdoing, and refusing to forgive and give mercy to some leads to a society that is cruel. As Thomas Acquinas put it:
> justice without mercy is cruelty; mercy without justice is dissolution.
Yet government wrongs normal people who have done nothing daily. Subjects them to crime through ineffective justice, taxes them, criminalizes behaviour that rational people would consider not to be criminal, etc...
In my country they'll try to prosecute you for longer jail sentences if you criticize the government than if you kill someone...
Look at the UAE, no income tax, only 9% corporate tax, GDP per capita higher than most of western Europe, and three of the top ten safest cities in the world (https://worldpopulationreview.com/world-city-rankings/safest...). GDP projected to grow 3% this year in spite of being bombed and having its main export waterway blocked. Literally over 100x lower chance of being sexually assaulted there than in the UK or France.
Given a bunch of cultural considerations in the UAE, I highly doubt that the reporting rates of sexual assault in UAE is comparable to that of France and UK. "Marital rape" isn't a thing in UAE; nor is consent generally legally codified. UAE has a history of laws against extra-marital relations; rape victims could face legal counter-charges.
Also, the legal definition of what a sexual assault is vary widely across earth making apple to apple comparison difficult. In addition to the reporting problem. Safe is hard to measure.
> Human Rights Watch has reported on the country's ongoing unfair mass trials, restrictions of freedom of speech and abuses to migrant labour forces.[217] The annual Freedom House report on Freedom in the World has listed the United Arab Emirates as "Not Free" every year since 1999, the first year for which records are available on their website.[218] In 2025, the country ranked 18 out of 100 in terms of the freedom index, due to a lack of free elections, lack of government transparency and accountability, and a lack of free media and independent judicial system, and low scores against other metrics.[140]
> At the same time, the UAE has made it illegal to disseminate online material that can threaten "public order",[375] and hands down prison terms for those who "deride or damage" the reputation of the state and "display contempt" for religion. Journalists who are arrested for violating this law are often brutally beaten by the police.[376]
> Freedom of association is also severely curtailed, and in most cases, banned under existing law. In the UAE an association requires twenty individuals, none of which can have previous convictions and must be preauthorized and registered with the government.[219] All associations have to be submitted to censorship guidelines and all publications have first to be approved by the government.
Are you one of those technofascists who wants to trade everyone else's privacy and freedom all in the name of "security" (read: repression of the masses) for the elite?
Because, with your comment, it surely seems that way.
Furthermore, your source is garbage. No methodology at all, and if you click around to try to get what might be methodology, you instead get popup spam for malware. For fuck's sake get some actual data to underpin your opinions.
I think you've actually made my point for me with your example, thank you.
We, in general, are just very bad at letting code ossify, or for this metaphor, dry out and crumble. AI does not solve this problem and I fully expect to see situations where AI generated code becomes so hard to work with that even LLMs prefer to throw it away and start fresh again.
reply