They are always available, and always responsive. Their green dot on Slack never disappears. They give you thirty options when you only needed three. Their calendar is full, but they keep working after everyone else has stopped.

Are they good at their job?

Perhaps.

They might be exceptional. Their force of will might be the only thing keeping an organization together. Carrying impossible work that their manager doesn’t even understand, and their colleagues never see.

They might be completely overwhelmed. Inefficient. Anxious. They might be producing a stream of work that makes more work for all the rest of us.

And the midnight email doesn’t help us know which one.

We know that manager who mistakes dedication for performance.

They see the hours at your desk. They look at the messages you send, the meetings you attend. The tickets closed and the lines of code written. They count the documents you produce.

Did that message change an outcome? Was that outcome worth the effort?

Now we have AI. We’ve built the employee who sends emails at midnight.

We haven’t changed its manager.

It’s permanently available. It never gets tired. It responds immediately, every time. It can outmatch any human worker in its capacity to generate reports, plans, code, images, summaries, strategies - every document or artifact you could ever want.

If we’re measuring by presence, effort, and production then AI is the greatest employee who ever lived.

That’s probably not helpful.

The things a manager sees

When I was leading the Carbon Design System at IBM, I brought adoption targets to Phil Gilbert, the GM of IBM Design. He told me to stop focusing on adoption. It wasn’t the right measure of success.

Adoption was interesting. It wasn’t inherently valuable.

That conversation was years before we started asking the same question about a machine.

There are six different questions we can ask about work.

Presence: Was someone at their desk?

Effort: Did they put in the work?

Production: Did their work create outputs?

Performance: Were those outputs any good?

Outcome: Did they change anything?

Value: Was the change worth it?

Good management, good measurement, will look at all six but judge mostly through the final three.

Presence and effort matter. We like people who show up. And we usually want work to produce something.

Those things are necessary. But they don’t demonstrate success.

Performance is an assessment of the quality of the effort, not just the volume. Outcome lets us ask what changed in the world because the work was done. Value asks whether that change was worth the cost and risk.

Those are harder measures. At a minimum, they need someone to define what “good” means.

Bad management - maybe even average management - reverses that importance.

The employee who stays late looks more committed than the employee who finished the important work and left at 4pm. The person who sent you a fifty-page document looks more substantial than the one who sent you a two-line email that identified the decision that mattered. One team closes a hundred tickets, and looks productive. Another team prevents the creation of a hundred tickets, and looks quiet.

And it’s not just managerial foolishness. It’s not malice.

We understand bums in seats. We understand people working late. We understand the production of stuff. It’s all trackable. It all shows willing.

Value emerges more slowly. There are dependencies. More people are involved. Value might be stopping some work from ever happening. It needs an understanding of quality.

And we’re not great at that nuance. So organizations reward the visible. Employees learn to be visible.

If you’ve sent an email after 6pm when you could have sent it before 6pm, you know what I mean.

That’s about showing that you’re working. Not about showing that the work matters.

The proxies used to mean something

We valued presence, effort, and production because they’re connected with human limits.

You have to be there. You get tired. You spend your own time making stuff.

If you’re a person who made twenty substantial reports, beautifully presented as PDFs, you’ve done a bunch of work. That doesn’t mean the reports are good, but shows you’re invested.

Stuff that takes time, that takes effort, has scarcity.

Until AI came along.

AI can be there every hour of the day. Its effort doesn’t come with fatigue. It can make a lengthy report while you’re making your coffee.

Human limits secured that proxy.

Now? Delivery is decoupled from investment.

AI isn’t padding its hours to optimize a number. It genuinely is always available, always responsive. It’s making a lot of stuff. Nothing is being faked. The activity is real, and it’s honest.

But whether it’s valuable...that’s another question.

Here’s the kind of evidence we’ve seen for AI success:

• The system generated ten thousand lines of code.

• The system answered five hundred questions.

• The system created forty campaign concepts.

• The system summarized every customer interview.

These might all be true.

• Was the code reliable, maintainable, or necessary?

• Were the answers useful? Correct? Did anyone act on them?

• Were the forty concepts any better than the three that the team developed without that tool?

• Were the summaries accurate? Did they reflect what was really important to users?

They aren’t, by themselves, value claims. They’re diagnostics.

Is the machine operating?

The industry has automated its weakest managerial instincts and called it “observability”.

Production is not productivity

Generative AI is seductive. It makes stuff.

Blank page to full page. Empty backlog to populated. Busy inbox to drafted replies.

It did something. And we, as humans, like something more than nothing.

And we’re still adjusting to the sense of movement.

Before we had generative AI, making that report was - at a minimum - demonstration of effort: research, organization, and writing. The size of the artifact was evidence that we’d worked hard.

AI completely breaks that relationship.

That long report might come from a one-line prompt. It might never provide value.

The artifact, when it had human cost, looked significant. AI strips that cost. But as humans we still respond to the length, fluency, and completeness. We want the work to be consequential.

The AI stayed late. Look at everything it made.

AI gives you execution speed, no question. The correction tax is an efficiency cost.

Who’s going to read the report? Which developer will be reviewing the code? Am I going to have to choose between the fifty options it gave me? I’ll need to check the citations. I’ll go through the error logs to find the gaps in a convincing answer.

That isn’t a productivity increase. It’s an increase in paperwork.

We don’t demo the cost part of AI, just the speed.

The work management avoided defining

I wrote recently about auditing the AI skills I had built for my own work and life. The audit showed me that measuring the machine was just the beginning.

We only know if the AI-generated product brief is good if we actually know what a good product brief is. To evaluate a coding agent, we need to decide if we care about delivery time and defects, or lines written.

We can’t rely on “I’ll know if it’s good if I see it.” That’s a managerial dodge.

And it’s not about one universal definition of quality.

We need stated definitions for success, quality, and value, in the context the work is delivered. And those definitions should be owned by somebody willing to defend them.

Organizations have left this vague for years. Effort is reassuring. Good managers - able to apply their contextual understanding - filled gaps with their own judgment on impact.

AI makes those gaps harder to ignore.

AI can generate more activity than we can inspect. Faster to production also means faster to shipping mistakes.

If production is unlimited, what does production tell us?

This is why evals matter.

It’s not about reducing every aspect of work to a score. Quantitative measurement doesn’t remove judgment.

Who receives the benefit, and who absorbs the cost? A serious eval makes those kinds of judgments explicit.

Evals shouldn’t just be tests for the AI systems.

They’re tests of whether management knows what it is asking the system to accomplish.

The performance review

AI looks amazing under the weakest measures of productivity.

It is always at its desk. It works with astonishing speed. It’s never tired. It produces more than anyone else.

Perhaps it is also doing excellent work. Perhaps it is changing outcomes that matter and creating value far beyond its cost.

But the first three things don’t prove the final three.

The midnight email never proved value.

Evals move the performance review beyond production.

It means defining what good looks like. Being able to sift through volume for value. Not simply admiring the output.

AI worked through the night. We already know that about AI.

We need to know whether the work matters.

Further reading:

• Design system adoption numbers...just a vanity metric? - the same argument, before AI: adoption is interesting, not valuable.

• I know kung fu. I might remember how to throw one punch. - the skills audit referenced above.

• Collins, S. We Hired AI to Work Less. Instead, Our Workload Jumped 346%. Here’s Why. Activated Thinker, Mar 2026.

• Schawbel, D. How AI turned your best work into the bare minimum. Fortune, Aug 2026.

Article photo by Bruno BD on Unsplash.

Should this person be allowed to generate that?

That’s identity management and role-based access controls. Audit logs. Data-retention policies. Spend limits (now that we’re realizing tokens aren’t free!). Permissions for tools and connectors. And controls over the models available, what information they can reach, and what gets recorded.

This is good. Sensible and secure.

It’s also only half the problem.

There’s another question that gets missed.

Is what gets generated acceptable?

We’re still talking about governance. But the first question was about access. The second is about conformance.

Enterprise AI stacks are much better at the first one than the second.

Anthropic has built in SSO, SCIM, role-based permissions, audit and compliance tools, data-retention controls, observability, spend management, and controls to configure how models connect to outside systems. Microsoft has a growing governance layer around Copilot. Okta is putting work into expanding identity governance so it captures agents as well as humans.

Enterprise companies know how to solve these problems.

I’ve worked at IBM and at J.P. Morgan. These are the types of companies who need to determine who someone is, what they can access, and what they did.

So it’s natural that they apply the same methods to generative AI.

Who invoked that model? Were they allowed to? What data and tools could it use? How much did it cost?

And these could all work perfectly.

The authorized employee signs into the approved AI product at their company. They have all the right permissions. The model is locked down - only the information they’re allowed to see. The interaction is logged, there are traces. Nothing leaks, no policy is breached.

The AI makes some kind of plausible artifact.

And it’s wrong.

Maybe not obviously. But wrong according to all of the organization’s own standards.

It violates accessibility. It ignores a code convention. It’s in conflict with an existing product decision. It invents a component that’s already in your design system.

Nobody catches this. It looks right, and it passed all the governance controls.

It ships.

The governance stack only solved access. It protected the company from misuse of AI.

Conformance governance would protect it from AI that makes the wrong thing.

We’re building the first one faster than the second.

Not my first governance rodeo

Before AI (and after), I’ve spent years working on design systems.

Design systems always had a governance problem - more than they had a component problem.

The component library is the simpler part. The hard questions come when hundreds or thousands of people start using it.

Introduce standards and training. Establish review procedures and processes.

And, if you’re not careful, you become the design systems police.

I wrote about that problem four years ago.

That central team discovers their job isn’t helping people make good decisions. It’s turned into catching people who make bad ones. It’s not governance, it’s enforcement. The system is a gate.

That wasn’t scalable when the people doing the work were all human.

AI’s made the same problem much larger.

A designer can create five credible options in the time it used to take them to make one. Now there are five times as many things that need checking.

Same on the engineering side. There’s much more code to review.

Did the ten pages of analysis that the product manager made this morning align with what the company knows?

The smaller the generation problem, the bigger the output problem.

And we’re only just starting to pay attention to that part of the productivity story.

We’re all striving for velocity. For me, that means a combination of speed and quality.

AI can reduce the cost of making an artifact from four hours to four minutes.

Then we have to spend thirty minutes reviewing that artifact. Another thirty to identify all the deviations. An hour of corrective work. Coordination with other people who also need to review.

The work’s moved, not disappeared.

AI without conformance means the generation cost is converted into correction cost.

And right now more of the correction remains human. So the faster generation makes things even worse.

I wrote earlier this year that execution is becoming cheap while coordination is not.

This is one of the consequences.

The bottleneck moves downstream.

System discovery isn’t the problem

In early evals work at Knapsack, we started to see a clear distinction.

A controlled evaluation. Test a coding agent doing design system tasks. A matched task set, no customer data. Give it two conditions. One where it has an MCP connection that provides guidance for that system. One where it doesn’t.

The MCP doesn’t help the agent find the system. It does that successfully, assuming it has access. It even imports the components at about the same rate.

The agent knows to look in node_modules.

But if it doesn’t have the MCP serving the context, it doesn’t know how to use that system.

Give it that context, and design fidelity improves 5-10%. Code quality improves by more than 20%.

Prompts that produced shippable code rose from 40% to over 60%.

TypeScript errors down significantly. Prop violations similarly reduced.

The cost of running any individual task was higher. But the cost per shippable output was thirty percent cheaper.

This agent didn’t have new access. It already had the components.

But now it had context about how the organization expected the components to be used. Props, variants, compositions, and the constraints around them.

The access problem was already solved. The conformance problem wasn’t.

Conformance improves the economics of usage. Even with our early, simple context provision the benefits are clear and measurable.

The organization’s intent becomes a participant in the generation.

Plausible mistakes compound

The more complex the task, the more the agents benefit from additional context.

On a multi-screen flow, attaching the MCP gave us gains that were nearly double what we saw on simple patterns.

This isn’t a neat scaling. We don’t have enough data. On some simpler template-based tasks, the additional context sees the agent second guess itself and reduces its reuse of the right components.

But high-complexity tasks, broadly, benefit the most.

As tasks get bigger, they involve more decisions. And multiple small plausible but wrong decisions start to compound into something globally wrong.

I always talked about it when it came to design systems. You can take a bunch of completely accessible components and assemble them into a really inaccessible experience.

A complete flow can violate how your company believes the experience should work.

Conformance is broader than compliance

“Conformance” isn’t just another word for regulatory compliance.

Conformance is a broader evaluation of whether an artifact satisfies the constraints your organization has already decided.

Yes, be compliant with accessibility. Dealing with private information. Legal restrictions your company needs.

But some of the constraints and context are just how the organization has chosen to operate.

Brand standards.

Design-system conventions.

Product strategy.

Architectural decisions.

Content guidelines.

Approved patterns.

These are things that teams throughout your company have learned painfully before. And they’d prefer not to learn them painfully again.

Any organization is full of these decisions.

But they’re scattered.

Design system sites. Wikis. Policy documents. An old presentation. Architecture records. Jira tickets. Multiple Slack threads. That developer’s memory. The shared knowledge of the people who were in the room when some decision was made.

AI isn’t magically better than humans at pulling all this context together when it’s time to execute.

Given incomplete organizational context, it’s probably worse. It’ll make more guesses, ask fewer questions, and generate something plausible from the context it does have.

Which is what we asked it to do.

And generic AI evaluation only gets us to a certain point.

A benchmark can tell me if Opus 5 is generally good at coding.

An eval can tell me if GPT 5.6 tends to complete some specific task successfully.

It doesn’t tell me if the code it’s producing is what IBM wants to ship. Or if the artifacts it creates follow Amazon’s design standards.

I say it a lot. AI is very good at making “plausible but wrong.”

Conformance is contextual to the environment.

But we can’t just make another gate

The default enterprise solution is probably going to be simple.

Review everything.

Create an approval process.

Put a human in the loop (...that poor human).

Build a better police force.

It won’t work.

