Technical documentation has a structural problem. It's written by humans at a moment in time, but code is a living system. Every deploy, every refactor, every API change creates a gap between what the documentation says and what the system does. At Google's scale — millions of lines of code, thousands of engineers — that gap is not a nuisance. It's a major source of engineering friction, onboarding failure, and production incidents.

LemonADE was a suite of AI agents designed to eliminate that gap by automating the creation, maintenance, and discovery of technical documentation across the full software development lifecycle.

The System

The project deployed 15+ specialized agents, each responsible for a specific documentation task at a specific point in the SDLC:

• Inception & Planning — agents that generated project briefs, design docs, and API contracts from code and requirements
• Development — inline documentation agents, code comment generators, and change log writers operating inside the Cider IDE
• Testing — agents that maintained test documentation and coverage reports in sync with the test suite
• Release & Deployment — release note generators, migration guides, and deprecation notices triggered by deployment events
• Monitoring & Maintenance — agents that detected documentation drift, flagged stale content, and proposed updates when the underlying code changed

I owned the horizontal UX strategy across all agents — the interaction model that unified them into a coherent experience rather than 15 separate tools.

The Real Design Problem

The automation was solvable. The engineering team could generate documentation. The harder question was: how do you design the interaction between a developer and an AI agent when the developer has fundamentally different preferences about how much control they want?

Some developers want to review every line the agent produces before it lands in the codebase. Others want the agent to operate autonomously and only surface work for approval at the end. Most are somewhere in between, and their preference varies by task — they might want full control over API documentation but be happy to fully delegate comment generation.

The interaction model I designed: a call-and-response framework that adapted to individual developer preferences — from step-by-step co-creation to full artifact review, with every point on the spectrum explicitly supported.

The Interaction Model

The model had two poles and a continuous spectrum between them:

• Co-creation mode — the agent surfaces a proposal at each step, waits for developer input, and incorporates feedback before proceeding. High control, high engagement, appropriate for high-stakes documentation.
• Artifact review mode — the agent works autonomously and surfaces the complete output for a single review-and-approve interaction. Low friction, appropriate for routine maintenance tasks.

Between these, the framework supported any combination: agents could be set to interrupt at specific decision points, surface confidence scores that triggered manual review when below a threshold, or operate in background and batch their outputs for periodic review.

The key design principle: the developer should never be surprised by what the agent did. Every autonomous action should be legible in retrospect, and every agent decision point should be explicit rather than hidden.

The IDE Integration

The primary surface was Google's Cider IDE — the internal development environment used by the majority of Google engineers. LemonADE agents surfaced inside Cider via the Cider Agent framework, alongside Google Coder and Jetski.

I designed the agent interaction patterns for the IDE context specifically — where the developer is heads-down in code, interruptions are costly, and the visual real estate for agent communication is extremely limited. The same call-and-response framework had to work in a sidebar panel without disrupting the primary coding workflow.

Platform Adoption

I designed and personally shipped the internal LemonADE documentation site. The prompt and tool architecture I developed was subsequently incorporated into multiple Google AI support libraries — a signal of platform-level adoption that typically indicates a design pattern has proven durable enough to generalize.

Why This Was the Bridge to Act 3

LemonADE was where I moved from designing systems that help humans understand AI, to designing systems that are themselves autonomous agents operating in production environments. That's a categorical shift — not just in technical complexity, but in the design responsibility.

When an AI agent generates documentation that gets committed to a codebase used by thousands of engineers, the designer is responsible for whether the output is trustworthy, legible, and correctable. The same question I've been asking since a Boeing flight deck in 2009 — when the system fails, can the human take back control? — becomes acutely relevant when the system is operating without human intervention in a production engineering environment.