The Right to Explore

I was driving home today with Steven Levy's Hackers in my ears again. It's late in the book now, the Computer Faire, the first personal computers, the boom and then the crash. Yesterday I wrote about the hacker ethic meeting cybernetics, the kid with the robot bug and the grad students downstairs who wanted him out. Somewhere on the road a question came up that I couldn't put down.

None of those people understood the machine when they started. That was the whole point. They put their hands on it before they knew how it worked, and the machine taught them. So why is somebody who explores with AI today written off for not understanding yet?

Not yet

Not understanding yet is where learning starts. It isn't proof that learning failed.

There are three different states that get mashed into one. There's the person who doesn't understand a system and goes exploring because of it. There's the person who can make the thing work and is still finding out why it works and where it breaks. And there's the person who doesn't understand it and says it's correct, safe and ready anyway.

The third one is a real problem. The mistake is treating the first two like the third. Most of the hackers in Levy's book spent years in the first two. So did I. So does everyone who has ever gotten good at anything.

So here's what I'm saying. Not understanding yet is no reason to write someone off, as long as they close the loop against the real system and carry the risk themselves. That's all. I'm not saying AI is good, or that every use of it is fine. People learned this way long before there was any model to learn with.

We've been here before

John Backus led the team that made FORTRAN, an early programming language that turned formulas into machine code, and when he wrote its history he started with the mood of the 1950s. Before FORTRAN almost all programming was done by hand in machine language or assembly, and in his words, "Programmers rightly regarded their work as a complex, creative art that required human inventiveness to produce an efficient program."

When his team went out to describe a compiler that would write the machine code for you, the audiences "were mostly skeptical." And "most of all, our claims that we would produce efficient object programs were disbelieved."

A compiler isn't a language model. A compiler turns the same input into the same output every time, and a model can generate something different on each run. That difference matters and I'm not going to wave it away. Backus's skeptics could be answered with measurements, and he answered them by building a compiler whose output held up. Model output still has to be checked piece by piece. What repeats is the attitude: the real work is the part a person does by hand, and whatever a tool does for you must be worse. They had seen too many clumsy systems that didn't do what was promised, so they had reasons. They were still wrong about that one.

The doubt came from inside the craft then. The sharpest criticism of exploring with AI that I hear comes from engineers too, new to the work and long in it alike, and what they see as a break with everything before looks to me like the same thing as before.

It's all still just engineering.

Where the friction comes from

Here's what exploring with AI looks like when it works. Say a model generates a Kubernetes manifest for me, a file describing what to run on a cluster. I apply it and the cluster rejects it.

Now there are two paths. On one, I paste the error back and ask again, and again, until something passes. On the other, I read the events and the logs, find out what the cluster actually objected to, and fix it knowing why.

It's the same tool and the same error on both paths, and what I learn is completely different. The friction came from the world, from the real system saying no, and it was the kind I've called germane friction, the kind that builds you. The learning happened in me, or didn't, depending on what I did with it. The model generated text on both paths, the same kind of text, and it wasn't the one who had to learn from that no.

Understanding, when it shows up, lives in the person, and it gets built out of contact with something real.

That's the loop I care about. It closes through the real system and the evidence it hands back. The model's in there, off on one side. It never closes the loop.

Judging the tool instead of the work

Logic has an old name for judging something by where it came from instead of what it is: the genetic fallacy. "A model wrote it, so it's bad" is that move. So is "they used AI, so they don't understand it."

Where something came from can be a fair reason to look closer. If a tool tends to make a certain kind of mistake, check for that mistake. That makes the origin a reason to look, and for a single piece of work it never replaces looking. When reviewers are buried, the way open-source maintainers are right now, origin can fairly decide what gets read first. That's triage, and I'd do the same in their shoes.

The curl project shows both halves. Daniel Stenberg, who maintains it, ended curl's bug bounty this year because the torrent of submissions was swamping his security team. The point, he wrote, was to remove the incentive to send "crap and non-well researched reports to us. AI generated or not." A few months earlier he had landed dozens of real fixes, mostly small but genuine, from one researcher, Joshua Rogers, who found them with AI-assisted analysis tools. Stenberg called the findings "truly awesome." One project and one kind of tool, and it went opposite ways depending on who was using it and what they did with it.

