What AI engineers do in the age of agentic code

Two years ago, AI engineers wrote code. A lot of them were still making traditional software. They got their jobs because they were good at writing code, and they got assigned projects that required them to turn ideas and requests into functional, deterministic code. The skill was rare, and it took a lot of time and energy to learn.

Today, AI engineers have mostly stopped writing code. Shopify claims they use AI to write more than half of its product code. Airbnb says they use AI for 60% of their code. Google says 75% of its code is AI-generated. Anthropic can do even better: 90%! These numbers are probably best analyzed with some skepticism, but the pattern is still easy to recognize. What used to be a long and expensive process became much faster and cheaper. Not rare at all.

With all this agentic help, AI engineers are now accountable for shipping more new product features than ever before. To complicate things, AI engineer tasks are far more probabilistic than the old software engineering ones. It’s not as simple as just building a model and watching it run the same way every time. They’re tuning inputs and outputs, but a lot of the actual operational work happens in a black box, so it needs to be checked.

In a very short timeframe, modern AI engineers began overseeing teams of agents that were creating enormous volumes of code faster than it could be read. Instead of building products, these AI engineers shifted to improving trust in something that an agent (or a team of them) built first. These employees are still some of the most valuable resources on a product team, but the rapid evolution of their day-to-day job description is forcing companies to rethink the way they operate.

Every AI engineer got an unrequested promotion

If you’re an engineer working with AI agents, you probably didn't apply for a new position. There was no announcement or job description. But the shape of your role is unmistakably different: you assign work, wait for it to be done, review the output, suggest improvements, and once it’s shipped, you are responsible for the quality. Congratulations! You're running a team.

Not everyone wants that. Some AI engineers love working deeply on one part of their product. They may have built it from beta or launched the idea at a hackathon. They own the infrastructure and their fingerprints are proudly on every iteration of that product. Some engineers are content as hyperfocused ICs and don’t have larger ambitions to be team leads.

Even for those who have always wanted to lead teams, the jump in responsibility came on fast. The final product works or it doesn't, regardless of who wrote the code. The accountability doesn’t move to the agent that made the first draft, it’s still squarely on the shoulders of the engineer who publishes the change. All that matters is the quality of the final output. If the agents did bad work, the engineer did bad work.

It’s an entirely new type of employee management. Your direct reports can be created at will, don’t show much capacity for coaching over time, have spotty memory about past projects, and are prone to handing in defective work with complete confidence. The performance review is nonstop and the only limit to your agents’ ability is your own skill ceiling. There’s unlimited potential but far heavier expectations.

This is what AI engineering jobs look like now.

Building is more efficient than ever, but no one has extra time

Everyone remembers the original theory of agents: automating code production would free engineers for higher-value (and more satisfying) work. That promise never came true. The speed of the agents accelerated production, but it also introduced the perpetual threat of opportunity cost. Every moment diverted is a new feature that goes unbuilt. That kind of potential is equally liberating and suffocating.

Imagine an engineer sends an agent to work on something. It needs time to run that task, so while that agent runs, the engineer starts another agent on another task. If the first agent still isn’t ready, there’s time to start a third … Instead of managing one project at a time, they’re constantly switching among 5-10. Each one is at a different stage, needs review for different qualities, and has a unique path to completion. This style of work has scrambled the AI engineer’s attention in a new dimension: instead of going deep on one project, they juggle more balls than ever, each with a different size and weight.

All the time saved from agentic efficiencies hasn’t been converted into new value from deeper focus. It got fractured and recycled into parallelism.

Faros AI found that engineers using AI tools touch 67.4% more PR contexts per day, but leave 26% more tasks sitting idle for a week or longer and restart projects 13% more often. Essentially, engineering work got significantly easier to start, but harder to finish.

Reviewing code is a different muscle than writing code

When AI engineers work with agentic code, it feels like a different job than writing code because it is a different job. It starts from a foundation of the same skills, but deploys them in a new way. When an engineer starts from scratch and writes code, they evaluate as they go. If there’s an error, they catch it immediately. If the approach is wrong, the engineer figures it out as they build and can correct it on the fly before the rest of the project goes down the wrong path.

The cost of those mistakes is minimized because they are fixed before they waste any more time and compute. Review happens invisibly because it’s baked into creation.

Now review is its own disparate step. No one starts anything from scratch. They start at v1. Sure, that v1 is influenced by the engineer’s initial request, but it’s still something net new that was created and handed off to them. The invisible review that used to happen during creation has been removed and added on at the end as an entirely new step. On average, this new workflow will probably still move faster, but it’s so different that it will take teams time to adjust.

What Amplitude's AI engineers do

How should AI engineers adapt their roles in the age of powerful agents? I’ll yada yada yada past the usual disclaimers (every team is different, there’s no one answer, etc.) and take a real shot at answering: AI engineers should turn a flood of unverified agentic code into a working product that the whole company and its customers trust.