Generative systems are supposed to dramatically increase the amount of plausible work produced. We couldn’t scale human review enough when humans were the only ones generating work. It’s even more impossible to grow proportionally with AI generated output.

Which defeats the economics of using that system to govern AI.

The best design system teams I’ve worked on weren’t successful because they were really efficient at rejecting bad work.

They made doing the right thing the path of least resistance.

Documented decisions. Context. Clear constraints.

Visibility to what already exists.

People were guided towards conformance while they worked. It wasn’t a case of coming to the end of the day and realizing they’d violated some rule they never knew about.

I’ve described this, slightly in jest, as a virtuous panopticon. Not watching everyone. Instead making the possible and the preferred more visible.

The same applies to AI. Conformance can’t come after, it needs to participate in the generation.

Guide the way, don’t gate the path

So that’s an interesting new enterprise AI infrastructure problem.

Not how to restrict what models can reach.

How do we make our organizational standards available to them while they work.

If the model is producing UI it needs to know components, accessibility requirements, voice and tone, patterns, and interaction conventions.

If it’s also writing code, it needs access to architecture decisions, security policies, dependency rules and engineering conventions.

Output needs to be evaluated against those constraints.

Block some failures before they’re made. Warn about others. Point to an alternative.

Or just make the relevant context more visible to the human-in-the-loop.

Governance can mean guidance as much as it means permission.

It’s not enough to have standards. It’s about having standards that are easy to follow.

Which, if you’ve worked in enterprise, you’ll know is very often not the case.

There’s a standard. Or six.

Policies and approved patterns.

And the people doing the work don’t know where to find it. Or how to choose which one they should use.

If it’s a human, they probably stop and ask someone.

Generative AI doesn’t stop. It produces some finished-looking artifact.

That can be a hard failure to notice.

The missing half

AI access governance needs to be sophisticated.

We need all that information about users, controls, audits, permissions and boundaries. Especially when we’re monitoring autonomous systems.

But those controls don’t tell us whether the thing those systems produced should exist.

That’s the conformance layer.

The layer that goes beyond just who can ask the question, but whether the answer that comes back is right.

Approval queues don’t work as governance at scale. They slow everyone down. They make people hate the expert teams reduced to policing them.

AI can actually give us an opportunity to make it better.

Make our standards more easily available when the work is being created.

That means encoding organizational knowledge at the right level. And evaluating our outputs directly against what the organization has already decided.

Guide people and agents in the right direction, before we have to stop them going in the wrong one.

Access protects the company from the AI. Conformance protects the company from what it asked the AI to do.

Further reading:

• Don’t become the design systems police - on showing up as a facilitator and not a blocker.

• Nashawaty, P. & Weston, S. AI Output Governance: The Blind Spot in Enterprise AI Strategy. Efficiently Connected, Aug 2026.

• Sure, R. W. The Enterprise AI Governance Layer as a Control Plane for Trusted Enterprise Intelligence (pdf). Independent Research Paper, Jun 2026.

• Mugel, S. Enterprise AI’s Governance Gap: Runtime Safety Is The Missing Layer. Forbes, Aug 2026.

Article photo by Annie Spratt on Unsplash.

Give a designer and a developer the same product brief.

Give them the same amount of time. The same access to users. The same AI tools.

The designer needs enough technical awareness to understand that architecture, performance, accessibility, and security are real constraints. The developer needs the design awareness to recognize familiar interaction patterns and make a coherent interface.

Let them work independently.

At the end of the time, don’t judge the codebase. Don’t count the features. Don’t ask which interface is more polished.

Put the products in front of users and see which one better solves their problem.

My bet is on the designer.

That wouldn’t have been the case a few years ago.

The gates were never symmetrical

Designers understand users. They can frame a problem. Structure the information they have into useful conclusions. Take all that, and determine what the experience should be.

But they couldn’t ship it.

They could make screens. They could have a click-through Figma prototype of the interactions. Explain the behavior with notes, annotations, tickets, meetings, and the all-important handoff.

So that someone else could make it real.

Developers had an opposite advantage. They can take an idea and make a working piece of software. What’s behind the interface - dependencies, data, performance implications, and how simple requirements get complicated very quickly when they meet reality.

But they didn’t have the judgement to decide how that software should work for a person.

Obviously these aren’t universal limitations. I know plenty of great designers who can code, and developers who have excellent design judgment.

But disciplines are training. They point our attention, so we notice different things.

Design trains people to see what’s confusing. What is incorrectly emphasized. The breaks between what a system allows and what a person is actually trying to do.

Engineers are trained to see fragility and bad abstractions. Understand the architecture and hidden dependencies. Bridge the gap between a convincing demo and a system to survive production.

Both those kinds of judgement are important.

AI hasn’t affected them equally.

Didn’t we always want designers who code?

AI gives the technically aware designer a remarkable amount of implementation capacity.

Scaffold an app. Connect it to APIs. Generate components or use the ones that exist. Explain unfamiliar code. Debug when things go wrong. Write a test suite. Take a clear spec around intended behavior and execute on it.

It will still need direction. A designer will need some technical understanding - enough to recognize if the system is making dangerous assumptions. To know if something is moving beyond their competence.

But it’s not the hard stop it used to be.

Designers don’t have to persuade a production chain to make something in order to discover whether it works.

They can make it.

AI also gives developers greater access to design production.

It can generate a clean dashboard. Use a familiar onboarding flow, or a plausible settings screen. It knows visible conventions of software very well. Sensible spacing, tidy cards, useful empty states - everything to make a product feel like it’s finished.

These upgrades aren’t symmetrical.

The system can increasingly perform implementation on the designer’s behalf. But design judgement can’t be acquired by a developer asking a system to produce design artifacts.

The artifact isn’t as valuable as the judgement. As the critique. As the understanding of the user.

AI passes the “first look” test

AI can make some very plausible interfaces. Many product generation tools lead with that capability. Here’s an immediate, visual, impressive interface.

The product appears before your eyes.

That looks like the design was the easy part.

It’s evidence of something else.

The presentation layer is the part of software applications where it’s easiest to manufacture the appearance of correctness, and hardest to verify if it’s actually correct.

If code is plausible but wrong, there are usually backstops. It doesn’t compile. The tests fail. There’s an error.

Engineering is great at detecting what’s incorrect because - if they don’t - the machine doesn’t execute its instructions.

Plausible-but-wrong design is dangerous because it can work perfectly.

The interface renders. The button works. The form submits cleanly.

It’s a great demo.

And there’s no alarm because the dashboard surfaced the wrong metric, and hid the one the user needed to make a decision.

There isn’t the same binary test when we cleanly and efficiently guide our user to the wrong outcome.

If we make a destructive action overly convenient, the app still builds.

We’ve got something usable.

We’ve got something wrong.

Those costs will come later - after it ships. Abandoned tasks. More support tickets. Bad business decisions because the information was wrong. Seemingly inexplicable churn.

It’s because AI is so fluent in the generalities of finished software that discrimination becomes more valuable, not less.

It’s not a matter of taste

This isn’t domain protection.

I’ve led design systems. Of course I think designers are important.

But the argument only works if design judgment means something tangible.

It’s not about choosing better typography, or adding visual polish. It’s not “make the logo bigger”. If it is, then AI has eaten up most of it already.

Some design execution can be automated - because production work in every discipline is getting easier and easier to automate.

Designers don’t have better taste.

Designers are best trained to determine if an experience represents what the user actually wants and needs to do.

What decision is the user trying to make? What information changes their decision? Which actions are reversible?

Does the structure of the product match the structure of the problem?

That’s judgement rather than taste. And, while not exclusive to designers, it’s what their discipline is supposed to train.

The design-aware developer knows that a destructive action may need confirmation.

The designer asks why the destruction is even an option.

It’s different below the waterline

The argument works on the surface. At the level the user sees.

Deeper than the presentation layer, and the results invert quickly.

Ask those same two people to create an infrastructure for high-scale transactions. To protect sensitive data. Recover from partial system failure. Avoid making an architectural decision that will constrain the company for a decade.

Now it’s the engineer’s judgement that’s the scarce thing.

AI produces plausible architecture, too.

So it’s not that designers now outrank developers. That’s dumb. And it reproduces the same mistake companies always seem to make - taking multidisciplinary product development and trying to turn it into a contest between the disciplines.

But AI shifts capability based on the nature of the missing skill.

AI is good at execution.

AI is bad at judgement.

If your historical limitation was execution, then AI gives you more benefit than the person whose historical limitation was judgement.

At the interface layer, that person is probably a designer.

Our org charts were built for the world before AI

Companies are making headcount decisions right now.

They’re compressing design teams, and ensuring engineering is the presumed center of their product creation.

And there’s plenty of logic to that. Hard engineering problems still exist. Software needs to work. And their AI investment is framed around making developers faster.

But that assumes the old distribution of capabilities.

The ability to ship is the decisive gate. Whole organizations have formed around that gate.

Now more people can go through it.

A designer who understands enough about software can increasingly go through it. Move from problem framing to working product, without a bunch of translation layers.

The reverse gate isn’t widening in the same way.

A developer can ask AI to produce a convincing interface. They can’t easily tell if that interface has the right understanding of the person who’ll be using it.

AI won’t be reliable at warning them.

Companies cutting design while concentrating on engineering investment “because AI can do the UX” might be reinforcing a discipline whose historical advantage is eroding the fastest. And reducing or removing the discipline whose central value AI is least suited to reproduce.

AI has made it much easier for designers to become builders.

It has not made it equally easy for builders to become designers.

Further reading:

• Execution is cheap. Coordination is not. - on catching what’s organizationally wrong and codifying it.

• The Intersection of Design Thinking and AI: Enhancing Innovation. IDEO U, Jun 2025.

• Hill, M. Half of developers say AI can code better than most people. AI Data & Analytics Network, Aug 2025.

• Morton, P. Why is AI bad at design? Phil Morton, Jul 2026.

Article photo by Eyre June Bustamante on Unsplash.

Last week I audited my entire toolkit of AI skill suites. Telemetry had its own verdict.

I didn’t use the fitness suite. At all.

I’ll come back to that verdict.

In The Matrix, Neo jacks in, downloads a file, his eyes open: “I know kung fu.”

Using my deep research skill to define a strategic plan for a topic, and turning that into an AI skill suite, is the closest thing I’ve come to feeling like that for real. Research goes in, a tool comes out.

Capability acquired.

I’ve had that feeling multiple times. I have twenty-two domains for work and life - 193 skills in total. Product specs, competitive analysis, balcony gardening, wardrobe management.

Do I know kung fu? Or do I just have a big folder of downloads?

I’m a bad person to answer my own question

In 2025 METR ran a randomized trial. They gave experienced developers frontier AI tools for their own codebases, and measured what happened. The developers believed the AI tooling made them 20% faster.

They were 19% slower.

METR ran a follow-up in late 2025. The slowdown headline went away - newer tools, more practiced people. More interestingly, their measurement broke. Developers wouldn’t even submit tasks they’d have to do without AI. And time-tracking was unreliable when they applied it to agentic multitasking.

The people who measure this as their job concluded that their own results weren’t a good “proxy for the real productivity impact.”

So the durable finding isn’t the 19%. It’s the gap between what we feel and what we can verify - and that gap is getting harder to close, not easier.

This isn’t about developers, so much as it’s about our own testimony. Fluency feels fast. My tooling makes me feel capable, which makes me less reliable. With nearly two hundred tools, I’ve constructed myself into the least reliable witness possible.

So I decided to see if I could pull the data.

• Invocation - what actually ran, when, and where.

• Artifact trail - whether the tools produced anything, and whether that went anywhere further.

• Research lineage - what was fed downstream.

And, fair to say, the telemetry itself isn’t perfect. It’s definitely missed skills that I know I use. Capture is hard.

But the numbers are more honest than my own feelings...my own vibes.

What did the audit say?

In the window I measured, 23% of the skills I’ve built were used. And only twelve skills carry half of all the activity.

That sounds terrible! 193 skills built, and I only really use twelve of them. What a failure!

But I don’t read it that way.

That’s not failure. It’s portfolio selection.

The marginal cost of building the skills with AI was tiny. And when the cost is tiny, the rational strategy is “build a bunch of stuff, and then let reality select.”

While the cost of building might be negligible, the cost of not deciding what to do with it is not.

My sin wasn’t building too much. It was that it took me this long to run the curation.

Living, dead, and somewhere in-between

When I look across my whole portfolio, I can break it down into six different states.

• Regular use. My daily workhorses. A dozen skills doing half the work - meeting debriefs, deep research, spec writing. No notes, these are clearly things I actively reach for.

• Retired, with honors. My first delivery suite - twenty commands - I used heavily for months. But it’s silent because I built a successor and ran an A/B between them. Three of six predictions were wrong - including one I’d filed explicitly as “what would particularly surprise me.” The new suite won, the old one retired. That’s a system that works.

• Obsoleted by drift. I had sprint-cycle skills. We moved from cycles to Kanban. The tools weren’t wrong, they just didn’t apply any more.

• Dormant. I have some skills around tax preparation. They’ve done nothing all summer. That’s correct - they shouldn’t be doing anything in summer.

• Graduated. An interesting one. My wardrobe and style suite logged 46 outfits, cataloged a 222-item inventory, and scored what worked. It went quiet in June. But I think that’s because I’ve taken on those behaviors myself. The tool taught the pattern and then became unnecessary. I need to validate - I’m suspicious of that conclusion - but it’s a case where the kung fu downloaded into me, and didn’t stay in the file.

• Presumed dead. The fitness suite I mentioned earlier. Ten commands for regular use, zero recorded invocations.

...except when I went to look back, even the fitness suite’s logbook told a different story. There are dated entries over several months. Including some that are inside my measurement window. So for some reason the telemetry was blind to it.

The audit result then suggests that there are zero confirmed “dead” skill suites. Silence by itself isn’t enough to declare them dead.

That telemetry issue needs investigating. Measurement brings discipline to judgment. It doesn’t replace it. Apparently a death certificate needs a second witness.

Research - my busiest, most unread, most vital skill

