Where's the bottleneck now? The room told me.
What ten engineering leaders across four European countries and six industries actually said about AI's shifting bottleneck, from the July 22 round table.
On July 22 I hosted a round table on AI in software development. Ten people, four European countries, six different industries, live on Zoom, deliberately small. What put everyone at the same table was AI raising the same questions inside very different businesses. One question sat in the title: where's the bottleneck now? I asked it because generation stopped being the hard part a while ago, and I wanted to hear from people running real teams whether the rest of the pipeline had caught up.
The hour felt like ten minutes. We could easily have kept going for another two or three, the conversation was that interactive, and I'm genuinely glad it ran that way. What follows is the background on the shift we were all describing, then what the room actually told me about it, then a few places I think this goes next.
What "agentic SDLC" actually means
SDLC is the old acronym: software development lifecycle, plan through operate. "Agentic" is the new part, and it gets thrown around loosely, so here's the precise version. An agent plans a task, calls tools, writes and runs code, checks its own output, and iterates, with a human setting the goal and the guardrails.
The agentic SDLC is what happens when that behavior spreads across the whole lifecycle: specs, planning, building, testing, release, and monitoring each pick up an agent in the loop. PwC found 70% of teams already running GenAI at moderate-to-high intensity across their SDLC. This is the current state, unevenly distributed.
It helps to place any given team on a spectrum. Casual prompting with no real verification is vibe coding: fine for a prototype, risky for anything that ships. Structured AI assistance, detailed prompts against an established codebase with a human spot-checking output, is where most professional teams sit today, whether they realize it or not. Agentic engineering is the far end: formal specs, automated test suites, CI gates, and evaluation layers verifying every change before it reaches a user. The position on that spectrum isn't about which model you use. It's about how the output gets checked.
That's the part with real stakes attached. Veracode found 45% of AI-generated code carries a known security flaw. GitClear measured roughly 4x more code cloning in AI-assisted repos. METR found experienced developers 19% slower on real tasks with early-2025 tools, while they felt 20% faster, because the extra time went into verifying and correcting output nobody had budgeted time for. And the failure math compounds fast: Galileo's research on agent chains puts a 1% error rate per step at a 63% chance of failure over a hundred steps. One good agent, run long enough without a checkpoint, fails more often than it succeeds. Generation got cheap. Trust didn't come free with it, and the gap between the two is exactly where every team in that room is currently living.
What the room actually said
I opened with the theme that ended up running through the whole hour: trust, but verify twice. AI produces good output most of the time, and the failures don't look like failures. They look confident. The room spent the next fifty minutes finding out where that bites, across five distinct threads.
01The spec is becoming the product
One clear position in the room: with AI writing the code, the specification is the asset that survives. If the blueprint (every decision, every business rule, every piece of logic) is good enough, you can hand it to a different model or a different stack and regenerate the whole system. The code stops being precious because it's cheap to produce. The spec stays precious because it's the only place your judgment lives. And the spec has to change shape for this to work: specs written for a human reader leave a thousand assumptions unstated, because the reader fills them in. A spec written for a machine has to say what the system should not do as explicitly as what it should, or the agent assumes, and a quick review waves the assumption through.
02Testing has a blind spot now
A green test suite used to mean something close to safe. The room pushed back on that. One story stuck with me: an AI-generated test for a payment flow passed cleanly, on an error state, because the error appeared and the test only checked that it appeared. The message underneath gave the user no explanation of what had gone wrong or what to do next. Nobody caught it until a human tester did, in UAT. AI speeds up test generation and regression coverage. It does not replace a human judging whether the experience is actually usable, because we build software for humans, and only a human currently checks for that.
03Shadow AI is the risk nobody's budgeted for
As teams grow, a quieter problem showed up in the room: people picking their own AI tools, their own models, outside whatever the company actually standardized on. It looks harmless when it's one engineer with a favorite extension. It stops looking harmless once a dozen people are shipping production code through a dozen different unaudited tools, none of them covered by the same guardrails, logging, or data-handling review.
04The bottleneck moved, it didn't close
This was the sharpest reframe of the day. The old constraint was throughput: not enough engineering hours, so every feature request got fought over before it got built. That constraint is gone or going. What replaced it is harder in a different way. When almost anything can be built, the burden shifts to deciding what's worth building, and that decision now sits with product and engineering leadership without the old excuse of "we don't have the hours." DORA's own 2025 numbers back the shift: throughput turned positive with AI adoption for the first time, while delivery stability is still negative. PwC found the gap between AI-mature teams and everyone else is already showing up in output: 75 releases a year for Pioneer-archetype teams against 41 for Observers. Teams are moving faster into more decisions per week, and the gap between the teams that decide well and the teams that don't is going to look a lot like the old gap between fast shippers and slow ones.
05The process survives, the math inside it doesn't
Scrum and sprints came up as still useful. What changed is what happens inside the cadence. The old estimation math (story points, velocity, capacity planning built around human typing speed) stops meaning much when a sprint's worth of code can ship in a day. The frame holds. What you plan inside it needs a rewrite.
Why this is bigger than one event
None of this is a tooling footnote. It's an operating-model question, and it's already showing up in budget and hiring decisions, well beyond the engineering standup. A team that gets the spec discipline, the eval layer, and the governance right captures the throughput gains DORA is measuring. A team that skips straight to "the AI writes it now" without those three things inherits the Veracode and GitClear numbers instead, and finds out at the worst possible time. Ten people running real engineering organizations, spread across four countries and six industries, converged on the same read of where the pressure moved, independently, in the same hour. That's not a coincidence. That's a pattern worth paying attention to whether you were in the room or not.
Where this goes next
The room closed on something simple: relief at hearing other people, independently, arrive at the same read on where this is going. That's the reason I run these. One team's experience is a data point. Ten teams across six industries, agreeing independently on where the pressure moved, is a pattern.
I'm genuinely thankful to everyone who joined. If you couldn't make it this time, don't worry, this round table opens a series and there will be more rounds like this one. More soon, stay tuned!
And if you're working through any of this on your own team right now, spec discipline, the testing gap, shadow AI, or just figuring out where your own bottleneck actually sits, reach out. I work with engineering teams on exactly these problems. Let me know if you need any support. I'm always happy to help.