Documentation doesn't fail because designers are lazy. It fails because it always comes last – and that's a structural problem, not a discipline problem.
Uber's team has now tackled this with an AI agent. The result isn't a shiny AI showcase. It's the solution to exactly the problem that quietly causes damage in every project.
#Why specs always lag behind
A project runs. Components get built, iterated, refined. Somewhere along the way, someone should actually update the specs. But the launch is closer than the docs, the next sprint starts, and the specs wait.
This isn't individual failure. It's the natural consequence of how priorities get set in reality. Specs don't ship features. They're infrastructure – invisible as long as they work, painful when they're missing.
At Uber, this problem multiplies to a barely imaginable level: 7 different implementation stacks, density variants for each one, strict accessibility requirements. Every component needs a spec page that covers all of that. Manually means: A designer sits page by page in Figma documenting what others have already built.
Engineering builds on assumptions in the meantime. Not out of negligence, but because the current definitions simply aren't available.
#What Uber built – and why it works
uSpec connects an AI agent in Cursor with Figma via the Figma Console MCP. The agent crawls the actual component structure, pulls all relevant data, and generates finished spec pages directly in the Figma file. What used to take weeks now runs in minutes.
The crucial point: The entire system runs locally. No proprietary design data leaves the network. For a company like Uber, this isn't an optional comfort feature – it's a hard requirement.
What convinces me about this approach isn't the speed. Speed is the byproduct. The real win is that specs can now keep up with the actual state of components for the first time. No more lag between what was built and what's documented.
#The fundamental problem doesn't scale
Ian Guisard, who developed the system at Uber, describes it directly: He spent years manually creating specs and teaching others how to do it. The methodology was good. The process was repeatable. But it doesn't scale when complexity grows.
That's the core. Manual documentation isn't a bad approach – it's an approach that collapses under pressure. And pressure is the normal state in every project.
I know this from smaller projects. The complexity isn't comparable to Uber's 7 stacks and hundreds of components. But the pattern is identical: Specs get created when energy is high. They don't get updated when everyday life returns.
#The counterargument that doesn't hold
"It's different for us. We have clear processes."
Maybe. But I haven't seen a project where the specs at the end were as current as at the beginning. Not because the processes were bad, but because people under time pressure always prioritize visible work.
Automation doesn't solve this problem through discipline. It solves it through structure. The agent documents because it was built for that – not because it currently has time.
#What you can concretely take from this
You don't need Uber infrastructure to learn from this approach. A few principles can be directly transferred:
Documentation must be integrated into the build process, not come after. If specs are planned as a separate step after building, they won't get done. Or they'll lag behind. The trigger for documentation must be the same action as the trigger for the component itself.
Manual processes need boundaries. If you document manually, define from the start what gets documented and what doesn't. A complete spec for ten components beats a half-finished spec for thirty.
Local and secure isn't a nice-to-have. Once design data leaves the network, control is gone. For freelancers this might sound abstract – for agencies with NDA obligations it's relevant.
AI tools are most useful where work is repetitive and error-prone. Writing specs is exactly that. There's no creative decision in filling out a density table. That's precisely where automation makes sense.
#What really changes
Writing specs is craft work. Nobody shows it in their portfolio. It doesn't get likes on LinkedIn. But when it's missing, engineers build on assumptions – and assumptions cost time, money, and consistency.
A system that takes over this part gives designers capacity for the work that actually needs decisions. Not because specs are unimportant, but because they're too important to always be postponed.
Uber didn't solve the problem by making designers more disciplined. They solved it by designing the process so it works without human willpower.
That's the approach that lasts.
