Directing the Delegation

The build that wouldn't deploy

A deploy fails on Vercel. The first error is easy — Node 18 is going away, the project needs 22.x. Upgrade, push, wait.

The next build fails differently. Puppeteer can't find the libraries it needs. Add libnss3 through build config. Fails. Try an alternative Chromium package. Fails. Adjust executablePath. Now the error says the path points somewhere Vercel's runtime simply doesn't support.

At that point the logs have stopped being useful in the way logs are supposed to be useful. They name a symptom. They don't name a cause. What got me out of it wasn't AI knowing Puppeteer — AI knew Puppeteer fine, and every fix it offered was a reasonable fix for the error message in front of it. What got me out was knowing there was a dependency chain to look at: rollup-critical-plugin runs Rollup plugins, which run Penthouse, which depends on an older Puppeteer that expects a runtime Vercel can't guarantee. Once I could see that, the question changed from what does this error say to where does this error come from, and the answer stopped being a patch and started being a decision — move the build to GitHub Actions, where I control the environment, and let Vercel deploy the artifact. I wrote up that whole investigation here.

Now take the same failure, minus that. Same logs, same error chain, same tooling — but you didn't build the chain, you approved it. Every suggestion looks plausible because you have no basis for finding it implausible. You try one, it fails, you try the next. This is the circling. It isn't a knowledge gap about Puppeteer. It's that the logs point somewhere you don't have a map for.

I've been in both positions. The difference between them is not how much AI was used. It's who was holding the reasoning.

Give AI the right to answer how. Keep the decision on why.

The thing worth noticing is that nothing went wrong at the moment the reasoning was handed over. The config got written. It probably worked. The cost of that handover became visible here, at the failure, weeks later.

What the study found

Anthropic looked at this directly: how AI assistance impacts the formation of coding skills. Developers learned an unfamiliar Python library, some with assistance and some without.

What stayed with me from it is that using AI didn't decide the outcome. How it was used did. The developers who came out stronger used AI assistance not just to produce code but to build comprehension while doing so — asking follow-ups, requesting explanations, treating the tool as something that could account for its own output rather than just produce it.

That matches what my own work looks like. The tool is the same tool either way. What differs is what the person in front of it is doing with it.

How you use it comes from whether you own the why

Asking follow-up questions is a behaviour, and behaviour comes from somewhere. What produces it, in my experience, is whether the developer holds the reasoning behind the work.

Someone who knows why they need a function asks different questions than someone who doesn't know they need one. The first developer is checking an expectation against a result. The second is waiting to be told what the result should have been. Both can be described as using AI to write a function, and the description is useless, because one of them is directing and the other is delegating without direction.

It always starts from a human. Even AI is built by humans. Whatever the tool produces, someone decided the thing was worth producing, and that decision is the part that doesn't transfer.

What changed for me when AI arrived wasn't that I stopped needing to think. It's that the thinking moved. I don't spend time on how to write a function anymore. I spend it on knowing that I need that function, and when, and whether something else would solve the problem better. Before, syntax was a bottleneck — I struggled with it, and it slowed everything down. With AI I could finally see a project from start to finish, because I wasn't spending the day on scaffolding and config files. That time went to the things that actually decide whether a project works: knowing when a function needs extending, why a configuration file is causing a deployment to fail, why an HTML element isn't getting the CSS rules applied.

The study's own evaluation design points the same direction — it treats low-level code writing, remembering the syntax of functions, as the part that matters less as these tools integrate, and high-level system design as the part that matters more.

This is where the asking comes from. If you have an idea, you know what to ask for — and if AI writes the code, you'll understand the translation, because you know what you asked for. If there's something in the syntax you don't recognise, you ask for the explanation and move on. The questions aren't a technique you apply to get more out of the tool. They're what directing sounds like from the outside. You ask because you're the one who knows what the thing is supposed to do.

The explanation is always available. Whether it becomes understanding depends on whether you asked, and you ask when you are holding the why.

I wrote about the shape of this distinction in Real vs. Allowed Ownership — the difference between understanding your code and approving it.

Why the debugging gap follows

The gap between the two groups was widest on debugging. That's the part I'd expect, and I think the reason is fairly plain.

Debugging is the first task that requires the reasoning behind the code rather than the code itself. Everything before it can be done without that reasoning. You can write code you don't understand and it will run. You can ship it. You can put it in production and it will serve requests. Nothing in the process forces the question of why is this here until something breaks — and then the question is mandatory, and it's the only question that helps.

This is also why the cost is invisible for so long. There's no feedback signal on the day you accept a suggestion you couldn't have written. The signal arrives at the next failure, and by then it's not one decision you're reconstructing, it's every decision since.

What follows from this is a standard I try to hold: you have to be able to fully verify the code you stand behind, regardless of who wrote it — you or AI. Not it ran. Not it looked right. Verified. That means you have to be able to recognise when the output is wrong, which means knowing enough about the shape of correct answers in that context to notice a wrong one. It means seeing patterns in AI responses and knowing where they tend to break down.

You have to act like someone who shapes everything, and take on the responsibility that comes with it.

That Vercel build is this finding in production. The whole reason I could stop patching and start reasoning about placement was that I knew what the pipeline was for.

Where I'm standing when I say this

I should be clear about the position I'm describing from, because it isn't neutral.

I had six years of development behind me before AI became part of how I work. The mental models came first. When AI arrived it removed a bottleneck that had been sitting around models I already had — I was genuinely relieved to have it, because syntax had been costing me time I wanted to spend elsewhere. That's a different situation from starting out with the tool already in place.

Directing requires something to direct with. I can steer because I know roughly where I'm going, and I know that because of work done before the assistance existed. That's the honest shape of my claim.

The participants in the study were largely junior and working in a library they didn't know. That's a different starting point from mine, and worth naming so anyone reading can locate themselves against it rather than assuming my experience maps onto theirs.

For developers still building those models, whether the director role is available to them yet is an open question. It's one of the things my ongoing research is aimed at — and not only for juniors. Cognitive drift isn't a beginner's problem. It's what happens to anyone who stops holding the reasoning, at any level of experience.

Agentic tools, and what I'm building

The study carries a footnote worth sitting with: the setup they tested is different from agentic coding products like Claude Code, and they expect the effects on skill development to be more pronounced there.

Under the framing in this post, that follows directly. Agentic tools operate at exactly the level where the why is easiest to hand over. You're not reviewing a function; you're approving an outcome. The reasoning that connected the problem to that outcome happened somewhere you weren't, and there's often no artifact of it left to inspect. Everything I've described as the slow, invisible cost of delegating reasoning applies with less friction and at greater speed.

That's the direction of the research I'm working on: cognitive drift in developers, under the premise that AI should witness, not compete for cognition. The AI Observer Tool is the instrument — it logs what the AI proposed alongside what the developer decided, so the two can be told apart afterward rather than blurred together in the commit history. It's in early stages. It's being built, not deployed, and I don't have findings to report yet.

What I have is the failure at the top of this post, and the fact that I've been on both sides of it. The tooling will keep getting better at how. Nothing is coming to take why off your hands, and nothing should.