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. The work is moving toward two things: having the ideas, and checking the result. My attention has moved up a level — away from how a detail is implemented, toward the shape of the thing.

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 was never the calculator. It’s reaching for it before you understand what you’re computing.

So what a junior needs now isn’t “be able to do everything without AI.” It’s this: 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 wasn’t the answer. It was the 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.

But really, this isn’t the story of me starting to use AI. It’s the story of what becomes scarce once implementation no longer is — and of starting to see it. AI doesn’t pile more work on the engineer — it moves the center of the work from implementation to judgment. What carries value from here isn’t being able to write code; it’s being able to see what should be built.