Why (Senior) Engineers Struggle to Build AI Agents — Philipp Schmid, Google DeepMind
Summary
Philipp Schmid, Developer Advocate at Google DeepMind working on agents and the Gemini API, delivers a focused 10-minute talk on why experienced software engineers — not junior developers — are often the ones who struggle most when transitioning to building AI agents. The central argument is that seniority creates a liability: years of accumulated implicit context about codebases and APIs leads engineers to design tools and systems that assume knowledge that an agent simply does not possess.
Schmid structures the talk around five concrete paradigm shifts that distinguish agent development from traditional software engineering.
**1. Text replaces structured state.** Traditional software maps state to booleans, flags, and well-defined data structures. Agents operate on semantic meaning. He illustrates this with a deep-research agent: rather than a binary approve/deny plan interaction, a user can provide nuanced, free-form instructions — 'focus on the US market, ignore California' — and the LLM can interpret and incorporate that context dynamically. User preferences like preferring Celsius in general but Fahrenheit for cooking cannot be cleanly reduced to enumerated flags; they require text and context as the primary state representation.
**2. Control must be handed over.** Engineers accustomed to deterministic workflows — such as classification-model-driven customer support flows — struggle to trust the LLM to navigate unexpected intents dynamically. Schmid uses the example of a customer threatening to cancel a subscription: a static workflow would follow predefined steps, but an agent could recognize opportunity to offer an alternative, dynamically shifting the outcome. Engineers must stop forcing models into rigid step-by-step workflows and instead define goals while ceding control over the exact execution path.
**3. Errors are inputs, not restart triggers.** In traditional HTTP services, a failed request is cheap to retry from scratch. With long-running agents — those taking 5 or 15 minutes — a mid-flow failure that triggers a full restart wastes substantial compute and loses accumulated context. Schmid draws a parallel to Go's error handling model, where errors and values are treated equally as function outputs. Agents must be designed to receive errors as normal inputs, provide them back to the model, and continue forward rather than restarting the entire process.
**4. Evals replace unit tests.** Traditional software testing assumes determinism: input A always produces output C. Agents are non-deterministic — the same prompt may produce different steps and results across runs. The correct question is not 'does this input always produce this output?' but 'how often does this agent succeed?' Schmid argues that flakiness is the enemy of production agents: a customer support agent that only works 1 in 10 times is not deployable. LLM-as-a-judge and human expert review are cited as appropriate evaluation mechanisms. Critically, what must be measured is the final outcome, not intermediate steps — an agent might take more steps for one user than another but still produce the right result.
**5. Build to delete.** Agent code is disposable. Engineers will rebuild the same agents multiple times as better models emerge. The 'bitter lesson' — that software built for today's model constraints becomes obsolete — means that agent architectures must be designed without over-investment in specific model behaviors. Additionally, APIs and tools must be designed as agent-ready from the ground up: self-documenting, with semantic interfaces and detailed docstrings. A `deleteItem` endpoint with an `id` parameter is self-explanatory to an engineer with years of context; to an agent seeing only the function schema and docstring, it is opaque.
Schmid closes by summarizing the five principles: trust but verify, stop fighting the model, preserve meaning (context over data structures), design for recovery, evaluate rather than assert, and build to delete. He notes that code examples are available on his blog for engineers who want to go deeper.
Key Takeaways
- •Senior engineers' accumulated implicit context becomes a liability — they design tools that assume knowledge agents don't have; all tools must be fully self-documenting with explicit docstrings.
- •Text is the new state: stop mapping all agent context to boolean flags and data structures; LLMs can and should operate on free-form semantic context.
- •Never treat a mid-flow agent error as a reason to restart from scratch — pass errors back to the model as normal inputs and design recovery paths that preserve accumulated context.
- •Replace unit tests (input A → output C) with evals that measure how often the agent succeeds across many runs, using LLM-as-a-judge or human experts for subjective outcomes.
- •Define goals for your agent, not step-by-step workflows — fighting the model into rigid execution paths undermines the LLM's core advantage.
- •Compute cost of long-running agents (5–15 minutes) makes full restarts on failure prohibitively expensive; design explicitly for fault tolerance and forward progress.
- •A customer support agent that only succeeds 1 in 10 runs is not production-ready — reliability thresholds must be defined and met before deployment.
- •Build agent code to be deleted and rebuilt; as better models emerge, code written around current model constraints becomes obsolete — avoid over-engineering.
- •Measure final outcomes, not intermediate steps — an agent taking more steps for one user than another is acceptable if both arrive at the correct result.
- •The development loop for agents is fundamentally iterative: define instructions → run → observe → adjust prompts/tools → repeat, not write spec → write code → ship.
Transcript
[music] >> Okay, cool. Awesome. Hi everyone. My name is Philip. I work at DeepMind everything related to agents on Gemini or Gemini API. So if you have some questions afterwards, some concerns, some bugs, some issue, please let me know. We're going to talk today 10 minutes about why engineers struggle to build agents and I see this every day internally at Google but also externally at Google and I brought five example on like what's really different to how we built traditional software a few yea...
Speakers
Topics
Related Sessions
