What to do when AI is quietly making you worse – Vardan Torosyan

What to do when AI is quietly making you worse

I’ve been thinking about this for a while now, and a recent Root Cause podcast conversation pushed me to finally write it down. In the podcast they talking about something that I suspect a lot of engineers feel but rarely say out loud: you might only need deep system knowledge 1% of the time, but that 1% is often the moment that matters most. And AI is quietly eroding exactly that.

This isn’t a “AI bad” post. I’ve been using it heavily - for coding, for analysis, for thinking through hard problems. The throughput gains are real. But throughput and understanding are not the same thing. And I think we are, collectively, choosing throughput in a way that we’ll regret.

What actually erodes

The risks aren’t dramatic and they are not immediatly visible, they’re slow and they’re invisible.

When you stop fighting with hard problems directly, the mental models fade. You stop building intuition. You start pattern-matching on outputs instead of reasoning from first principles. And the worst part –> you don’t notice it happening. The code still ships. The PR still merges. Everything looks fine until the incident at 2am where you genuinely cannot reason about what the system is doing because you never really had to learn it.

There’s a good analogy here from aviation. Pilots trained heavily on autopilot gradually lose the ability to fly manually and this isn’t theoretical, it’s contributed to real crashes. Air France 447 is the well-documented case. The response from regulators wasn’t to ban autopilot, it was to mandate manual flying hours. The industry recognized that certain skills only stay alive through deliberate practice, and built that practice back in artificially. We haven’t done anything equivalent in software yet .

The junior problem is where this gets most acute. New engineers joining today may never develop system intuition the way the previous generation did, because the friction that forced learning is gone. Getting stuck for hours on a weird race condition, debugging by reading logs, writing something from scratch and not understanding why it was slow - those were annoying, but they put knowledge in your head in a way that reading the answer doesn’t. We’re removing that forcing function without replacing it with anything. The people who need the reps most are the ones who never get them.

The three things that actually still matter

A few days ago I organized some thoughts on this in an internal talk, and I keep coming back to the same framing: engineering right now boils down to three things.

What problem should you solve? This requires taste, judgment, closeness to the customer. Cannot be outsourced to AI.

How should you solve it? Architecture, tradeoffs, understanding the system. Fundamentals compound here: a 25-year engineer’s grasp of OS internals still makes them dramatically better even as AI does more of the actual coding.

Actually solving it. AI is handling more and more of this. It’s the part changing the fastest.

The trap is thinking the third thing is the whole job. It was never the whole job. It just happened to be the most visible part. Now that it’s getting automated, the first two things are getting exposed as the actual leverage and a lot of engineers aren’t ready for that.

What nobody talks about: how do you actually develop judgment?

Everyone says judgment will matter more. Agents will do the thinking, humans will make the decisions. Fine. But nobody really explains how you develop that skill, or how you avoid losing it.

I think judgment is built from a specific loop: you form a view, you commit to it, you see what happens, and you update. That cycle, repeated enough times, is what builds calibration. The problem with AI is that it short-circuits the first step. You skip forming your own view and go straight to evaluating someone else’s. Do that enough and the muscle atrophies and again, not dramatically, just quietly. You become a better reviewer and a worse thinker.

Two practices I’ve found actually help, and they’re related.

Write before you look. Before opening a tool, before asking the model, write down what you think. Not a design doc necessarily, just your current understanding of the problem, your instinct about the solution, where you think the tricky part is. Even a few sentences. This forces you to articulate your reasoning rather than pattern-match on someone else’s output. It’s also surprisingly useful as a diagnostic: if you can’t write anything, you probably don’t understand the problem well enough to evaluate any answer.

Form a view before reading the suggestion. When reviewing AI-generated code or design, read it critically with your own opinion already in hand. What would you have done? Where does this differ? Why might the model have gone this direction and is it right? This sounds small but it’s the difference between passive consumption...