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.
This used to be what being a dev was, if I recall. It's been a few years.
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.
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".
Regarding the average developer as an imbecile was a cottage industry from Djikstra to FizzBuzz.
And non-slop parts were maybe some prominent open source projects.
Most bigtech company had an internal joke of "we couldn't ever open source X, not because it can't be done, but it would be too embarrassing"
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.
I'm not sure your experience is the norm.
LiveCoding in CommonLisp.
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.
Also comprehension is one side, its "Consuming" code, but it doesnt say anything about theyre talent of producing great code.
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."
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.
This is a one possible approach/explanation:
https://pragprog.com/titles/swdddf/domain-modeling-made-func...
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.
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.
[0]: https://www.youtube.com/watch?v=P5eO7BNyJao
ADDENDUM
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).
> 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.> 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.
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.
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.)
You're missing the point. Understanding has nothing to do with code.
"Code" is short for "encode", which is an industry term for "encoding a solution". This implies a solution has been formulated before it is expressed in a programming language.
There is no "codebase" without a person or people who understand what solution to reify in the first place.
> A model can absolutely help create understanding in the person overseeing these changes, provided that person deigns to ask for it.
A model can assist a person to gain understanding, sure, but like you said yourself:
... provided that person deigns to ask for it.
By this statement alone, you have proven my point of:
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.The reason code takes time to change is not because changing it takes time.
You have to redo all the testing and relearn all the hard fought and underspecified lessons of the previous attempt. That's what takes the time.
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.
If you did, please do an urgent meeting with your team and dont tell anybody, just fix it. When shit hits the fan, it really hits hard.
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.
I also wrote about internal tools. Not public facing applications. That would be a bit much for my taste.
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's far from fantasy.
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.
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.
Yes, they really have been. It’s exhausting at work.
That's what truly convinced me programming was over: it writes better tests, more thoroughly, then any developer.
Can you help me understand what domain and language(s) you are using here?
This really does not match my experience so I'd love to understand what the differences may be.
Was there an existing good test suite? Is this an application built before LLMs?
I'd love to get more info so I can figure out how to get Opus to do this for myself, as I really haven't had this experience.
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.
AI absolutely solves that problem. Just about every prompt "fixes" the dried out pieces of the code. And it's only getting better at that every month.
Sometimes I feel like people are experiencing AI so differently that it makes talking about it nearly impossible.
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.
Please enlighten me.
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.
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.
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.
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 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.
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).
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.
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.
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.
Dependency is a cause of ossification.
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
You know, I've never thought about that. It's really interesting to consider, especially since refactoring code is now cheaper than ever.
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.
This is not the case as far as accounting and the law is concerned.
Not sure what kind of data this refers to?
Akshually, you can never rewrite your code.