learning to lean

In the first note on this site I said that agents becoming common would bring good and bad, and that it was for another post. This is that post.

borrowing carefully

Around 2023, when ChatGPT was suddenly everywhere, I started letting AI write small things for me. The work was narrow: write this for loop, fill in this function where the requirements were already settled. I was skeptical of the output, so I leaned on tests and read everything carefully.

Honestly, between the rewrites and the reviewing, it wasn’t much faster than writing it myself. And I was moving into a part of the field that was new to me, so I wanted to understand things with my own head before building on them. So through the end of 2025 I held back on purpose — I kept the parts I handed off small, so I’d actually learn instead of skipping the lesson.

learning to lean

Two things changed my mind. My own field had settled enough that I understood it. And I watched a friend who had folded AI agents completely into how he works — and saw that you can learn from what they produce, and that if the speed is real, holding back was just costing me. So in early 2026 I started using coding agents properly: Claude Code and Codex. By then they were good.

It felt like a small revolution. And I think the reason it worked was the time before it. Having done the work by hand for a while, I had enough footing to judge whether the output was any good, instead of just trusting it. That’s the whole thing for me:

you don’t hand your judgment to the tool. you use the tool on top of it.

i don’t read every line anymore

My process now is different. Instead of reading the code top to bottom, I ask the agent what the design is and why it’s that way, get my bearings, and judge from there. Then I check that it actually works on screen. I don’t look at which function is called where, or how exactly something runs, until I have a reason to care. The one thing I still read is the tests, when a project has them — they’re the cheapest way to know the behavior is pinned down.

Reading every line by hand is starting to feel like the wrong use of my time. While I was writing this, the team behind Bun used Claude Code to port close to a million lines from Zig to Rust in about six days — and trusted its test suite, not a line-by-line read, to tell them it worked. The work is moving toward two things: having the ideas, and checking the result. My attention sits on the shape of the thing now, more than on the typing.

where the design comes from

That shift puts more weight on the shape of a thing than on the typing. When I already have a clear design, the cleanest path is to hand it over and let the agent fill it in — that’s the least rework there is. So when I know the shape, I pin it down first: what we’re building and why, what the data looks like, where it breaks.

But I don’t always know the shape going in, and pretending I do is its own trap. I often can’t see the best version of something until I’m looking at a concrete one. The agent changes the math here, because a rewrite is suddenly cheap: I can have it build a rough cut fast, read that, and a better approach shows up that I’d never have reached on a whiteboard. I tell it to redo that part, and a few minutes later it has. Building becomes a way of thinking.

So it isn’t really “design first” or “build first.” What’s worth avoiding is the vague middle: handing it a loose brief and then treating the first thing it builds as the answer. A loose spec gets implemented just as fast as a tight one, so a half-formed idea becomes a half-formed system before I’ve looked at it. The point isn’t a perfect design up front — it’s staying in the loop: decide what I can, let it build, and keep judging the shape as it takes form.

the answer machine

At work we’re rolling AI out across the board, and I’m one of the people planning and researching how. That raised an obvious question: when juniors with no real experience join, how do we train them? People worry — you hear it in classrooms too — that AI makes you think less, that it dulls you. I don’t think that’s right. Used well, I learn more, not less: the details get filled in, but I get to see the whole picture, and when I want a detail explained, it explains it more clearly than a person usually would.

But the worry isn’t empty. Used as an answer machine — paste the question, paste the answer, never read, never think, never check — yes, you’ll stop growing.

People reach for the calculator here: it made us worse at arithmetic. That’s true, but it’s only half the story. The calculator didn’t just take something away; it changed what we bothered to teach. We stopped drilling long division and spent that time on the problems worth solving. A tool that fills in the low layer doesn’t have to lower you — it can raise the question you’re allowed to ask. The risk is reaching for it before you understand what you’re computing.

So what a junior needs now is to move fast with it and still judge for yourself. And I think the not-taking-it-at-face-value part can be trained, because for me it’s mostly a habit. When I look at what the agent gives me, there are only three things worth asking:

• what is it assuming?
• what is it missing?
• when it breaks, who gets hurt?

When I do this, the agent stops being an oracle handing down answers and becomes what it should be — something that gives me a draft to push back on. On a backend api I work on, its first cut at the design carried a lot of redundancy — the packages weren’t organized consistently, and the values the api returned weren’t consistent either. I pushed back, we tidied it down, and that’s the design it runs on now. The output was a first draft.

the debt nobody reads

There’s a bigger version of this worry I don’t want to wave away. When everyone leans and almost no one reads — what people now call vibe coding — the code gets written but the understanding doesn’t. Systems pile up that work today and that nobody holds in their head, and the bill comes later, in maintenance: when something breaks, you need someone who understands it, and if no one ever did, that person doesn’t exist.

I’ll be honest: my own way of working feeds this if you take it on its own. I lean because I put in the time to understand the work first; the leaning is the last step, not the first. Skip that and copy only the leaning, and you get exactly that debt — multiplied by everyone.

what it gave me

Here’s the part I didn’t expect. The fear around all this is that AI takes the engineer’s place. It hasn’t felt like that to me. It’s felt like growing more hands — the range of what I can reach got bigger.

And it showed me something about myself. I’d always known I liked turning an idea into something real and putting it in front of people. What I realized is that I like that part more than the writing itself — that it’s the part I was really after. It’s still making, just at a higher level. So from here I want to trust my own hunches more, and spend less of myself on the layer a tool can fill.

I’ve only been working this way for a few months, though, and AI moves fast enough that I expect to disagree with some of this before long. It’s a snapshot, not a settled view.

Still, this isn’t really the story of me starting to use AI. It’s the story of what becomes scarce once implementation no longer is. The center of the work has moved from implementation to judgment, and what carries value from here is seeing what should be built.