Thank you for opening up the latest article in 'The Intelligent Commit' newsletter, my thoughts, research and analysis on Artificial Intelligence and how AI is reshaping the software development lifecycle. I hope you find it insightful, subscribe, and engage.
On Thursday morning, I hosted Axiologik's latest webinar on the Agentic SDLC, where I was joined by two fellow Yorkshire engineering leaders, Andrew Adam and Rachael Morgan.
The hour went fast and both explained how their organisations had made a deliberate decision not to use AI to speed up coding. That's right, we spent an hour on the agentic SDLC and barely mentioned code generation.
Why? Here are the five things I took away from our conversation.
1. Accelerating coding just moves the queue.
"There's no point accelerating too much of the coding because all that's going to happen is you move bottleneck elsewhere" — Andrew
The majority of technology professionals are using AI tools to write new code, however a common refrain is that coding was never the bottleneck, leading to stress on review, test, or release processes.
If we allow individual engineers to run hard at accelerating coding, the tech lead may immediately become the bottleneck; instead, Andrew recommended engineering leaders should "observe, protect, then accelerate" (borrowed to be the title of this piece).
2. The early wins came from reading systems, not writing them.
"Missing documentation is a tricky problem that I've seen really, really impressive results using AI to solve for" — Rachael
The best examples shared did not involve writing new features. Instead, they used AI tools for two jobs.
- reverse engineer systems to build an evidence base ... before anyone changes anything!
- walk the lineage of legacy data products to draft the missing documentation.
3. Ambiguity is now an engineering defect.
"The use of a small word here or there can actually change the way it's interpreting those things." — Andrew
I argued that an engineer who doesn't understand a requirement will come and ask you, but an agent may end up guessing what you meant and never mention it.
Andrew explained how one of his teams runs 'loose requirements' through an agent that turns them into locked-down formal ones, to ensure that downstream agents can't reinterpret them.
What the process exposed was how fragile casual language and wording had always been.
After the webinar, I researched this point and found a 2026 study that tested models against over a thousand tasks and deliberately ambiguous variants. Ambiguity cut first-attempt correctness by around 7%, while the models proved unreliable at judging whether a requirement was genuinely ambiguous.
4. Accountability hasn't moved. It is still human.
"You cannot make an AI agent accountable." — Rachael
Both agreed, unequivocally, that a named human must always own what ships.
However, with the rate of change, review requests may arrive at a rate faster than tech leads can absorb them, leading to them becoming disengaged. This is consistent with Faros AI's telemetry study which found PRs merged with no review at all are up by almost a third. I covered this in more detail in LGTM, but did anyone actually read it?
Andrew's answer is to move accountability into the system design. In his words, "we're accountable because we've implemented the right constraints, the right guardrails, the right controls."
5. If you can't state the hypothesis, you can't claim the win.
"Start with the problem that you want to solve" — Rachael
Without knowing why you are doing the work, there is nothing to measure against, and no way to tell a win from a pure coincidence. And we can't rely on our instincts either, even among principal engineers. METR's randomised trial in early-2025 found experienced developers were 19% slower when allowed to use AI tools, while they believed afterwards they had been 20% faster.
The counting has to change too, and Andrew put that plainly, "there's no point measuring output anymore. It's gotta be more about outcome."
Thank you for reading my latest article. Please share your experiences and engage with the discussion. I am not always right, but I try to be insightful and thought-provoking.
Please reach out if you'd like to continue the discussion.
Sources
- DORA, "2025 State of AI-assisted Software Development", Google Cloud, September 2025 (nearly 5,000 technology professionals) — https://dora.dev/research/2025/dora-report/
- Di Yang et al., "Assessing the Impact of Requirement Ambiguity on LLM-based Function-Level Code Generation", arXiv, 2026 — https://arxiv.org/abs/2604.21505
- Faros AI, "The AI Engineering Report 2026: The Acceleration Whiplash", March 2026 (22,000 developers, 4,000+ teams) — https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", July 2025 — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/