Blog · AI engineering
Faster coding is not faster delivery.
A video landed in my feed that says out loud what I keep drawing on whiteboards: AI has made coding dramatically faster, and software delivery barely noticed. Cedric Clyburn of IBM Technology explains why in twelve minutes, and his answer resonates with everything I see at work.
The video#
Play the video (loads the YouTube player)
AI in the SDLC · IBM Technology, June 2026. Nothing loads from YouTube until you press play.
It opens with an uncomfortable number: a controlled study of experienced open-source developers who believed AI tools made them about 20 percent faster, while the measurements showed them roughly 20 percent slower. Feeling faster is not being faster. That single finding deserves to be pinned above every engineering dashboard, right next to the honest question it forces: if the model writes code this well, why is delivery not moving?
A lifecycle of waiting#
Clyburn draws the classic pipeline: requirements, design, build, test, release, operate. Then he gives away the secret that every engineering manager learns the hard way: most of the elapsed time in that pipeline is not spent writing code. It is spent waiting. Developers wait for the product team to clarify a story. Operations waits for the release. QA waits for a build, in an environment that never quite matches production, across a pile of fragmented tools.
So when AI makes one box faster, the queues around it quietly absorb the gain. Code three times faster, and the pull request still waits for reviewers, the compliance check, the shared test environment. Running a portfolio of regulated platforms, I can confirm: the build phase is rarely my constraint. Coordination is.
Two ways to fail#
The video describes AI adoption as a spectrum with a trap at each end, and I have watched teams, mine included, step into both.
Over-delegation: hand a frontier model a big ambiguous problem, “build me an e-commerce platform”, and let it run. Every unstated decision about payments, authentication and shipping gets made silently by the model, which returns thousands of lines nobody has read. Review becomes the bottleneck, and the back-and-forth burns everything the generation saved.
Under-delegation: the senior engineer keeps all the planning and hands the model crumbs, write this function, scan this file for SQL injection. The code that comes back is good, but the intellectual heavy lifting stays entirely human, so the lifecycle barely accelerates. This is the trap disciplined teams fall into, precisely because their discipline protects them from the first one. Our own guardrails keep us safe from over-delegation; the honest question is whether they sometimes keep us too far on the timid side.
Redesigning around AI#
The heart of the video is a reframe: stop bolting AI onto the existing lifecycle and redesign the lifecycle around it. Phase by phase, that looks like this:
Requirements and design
Synthesize the unstructured mass of surveys, user reports and stakeholder emails into user stories, and let agents mine production logs and bug reports so the next iteration starts from what actually fails.
Build
Small, well-defined tasks instead of vibe-coded systems: a specification the model can read and follow, subagents for research, for pulling data through MCP servers and for editing, and shared context files so every team gets consistent output.
Test
Generate test data straight from the user story, and let the model read the 3 a.m. stack trace without the 3 a.m. panic.
Release and operate
Models are already fluent in infrastructure as code, from Ansible playbooks to Kubernetes manifests.
Legacy
Explain and reverse-engineer the systems nobody fully understands anymore, which happens to be a fair description of my day job.
The whole idea in one picture#
Swipe horizontally to read the full lifecycle.
Outcomes, not lines#
The conclusion is the part I would frame: the productivity gain does not come from a better model or a better tool, it comes from “redesigning the software delivery lifecycle around the model”, as Clyburn puts it. The human role moves from typing to validating, which is exactly the flip I described in Claude assisted by a human, arrived at from the org-chart side instead of the keyboard side.
Amdahl’s law applies to organizations too: speeding up one stage mostly reveals the cost of all the others.
And the measurement follows: not lines of code generated, but system health, maintainability, and how long a change takes to reach production. Those are the numbers I already answer for in front of my stakeholders, which is probably why this video felt less like a lesson and more like a colleague agreeing with unusual production values. Worth twelve minutes of your lifecycle.