Every mentee I have talked to this year has asked some version of the same question: what is an AI first engineer, and am I behind? The phrase is on job descriptions now. It is in performance reviews. Nobody defines it, so everyone assumes it means the person who prompts fastest.
It does not. After a year of shipping GPT and Claude powered features at HackerRank and watching how the work actually changed, here is the definition I have landed on:
An AI first engineer delegates execution by default, and owns intent and verification personally.
That is it. The generation part is not the skill. The deciding part is.
An AI assisted engineer reaches for a model when stuck. An AI first engineer starts from the assumption that a machine will write the implementation, and asks a different opening question: what would I have to specify for that output to be correct, and how would I know if it was not?
Notice what that question requires. You cannot specify what you cannot describe. You cannot verify what you do not understand. The model removed the typing, and in doing so it moved the entire job upstream into judgment and downstream into proof.
This is also why the role is not what most people think it is.
Two things get confused with this constantly, and the confusion is costing people interviews.
An AI engineer builds AI systems. Retrieval pipelines, evals, fine tuning, inference cost, model routing. That is a specialization with its own stack.
An AI first engineer builds ordinary software, using AI as the primary means of production. You could be doing billing, or a design system, or internal tooling. The domain is unchanged. The workflow is not.
And prompt engineering is a tactic inside that workflow, not the workflow itself. Prompt phrasing stopped being the differentiator once models got good at inferring intent. What separates people now is context and verification, which are engineering problems, not writing problems. 🙂
The honest version of this story is not the marketing version.
Adoption is effectively finished. Google's 2025 DORA State of AI assisted Software Development report found that 90% of technology professionals now use AI at work, and over 80% believe it has made them more productive. That is the part everyone quotes.
Here is the part that matters more. The same research found that 30% of developers report little to no trust in the code AI generates. And higher AI adoption correlated with increases in software delivery throughput and software delivery instability, at the same time. Faster and shakier, together.
DORA has a name for the mechanism, and it is the most useful phrase I picked up all year: the verification tax. Time saved during generation gets reallocated to verification overhead. The work did not disappear. It moved.
If you have felt busier while shipping more, you are not imagining it. You are paying the tax.
For my whole career the scarce resource was the ability to produce a correct implementation. That is no longer scarce. What is scarce now is the ability to decide, quickly and correctly, whether a change is safe to merge.
This inverts a lot of received wisdom. Review used to be the cheap step at the end of the expensive step. Now review is the expensive step, and generation is nearly free. Teams that did not restructure around that are drowning in pull requests that took four minutes to write and two days to trust.
The failure mode is specific and worth naming, because it is not what juniors expect. Agent output does not fail loudly. It fails plausibly. It will hand you an API integration that reads beautifully, passes your happy path test, and silently never requests page two. Nothing crashes. The bug ships. You find it in a support ticket six weeks later.
Bad code announces itself. Confidently wrong code does not. Developing a nose for the second kind is the actual craft now.
Concretely, from how my own loop changed:
1. Context before prompt.
Most bad output is an underspecified request, not a dumb model. Before delegating, I make sure the constraints that live in my head are written down somewhere the agent can see: the invariant that must hold, the pattern this codebase already uses, the thing we tried last quarter that failed. Repos that carry their own conventions in a file get dramatically better output than repos where that knowledge only exists in senior heads.
2. Small diffs, on purpose.
A 40 line change I can fully reason about beats a 400 line change I can only skim. The temptation is to let it run, because it can. Scope is the main lever I have on how carefully I can review, so I keep it short deliberately.
3. Tests as the specification, written first.
This is the practice that changed my output quality most. If I can express correctness as a test before generating, I get two things: a clearer instruction, and a check that does not depend on my attention holding. I no longer trust myself to catch a subtle logic error by reading at 4pm on a Thursday.
4. Read the edges, not the middle.
I skim the shape and then go straight to the boundaries: empty input, pagination, timezone, concurrency, failure of the thing it calls, the error path nobody exercises. That is where plausible code hides its wrongness.
5. Know when to close the laptop lid on it.
I do not delegate work I do not understand yet, in a part of the system I cannot afford to get wrong. Not because a model cannot do it, but because I would have no basis for judging the answer. Delegating the thing you most need to learn is how you stall your own growth.
The repricing has been sharper than I expected.
More valuable: reading unfamiliar code quickly, writing tests that pin real behavior, system design, debugging from symptom to cause, and taste. Taste is doing a lot of quiet work here. When three plausible implementations arrive in ten seconds, having an opinion about which one this codebase should live with is the differentiator.
Cheaper: memorized syntax, boilerplate throughput, knowing the exact argument order, and speed at the keyboard. These were real advantages for a long time. They are close to worthless as differentiators now, which is disorienting if you built your professional identity on them.
I want to be honest about who this hurts. The tasks that used to be how juniors got reps, the small well defined CRUD ticket, the test nobody wanted to write, are the tasks most completely absorbed. The ladder did not get harder at the top. It lost its bottom rungs. If you are early, your job is to deliberately acquire the judgment those rungs used to teach, without the luxury of being paid to acquire it slowly. Read more code than you generate. Do the hard debugging yourself.
You are less behind than the noise suggests. Adoption is universal; competence is not.
I wrote earlier this year that product thinking is the skill that survives the AI era, and I still believe that is the more important half. Knowing what to build was always the harder problem, and it got harder as building got cheap.
This is the other half. Knowing what to build decides whether the work matters. Knowing whether the output is correct decides whether it ships without hurting anyone. An AI first engineer in 2026 is someone who has taken personal ownership of both ends of that, and stopped treating the middle as their identity.
The typing was never the job. It just took up so much of the day that it was easy to mistake for the job. 🚀
If you are working through this and want the longer career arc behind it, I wrote about seven years as a software engineer, and I keep my reference notes on levelling and scope in career growth resources. Originally published on August 18, 2026 at souravdey.space.