Seniors Use AI Like They Used Google

Think back to when Google became the default tool for every developer question. Two very different patterns emerged almost immediately.

A senior engineer would type something like: "nginx reverse proxy upstream keepalive timeout" — and land on exactly the right StackOverflow thread in the first click.

A junior would type: "my website is slow" — and spend 45 minutes reading articles that weren't quite about their problem.

Same tool. Completely different outcomes. Not because one person was smarter. Because one person already knew what they were looking for.

AI is the same story, one decade later.

The Junior Trap: Hoping for Magic

When a junior developer hits a wall, their instinct is to describe the symptom and hope the AI figures out the rest:

"My app isn't working. Can you fix it?"

"Write me a backend for a social media app."

"Why does this code not do what I want?"

These prompts aren't stupid — they're just underdetermined. The junior doesn't yet have a precise mental model of what's wrong or what they need. So they hand the vague feeling to the AI and wait.

The AI responds with something. Sometimes it's close. Sometimes it's completely off. The junior either accepts it without knowing why, or gets frustrated that "AI doesn't work."

The tool didn't fail them. The question failed them.

The Senior Move: Knowing What You're Looking For

A senior engineer uses AI the same way they used to use Google or documentation: as a tool to confirm, retrieve, or generate something specific they've already reasoned about.

They've already mentally decomposed the problem. They know whether they need:

A syntax reminder for something they don't use often
A second opinion on a design decision they've already drafted
Boilerplate for a pattern they know well but don't want to type out
An explanation of a concept they've heard of but never dug into

So their prompts are precise:

"I'm using Postgres. I have a query that does a self-join on a 2M row table. Here's the explain plan. What index would help most here?"

"I want to implement the outbox pattern for reliable event publishing. Here's my current service structure. What changes do I need?"

"Is there a name for this pattern where the caller provides a callback to control retry logic? I've been calling it strategy but I'm not sure."

The AI isn't doing the thinking for them. It's extending thinking they've already started.

Here's a concrete example. AI can generate a diagram in seconds — Mermaid, C4, sequence, ERD, whatever you need. That's genuinely fast and useful. But to get there, you first need to know that those diagram types exist, what each one communicates, and which one fits your audience. A senior presenting a design to customers and engineers already has that knowledge. So they use AI to execute quickly on something they've already decided.

A junior in the same situation doesn't even know those choices exist. They might ask AI to "make a diagram of my system" and get something back without understanding whether it's appropriate for a non-technical customer or a backend team reviewing the architecture. The speed was there. The knowledge to direct it wasn't.

This Was Always True

The Google parallel isn't accidental. The same dynamic played out with every tool that lowered the barrier to information:

Before Google: Seniors knew which book, which man page, which IRC channel. Juniors didn't know what they didn't know.

With Google: Seniors knew what terms to search. Juniors searched their symptoms.

With Stack Overflow: Seniors could tell immediately which answer was actually correct and which was the accepted-but-wrong one. Juniors copy-pasted the top answer.

With AI: Seniors know what output they're driving toward. Juniors are exploring in the dark.

The tool changes. The underlying gap doesn't.

What the Gap Is Actually Made Of

It's tempting to call this a "prompting skill" gap. But that frames it wrong. Better prompts come from better mental models, not from memorizing prompt patterns.

The real gap is about three things:

1. Problem decomposition. Seniors break a vague problem into specific subproblems before opening any tool. Juniors start with the tool and hope decomposition happens along the way.

2. Knowing the vocabulary. You can't search for something you don't have a name for. A senior who knows the term "distributed tracing" can ask about it precisely. A junior debugging a slow microservice might not even know that's the domain they're operating in.

3. Judgment about output. Seniors evaluate the AI's response against their existing knowledge. They notice when the AI confidently produces something wrong. Juniors often can't tell the difference — and that's when AI becomes actively dangerous.

The Uncomfortable Implication

If this framing is right, then AI doesn't actually close the gap between seniors and juniors. It might widen it.

Seniors get dramatically more productive because they can use AI to skip the boring parts of work they already understand. Juniors who lean on AI to do their thinking end up with code they can't explain, architecture they don't own, and gaps in their mental model that compound over time.

The junior who uses AI as a crutch learns less. The senior who uses AI as a multiplier delivers more.

This isn't an argument against juniors using AI. It's an argument for juniors understanding what AI can and can't replace in their development. The tool works best once you have something to work with — a hypothesis, a direction, a vocabulary.

What Juniors Can Actually Do About This

The single most important reframe: use AI to learn faster, not to skip learning.

Those two things feel similar but lead to completely different outcomes. Using AI to skip learning gives you an answer you can paste. Using AI to learn faster gives you an understanding you can build on. The first makes you dependent. The second makes you dangerous.

In practice, that means:

When AI gives you code, don't stop there. Ask it to explain the decision. Ask what alternatives it considered. Ask what would break this. Ask why it chose that approach over another. Turn every output into a conversation, not a copy-paste.

Practice decomposing before prompting. Before you open the AI, write down in plain language: what do I think is wrong? what am I actually trying to achieve? what constraints exist? This forces the mental model to form first — and you'll often find the answer yourself before you even need to ask.

Build vocabulary deliberately. You can't ask a precise question about something you don't have a name for. Read system design content, architecture patterns, technical blogs — not to copy solutions, but to acquire the vocabulary that makes precise questions possible. The more you know, the better your questions get.

Be suspicious of outputs you can't evaluate. If the AI gives you something and you have no idea whether it's right, that's a signal. Don't just ship it. Either learn enough to evaluate it, or acknowledge you're building on ground you don't understand. Confidence in AI output you can't verify is one of the fastest ways to erode your own growth.

So No, AI Isn't Replacing Developers

This is also why the "AI will replace developers" narrative keeps missing the point.

AI is extraordinarily good at answering well-formed questions. It can generate code, write tests, explain concepts, and scaffold systems at a speed no human can match. But it can't decide what question to ask. It can't know what your users actually need. It can't hold accountability for a system in production. It can't walk into a room with a customer and read which diagram will land.

Those things require judgment built from experience. And judgment is exactly what separates the senior from the junior — not syntax, not even knowledge, but the accumulated ability to know what matters in a given situation.

AI raises the floor. It doesn't change what the ceiling is made of.

We should absolutely embrace AI to work more efficiently — there's no argument against that. A developer who refuses to use it is just making their job harder for no reason. But embracing a tool and being dependent on it are different things. At the end of the day, AI is still just a tool. A hammer in the hands of someone who understands construction builds something real. In the hands of someone who doesn't, it just makes a mess faster.

Which brings everything back to the same conclusion it always has: the fundamentals still matter. Not despite AI, but because of it. The developers who build strong foundations — system thinking, design principles, communication, domain knowledge — are the ones who will use AI most effectively. Better developers use it better. That's the whole story.

The tool changed. The path didn't.

The best AI users aren't the ones who know the most clever prompts. They're the ones who know the most about the domain — and use AI to go faster inside that knowledge, not to substitute for it.

That was true of Google too.