Execution used to be the hardest part.
Writing code. Building components. Translating product strategy into design intent into something that ships. It’s where time went, budget, and where the frustration lived. We organized entire teams and workflows around the bottleneck of making things.
But the bottleneck is dissolving. AI tools can generate a login form in thirty seconds. They can scaffold a page layout, draft a component from a simple text description. The raw act of production is being commoditized. If we’re only measuring speed from prompt to output, we’ve never been faster!
Speed…is not the same thing as progress.
I’ve talked about this before. If you use AI to build product right now, we know the story. The tool generates something very quickly. You spend time fixing it. Wrong components, bad spacing, didn’t use the right patterns, made incorrect assumptions about how your product works. You might throw it away and write it yourself.
The generation was really fast. The correction then ate up all those savings.
This isn’t AI’s fault. The models are getting remarkably capable.
It’s a failure of context. The AI simply doesn’t know what “right” looks like for your team, or for your company. What’s your product context? What standards should it apply?
Nobody told the AI the answers. At least, not in a way that’s structured, coherent, and persistent so it can use it every time it generates something.
Our enormous investments are making execution cheaper. And not enough people are investing in making sure that cheap execution is pointed in the right direction.
There’s already a name for this
Infrastructure engineers have already solved for this problem. In a system like Kubernetes, there’s a clean split between:
The data plane (the thing that does the work, moves traffic, runs containers)
The control plane (the configuration, policies, and health checks that govern execution)
Hell, we can even apply this to actual airplanes. Air traffic control is an intuitive version of this. ATC isn’t flying any planes. It’s telling the pilots where to go, what to avoid, how to land safely. The planes are carrying the passengers. ATC has the rules and system-wide awareness. An airport needs both to run successfully.
AI tools are a powerful data plane. They carry out execution very effectively. But organizations are running them without a control plane. Without any kind of structured, persistent, layer of context. Something that tells the AI how this team is supposed to build this product.
Our generation requests start from near-zero. Output is technically functional but organizationally wrong. The 70-90% first-generation rejection rate isn’t necessarily a model quality problem.
It’s missing infrastructure.
What a control plane actually does
What would a control plane for digital product delivery look like?
1. Gather what’s true about what you build
Design tokens, component APIs, coding standards, accessibility rules, brand guidelines. Institutional knowledge that probably lies scattered across repos, Figma files, a Confluence page, embedded in tribal knowledge across teams. A control plane assembles those into a single layer that an AI tool can query.
2. Know which sources to trust
Your docs say that button should use an 8px padding. The shipped code uses 12px padding. Which one is right? Maybe the code, because documentation drifted and the implementation is a better reflection of reality. A control plane can apply ranking. Which sources are authoritative. Which might be more aspirational. Which are fall-backs.
3. Measuring if the output is any good
Not “did the AI generate something?” But “did the generation meet your standards?”
How many regeneration cycles did this take? What was the token cost? Does it pass linting?
Without measurement, AI-assisted development is governance by intuition. If you have measurement, you can actually govern and improve.
4. Connect to the tools your team already uses
A control plane isn’t a new tool to adopt.
It feeds context into the tools you already have. Claude, Cursor, Gemini, whatever comes next. Protocols like MCP make this control layer tool-agnostic. You keep your context layer - your control. Your execution layer becomes interchangeable.
Bigger than your components
If you’re a design systems person, maybe you hear “control plane” and think my component library is AI food. That’s true, but just a part of it.
A real control plane touches everything that shapes how a product ships. API contracts. Content strategy. Performance budgets. Security policy. Compliance and regulatory requirements. Localization. Roadmap constraints.
It’s the institutional memory of “how we do things here” that no document captures, and no new hire absorbs until at least a few months in the job. But here, we codify it for AI.
The difference really matters. Narrow integrations answer “how many components do we have?” A control plane answers “how does the organization deliver product?” Different questions, and the second one is where there’s real leverage.
Infrastructure solutions for infrastructure problems
Most organizations already possess most of the raw materials they need. Those coded components, documented standards, guidances, and repos that are full of already shipped product.
The gap isn’t source material. It’s a gap in aggregation, ranking, and feedback loops that can turn all of this scattered knowledge into usable intelligence.
Execution is going to keep getting cheaper. That’s a trajectory I don’t see reversing.
The organizations that invest in coordination infrastructure - including the kinds of systems we build at Knapsack - are the ones who’ll actually ship.
The concept isn’t unique to us. But every team using AI to build product is facing the same challenge - whether they’ve named it yet or not.
The machines work. They need to know what to build.
Further reading
Walker, J. Kubernetes Control Plane: What It Is & How It Works. Spacelift.io Blog, Jan 2025.
AI-Assisted Coding Reaches 29% of New US Software Code. Digital Information World, Jan 2026.
Article photo by CHUTTERSNAP on Unsplash.