The worry about slop has a real core, and I share it. I made the case against AI at full strength once, and this part of it still stands. More generated text, code and imagery is coming at readers and reviewers than anyone can absorb, and somebody has to answer for all of it. Volume is a real problem. Back in January I took the word on myself and wrote I Am AI Slop, because I'm standing right in the middle of it.

Judging one piece of work, or one person, by the tool they used, without reading the work, is a different thing. I'd ask anyone making that call to put some truth into it and look back at the history. Human slop has always been here. In 1968 NATO brought people together in Garmisch to talk about why large software projects kept arriving late, broken and over budget, and every line of that software had been written by a person.

Bad code was never the machine's invention. What's new is the volume, and that's the real problem to solve.

I'd rather help solve it than just name it. Working with AI is great for big hairy problems, the ones too big to hold in your head at once, and finding real bugs in a codebase the size of curl's is one of them. That's what the researcher's tools did for Stenberg. So here's what I can give back: do the exploring in my own lab, in the open, close the loop before anything leaves it, and only send other people work I can explain and stand behind.

The boundary

The right to explore stops where other people start carrying the risk.

My lab is a few little Kubernetes clusters on machines I own, the smallest world that still tells the truth. In there I can break things all day and the only one who pays is me. I built a small tool for that, Fidelitron, which makes the smallest world that can answer one question and reports the answer with its limits. Production is other people's money, data and time, and the standard changes there. Before something goes to production, someone has to be able to say what it does, how it fails and how to undo it. The same goes for anyone else's repo, inbox or review queue. A pull request to a project I don't maintain is spending somebody else's time.

A model has no standpoint. It selects among likely continuations, and it isn't accountable for what it picks, so it can't be responsible for a system. The responsibility stays with the person, whether they wrote every line or none of them.

What the studies say

The evidence so far is mixed, which is about what you'd expect from a few years of a new kind of tool.

Study	What it measured	What it found
METR, randomized trial, early 2025	16 experienced open-source developers, 246 tasks in their own repositories, with and without AI tools	Tasks took about 19% longer with AI allowed. Afterward the developers estimated AI had sped them up by about 20%. METR says it doesn't speak to less experienced developers or unfamiliar codebases.
METR, update, February 2026	A later run of the same kind of study	Unreliable, mainly because developers declined to work without AI. Its raw numbers now show a speedup, but METR calls them "only very weak evidence" of how big it is.
Cui, Demirer, Jaffe, Musolff, Peng and Salz, Management Science	Field experiments with 4,867 developers at Microsoft, Accenture and a Fortune 100 company	About 26% more completed tasks. Less experienced developers adopted the tool more and gained more. Copilot-era tools, 2022 and 2023; measures output, not understanding.
Borg and colleagues, "Echoes of AI," Empirical Software Engineering, 2026	151 participants, mostly professionals, preregistered	People extending code that had been written with AI help, working without AI themselves, showed no significant difference in time or quality. One Java task; the authors call any effect at most small and uncertain.
Shen and Tamkin, "How AI Impacts Skill Formation," 2026, randomized	Developers learning a new programming library, with and without AI help	AI use weakened conceptual understanding, code reading and debugging, with no significant average speedup. Those who handed off the coding learned least; the patterns that kept them thinking preserved learning.

These are different studies, tools and people, so they don't add up to one story. One showed experienced developers feeling faster while being slower. Only the last one measured learning, the thing this essay is about, and it found the two paths from the manifest example: hand the work over and you learn less, stay in the loop and you keep learning. That cuts against careless use, and I'm glad it does. How fast it feels tells you almost nothing. You have to close the loop and check.

A newcomer's view

I'm new to cybernetics, early in the reading, and this is what I'm learning to see. The person who trusts every output and the person who rejects every output are skipping the same step. Neither one looks at what the real system said back.

This is a real cultural problem right now. I'm an engineer and I teach, and it's hard to watch so much of the conversation turn against experimenting and learning, which is how this whole field got built.

I know plenty of people will disagree with this, and that's fine. I'd like the argument about AI and engineering, and about AI slop, to be about the evidence and the history, and a lot of it isn't yet.

A thinking machine

A little part of me wants to ask anyone who uses a computer all day and can't stand AI, what did you think we were building? Calculators? The hackers in Levy's book did a lot of their best work in a place called the AI lab, though their AI was nothing like today's.