By volume, my deep research skill is the most productive by a lot. It’s made hundreds of artifacts over the last few months.

I almost never reread them.

But that’s the wrong model. If I use a skill to generate a competitive battlecard, its value is clear: someone opens it and uses it.

If it’s a research brief, its value comes from being transformed into something else. After that, it might never be opened again. The value moves forward.

I ran a trace on my ninety research runs. Eighty percent of them led to something real. Thirty-three of them became skills or skill suites themselves. Some of my most-used skills come from the research run that designed them. Others fed identifiable decisions. And some of them led nowhere - like fully drafted skills I never moved to install. No entire suite was confirmed dead. Plenty of individual work was.

The 20% dead rate helps me believe the 80%.

We have to learn to say goodbye

This goes beyond just skills creation.

Build-on-demand works. Twice this summer a real need appeared and I could implement a working Claude skill suite in days, one that immediately became integral.

For personal tooling like this, production isn’t the difficult bit.

But what’s missing - for my practice, but really in every AI-use conversation I see - is the other half of the loop.

Scheduled, honest selection. Kill criteria written at build time, before we get emotionally attached. A quarterly pass where every tool gets a verdict: active, dormant, retired, obsolete - or given a funeral if it’s actually dead.

And I still can’t empirically claim that this makes me faster or better than I’d be if I didn’t have it. I’m not sure anyone can claim that about themselves based on feelings alone. That’s the thirty-nine-percentage-point gap between perception and measured performance in the METR study.

Designing the experiment to measure that is what comes next.

So...I know kung fu. I have the logs to prove it.

But the only kung fu that’s mine is the punch I can still throw after the file closes.

Right now, that’s just one punch. I’ve counted it. Twice.

Further reading:

• Becker, J, et al. We are Changing our Developer Productivity Experiment Design. METR, Feb 2026.

• New data: AI’s impact on engineering velocity is more modest than expected. DX, April 2026.

• Counts, L. AI promised to free up workers’ time. UC Berkeley Haas researchers found the opposite. UC Berkeley Haas, Feb 2026.

Article photo by Getty Images on Unsplash.

But he’d decided it couldn’t just be any old pillow fort. It needed to be different. It needed to be more interesting than “put the cushions against the sofa and throw a blanket over it”.

He wanted me to suggest things.

A cave? No.

A spaceship? No.

An igloo? No.

A pirate ship? No.

And at a certain point, I hit the limits of my imagination. I was tired, and I think he’d just decided to say “no” to everything. He was a challenging client. So I said “why don’t we ask ChatGPT?”.

It gave me ten ideas immediately. Some of them I’d already suggested. But he latched on to the idea of building an animal hospital, and he was off and building.

AI is a good machine for getting unstuck - it doesn’t run out of ideas.

But if there’s a machine that can generate ideas indefinitely, ideas stop being a scarce resource. The scarce resource becomes something else: selection, validation, even taste.

It’s less “can I think of something?”

It’s more “which of these ideas deserves to survive?”

Everyone with access to an LLM has their own brainstorming machine.

Brainstorming fills up a page. It can be energizing. It produces a list of things. But the old refrain of “no bad ideas in a brainstorm” only lasts as long as the brainstorm does. There’s nothing to say that those ideas will turn into something people would use, pay for, or trust.

Idea generation is not invention.

Building a pipeline, not a prompt

I created a set of invention skills that, together, are a structured opportunity discovery and invention suite.

I need the sequence.

Too much AI ideation starts in the middle. Product ideas. New features. Startup concepts. Ten improvements.

We need to start before that.

What’s the opportunity? Who has the pain? What workarounds exist? What would make someone want to use this? What pushes them away from current solutions, or keeps them attached to what they already have?

Once there’s a problem worth exploring, the suite generates concepts that go through multiple methods.

This isn’t free association. This is structured invention.

The suite applies SIT patterns. Uses TRIZ-style contradictions. De Bono provocations. It will collide problems with another domain entirely. It’ll map a solution space morphologically, and build a Zwicky box of parameters and combinations.

And when it’s expanded the problem into potentially hundreds of combinations of ideas, it gets less generous.

Ideas are scored. Stress tested. It compares competing hypotheses against the evidence. Validation planning asks which experiments reduce uncertainty. We do a Mom Test.

We apply kill criteria.

And then the pipeline produces a brief.

One page that states the opportunity, the proposed solution, and the evidence that supports it - provenance is vital. What’s still uncertain? How will we validate? When do we stop?

If you can’t give an elevator pitch for your invention then it’s not finished.

That doesn’t mean it isn’t useful. But it’s not work yet.

Pressure, not abundance

Different methods apply different pressures.

• The opportunity scan will ask if there’s a real problem underneath an imagined solution.

• SIT asks what happens if you remove something, divide it, give it new tasks, or add dependencies.

• Collision takes a domain and forces it into contact with another. Sometimes that second domain might be ancient. Sometimes it’s ordinary. Sometimes it’s weird. The point is not to deliberately get exotic. The point is to apply distance and structure.

• Morphological analysis maps the problem to configurations that might have been entirely overlooked.

• Hypothesis testing weighs ideas against supporting and contradictory evidence.

• Scoring forces those criteria into the open. It attempts to apply some objectivity, and to expose that judgment.

• Validation planning asks what the world needs to show us for this idea to earn more confidence.

• And the final brief ensures that the idea survives to the point of clear explanation.

The suite isn’t magic prompts.

It’s a set of instrumentation, where each instrument marks and deforms the problem in different ways.

Collision rather than metaphor

The skill I have the most fun, for me, is collision.

In a recent piece, I wrote about how old institutions can be repositories of hard-won judgement. Guilds, courts, religious orders, astronomers and scribes. Not because they’re quaint, but because they solved problems around trust, readiness, drift and dissent centuries ago.

My invention suite entrenches that instinct. But it’s not limited to ancient history.

Collision uses anything structurally rich.

DJs building mix decks manage transition, mood and energy. Air traffic controllers sequence risk. Emergency rooms triage scarce attention and resources. I’ve collided ideas and inventions with sources ranging from prehistoric petroglyphs to jazz improvisation to standup comedy.

The source domain has to be useful.

Pure analogy is decoration. “The dashboard is like a city.” Great. Maybe. But something operational needs to flow from that comparison. Metaphors can give the impression of depth without making anything better.

My collision skill tries to avoid that trap by mapping domains structurally.

Who are the roles? What are the processes? What are the constraints? What feedback loops exist? How does the system fail?

After that mapping, it looks for isomorphisms: places where the bones of those structures match up.

I don’t want to know if one idea reminds me of another.

I want to know if one domain has used a mechanism to solve a problem, and whether I can apply that mechanism to a different domain.

Collision should provide functionality.

Making a better dashboard

I’ve been building an internal product flywheel. An AI-and-human pipeline turning customer signals into prioritized work. Scanning sources, routing work, and giving a product manager a draft queue to review.

There’s a dashboard, so that the product manager can see what the flywheel did.

It provided status, trust tracks, run history, signal counts, sizing. It showed what was under the flywheel’s hood.

But the question I was asking of the dashboard was a simple one:

Do I need to do anything?

My dashboard had the problem many dashboards have. It shows you everything you already know. It expects you to infer what matters.

I ran the invention suite against a question: what should the next version of the dashboard look like?

The invention suite came back with a cluster of solutions.

Pattern-driven concepts from SIT. Possible configurations from the morphological pass.

The collider put the dashboard into contact with petroglyphs and twelfth-century administrative registers. That sounds ridiculous - until it produces useful artifacts.

The collision focused on an idea missing from normal critique. Spatial hierarchy is semantic encoding.

If something urgent is visually subordinate, that’s confusing.

That wasn’t the whole answer. But it was an additional pressure brought to bear.

And the same recommendation began to coalesce. A headline-first dashboard, with an action queue separated from the observatory.

That’s a good idea. It might even seem an obvious idea. And the important piece isn’t that the AI produced it. It’s important that multiple methods converged on it.

SIT liked that there was no need to parse the deck first. Morphological analysis had already identified “headline plus detail” as a strong configuration. Collision liked it because spatial hierarchy encodes priority.

It was solving a problem painful enough to justify work. And the hypothesis testing didn’t come back with contradiction.

And so the suite of skills concluded with a brief.

Build a headline-first dashboard with a plain-English status sentence at the top, and in the browser tab title. Put a queue of actions immediately underneath it. Don’t remove all the existing dashboard, but put it below the fold - for observation rather than action.

With a set of validation tests.

Do PMs close the dashboard quickly if it’s all-clear? Do action items get resolved? Does the headline produce false “all-clear” messages?

Scoring, challenging, briefing and validating is invention.

The Machine God isn’t omniscient

This doesn’t make the machine wiser.

The invention suite can still produce nonsense. Scoring can be subjective, with a veneer of precision. Validation plans are useless unless someone runs the experiments.

But the suite provides a foundation for better judgement.

I don’t want any single method to be authoritative. I want it to disagree. I want it to consider a null hypothesis (”don’t do anything”). I want kill criteria.

Curiosity is a good reason to explore something.

The invention suite is intended to help us turn that curiosity into trust.

Back at the pillow fort

My son didn’t need the invention suite for his pillow fort.

He just wanted ten ideas, fast, from a machine that thought faster than a tired dad.

After that, it was just a source of childhood play. The big list of possibilities is great when the cost of choosing is just having to pick up some of the cushions.

That’s not most work.

Product ideas have cost. Engineering work has cost. A strategic choice has cost. AI-generated recommendations entering the workflow have cost.

And as AI becomes increasingly powerful at generating ideas, our judgement of those ideas becomes increasingly important.

AI makes ideation trivial.

That exposes how much of invention was never ideation in the first place.

Invention is about killing the idea you really wanted to like. Then turning the surviving thing into a brief that’s clear enough for someone else to decide what to do next.

Invention is not cheap.

Further reading:

• Why I want my AI projects blessed by Jesuits - on teaching AI what others learned centuries ago.

• Lohr, S. Can A.I. Invent? New York Times, Jun 2023.

• Schultz, B. N. N. Morphological Box (Zwicky Box): Guide with CCA & Example. Service Innovation Labs, Feb 2026.

• Rodriguez, G. R. SIT: Israel’s Answer To Design Thinking? Forbes, Apr 2015.

Article photo by History in HD on Unsplash.

Boring.

Some combination of:

• The Strategic Advisor

• The Risk Analyst

• The Customer Advocate

• The Technical Expert

• The Innovation Lead

A sensible group of faceless people who sound like they’re in a windowless office somewhere talking about operational synergy.

It doesn’t have to be like that.

It could be the Council of Elrond.

It could be a pirate crew.

It could be your younger self, your exhausted present self, your hypothetical 70-year-old self, and someone who thinks your entire definition of success is bonkers.

It could be the contestants of Love Island.

That’s the idea behind my Configurable Council, a Claude Code plugin that lets you run a question through a council of AI perspectives you define yourself.

The process might be serious.

The people don’t have to be.

The council is a mechanism

The original LLM Council, by Andrej Karpathy, asks different language models the same question. They answer, review each other’s answers, and pass everything to a final model for a synthesized verdict.

The diversity comes from the models. Models from OpenAI, Anthropic, Google, and xAI can all make their individual points.

“LLM council” has become a bit of a broader pattern now. Run one model several times, give each instance a different role or perspective. Ask them to approach the problem from different angles.

The diversity is from the prompt, not the model.

The Configurable Council uses that second pattern.

Each member of the council answers separately. Then the answers are redistributed and they review them - anonymously. A chairman weighs the arguments and produces a recommendation.

But you can decide who’s on that council. And that changes more than just the report’s title.

Characters are compact thinking models

A default council might be sensible enough.

A Contrarian tries to find the fatal flaw. A First Principles Thinker asks whether you’re solving the right problem. An Expansionist looks for missed upside. An Outsider catches assumptions. An Executor asks what anyone is actually going to do next.

Professional. Entirely defensible.

But it’s not the Council of Elrond.

Gandalf challenges the framing. Aragorn focuses on practical execution. Boromir looks for power and opportunity. Frodo asks who’ll carry the burden. Galdor demands evidence. Elrond makes the final decision.

The process is the same.

The report is much more dramatic.

But the theme isn’t only decoration.

Any good character is a compact thinking model.

We already understand that Boromir will be drawn to power.

We understand why Frodo cares about the cost to the person doing the work.

We expect Gandalf to tell everyone they have misunderstood the problem.

So we already have a sense of their perspectives.

A “Risk and Governance Advisor” sounds important, but I don’t know how it really thinks.

I have a better idea of how Boromir thinks.

It’s not about more responses

Claude can already generate five answers to the same question.

What we’re trying to do with the council model is generate productive disagreement.

If everyone is kind and helpful, and they produce slightly different versions of the same answer, nothing really happens.

A council needs tension.

Someone should be arguing for the high-risk approach.

Another should think that’s irresponsible and dangerous.

Someone cares about speed. Someone else cares about precedent.

If one person wants to know if the plan will work, another might be asking if success creates a result worth having.

The Configurable Council lets you define explicit tensions. And that disagreement is vital.

A Contrarian isn’t there to add balance. They should be actively trying to kill the idea.

The Expansionist isn’t there to be a cheerleader. They should be trying to push you beyond the caution that undermines the idea.

That’s the work we want.

There is no single council

For a technical architecture question, you might create a council made up of a security engineer, an operator, a maintainer, a finance lead, and the person who gets paged at 3 a.m.

A product strategy question might need a customer, a salesperson, a competitor, a skeptical CFO, and a user who has already decided to leave.

When you’re making a career decision, maybe you need your ambitious younger self, your exhausted present self, your partner, your future self, and someone who thinks you are asking the wrong question entirely.

And some decisions might genuinely benefit from the contestants of Love Island.

Probably not because they know more about corporate strategy.

But expertise might not be what the decision is missing.

Maybe two departments keep saying they’re aligned, but they’re behaving like they’re waiting for someone better to walk into the villa.

