“What we have worked through ourselves belongs to us. What we have merely been handed stays foreign.”
(Richard Seidl)
Last year, in “Are We Preventing Learning?”, I worked through this idea: when we let AI create something for us, we focus only on the product and no longer on the process of making it. And that costs us something: the chance to learn.
Today I want to take that thought a step further. Because I believe we’re doing something else, too: we don’t build a relationship with the result. So we value it less, replace it faster and never really get attached to it.
Two examples. Someone repairs an old laser printer. Paper jam sensor cleaned, roller swapped, case closed. An hour of work, a screwdriver and a YouTube video. Once you’ve had a machine like that open, you know it. You know where it jams, why it sometimes feeds the paper in crooked, where the weak spot is. You know what toner dust smells like. You’ve figured out why the feed sometimes fails.
A brand-new blender, thrown out after two years because the motor died. “Nobody repairs these anyway.” Maybe true. Maybe not. But the more interesting part comes earlier: nobody even tried. Two years of daily use. Smoothies every morning. And still a total stranger. A black box. Plugged in, used, tossed.
To Own Something, You Have to Understand It
The other day I came across this line: “If you can’t fix it, you don’t own it.” (iFixit manifesto). I think there’s something to that. The things we’ve put time and thought into are close to us. The things we only consume stay at arm’s length.
We throw things away by the ton these days. Not because we don’t care about sustainability. Because we don’t care about the things. No relationship. No pain in letting go.
Agentic Engineering
And now we’re doing the same with vibe coding and agentic engineering. We generate test cases, automation, code, database schemas, test data, interfaces … and when we find a bug? We quickly let Codex or Claude Code have a go at it. And presto, the bug is gone. We don’t even know what caused it. And even if we read the explanation, that doesn’t stop it from happening again.
Same story with testing. Generating test cases from requirements, hooray. Fast, clean, lots of them. But who, along the way, understood why this edge case exists? Which stakeholder conflict hides behind this requirement? What went wrong in the last release that put this test here in the first place? The artifact is there. The story behind it isn’t.
Ownership Grows Out of the Process
Ownership doesn’t come from receiving something. It comes from working your way through it. From debugging, refactoring, struggling, wrestling with it. From making a mistake and fixing it.
I don’t mean this kind of ownership in a romantic way. If you own your code, you can fix it. If you own your architecture, you can stand behind it. If you own your tests, you know what they check and what they don’t.
I’d even say: the deeper we dig in and work our way into something, the more pride, connection and responsibility we feel.
If you simply take over AI output, you don’t get that. And that makes a difference.
Right now we’re building software at full speed, pieced together from generated parts that nobody has really worked through. And we call it productivity. It runs as long as nothing happens. The moment something does, everyone looks at each other, clueless … and asks the AI.
Finding the Balance
You know I like AI. I use it a lot. But as so often with technology, we first have to learn to use it in healthy doses … and quickly, please. Right now I see a big imbalance. Maybe a good start is to treat AI as a starting point, not an end point. And to keep asking ourselves: do I actually identify with what I’m doing here, or am I building throwaway software?
One last thought: think about why you really got into programming, or writing test cases, or designing architectures. For most of us, I believe, the motivation was: I get to create something here, and building things is fun. Do we really want to take that away from ourselves?
