Skip to main content

Search...

Between Pride and Throwaway Software

Taking over AI output builds no relationship with the result. Why ownership grows from working through things, not from generating them.

4 min read

“What we have worked through ourselves belongs to us. What we have merely received remains foreign.” - Richard Seidl

Last year, in “Are we preventing learning?”, I worked through the following thought: when we have AI create something for us, we only focus on the product, no longer on the process of its creation. And that way we miss something: the chance to learn.

Today I want to spin this thought a little further. Because I believe we are doing something else entirely as well: we build no relationship with the result. Which means we value it less, replace it faster, and never develop much of a bond with it.

Two examples. Someone repairs an old laser printer. Paper jam sensor cleaned, roller replaced, case closed up again. An hour of work, a screwdriver and a YouTube video. Once you have opened up a machine like that, you know it. You know where it jams, why it sometimes pulls the paper in crooked, where the weak spot sits. You have smelled what toner dust smells like. You have understood why the feed sometimes fails.

A brand-new blender, thrown away after two years with a broken motor. “Can’t get it repaired anyway.” Maybe true. Maybe not. But the more interesting part comes before that: nobody even tried. Two years of daily use. Smoothies every morning. And still a complete stranger. A black box. Plugged in, used, disposed of.

Owning means understanding

The other day I came across this sentence: “If you can’t fix it, you don’t own it.” (iFixit manifesto). And there is something to it, I think: things we have put time and thought into are close to us. Things we merely consume keep their distance.

We throw things away in bulk today. Not because we don’t care about sustainability. But because we don’t care about the things. No relationship. No pain in letting go.

Agentic engineering

And we are now 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 defect? We quickly let Codex or Claude Code have a go at it. And presto, the defect is fixed. We don’t even know what the cause was. And even if we read it there, we are not immune to it happening again.

Same picture with testing. Generating test cases from requirements, hooray. Fast, clean, plenty of them. But: who understood along the way why this edge case exists? Which stakeholder conflict is hiding 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 is not.

Ownership grows in the process

Ownership does not come from receiving something. It comes from working through something. From debugging, refactoring, struggling, wrestling with it. From making a mistake and fixing it.

This kind of ownership is not meant romantically. If you own your code, you can repair it. If you own your architecture, you can answer for it. If you own your tests, you know what they check and what they don’t.

I would even say: the deeper we sink into it and work our way in, the more pride, connection and responsibility we have … we feel.

If you just take over AI output, you don’t have that. That is a difference.

Right now we are building software at full speed, assembled from generated parts that nobody has really worked through. And we call that productivity. It runs as long as nothing happens. As soon as something happens, everyone looks around helplessly … and asks the AI.

Finding the balance

You know I like AI. I use it a lot, too. But as so often with technology, we first have to learn to handle it in a healthy measure … and quickly, please. Right now I see a very large imbalance there. 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 am doing here, or am I building throwaway software?

One more thought to close: think about why you really started programming, or developing test cases, or designing architectures. I believe for most of us the motivation was: I can create something here, and building things is fun. Should we take that away from ourselves?

Share this page

Related Posts