Ship and Learn Are Two Different Metrics

Addy Osmani wrote a short thing recently called "Don't Outsource the Learning." It stuck with me, not because it was new, but because it named a habit I had been pretending I did not have. So here is my version, the one that actually shows up in my week.

The loop that skips the part that matters

You hit an error, or a blank file. You paste the spec, or the stack trace, into the model. It hands back something that works. You skim it, accept it, ship it. Green check. Next.

No single pass through that loop is wrong. It goes wrong in aggregate, because of what it quietly removes. The struggle you just skipped, sitting with the error, building a wrong theory, throwing it out, building a better one, was not in the way of the work. For most of my career it was the work. It was where the learning happened. Skip it every time and you keep shipping while you stop learning, and from the inside those two feel exactly the same. The green check looks identical whether you understood the change or not. That is the whole problem in one sentence.

I catch this most on my own projects, where no reviewer is going to catch it for me. Building Raised, dogfooding Compass, putting the Maven course together, the pull is always the same: let the model close the task and move on. Then a week later I am looking at a function in my own codebase that I cannot fully explain. I did not build the understanding. I built the file.

What you are actually paying

The cost is easy to miss because it is deferred. You are not paying in bugs today. You are paying in cognitive debt, a balance of skipped understanding that comes due later, usually at the worst possible moment.

The defaults push you toward taking on more of it. An assistant is tuned to close your task, not to keep you sharp. Those are not the same goal, and the gap between them is where your skill leaks out. The tool is doing exactly what it was built to do. Nothing in the product is going to supply the intent to learn. That has to come from you, every time, against the grain of how the thing wants to be used.

The research is starting to catch up to what this feels like. An MIT Media Lab team wired people up while they wrote essays with and without an AI assistant, and the assisted group showed lower engagement and, tellingly, struggled to quote back essays they had supposedly just written. The thread running through this work is not any single number. It is that the tool matters less than your posture toward it. Interrogate the output and you keep learning. Paste it and move on and you do not. Same tool, opposite result.

When delegation stops covering for you

If pure delegation worked forever, none of this would matter. It does not, and the bill tends to arrive in a few predictable places.

The worst one is when the model is confidently wrong. A plausible answer that happens to be false throws no exception. It reads exactly like a correct one, and if you never built your own model of the problem, you have nothing to check it against. You ship the wrong thing with full confidence. The other place it bites is at the edges: models are excellent at the common case, and your most valuable problems are, almost by definition, not the common case. That is precisely where the assistant thins out and you are on your own with the understanding you decided not to build.

The slower failures matter too. Frameworks and APIs move, and the patterns a model leans on are last year's until you have done the work to adapt them. And there is the market itself. When everyone can generate working code, generating working code stops being scarce, and judgment becomes the thing people pay for. An engineer who only ever closed tasks has spent two years training the one muscle that just got cheap.

The fix is posture, not abstinence

I am not telling you to put the tools down. That would be slower and dumber and I would not do it either. The fix is a change in how you hold the tool, not how often.

Before you prompt, write one line of what you think is going on and what you expect the fix to be. Now the answer confirms or corrects a real theory instead of filling a vacuum. Ask for the reasoning before the code, and if the explanation does not land, the code is not ready, however green the check looks. Read what comes back the way you would read a junior engineer's pull request, because that is what it is, and the bar does not drop just because a model wrote it. For anything you actually want to own, rebuild the key piece once by hand. It is slow and it is worth it. And when the topic is genuinely new to you, let the session optimise for understanding rather than speed. The same prompt that closes a task can also teach you the task, if you ask it to.

None of that is anti-AI. It is the line between using the tool to extend your judgment and using it to replace it.

The two metrics

Here is the question I have started asking myself at the end of a day: did I learn anything, or did I just close issues?

They are two different metrics, and only one of them gets tracked. Issues closed, pull requests merged, features shipped, all of that shows up on a dashboard and gets asked about in standup. Whether you got sharper this week appears on no chart anywhere, so it quietly stops happening, and the line that matters most to your career is the one nobody is plotting.

Keep shipping. Ship is real and it pays the bills. Just do not let it be the only number you watch, because the other one, the invisible one, is what decides whether you are still the person worth hiring once the shipping is something anyone can do.

I write about system design and the senior-to-staff transition every week in Monday BY Gazar on Substack, and I break down architecture and engineering decisions on Gazar Breakpoint on YouTube. If you want this thinking applied live, my Maven cohort Production-Ready Systems with LLMs and Agents is a hands-on intensive (July 13 to August 23, 2026), and my free lessons and other cohorts are on my Maven profile.