How to become an AI-native software engineer without getting slower

In this article I will explain what an AI-native software engineer actually is, why experienced developers who adopt AI often get slower without noticing, and the one habit that separates the two. I will use figures from named studies rather than the productivity multipliers that get passed around on LinkedIn.

To begin with, the problem.

In July 2025, METR ran a randomised controlled trial on sixteen experienced open-source developers across 246 real tasks. These were not beginners doing toy exercises. The paper records that they worked in mature projects on which they had "an average of 5 years of prior experience". Before starting, they expected AI to speed them up by 24%. They finished 19% slower.

The part that should worry you is what happened afterwards. Having done the work and been measured, those same developers still estimated that AI had made them about 20% faster.

That is a forty point gap between what a room of experienced engineers felt and what the stopwatch recorded. Clearly, something is happening that the person doing the work cannot see from the inside.

Thus, the useful question is not "does AI make engineers faster". It is why skilled people can be slower and feel faster at the same time, and what you have to change so that the speed becomes real.

What an AI-native software engineer actually is

An AI-native software engineer is one who has restructured how he or she works so that the model does the generating and the engineer owns two things: the specification going in, and the verification coming out.

In simple words, an AI-assisted engineer asks a model for help with a task. An AI-native engineer builds a setup where the model can do the task and be checked automatically, without the engineer reading every line.

The distinction matters because it changes what you are optimising. Consider the difference in practice.

AI-assisted looks like this:

• You hit a problem, open a chat, describe it, paste the answer back.
• Context is whatever you remembered to paste.
• The check is you reading the diff and deciding it looks fine.
• Speed comes from typing less.

AI-native looks like this:

• The task is written down before the model starts, including what "done" means.
• Context is a file the agent reads every time, not something you retype.
• The check is a command that passes or fails, and it runs before you look.
• Speed comes from being able to trust output you did not read closely.

It is important to note that this is not a tools question. You can run Claude Code or Cursor all day and still be working the first way. The second way is an operating change, and it is mostly unglamorous plumbing.

Thus, if you want a one-line test for where you currently sit: when the model hands you two hundred lines, do you have a way to find out whether they are correct that is faster than reading them? If the answer is no, you are AI-assisted, and the METR result applies to you.

Why experienced engineers get slower

Three things are going on, and they compound.

Reading unfamiliar code is slower than writing familiar code

When you write code yourself, you build the model of it in your head as you go. By the time it compiles you already know how it works. When a model writes it, you get the code without the understanding, and you have to reconstruct the understanding afterwards by reading.

For a junior working in an unfamiliar codebase, that trade is a clear win, because they were going to have to read and learn anyway. For a senior working in a repository they know by heart, it is often a loss. They gave up the fast thing they are good at, which is writing, in exchange for the slow thing, which is reviewing somebody else's work.

Moreover, this is exactly the population METR measured, which is probably why the result surprised so many people who had only seen AI demonstrated on greenfield projects.

"Almost right" is the worst possible output

In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools, up from 76% the year before. In the same survey, more developers actively distrust the accuracy of AI output (46%) than trust it (33%). The single biggest frustration, cited by 66% of them, was AI solutions that are "almost right, but not quite". The second was the human verification and debugging that follows, at 45%.

That phrase is doing a lot of work. Code that is obviously wrong costs you nothing, because you throw it away in five seconds. Code that is obviously right costs you nothing either. Code that is 95% right is the expensive case, because it passes a skim, gets committed, and the remaining 5% surfaces later as a bug that nobody associates with the moment it was introduced.

Adoption going up while trust goes down is not a contradiction either. It is what it looks like when a tool is genuinely useful and genuinely unreliable at the same time, which is an awkward thing to build a workflow around and exactly why the workflow has to change.

Furthermore, the failure is silent. You do not feel the cost of the almost-right code on the day you accept it. You feel it three weeks later, which is why the perception gap in the METR study is so wide.

The work moved to reviewing, but nobody budgeted for reviewing

Writing was always the visible part of the job, so that is where the tools and the habits are. We have linters, type checkers, formatters, test runners and CI for the writing half. For the reviewing half, most teams have one thing: a human being looking at a diff and getting tired.

