Matt Whetton recently wrote a piece about the wall between technical and non-technical builders. On one side, the people who build from understanding and can maintain what they ship. On the other, the people who can assemble something but couldn't keep it running on their own. AI was meant to be the thing that finally let the second group across.
Matt's argument is that it hasn't worked out that way. The wall didn't shift sideways to let people over. It turned, and now runs through each project instead, however technical you are. There are parts you understand and could maintain, and parts you've effectively rented: code you can operate but couldn't rebuild or fix without relearning it first. The article is worth reading in full.
My first instinct was to disagree. Plenty of it rang true, but not the central claim: that this line now runs through everyone's work. I couldn't find it in mine, and I sat down to write a reply explaining why.
Mostly a pair programmer
Most of the time I use AI as a pair programmer, something to think against rather than hand the thinking to. Debugging a stubborn fault, pulling a design apart before it reaches a colleague. It narrows things down fast and it's good to argue with, but I stay in the problem the whole way through. None of that touches ownership. The reasoning stays mine.
My default is still to write the code myself (yes, still, even with [whatever dropped this morning]). Now and then, though, I hand a whole job over. For a moment the code genuinely isn't mine, but that fades in the review. By the time I've read it and understood it, I hold it like a teammate's code, or like my own from more than a day ago. I couldn't rebuild it from memory, but I could work it back up eventually if I had to, and when it breaks I can fix it myself. The standard hasn't changed: if I won't sign a piece of work off as mine, I don't commit it.
That was the reply I meant to write. In my own stack the line is faint. I work in languages I know, AI's code lands where I could rebuild it if I had to, and the part I'm renting never feels far out of reach. Then I built something on unfamiliar ground.
I built something I can't rebuild
The project was contract work, a proof of concept for an external client. The shape was mine: the architecture, the planning, how it all fit together. What AI did was the translation, turning that design into running code. It's written in Python, a language I can more or less read but don't write.
I can follow the structure, and roughly what it's doing. But I couldn't rebuild it, or maintain it directly, without far more effort than my work usually asks. There it was, clean as anything: the thinking unarguably mine, the implementation rented, a line running straight through a project with my name on it.
I wasn't trying to prove Matt right. I set out to build a proof of concept and met the line on the way. And I'd do it again. The thing works and I trust it, because the design under it is mine and I understand that completely. I'll take it to production, I'll answer for it, and I'll keep AI alongside me to maintain it.
We've always built on code we couldn't reproduce, of course, the language, the framework, the libraries we pull in unread. But those are shared and proven, leaned on by thousands. This was written for my problem alone, and I'm the only one who answers for it.
Matt was right
So I was wrong, and Matt was right. The line ran straight through that project. I'd been looking in code I could have written myself, where the line barely shows. It comes into focus when AI takes you somewhere you couldn't have gone alone, into a language or a problem outside your own. That is where the potential of all this sits, and where the line is impossible to miss.
The shift underneath is a strange one. AI has pulled apart two things that always travelled together: being responsible for something, and being able to rebuild it yourself. If you owned a system, you could once have rebuilt it, given time. I could rebuild this only as a different system, in a language I write, never the thing as it stands. And I own it anyway. That gap is what's new.
The divide didn't move with it
Where I part company with Matt is the larger claim underneath: that the split between technical and non-technical people has gone. I don't think it has.
A non-technical builder owns the work up to the line and hands the rest on, expecting someone else to answer for the part they rented. A technical builder has the same line and owns the whole thing regardless. It's the old rule of team management, the one that says you can delegate the work but not the responsibility, turning up somewhere new.
I've watched AI move people across that divide. A colleague who'll tell you they're not technical has built real internal software with AI: interfaces, databases, tools the business runs on. They own it, and when it breaks they dig in rather than hand it off. That's the crossing. Not into engineering, but far enough to count as a technical builder.
It doesn't always happen. Someone at another company had built a sprawling, widely-used tool entirely with AI. It mostly worked, but it was stalling, the foundations too thin to carry what they wanted next. They couldn't say how any of it worked and didn't want to find out. So they went looking for someone technical to hand it to. They reached the same line and stopped, handing everything past it to somebody else.
Being a software engineer still comes down to one thing: whether you take responsibility for the whole of what you ship, the rented part included, and stay with it when it breaks. That's the job it has always been, and the part of it AI hasn't (yet) touched.
As a side note, seeing Matt write his articles, working things out in the open and learning in public, is what encouraged me to start writing up my own thoughts and experiences. His back catalogue is worth your time.
References
- Matt Whetton, "The line moved into my own work", Sidewrks. The piece this is a reply to.
Human written, AI assisted.
Top comments (2)
That is the line. One push, on the move you make right after it.
You frame the difference between library-rented code (shared and proven, leaned on by thousands) and AI-rented code (written for your problem alone) as a question of trust by share-count. The sharper version of the asymmetry is external verifiability. A library has a community, a bug tracker, a public history, prior incidents in other people's repos. When something looks wrong you can ask anyone. AI-translated code written for your one problem is a private artifact. Nobody else has the receipt. The corroborator does not exist outside your runtime.
That recasts ownership too. You can defend the design because it has external anchors: the client's domain constraints, the protocol it speaks to, the requirements that exist independent of any one implementation. You cannot defend the rented implementation in the same way, because the only witness to whether it is right is the same system that wrote it.
So the part you trust is not the part you would rebuild. It is the part something other than you can corroborate. The design has corroboration. The translation does not. That is what shifted under your feet on the Python project, and it is the same shape showing up in agent audit logs that self-attest and in benchmarks where the judge and the player are the same network.
Responsibility for the whole when it breaks holds as a rule. The work the rented part does between now and breakage is where AI moved the cost.
Thanks, this is a great comment, and "can anything outside the system check this?" is a sharper way of putting it than my share-count version.
One push back though: that self-verification problem isn't unique to AI code. I write custom logic most days, and how do I know it works? I write tests and I QA it by hand. That's it. Nothing external to me, the thing that wrote it, confirms it's right. Code I write myself is just as much a private artifact as the stuff AI writes.
And humans produce that confident green tick all the time. I once spent ages chasing a bug that had a passing test covering the exact thing that was broken. The test was set up correctly right up to the last line, where instead of asserting on the result it just asserted true. All green, no problems here. A person wrote that, years before AI was involved.
So how different is this really from a manager handing a developer some requirements and getting code back? My instinct says AI is a bigger deal, but side by side I'm not sure. Both can misread requirements, miss an edge case, hand you a test that only looks like it's checking something. Either way the person who owns it has to check the result themselves, not lean on something external that says it's right.
So I don't disagree, I just don't think it's as dramatic a shift as it first looks. The verification was always on me. AI is one more thing producing code I then have to stand behind.