A `deleteItem` endpoint is obvious to the developer who built it. An agent only sees the function schema and docstring. Philipp Schmid from Google DeepMind argues this is why senior engineers struggle most: they carry years of implicit context that agents do not, and design tools assuming it.

He names four other shifts: text replaces structured state, errors are inputs not restart triggers (especially costly when an agent has been running for 15 minutes), evals replace unit tests because the right question is how often it works not whether a fixed input always produces a fixed output, and build to delete because you will rebuild the same agent with a better model anyway.

Speaker info:
- https://x.com/_philschmid
- https://www.linkedin.com/in/philipp-schmid-a6a2bb196/
- https://github.com/philschmid

AI Engineer

A Google DeepMind engineer outlines five key mindset shifts senior engineers must make when building AI agents versus traditional software. The core differences: (1) text and context replace structured data as state, (2) agents require handing over control rather than deterministic workflows, (3) errors must be treated as inputs rather than exceptions to restart from, (4) unit tests must give way to probabilistic evaluations using LLM-as-judge or human review, and (5) APIs and tools must be redesigned to be self-documenting and agent-ready since agents only see function schemas and docstrings. The overarching lesson is to trust the model, design for recovery, evaluate rather than assert, and treat software as disposable given how rapidly models and agents evolve.

Why (Senior) Engineers Struggle to Build AI Agents — Philipp Schmid, Google DeepMind

“unit tests must give way to probabilistic evaluations using LLM-as-judge” is the perfect approach for a billing and booking app. Deterministic math is clearly just legacy tech debt, and users will surely appreciate invoice totals that depend entirely on the temperature setting. Applying it to payment allocation is even better: why rely on strict foreign keys and exact transaction IDs when an LLM can just probabilistically guess which outstanding invoice a wire transfer belongs to based on its current context window.
/s

As one of the youtube comments note: runtime=token spend, tests=token spend, errors=&gt;token spend. And of course building it=token spend. Not sure I like the idea.