Directing Attention with Doubtful Intent

People now get things done by asking for them: a fix to our codebase, a new feature, an entire system built to a specification. Doubtful intent is asking while doubting what comes back. I doubt the fix comes without side effects. I doubt the feature meets the expectations we never thought to say out loud. I doubt the system works across all the scenarios and perspectives that matter.

Watching work under the influence of AI, I see what doesn't work: separating specification, development and testing with handoffs between them. What I look for instead are virtuous loops in cross-functional teams of specialists and generalists. In this talk, I share three practices I have found useful:

Living common ground: bring specification into the team's conversations and writing. Build a shared knowledge base with role-specific views, traceable changes, and a path from text to executable specification. Instead of walls of text.
System properties: use AI to identify candidate properties, have the team assess which matter, and evaluate the built system against them. Mismatches reveal gaps between expectations and behavior. Instead of hand-picked examples alone.
Model reconciliation: compare AI-generated models of the system with the team's expectations, and investigate the gaps. Instead of traditional testing that cannot keep up with this speed and scale.
Each practice generates something to examine, surfaces differences, and reconciles them with evidence and shared understanding. Common ground grows from what we intend; properties and model reconciliation start from what we built. None of them belongs to a tester or a phase. They are things the whole team does, developers included.

You'll leave with practices to try, and a quality engineering view of collaboration where doubt directs attention to where value is at risk.