AI is making it faster and cheaper to ship features. That doesn't mean you should ship more of them at once.

Peter and Dave dig into a pattern they're both starting to see: organizations using AI-assisted development as a reason to bring back big upfront planning and large project releases. The logic makes a certain kind of sense. If AI can build faster, why not design bigger? But that reasoning skips the part that actually mattered when teams moved to product delivery in the first place: validating that you're building what customers actually need.

The conversation covers why large releases make it harder to learn what's working, why feature parity with competitors is a trap, and what "North Star context" actually means when you're coordinating AI agents. The core argument: the planning layer is back in vogue for good reason, but the delivery layer still needs to be small and iterative. Cheaper to build doesn't reduce business risk. It just makes it easier to build the wrong thing faster.

This week's takeaways:

• AI augmentation speeds up building and releasing features, but it doesn't replace the need to validate whether those features are what customers actually want.
• A big picture plan is useful as context for AI agents and delivery teams, but over-specifying every step upfront wastes time on details that will change anyway.
• The goal isn't projects vs. product delivery. It's combining a clear long-term direction with small, measurable, iterative delivery tied to real outcome metrics.

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

Tommy Cotter is Director of Data Products at Benzinga, a financial media company building the data infrastructure that sits behind trading platforms and investment apps used by millions of people daily. He's been navigating the shift to AI-assisted workflows in a space where speed and accuracy aren't just nice to have - getting it wrong has real consequences.

In this episode, Peter and Dave talk with Tommy about what it actually looks like to build data products responsibly in a fast-moving AI environment. They get into where humans still need to be in the loop, how compliance has become a competitive signal, and why being nimble matters more than picking the perfect architecture from day one.

Three things to take away from this conversation:

1. Self-agency is real now. If you have a strong conviction about a product or problem, the barrier to building something has never been lower. That's a genuine shift from even five years ago.
2. Security and compliance are no longer just internal concerns. In a world where AI startups spin up overnight, having invested in SOC2 or GDPR signals to customers that you're a legitimate, trustworthy operation. It's a market differentiator.
3. Humans still belong in the system. Not everywhere, but in the right places. For low-risk, deterministic processes, let AI run. For anything client-facing or accuracy-critical, keep a human in the loop. Knowing the difference is the skill.

If this conversation sparked something for you, send us your thoughts at feedback@definitelymaybeagile.com. And if you haven't already, hit subscribe so you don't miss the next one.

Royce Sin spent a decade at HSBC automating things nobody asked him to automate. He didn't ask for permission. He just did it, showed people the results, and let the time savings speak for itself. That instinct, to question why things are done a certain way and then actually do something about it, is what eventually led him into the AI space.

In this episode, Peter and Dave sit down with Royce Sin to talk about what it actually takes for AI to stick inside an organization. Spoiler: it's not about the tools.

We get into the tension between flexibility and reliability, why most people are being set up to fail with AI, and what it means to think like a manager when you're not one. Royce also shares his MIND framework, a practical way to think about AI adoption that he developed through hands-on work across enterprise and startup environments.

There's also a good conversation about the trades, no-UI as an ideal, and why the most dangerous move in transformation is knocking down fences you don't fully understand.

This week's takeaways:

• Think of AI as a new type of employee. Set it up for success the same way you'd set up your staff. Design roles and processes to match what it's actually good at.
• Not every rule is a hard rule. Before treating a constraint as a blocker, understand what's behind it. Some fences are load-bearing. Some aren't. Know the difference before you act.
• Don't just bring in AI. Know what outcome you're after. If you can't tell whether it's working, you don't have a tool problem, you have a clarity problem.

Have a thought on any of this? Reach us at feedback@definitelymaybeagile.com