I've always seen a computer as a thinking machine. Mine, as a kid, was an Apple IIGS. I typed BASIC into it with no real idea what I was doing, and the screen answered me. That was the whole relationship, right there. And I loved, loved, loved Softdisk G-S, a magazine for the IIGS that came by mail on floppy disks. I had a subscription, and new programs showed up in the mailbox every month. I knew about recursion early on, a program that calls itself, and I found it fascinating. Even as a kid I wanted to give the machine more power, and in the end the power to create and write its own programs. That was a dream of mine from the start. It sits right beside my love for systems, electronics and machines, and for the other mathematical and scientific universes, physics, chemistry, biology. All of it fascinates me.

A lot of kids in those years learned from type-in magazines, and Compute! was legendary. Every month the magazines printed whole programs, pages of them, and you sat at the kitchen table and typed them in line by line, long before you understood them. Compute! and its sister Compute!'s Gazette gave you a little program called the Automatic Proofreader and printed a short checksum beside every line, so when your line didn't match you knew exactly where you'd gone wrong. A checksum on every line. A feedback loop, printed in a magazine! And somewhere in all that typing you started guessing what the next line would be, then changing the program, then writing your own. Nobody called those kids frauds for typing code they didn't understand yet. They typed, the machine said no, they found the line, and a generation of programmers learned inside that loop. The checksum only told you that you'd copied the line right. The understanding came later, for the ones who stuck with it. I loved magazines growing up, and later on it was 2600, the hacker quarterly. Linux Journal, the main Linux magazine, is where I first remember reading about neural networks, in a feature on a neural network simulator out of the University of Stuttgart. The thinking machine again. I got to watch the PC arrive, then the internet, cloud computing, virtualization and containers, and now this. To me it feels like the dawn of cybernetics in action, a new age, and I'm lucky to be alive for it.

The hacker ethic is alive. It's in my blood and soul.

The hacker spirit is joining new ranks, people putting their hands on real systems for the first time with a model beside them, the way the students in Levy's first chapter put their hands on the TX-0 at MIT. Thank goodness for engineering, which gives that curiosity a safe place to go and a way to find out when it's wrong. And thank goodness for AI too, in the hands of people who keep the loop closed. The hacker ethic is the fire of engineering, and we have to keep the flame going.

What's the least a person has to understand to be responsible for a system bigger than their understanding? I have a word for the capability under that question, complexence: standing inside a system larger than yourself, seeing it whole, and still choosing. I don't know yet how much understanding it takes. I'm going to find out the way the hackers did.

Related reading: A Sound Plan, a Napkin Films short from the same night that makes this argument as a duo rap: the fear verse is the same speech in a new font, and the turn is taking it apart to learn it.

Source	Where
Steven Levy, Hackers: Heroes of the Computer Revolution (1984)	the hackers, the Computer Faire
John Backus, "The History of FORTRAN I, II, and III," ACM SIGPLAN Notices (1978), sections 1.1 and 2	the 1950s attitude to automatic programming, the skeptical audiences
Peter Naur and Brian Randell, eds., Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, Garmisch, 1968 (published 1969)	the 1968 conference
Charles Brannon, "The Automatic Proofreader," Compute! (March 1984)	the checksum beside every line
Softdisk G-S, the Apple IIGS edition of Softdisk (from 1989)	the magazine on floppy disk
Ed Petron, "Stuttgart Neural Network Simulator," Linux Journal 63 (July 1999)	the feature on neural networks
METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (2025)	the slowdown, and the gap between felt and measured
METR, uplift update (2026-02-24)	the selection problem in the later run
Cui and colleagues, "The Effects of Generative AI on High-Skilled Work," Management Science	completed tasks, and who gained most
Daniel Stenberg's curl bounty decision, reported in The Register (January 2026) and the Rogers fixes, via Simon Willison (October 2025)	curl, both halves
Judy Hanwen Shen and Alex Tamkin, "How AI Impacts Skill Formation" (2026)	learning with and without AI
Borg and colleagues, "Echoes of AI" (preprint), published in Empirical Software Engineering vol. 31	maintainability of AI-assisted code
The Hacker Ethic Meets Cybernetics and Germane Friction	the posts this one follows from

How this was made: an AI model generated the first notes and the loop diagram in a chat, and an agent drafted from those notes and my messages and checked the sources. I chose what stays, and I answer for it.