Xin Yao – Podcast Stage | Craft 2026 (Conversation Outline)

A podcast-stage conversation at Craft 2026 recorded by the ABK Podcast (Hungarian leadership club, 4th year), hosted by Dávid (aka “Kisputsok”). The guest is Xin Yao — an independent consultant, trainer, and socio-technical architect based in Copenhagen who supports European organizations on complex design/architecture/modernization, blending domain-driven design, collaborative modeling, socio-technical thinking, psychological safety, and conversational leadership. (The auto-transcript renders her name as “Signe.“) The topic: how to “plug AI into your team” — past individual experimentation, embedding AI sustainably into the system that is a team. Her thesis: there is no plugin; the real blocker is a collective lack of safety, and the missing skill is social/conversational, not technical. Structure as a topic-threaded dialogue.

1. Framing: “Plug AI Into Your Team”

• Dávid’s definition: move past individual experimentation (easy — just sit in front of your favorite LLM) to embedding AI into the system called a team. In 2026 most engineering orgs are past “should we?” but stuck on how to do it sustainably.
• Xin: people love plugins because they’re standard and “bang, it works” — but there isn’t one for teams + AI.
• Beneath the logical questions (tooling, process, team dynamics) sits existential threat: individuals feel “should I jump before I’m pushed?”; teams see Silicon Valley firing constantly and wonder “is it going to be me?”

2. Survival vs. “Thrival”

• Until the lack of safety is addressed in ourselves and in the collective, we won’t activate our higher-order functions (the rational questions about process/tooling/dynamics) — “right now we’re in survival mode.”
• Need to move from a survival narrative to a thrival narrative — “it’s both, so it’s a thrivival kind of thing” (a term she coined). “Unless we get a calm feeling in our collective stomach, the plug-in won’t happen at all.”
• The four F’s under threat: fight, flight, freeze, feed — “feed is very common”: told to do LLMs, people over-consume/bikeshed on productivity instead of asking the higher-order question.
• ”If productivity is the trees, what is the forest as a team?” — asking better questions is more valuable than having answers (the LLMs have the answers).
• On the “plugin” itself: “if there is a plugin, Kent Beck would be a better person to talk about it — and there isn’t any.”

3. Being Forced vs. Choosing a Tool

• Dávid: if an engineer has a motivation, they pick the right tool and do the job better. The problem is being forced — not just by a boss, but by the industry saying “this is what you have to use” — which isn’t genuine, and the feeling of safety using a new tool isn’t there because “we don’t know yet what will happen.”

4. Commoditized Expertise and Grieving

• Knowledge professionals have been defined by expert knowledge (design, modeling, coding, analysis, architecture) — and ”all that, as we speak, is being commoditized by the machine.”
• We must leverage AI in a way that evolves us, not replaces us. Rationally we know “life is nothing but change,” but at a gut level letting go of the identity/skills that brought past success “requires a grieving process (as Kent Beck called it) — also as a team. Unless we let go properly, we won’t embrace the new.”
• The workshop experiment (day before): a modeling approach to the identity shift in the age of AI, borrowing from event storming and user-needs mapping to map three things about our AI engagement:
  • Possibles — the use cases / all imaginable possibilities.
  • Lovables — the deeper need beneath a use case (“I get a lot of emails answered” isn’t a need — what’s underneath? If you can’t answer, you’re not playing the productivity card well).
  • Undiscussables — what we won’t touch because of fear (“if I poke that, might I be the first they let go for resisting?”).
• Language is powerful; we need language to articulate these contradictions (“many shades of gray”). The missing skill is not technical — it’s a social/conversational skill, plus trust in ourselves to navigate it. Every one of us can start that process.

5. Control Is an Illusion; Human Slop vs. AI Slop