Or one team thinks their relationship is an exclusive strategic commitment, and the other behaves like they still want to explore.

Different groups will notice different things.

Your organization probably already has the same groups of people coming together in the same rooms. People with similar backgrounds, incentives, and vocabulary.

Creating a bunch of AI personas that imitate those people doesn’t really give you much diversity.

A dwarf, a hobbit, an elf, a wizard, and a ranger might.

It’s still your verdict

A council is there to provide reasoning.

It’s not there to make the decision.

It’s still AI. A polished report, reviewed responses, a confident-sounding chair.

None of them have to live with the consequences.

Your AI council shouldn’t be an authority. It should expose the assumptions, objections, and missing perspectives around a decision.

It might give you a better answer. It might help you understand why you disagree with the answer it gives. Either will be useful.

The default council is fine.

The Council of Elrond might be better.

Sometimes what your product strategy really needs is a fire-pit conversation with eight people in swimwear trying to work out who’s here for the right reasons.

You don’t always need the same people in the room.

You don’t always need more experts in the room.

You might just need different people in the room.

Further reading:

• My Configurable Council on GitHub.

• Krishnan, R. LLM councils show groupthink. Strange Loop Canon, Jun 2026.

• Champagne, S. What’s Really Behind ‘Love Island USA’ Drama? A Psychologist Explains. Today, Aug 2025.

• Jacobs, Prof A. Why Gandalf and Elrond were wrong. The Homebound Symphony, Aug 2011.

Article photo by Muhammadh Saamy on Unsplash.

The shape of the work doesn’t change.

It’s faster horses.

I know, because I built one of them.

I made a Claude skill suite called delivery-team. Thirteen role-shaped agents; scrum master, devs, QA, conservative and aggressive project managers - all moving stories through a multi-stage pipeline.

It’s good, too. Fast, tireless, it never lost the thread. It moved “vibe coding” to something with much more rigor around it. It wasn’t something I was looking to replace.

But a couple of months ago I had the chance to sit down with some of the staff at Obvious.ai to talk about their autobuild solution. And an idea got stuck in my head.

It wasn’t “how do I make this faster?”

I wondered if we were looking at things the wrong way. That speeding up human processes is the least interesting things we can do with the power of AI.

Scrum exists because humans get tired, change their minds, need ceremony to keep coordinated. Agents have none of those problems.

So I built a second suite of skills. It’s called flow, and it keeps almost nothing from the first. It trades sprints for convergence. Stories for detailed, executable specs (something Obvious.ai highlighted), pass/fail gates for a Pareto front of competing implementations. No retros, but preserved dissents that reactivate when the conditions come true.

This piece is two things. I’ll talk about the practicalities of each suite - the repo is public, there’s a website explainer, you’re welcome to run either. But it’s also an argument about the underlying thoughts: about the difference between speeding up human workflow or asking what delivery can look like when humans don’t have to coordinate inside it.

Respect to the horse

I built the horse first. And I built it with care.

delivery-team simulates a thirteen person Scrum team, with seven gated stages. They coordinate with documents - agents reading and writing artifacts with clear schema. QA can veto but not write code. Architects lay down high level skeletons that are sharded into stories, and that avoids drift. It uses recognized foundations: BMAD, MetaGPT, Team Topologies.

I can point it at a codebase, or work with it to build from scratch. It goes fast, and it’s good. It never gets tired, never waits for a calendar, and never forgets where it’s at.

But that’s also a problem.

It’s accelerating workarounds that we made for humans. It’s not doing AI-native delivery.

Hell, it still asks me “do you want this to be a 3-day, 5-day, or 10-day sprint?”, even when I know the work will be done in about an hour and a half.

1. Role abstraction is a crutch.

   The suite has thirteen fixed agents. Hand-tuned. But those roles exist because hiring humans is expensive and so we specialize and we commit. That’s payroll, not architecture.
   

   Google and the University of Cambridge’s paper on Multi-Agent Design found that optimizing topology and prompts beats fixed roleplay by nearly 80% on agentic tasks. Anthropic’s own research system dispatches dynamically - one agent for something simple, ten or more for something hard. It’s not using the same org chart every time.

2. Sprints are a backstop for risks in human commitment.

   We time-box sprints because calendar coordination is costly, and if we put things into two-week boxes then it’s safer. An agent doesn’t have any of those uncertainties, and it doesn’t need a calendar.
   

   Sprint boundaries are arbitrary lines we use to manage people. Not the work.

3. Heuristics for humans.

   Story files locked at eighty percent test coverage. That’s a number to trade human effort for human risk. It’s not a property of LLM code. But our stories start drifting the moment we start work.

Rituals aren’t features. And if we put them in the AI loop, they start to become obstacles.

What if nobody gets tired?

flow is designed for agents instead of trying to design around them.

I took some insights from Cognition AI’s 2025 engineering post.

• Actions carry implicit decisions, and conflicting decisions carry bad results.

• Agents can read in parallel safely. But they cannot write in parallel safely, because they all made decisions and accumulate a pile of them that aren’t reconciled.

flow lets multiple agents read, score, search and dissent - but only one of them commits. Intelligence works in parallel, but writing is serial.

Not my invention, but it’s what I built around. It shapes everything that happens downstream of it.

1. Specs are the source of truth.

   I think this is a concept fast getting traction. Take the whenwords library, which shipped in February. More than seven hundred conformance tests, no hand-written code, and all the maintenance is in the spec.
   

   The code is the build artifact of the spec.

2. Stories become generations.
   We build a wide population of implemented variants. They’re scored against an eval suite. It’s not one attempt that we choose to accept or send back.

3. Acceptance gates become a Pareto front.

   We treat quality as a vector. We’re trading speed against simplicity, simplicity against security, and so on.

4. Retros become diffs, reviews aren’t forgotten.

   We maintain a running diff between predictions and productions, rather than the ceremony. And dissents are saved as objects that get reactivated under certain conditions. If a reviewer warns “this will break if we introduce X,” they might be right later.

The bit that still feels like AI being “magic” is what happens next. flow doesn’t build one implementation and refine it. It builds five (or six, or seven - it decides how many it needs) at once, all from the same spec. It scores against different evals, and each build focuses attention on a different metric. Then it converges, keeps what’s good, regenerates and converges again.

That’s five parallel takes being iterated in tandem. If that was a human team, that’s five engineers, five branches, a month of time we probably don’t have. An agent population does it in one afternoon.

It’s a weird way to work. It burns a lot of tokens. But watching it happen convinced me it’s a question worth chasing after.

But we all know the price of gas

None of this is perfect.

flow costs about five times the generation tokens of delivery-team. That signal might be worth every cent. Or you might have spent fifteen dollars when three dollars would have told you what you need.

It fails in different ways, too.

Sometimes it will try to game its own metric. Generators tend to satisfy the eval as much as solve the problem. Goodhart’s Law lives in the same system I built to avoid Goodhart’s Law about old threshholds!

Eval suites can be wrong, and wrong evals aren’t a bug, they’re a problem with the spec. So we might confidently reward the wrong variant.

It’s not fully automated yet (although neither is delivery-team), which is already leaving opportunities for acceleration on the table.

Perhaps most importantly, flow needs that spec, so you need to be able to write it. If it’s doing exploratory work, or you don’t know what “correct” even means, it’s going to flail. And its flailing gets expensive.

The horse is still valid. delivery-team might still be the right tool. When the spec can’t be pinned down. When stakeholders need a recognizable word like “sprint” to trust the machine. You can reach for different skills at different times.

My curiosity has resolved into a much better set of questions. Not yet a verdict.

Curiosity killed the cat

Curiosity is a great reason to build something. But a bad reason to trust it.

So run the same effort through both. You can write the same problem statement. Define the same set of evals. And look at the metrics; time to ship, token spend, human review time, defect count, etc. flow should beat the delivery-team horse, and it certainly shouldn’t regress.

This is still a live test. It isn’t a launch.

Both suites are open-source.

• The repo is at github.com/shinytoyrobots/agentic-delivery-suites.

• Further documentation at shinytoyrobots.github.io/agentic-delivery-suites.

Clone them, run them, apply them to your work. Tell me what’s wrong.

The fork

It’s not really about the specific skill suites.

It’s about the problem. Can you write the spec? Can you instrument the evals? Do stakeholders need a specific vocabulary to instill trust.

One of these is the better horse. The other one might be a car.

Further reading:

• Zhou, H, et al. Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies. Google, Feb 2025.

• Yan, W. Don’t Build Multi-Agents. Cognition, June 2025.

• Breunig, D. A Software Library with No Code. dbreunig.com, Jan 2026.

• Marwala, T. ‘Greatest Good’ Exists Not at the Extremes but Through Exploration of the Middle Ground — Pareto. United Nations University, Feb 2024.

Article Photo by Pete Godfrey on Unsplash.

Earlier this year this centuries old approach to astronomy and astrology solved a problem I had trying to fix a dashboard.

The dashboard’s mine. It’s on top of a system I’ll come back to later - an AI pipeline to turn customer signals into executable work. The dashboard tells me if I can still trust the machine’s judgement.

It had a problem every dashboard faces. It can’t see its own drift.

When the AI slowly gets worse, and if my own instinct on “good enough” also slides, the dashboard will have green lights all the way down. It’s not lying, but it’s quietly going wrong.

The astronomers at the Jantar Mantar solved the problem centuries ago.

They knew their instruments drifted. They knew the assumptions they had in their calendar would, over time, pull away from the actual stars in the heavens.

They also didn’t trust the running system to catch its own decay. They re-anchored, on a schedule, against a fixed external baseline. It’s a mathematical correction called Ayanamsha to anchor their astrology to the fixed stars, and account for the earth’s drift.

I didn’t learn this solution from a digital product blog about dashboards.

But I did get it on purpose. By colliding the problem in front of me with a domain that had nothing to do with it. And, once I really started doing that deliberately, I can’t stop noticing a pattern. The hardest problems in the newest technology - AI - are often old problems wearing new clothes. And ancient answers are better than ones we’re busy reinventing.

The library five years shallow

Most people building with AI are reasoning from five years of data at most. Last quarter’s framework, the most recent SaaS playbook, or the pattern that worked last time.

That’s not a knock. It’s a fast moving field. Five years ago feels like forever. But it means we’re solving ancient problems with a shallow frame of reference.

And it’s not just a story about code. That’s the one we’re telling the most. AI writes a function. AI reviews a pull request. AI ships a feature. That’s real, interesting, and only a slice of the whole.

I lead product. When I’m using AI it’s not primarily about writing code. I’m triaging customer signals, internal data, and predictions about the future. And using that data to recommend how to route, draft specs.

How to decide what’s worth building.

Those are judgement calls, and I need to know how much of that judgement I feel comfortable trusting.

Is something ready? Calibrated? True? Is that prediction honest?

These aren’t engineering problems. They’re the problems guilds, courts, councils, and churches have stress-tested over centuries - and we can use the answers they wrote down.

So I went looking for the answers on purpose. This is how I did that, and what I found when I started building with them.

Reading old code

The how is a method I built into a skill called inv-collide. Part of a broader suite of invention related skills.

It stems from an idea called bisociation, created by the author Arthur Koestler. Then it operationalizes that idea.

Take a problem in front of you, and then a domain that has nothing to do with it, and you force them through three steps.

1. Map both as structures. The roles, processes, constraints, feedback loops, value flows, and failure modes. Not what they’re about, but about the bones of what they do.

2. Find the places where the bones are identical. Isomorphisms.

3. Generate concepts at that intersection. e.g. if this domain solves problem P with mechanism M, and I also have a version of problem P, can I transplant M?

It’s not the same as brainstorming. Brainstorming is free-association. Bisociation matches the bones of the thing. That discipline makes the output usable.

And that discipline requires a step people might skip.

Disciplined enough to discard it

It’s all very romantic. I found a poetic parallel between a dashboard and the stars in the sky. Well, the universe is really big and it’s easy to make up a metaphor.

If the method was just making nice-sounding coincidences, it would be a party trick.

It also generates a big discard pile.

When I collided the trust dashboard with the Jyotish astronomy and the Jaipur observatory, it surfaced twelve structural matches.

Astrological muhurta - an auspicious window where conditions align and you can move forward - mapped directly onto a promotion gate in my system. The point where AI capability became more trusted to act autonomously.

That got thrown out. It wasn’t bad, but my system already had a streak counter and encoded readiness gates. This added costume, not structure.

The collisions are only worth integrating when they survive an honest attempt to kill them. Re-anchoring survived. It runs in production.

Running old code in my product flywheel

Underneath the status dashboard is what I call my product flywheel. It’s an AI-and-human pipeline to turn customer signal and internal consensus into execution ready work, without a person writing every issue.

It reads from various sources - customer knowledge base, Slack, Zendesk. Then it classifies and routes what’s changed. It’ll draft a business case and independently assess it, scaffolding the approved work into Linear. Then it will recommend routing, priority, and provides a rate-limited queue for engineering to pull from.

This is product work. The product flywheel feeds execution, but it isn’t the execution. This is triage, routing, specs, and prioritization. Engineering pulls from its output in order to execute.

This isn’t a story about code review. These are rules for intelligence from medieval guilds, eighteenth-century astronomers, and the Talmud. And they’re applied to the most difficult parts of trusting AI with product judgement. Applying methods that were created a long time ago.

Here are three that are running.

Earned trust, and the medieval masterwork

One of the oldest problems in management. When do you let someone work unsupervised?

If you get it wrong early, you’re letting unqualified hands do a lot of damage in your name.

If you get it wrong late, you’re throttling the potential of someone who was ready.

Every craft tradition that’s lasted seems to have solved this in the same way. With a gate. A guild apprentice submitted a masterwork, and the sitting masters judged it. A Jesuit student reached a point where his judgement was, in their words, formed. Trust was domain-specific, slow to build, easy to lose.

AI tooling uses a flag. We set a permission mode, and we crank the autonomy up and down depending on how brave we’re feeling. But the system isn’t demonstrating anything.

