Web Directions Year round learning for product, design and engineering professionals

Building SDKs in the Agentic Era

The landscape of software development has fundamentally shifted. Once, an SDK was a relatively stable interface: you documented it, developers learned it, and for years it remained largely unchanged. But in the age of frontier AI models and coding agents, that stability evaporates. An LLM trained on your current SDK documentation might suggest patterns that made sense in 2024 but are now anti-patterns in 2026. By the time a model has been trained, the open source libraries it was trained on have already moved on.

This creates a peculiar kind of technical debt—not in your own code, but in the gap between what AI systems know and what the world has actually become. For teams shipping both cutting-edge models and developer-facing SDKs, this isn't a theoretical problem. It's a daily operational challenge.

The Knowledge Gap Problem

Consider the developer experience loop: a data scientist wants to integrate a new model. They query their favourite LLM for example code. The model confidently suggests an API pattern based on what it learned. But the SDK changed three months ago. The pattern still works, but it's inefficient. Or worse, it doesn't work at all because a deprecated parameter was removed. The developer is frustrated. The SDK team looks negligent. Nobody is happy.

This gap exists because LLM training happens on a schedule measured in months, while API evolution happens on a schedule measured in weeks. The frontier models are powerful, but they're knowledge-frozen at training time. The open source ecosystem is fluid and responsive—which is wonderful until an AI agent needs to navigate it.

Experiments in the Real World

The team at Google DeepMind has been running experiments to understand this problem empirically. How large is the gap, really? Which kinds of changes are most likely to trip up AI agents? When an LLM makes a suggestion, how often does it match current best practices? What can SDK maintainers actually do to keep their libraries legible to future AI systems?

The answers are surprising in some ways and confirming in others. It turns out that breaking changes matter, but so does documentation. A well-structured changelog that explains not just what changed, but why, helps models reason about the shift. Examples that show before-and-after patterns give agents something to ground on. Consistency in naming conventions and structure makes it easier for models to generalize.

Building for Machines and Humans

This framing shifts how SDK design should work. You're not just designing for the humans who will read your documentation. You're designing for the LLMs that will be asked to generate code using your library—both current models and future ones that don't exist yet. That doesn't mean writing for machines at the expense of clarity for humans. It means being more deliberate about structure, more explicit about versioning, more thoughtful about deprecation paths.

It means treating your changelog as API documentation. It means thinking carefully about consistency across similar functions—if one follows a pattern, users (human and artificial) expect others to follow it too. It means recognizing that your SDK isn't just an interface to your service; it's training data for the AI systems developers will use.

The implications ripple across the ecosystem. As more developers delegate code-writing to AI agents, the SDKs that win will be the ones that are easiest for those agents to work with. This isn't about dumbing down the API or removing power. It's about being intentional about how that power is exposed and documented.

Mark McDonald, who co-wrote the Guinness World Record holding Kaggle Generative AI course and now works with DeepMind research teams to bridge cutting-edge technology and developer experience, is exploring these questions directly. His work across Gemini API, PaLM API, TensorFlow, and Google Maps gives him a unique vantage point on what it takes to ship SDKs that work well in this new era.

He'll be discussing these challenges and sharing results from experiments on the training cutoff knowledge gap at AI Engineer Melbourne 2026, June 3-4.