The book · Ritesh Vajariya
An AI-native engineer is not the person who uses AI most. It is the person who compounds judgment through AI.
The distinction is not tool fluency, and it is not volume of use. It is knowing, before the handoff, which parts of the work carry judgment that lives only in you, and refusing to price those parts at the commodity rate.
The distinction this rests on
AI-assisted is using the tools to do your existing work faster. It is real, it is worth having, and it is where most working engineers currently are. Nothing on this site argues against it.
AI-native is narrower. It is a position on where judgment lives and what you do about it. The AI-assisted engineer moves faster this quarter. The AI-native engineer is accumulating something that makes them harder to replace next year, and the thing they are accumulating is a written record of their own reasoning, sitting where the work happens.
That is the whole mechanism. One rule you own, with the reason written above it, your name and the date on it. Then again next week, until the record is worth more than the output.
The characteristic failure of this decade is not bad generated code.
Why the difference is hard to see from inside
The characteristic failure of this decade is not bad generated code. It is excellent generated code that is wrong in a way that required someone's specific history to catch, shipped by a competent engineer who had every reason to trust it.
The vocabulary does not protect you either. It is entirely possible to say "that part is commodity" to talk yourself out of the one review that needed you, and to sound disciplined while you do it.
So this is not a maturity model you graduate from. It is a set of calls you make repeatedly, under time pressure, with incomplete information, and get wrong sometimes.
The frameworks
Ten of them, one per situation rather than one per tool. How to sort work that got cheap from work that did not. How to find the line where a handoff stops being safe. How to decide how much of a task to hand to an agent. How to make judgment legible when the repo is confidential. How to ask someone for a decision and hear whether they made it.
- 01The Honest LookWhen a field shifts, the announcement layer tells you nothing you can act on: demos, launch posts, someone else's promotion.Ch. 1 · The Ground Moves
- 02The Three Kinds of WorkWork no longer divides in two.Ch. 2 · What's Getting Cheaper
- 03The Handoff LineSome work has become safe to hand off, to a tool or a pattern or a person new to your domain, and some has not, and the line between them moves without announcing itself.Ch. 3 · The Gap
- 04What Cannot Be DelegatedNot all valuable knowledge becomes more abstract as tools improve.Ch. 4 · What Cannot Be Delegated
- 05Asking for the DecisionJudgment cannot be assessed by asking someone about a system.Ch. 5 · Context Is the Edge
- 06AI-Assisted vs AI-NativeAI-assisted is using the tools to do your existing work faster.Ch. 6 · The Confident Version
- 07The Three SeatsThe shift does not price every career stage the same way.Ch. 7 · Where You Stand
- 08The Delegation LadderDelegating work to an AI system is not one decision about whether to trust it.Ch. 8 · The Room Nobody Booked
- 09The Portfolio of DecisionsJudgment is invisible until it is made legible, and the evidence is decisions rather than output.Ch. 9 · What They Can See
- 10The Three Traps and the Decision EntryThere are three ways to lose this decade.Ch. 10 · Compounds From Here
- Not sure where to start?Take the diagnostic →Nine questions, no email required. The result names the frameworks worth starting with.
- Put one to workThe ten practices →One small exercise per framework, all in one place.
Where you sit
Nine questions, no email required, and the result names the two or three frameworks worth starting with.
Example result
13of 27
In the transition
The book
These frameworks come from The AI-Native Engineer, a novel about an engineer working this out in production, at payment scale, with the usual amount of career at stake.
Who writes this
Ritesh Vajariya
Founder and CEO of AI Guru; before that Cerebras, AWS and Bloomberg. The frameworks are patterns from interviewing engineers at volume, not research findings.
- 25+years in engineering and engineering leadership
- 1,000+engineering interviews run
- 4,000+readers of The Forward View
Questions
What is an AI-native engineer?
An AI-native engineer is not the person who uses AI most. It is the person who compounds judgment through AI.
How is AI-native different from AI-assisted?
AI-assisted is using the tools to do your existing work faster. It is real and worth having. AI-native is narrower and harder: knowing, before the handoff, which parts of the work carry judgment that lives only in you, and refusing to price those parts at the commodity rate.
What actually goes wrong?
The characteristic failure of this decade is not bad generated code. It is excellent generated code that is wrong in a way that required someone's specific history to catch, shipped by a competent engineer who had every reason to trust it.
What is “the record”?
That is the whole mechanism. One rule you own, with the reason written above it, your name and the date on it. Then again next week, until the record is worth more than the output.
Is this a maturity model?
So this is not a maturity model you graduate from. It is a set of calls you make repeatedly, under time pressure, with incomplete information, and get wrong sometimes.
Where should I start?
Nine questions, no email required, and the result names the two or three frameworks worth starting with.
Take the diagnostic