• Dávid: the change is a combination — accelerated pace, uncertainty of how to use AI, and a team leader who may be less aware than someone on the team; hard to be the first to step up with “hard stuff” for management, and timing matters (proposing this 4–5 months ago might have been wrong).
• Xin: much is already changing — notably the notion of control. She chose computer science because math/CS gave control (design the theory, code it, it compiles — you’re in control); the LLMs’ non-determinism shifts that paradigm. “That notion of control needs to be updated.”
• Dávid: denying/controlling “the unpredictable genie” is a stage of grief.
• Harness engineering (a popular talk topic) is a way to reclaim control — put a “moat”/protection mechanism around the non-determinism so “the code is committed in my name, done by someone else, but I built the moat.”
• But control was never fully consistent — ”coding has always been non-deterministic”: you code differently with/without coffee, sleep, a fight with your spouse, a misbehaving kid. “We’ve been dealing with human slop all the time”; AI is “the cliché, the force multiplier” — now it’s AI slop with all this harness (“I gave the harness to my dog — he’s not running away”).
• Fred Brooks’ two integrities: we need structural integrity (security, reliability, reproducibility — the non-functional) and conceptual integrity as a team — the latter won’t come from harnessing alone (a defensive mechanism); we need to dare to diverge before converging, and an LLM can help — once we leave survival mode. “Control is an illusion, and we have different ways of ensuring our happiness in this career.”

6. Trust — Old Problem, New Force Multiplier

• Dávid: is trusting the genie’s output a new trust issue?
• Xin: trust is a metaphor — did I trust code I wrote in a top-notch mood? Code someone else wrote before the genie? That trust issue predates AI.
• We already have good practices for shared understanding and trust:
  • DDD — a ubiquitous language so business-domain language and code language correspond (no translation loop) — building trust between humans and in the language cohesion.
  • TDD (per Michael Feathers, Kent Beck) — ascertain that intended business logic keeps working as you change things.
  • Neal Ford’s Architecture Definition Language — not a harness/moat but a change sensor: if those (ArchUnit-style) tests break, “we should be happy because change is coming and it’s been detected,” not feel an inferiority complex.
• These free up cognitive capacity (the frontal cortex) from the fear response — the capacity we need.

7. Autopoiesis and Conversational Leadership

• Dávid asks for practical ways to remove fear / build a system that helps teams harness the new era.
• Xin references co-speaker Simon Rohrer’s “who are ‘we’?” — is there an omnipotent system designer outside our team-of-teams? Engineers often expect that to be “taken care of” so they can do their thing.
• Autopoiesis (Greek: auto = self, poiesis = creation): in a living system, every component can also influence the system. So how can I influence my team now?
  • Hack a retrospective by starting a conversation — e.g., via a liberating structure — pose a question and suggest a discussion: “how do we feed business context into the LLM? what are our preferences? how do we make that decision?”
  • Don’t wait for managers/CTOs/CEOs to mandate it — these should be bottom-up enabling constraints (a question is a constraint: it frames attention).
• Conversational leadership is now “a core differentiator for every software engineer” — those who can start, facilitate, and summarize conversations (with LLM help) and communicate results at the team level will be the survivors and thrivers. “It’s so easy to start a human conversation — like you asking me a question.”

8. Top-Down Mandate vs. Bottom-Up (and Emotions)

• Dávid: there’s a fundamental difference between top-down (“big tech says we must use AI” → token-maximizing, a proxy for a measurement) and bottom-up (start a conversation about “what are we afraid of?”). If someone already decided the tool must be used, how do I reflect on it when it’s not my view but I want to comply and succeed?
• Xin: with several teams over the past 3 months she’s tackled this:
  • Emotion is symmetrical — fear/anxiety is often ”excitement with a different sign.” We feel fearful because we want to be excited about something — so what can we be excited about?
  • We’re asked to play the short-term productivity/efficiency game (burning tokens for low-hanging fruit), but two things to genuinely be excited about:
    1. Adventurous ideation partnership with LLMs — Henrik Kniberg’s “Einstein in the basement”: your brain extended with the world’s biggest wisdom library.
    2. Not confronting your manager, but asking: “what’s the outcome you’re expecting? what’s the difference if I use the LLM vs. not? how much freedom do I have — must I use the LLM for linting/structural analysis, or could I use a traditional tool?”
  • Reframe identity (inspired by Simon Wardley): think of yourself not as a code producer/programmer but a value engineer — “what is the value I can be part of creating?” That gets us calm and excited again. “We don’t want to live a heavy life because of AI — that’s not worth it.”

