Kent Beck created Extreme Programming, helped pioneer test-driven development, and was the first signatory of the Agile Manifesto. At Prodacity 2026 he talked about what craft means now that a model is writing much of the code.

In this session:

• Why Beck calls it the genie, and why plausible code is not working code
• Features and futures: how every feature you ship burns some of your options for change
• Resting between the notes, and what teams do in the space between features
• One-shot versus iterative, and why spec-driven development is waterfall wearing a new coat
• What he found in formal methods with Lean, and the gap he still cannot bridge
• Effort, output, outcome, mission: a revision Beck worked out during Day 1, and what Goodhart's law does to any measure taken too early

Recorded live at Prodacity 2026 in Nashville. Prodacity is Rise8's 3-day training event for GovTech leaders delivering mission-critical software.

When my new insulin pump’s algorithm confidently delivered what it claimed were hefty doses while my blood sugar soared toward dangerous levels, I faced a terrifying reality: the software was learning, but learning the wrong things.

And it was utterly convinced it was doing a great job.

This isn’t just a medical device story - it’s a wake-up call for our entire industry. As ML and AI become critical infrastructure, they’re exposing fundamental flaws in how we approach quality. We test implementation rather than behaviour, write tests that validate our assumptions rather than challenge them and mistake comprehensive coverage for genuine safety.

Drawing from 15+ years as a software engineering trainer and consultant across multiple industries, I’ll explore how traditional testing blind spots become genuinely dangerous when systems learn and adapt. We’ll examine why teams confuse feeling safe with being safe, how AI amplifies our existing quality gaps and what it really means to test systems that make decisions affecting real lives.

You’ll leave with practical approaches to testing that focuses on impact over metrics, strategies for validating both deterministic and learning systems, and the essential questions every team should ask when software moves beyond just processing data to making decisions that matter.

Because whether it’s a payment system, a recommendation algorithm or life-critical medical software, our users are trusting us to get it right.

The edge cases between the edges

T shaped but untrained in testing

Quelques invitations :

1. Create an interaction matrix for your edge cases
2. Write Property Based Tests for your constraints
3. Implement chaos engineering for your business logic, not just your infrasctucture
4. Document and test your "must never" invariants explicitely (ex. MUST_NEVER.md
5. For ML systems specifically, test the decision boundaries, not just accuracy
6. Build observability into your business logic, not just your infrastructure
7. Implement feature flag controls for rule interactions
8. Use your Threat Model
9. Get to know all the people and what they need
10. Ask the uncomfortable question

Would I trust this system... With my wealth ? My Freedom ? My Life ? -> Meeh, or No and you put it out in production, SHAME ON YOU.

AI can write code faster than you. Congratulations to the robots. But if speed of code production is the thing holding your team back, I've got some uncomfortable news: you have much bigger problems and nobody is willing to talk about them.

I've spent over 25 years building software and the bottleneck was almost never the typing. It was the three-week argument about what to build. The requirements that changed after you shipped. The stakeholder who couldn't articulate what they actually needed. The architectural decision nobody wanted to own.

Kent Beck said something that stuck with me: 90% of his skills dropped to zero value, but the remaining 10% got a 1000x multiplier. He's right. And the engineers doing well right now (actually well, not performing wellness for LinkedIn) are the ones who figured out which 10% is theirs. They stopped identifying primarily as "people who write code" and started identifying as people who solve problems. Code just happens to be one of the tools.

If your AI strategy is "write code faster," you're optimising the wrong thing.

Let's talk about what to optimise instead.