Are You an AI Dumper?

There's a pattern we've started noticing in code reviews. A pull request lands. It's clean, well-structured, passes CI. The developer who submitted it can walk you through what it does. But when you ask why it handles the empty-input case this way, or why this particular retry interval, or what happens if the upstream service is down for longer than the timeout — the answers get vague.

Not because the developer is weak. Because they didn't write it. They prompted it, reviewed it for thirty seconds, and shipped it. The code is someone else's reasoning, and the developer has adopted it without fully inheriting the understanding.

This is what we've started calling the Dumper pattern. And it is, by a significant margin, the most common pattern we see in engineering teams right now.

The three groups

When we look at how engineers are actually working with AI tools today, three patterns emerge.

The first group — the Avoiders — are still writing most of their code manually. They use AI occasionally, for boilerplate or documentation, but fundamentally the development model hasn't changed. This group is shrinking fast. The productivity gap between them and AI-assisted engineers is now too large to ignore.

The second group — the Dumpers — use AI heavily but treat the output as finished work. They prompt, they get code, they check that it compiles and the tests pass, they ship. The review is surface-level. The understanding is borrowed. This is the majority.

The third group — the Steerers — use AI as a tool they direct rather than a source they consume. They specify carefully before they prompt. They read the output critically, looking for behavioural correctness, not just syntactic coherence. They can explain the agent's architectural choices because they defined the constraints that shaped those choices.

Most engineers who read this will recognise themselves in group two. That's not a judgement — it's where the workflow naturally leads when you optimise for speed without building the habits that keep the quality of judgement high.

What the Dumper pattern looks like in practice

It's worth being specific, because the Dumper pattern is invisible from the outside. The commits look fine. The velocity is high. The PRs are green.

The signs are behavioural:

You prompt before you specify. The first thing you do with a new task is open the chat window, not write down what done looks like. The specification emerges from the interaction rather than preceding it.

Your review standard is "does it look right." You're checking structure, naming, format — the things AI gets right almost every time. You're not systematically checking for the failure mode that only shows up under a specific input, or the race condition that only matters at 10× load, or the silent error that drops data without raising an exception.

You can explain what the code does, but not why it was structured this way. If someone asks you to defend an architectural decision in the code you submitted, you go back to the code rather than drawing on a mental model you built while writing it.

"The tests pass" is your primary quality signal. Tests check the cases you thought of. They don't check the cases the agent didn't anticipate and you didn't notice it hadn't anticipated.

None of these are obvious failures. The code works. The feature ships. The problem surfaces later — in the production incident, the three-weeks-later bug, the review where someone asks a question you can't answer.

Why this is the wrong pattern to be in right now

If AI tools were going to do more over time, and the engineer's role were going to shrink, then optimising for output volume would be the right move.

But that's not what's happening. The engineer's role is getting harder in a specific way: the implementation is getting easier and the judgement is getting harder.

Anyone can generate code. The skill that separates engineers now is the ability to evaluate what was generated — to find the wrong answer in the plausible-looking output, to catch the assumption that won't hold in production, to know when the thing that came back is subtly not the thing you asked for.

That skill is exactly what the Dumper pattern doesn't develop. You don't build judgement by accepting output. You build it by interrogating output, which means having a standard against which to interrogate it, which means specifying what you wanted before you see what you got.

We mapped this out against the full skill set for the AI era — you can see where these skills land on the Interview Skill Map and compare it against where they used to sit before AI changed the weighting. The skills that dropped in traditional importance (syntax, algorithms from memory, framework knowledge) are exactly the ones the Dumper pattern still exercises. The skills that rose (specification quality, output evaluation, failure-mode reasoning) are exactly the ones it doesn't.

A five-question self-check

These aren't trick questions. They're things you should be able to answer about any code you shipped this week.

1. Before you started, did you write down what "done" looks like? Not a ticket description someone else wrote. A behavioural specification: what inputs, what outputs, what happens in the error cases, what performance assumption is baked in. If you started by prompting, you skipped this.

2. Can you name the failure mode in the last feature you shipped? Not "it might have bugs." The specific scenario where it behaves incorrectly: the input that breaks it, the load condition that causes it to degrade, the dependency failure that produces a silent wrong answer instead of an exception.

3. Did you read the last PR you approved for behavioural correctness, or for style? Style is naming, formatting, structure. Behavioural correctness is: does this produce the right output for all valid inputs, and the right error for all invalid ones? These are different reviews. Most people do the first.

4. If someone asked you to explain the retry logic in the last feature you shipped, would you need to re-read the code? A developer who wrote that code manually would have the answer immediately. A developer who prompted it and accepted it may not. There's no shame in re-reading — but noticing that you need to is the signal.

5. What tool did you most recently evaluate and decide not to adopt? This one is about early adoption, which turns out to be a stronger career signal than it looks. Genuine early adopters have a list of things they tried and rejected as well as things they adopted. If you can only name things you use, not things you considered and passed on, the adoption pattern is reactive rather than deliberate.

If questions 1, 2, and 3 are uncomfortable, you're in the Dumper pattern. That's the starting point, not a verdict.

What to do with this

The hiring series started from the interviewer's perspective — what interviewers are now testing for, and why the old interview process stopped working. If you want to understand how you'd be evaluated by a team that's thought carefully about this, that's a useful read from the other side.

The next article in this series is about something more specific: what you're quietly losing, in measurable terms, the longer you stay in the Dumper pattern. The research is uncomfortable.