# How to become an AI-native software engineer without getting slower
A randomised trial found experienced developers were 19% slower with AI while believing they were 20% faster. This is what closes that gap, and the workflow that makes the speed real.
- Author: Radwan Altaf (https://radwanaltaf.com)
- Published: 2026-08-27
- Topics: AI transformation, Engineering
- Canonical URL: https://radwanaltaf.com/writing/how-to-become-an-ai-native-software-engineer
- Disclosure: Every figure in this piece comes from a named public study, linked where it appears. The workflow is my own, from projects I have built. I have not included any client detail.
---
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](https://arxiv.org/abs/2507.09089) 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](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/).

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](https://survey.stackoverflow.co/2025/ai),
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](https://cloud.google.com/blog/products/ai-machine-learning/announcing-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.