Are We Still Pretending Coding Was the Bottleneck?

AI has changed a lot of things in software development. But if you’re shocked that it can write code, you’ve probably misunderstood where the real constraints are.

Let’s be clear: coding was never the bottleneck.

If you’re still organising your system of work like it is—managing capacity by developer headcount, measuring velocity in story points, handing off tickets from BA to Dev to QA—then AI isn’t going to save you. It’s going to expose you.

The First Way of DevOps Was Always the Warning

The First Way of DevOps is Systems Thinking. It’s the relentless focus on flow, from idea to delivery. Not just within development, but across the entire value stream.

So why is everyone panicking about code-writing agents?

Because most organisations never understood the First Way in the first place. They thought DevOps was about pipelines, YAML files, and infrastructure automation.

They forgot it was about fixing the system.

AI isn’t breaking your delivery model. It’s just revealing how broken it already was.

If You Map Your Value Stream, the Bottleneck Isn’t Where You Think

Do the work. Map your system. What you’ll likely find is this:

• Work sits in queues waiting for “clarification”
• Teams are blocked by signoffs, dependencies, or overburdened specialists
• Test feedback takes hours, days, or never comes at all
• Quality is gated by QA teams, not engineered into the product
• Your best developers are busy merging branches, not solving problems

In that mess, how is code ever the constraint?

AI Hallucination? Or Garbage In?

Yes, AI sometimes generates code that doesn’t compile or misbehaves. But let’s not act like human-written code is immune to those flaws.

Garbage in, garbage out. If your acceptance criteria are vague, your architecture is a mess, and your quality is outsourced to downstream testers, you’re giving AI the same bad inputs that led you here in the first place.

You don’t fix that by blaming the tool. You fix that by adopting disciplined engineering practices:

• Test-First development so intent is explicit
• Observability built in from the start
• Definition of Done that includes operational readiness
• Autonomous teams accountable for outcomes, not output

The problem isn’t the LLM. The problem is the system it landed in.

QA Is Not a Team. It’s a System Responsibility.

If you still have a separate QA team running tests after “dev is done,” you are perpetuating one of the core dysfunctions that made DevOps necessary.

Quality is not something you inspect in later. It’s something you build in from the start—with design, pairing, automation, and feedback.

AI won’t fix this. But it will make it more obvious.

So How Do You Test AI-Generated Code?

The same way you should already be testing human-typed code:

• Write the test before the code
• Make quality part of the Definition of Done
• Deploy frequently, observe outcomes, adapt fast

AI doesn’t change that. It just removes the excuse that “we didn’t have time.”

If You’re Still Blaming the Tool, You’re Not Owning the System

AI isn’t the enemy. Your culture is. Your delivery model is. Your lack of flow is.

If your teams can’t ship working software reliably today, AI isn’t going to help.

But if you’ve invested in autonomy, flow, and observability—if you’ve taken the First Way of DevOps seriously—then AI is a force multiplier.

The bottleneck was never the code. It was the way you worked.