AI took me somewhere new, and proved me wrong // Ollie

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.