🔥 The AI Engineer Is a Job Now
I have not been that active in searching job boards. Mostly I see what crosses my LinkedIn feed, or I hear from friends about referrals. But even with that passive level of attention, I have noticed a shift.
In December 2025, the listings I came across were almost entirely “Software Engineer” roles. Some mentioned AI tools in the nice-to-haves. Maybe you were expected to use Cursor or Copilot inside your IDE. But the job was still fundamentally the same job it had been for the past twenty years: write code, review code, ship code.
In the past week or so, something changed. I am seeing postings specifically for “AI Engineer” — and not in the machine learning sense, not “train a model” or “fine-tune an LLM.” Applied AI engineer. The job description is: use AI agents to build software, fast, at scale.
I am in the interview loop for a couple of these right now.
What Shifted
I have written about the late 2025 inflection point before. A lot of factors had been building — models getting smarter, inference getting cheaper, context windows getting longer. But the thing that actually broke the dam was tool use.
An AI agent is just an LLM that can use tools. That sounds simple, but it changed everything. Tool calls are actions: browse the web, read a file, write a file, run a terminal command, make an API request, commit to git. Before tool use worked reliably, you had a chatbot. After, you had a coworker.
The other half of the shift was the rise of CLI agents — tools like Claude Code, Codex, and Gemini CLI that run directly on your local file system. They do not live in a browser tab or an IDE sidebar. They have access to your entire project directory, your terminal, your git history. They can read every file in your codebase to figure out what to do next, then actually do it — edit files, run tests, fix errors, commit. Given a well-scoped task, something that resembles a Jira ticket an engineer would pick up, these agents can now execute it end to end.
These changes are recent. Like, measured-in-months recent. And until the past few days I had not seen many companies actually hiring around them.
The Role
The postings I am seeing describe a person who is expected to:
- Run multiple AI agents in parallel to achieve goals concurrently
- Iterate at speeds that would be impossible if you were writing every line yourself
- Know how to scope, specify, and delegate tasks to agents effectively
- Have deep hands-on experience with the current generation of CLI tools
That last bullet is the interesting one. This is not a skill set you pick up from a weekend tutorial. You build it by spending hundreds of hours actually working with these tools — learning their failure modes, developing intuition for what kind of prompts produce good results, understanding when to intervene and when to let the agent run.
And here is the uncomfortable part: the people who have that experience right now are disproportionately people who have been unemployed.
I have been in that situation. Away from traditional employment since mid-2025, spending something like eight to twelve hours a day working with Claude Code, Codex, Gemini. Not just using them — actively experimenting, pushing into edges, trying to find what they can and cannot do. Building a core banking system in COBOL to see if agents can handle regulated domain logic. Building 3D renderers in Metal to see if they can handle low-level GPU code. Writing entire iOS apps by voice to see how far the feedback loop stretches. So far I have been very impressed. I have the Claude Code Max plan and my philosophy has been simple: the more tokens I burn, the better things get. I have pushed tens of billions of tokens through these systems across dozens of projects. At some point you start developing intuitions that you cannot get any other way.
What the Intuition Looks Like
One thing I have learned: on any single prompt, there is no guarantee the agent comes back with something correct and comprehensive. It might hallucinate a function that does not exist. It might misunderstand your intent in a subtle way. It might write code that passes the obvious tests but breaks on an edge case.
But zoom out. Over hundreds of prompts, thousands of commits, the output converges on your intent — if your intent is specified well enough. I saw this clearly when I built a core banking system in COBOL. The initial generation had bugs everywhere. But with good specs and 612 tests, 41 rounds of auditing drove the implementation to exactly where it needed to be. The short-term is noisy. The long-term is precise.
That convergence is not automatic, though. It depends on the engineer.
The Bottleneck Is Specification
The agent is smart enough to handle almost anything. The bottleneck is our ability to tell it exactly what we want.
This is a different skill than writing code. When you write code, you translate intent into syntax. When you work with an agent, you translate intent into language — natural language, precise enough that another intelligence can act on it without ambiguity. The agent has no tribal knowledge. It has no context about your project beyond what it can read from the files on disk. If your task description would confuse a new engineer on their first day, it will confuse the agent too.
The people who are good at this tend to be good at writing clear specs, scoping work into discrete tasks, and — this one surprised me — having the right vocabulary.
Vocabulary as Leverage
I keep coming back to this. Domain vocabulary is not decorative. It is functional.
When you are working in a niche area — banking regulations, audio signal processing, iOS accessibility APIs — there are words that exist specifically because the people in that field needed more precision than everyday language provides. “Accrued interest” is not just a fancier way to say “interest.” It refers to a specific accounting concept with specific calculation rules. “Debounce” is not just “wait a bit.” It is a specific timing pattern with specific behavior at the edges.
When you use those words in a prompt, you are activating weights in the model that are tuned to that specific meaning. You are reaching into a deeper part of the model’s knowledge — the part that was trained on technical documentation, regulatory filings, API references, and domain-specific textbooks. The niche word draws out the niche knowledge.
This is not a coincidence. Niche communities develop specialized vocabulary because they need more precise language to describe the things they care about at the level of depth they operate at. And when we prompt AI agents, that same precision helps us get more pointed and accurate output.
So it might not be the most important thing anymore to know exactly how a particular sorting algorithm works internally — the way traditional CS curriculum would have you implement quicksort on a whiteboard. What matters more is knowing that the algorithm exists, knowing its name, knowing when it applies, and knowing the vocabulary around it. Just having that knowledge lets you say “use a topological sort here” and the agent produces a more comprehensive and correct implementation than most of us could write by hand.
The skill shifted from implementation to specification. From writing code to writing intent.
The Jobs Are Here
I wrote in The Software Printing Press Moment about Block cutting 40% of their workforce — one of the first big companies visibly affected by the agent revolution. That was the contraction side of the shift.
Now I am seeing the expansion side. New roles, with new titles, looking for a skill set that genuinely did not exist as a job category six months ago. Companies are figuring out that the person who can harness twenty concurrent Claude Code sessions, scope tasks like a staff engineer, and iterate through a hundred commits in an afternoon is a different kind of role than a traditional software engineer. Different enough to warrant its own job posting.
At that level of concurrency, you start needing — and building — your own tooling. I built File City, a 3D file system visualizer that lets me watch multiple AI agents working across a codebase simultaneously. I repurposed a PlayStation DualSense controller as a hardware interface for managing Claude Code sessions, which turned into ControllerKeys, a macOS app that maps any game controller to keyboard shortcuts. When the off-the-shelf tools do not scale to how you work, you make new ones. That is part of the job now too.
Whether “AI Engineer” becomes a durable job title or just gets absorbed back into “software engineer” over time, I do not know. But right now, today, in March 2026, it is a real thing on real job boards. And the people best positioned for it are the ones who have been living in the terminal with these tools for the past few months — not reading about them, not watching demos, but actually burning tokens and building things.
I find it a little ironic that being unemployed turned out to be the best training program for the job.
I have not been that active in searching job boards. Mostly I see what crosses my LinkedIn feed, or I hear from friends about referrals. But even with that passive level of attention, I have noticed a shift.
In December 2025, the listings I came across were almost entirely "Software Engineer" roles. Some mentioned AI tools in the nice-to-haves. Maybe you were expected to use Cursor or Copilot inside your IDE. But the job was still fundamentally the same job it had been for the past twenty years: write code, review code, ship code.
In the past week or so, something changed. I am seeing postings specifically for "AI Engineer" — and not in the machine learning sense, not "train a model" or "fine-tune an LLM." Applied AI engineer. The job description is: use AI agents to build software, fast, at scale.
I am in the interview loop for a couple of these right now.
## What Shifted
I have written about the late 2025 inflection point [before](/the-software-printing-press-moment.md). A lot of factors had been building — models getting smarter, inference getting cheaper, context windows getting longer. But the thing that actually broke the dam was tool use.
An AI agent is just an LLM that can use tools. That sounds simple, but it changed everything. Tool calls are actions: browse the web, read a file, write a file, run a terminal command, make an API request, commit to git. Before tool use worked reliably, you had a chatbot. After, you had a coworker.
The other half of the shift was the rise of CLI agents — tools like Claude Code, Codex, and Gemini CLI that run directly on your local file system. They do not live in a browser tab or an IDE sidebar. They have access to your entire project directory, your terminal, your git history. They can read every file in your codebase to figure out what to do next, then actually do it — edit files, run tests, fix errors, commit. Given a well-scoped task, something that resembles a Jira ticket an engineer would pick up, these agents can now execute it end to end.
These changes are recent. Like, measured-in-months recent. And until the past few days I had not seen many companies actually hiring around them.
## The Role
The postings I am seeing describe a person who is expected to:
- Run multiple AI agents in parallel to achieve goals concurrently
- Iterate at speeds that would be impossible if you were writing every line yourself
- Know how to scope, specify, and delegate tasks to agents effectively
- Have deep hands-on experience with the current generation of CLI tools
That last bullet is the interesting one. This is not a skill set you pick up from a weekend tutorial. You build it by spending hundreds of hours actually working with these tools — learning their failure modes, developing intuition for what kind of prompts produce good results, understanding when to intervene and when to let the agent run.
And here is the uncomfortable part: the people who have that experience right now are disproportionately people who have been unemployed.
I have been in that situation. Away from traditional employment since mid-2025, spending something like eight to twelve hours a day working with Claude Code, Codex, Gemini. Not just using them — actively experimenting, pushing into edges, trying to find what they can and cannot do. Building a core banking system in COBOL to see if agents can handle regulated domain logic. Building 3D renderers in Metal to see if they can handle low-level GPU code. Writing entire iOS apps by voice to see how far the feedback loop stretches. So far I have been very impressed. I have the Claude Code Max plan and my philosophy has been simple: the more tokens I burn, the better things get. I have pushed tens of billions of tokens through these systems across dozens of projects. At some point you start developing intuitions that you cannot get any other way.
## What the Intuition Looks Like
One thing I have learned: on any single prompt, there is no guarantee the agent comes back with something correct and comprehensive. It might hallucinate a function that does not exist. It might misunderstand your intent in a subtle way. It might write code that passes the obvious tests but breaks on an edge case.
But zoom out. Over hundreds of prompts, thousands of commits, the output converges on your intent — if your intent is specified well enough. I saw this clearly when I [built a core banking system in COBOL](/i-built-a-bank-in-cobol.md). The initial generation had bugs everywhere. But with good specs and 612 tests, 41 rounds of auditing drove the implementation to exactly where it needed to be. The short-term is noisy. The long-term is precise.
That convergence is not automatic, though. It depends on the engineer.
## The Bottleneck Is Specification
The agent is smart enough to handle almost anything. The bottleneck is our ability to tell it exactly what we want.
This is a different skill than writing code. When you write code, you translate intent into syntax. When you work with an agent, you translate intent into language — natural language, precise enough that another intelligence can act on it without ambiguity. The agent has no tribal knowledge. It has no context about your project beyond what it can read from the files on disk. If your task description would confuse a new engineer on their first day, it will confuse the agent too.
The people who are good at this tend to be good at writing clear specs, scoping work into discrete tasks, and — this one surprised me — having the right vocabulary.
## Vocabulary as Leverage
I keep coming back to this. Domain vocabulary is not decorative. It is functional.
When you are working in a niche area — banking regulations, audio signal processing, iOS accessibility APIs — there are words that exist specifically because the people in that field needed more precision than everyday language provides. "Accrued interest" is not just a fancier way to say "interest." It refers to a specific accounting concept with specific calculation rules. "Debounce" is not just "wait a bit." It is a specific timing pattern with specific behavior at the edges.
When you use those words in a prompt, you are activating weights in the model that are tuned to that specific meaning. You are reaching into a deeper part of the model's knowledge — the part that was trained on technical documentation, regulatory filings, API references, and domain-specific textbooks. The niche word draws out the niche knowledge.
This is not a coincidence. Niche communities develop specialized vocabulary because they need more precise language to describe the things they care about at the level of depth they operate at. And when we prompt AI agents, that same precision helps us get more pointed and accurate output.
So it might not be the most important thing anymore to know exactly how a particular sorting algorithm works internally — the way traditional CS curriculum would have you implement quicksort on a whiteboard. What matters more is knowing that the algorithm exists, knowing its name, knowing when it applies, and knowing the vocabulary around it. Just having that knowledge lets you say "use a topological sort here" and the agent produces a more comprehensive and correct implementation than most of us could write by hand.
The skill shifted from implementation to specification. From writing code to writing intent.
## The Jobs Are Here
I wrote in [The Software Printing Press Moment](/the-software-printing-press-moment.md) about Block cutting 40% of their workforce — one of the first big companies visibly affected by the agent revolution. That was the contraction side of the shift.
Now I am seeing the expansion side. New roles, with new titles, looking for a skill set that genuinely did not exist as a job category six months ago. Companies are figuring out that the person who can harness twenty concurrent Claude Code sessions, scope tasks like a staff engineer, and iterate through a hundred commits in an afternoon is a different kind of role than a traditional software engineer. Different enough to warrant its own job posting.
At that level of concurrency, you start needing — and building — your own tooling. I built [File City](/file-city.md), a 3D file system visualizer that lets me watch multiple AI agents working across a codebase simultaneously. I repurposed a PlayStation DualSense controller as a hardware interface for managing Claude Code sessions, which turned into [ControllerKeys](https://kevintang.xyz/apps/controller-keys/), a macOS app that maps any game controller to keyboard shortcuts. When the off-the-shelf tools do not scale to how you work, you make new ones. That is part of the job now too.
Whether "AI Engineer" becomes a durable job title or just gets absorbed back into "software engineer" over time, I do not know. But right now, today, in March 2026, it is a real thing on real job boards. And the people best positioned for it are the ones who have been living in the terminal with these tools for the past few months — not reading about them, not watching demos, but actually burning tokens and building things.
I find it a little ironic that being unemployed turned out to be the best training program for the job.