Case study · AI product & developer tooling
An AI-first SDK for ~30 engineers
Migrating a monolithic industrial control application into a modular SDK that both engineers and LLM agents can build against.
Context
An energy company ran its station operations through a single monolithic control application. Every new screen meant working inside that monolith, and every engineer — and increasingly every model asked to help — had to infer what a component expected from reading its source.
The goal was not to add an AI feature. It was to change the substrate: make the UI layer something an LLM can compose against safely, from real contracts rather than guesses, while the same contracts make the codebase easier for humans.
Scale
Engineers using it
In daily use by ~30 engineers
Team I lead
A frontend team of 4–6 — and I still write code daily
Status
In production
What I decided and built
- ›Broke the monolithic control application into a modular SDK, with a UI kit whose components carry strict prop contracts rather than loose props.
- ›Published component metadata in machine-readable form, so a model can read what a component accepts instead of inferring it from source.
- ›Built an MCP server that exposes that metadata to any MCP client, making the contracts available to Claude, Cursor and Windsurf without bespoke integration per tool.
- ›Built the CLI first, aimed at LLM agents rather than only at humans, so a model had tools to work with the repo — and to build an app against the SDK — before anything else existed.
- ›Added the MCP server after it, as a thin layer over the same HTTP calls, so the contracts reach any MCP client without a second implementation.
- ›Wrote documentation and agent skills as first-class deliverables of the SDK — the model reads the same docs the engineers do.
Outcome
- ◆The LLM operates the station and generates UI on the fly from the UI kit, composing against real contracts instead of guessing.
- ◆In daily use by ~30 engineers.
What I'd do differently
- ›Cut the scope. We built separate frontend and backend showcases, and support for several frontend frameworks when only one is actually in use — breadth that was hedging against a product intent nobody had pinned down yet.
- ›I would force that conversation before writing code rather than absorbing the ambiguity as extra surface area. The build order I would keep: the CLI earns its place first, and the MCP server is thin enough to follow it.