I can write succinct code slowly, agents can write verbose code fast.

Depends on use case

I have a Stackoverflow mode for my agents (essentially a tutor) and sometimes I spend time hand coding but heavily guided by an agent. It helps A LOT to make careful tradeoff when succinct and line by line care matters.

So you're essentially willingly becoming 100% dependent on AI, while praying that hopefully they'll become good enough to save you from the slopocalypse down the line.

Doesn't seem like a good strategy to me.

It boils down to architecting systems.

Using AI is one element for a pipeline that produces code.

If you architect well what you generate then it stops being slop and starts behaving like a cohesive system where code is produced automatically.

I don't think there will ever be a way to "steer" an LLM such that it produces the correct output 100% of the time. You can certainly context engineer your way to better outputs, but you can never reduce to 0 the possibility of the LLM making a mistake, due to inherent limitations of the LLM (perhaps what you ask of it wasn't RL'd during its training), but especially due to the fact that it will often misunderstand requirements and make unjustified assumptions.

So, no, you will never be able to produce code automatically. You can and certainly should use AI as a code assistant to write code faster, but the human should always 1) make all important architectural decisions and 2) carefully review the outputted code

The human bottleneck is necessary.

Not correct but you can plan in the mistakes. E.g: I designed a modular monolith where each module is strongly decoupled so an LLM can work on it individually and if it breaks it can be ripped out and replaced without damage to the rest of the system.

So the system accounts for mistakes and has protocols for removing bad modules/code.

Sure but that means accepting the cost of having faulty modules running in production (and there is no guarantee that your LLM could fix a faulty module, perhaps it will just replace it with a module with different bugs. There's no way to know!)

This obviously won't fly for "serious" software such as airplane software, but I'm willing to guess that even customers of a low-stakes SaaS would get pissed off if your product regularly turns up new bugs.

I think it's easier to just do code reviews...

There are code reviews. At no point did I write no reviews, that's something you inferred.

Both me and LLMs are constantly auditing software.

In-fact auditing and QA is mainly what I do now and human audits become much easier when it's scoped to modules.

> I don't think there will ever be a way to "steer" an LLM such that it produces the correct output 100% of the time.

You cannot do that with humans either.

The difference with humans is that you can incentivize them to try and do the right thing via money. Humans are error-prone and slow, but they don't have an alignment problem, and the types of mistakes they'll make are pretty much understood. There are entire programming languages designed to minimize those types of mistakes.

The types of mistakes LLMs will make are failures of alignment, that is, basically unpredictable. They could fuck up anything. Where a human fucks up by introducing a crash, the LLM fucks up by just not solving the problem you asked it to solve.

It will happen less and less as they get better and better, but as the volume of software output keeps growing, it will happen with a consistent defect rate. And we won't be able to catch it prior to shipping, because humans won't be able to review all the code or verify all the tests.

I don't think anyone's started taking this seriously yet.

> The difference with humans is that you can incentivize them to try and do the right thing via money.

Gen Z has learned that usually, your dedication to work is not tied to the monetary reward.

> Where a human fucks up by introducing a crash, the LLM fucks up by just not solving the problem you asked it to solve.

Have you ever done a group work project at school?

> If you architect well what you generate then it stops being slop

the problem is that the "architect well" part is also being left to the LLMs

This is what I came to post.

For the last 20 years of my career, I have prided myself on keeping a clean codebase, making 'art-not-science' decisions of when and what to abstract, scope boundaries, then implementing them cleanly, specifically to be easily grok'd by other developers. But after building, from scratch, and operating an (essentially) vibe coded software solution (in typically a very engineer led/low level space) over the last 9 months, I am still able to move at super-human speeds in terms of delivering features, investigating and fixing any issues (there aren't many, certainly less than most human teams I've been in) - whether that's because of AI advances or just their innate quality of being able to tackle the dross coding tasks that always got avoided by humans in my past I'm not sure but I'll stick with it until a better approach becomes apparent!

I feel my specialist skills (coding, debugging, devops) has been devalued - I can't justify holding those as my value-add proposition any more - but new skills are replacing those (context/AI/agent engineering) in equal measure.

I think I agree with all you said, but I can’t go of a clean codebase yet. And I’m not sure I should. Or at least not now, not until the agent can better understand what I actually want.

And you’re right, with a bit of direction and further prompting it’s quite easy to get your code in a reasonable shape.

Mostly my hope is that at some point soon the agents will start writing clean code. But then again, maybe clean code for a galaxy brained agent is not actually the most efficient code from token spend perspective.

Might be true in your company, your culture, or in Big Tech.

For a different perspective, the european peers in my developer network, while never outspoken against their company, like, and redistribute content that circle around the same points. Some have fixed mandates to use AI, in order to use AI, working more to keep the product stable (even outside normal work hours), or complains about the divide between management and developer's perspective on these tools.

There is also some consideration about compliance issues and liability when you're stamping commits with your name (luckily for almost all software enginners there is no malpraxis law to punish gross negligence).

> Might be true in your company, your culture, or in Big Tech.

For context, I work in a big tech company with virtually unlimited tokens on the best models, and a lot of tools integrated in our workflows. The culture makes it impossible to go against the wind. Even if you don't want to use AI as much as others, you won't be able to prevent them to do so.

Meanwhile overlooking all the strategic implications of handing off your production to an external service provider, with built-in total surveillance and industrial espionage. All the software shops are turning into lemmings. Running faster into the abyss is called increased productivity. Full speed ahead!

The experience still matters.

I have had experiences out of my technical depth where I’ve instructed an agent to do something technically nonsensical. And it tried to do it or created a mess. Nothing works, I get frustrated, only to realize I have a fundamental misunderstanding of something technical

Fwiw, that's not what the parent was talking about.

You're trying to middle road it. He was talking about actually treating it as a black box, so just give the model your expectations and goals it needs to meet, not tell it a rough solution for it to apply in detail.

Expectations and goals can be technically nonsensical. Agents have gotten really good, but they can’t magically solve intractable problems. If you’re out of your technical depth it can be easy to set unrealistic expectations without realizing it

Then you're still middle-roading it from my perspective. Treating it as a black box means you're only specifying what comes out, essentially.

But to preempt a "I can't do that in my brownfield distributed monolith I'm maintaining at $dayjob": yes, that's why I said it may not be possible without refactoring.

I think we are talking past each other a bit? I’m curious about GP’s perspective here

My point is that you can ask for unrealistic outputs even if you’re treating the system as a black box. This is the classic case of higher level managers asking for infeasible results from their engineering team because they haven’t considered they’re trying to solve the wrong problem. Depends what you’re doing but I don’t think agents tend to push back on badly specified goals unless you’re proactive about it

[delayed]

> Is it an issue? you could think that in the long term it'll be

This raises alarm bells. It's a deeply unserious take on software development that I hope doesn't spread (but I know will). YOLO it all.

We absolutely will regret the slop AI, as it will become load-bearing (ahem) in short order. There will be critical outages and people will die.

That's right. I call it "organic software" --- software that behaves like living organisms --- lots of glitches and flaws but are constantly being fixed by AI agents. 99.8% of users never run into catastrophic issues, and for those who do, a dedicated human/agent will handle it manually.