I barely write code anymore.

My setup at this point is almost fully automated: Ralph loops grinding through tasks in parallel git worktrees, MCP servers wired into everything, agents planning, implementing, and testing while I do something else. My actual job has compressed into two activities. I orchestrate, deciding what should happen, and I review, judging what did happen. I type prompts and plans, I read diffs, I say yes or no.

Our CEO at ClickUp recently published a post about restructuring the company around what he calls the “100x org”, so I’m watching this shift from inside a company that is explicitly betting on it. Strip away the corporate framing and the technical core of his argument is hard to disagree with: the best engineers aren’t writing code anymore. They’re directing agents that write code, and the two real bottlenecks left are orchestration and review. As he put it, “the skill is judgment.”

He’s right. That is the skill now. And that’s exactly what worries me.

Because here’s the uncomfortable question nobody in the 100x discourse seems to ask: where does judgment come from? And what happens to it when you stop doing the thing that built it?

We’ve been here before

Years ago, at the start of my career, I watched a talk on YouTube by bobuk called “Can You Program Without the Internet?” (in Russian).

This was the Google-and-StackOverflow era, and the debate of the day was remarkably similar to today’s. Developers were shipping faster than ever. Any error message was one search away from a fix. Any problem had an accepted answer with a green checkmark and a snippet ready to paste.

And the concern was simple: people achieve their goals so easily that they stop learning anything. You copy the snippet, the test goes green, the ticket moves to Done, and your brain was never actually in the loop. The task got solved; the engineer didn’t get built. The struggle, it turned out, was the curriculum.

Sound familiar?

Round two, higher gain

What’s happening with AI right now is the same process, just with the dial turned way past where StackOverflow ever had it.

Back then, copy-paste still required some friction. You had to find the right answer among five wrong ones, read the snippet, adapt it to your codebase, fight the compiler when it didn’t quite fit. The friction was annoying, but friction is where learning lives. Every adaptation was a tiny rep for your brain.

Now even that friction is gone. The agent reads the error, writes the fix, runs the tests, and opens the PR. I handle several times more tasks daily than I did three years ago. I produce more code and, honestly, more value. The throughput numbers look great.

But it has become genuinely hard to stop and deeply think about what we’re doing and how we’re doing it. Not forbidden, just hard. The economics of the workflow push against it. Why spend forty minutes understanding a race condition when the agent already fixed it and three other tasks are waiting in the queue? Why read the library source when the model has read all of it already?

Learning is physical. New skills are new neural connections, and those connections form under load: effortful retrieval, confusion, the slow grind of holding a problem in your head until it yields. Cognitive scientists call it “desirable difficulty”. AI workflows are, almost by definition, machines for removing desirable difficulty. They optimize away exactly the thing that makes you better.

We’re getting faster and shallower at the same time, and the speed is masking the shallowness.

The judgment paradox

Here’s where it gets properly weird.

The market now pays for judgment. Orchestration and review: knowing what to build, smelling when the generated code is subtly wrong, catching the architecture decision that will hurt in six months. The ClickUp post is explicit about this. The engineers worth million-dollar bands are the ones who can architect and review at scale.

But judgment isn’t a skill you can prompt into existence. It’s compiled from years of manual work. Mine was built by debugging ProseMirror position mapping at 2am, by reading Quill source because of an internal bug, by writing the wrong abstraction three times before understanding why it was wrong. Every senior engineer’s “taste” is a cache of thousands of hours of hands-on struggle.

Orchestration today feels a lot like dialing a Stargate. The DHD does all the actual physics; you just punch in seven symbols and a stable wormhole appears. But somebody on the team still has to be Daniel Jackson, the one who spent years with the glyphs. Because a wrong address looks exactly like a right one, right up until you step through.

So the new economy runs on expertise capital while quietly shutting down the factory that produces it.

You can only meaningfully review code you could have written yourself. The moment your agents routinely produce code outside that envelope, you’re not reviewing anymore. You’re nodding along like Penny at one of Sheldon’s whiteboards. And the envelope doesn’t hold still: skills you don’t use depreciate, like a cache without writes that eventually serves nothing but stale data.

That’s the paradox. The job is judgment, judgment comes from doing, and we’ve automated the doing.

The old trick

In that talk, the trick that was suggested sounds almost absurd today: disable the internet and just work.

I actually did this. A couple of times a week in my early career, I’d kill the connection completely, pick a couple of tasks, and work fully offline. For documentation I used Dash, offline docsets for everything, still a great app.

It was painful at first, which was precisely the point. No internet meant no escape hatch. If I didn’t remember how Array.prototype.reduce handled the initial value, I had to read the docs properly, once, instead of googling it for the fifteenth time. If a library behaved strangely, I read its source. I learned to hold an entire problem in my head because there was nowhere to offload it.

I still think it was one of the most useful habits of my career. Not because the internet was bad, but because deliberately removing the crutch a few hours a week trained the muscle that the crutch was atrophying.

The 2026 version

These days I already block daily slots in my calendar for learning, protected time where tasks and calls can’t reach. It works, but reading and watching is passive. The original trick was about doing under constraint.

So I’m bringing it back, adapted for the new round:

# crontab for your brain
0 9 * * 2,4  /usr/bin/disconnect --agents --duration=2h

A few sessions a week, no AI in the loop. Not as productivity time but as training time. The distinction matters: the goal of these sessions is not output, it’s load. Things that go in those slots:

Writing a bunch of functions by hand, fighting my own typos, letting the type checker humiliate me. Reviewing a teammate’s PR without an agent summary, building the mental model of the change myself, line by line. Re-implementing some utility from scratch that I’d normally import or generate. Reading the actual source of a dependency I rely on, instead of asking the model to explain it.

It’s the same logic as going to the gym in a world full of cars and elevators. Nobody walks fifty kilometers to work to prove a point. But everybody understands that if you never move under your own power, the body quietly degrades. Same hardware, different organ.

Not a luddite manifesto

To be clear, I’m not disabling my Ralph loops. I still use automated personal agents to review PRs alongside me, and that’s not changing either. Refusing AI in 2026 isn’t principled, it’s just slow.

But agents without supervision have a known failure mode. Anyone who watched Silicon Valley remembers Gilfoyle’s Son of Anton fixing bugs by deleting the code that contained them. Technically correct, zero bugs remain. That’s roughly what an unsupervised agent fleet does to a codebase, except it’s much less funny when it’s your repo and the deletion passed CI.

The asymmetry worth noticing is this. Speed is table stakes now. Everyone has the same models, the same agents, the same tooling, and that advantage compresses to zero almost immediately. Depth doesn’t compress. Engineers with deep knowledge write sharper prompts because they know what good looks like, catch the hallucinated API before it ships, and smell the architecture problem the agent cheerfully built three features on top of. Expertise is the one asset in this whole system the agents can’t generate for you.

So that’s the plan, nothing heroic about it. Keep the loops running. Keep the learning slots. And a couple of times a week, go offline and lift something heavy with my own head. Worst case, I waste two hours writing functions a model would have written faster. Best case, a few years from now I’m still the one on the team who knows which address we’re dialing.