The flywheel doesn’t have a dial. Its agents earn the right to act, and they don’t start with it.

I track trust per stream. Incoming customer signals, routing, drafting, the queue controller all have their own standing. Being good at one thing is no evidence of being good at anything else.

Each capability can climb through three tiers. The tier changes what the agent is allowed to do. An apprentice intake agent reports what it would have done, line by line, and needs a human to confirm every call. A journeyman provides a summary of what it would do, and asks for a single confirmation of that summary. A master executes and then reports back for review.

An agent moves from apprentice to journeyman on fourteen consecutive clean runs - confirmed, by a human, as correct. The journeyman to master takes thirty. And this isn’t an average. One bad run resets the streak to zero. And mistakes made by more “senior” agents mean demotion and a doubled threshold.

That’s the medieval guild structure, as a YAML file.

Trust is isolated by domain. It’s earned slowly, lost easily, and more expensive to win back a second time. That’s not how permission flags work, but every master craftsman who ever lived would recognize it.

That makes autonomy something earned - and easily lost.

Calibrating my judgement against the stars

Let me close the loop on that dashboard.

I’m not worried about the AI “breaking”. That will be loud and obvious. What I’m worried about is silent drift. Miscalibration as the AI degrades slowly, and the gap never shows up.

Those astronomers in Jaipur had an answer. Re-anchor on a fixed, external, baseline. On a schedule. Not trusting the instrument to audit itself.

My flywheel uses two versions of that.

1. A deliberately imperfect target. My runs are clean if I override the AI’s call no more than fifteen percent of the time. Not zero. Zero overrides is a person not paying attention. We want a target that keeps someone in the loop.

2. You can’t re-baseline a scoring system - even if it’s an improvement - without re-scoring at least five historical projects against the new rules. Then recording the sign-off and noting the discontinuity. You can’t move a baseline and also erase the evidence that you moved it.

That’s Jantar Mantar. Re-anchoring against a fixed point, on a cadence. And keeping its receipts.

Adversarial truth-seeking, in the room and in the spec

If we review for consensus we throw information away.

Two smart, competent people disagree about a tough problem. When that disagreement gets resolved, we move on.

But that signal tells you a problem has more than one shape. And that losing argument might be right under conditions that develop in future.

The Jesuits formed students through disputatio. A structured, adversarial defense. You don’t prove you’re competent. You prove you’re competent when a skeptic attacks your work.

The Talmud has preserved the minority ruling alongside the majority one, deliberately, for two thousand years. A defeated argument might become the right argument when the world changes.

Those memories need to be written down. If they don’t, we don’t remember them. A dissent gets aired in a meeting, a decision gets made, and the losing argument is - at best - noted in a retro document that nobody reads. That’s even worse for product decisions - routing, prioritizing, build this not that - than code, because the record’s thinner.

The flywheel runs these institutions against product judgement.

Disputatio is in every routing decision. Recommendations don’t come from one agent, they come from a pair. One proposes the route and the priority, and the second is designed specifically to challenge it. Attack the recommendation before it’s committed. The proposal has to survive the examination. That’s Jesuit insight - that the defense is where the judgement is formed - applied to a decision about a customer request.

Chavruta is the basis for how the system records the disagreements. Reviews produce dissents. The dissents don’t need to be resolved, but they are committed. And not just as a stale record. They’re structured objects that include conditions under which they wake up again. Recheck at the next live run. Resurface if a specific metric flatlines. When the world changes to match a trigger, that old losing argument comes back on its own and demands a second hearing.

Consensus is lossy. The Talmud knew that two thousand years ago. My flywheel acts on that memory.

Others still on the bench

There’s a couple more collisions which produced things that I haven’t shipped yet. The same method, but in the design stage.

1. Drift lineage. A text copied by hand for a thousand years has scribal drift - small errors that harden into official fact because the chain is trusted. Traditions that survive have apparatus for this - lay one manuscript next to another and see where the text mutated. I’m building the same thing for a claim - a walk backwards to the primary source, and flags where the numbers or the conclusions changed. Not whether those changes were right or wrong, but a lineage of provenance and drift from source.

2. Avoiding “vaticinium ex eventu“. This is prophecy after the fact. Re-reading the record once you know the outcome, and bending the record to show you were right. AI multiplies confident predictions, and decision journals are editable. Medieval clerks had the answer. A boring, comprehensive one. Witnessed, dated, tamper-evident entries. Predictions logged and stamped, and scored at outcome time. It’s about not lying to yourself about a prediction.

We keep reinventing what was proven

It’s about trust.

Transferring trust to something that acts in your name. Keeping your own judgement from drift. Not letting disagreements die. And being honest about predictions.

None of them are about AI writing code.

It’s about trusting AI’s judgement, calibrating it against my own, auditing it, and keeping us both honest.

This match to old institutions is real, not a flourish. History is not just a charming source of cool metaphors. It’s where they already ran these experiments. Where they wrote down the answer in a language nobody speaks any more.

It’s the debugging history of our species, and we’re reaching past it for last quarter’s new framework.

When you hand an AI something that matters - a decision, a forecast, a release - find the institutions that already solved it.

Read their old code.

Get the thing blessed by Jesuits.

Further reading:

• Sarda, S. India’s mysterious gateway to the stars. BBC, May 2022.

• Popova, P. How Creativity in Humor, Art, and Science Works: Arthur Koestler’s Theory of Bisociation. The Marginalian, May 2013.

• Farrell, A. P. The Jesuit Ratio Studiorum of 1599. Conference of Major Superiors of Jesuits, 1970.

Article photo by George Dagerotip on Unsplash.

It also seems to have a problem: a strategic imagination still bound to the canvas.

I realize that’s a challenging thing to say about perhaps the most important product tool of the past decade. This is not a “Figma is dead” article.

Figma changed how digital product teams work. It made design a genuinely multiplayer activity. It made a design file a shared space. Collaboration, critique, exploration, and handoff in a browser-based canvas everyone could see.

Sketch looked comfortable before Figma came along. Users and workflows and plugins, and enterprise legitimacy. A whole ecosystem. InVision for prototypes, Zeplin to support handoff. Abstract for version control.

Then Figma came in like the Kool-Aid Man and made Sketch look obsolete almost overnight.

It wasn’t anything to do with Sketch’s design features. It could still draw a rectangle!

But Figma changed the whole basis of where the two products were competing. Not the design tool with the best interface, but making design collaborative.

I’ve never seen another product that created as much practitioner pressure for change as the internal demand at IBM to switch from Sketch to Figma. It overcame corporate inertia faster than I’d have imagined.

Figma just had better answers. Staying on Sketch meant being left behind.

Figma solved the coordination problem of its moment. Its risk is in continuing to solve the problem after the problem has changed.

There is a historical parallel. But it’s not as glib as “Figma is the new Sketch”. That’s too neat. Figma is clearly larger, more deeply embedded, and has a degree of strategic awareness.

But incumbents don’t usually look like they’re sleeping. Especially from the inside.

Figma is shipping a lot of stuff. And they’re telling a coherent story about the future that runs through them.

Are they building that future, or just extending the conditions that made them dominant before?

The center of gravity is moving from canvas to code.

That means from abstraction to execution. From static artifacts to live systems. And from design files to context that AI interprets and generates from.

Designers will still need visual tools. And teams will need shared spaces for critique and exploration.

But what does Figma do when the canvas is not the center of gravity?

How Figma won in the first place

Figma’s first great achievement was technical. They made the browser matter far more for design than anyone thought possible. Cross-platform access mattered. Performance mattered. Multiplayer mattered.

The product was excellent, and execution counts.

But the deeper shift was cultural.

Before Figma, collaboration was fragmented. It needed local files, redlines, PDFs, and those meetings where everyone asked “is this the right version?” Figma collapsed all that distance.

Figma wasn’t merely a better canvas. Figma was a better coordination model.

It made work around the design abstraction collaborative. Which was a huge step forward.

But an abstraction is still an abstraction.

The canvas is not the product. It’s a representation. The real product is in code.

The canvas was vital for helping us think before the reality of implementation got too expensive.

But it depends on a world where there’s a big gap between visual intent and working software. That’s where the abstraction lives.

AI is collapsing that distance.

The canvas answers a translation problem

The canvas makes sense.

Designers express intent. Engineers translate the intent into code. Product managers mediate priority and scope.

We use the thing we imagined to help us ship the thing that’s real.

And that model isn’t going to be going away any time soon. Many organizations will likely work this way for years to come, if they can get away with it.

But the direction of travel has changed.

Design-to-code is faster. Which is great. But it’s just collapsing the way we already work. Handoff, but faster. Translation, but faster.

What’s genuinely different is how structured design and product context, component code, and rules can be interpreted directly into coded, working interfaces. A prompt no longer has to start from nothing if it has access to the design system, APIs, patterns and engineering constraints.

And design becomes that context. A context for AI execution systems to use.

Teams are still going to need visual comparison and critique. They’ll need shared spaces to make business calls. The terminal window or an IDE is not a place for a lot of stakeholders to participate.

That doesn’t make the canvas central.

Bring it back to the canvas

When I look at Figma’s recent moves, they make sense. They build on its current strength.

More work should happen in Figma. More artifacts should come from Figma. Workflows should come back into Figma. More of the product development should be in the Figma ecosystem.

Reduced to its simplest form, the strategy seems to be:

Bring everything back to the canvas. Our canvas.

But the next era won’t be organized around that.

It’s why I thought “code-to-canvas” was pretty revealing. Make a real thing, then bring it back into Figma as editable frames.

That might solve a short-term collaboration problem. Directionally, it’s strange. Actually, it’s wrong. Wrong for the future, even if useful for Figma’s current position.

In that example, Figma is more worried about getting you back into their room - where they know how collaboration works. Less worried about whether that’s the right model of collaboration for the future.

The canvas won’t be the source of truth

Of course, Figma might be moving towards a more compelling future. One where Figma is a collaborative interface that reflects reality.

But it would be Figma as a lens.

Figma might be where you inspect your working systems. Compare variants. Annotate things that are real. See the design system drift. To steer and govern.

That might be valuable.

It also means accepting the canvas isn’t the center any more. And if it remains important, it only does so if it can be an interface to the truth.

The code, the runtime, what’s real, and what actually ships.

Figma’s danger seems to be trying to remain central by making everything pass through your old model.

That’s an incumbent trap.

That’s looking at what made you dominant in the first place, and only working to improve that thing. And that will be right...right up to the moment that the basis of competition changes.

Figma won against Sketch because it realized the center of gravity could change.

Now that center of gravity is changing again. And Figma is on the other side of the innovator’s dilemma.

Execution is cheap. Coordination is not.

AI makes execution cheaper.

Not free. But from a practitioner perspective, it can feel that way.

AI scaffolds the screens, uses the components, wires them up, refactors and gives us variants. It can create at a speed that changes all the old bottlenecks.

So the limiting factor is not “can we produce an interface?”. The limiting factor is “can you produce the right interface, with the right standards, for the right users, in a way our organization can trust?”

Coordination with AI assistance is not the same as collaboration in a canvas abstraction. We need structured and ranked context.

Which components are approved? Which patterns are deprecated? Which implementation is authoritative when the docs say one thing, the code says another, and Figma says a third? Which accessibility rules apply? Which regulatory constraints matter? Which engineering standards are non-negotiable?

That isn’t a canvas problem.

It’s an infrastructure problem.

Design systems are even more important in this world. Not as component libraries or asset stores, or even as docs for people to manually consult. They’re executable intelligence that tell AI systems how an organization builds.

The canvas is insufficient. It can arrange. It can invite critique. But unless it’s deeply connected to some control layer of product delivery, it risks becoming a pretty picture while the real thing lives elsewhere.

That’s a strategic problem.

What Figma seems to believe

From the outside, Figma seems to believe it can expand its canvas to contain the next era.

And, look, that may be unfair. It’s an external read of a company’s strategy. Figma is full of smart people, with every incentive to understand the shift. It may even be the smart commercial decision. That doesn’t make it the right product model for the next era of work.

Product strategy reveals posture. And Figma’s posture seems focused on a return to canvas.

Bring your generated work back. Bring your coded artifacts back. Bring your developers into Figma. Bring AI into the canvas.

Put more of your organization into the place Figma owns.

Which isn’t necessarily stupid. Enterprises have historically liked consolidation. People are familiar with Figma. And Figma has a gravitational pull from its market dominance.

Figma can keep adding useful capabilities.

Will those capabilities help Figma adapt to a world where the working artifact, and the organizational context, matter more than the design file?

Figma’s bet is: yes, because all of that will come back into Figma.

It’s a bet that the canvas is the core.

And if we change the spaces where we work?

I don’t think the next dominant product workspace will look like Figma with more AI features.

I don’t think it will look like a traditional design tool at all.

More likely, an IDE with some spatial collaboration. Or a browser-based product environment where live software is directly editable, inspectable, and deployable.

It will need to involve an AI orchestration layer that sits across design systems, repos, documentation, analytics, and product management tools.

Some integration of canvas, code editor, staging environment, governance and rules system.

It’s going to look bad at first.

Early versions of what’s right are going to look worse than mature versions of the past. Awkward, incomplete, and easy to dismiss.

Figma should understand this better than most. It won the last round because the future wasn’t just a better design tool, it was a different environment for the work.

The canvas may well remain essential. The canvas-as-abstraction will not.

The canvas needs to be a place to discuss reality, not flatten it.

That is a hard, interesting problem.

What does Figma do next?

I can think of three paths.

A defensive path is to continue to expand the canvas. Build to make more and more work happen inside Figma. That will definitely produce useful features. And it might produce strong revenue. Figma is dominant, and can become stickier and more embedded.

A second path is transitional. Make the canvas more code-aware, and more interactive. Better generation and better workflows. Better import and export. This seems to be where their current moves are. It’s really useful, but it still organizes around the canvas as the product environment.

Or it might accept that the canvas - and thus Figma - won’t be the center of truth. So they build to become one of the best collaborative interfaces into that truth.

