(2026 KanDDDinsky) What if your biggest technical debt is social

Ward Cunningham's original technical debt metaphor in 1992 was not about bad code. Debt could be a business and learning strategy: we build with the understanding we have today, use the software, learn something new, and discover that yesterday's good design no longer fits what we now know.

More recently, Kent Beck has reframed a similar tension as Features vs. Futures: delivering value now while preserving our ability to respond to what comes next.

AI-accelerated code production makes that learning debt more urgent.

This talk explores why faster execution loops, better DDD-informed specifications, disciplined TDD, and stronger AI harnesses are only part of the answer. The deepest learning debt is social and non-linear. It accumulates in our pursuit to understand the problem, notice assumptions, let our mental models shift, decide what matters, take ownership, and act under uncertainty.

Drawing on Domain-Driven Design, collaborative modeling, cognitive science, and dialogical practices, we'll explore how we can make thinking together a deliberate part of software design.

Borrowing Kari Zeller's language, how might we* re-place ourselves* as AI changes how software gets made? Instead of simply inserting AI into our existing processes and ways of thinking, what would it mean to rethink how we work with each other and with AI, where we create value, and what we take responsibility for?

Transcript

2. The arc of this talk 01 Debt is the price of learning 02 Be in control, and in learning 03 The ways we know, the knowledge we grow
3. 1. Debt is the price of learning What changed when AI accelerated execution? KanDDDinsky
4. Debt as a business strategy “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Ward Cunningham OOPSLA 1992 The WyCash Portfolio Management System Every minute spent on not-quite-right code counts as interest on that debt.”
5. Debt as a learning strategy “I am never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial. Ward Cunningham 2011 Debt Metaphor I thought that rushing software out the door to get some experience with it was a good idea, but you would eventually go back and … put that learning back into the program.”
6. Debt as a communication strategy Design flaw is like reckless debt Business strategy Martin Fowler 2014 Technical Debt Quadrant Learning strategy
7. Debt can be rational when acting now leads to the learning needed to improve later.
8. Every feature eliminates some future optionality It costs us to maintain or delete the feature Kent Beck 2026 Earn *AND* Learn
9. Technical debt is learning made visible in software Code will always be a little behind the current reality UNDERSTANDING₁ → SOFTWARE₁ → EXPERIENCE → UNDERSTANDING₂ Software₁ may no longer fit what we now understand. Yesterday’s good understanding can become today’s debt. Code as fossil records
10. Debt is the price of Learning. What changed when AI accelerated execution?
11. Earlier, code could only move as fast as developer understanding Delivery speed was a good proxy for measuring learning debt EXECUTION · PRODUCTION Spec → Code → Features ↑↑↑ UNDERSTANDING · ACCOUNTABILITY ↑↑↑
12. AI reveals the real bottleneck Human learning and understanding EXECUTION · PRODUCTION Spec → Code → Features ↑↑↑ UNDERSTANDING · ACCOUNTABILITY ?
13. Code becomes the fossil records of agents’ understanding. Tech Debt → AI Slop Learning Debt → How does it show?
14. Learning debt spreads in the sociotechnical system
15. What happens when ‘our’ capacity to produce exceeds our capacity to understand what’s produced? How do we get back in control?
16. 2. Be in control, and in learning Which loop are we in? KanDDDinsky
17. We must pace the frontier Pay the learning debt - “Understand and control these systems” (Essay, Sept 12, 2026) “AI has been advancing drastically faster, driven primarily by AI’s growing ability to build the next generation of AI. This dynamic is called recursive self-improvement… Left unchecked, it could outrun our ability to understand and control these systems, and so must be pursued very carefully, if at all. “
18. A timely response: improve the execution loop Harness engineering ensures fidelity between intent and execution Credit: Birgitta Böckeler
19. Spec-Driven Development as part of the harness Specifications as the primary source of truth INTENT SPEC CONTEXT AGENT TESTS Functional & Non-functional SDD makes intent explicit before asking the agent to execute VERIFY
20. DDD-informed SDD Many similar experimentations in our community “ESML (Event Storming Markup Language) is a faithful, high-fidelity transcription of what's on the board — stickies, colors, positions, groupings — without interpretation. DMML (Domain Model Markup Language) interprets the ESML into a strategic and tactical DDD domain model — subdomains, bounded contexts, aggregates, entities, value objects, events, commands, policies, and more”. Credit: Joseph Yoder & Marden Neubert
21. A harness is a frame INTENT SPEC CONTEXT AGENT TESTS What if the frame needs to change? VERIFY
22. A harness can only go so far Human experience and intuition remain part of the “implicit harness” SITUATED JUDGMENT What “good” looks like in this context Birgitta Böckeler 2026 Harness Engineering for coding agent users “Harnesses are an attempt to externalise and make explicit what human developer experience brings to the table, but it can only go so far.” ORGANISATIONAL ALIGNMENT What debt is tolerated, and why ORGANISATIONAL MEMORY We don’t do it that way here SOCIAL ACCOUNTABILITY What this means for people maintaining the code
23. Double-loop learning LEARNING LOOP Assumptions Spec Execution Why we do what we do What we want to do How do we do it (“Theory Building”) EXECUTION LOOP Credit: Chris Argyris & Donald Schön Organizational Learning II: Theory, Method, and Practice. (1996)
24. Better specs improve execution with a frame. But sometimes we need a new frame. LEARNING LOOP Assumptions Spec Execution Why we do what we do What we want to do How do we do it (“Theory Building”) EXECUTION LOOP Credit: Chris Argyris & Donald Schön Organizational Learning II: Theory, Method, and Practice. (1996)
25. What if surprise is a feature? “The XP goal is not to have results match expectations. Kent Beck 2026 The Third Loop Podcast I prefer to have results not match expectations in positive ways.”
26. Learning is the point Code is a side effect Are the specs optimized for human learning? “Software development is a learning process. Working code is a side effect.” Alberto Brandolini Credit: Alberto Brandolini “Code is still a side effect” (2026)
27. Execution Loop. Learning Loop. Different mindset. CONTROL MINDSET TECHNICAL EXECUTION Intent → Spec → Harness → Software → Outcome → Learning deviation = problem Did the outcome match our expectations? LEARNING MINDSET SOCIOTECHNICAL LEARNING Intent ⇄ People ⇄ Conversations ⇄ Models ⇄ Software ⇄ Learning Which assumptions produced the current intent? deviation = information
28. How do we think across different loops?
29. 3. The ways we know, the knowledge we grow What is unique about human intelligence? KanDDDinsky
30. John Vervaeke - four ways of knowing PROPOSITIONAL logic · semantic · mental model · beliefs ↑ PROCEDURAL know-how · skills · power ↑ PERSPECTIVAL embodied · presence · situated · episodic ↑ PARTICIPATORY agent–arena coupling · meaning · identity
31. Salience landscaping How do we know what to pay attention to? SALIENT What stands out to me in this situation, this state of mind? Human intelligence includes discovering what is worth noticing. Credit: John Vervaeke
32. Relevance realization How do we know what calls for action? NOTICEABLE → SALIENT → RELEVANT → ACTIONABLE Human intelligence includes discovering what deserves attention and action. Credit: John Vervaeke
33. Have you noticed … When WE use mental shortcuts, we call them heuristics, or patterns. When OTHERS use mental shortcuts, we call them biases. What feels relevant depends on where we stand.
34. Relevance realization contains the risk of self-deception (aka. salience bias).
35. Dialogic relevance realization We need each other to escape self-deception and update mental models IN A DIALOGUE MY PERSPECTIVE DIALOGIC SPACE YOUR PERSPECTIVE Your reaction can make my assumption visible. My question can change what becomes relevant to you. Together, we can discover what neither of us could see alone. A dialogue affords reciprocal opening, not just information exchange. Credit: David Bohm, John Vervaeke, Rupert Wegerif
36. A recent client engagement
37. In a dialogue, the frame itself becomes available for inquiry DDD PERSON’S MENTAL MODEL SDD PERSON’S MENTAL MODEL Detailed specs constrain learning Detailed specs align execution with intent clarity-through-doing clarity-before-doing Credit: David Bohm, John Vervaeke
38. A dialogue affords insight (i.e. reframing) DDD PERSON’S MENTAL MODEL SDD PERSON’S MENTAL MODEL Detailed specs constrain learning Detailed specs align execution with intent clarity-through-doing clarity-before-doing What if we use SDD to externalize the current state of understanding, and use DDD to continuously challenge and evolve that understanding? clarity-before-doing AND clarity-through-doing Credit: David Bohm, John Vervaeke
39. Keep execution and learning in sync Execute on current understanding. Refactor when understanding changes. EXECUTION LOOP LEARNING LOOP DDD / XP / COMO SDD / HARNESS Externalize intent Govern execution “How do we align output with specs?” ⇄ Challenge assumptions Reframe intent “Why are we modeling it this way?”
40. Bohmian dialogue - an adapted model Notice → Welcome → Attend → Share → Listen → Reflect → (Possible) Insight Perspective Taking Opponent Processing Reciprocal opening From reaction to curiosity about my own assumptions. Different perspectives make our assumptions visible. A new frame can emerge that none of us saw at the start. Dialogue does not manufacture insight. It creates conditions in which reframing can emerge.
41. Dialogue as a sociotechnical design tool Design Goal: Perspectival flow & reciprocal opening PERSPECTIVAL embodied · presence · situated · episodic PARTICIPATORY agent–arena coupling · meaning · identity Dialogue: update the perspectival through the participatory Credit: John Vervaeke
42. Bohmian Dialogue “A dialogue must have no other goal but to be able to talk together. A group starts as a microcosm of the whole culture. We want to be part of the group but we are also afraid of losing our individuality. David Bohm (1917-1992) American Physicist A dialogue loosens the collective sociocultural rigidity that holds all of us in its grip. In a dialogue we suspend assumptions and become witness to the limits and boundaries of our own thoughts. ”
43. Agile was almost “Conversational” At Snowbird, Kent Beck proposed “Conversational Software Development” rather than agile “Sitting together and working on something is such a powerful source of energy, feedback and value, that I want to find ways to bring people together, not ways to Kent Beck 2026 The Third Loop Podcast successfully keep people apart.”
44. Propositional knowing has been privileged in knowledge work PROPOSITIONAL logic · semantic · mental model · beliefs ↑ THE NON-PROPOSITIONAL PROCEDURAL know-how · skills · power Human knowing cannot be reduced to propositions. ↑ PERSPECTIVAL embodied · presence · situated · episodic ↑ The non-propositional layers of knowing afford and constrain the propositional. PARTICIPATORY agent–arena coupling · meaning · identity Credit: John Vervaeke
45. AI excels at propositional knowing WHAT I KNOW → WHAT I PRODUCE → HOW I PERFORM If this is where I place my identity… …what happens when technology is designed to outperform me there?
46. Who is enjoying the fast flow? “This is not what I signed up for …” What are humans actually for?
47. ‘Agent-arena’ decoupling The realness of my identity is in my felt agency toward the arena My participatory knowing is breaking down
48. Meaning in life A deep, active connection to reality
49. Research paper (2025) AI skill threat, identity change & developer thriving Survey: 3,267 developers & managers across 12+ industries Credit: Catherine Hicks et. al. (2025) “How the Structure of Developers’ Beliefs about Software Development Ability Impacts Their Psychological Resilience During Rapid Technology Shift”
50. Ontological vulnerability Who am I? What’s my place in the world? “Operational vulnerability threatens what you do. Ontological vulnerability threatens your sense of who you are and your place in the world. It’s when things that gave me a coherent place in the Kari Zeller 2026 “Re-placed: Answering the Call of Leadership in the Age of AI” world become uncertain. Non-human intelligence now participates in our work and decisions without participating in our humanity.”
51. Do not just be displaced. Re-place yourself. Rather than outcompeting machines, claim a uniquely human position DISPLACED RE-PLACED Efficiency → Agency Performance → Participation Control → Care Answers → Questions Output → Accountability Design an identity-level transition of our software profession. Credit: Kari Zeller, John Vervaeke
52. Back to the debt metaphor
53. AI makes an older human debt visible Long before AI, we borrowed productivity by treating humans more like machines WE OPTIMIZED FOR efficiency · utilization specialization · predictability · output · performance WE PAID WITH connection · belonging meaning · care · agency · adaptivity AI exposes the debt because machines can now outperform us at the growth & productivity game.
54. Maybe that social debt is worth taking After all, debt is the price of learning DECOUPLE MOVE FAST LEARN “Not quite right” development community (structure, process, mindset) RECONNECT Collaborative and Dialogic practices; Self-leadership We borrowed speed through decoupling. Reconnection is part of repayment. Credit: Phillippe Kruchten et. al. “What is social debt in software engineering?” (2013)
55. Technical debt threatens our capacity to change software. Social debt threatens our capacity to change ourselves together.
56. But people are not code Repayment is not “refactoring humans” TECHNICAL DEBT SOCIAL DEBT restore evolvability regenerate adaptive capacity
57. What if coupling is the point? Coupling is not a liability among humans. Coupling is a capacity for the unknown. SOFTWARE OPTIONALITY SOCIAL OPTIONALITY Can the software respond to change? Can we respond together to change? The future is not something we specify. It is something we remain capable of responding to. Credit: John Vervaeke, Kent Beck
58. Living: situated, embodied, emotional, relational, perspectival, participatory We need human interactions that afford living knowledge AI cannot embody care and meaning
59. A human face still asks to be gazed upon “No computational system, however sophisticated, can create a heart that gives itself, or a conscience that discerns good from evil. Even when machines excel in efficiency, a human face that asks to be gazed upon remains the center of our history.” Pope Leo XIV Magnifica Humanitas · §233 (2026) The Pope warns against reducing the mystery of the human person to data, performance, or usefulness.
60. Model the human context Our unique contribution is not to give AI better specs and harnesses BUSINESS What matters? For whom? Why? COGNITIVE What assumptions shape what we see? SOCIAL SOFTWARE What do we care about? How do we collaborate? How does understanding become boundaries, models & constraints? DDD · Collaborative Modeling · Dialogic Practices · Self-Leadership Shape the context for situated, embodied and non-propositional knowing.
61. CAPACITY WHAT CAPABILITY MUST WE DEVELOP SO WE CAN CARE, LEARN AND ACT TOGETHER in a future we cannot know?