It’s a hard job to define prescriptively. Maybe a better way to move the discussion forward is to describe exactly what daily work looks like for Amplitude’s AI engineers. These are some of the best AI minds at an AI-first company. Each of the four people below has the same title (AI Engineer), but none of them do the same work. They aren’t interchangeable. As they move further away from producing code firsthand, they’ve also spread out to differentiate into custom lanes. The throughline is that they found a way to fit their skills into a niche that Amplitude needs.

Ram Soma: the customer-facing product owner

Ram owns Amplitude’s Global Agent. It’s an AI chat box in our product that works like a plain-language data scientist. Our customers use it for a wide range of use cases, from creating a chart to conducting deep research, essentially automating analysis that a PhD-level statistician used to do by hand: gathering data, choosing the right statistical method, applying analytical rigor, and explaining the result to non-statistician colleagues.

Most of his time is committed to quantifying product quality. He (and his coding agents) reads traces, finds model failures, and works out root causes. As it relates to agentic management, Ram’s job is to build a product workflow that leverages AI's strengths while masking its weaknesses. Where AI fails, Ram has to step in himself or build a new AI solution to cover the gap.

Unlike most engineers, Ram partners closely with a product manager to co-own Global Agent’s eval set. They're the two people who read the most model output, so it’s logical that they work together to define what good looks like. Since they read the traces, they write the specs. Ram does customer-facing work too, joining calls to hear where the product fails directly from the person it failed.

Because of the type of product that he owns, Ram can dogfood relentlessly, using Global Agent to ask itself about customer usage trends, whether people are churning, and why.

Lew Gordon: the PR review machine

Lew maintains the data infrastructure that powers Statsig: ingestion, transformations that find out how many users were exposed to an experiment, jobs that calculate experiment results, and analyzing session replay data. Almost none of that work is customer-facing. It’s a broad job description that requires handling a constant barrage of one-off tasks. Rather than pairing up with a PM, he collaborates across the team through Slack and pull requests from other engineers.

In an environment that makes PR generation easy, Lew prioritizes reviewing them. Rather than add to the infinite stack, Lew realizes he can create the most value by closing out PRs instead of creating them. He’s applied his engineering skills to the team’s own workflow, realizing that human attention is the new scarce resource and allocating his own attention to solve the most problems.

Lew’s so-called “janitorial” engineering work is also part archaeological. Amplitude’s Statsig team inherited a set of alerts nobody understands, so he uses agents to decode what they mean and interpret what to do about them. His agent abilities have earned him the top spot on Amplitude’s AI leaderboard.

TJ Torres: the investigative problem finder/solver

TJ operates as an internal applied researcher at Amplitude. He looks for high-leverage problems across the whole company, builds a solution prototype, moves it to alpha, and hands it off to a team as they come online to own it.

Instead of starting projects with an AI agent, TJ uses personal inputs from teammates to understand how the team is working and find new problems to solve. Once he has an idea, TJ’s engineering skills go to work. He pulls data from Slack, email, meeting notes—anywhere problems are described. Then he builds a corpus of data and has agents synthesize the common findings.

The agents give him the breadth to canvass the entire company and find broken things. He uses his human validation on top of that analysis to zero in on the right next target. He triangulates what to build next by finding the overlap between his human conversations and the agent analysis.

Vinay Goel: The agent upleveler

Vinay leads Agent Analytics at Amplitude. He founded the product as an internal tool to measure the impact of Global Agent, and has navigated its growth from an internal analysis tool to a customer-facing product. He’s building a data-backed mechanism to eliminate agentic AI slop.

Vinay has an extensive systems engineering and data platforms background which turns out to be the right mix for this job. He doesn't tune models. His craft is turning data into better performance: orchestration, evals, governed schemas/taxonomy, cost tracking, and building harnesses configurable enough to swap one model dependency for another without rewriting everything around it.

Operating as a high-velocity orchestrator, he rarely writes code by hand, yet remains one of the company's most prolific PR creators. That’s only possible because of how he works. His workflow centers on deep spec-driven planning, using agents first as adversarial sounding boards to critique architecture, then dispatching and guiding parallel agentic builds from plan to merge.

AI engineering still boils down to problem-solving

Everyone’s job looks different with agents. AI engineers have been disrupted as much as any role, and the way teams react to that disruption will decide how successful they are at building products in the new age.

As they get further from code, these jobs will look more and more different. The reality is that they’re translating the their energy in new ways. Instead of turning a request into a working product, AI engineers are training their skills on the building process itself.

These jobs aren’t easy to define with a specific title or fit into the boxes of a neatly defined role. It’s a high-potential, high-pressure role that requires perpetual reinvention. The most valuable skill is still problem-solving. The best engineers will find a place where company trust is thinnest and build new things that apply their abilities as broadly as possible.