A colleague said something to me recently that I keep coming back to:

“Often, by the time you’ve finished articulating a complex problem for the AI, you’ve already solved it yourself.”

It sounds almost like a joke. You open a chat window, start typing out your problem in careful detail — and somewhere in the middle of the second paragraph, the answer appears. Not from the AI. From you.

If you’ve worked with LLMs seriously, you’ve probably experienced this. And I think it points to something important about what is actually changing in our craft — something that goes beyond the usual conversation about automation and job displacement.

The Rubber Duck, Promoted

Developers have known for decades that explaining a problem out loud helps solve it. The classic technique involves a rubber duck: you place it on your desk, narrate your code to it, and the act of articulation forces you to confront the assumptions you’d quietly made. The duck never responds. That’s not the point.

The LLM is a rubber duck that occasionally says something useful back.

But even when it doesn’t — even when the response is generic or slightly off — the discipline of formulating the prompt has already done its work. You’ve had to be precise. You’ve had to strip away ambiguity. You’ve had to decide what actually matters.

That process is not a workaround. It is thinking.

The Inversion of the Workflow

In the pre-AI era, the typical development workflow looked something like this: you had a rough mental model of the solution, you started coding, and you discovered the edge cases along the way. The code was exploratory. The thinking happened during the writing.

With AI assistance, that workflow inverts. Vague inputs produce vague outputs — the model has no way to compensate for an underspecified problem. So precision becomes mandatory upfront. You have to think before you type, not while you type.

This is a more demanding cognitive posture. It requires holding the full shape of a problem in your head before committing to an approach. For experienced developers, this often feels natural — it’s close to what they were already doing mentally. For less experienced developers, it can feel like a new kind of friction.

That friction is not a bug. It’s the learning.

Validation Over Construction

There’s a second shift worth naming: the center of gravity in engineering work is moving from construction to validation.

When I can generate a working implementation in minutes, the scarce resource is no longer the implementation — it’s the judgment to know whether the implementation is right. Right for the requirements. Right for the system it lives in. Right for the team that will maintain it in eighteen months.

This kind of validation requires something the AI doesn’t have: context. Not just the context of this ticket, or this sprint, but the accumulated context of this codebase, this team, this organization’s history of decisions. The AI can tell you whether the code compiles and whether it handles the happy path. It cannot tell you whether this is the kind of abstraction your team will still understand in two years.

That judgment — the ability to look at something technically correct and say “this is wrong for us” — is increasingly the most valuable thing a senior engineer brings to the table.

The Cognitive Offloading Trap

Here’s the risk I want to name directly: if we use AI purely as a cognitive offloading tool — a way to avoid thinking rather than a mirror to think against — we gradually erode the very capability that makes us useful.

It’s subtle. Each individual decision to let the AI handle something feels reasonable. The cumulative effect is that we stop exercising the muscles that generate real insight. We become reviewers of outputs we no longer fully understand. We lose the thread.

The antidote isn’t to use AI less. It’s to use it differently — as an interlocutor rather than an oracle. Ask it to challenge your assumptions. Ask it what you might be missing. Ask it to steelman the approach you’re not taking. These prompts don’t just produce better outputs; they produce better thinking.

What the Next Generation Will Actually Need

The skills that defined excellent engineers ten years ago — typing speed, syntax recall, pattern library depth — are depreciating. The skills that are appreciating are older and harder to teach:

Structured thinking. The ability to decompose a complex problem into parts that are independently understandable and collectively complete.

Precise communication. Not just writing clear code, but articulating requirements, constraints, and assumptions in ways that leave no ambiguity — for the AI, yes, but more importantly for your team.

Critical evaluation. The habit of asking why does this work? rather than accepting that it does. Of stress-testing a solution against its own assumptions before shipping it.

None of these are new. What’s new is that they are now the primary differentiator. The floor has risen for everyone. The ceiling belongs to the people who can think clearly about hard problems — and who have built the discipline to do so even when a faster, easier path is one prompt away.

Have You Already Solved It?

Next time you sit down to write a prompt for a difficult problem, pay attention to what happens as you write. Notice when the act of articulation clarifies something you didn’t know you were confused about. Notice when the constraint of explaining your reasoning exposes a gap in it.

The AI may or may not give you a useful answer. But you will have thought more clearly than you would have otherwise. And in the long run, that compound interest in thinking quality is worth more than any individual answer the model produces.

This post is part of an ongoing series exploring the intersection of engineering practice and the changing landscape of AI tooling.