Spec-driven development with AI is getting a lot of attention. Peter and Dave ask when that structure actually helps you, and when it slows you down.

They start with the AI SDLC white paper Anthropic recently published. It lays out a structured, spec-driven approach built for consistency. Peter sees it working best on large legacy systems, the kind with millions of lines of code written over 15 years by thousands of people. For greenfield work, a looser approach of prototyping and exploring often fits better. Dave pushes on the piece most teams drop: the feedback loop. Everyone agrees to review and validate, and then the next shiny feature shows up. They also cover what happens when an AI agent follows an over-detailed spec too literally, why systems thinking beats chasing every edge case, and how explore versus exploit plays out differently for a startup and a company with 10 million customers.

This week’s takeaways:

• A structured, spec-driven SDLC pays off on large, complex systems where stability matters, but it can feel like far too much when you are just prototyping something new.
• Define enough up front to guide the work, then rely on regular check-ins and feedback loops to course-correct, because no spec can predict every case and an AI agent will happily take the shortcut you never meant to allow.
• Explore and exploit are not either/or. Organizations can now run both under one roof, as long as they know where they sit on the path from startup to established player and use judgment about how much structure to add.

Listen to the full episode at definitelymaybeagile.com
Subscribe so you never miss an episode.

Have a question or topic you’d like us to cover? Reach out at feedback@definitelymaybeagile.com

AI agents will tell you everything works. Here is how to validate AI output when the mistakes are ones no human would ever make.

Peter and Dave compare notes from building software, training material, and presentations with AI. The problems they keep running into are strange ones: the wrong database ID dropped into a system, 236 passing tests that test nothing, and five layers of abstraction added to a solution that needed none of them. Their answer borrows from good agile practice. Define what validation means before the agent starts, the same way a team agrees on its definition of done. Keep checking that the context you gave the AI is still relevant as the work moves. And keep someone in the loop who knows the problem well enough to look at the result and say, "Actually, you got this wrong."

This week's takeaways:
- Decide what "done" and "valid" mean before you hand work to an AI agent, and use a separate agent to grade what comes back.
- A test suite that pings components or mocks everything out can report hundreds of passes and prove nothing, so ask for synthetic transactions that run through the whole system.
- AI will happily over-engineer a small problem, so someone needs enough knowledge to ask whether the solution fits the size and scale of what you are actually trying to solve.

Listen to the full episode at definitelymaybeagile.com
Subscribe so you never miss an episode.
Have a question or topic you'd like us to cover? Reach out at feedback@definitelymaybeagile.com

Giving AI agents names and a spot on the org chart makes people feel less accountable for the work, and it squeezes the agent into a role it doesn't need.

Dave Sharrock and Peter Maddison dig into new research from the September/October 2026 issue of Harvard Business Review on what happens when organizations add named AI agents to the org chart. When people use AI as a tool, they own the result and check it carefully. When the same work comes from a personified agent, accountability quietly shifts to the software, and nobody is really holding it. Peter connects this to the idea of accountability sinks, the layers in an organization where responsibility disappears. They also talk about review fatigue, the growing pile of AI-generated documents, slides, and code that someone still has to read, understand, and sign off on. Onboarding an agent like a new hire still makes sense. Leaving it on the org chart with a name is where the trouble starts.

This week's takeaways:
- How people work alongside capable AI agents is still poorly understood, and the old problems of ownership, accountability, and decision making do not go away just because an agent is involved.
- Review fatigue is real and getting worse, because cheap generation still means expensive human review for every artifact someone has to approve.
- Naming an agent into a human role limits it to the shape of that role, while treating it as a tool in the workflow lets it work across boundaries in ways a person cannot.

Listen to the full episode at definitelymaybeagile.com
Subscribe so you never miss an episode.
Have a question or topic you'd like us to cover? Reach out at feedback@definitelymaybeagile.com