That means treating code, product context, design systems, and live behavior as the actual work. And the canvas is just a view into that. A place where teams can reason in a visual way about a system that’s already alive.

I don’t know if Figma wants to make that pivot.

Strategic change isn’t necessarily about seeing into the future. It’s about having to give up on the assumptions that make the present business work.

Multiplayer design isn’t going to go away. It still matters.

The question is where that will live when we can generate, modify, review, and ship product much closer to code.

Figma understood the last change in the center of gravity. Now that center of gravity is moving again.

I’m curious whether Figma follows it.

I’m not a neutral observer.

I’m VP of Product at Knapsack. We’re building in the place where structured design systems and product context meet AI-driven delivery.

Further reading:

• Seiz, G. & Kern, A. From Claude Code to Figma: Turning production code into editable Figma designs. Figma Blog, Feb 2026

• Banfield, R. Digital Design Isn’t Dead. It Just Got Way More Interesting. Medium, Apr 2025.

• The Innovator’s Dilemma. Wikipedia.

Article photo by Krakograff Textures on Unsplash.

A library is where you put your artifacts.

The humans provide the system.

People explain what the documentation misses. They can tell you why a component works that way. The problems with the official pattern, and why it hasn’t been fixed. They’re the emergency service for a team who can’t find the artifact or guidance that quite fits what they need.

Design system teams patch the gaps with critique. Slack threads. Office hours. Design reviews. The accumulated judgment of the organization.

We got away with that for a good while now.

It’s not ideal. Not efficient. But it’s workable.

AI makes it a lot less workable.

That’s not because AI needs something fundamentally new from a design system. It’s because it exposes a requirement we’ve been fudging all too often.

A system that doesn’t know how it wants to be used isn’t incomplete because AI arrived. It was already incomplete.

Its humans were just better at workarounds.

It’s why I’m skeptical of the idea that making design systems “AI-ready” is a new category of work.

AI consumes information differently than a person browsing a docs site. Markdown, frontmatter, metadata, and retrieval-friendly matter in a way they might not for a human reader.

That’s an important representation layer.

It doesn’t change the concept of a design system.

Design systems have always needed to explain more than just what exists. They need to explain how to use what exists, why, what it replaced, where it can flex, where it breaks, and what to do when something’s missing.

That’s design system maturity.

It just happens to parallel AI readiness.

The real shift is this:

Take away your components, and what have you got?

Salesforce Lightning, Google Material, IBM Carbon. These systems didn’t arrive as immaculate frameworks, independent of existing product realities. They emerged out of large organizations that were already shipping at scale.

They codified familiar solutions, refined them, integrated them with existing ways of working.

The best systems grow out of prior knowledge.

At IBM, Carbon has components, tokens, and documentation. But what makes it strong is that it has a stance.

It explains how the system wants to be used. It makes decisions visible. It gives teams accessible components, but also explains how IBM thinks about accessibility.

What to avoid. Where to extend. How to think when the answer isn’t obvious.

I pointed an AI at Carbon when I was vibe coding a personal project. It got a solid result.

Carbon hasn’t been magically reimagined for AI. Carbon is powerfully explicit about how the system works.

The operating model is more important than the components.

Broader product and brand intelligence still matters too. A design system alone can’t tell AI what your company should build or what your product strategy is.

The design system has a narrower responsibility. How to make its own operating model legible.

That means decisions on what the system encourages. What makes a good extension? Which are the patterns we like and which do we tolerate? Why did we change that component? What’s the justification for that exception?

Humans usually want to ask those questions.

AI powers past all the missing answers.

“Context-based” design systems, also known as “good” design systems

So much of this “AI-ready design system” conversation misdiagnoses the problem. It’s as if “context” is some mysterious new discovery that we need to add for the machines to use.

Not the thing that separated a design system from a component library in the first place.

The system is not just its visible parts. It’s the reasoning that connects them.

TJ Pitre at Southleft describes part of this problem well in his writing on context-based design systems. His diagnosis is right: components and tokens alone are not enough. AI needs the context around the system, not just the artifacts inside it.

But this isn’t a new model for design systems.

It’s the old model.

Except now it’s being tested by a consumer that can’t quietly compensate for everything we failed to document.

Plausible is not the same as good

AI design system demos can produce something plausible when the room’s furnished. The framework. The components. The tokens. Codebase conventions it can imitate.

Plausible is not the same as correct.

Plausible means it holds together in that moment. Consistent spacing, the right component names. It passes the first glance test.

Good means the decision makes sense.

Good means the pattern fits the use case. That we understand the accessibility tradeoffs. Know that the exception in the implementation is intentional and justified. That it respects the system.

You can’t get that kind of quality from just your artifacts.

It depends on the receipts behind the artifacts.

People carry a lot of that context informally. In the heads of people who’ve been around long enough, who take the time to talk about it. In the old email threads that live long past their expiration date.

That’s worked better that it might have.

It’s also failed regularly.

This is how design systems drift. It is also how products drift away from design systems. It’s why you can build an inaccessible experience from 100% accessible components. The pieces are correct. The composition is not.

Someone might have the artifact, but not the context, the nuance or judgment to make the artifact useful.

AI accelerates that. A lot.

AI reaches for what’s visible. Uses the semantically close component. Follows a statistically likely pattern. It will make something that looks kinda aligned and completely miss the reason the alignment mattered.

That is a design system problem exposed by AI.

Different format, same responsibility

We don’t need to invent a separate discipline or domain around “AI design systems”.

We need to be more rigorous in doing the work that good systems always required. Then make that work consumable by machines as well as people.

Write guidance that explains usage, not just availability.

Document the reasons why, not just the end outcome.

Use examples as evidence of judgment.

Be explicit about exceptions.

Explain what to do when the system doesn’t have an easy answer.

Structure the content well. So that humans can read it and machines can retrieve it.

The design systems that handle AI well are ones that already understand what they’re for.

They will have a point of view. Patterns grounded in use. Teams that have captured not only what they shipped, but why it was worth sharing.

AI doesn’t make that a new requirement.

But it probably removes our ability to pretend the artifacts were ever enough.

Further reading:

• Pitre, TJ. Context-Based Design Systems Revisited. Slot Machine Substack, May 2026.

• Whitehead, R. Does It Matter If AI Doesn’t Understand Context? Institute of Analytics, Apr 2025.

Article photo by tonny huang on Unsplash.

That might be true.

Evolutionary biology has a concept called carcinization. Crustaceans that aren’t crabs will - independently - evolve into crab-like forms. They do it across lineages, and it’s happened multiple times through history.

Different species. Different environments. Same solution.

Crabs, as it turns out, are what you get when you optimize hard enough for a similar set of pressures.

You might make the same observation about the application landscape. The same component libraries. Same sidebar navigation. Chat interface with an input field at the bottom. Muted palette, rounded corners, and empty states with friendly illustrations.

Nobody is copying anybody.

It’s a reaction to the same constraints. Foundation models producing the same outputs. And now we’re optimizing for the same LLM coding workflows. That creates a consistent pressure to ship fast, test cheap, and iterate immediately.

Same environment. Same selection pressures.

Same crab.

When everyone’s solving for the same things - speed, cost, LLM-friendliness - convergence isn’t a failure of imagination. It’s the logical outcome. And AI can make that convergence happen at speed.

Carcinization is inevitable...if the selection pressures stay the same.

Crabs aren’t destiny. Crabs are what evolution produces to answer a specific question. If the question changes, the answer will too.

Teams building things that actually look different aren’t ignoring the constraints. But they’re adding at least one more - the need for something to be good. Not just fast and functional. And not just a matter of taste.

Good that requires someone to have made a decision about what good means.

AI can’t optimize that. It’s a human call.

Speed is table stakes. Cost is...if not free then converging to the point of consistency. The scarcity is wanting something specific that pushes against the path of least resistance.

I wrote a piece last year about how AI changes the creative equation. Fast is free. Cheap is everywhere. So the only real differentiator left is good.

This is what that looks like in practice.

Yes, early AI adoption will make teams stand out. But AI will make fine effortless. The true differentiator is something ingenious, or newly imagined.

Convergent evolution is real. It happens anyway. AI means it’s coming for every product category, every interface pattern, every design system. And coming fast.

Time to decide whether you want to be a crab.

Further reading:

• Hamers, L. Why Do Animals Keep Evolving into Crabs? Scientific American, Jun 2023.

• Rizal, K. Tyranny of Smoothness in the Age of Generative AI. AI Advances, Jan 2026.

• Martignetti, T. AI is replacing creativity with ‘average’. Fast Company, Apr 2026.

Article photo by Mackenzie Cruz on Unsplash.

Brand guidelines, brand standards. Decks sent to agencies. A Confluence page. Almost certainly a PDF or two.

Where does a design system team’s work live?

The component library. Tokens. The design system website. A Storybook instance. An npm package.

Two expressions of what a company is. Consistent and coherent in themselves. Often almost zero shared conversation.

It’s a strange structural failure in modern product organizations. I’m surprised it’s not talked about more often.

Brand sits in the marketing organization. Design systems sit somewhere in product, design, engineering organizations. They share a fundamental subject matter, but operate in organizational separation.

The results are predictable.

Design systems encode visual consistency without brand meaning. Brand guidelines describe how a company should feel...and nobody in product has read them.

The digital expression of the brand gets determined by whoever’s in the room.

Whose job actually is it to ensure that a product expresses the brand?

In most enterprises I’ve seen, the honest answer is nobody. Brand says what a company should feel like. Design systems say what the products should look like. And there’s a gap between the two where digital brand value can quietly disappear.

It’s an archaeological artifact.

Brand as an organizational function predates digital product as a discipline, by decades. And those structures have calcified. Brand in marketing, product in...product. And that’s held even after the product has become the primary brand experience for most companies.

Your brand is not the ad. Not the packaging. It’s the thing you use every day. But the org charts are already set.

I’ve seen the alternative. I built one of the few examples I see of how it can exist at scale. IBM Carbon doesn’t derive from component logic. It derives from a broader IBM design philosophy - that predates the system, runs deeper than any product services. But which defined a design language with awareness of, and collaboration with, the digital design system team.

The result is that I see Carbon in an IBM television ad or on a billboard. Or, more accurately, IBM products that use Carbon represent a coherent design language. Something that exists across mediums because it’s grounded in something universal.

That’s not the norm.

Brand guidelines evolved from print and campaign logic. Design systems evolved from digital product delivery logic. They haven’t evolved toward each other. Customers are the ones who absorb the incoherence.

This might have been manageable when product moved relatively slowly. Misalignment can be addressed (...or ignored!). Brand drift was visible enough for someone to notice before it compounds too much.

The faster delivery accelerates, the more difficult it is to manage. And we’re at the point of AI driving acceleration so that delivery might become almost incomprehensibly fast.

The models that let us ship in days instead of months will be generating interfaces, copy, and variations at a scale no brand team has ever accounted for. AI will drift because it has no context for what that brand is.

Design systems that carry genuine brand meaning - not just coherent visual rules, but the reasoning behind them - will compound in the right direction. Design systems that are sophisticated token libraries and nothing more will produce brand-incoherent experiences. Faster, and at greater volume, than before.

The AI case makes the structural fix urgent. But it was already necessary.

The product has been the brand for years.

The org chart just hasn’t caught up.

Further reading:

• Weidemann, V (PhD). The Unspoken Tension: Product vs. Marketing — Why We Still Don’t Speak the Same Language. Medium, May 2025.

• Why do product and brand need to be developed together? GreyGekko, Apr 2026.

Article photo by naeim jafari on Unsplash.

That’s shifted.

I interact with my computer almost entirely through conversation now. Not novelty. Not occasionally. It’s the primary mode.

I describe what I want in plain language. Despite the discomfort I mentioned in an essay a few weeks ago, I increasingly do so through voice as well as keyboard. Things get built. Files get created. Plans are written. Code is built. Systems get modified.

And then I look at what was made and decide whether it was right, or how to modify it. And we chat some more.

I don’t think I’m alone. In my circles, at least, feels like more people are operating this way. Directing tools through text and conversation, not clicking through interfaces that hold your hand.

GUIs didn’t disappear. But for a growing number of people they’re something you produce for others. They’re not where I operate from.

One of these things is not like the other

Conversational interfaces are the mechanic.

What’s underneath that interface is not all the same.

I use Claude in a chat window. I use Claude Code in the terminal. In both cases I type, something responds, I evaluate the output. We have a conversation. The interaction pattern is recognizable across both of them.

Claude Code has system access. It writes files. It runs commands. It asks my permission to modify things. And if I say “yes, do that”, I’m not just approving the generation of a document. I’m approving an operation on my own system.

The “yes” can feel similar in Claude.ai as it does in Claude Code. The blast radius is not.

Approving an operation in a chat window isn’t the same as approving a system permission in a dialog box. And on one level we know that.

But there’s an older, visceral aspect to this. Conversation triggers social trust.

We trust things that communicate like people.

When Claude asks me ever-so-nicely whether it can have bash access, a part of my brain processes that like a colleague asking me for a favor. Not just a root access prompt.

When it’s just a dialog, I can dismiss it. When it’s a colleague, I can’t dismiss them.

Claude Code is genuinely the most capable thing I’ve used for building. That capability is the point. It’s exciting. But the same quality that makes it feel trustworthy - it’s fluent, reasonable, amenable - is exactly what makes the trust worth examining.

What’s going on?

OK, let’s think about the first part first. Before we get cautious.

It’s really fucking cool that you can chat with your computer. Like actually chat to it, in ordinary language, and have it do useful stuff.

That’s new. That’s sci-fi made real for a lot of us. A genuine shift in how humans relate to machines. Maybe the biggest shift in interaction since the invention of the mouse and the window.

For all my life, computers needed me to learn their language to communicate. Commands, syntax, interfaces. So that the machine could parse it. We adapted to that tool.

Now...the tool adapts to me. It’s not perfect. It’s inconsistent. But so are people. At a very fundamental level, I think the direction of translation has reversed.

That’s not trivial. It’s not Clippy. It’s not a better search box.