9. Output → Outcome, and Continuous Comprehension

• “It’s the same old issue: from output to outcome.”
• The force-multiplier creates tech debt — and now it’s multiplying faster than we can catch up (“the comprehension debt”); she jokingly adds “continuous comprehension” to the CI/CD pipeline.
• Lead with the why, not the way (John Cutler’s line) — shift attention from the what to the why.

10. What Human Capabilities to Invest In

• Technical (will get standardized/platformed): harness engineering / building the “moat”; and moving the capacity stack from coding toward product understanding / product thinking (the “value engineer”) — value mapping, user-needs mapping, defining the why/outcome.
• Relational (the real differentiator): she corrects herself — not all knowledge is commoditized; transactional knowledge is commoditized, but the capacity to make knowledge relational is the core differentiator.
  • Methodologies: collaborative modeling, liberating structures, Peter Block’s six conversations, and “common good protocols.”
  • Socio-technical thinking lifts the social system’s well-being from a means to an end (producing software) to being as important as the output — a skill lift, an awareness shift, and a paradigm shift that “won’t come from outside.”
• Systems thinking has been “sabotaged by rational system thinkers” — real systems thinking is seeing your power/influence in the system. With “agency” now tainted by AI “agents,” she prefers “self-power” / “empowered over power” — empowering yourself because you have influence on making knowledge relational. “Sounds like a soft skill, but it’s going to be a hard skill with AI in the game.”

11. Audience Q&A

11.1 Tips for teams simply handed Cursor/Claude — rules & training, or chaotic exploration? How to motivate scaling up?

• Agree on the interfaces first: solo/efficient use vs. multiple individuals; if divide-and-conquer, how — which needs a collaborative process (a meeting/workshop), asking why are we doing this?
• The first-mover trap (seen many times): one or two first movers drive everyone — “I made this MD file, it’s spec-driven, fantastic, this is where we go.” But remember: make knowledge relational — what excites you “makes no sense to your teammates until you’ve made them relate to your MD file.” How you make them relate — “I’ll leave that question for you to answer.”
• Dávid’s reflection: it’s a vicious circle — you’re given a tool and an answer for how to use it, then adding a mandate about why just adds another top-down request.

People & References Cited

• Xin Yao — guest; socio-technical architect, Copenhagen (DDD, collaborative modeling, psychological safety, conversational leadership).
• Dávid / “Kisputsok” — ABK Podcast host.
• Kent Beck — grieving process; keynote; “there is no plugin.”
• Fred Brooks — structural vs. conceptual integrity.
• Michael Feathers & Kent Beck — TDD.
• Neal Ford — Architecture Definition Language as a change sensor (ArchUnit).
• Simon Rohrer — “who are ‘we’?” system-design question.
• Simon Wardley — “value engineer” inspiration.
• Henrik Kniberg — “Einstein in the basement.”
• Peter Block — the six conversations.
• John Cutler — “lead with the why, not the way.”
• Concepts: plugging AI into teams, survival vs. “thrival”/“thrivival”, four F’s (fight/flight/freeze/feed), grieving commoditized identity, possibles/lovables/undiscussables, event storming, user-needs mapping, control as illusion, human slop vs. AI slop, force multiplier, harness engineering / moat, DDD ubiquitous language, TDD, autopoiesis, liberating structures, conversational leadership, token-maximizing, output→outcome, comprehension debt / “continuous comprehension”, socio-technical thinking, systems thinking / self-power, making knowledge relational, the first-mover MD-file trap.

Video: https://www.youtube.com/watch?v=aTf3bXxcKnY — Transcript via yt-transcript.sh; outline generated from the transcript.