Everyone is slowly coming to this realization, and I assure you, no one is running multitudes of agents overnight. No one that is doing anything of substance at least.
There _are_ people pretending to be scientists, or fully caught up in their drug infused AI overdose, that think their slop machines are changing the world. They're not tho, and they're just wasting a bunch of money and compute to create a lot of LoC that will just get thrown away.
The state of the art is still "can we even one shot a production quality patch that we wont regret later", and its rarer than you'd expect based on discourse.
@themoontography@ZssBecker Considering that one of the biggest problem in software history is having too much code and too much features… doesn’t look much good to me.
LLMs have made code cheap.
So now people are spinning up 10 agents working on 10 features in parallel. Sounds productive.
But the tradeoff is obvious: the code quality is often spaghetti + over-engineered.
LLMs behave like over-eager interns. They will do more than asked, add abstractions you didn’t need, and optimize for "completeness" over simplicity.
Which means you end up babysitting anyway.
For anything non-trivial, I have found you still need to spend 1–3 hours upfront:
• defining scope
• writing clear specs
• thinking through system boundaries
• setting constraints
Otherwise, the system drifts.
And even after that, you have to review the code.
They still hallucinate patterns, introduce unnecessary layers, or miss edge cases, even with detailed instructions.
A lot of people advocate "just let agents cook."
In practice, you're often getting 60-70% unnecessary code that increases:
• cognitive load
• onboarding time
• surface area for bugs
• long-term maintenance cost
For side projects, this is fine.
But for real systems with shared codebases, multiple engineers, and production traffic, this compounds fast.
We are already seeing:
• unstable tools
• memory leaks
• constant crashes
• frequent rewrites
This isn't just "early days", it’s a direct result of speed > discipline.
Spinning up 10 agents feels like productivity.
But you are often just pulling forward the cost into refactoring hell.
I would rather:
build slower → keep systems simple → refactor less frequently
Good engineering is still about what you choose not to build.
Cannot wait for teams that build their custom JIRA/Workday replacement/custom CRM to one day turn around and ask:
“Why do we have so much internal software that is buggy / has poor UX + we need to maitain?”
Seen this movie well before AI, when Uber built uChat (custom Slack)
@nateliason Your expectation of AI handling all of your code on its own is pretty delusional at the moment. Therefore, people will still change it manually. Therefore, it must easy to read and change for a human.
@SumitM_X Multiple microservices query the same database? Mmm. Microservices should be indipendent, even from data perspective. That’s the real issue 😉
@Hasen_Judi That’s not the problem that docker tries to solve. The problem is ensuring the environment is the same everywhere, basically removing the “it works on my machine” sentence.
@fidexcode CRUD is just one way to expose data. Better approaches are domain driven (see DDD and Hexagonal architecture). Backend is knowing all of those, and everything else about scalability, data management, ecc - and picking the best option for the current situation
@brankopetric00@rob_ferney That’s exactly where agile/xp/lean can help. They are heat friend of devops - which is not infrastructure, btw. Same as agile is not scrum or sprints. 😉