An AI-first SDK for an energy company

Context

An energy company ran its station operations through one monolithic control application. Every new screen meant working inside it, so delivery was slow, and every new engineer had to infer what a component expected by reading its source.

The company is now moving from that one application to a platform of many applications built on a shared SDK. Models were becoming part of how the team wrote code, and a model asked to build a screen against the monolith had the same problem as a new hire, only worse: it guesses confidently.

The brief I took on had two halves. Make the UI layer something engineers and their agents can build against from real contracts. And give operators an AI assistant that helps run the station without ever acting on it alone.

Constraints

• ›Safety: this is an industrial control system, so a wrong action has physical consequences. The model may only propose commands; every command needs two human approvals, operator and admin, before it executes.
• ›Legacy: the monolith keeps running station operations throughout the migration, so the SDK has to be extracted from it, not built beside it.
• ›Team: a frontend team of 4–6, with me leading it and still writing production code.
• ›Agents: anything an agent builds against has to be machine-readable. If the contract only lives in source code, the model starts guessing.

Architecture

Components live in a UI kit, and each one carries a strict prop contract plus machine-readable metadata describing what it accepts. Agents reach that metadata two ways: CLI tooling built for LLM agents, which is where an agent assembles an application against the SDK, and an MCP server that exposes the same component metadata to any MCP-capable client. Documentation and agent skills ship with the SDK, so a model reads the docs the engineers read. On the operations side, the backend, the model and the agent harness existed as separate pieces; I wrote the interface layer that joins them, which the operator chat and the SDK tooling both stand on. Screens are composed at build time, never generated live in the product.

export interface ReadingCardProps {
  /** Human label, shown above the value. */
  label: string;
  /** Latest reading. null renders the stale state, never 0. */
  value: number | null;
  unit: 'bar' | 'MW' | '°C' | '%';
  thresholds?: { warn: number; alarm: number };
  onAcknowledge?: (alarmId: string) => void;
}

{
  "component": "ReadingCard",
  "package": "@sdk/ui-kit",
  "summary": "One live reading with its unit, thresholds and stale state.",
  "props": {
    "label":         { "type": "string", "required": true },
    "value":         { "type": "number | null", "required": true,
                       "note": "null = stale; never substitute 0" },
    "unit":          { "type": "enum", "values": ["bar", "MW", "°C", "%"], "required": true },
    "thresholds":    { "type": "{ warn: number; alarm: number }", "required": false },
    "onAcknowledge": { "type": "(alarmId: string) => void", "required": false }
  },
  "rules": ["Data comes from a typed hook; the component never fetches."]
}

→ { "jsonrpc": "2.0", "id": 7, "method": "tools/call",
    "params": { "name": "get_component",
                "arguments": { "name": "ReadingCard" } } }

← { "jsonrpc": "2.0", "id": 7,
    "result": { "content": [{ "type": "text",
      "text": "{ \"component\": \"ReadingCard\", \"props\": { … } }" }] } }

Key decisions

Outcome

• ◆Test coverage from 0 to 92%, the bar I set for the team.
• ◆CI from 10–12 minutes to under a minute after migrating the framework to TypeScript 7.
• ◆400+ tech-debt issues identified and resolved.
• ◆In daily use across the engineering org.
• ◆The team also uses the AI code-review GitHub App I built, which has its own case study.

What I'd do differently

• ›Cut the scope earlier. We built separate frontend and backend showcases, and support for several frontend frameworks when only one is in use. That was breadth hedging against a product intent nobody had pinned down, and all of it had to be built, tested and documented.
• ›Force the product-intent conversation before writing code instead of absorbing the ambiguity as extra surface area. The build order I would keep: the CLI first, then the thin MCP server.