The Craft Gap
How agentic engineering is changing what technical trust looks like.
The Craft Gap
How agentic engineering is changing what technical trust looks like.

The sprint review runs clean. Twelve items closed, three features shipped, the velocity chart moving in the right direction. Someone marks the roadmap items done. The team looks satisfied. They should be.
Then a stakeholder asks a question that isn’t on the agenda. Not what shipped. Why two of the shipped features interact the way they do, and what that means for how users will move between them.
The room slows.
I’ve been in variations of that room more than once. The velocity is real. The shipping is real. But something else is in the room that doesn’t make it into the demo: a growing distance between the speed of what’s being built and the depth of understanding of how the pieces fit together.
That distance has a name. Most teams haven’t named it yet.
Building used to be the mechanism of understanding
For most of the history of software development, you couldn’t write a function without knowing what called it. You couldn’t design a schema without working through the relationships inside it. The friction of building forced comprehension.
This wasn’t incidental. It was how technical judgment developed. The philosopher Michael Polanyi called this tacit knowledge: the understanding that lives in doing, not in knowing about.¹ Senior engineers weren’t simply faster than junior ones. They had accumulated patterns through years of building things, watching them fail, and understanding why.
It was also legible. How an engineer approached a problem told you something real about how they understood it. The code surfaced the model in the engineer’s mind.
The craftsman Richard Sennett describes this as a dialogue between hand and head: the act of making shapes the thinking, and the thinking reshapes the making.² You don’t fully understand what you’re building until you’re in the middle of building it.
Agentic engineering interrupts that dialogue
The engineer now works primarily at the level of intent: describing what should be built, reviewing what the agent produces, approving the output. Velocity increases. The friction that used to deposit understanding decreases alongside it.
Gary Klein’s research on expert judgment found that expertise forms through accumulated exposure to real situations, in the patterns that emerge from that exposure.³ The engineer who spends years building and debugging forms a different kind of understanding than one who spends those same years reviewing and approving.
The question isn’t which one shipped more. It’s what each one does when the system fails in a way nobody anticipated and the spec doesn’t cover it.
This is where the trust question inside teams is changing shape.
It used to be: can I trust this person’s code? Now it is increasingly: can I trust this person’s understanding of what the code is doing inside the larger system? Those aren’t the same question. The second one is harder to answer when execution is no longer the evidence.
The question worth thinking about before the next sprint review
This isn’t an argument against the tools. Teams are shipping things that matter.
But: how does your team understand what it’s building? Not what. How.
When someone asks why two features interact the way they do, where does that answer live? In a document? In the person who scoped the work? In no one in particular, because the implementation came from an agent following a spec that captured the what but not the why?
The teams navigating this well are building the understanding back in deliberately: explicit architecture conversations, documented decision rationale, moments where the team explains not what shipped but what it connects to and why that connection matters.
That work is slower than shipping. It doesn’t show up in velocity charts. It is also what strategy looks like inside a product team.
The next sprint review will run clean. Things will have shipped. That question will still be in the room.
You can be the one who pushes the team to answer it.
Sources & References
¹ Polanyi, M. (1966). The Tacit Dimension. Doubleday. ISBN: 978–0226672984
² Sennett, R. (2008). The Craftsman. Yale University Press. ISBN: 978–0300119091
³ Klein, G. (1998). Sources of Power: How People Make Decisions. MIT Press. ISBN: 978–0262611466
메타데이터
- post_id
- f5233e54eb0e
- slug
- the-craft-gap-f5233e54eb0e
- url
- https://medium.com/@stephanie-muxfeld/the-craft-gap-f5233e54eb0e
- canonical_url
- https://medium.com/@stephanie-muxfeld/the-craft-gap-f5233e54eb0e
- author_url
- https://medium.com/@stephanie-muxfeld
- status
- ok
- fetched_at
- 2026-08-08 18:13:23