Why Senior Engineers Struggle Most With AI Agents

Here's the thing nobody expects: the engineers who struggle most with AI agents aren't the junior devs still learning system design. It's the senior engineers. The ones with the most context. The ones who built the APIs.

Philipp Schmid — who works on Gemini agent infrastructure at Google DeepMind and gave this talk at the AI Engineer conference — frames it as a context problem. "An agent doesn't see the code," he says. "An agent doesn't have the context and the background from all those years from you working on the API." That deleteItem endpoint you designed five years ago? Crystal clear to you, completely opaque to an LLM that only sees a function name and a docstring (if you even wrote one). The more invisible your expertise, the worse your agent tooling will be. Seniority, in this context, is a liability.

That's the provocation. It's worth taking seriously.

A quick note on attribution: The video description identifies Schmid as being at Google DeepMind, and his LinkedIn confirms this. His social links are here if you want to verify or reach him directly. The talk was published to the AI Engineer YouTube channel.

Five shifts. One through line.

Schmid's talk is structured around five concrete ways agent development diverges from traditional software. They're not five random tips — they all point at the same root problem: the mental models that made you good at software engineering are exactly the ones that will sabotage you here.

1. Text is your new state. Traditional software maps everything to data structures — booleans, enums, flags. A user preference for temperature units becomes a field in a database: { "units": "celsius" }. Clean, queryable, deterministic. Schmid's argument is that this whole paradigm breaks when you're working with agents, because language carries semantic meaning that structured data can't hold. "I mostly use Celsius, but I want Fahrenheit for cooking" — you cannot model that with a flag. You need context. This sounds obvious until you realize how deeply the instinct to structure runs in experienced engineers. The reflex is to reach for schemas. Schmid is saying: stop.

2. Hand over control (seriously). This one bites experienced engineers in a specific way. Years of building deterministic systems creates a strong pull toward prescribing exact execution paths. Schmid's metaphor: traditional software makes you a traffic controller — you set the lights, define the roads. Agents make you a dispatcher. You say "get from Berlin to London," and you let the agent figure out whether that's a flight, a train, or the Chunnel. "We define the goal on what we want the agent to do, but we don't define the exact step the agent needs to take to achieve that goal." Fighting this — trying to force step-by-step workflows onto non-deterministic systems — is one of the most common failure modes he sees.

3. Errors are inputs, not exceptions. This is the one with the most immediate production stakes. In traditional software, a failed HTTP request is cheap: throw an exception, restart, retry. No big deal. But if your agent has been running for 15 minutes, chaining tool calls, building up context — and then something fails and you restart from scratch? You just torched a lot of compute and lost the accumulated state. Schmid points to Go's error-handling philosophy here (errors as values to be passed forward, not exceptions that halt execution — a well-established pattern in Go that he applies to agent architecture) as the right mental model: treat errors as just another input the model can reason about. Route around failures. Keep going.

4. Evals replace unit tests. This is the shift that I think is most disorienting for developers trained on deterministic testing culture. Unit tests assume: input A → function B → always output C. Agents don't work like that. Same prompt, same agent, different run — you might get different steps, different outputs, both potentially "correct." Schmid's point is that the right question isn't "does this always produce X?" It's "how often does this produce something good enough?" That means statistical evaluation — running your agent across many inputs, using LLM-as-a-judge or human raters, measuring pass rates rather than asserting exact outputs. "Agents are only successful if they are really reliable. If you have a customer agent and the same prompt only works one out of 10 times, it's nothing really you want to put in production." This is a real infrastructure lift, and it's one reason proper testing frameworks matter so much before you ship anything agent-based.

5. Build to delete. Schmid closes with what he calls "the bitter lesson" — and here it's worth being precise about what that phrase carries. Richard Sutton's 2019 essay "The Bitter Lesson" argued that general methods leveraging computation at scale consistently beat approaches encoding human knowledge. Schmid appears to be invoking that framing to make a related but distinct point: the code you write for today's model will probably be suboptimal for tomorrow's, and the best thing you can do is design for replacement rather than longevity. "Software is disposable. We are going to rebuild many, many times the same things with better models, better agents." That's either the most liberating thing you've heard all week or a quiet nightmare, depending on how much of your identity is tied to shipping something that lasts.

The seniority trap, unpacked

There's something almost funny about the framing here if you grew up learning to code on YouTube and Discord. The five shifts Schmid describes — trust the model, write documentation for the machine not yourself, measure statistically, design for failure, expect to rebuild — these aren't instincts that a developer with six months of experience has to unlearn. They don't have deeply grooved habits around PRD-to-deploy pipelines or deterministic test suites or carefully-maintained API contracts. The clean-slate thing is actually clean.

The 20-year veteran's problem isn't lack of skill. It's accumulated intuition that keeps firing in the wrong context. The traffic controller reflex — define the roads, set the lights, control the path — is exactly what made them effective for two decades. It's a real cost to suspend it.

This is the same tension IBM's Grant Miller surfaced from a different angle — arguing for specialized, constrained agents rather than general-purpose autonomous systems. The underlying worry is identical: open-ended agent autonomy makes experienced engineers deeply uncomfortable, for reasons that aren't irrational. And the failure modes when things go wrong can be spectacular. (The database wipe scenario is not hypothetical — it's happened.) The supervision question doesn't go away just because you've internalized the new mental models.

What Schmid is offering is a framework for building reliably inside that uncertainty — not for eliminating it. Design for recovery. Evaluate statistically. Document for the agent, not for yourself. Trust the model's goal-seeking, but trace everything it does. These aren't promises that agents will always behave. They're principles for building systems that degrade gracefully when agents don't.

The interesting open question isn't whether these shifts are correct — Schmid's logic holds up. It's whether "build to delete" can actually be a team-wide norm when most engineering organizations still measure people on the durability of what they ship. If the incentive structure says "build something that lasts," and the technical reality says "build something you'll replace in six months," someone's going to feel that tension in a performance review. And it probably won't be the senior engineer — it'll be whoever's newest to the team, trying to explain why they're already rewriting the agent they shipped last quarter.

That's not a contradiction in Schmid's argument. It's the part he didn't have time to address in ten minutes.

By Yuki Okonkwo, AI & Machine Learning Correspondent, Buzzrag