Generation just got roughly free. Review did not. Thus, review is now the bottleneck, and pointing more generation at a bottleneck makes it worse.

This shows up at the organisation level too. The 2025 DORA report found a positive relationship between AI adoption and delivery throughput, which is a reversal from the year before. In the same breath it reports that "AI adoption does continue to have a negative relationship with software delivery stability". Its explanation is worth quoting directly: without strong automated testing, mature version control and fast feedback loops, "an increase in change volume leads to instability".

DORA's own framing is that AI does not fix a team, it amplifies what is already there. Thus, a disciplined team gets faster and a messy team gets messier, and the same tool does both.

The shift: make checking cheaper than generating

Here is the whole idea in one sentence. An AI-native engineer is someone who has made verification cheaper than generation.

Every practice worth adopting follows from that. If checking output costs you less than producing it yourself, you can accept work you did not read, and the speed is real. If checking costs more, you are paying a review tax on every token, and you get the METR result.

This reframes the skill you are building. It is not prompting. Prompting is a weekend's worth of learning and the models get better at forgiving bad prompts every release. The durable skill is designing the loop the model works inside: what it reads before it starts, what it is allowed to touch, and what has to go green before you look at it.

In a nutshell, you are moving from writing software to specifying and proving software. Thus, the engineers who are compounding right now are the ones who were already good at architecture, testing and clear thinking, because those are precisely the three inputs this loop runs on.

The workflow, concretely

This is the loop I actually run. I will use this site as the worked example, because you can see the result of it, and because it is small enough to describe honestly.

1. Write the context file first, before any code.

There is a CLAUDE.md at the root of the repository. It is the first thing any agent reads. It contains the stack, the commands that must pass, the things that are decided and not up for re-litigation, and the mistakes that have already been made once. It is not documentation for humans. It is the briefing you would give a competent contractor who has never seen the project.

The reason this matters more than prompting is that a prompt is a one-off and a context file is compounding. Every time I catch a wrong assumption, I add a line, and it never comes back.

2. Specify the task in writing, including what "done" means.

Not "add a contact form". Instead: the fields, the validation rules, where the submission goes, what happens when the provider is not configured, and which command proves it works. If you cannot write down what done means, the model cannot hit it, and neither could a human contractor. That is not an AI problem, it is a specification problem that AI has made visible.

3. Let the agent work in a scoped area.

Give it the files it needs and not the whole repository. A narrower blast radius means a cheaper review and fewer accidental edits in code you were not thinking about.

4. Run the gates before you read anything.

On this project that is four commands: tsc --noEmit, eslint ., vitest run, and a custom content validation script. The last one is the interesting one. It walks every published page and fails the build if it finds placeholder tokens, claims that were never approved, or an article marked published that was never reviewed. It is wired into the deploy command, so a broken claim cannot reach production even if I am not paying attention.

That script took an afternoon to write. It has caught things every week since. That ratio is the whole argument for this way of working.

5. Review the diff, not the process.

Once the gates are green, you are reviewing decisions rather than syntax. Did it put this in the right layer? Is this the abstraction we want to live with? Those are questions your judgement is worth something on. Whether the semicolons are right is not.

6. When something is wrong, measure before you fix.

This is the step people skip, and it is where AI-generated code punishes you hardest. An example from this very site: hover animations on every card had gone stiff. The obvious guess is a timing value, and the obvious fix is to change a duration and see if it feels better.

Instead I measured it in a real browser, reading the computed styles during the transition. The output was this:

transition-property: opacity, transform · transform: none at +30ms · transform: none at +730ms

The scroll-reveal system had been written as a CSS transition, and its selector was more specific than the card's. Thus, it silently replaced the card's transition list, so the border and shadow had no transition at all and snapped. Worse, a transform: none rule for revealed elements out-specified the hover rule, so the lift never fired at all. Nothing was broken enough to fail a test. The types were fine. The build was fine. It just quietly did not work.

No amount of prompting finds that. A measurement finds it in one run. That is what "verification cheaper than generation" means in practice.

What to actually learn

If you want a list to work through, in the order I would do it.