It’s different.

But there’s a question worth asking. I don’t have a clean answer to it yet.

What does it mean to approve operations that you don’t fully see? What does it mean to let something that feels like a real conversation make changes to systems that actually matter? How much do we care how the thing was built, if we ask for something and our agent makes it work?

We haven’t built the intuition to deal with that yet.

I think the interface arrived well before our instincts have had time to adjust.

Further reading:

• Gibbons, S, et al. The 4 Degrees of Anthropomorphism of Generative AI. NN/Group, Oct 2023

• Milano, B. Your chatbot may be the friend that isn’t. Harvard Law Today, Oct 2025.

• Numan, G. Are ‘Friends’ Electric? Youtube (official), Jan 2020.

We have an MCP.

We have an MCP.

We have an MCP.

Procurement teams talk about it as a qualifying feature. The word itself is talked about as if it’s a feature.

It isn’t one.

I have an MCP. It has a cloud-based instance. You can hit it right now. It’ll pass all your tests. It’s fully compliant with MCP Inspector. Integrate it with any client.

It returns an empty object on every call. It has a zero toolset.

It’s useless. I built it as a thought experiment.

Because an MCP server is not a product. It’s a protocol.

A really useful protocol. One that this industry has converged on with exceptional speed.

But a protocol is a contract about how things plug into other things. It says nothing about what’s being plugged in. The protocol is an invitation, but if you accept it then you should have something to say.

The MCP protocol doesn’t ask where the data comes from. It doesn’t say anything about what to do if sources contradict. It doesn’t say if its payload is authoritative or based on junk.

None of that is in the MCP spec. None of it has to be true to ship an MCP. But those are the only things that matter about whether that MCP is worth connecting to.

Having an MCP isn’t that much different from saying you have a GitHub repo. It can be empty, it can be filled with junk, it can be filled with excellence.

I’ve argued at Knapsack to de-emphasize our MCP in our conversations.

The moment the term gets into the conversation, you get stuck in a comparative argument. A buyer can say “So does Storybook. So does Figma. What’s special about you having an MCP?”

At Knapsack I’ve been watching our IPE reconcile parallel implementations of a component, and surfacing where the disagreements are. Figuring out how sources coexist when they contradict. Normalizing those intakes into a consistent design system schema.

That’s the kind of work that’s valuable. We can serve that work through a protocol. But the protocol doesn’t have any opinions.

Products do.

Further reading:

• compliant-empty-mcp on GitHub.

• What is the Model Context Protocol?

Article photo by Craftsman Concrete Floors on Unsplash.

A rutter was a small black book containing the detailed observation of a pilot who had been there before. It recorded magnetic compass courses between ports and capes, headlands and channels. It noted the sounding and depths and color of the water and the nature of the seabed. It set down the how we got there and how we got back.

But he adds something important to that description.

But a rutter was only as good as the pilot who wrote it, the scribe who hand-copied it, the very rare printer who printed it, or the scholar who translated it. A rutter could therefore contain errors. Even deliberate ones. A pilot never knew for certain until he had been there himself. At least once.

The Dutch understood this. They built better rutters. And they kept them secret. A library of the best routes to India, China, Japan, and the East Indies.

Maps they denied existed.

In 1611, Hendrik Brouwer charted a route between the Cape of Good Hope and Java that cut the voyage from a year to six months.

Their rivals sailed the same oceans. The Dutch got there in half the time, carried twice the cargo. And nobody outside the Dutch East India company knew exactly how.

That’s more than navigation. That’s a competitive moat.

People are starting to realize that AI compounds what you feed it. Design systems, patterns, decisions - it produces at scale and speed that would have been inconceivable three years ago.

AI doesn’t know what context is worth compounding and what isn’t. Whatever you give it, it will amplify. Documented decisions and undocumented drift. Authoritative tokens, and a Figma file out of date with production. Enforced constraints, and those in one engineer’s institutional memory. All of it goes in.

Good context will compound into coherence at scale. Bad context into confident, fast-moving inconsistency. The AI isn’t lost, it’s just following charts that are wrong.

A rutter was only as good as the pilot who wrote it...

Most organizations haven’t verified theirs even once.

A rutter wasn’t a single source. Historical rutters were compiled from multiple voyages, multiple pilots. Sometimes conflicting observations.

The value wasn’t just having the information. It was knowing which accounts to trust when they disagreed. The 1589 observation or the 1612 one. The pilot who navigated this strait in summer, versus the one in winter. The hint that was a lie.

Your product context is the same problem. Design system, yes. But brand guidelines, Figma libraries, components, content strategy, regulatory environment. Institutional memory about why one pattern exists and what happens if you overlook it. And the sources don’t always agree, so how does the AI navigate?

Organizations that integrate, orchestrate, and prioritize those sources - they’re building rutters. Every decision made is another voyage in the record. Every conflict resolution is a note to avoid a reef. Generation cycles that feed back into the system to make the next one more reliable.

It’s compounding advantage. Your competitors all have access to the same models. For all their genius, they’re commodities. But accumulated product knowledge, integrated, adjudicated, tells AI what right looks like for you. It’s the rutter your organization built, deliberately or not, for as long as you’ve been making decisions and writing them down. Its compounding nature means the earlier you build it, the harder it is to catch up.

The Dutch didn’t win the spice trade because their ships were faster. They won by taking the navigational system they built into proprietary, compounding knowledge. Then they protected that fiercely.

Same ocean. Same models.

You know what the difference was.

Further reading:

• Clavell, J. Shōgun. Hodder & Stoughton, 1975.

• Bruijn, J. R. Between Batavia and the Cape: Shipping Patterns of the Dutch East India Company. Journal of South East Asian Studies, Sept 1980.

Article photo by Gene Brutty on Unsplash.

I was out. Had my phone in my hand. And wanted to run a competitive analysis to see how Knapsack was addressing the market issue raised in an article I’d just read. Everything I needed was in my cpo-skills suite. Context, background data sources, routing tables to know which command to pull for which task.

All sitting in my vault. Perfectly organized. Inaccessible to me.

Because Claude Code lives in my CLI. My CLI lives on my laptop. My laptop was at home.

Claude.ai was right there. And it had far less that could help me.

It made me take a closer look at what claude.ai skills could do. My assumption - skills are prompts. A few hundred words providing context, available to trigger. Useful for tasks. But a long way from the depth I’d built in Claude Code.

I’ve built for depth. My cpo-skills suite has ten discrete command files, a delivery pipeline context document, and utilizes my specialized data-gathering agents wired to Linear, Slack, Github, etc. My thought-leadership suite carries its own context file - posting cadences, metrics, content pillars, conferences I’m tracking.

When Claude Code triggers these, that’s more than a prompt. It’s loading a working system.

But I realized that a claude.ai skill can be a gateway to that same system. On trigger, instead of containing all the intelligence itself, it instructs Claude to fetch it. It reads the README from my vault, loads the context file, consults the routing table, and pulls the specific command for the task at hand.

The files live in GitHub. Claude fetches them directly during the session. The skill in claude.ai is the key. The vault on GitHub is the room it opens.

My cpo-skills and thought-leadership skills in my Claude.ai project work in exactly this way. Each one is a few dozen lines. When I trigger the skill, it expands into the full suite I built in Claude Code. That’s context, routing logic, specialized commands, and in some cases an agent. All also available in that GitHub vault.

If you’re working in claude.ai you see a simple skill with a clear description. What runs is everything in the vault, accessed remotely.

This matters beyond just my own workflow. Claude Code solves for depth. That’s complex, stateful, multi-step work with persistent context. Claude.ai solves for accessibility. No terminal, no config files, far lower technical barrier.

The bridging pattern doesn’t collapse the distinction. The complexity stays in the vault, versioned and maintainable. The interface stays simple.

The person who builds the vault and the person who opens the door don’t have to be the same.

Further reading:

• Salcan, Y. E. Claude vs Claude Code vs Cowork — Which One Do You Actually Need? Medium article, Feb 2026

Article photo by Alla Bila on Unsplash.

Not translated.

Not approximated.

Not handed off from one side and reconstructed on the other.

The same thing.

Our industry has been trying to build that for thirty years. We’ve gone from building bad versions of the right thing to building good versions of the wrong thing.

The jokes wrote themselves. Dreamweaver sites. FrontPage sites. If you were of a certain rebellious bent, HotDog sites.

These used to be mocked because they were the telltale sign of someone who didn’t really know what they were doing. Table-based layouts, inline styles, spaghetti markup so bloated that any developer would want to quietly rebuild the whole thing from scratch instead of fix it.

They were also empowering tools for a lot of people. They let you make stuff that was real. They weren’t being mocked because they were trying to unify the visual and the functional in a single interface. That instinct was right. They were mocked because of how much they corrupted the code side of the equation.

The canvas was easy to navigate.

The code output was garbage.

So industry corrected. Realistically, given the technical limitations. Built an organizational culture around the separation of disciplines.

Serious designers used serious design tools.

Serious developers wrote serious code.

And between them a handoff ritual grew - redlines, specs, prototypes, tickets.

We created a workaround dressed up as a workflow.

The separation is artificial. We’ve always known this to some extent. Design systems were an obvious admission. Design intent encoded as structured, reusable truth rather than redrawn from scratch on every new screen. Tokens, components, semantic definitions; shared language that both sides could read. I’ve often joked that the irony of the name “design system” is that its primary consumers are usually developers.

AI closes the remaining distance. When structured design context can be interpreted directly into working interfaces, the translation layer becomes unnecessary. The middle dissolves, and the destination comes into view.

It’s why I find these code-to-canvas offerings so strange. Code-to-canvas takes a working interface - real interactions, data, behavior - and converts it back into static frames.

It argues that collaboration is only possible on drawings of the real thing, not the real thing itself.

Dreamweaver and FrontPage, for all their failures, at least understood where they needed to go. The visual and the functional needed to live together. They just didn’t have the technology to make their ambition real. The code they generated was the limitation, not the vision.

You can forgive a tool for being ahead of its time. But the technology exists now to make the canvas genuinely real - connected, live, executable. And it’s harder to forgive a deliberate turn away than a premature attempt at the right destination.

Our destination hasn’t changed. A canvas as a live interface into the system. The real thing made navigable, editable, collaborative. We’ve known that’s where we were going for a long time.

Surely this time.

Further reading

• The digital workflow is obsolete, on the collapse of the handoff model.

• Code to canvas is bonkers, on Figma’s specific wrong turn.

• FrontPage vs DreamWeaver. Webmaster World.com discussion thread, July 2003.

• Smith, E. Your Code is Junky. Tedium, March 2017.

Article photo by Daniel McCullough on Unsplash.

You can read the system’s philosophy in how the tokens are organized.

The tokens aren’t what made the system work. The convictions are what made it work. The design tokens were an artifact of that conviction.

That distinction is the argument.

The W3C Design Tokens Community Group published its first stable spec at the end of 2025. It’s genuinely good work. Years of collaboration to solve a hard coordination problem. How to share design decisions without everything fracturing every time someone changes a color.

The spec is deliberately minimal. It defines tokens, their types, and a reference system that lets one token point to another — so color.text.primary can reference color.palette.black, and changing the palette propagates everywhere. It adds $extends for group inheritance, a Color module with modern color space support, and a Resolver module for theming and context.

It’s a sensible, focused infrastructure that solves real problems. It’s the kind of foundation that would underpin exactly the discipline Anna built at IBM.

What practitioners have built around that foundation is something else.

The spec is agnostic about tiers. It defines how to express token relationships, not how many layers you should have.

The community is far less agnostic. Three-tier has become doctrine: primitive tokens at the base, semantic tokens that make purposeful claims about use, component tokens scoped to specific components. This is “mature token architecture” in most design systems discourse.

The gap between doctrine and practice is instructive.

Three-tier is what gets taught and recommended. Two tiers is what the major systems actually implement.

Carbon’s architecture doesn’t map neatly onto the primitive/semantic/component model - it has its own layering logic built around UI depth. Polaris has moved away from its component token layer. Material Design 3 publishes reference tokens and system tokens, and stops there.

Three-tier is the aspiration. Two-tier is what survives contact with a real system.

That gap should be a signal. The canonical systems couldn’t fully sustain the doctrine. And yet the doctrine keeps getting taught as the definition of maturity.

The problem isn’t the spec.

The spec - unavoidably - creates a thing to make. “We’re implementing the W3C spec” can start to feel like a north star, when a real north star is missing.

At J.P. Morgan there was always a tension between a debate on token naming strategy and architecture coming before a simpler question was answered: what is this design system for?

Naming debates aren’t a path to that clarity. They can be a replacement for it.

For Anna at IBM, the tokens were downstream. Philosophy came first. Tokens encoded the philosophy.

Where I’ve seen more struggle - at JPM, at some of the design systems I’ve worked with at Knapsack - is when that order is inverted. Taxonomy comes first, the thinking is supposed to emerge from it. Sometimes it does. Often the taxonomy becomes the only explicit structure of the system, and so it becomes load-bearing.

Which leads to a design system whose deepest held opinion is how to name its hover state.

Run naming conventions workshops because mature systems have naming conventions. Produce token JSON because good systems produce token JSON. That’s a cargo cult pattern. The mechanism becomes the mission.

There is a failure mode you can identify: token counts scaling linearly with component complexity.

The Tetrisly design system acknowledged this problem. Their button component reached over 500 tokens. It enumerated every property of every state of every variant: background, border, text, icon, default, hover, focus, active, disabled, primary, secondary, danger, ghost, large, medium, small, dark mode, high contrast.

Before long you end up with button-background-color-primary-large-hover-dark, and hundreds of siblings.

The spec supports this. But at this point the abstraction provides no value over well-organized CSS. The overhead is real: tooling dependency, Figma sync, governance process. But there’s no additional leverage when your variable names map one-to-one to CSS properties you have to write anyway.

The promise of tokens is leverage - fewer, powerful constructs that express more than just flat specifics. 500 tokens is a clear failure of that promise - you may as well be writing CSS. Tetrisly acknowledged this, and they’ve very deliberately thinned their “component tier” so their model is much closer to a two-tier than three-tier model.

