The LLMs know design principles too, being an experienced developer doesn't make you as special as you might think.
Sometimes, not enough to believe you that you can do it better. And even if you could, to believe that it's overall worth it to work in that way.
It seems too early to make any conclusion like that. We've still only been doing agentic coding for a year and capability significantly improved during that time. I don't think anybody on either side of this debate can have actual empirical evidence to support conclusions about where it lands longer term.
The main argument I see is that it probably pays to be slightly conservative because the cost of being wrong by maintaining too much oversight and shipping slightly less code is better than the cost of ending up with an entirely unmaintainable system. In some cases it will be more than "slightly less" but in almost all complex pre-existing systems, you are rate limited by a lot of other factors outside of code production, so the effective difference just isn't that high.
And it's debatable how much better they will get quickly. Verifiable rewards for maintainability of software is, I think, possible but very hard.
I also see devs, seniors as well, that have a different experience. At least that's what they say. I stay open to the possibility that I'm doing or seeing it 'wrong', but I'm far from convinced. I do like to experiment like you wrote in a later comment, things may change, and even now I do find it can be very powerful, for the right tasks.
It still applies to all things LLms can do from law to code to art to ideas.
They can do it - and very acceptably - but only to the untrained eye.
Obviously there are mission critical systems where it matters, but if “your code can be A/B tested” or “slowly rolled out”, chances are, it doesn’t matter.
Tech debt is still tech debt, even if there exist models that can wade through, because it's going to require increasingly sophisticated models navigating increasingly large context windows and increasingly speculative workspace operations to keep making progress on it.
Vendors like Anthropic and OpenAI are laying a pit trap when they demonstrate how their models can independently code their whole platform as it becomes increasingly byzantine and inscrutable because not only do they benefit from internal/prerelease models but they have effectively unlimited spend because all that spending acts as a lure to draw you into their trap.
For everybody else, design still matters. People are just working really hard to make you forget.
There are legitimate FAANG-like companies that have general guidelines about “when to use Fable/GLM/DS” and etc. to keep the costs down. And I think it’ll continue that way.
https://www.cnbc.com/2026/10/11/ai-software-developer-jobs.h...
Doesn't matter as much. The cost of "maintenance" is going down, from what I can see internally, from other companies, and every story i'm reading from other organizations as well. Token budgets are changing, but model quality and effectiveness are going up as well.
> We've also been hearing for years that LLMs are going to automate away software development entirely, but software job postings are steadily rising.
I think this has been contested from day 1. SE jobs might be automated, but jobs might increase, if there's possibility of starting new companies / new investments / etc.
The analogy would be math people with AI vs. non-math people with AI trying to solve some problems. I cannot solve the problems because I have no idea how to prompt it to go specific way. But it doesn’t matter how dirty your scratchpad was, because you got to the solution.
> I don't see it happening on projects that have a minimum bar for security/reliability and long-term maintenance
I don’t get this, because this is currently, right now, at this second, happening across huge projects. My point was that maintainability is less of an issue than before. Also, frankly, over years, I’ve seen bad code that AI wouldn’t even write. So there can be a case that the maintainability/code quality isn’t even going down as the models get better.
You're also find that implementation matters when token spend starts facing real accounting.
I really wish people would become more coherent with their reasoning.
Cost of tokens is NOT a problem unless you have a codebase with hundreds of person-years of effort. Not many people do.
It may encourage more secrecy and backend style designs though.
That said, I also feel like betting on readability, maintainablility, taste, etc, being an important aspect of software, at least until code will remain some sort of human readable artifact. We'll still want to be able to understand it and perhaps occasionally add/edit by hand, make sense of it without trusting blindly what any kind of program (LLM based or not) will tell us about it, and so on.
These things are important even in a repo with zero human code. A project that's filled with tech debt will always be hard to work with no matter what latest frontier model you're using.
I think a lot of this can be automated with slop detectors that flag messy unreadable code and make agents rewrite it, but you can't say it doesn't matter.
1. We are working on different types of application and code.
2. I am in a bubble and no-one in it has experienced the standards and productivity that SOTA AI tools can achieve.
3. The advocates are in a bubble and no-one in it has experienced the standards and productivity that expert developers can achieve.
I hope the answer is 1. I fear the answer is 2. I suspect the answer is 3.
They are only as good as their training data.
I expect them to have badder taste for PHP or JS, than, say, Kotlin or Ruby.
That's be because I prefer the code the latter communities have produced over the former.
Way to come off as incredibly insecure. There's no need to randomly put people down.
That's it. Maybe you should go re-read?
The advantage I have is that I know things that are not in the training distribution. Things about our business, our product, and its internal architecture. Without this knowledge, some new features cannot be designed successfully.
Some day I expect that will change, but all the patchwork "memory" systems, all the docs etc, will never get there because at some point they just pollute context. Knowledge has to be integrated, and that is what happens during sleep for humans, during pre-training and RL for models. LLMs are terribly inefficient at learning though and degrade generally during fine-tuning.
That certainly can be true but I would challenge "generally". If you're working on something novel then it's not exactly unusual for even SOTA models to produce a first attempt that makes some very bad assumptions but then get stuck when instructed to use correct axioms instead. This looks a lot like the suduko meme - without any real insight into the problem the models end up just iterating around in circles and never finding a solution.
You probably won't see this very often if you're working on simple CRUD web applications where there are millions if not billions of lines of code in the training data set. IME you will probably see it quite frequently if you're working on - for example - software to control some kind of equipment or analyse the results of some kind of experiment where the LLM might have little if any training data about the field you're operating in.
Not any time. Your feedback loop must provide some direction so the iteration is at least heading towards an improvement. For novel applications you might not have a convenient way to do that yet.
Even with that provision there's still a possibility of incrementally updating output converging on a local maximum. That local maximum might not be a solution at all. If it is a solution then the model might still miss much better solutions that a real developer with more insight might find.
As you said yourself the models need external feedback if they don't have sufficient information to make adjustments by themselves. In some cases that feedback might be "Start again because you're hopelessly off track". Sometimes even when they start again they just get hopelessly off-track again. That can happen even if they are explicitly prompted to do something else. So even closely supervising the LLM and not using self-iterating agents isn't guaranteed to get good results for novel applications.
You're right though that in new territory you may often have domain experts who still cannot adequately define success in an automated fashion because this is literally something that hasn't been created before. So they must be a part of the loop. They cannot necessarily put into code and descriptions what "better" or "right" is for an LLM to follow. But they can recognize it when they see it. In this case, it's still best to create the tightest feedback loop you can. If the LLM is waiting 2 days for your feedback, the loop is 2 days long.
I would say that a system with some sort of binary evaluation that indicates whether it succeeded or not is receiving feedback. It could also be some kind of sliding scale - how close did it get?
Either of those might be useful for determining a good future direction to iterate in but that would surely depend on the nature of the problem and how it's possible to search for solutions. I'd still call it a feedback loop even if the evaluation wasn't enough to point in a specific direction for a further iteration though. YMMV.
For example, Li et al. (2023), Emergent World Representations, showed that a GPT model trained only to predict Othello moves developed an internal representation of the board state, without being explicitly taught the rules or board structure.