1. Specification writing. Practise turning a vague request into a written task with an explicit definition of done. This is the highest-leverage skill on the list and it is not an AI skill at all, which is why it will still be valuable in five years.
2. Testing, properly. Not coverage percentages. The ability to write a test that fails for the right reason before you write the fix. If you can express correctness as a command, you can delegate the code that satisfies it.
3. Context engineering. Deciding what the model sees. What goes in the persistent context file, what goes in the task, what is retrieved on demand, and what should never be in context at all. Most bad output is a context problem wearing a prompting costume.
4. Reading a diff quickly and sceptically. Specifically, learning where models fail: plausible-looking API calls that do not exist, error handling that swallows the error, and code that is correct in isolation and wrong in the system it was dropped into.
5. Systems thinking and architecture. The seams. What the units are, what the contract between them is, what "done" means for each one. Get this right and the model can fill in the units. Get it wrong and no amount of generated code saves you.
6. Observability. Given the DORA instability finding, being able to see what your system is doing in production is no longer optional. If you are going to ship faster, you need to find out faster when you have shipped something bad.

Notice how little of that list is about AI. That is the point. AI-native is mostly a set of old engineering virtues that used to be optional and are now load-bearing.

Anti-patterns I keep seeing

Measuring lines of code or pull requests merged. Both go up immediately and neither tells you anything. DORA's instability finding is what happens when a team optimises the number that is easy to move.

Accepting output because it is plausible. Plausible is exactly what a language model is optimised to produce. Plausibility is not evidence. If you cannot state how you know something works, you do not know it works.

Letting the agent touch everything. Wide permissions produce wide diffs, and wide diffs do not get reviewed properly. They get skimmed, which is how almost-right code gets in.

Retyping context every session. If you are explaining your conventions again, that explanation belongs in a file.

Using AI on the part of the job you understand least. This is backwards but very tempting. The output you are least equipped to check is the output you should be most careful accepting. Use it hardest where your judgement is strongest.

What this does not solve

I would rather be straight about the limits than sell you a method.

This approach does not help much on genuinely novel problems, where the hard part is deciding what should exist rather than producing it. If you do not know what correct looks like, no verification loop can tell you when you have got there.

It does not fix a codebase with no tests. If you cannot express correctness as a command today, the first months are spent building that ability, and during those months you will probably be slower, not faster. That is a real cost and the honest answer to "when will I see the benefit" is not immediately.

It does not remove the need to know how to build software. Everything above assumes you can tell good architecture from bad, because the loop is only as good as the specification you put into it. I do not think this method makes a junior into a senior. If anything it widens the gap, which is a genuine problem for the profession and I do not have a good answer to it.

Lastly, I have not run a controlled experiment on my own workflow. I am describing what has worked on my projects, supported by public research on the underlying problem. Somebody could measure this properly and find that parts of it do not hold. If you do, I would like to see it.

Frequently asked questions

What is an AI-native software engineer? An engineer who has restructured how he or she works so that AI does the generating while the engineer owns the specification going in and the verification coming out. The defining feature is an automated way to check output that is cheaper than reading it line by line.

What is the difference between AI-assisted and AI-native? AI-assisted means using a model to help with tasks you would otherwise do by hand, and checking the result by reading it. AI-native means designing the loop the model works inside, so that correctness is proven by a command rather than by inspection.

Does AI actually make developers faster? It depends on the setup, and the honest answer is that it is not automatic. A 2025 METR randomised trial measured experienced developers as 19% slower with AI in repositories they knew well, while those developers believed they were 20% faster. At organisation level, the 2025 DORA report found a positive relationship between AI adoption and throughput, and a negative one with delivery stability.

Do I still need to learn to code? Yes, and arguably more of it than before. The work has moved from producing code to judging it, and you cannot judge what you do not understand. The parts that matter most now are architecture, testing and reading code critically.

What should I learn first? Specification writing. The ability to state what "done" means before work starts is what everything else depends on, and it is useful whether or not a model is involved.

Is prompt engineering the main skill? No. Models keep getting better at tolerating imprecise prompts, so that skill depreciates every release. Context engineering and verification do not depreciate, because they are about your system rather than about the model.

Where to start on Monday

Pick the repository you work in most. Write one context file describing the stack, the commands that must pass, and the three mistakes you are tired of explaining. Then make one command that tells you whether the thing works, and run it before you read any generated code.

That is the whole change. Everything else is refinement.