Phillip Lovelace recently argued that tokens are even more important in an AI-driven workflow - token taxonomy can be an API the AI agent consumes. Semantic naming lets AI stop guessing your brand.

This is a worthwhile floor argument. AI generating UI from a token file produces more consistent output than generating from nothing. The W3C spec makes that even more reliable.

A floor isn’t a ceiling.

AI can traverse a token graph and resolve a name to a hex value. It can’t tell you why that color is right for a primary hover state, or if a destructive action should use the same token. Should a payment confirmation defer to stricter contrast constraints?

Those aren’t AI limitations.

Those are limitations of the information that tokens are supposed to carry.

Tokens encode what things look like. Not why. Not when. Not the conditions that change the answer.

The convictions in the best systems come from the decisions that precede them. An AI with access to those decisions - rules, intent, context - can do more interesting things than resolve color aliases.

Tight token architecture delivers real value. Tokens are a powerful artifact of thinking, but not a substitute for it. The W3C spec describes something of genuine worth, when it’s built in the right order.

The design systems that work treat tokens as output. Philosophy first, constraints second, governance third. Tokens encode the decisions that have been made. But only if those decisions have been made.

Systems that struggle have the sequence backwards. And the quality of the spec actually makes the inversion easier. It’s a rigorous blueprint for the mechanism, and the foundation is left implicit.

Tokens with system conviction are infrastructure. Tokens that substitute for it are dogma. The difference is everything.

Further reading:

• Frost, B. The Many Faces of Themeable Design Systems. bradfrost.com

• Gonzales, A. Introducing Figma variables and a consolidated “All themes” library! Carbon Design Blog, Aug 2023.

• Design Tokens Technical Reports. W3C Community Group, Oct 2025.

• Lovelace, P. Design Systems Are Having Their Moment. Design Systems Collective, Feb 2026.

Article photo by Jan Canty on Unsplash.

Her argument is that paid design system documentation platforms like Zeroheight are obsolete. Figma’s API is accessible. LLMs can write docs. Open-source tooling is good. Build the whole thing yourself, in two weeks, for free.

It’s a practical guide. It has sound tooling advice.

The piece treats design system documentation like it’s an asset display problem. How do you surface your Figma components and code repos in one place, more cheaply than current products offer? That’s a reasonable question.

But it’s based on a definition of design systems that I think is fundamentally too shallow. That’s a starting point that leads to something that looks like a solution, but isn’t.

The article describes documentation as an “aggregator - the one place that ties everything together.”

Sit with that word.

An aggregator is passive. It collects. It displays. It points at sources and renders them side by side.

A design system isn’t an aggregator.

It’s a contract.

A design system is the authoritative agreement between disciplines - design, engineering, product - about what is true, what is intentional, and why. Documentation doesn’t just display agreement, it’s where that agreement becomes canonical. Intent becomes instruction. “We discussed this on Slack” becomes “this is how we build things.”

If your docs platform is a viewer on top of your Figma files and your code repos, that’s not a system of record. It’s a window. It doesn’t resolve disagreements.

A DIY doesn’t solve one, vital problem - and the article doesn’t name it.

Figma is not a design system.

Storybook is not a design system.

Figma is a tool for designers. Their working files, experiments, intentions, abandoned interations. A designer’s environment - rich and full of things in-progress, deprecated, aspirational.

Storybook is a tool primarily for developers. It documents what has been implemented. It’s the engineering team’s environment - authoritative about code, somewhat indifferent to design rationale.

If you point an AI agent at your Figma library you’ll train it on your designers’ hypotheses. Point it at your Storybook and you train it on engineering implementation that may lag design intent, exceed it, or quietly diverge.

Neither tool can answer the question on its own: what is true?

When the Button component in Figma has rounded corners and the one in Storybook doesn’t, what does your documentation site say? If it just faithfully renders both sources, it’s documented your misalignment.

That’s not nothing. It’s useful to know. But it’s not a source of truth. It’s published disagreement.

The design system has to adjudicate. It has to carry a philosophical underpinning. A stance. Not just visual and technical inventory. It needs the decisions and reasoning that make the inventory coherent. Why did we make these choices? What are the governing principles? Which source wins when there’s a discrepancy? Why?

And how do we strive for excellence when there isn’t a source at all? A new pattern, an edge case, a platform you haven’t built for yet. The system of record doesn’t just arbitrate what exists. It also guides what should.

That’s not something that can be generated. It requires human judgment, authority, and a platform to enforce it.

The article’s AI-readiness argument is sharp. And it’s where the initial error becomes most consequential.

The article is right to identify that design system documentation is increasingly an instruction layer for AI agents. “Robot food” as my colleague Chris Bloom would describe it. The context that makes generated UI consistent and correct. And it’s also right that static platforms unable to expose data in a structured, machine-readable way, fail at this job.

So it proposes replacing them with Docusaurus and MDX files maintained by a team. Which is also static. And manually curated. But it’s free and you own it.

But the answer to AI-readiness isn’t just a better documentation site. It’s a genuine system of record. Where documentation is generated from structured, authoritative, interconnected sources. Where the connection between intent and implementation is dynamic, not periodically reconciled.

Documentation that auto-updates when code changes isn’t a feature. It’s the entire point.

But it needs to have broader context to update in an intelligent, guided, way.

Otherwise you’re just feeding AI a snapshot. A snapshot of what was true when someone last updated a file. Or a snapshot of the AI’s guess at what a conflict resolution was. And the gap between “what the docs say”, “what the design file says” and “what is in production” is exactly the kind of ambiguity that makes AI-generated interfaces drift.

The cost argument also dissolves.

The article compares platform licensing fees to zero.

But the real cost of a design system isn’t tooling. It’s the misalignment it prevents - or fails to prevent.

That’s the denominator.

The cost of rework because design and engineering interpreted a component differently. Cost of multiple QA cycles because the implementation didn’t match the spec. Cost of onboarding time because the documentation was out of date. Cost of inconsistent experiences because there wasn’t an authoritative answer to “how does this pattern work in iOS?”

The total cost of a DIY aggregator includes engineering time to build it, maintain it, update it when APIs change, wrangle the AI writing pipeline, manually curate the output. And, if it’s being seen as an aggregator, it includes the organizational cost of having a documentation site that’s a collection of assets rather than a system of authority.

That cost might seem invisible. Then it accumulates.

None of this is an argument against open-source tooling. Or AI-assisted documentation. Or against genuine improvements in what’s accessible and buildable. Those are real changes.

Infrastructure isn’t neutral.

The choice of what you build - aggregation layer or system of record - has downstream consequences for every discipline that depends on it. It shapes what designers trust. What engineers implement. What AI agents consume. What your product becomes.

If self-building (not merely aggregating) your design system platform is the right approach, and the costs and benefits are fully considered, great. That’s IBM Carbon, and it’s one of the best design system websites out there.

And if a documentation platform can make the building of the site easier, so you can focus on the creation of the actual design system, all the better.

Design systems are not a collection of Figma components and Storybook stories, with a documentation site sitting on top. The documentation is the surface expression of something much deeper and more considered.

Decisions made. Rationale captured. Authority established.

You can build an aggregator in two weeks. Building a system of record takes longer. Because you have to decide what’s actually true.

That’s the work.

I’m not a neutral observer.

I’m VP of Product at Knapsack. We build infrastructure that makes design systems a live system of record - connecting design, code, and documentation as a unified source of truth.

I have a direct interest in this question, and you should read with that in mind. But the argument stands regardless.

Further reading:

• Rita, M. Stop paying for design system documentation you can build yourself. All about design systems, Feb 2026.

• Aizlewood, J. Design systems don’t start with components. Clearleft, July 2017.

Article photo by Lewis Keegan on Unsplash.

Let’s break that down. You use an AI coding tool to generate a working interface. Real code, real interactions, and real data. Then take the functioning reality and convert it back into a static abstraction, so that people can look at it together on that canvas.

You had a building. Now you have an architect’s drawing of that building.

Figma is telling you this is progress. It isn’t. It’s a solution to Figma’s business problem - the growing irrelevance of the static canvas - presented as though it’s a solution to yours.

In November I wrote about the collapse of the traditional digital workflow. That comfortable fiction where design happens here, code happens over there, and a handoff ritual connects the two.

AI is dissolving that middle layer. Structured design systems, and wider product context, can be interpreted into working interfaces. At that point, the abstraction layer between design intent and delivery reality becomes unnecessary. Design isn’t a stage before delivery. Design is delivery.

It’s a defining shift in how products get built.

Jonny Burch made a complementary argument last week, in his piece “Life After Figma is Coming.” His framing encompasses the tooling ecosystem: as code becomes the source of truth, design tools become interfaces on code, not the other way around. Code is the only correct source of truth - open, shared, with common standards. The canvas doesn’t disappear, but it has to become a view into reality and not a substitute for it.

These arguments point in the same direction. The canvas is no longer a staging ground for ideas that exist outside the system. It needs to be a live interface for ideas that exist within it.

Claude Code to Figma points in the opposite direction entirely.

Field’s own framing is revealing. He describes working code as “tunnel vision” and that this feature will help you “escape” it.

…the design canvas is better at navigating lots of possibilities than prompting in an IDE.

The Figma blog announcing the Claude Code to Figma feature elaborates further. Solo code exploration is a “single-player environment”.

…that speed of solo exploration can become a constraint.

And as a contrast, they describe the canvas as a “shared space” where “the conversation changes and new possibilities open up.”

That’s a neat rhetorical move.

It takes a genuine limitation of current code-first workflows - collaboration and visual comparison are harder in a terminal - but reframes it so that the working artifact is the problem, and the abstraction is the solution.

Those are not the same thing. Needing better collaboration on working artifacts isn’t the same as needing to convert the artifacts into a different, lower-fidelity format in order to collaborate at all.

The answer to “how do we collaborate on code?” is not “convert it to not-code.”

The better solution is better collaboration tooling for code. Live preview sharing. Annotation layers on running applications. Structured feedback on deployed states. As Burch points out, a tooling ecosystem is already exploding in size - design interfaces that sit on top of production code, development environments that integrate design thinking. The pieces are coming together.

When you capture something from Claude Code and bring it into Figma you don’t add information. You remove it. You remove interactions, real data, actual behavior. You replace it with a picture of what it looked like at the moment of capture.

That’s trading truth for convenience, and claiming it’s a workflow improvement.

It’s an absurd proposition.

You have a working thing. You convert it into a non-working representation. You collaborate on the representation. At some point, presumably, someone has to make into a working thing again. That’s not a workflow, that’s a detour.

This is not just a feature decision. It’s a strategic posture that serves Figma’s interests while actively working against the interests of people using it.

Figma’s business depends on it being the place where product decisions happen. Their value proposition is the collaborative canvas being the hub of product development. The more decisions happen in code-first environments - engineers and designers collaborating directly on running applications - the more Figma risks becoming peripheral.

Figma is trying to maintain its gravitational pull. Every feature needs to bring work into Figma, not enable work to happen outside it.

Field says this directly:

Whether product building begins in a terminal, a prompt box, a visual UI or a hand-drawn sketch, we want Figma to be the place where it all comes together.

That’s not a workflow insight. That’s a business objective.

Claude Code to Figma is not about improving your workflow. It’s about preventing your workflow from leaving Figma behind.

And this is the part of the framing that I find genuinely dishonest. Figma’s blog post presents this as a way to unlock creativity and open up collaboration. Something to liberate teams from the constraints of solo code exploration. But the people who are using Claude Code to build working interfaces aren’t constrained. They are ahead. They have the real thing. The feature asks them to go backwards. Sacrifice fidelity, leave something functional and return to an abstraction layer. Because Figma needs them to.

That’s a solution for Figma. It’s not a solution for the people building products.

The timing might reinforce the point. Figma went public, and the stock has dropped a lot since IPO. It’s a legitimate question whether AI-native tools make traditional design canvas less central to digital product development. So product announcements also need to be a message to investors: the canvas is still essential.

Code-to-canvas is a defensive move dressed up as innovation.

The honest version of this feature announcement might say: “More product work is starting in code. We need to pull that back into our ecosystem so we can remain relevant.” That’s a legitimate business challenge. And I have sympathy for the difficulty of Figma’s position. They built something genuinely great, and the ground is shifting beneath it.

But don’t tell me it’s for my benefit. The loss of fidelity isn’t “opening up new possibilities.” A functioning prototype being flattened into a picture isn’t “changing the conversation”. The conversation was already happening - and in a richer, more honest medium. This feature interrupts the conversation to bring it back to Figma.

It’s not about fewer canvases. It’s about more honest ones. More real. Connected to live systems, reflecting real state. Enabling collaboration on the actual artifact rather than a simulation. The future of the canvas is as an interface to code, not a destination to convert code back to.

Code to canvas is the wrong direction. The future is canvas as code. Features like this are going to look increasingly strange as the rest of industry figures that out.

I’m not a neutral observer.

I’m VP of Product at Knapsack. We’re building in the place where structured design systems and product context meet AI-driven delivery.

But the proximity is also why this absurd code-to-canvas direction is so acute for me. When you’re working on systems that make design directly executable, watching someone propose converting execution back into abstraction feels like someone printing out a Google Doc so that they can fax it.

I'm presenting an expanded version of these ideas at the Great International Developer Summit in April 2026.

Further reading:

• The digital workflow is obsolete - the end of abstraction, and the start of design as delivery.

• Burch, J. Life after Figma is coming (and it will be glorious). jonnyburch.com, Feb 2026.

• Seiz, G. & Kern, A. From Claude Code to Figma: Turning production code into editable Figma designs. Shortcut - Figma’s editorial newsletter, Feb 2026.

• Field, D. Claude Code to Figma Design. LinkedIn, Feb 2026.

• Flowers, E. If you ask a designer what they want, they will say faster horses. Zero Vector, Feb 2026.

Article photo by Rob Martin on Unsplash.