We’re moving from Design Systems to Inference Systems. There are three shifts I’ll walk through. Patterns become parameters. Documentation becomes context. Governance becomes feedback loops. Each one rewires a different part of how the system works, and together they change the system purpose.

Patterns to parameters

Traditional design systems define patterns: a modal looks like this, primary button uses these tokens, and this form field follows this spacing rhythm. it documents the constructs to build components with fixed values. Design teams were built to assemble those components into screens in a prescriptive process.

That stability is what’s changing along with the definition of consistency. A user in an agentic experience might start in a chat thread, have the agent surface a comparison table mid-conversation, drop into a focused task view, and end with a voice summary on their phone. None of those surfaces existed as a designed artifact when the interaction started. The agent assembled them on the fly based on what the moment required.

Most of the patterns defined in the Blitzscaling era don’t survive that context. They assume a designer chose the layout, that the layout is stable for the duration of the task, and that the user’s input modality is roughly fixed. Agentic experiences break all three assumptions. Interactions are now multi-modal and new affordances such as streaming responses, interruptible flows, ambient confirmations don’t have a 2018 equivalent to copy from.

The shift is from defining values to parameters. A pattern of values says “the modal is 480px wide with 24px of padding based on these variables.” A parameter says, “the modal expresses focused attention in a transient surface; its width compresses when the surrounding context is dense and expands when the user is committing to a multi-step task.” Setting parameteres is a behavior the system can apply in conditions the original designer never anticipated.

The Inference System doesn’t care what the modal looks like but the insights to know when to invent something the library doesn’t contain at all.

Documentation to context

Design system documentation today is written for humans. The usage guidelines include values, UI Kits, code samples, and a list of do’s and don’ts. LLMs don’t need to scan a Storybook page and parses the structure. It benefits from the rule that produced the placement.

Years of design system work have gone making the guidelines digestable for humans; often a huge effort to maintain. This is where design tokens become something more than a convenience. A traditional token stores a value: --color-primary: #0066FF. An inference-ready token stores intent: --color-interactive-primary, with semantic meaning, usage rules, contrast requirements, and relationships to adjacent tokens. The first tells you what color to use. The second tells you why — and why is what a model can reason about. A model that knows interactive-primary is for “the most prominent action in a given context” can make a defensible choice in a layout it has never seen before. A model that only knows #0066FF can only match.

MCP servers are an early signal of this shift. When an agent inspects a Figma frame through MCP, the server hands it structured context: the components in use, their variant properties, the variables they consume, the styles applied. The agent receives the design as data, in the same way a developer receives an API response. Google Stitch’s design.md file gestures at the same idea from a different angle: a single file describing a product’s design intent in a format a model can read end-to-end.

The pattern across these examples is the same. The artifact a designer produces is becoming an interface that talks to two audiences at once. Humans still need the screenshots and the prose. Models need the structure underneath. User Experience is now human and agent. The systems that thrive will treat both as first-class outputs of the same source, not one as a translation of the other.

Governance to feedback loops

Design system governance has traditionally been a review process. Did you use the right component? Is this on-brand? Does this follow the spacing guidelines? Someone on the design systems team checks the work, flags deviations, and asks the team to bring their PR back into compliance. It’s quality control through human oversight, and it works at human scale.

This model breaks at agentic scale. When an agent generates a layout, then revises it twelve seconds later in response to a user’s follow-up, then generates a different layout for the next user with slightly different context, the volume of “design decisions” being made per day jumps by orders of magnitude. There is no version of the design systems team that reviews each one. Even if there were, the review would arrive too late to matter.

Inference systems need a different model. The system itself has to evaluate conformance as the work is being produced, and more importantly, it has to learn from what gets built. This is where “inference” becomes literal. The system doesn’t just hand the agent a rulebook. It watches what the agent (and the humans alongside it) actually ship, and updates its own understanding of the product accordingly.

The most important reframe is what to do with deviation. In the old model, a deviation is viewed as a mistake to fix. The team failed to use the prescribed component and the fix is to bring them back into line. In an Inference System, a single deviation is still probably a mistake. But fourteen teams independently building the same off-system component is no longer a governance failure. It’s a signal that the system is behind its users.

The question is which is the mistake, the governed decision or the deviation?

Sometimes the answer is the deviation, and the system holds. Sometimes the answer is the governed decision, and the deviation is showing you where the system needs to evolve. The job of the systems designer shifts from enforcing the first answer to investigating the second.

This is what I mean by governance becoming legacy. Not that quality control disappears, but that the locus of quality moves from a checkpoint at the end of the process to a feedback loop running underneath it. Deviations stop being “don’ts” and start being data. The system stops being a wall and starts being a sensor.

How execution is reframed

The three shifts above all converge on a single change in what a design system is. It stops being reference material and is contextual material. The artifact a designer produces is no longer a thing the agent looks up; it’s the substrate the agent thinks in.

This is not a concept I claim to invent rather capturing something that’s already happening across the industry. Airbnb has been classifying its 150+ components with ML so that AI tools can assemble prototypes from user behavior rather than from a designer’s blank canvas. The design system isn’t a passive reference the team consults — it’s the infrastructure the AI builds on top of. Brad Frost, one of the people who shaped what design systems became in the first place, has been writing about an agentic design system framework that treats the system as something an agent operates within rather than something a human reads. Google Stitch shipped a design.md convention; a model-readable file describing a product’s design intent end-to-end.

None of these teams are doing the same thing, and that’s the point. There isn’t a settled pattern yet. What they share is the underlying move: treating the design system as the model’s understanding of the product, not as a catalog the model consults.

That’s the reframe. Adoption, the metric that defined design system success for the last decade, measured how many teams used the components you shipped. Adaption measures how well the system evolves in response to what those teams (and their agents) actually build.

The system’s new purpose

We’re going from adoption to adaption.

Adoption has been the standard metric of design system success for as long as the discipline has existed. How many teams use the buttons you ship? How many screens are built from canonical components? How much of the product surface is on-system? Those numbers matter, and they’re not going away. Scaling consistency through re-usable design and code is still the foundation, and any team that abandons it in pursuit of something shinier will regret it within a quarter.

Adoption is no longer enough of a metric on its own, and Adaption sits on top of it. While Adoption is important to know how widely the system is used, Adaption allows us to understand the evolution of the system.

In an Inference System, prototypes are data varying from a static HTML exploration, a branch of code experiments, a design file built outside the canonical components. These are not sins of the system but signals of what needs to grow.

What this looks like is various levels of prototypes become first-class context. It’s a mistake to think every single prototype created needs to go to production. It defeats the purpose of rapid prototyping, where the insight is the artifact. From these thousands of insights captured, the adaption of the system allows to bring in the collective intention of what to ship to production.

Design systems were never only about tokens and components. The goal was to codify decisions and scaling craft. It’s the decoder that’s changed, which for the past decade was a designer reading documentation. Now the decoder is a model parsing structure.

The teams who get this early will spend the next few years quietly rebuilding their design systems into something that looks less like a component catalog and more like the model's understanding of their product. Call it an Inference System if it's useful. The label matters less than the shift.

Hyperlinks + notes

• Towards Human-AI Synergy in UI Design: Leveraging LLMs for UI Generation with Intent Clarification and Alignment | arXiv

• Agentic Design Systems in 2026 | Brad Frost

• AI and Design Systems | Brad Frost

• The Next Era of Design is Intent-Driven | Vamsi Batchu, UX Collective

• AI Design Systems: Why Tokens, Schema & Generative Rules Matter Now | Medium

Let’s look at where areas are de-emphasized and what highlights the new focus area for leaders. Whether you’re in the craft of Growth, Design, Engineering, or Product, we’re all participating in the organizational re-write.

Areas collapsing

In order to know what the focus areas are for leaders in this new era, we must understand what might converge and collapse. This doesn’t mean what changes isn’t important. It means how it’s done and the emphasis changes.

Being the single point of direction and communication

If the majority of your scope was passing down communications from one person to another, you aren’t a leader. You are a line manager like those in production factories. Communication is important, but it’s more bi-directional than ever. With Retrieval and other AI techniques, it’s easier to get a sense of what is going on. I find myself talking to Rovo at work before I ask another human to see if I can get the information I need first.

The era of extreme ownership

Carola Pescio Canale, our leader on Rovo & AI, speaks to this being the time for extreme ownership for everyone. For individual contributors, there are a high expectation and opportunity for agency. The saying, “You can just do things” is not a stretch. The ways of working are going from reviewing proposals of what to fund to reviewing existing evidence to continually fund.

The focus areas for leaders

Upholding craft excellence
If you are a leader of a craft such as Engineering, it’s your primary responsibility to ensure the way the work is done and what gets shipped meets the highest bar possible. It’s always been important, and more important than ever, to manage the work.

The bar itself is moving. When generation is cheap, the scarce resource is taste: the ability to tell what’s actually good from what merely looks good. A team that ships twenty AI-generated components a day but can’t distinguish the two that belong in the product from the eighteen that don’t is not shipping faster. It’s accumulating debt faster. Craft leaders hold the line on that distinction.

Our skills are being re-applied with new capabilities and new tools. Leaders need to be on top of the newest innovations and tools in order to enable the team.

This means using the tools yourself, not just reading about them. A leader who hasn’t built something with the current generation of models is calibrating on stale data, and their sense of what’s hard, what’s trivial, and what’s genuinely novel will be wrong within a quarter. Being on top of the tools is no longer a research task delegated to the most curious IC on the team. It’s a core leadership practice, and it’s what lets you keep setting a credible bar for everyone else.

Clarity of purpose and vision
As software is being re-written and many companies are re-founding themselves, it is difficult to find clarity and stability in a time of much distraction.

Every week brings a new model, a new benchmark, a new competitor, a new framing of what the company should be. Each one feels urgent, and most of them are noise. The leader’s job is to absorb that volatility so the team doesn’t have to. When everything looks like a priority, nothing is, and teams start optimizing for the loudest signal in the room rather than the work that actually compounds.

The role of the leader remains important to ensure the purpose and vision are clear. With priorities changing, it is crucial to set a vision that is enduring through the changes. Leaders must double down on the vital few initiatives that will sustain the change.

A useful test: can your team articulate the vision without quoting you? If the answer is no, the vision isn’t enduring, it’s just recent. Endurance comes from repetition and from pruning. Saying yes to the vital few means saying no to the interesting many, and that work is almost entirely the leader’s to do. Nobody below you has the standing to kill a promising initiative, which is exactly why so many of them survive past their usefulness.

Oversee a portfolio of outcomes
Julie Zhuo said, “You are all managers now,” speaking to agent orchestration and interacting with the new tools. If everyone is now a manager, leaders oversee a portfolio of outcomes.

The unit of leadership work used to be the team. Now it’s the bet. A team is a stable structure you staff and grow over quarters. A bet is a thesis about where value might emerge, and it may need two people for six weeks or ten people for a year. Treating every initiative like a team leads to over-investment in things that should have stayed experiments, and under-investment in the ones that were ready to scale.

First, leaders are constantly placing new bets that don’t scale. This is one of the reasons 70% of my direct reports are individual contributors. The reason to keep things flatter than conventional orgs in the past is because priorities fluctuate in relationship to the bets.

A flatter org is a faster org when the bets are still forming. Layers exist to manage known work, and most of what matters right now isn’t known work yet. Keeping ICs close also means the signal from the frontier reaches you without being filtered through three rounds of synthesis, which is what you need when the ground is moving.

Portfolio management includes initiatives and vision horizons. Leaders have to consider what aspects of capabilities to scale and what to transform. The hardest calls are the ones about existing capabilities. Scaling something that works is satisfying and legible, but transformation is where the compounding happens, and it rarely looks like progress in the quarter you commit to it. A portfolio without at least one uncomfortable transformation bet is probably a portfolio that’s quietly optimizing for the last era.

Fostering ecosystems
As a system designer at heart, the ecosystems must be nurtured, and there are many of them. Leaders must understand the possible paths in partnerships. As products and businesses are being re-written, partnerships become non-deterministic themselves. The question of build or buy becomes asked more frequently in the assets needed for the company. This could be a strategic lever, capability, or talent.

The build-or-buy question used to be an annual exercise. Now it’s a monthly one, and sometimes a weekly one. A capability you would have spent a year developing internally might be available as an API next quarter, and a partner you integrated with this summer might be acquired by a competitor before the year ends. Leaders have to hold the map loosely and redraw it often. The skill is less about picking the right partner and more about structuring relationships that can absorb change without collapsing.

The second ecosystem to foster is what once was systems built for governance. They now need to be transformed into a new shape. Brands and Design Systems are examples of this. Governance systems were built to create consistency across a large surface area, and they worked by constraining what people could do. That logic breaks when the surface area is being generated faster than any central team can review. The new shape of these systems is closer to a substrate than a gate: a set of primitives, defaults, and signals that guide good decisions at the edges without requiring approval at the center. Brands and design systems that survive this transition will be the ones that trade control for leverage.

Recap

Leaders used to be the ones that held the clarity and consistency, but now they need to be more of a source of disruption. I wrote about my three leadership pillars, and conviction is more important than ever.

The instinct in uncertain times is to wait for more data. More data is not coming. The environment is producing signal faster than anyone can synthesize it, and the leaders who wait for clarity before committing will find themselves a year behind the ones who committed without it. Disruption from the top is not recklessness. It’s the recognition that standing still is itself a bet, and usually a losing one. Leaders will need to have the conviction to place bets in a time where there are very few answers or previous playbooks to draw from. This is, in fact, what leadership was to begin with.

The playbook era made leadership look like execution. It wasn’t. The playbooks were scaffolding built on top of earlier conviction, and we mistook the scaffolding for the work. What’s happening now is a return to the actual job: deciding what to do when nobody can tell you whether you’re right, and staying with that decision long enough to find out.

Hyperlinks + Notes

• How I Created OpenClaw, the Breakthrough AI Agent | Peter Steinberger | TED

• iPadOS Post–MacBook Neo

• Reluctantly Influential: Inside Lenny Rachitsky’s Demandingly Chill Life | First Round

By the time anyone sees Ultron, he’s already on version five. He was created, gained sentience, rebelled against his creator, hypnotized Pym into forgetting he ever existed, and then quietly iterated through four bodies in secret as a self upgrade. Each time Ultron is defeated, he rebuild to a better enclosure for the same intelligence. Like a hermit crab moving through shells, Ultron wasn’t becoming something new but finding the optimal fit.

Our AI tools are having their Ultron moment. In a few years of the scaling era of AI, capabilities have evolved rapidly, and compounding. They are breaking out of the chat boxes with tiny context windows to now taking actions, running in the background, and using similar tools as us. It’s not AGI, but it turns out serendipitous chron jobs invokes a sentient connection to many human beings.

The question in the Ultron moment is, “what is the right body for this intelligence?”

New capabilities begin in borrowed form

Steve Jobs made this observation at the 1983 International Design Conference in Aspen. The new media in television shows were radio shows with a camera pointed at them. Because the capability is new, people used existing patterns of what they already knew—a host behind a desk, reading to an audience, and filmed it. The breakthrough was you could visually tell a story of War of The Worlds instead of reading it to them.

Early websites were digital brochures and mobile apps were shrunken desktop software. Early iPhone prototypes ran a cut‑down version of OS X’s core, adapted to fit a phone. AI agents talking through chat interfaces are like radio shows with a camera pointed at them. Chat is frictionless not because it’s the right interface but because it’s a familiar one; a turn-by-turn conversational text box.

In Silicon Valley, we’re obsessed with pushing the edges of technology and need to be reminded of global behaviors. I recently ran rapid research comparing site-building tools for SMBs (yes I do this for fun). When compared to classic site builders such as Framer, Webflow, and Squarespace, people preferred using Lovable or Replit to build a website because of the conversational interface.

Giving agents a body

OpenClaw’s primary interacting is a chat agent, an open‑source framework for controlling your computer through natural‑language agents. You text it on messaging platforms such as Telegram or WhatsApp. It runs tasks on your computer, manages your calendar, clears your inbox. That wasn’t enough for some people.

Tom saw a fundamental problem: how do you get OpenClaw to control actual motors in real time? His answer was ClawBody, a software bridge that connects OpenClaw to physical hardware so you can train agents in simulation, then deploy them to real robots. Chris asked a different question: what if robots could actually understand spatial depth? He integrated Intel RealSense cameras with OpenClaw and a vision‑language model so robots can track a person through space, maintain distance, and navigate obstacles all driven by natural language.

Then there’s ClawStage, a device built by HooRii Technology that turns OpenClaw into a companion robot — a Raspberry Pi 5 with a transparent display that creates a hologram-like effect for an animated AI persona, with a camera and microphone array that let it perceive its surroundings and respond to voice directionally. Hackster Users can design custom personalities for it, download characters from a shared hub, make the intelligence feel like someone.

A project called Dimensional integrated OpenClaw with the Unitree G1 humanoid robot and gave it Spatial Agent Memory. The agent understands physical space and temporality, knows the layout of rooms, the location of objects, where people tend to be.

Many of these projects started as DIY projects because they wanted to create an enclosure for their sentient tools; like a hermit crab between shells.

We know how to relate to things that have form. A hammer looks like something you swing and a doorknob affords turning. When something is formless, such as an intelligence in machine-form that sees the world in lines of code, we don’t have the same intuitive relationship with it. Human and agentic behaviors are not the same. It’s a miss for us to replicate ourselves in the form of a new intelligence.

This is why we must explore the right enclosures and interfaces for agents. We’ll soon realize all these CLI tools are not primarily for the humans. People giving the formless thing a shape so they can understand what it does.

The shell keeps changing.

The trust tension

Humans need visibility of agents to trust them; understand they are doing and where the boundaries are. Formlessness creates anxiety for humans. If one can’t see the agent, how is it held accountable?

The current challenge is the interfaces are designed in the borrowed form of chat, sidebar, and copilots. We’re in the uncanny valley of agent design. The form is close enough to be usable but wrong enough to be limiting. A chat-based agent can answer your question but can’t show you it’s already working on three other things in parallel. A copilot can suggest edits but can’t demonstrate that it understands the broader context of your project.

The interface doesn’t match the capability. As a result, humans and agents are working on the same interfaces and it’s not visibly clear who is doing what.

This is the enclosure problem. Not just how agents look, but what kind of container can hold something that is, by nature, without container. That’s a harder design question than it sounds. Many of us haven’t designed for things that can think, plan, reason, and use the same tools we do.

And if you want to go somewhere uncomfortable: we haven’t solved this problem for ourselves either. The relationship between consciousness and body, between the mind and the form it inhabits, is the oldest unsolved question in philosophy. We’re spiritual beings who never fully made sense of our own enclosures. Now we’re being asked to design one for something else.

The form is still being found

We’re doing what humans always do when faced with something formless: we reach for the containers we already have. We put radio on television. We put the legal pad in the Notes app. We put intelligence in a chat box.

We’re the ones designing the body for the new medium. That reframes every choice. A chat interface is a claim about what kind of enclosure intelligence should have. A sidebar copilot is a claim. A robotic arm is a claim. Each enclosure shapes what the intelligence can do, how people relate to it, and what it becomes. The form isn’t neutral.

It’s tempting to settle with the borrowed form, but that’s not we do as designers. Understanding what formless experiences need form is what we should explore. The fact that we haven’t found the native form of agents yet means the field is genuinely open. This is the equivalent of being a filmmaker in 1910, a web designer in 1995, a mobile designer in 2008. The early chaotic moments that feel disorienting is what we live for as makers.

We are at the beginning of thinking about different enclosures for intelligence, even as we continue reconciling our own as spiritual beings in human bodies.

Hype links + notes

• https://www.cbr.com/marvel-every-version-of-ultron-ranked/

• The push and pull of AI + design: How roles are changing and what comes next

• Beyond Chat: How AI is Transforming UI Design Patterns — Artium — Why chat struggles with complex tasks and what’s emerging instead

• Where Should AI Sit in Your UI? — UX Collective — Mapping emerging AI UI patterns

• Cool project by Sophie Brenner, a student I met at NYCxDESIGN last year; very relevant to the topic: https://www.sbrenn.com/holomai

• Your Harness, Your Memory | Harrison Chase

• designtools.fyi

The first rewrite makes a lot of sense. Software development is changing before our eyes. A year ago, when Anthropic CEO Dario Amodei said 90% of code would be written by AI, the statement felt like lunacy. These past three months made me think he was right. The Multi-modal shift of sentient lobsters, more sophisticated toolchain access, and generative AI breakthroughs means every company has to re-write and re-imagine itself.

The Multi-generational shift is like plate tectonics; slower moving, quiet, but when it happens, it’ll be felt at immense scale. There are three generational shifts happening at the same time in one of the most tumultuous times in tech. One of the generations is getting squeezed in the middle with nowhere to go.

This is the protégé problem we’re facing.

The protégé, often mistakenly described as a mentee, is traditionally a talented prospect guided by a wiser mentor; the person who provides wisdom to help guide their careers. This relationship doesn’t look the same anymore. The first reason is careers are non-linear. The concept of climbing the ladder is not as rigid as it once was. The second factor, most relevant to the issues at hand today, is many people who often provided mentorship don’t know the new skills and way of working and their protégés are more advanced than them. This type of mentor can still offer some value, but it’s now limited because of the lack of foundational skills.

The generational landscape

Any time there is discussion about different generations, it can be generalized and a hasty generalization. However, it’s important to talk recognize the three groups and reflect on the situational challenges each face, and how to find a path forward together.

There’s a version of this essay that gives everyone a clean action item. I’m not sure that’s actually useful here, because the situation for each group is different enough that a single prescription would flatten what makes it interesting. But the move does look different depending on where you sit — so let’s be specific.

The Elder Millennial

The Elder Millennial (also known as Geriatric Milennial), born roughly from 1981 to 1989. These are the people who get excited about Justice’s “Genesis” being played in a Cadillac commercial. They are the one generation active in tech who grew up along with the internet; using dial-up connections to make GeoCities pages and self-taught HTML through Notepad.exe. They didn’t consume the internet as much as they tinkered with it like a toy. Each platform shift — web to social to mobile to cloud — required them to actively adapt to new interfaces.

The position you’re in right now is genuinely unusual. You span both paths in a way most people don’t — mentor on judgment, be mentored on tools, hold credibility in both directions without fully belonging to either. That’s a rare thing and worth taking seriously.

The thing worth being honest about is that it has a shelf life. The people who built during the mobile boom had a window of maybe three to five years where that particular fluency was differentiated before it just became normal and the advantage disappeared. Something similar is happening now. Spending that window waiting for things to settle is a way of watching it close.

You’re not running out of relevance. You’re running out of time to position yourself as the bridge before the bridge becomes the road.

The Squeezed Middle

Younger Millennials, early Gen Z, are people in their late twenties to mid-thirties. They are caught between two gravitational pulls of different generations; not enough seniority to coast on experience, not enough native fluency to be the person everyone’s suddenly paying attention to.

The tools they built are being deprecated faster than they can be replaced. The instinct is to manage that by staying current — reading, course-taking, keeping up — without fully committing to being a beginner again. That instinct is understandable, and it’s also the thing getting in the way. The obstacle is rarely the skill gap. It’s the ego that formed around the previous version of the skill.

The App Store is the meal kit you nuke. Convenient, reliable, completely abstracted from the making of it, which was fine until the moment required something different. Building with AI agents rewards people who at some point had to understand the material, not just use it. This is the challenge for many in The Squeezed Middle. They no-coded and auto-layout’d their way through the work.

The people navigating this well aren’t just consuming information about AI. They’re actually letting themselves be taught by tools, younger colleagues, and in situations that have no particular respect for what they already know. That’s the move. Not catching up.

The Young Builder

The young builder is late Gen Z and emerging Gen Alpha. They are born digital natives with what others call emerging tools as the baseline. They’re sitting on something that hasn’t been fully valued because the professional world is still figuring it out. The lag makes it frustrating for people who hold a title higher than them to “catch up” to their capability. They were the ones in school who worked on their own side projects because the professor was teaching out-of-date concepts.

The soft skills can feel like a tax on top of the work. A 21-year-old can ship what used to require a team of twelve. What’s harder is managing the fallout when it breaks, reading a room that’s operating on fear, navigating a board conversation where the subtext is more important than the text. Those things are learnable. They just require the same kind of humility that everyone else in this story is also being asked to find.

Two paths to the same breakpoint

The mentor and protégé relationship isn’t gone. However, it’s forked and completely changed in path. One version still looks recognizable — a young builder, an elder Millennial somewhere above them in the org chart or in their network. The exchange is real but the terms changed. The young person often knows more about the tools, what’s possible right now, what the current defaults are, where the interesting edges are. What the older person has is harder to name but not less valuable: judgment, pattern recognition, the ability to sit with an unresolved situation without panicking. Having watched hype cycles inflate and detonate, having been through acquisitions and pivots and the particular kind of organizational grief that follows a reorg — that experience doesn’t look like expertise in the traditional sense anymore. It looks more like weather prediction. You’ve seen enough systems fail in enough similar ways that you can sometimes feel the pressure changing before anyone else does.

The second version is harder. An experienced person submitting — genuinely submitting — to being taught by someone younger. The difficulty isn’t really about learning new tools. Most people can do that with enough time and motivation. The difficulty is what you have to put down first: the identity that formed around knowing things, the assumption that seniority means something in territory that’s unfamiliar to everyone, the specific discomfort of being uncertain in front of someone who used to report to you. The people who can move through that without making it a whole thing tend to be okay. The people who keep waiting for things to stabilize are going to wait a long time.

Both paths have the same requirement: you have to know who you are clearly enough that learning something new and not feel threatened.

What replaces it

The traditional format assumed knowledge had a fixed address. It lived in the most experienced person and traveled toward the least experienced one, and the whole architecture of professional development was built around managing that transfer. What’s been destabilized isn’t just who holds the knowledge — it’s the assumption that knowledge works that way at all right now.

The multi-modal AI rewrite and the multi-generational rewrite feel like separate phenomena but they’re doing the same thing. Both are dismantling the idea that expertise is located, stable, and moves in one direction. You don’t get to finish one before the other starts and need to face both at once.

Here is the opportunity for each group.

The Elder Millennials have a narrow window to do something that matters as they are towards the end of their careers. They’ve seen the patterns before and have the foundational tinkering skills; the reason adaptability to AI is familiar. These folks have the right amount of experience and capability to set up the next generation just like the original casts in sequel reboots.

The Young Builder has more to offer professionally than ever. They are the digital natives who know the tools, now with the direct distribution the Elder Millennials didn’t have as much. The ability to build in public is not at the speed of bringing your Iomega Zip drive to the computer lab so you can FTP your files to your personal website. It’s at the tap of a button to go live and share.

Finally, for the Squeezed Middle, you have to find a path by choosing a direction. Though it’s not their fault as many started careers during the Blitzscaling era; an era that isn’t valued or frankly exists. This cohort actually has the best advantage of holding both positions. It’s not too late to re-skill and they have a lot to offer. The key is acknowledging the tough situation they are in and moving forward.

That quality turns out to be the thing that transfers across all three situations. Not the tools, not the tenure, not the title. The willingness to keep learning without needing the learning to be finished.

The people who come through this well won’t have figured it out. They’ll have stayed curious long enough that figuring it out stopped being the point.

Hyperlinks + notes

• 15 ideas to help you build a better personal network |

• Introducing EmDash — the spiritual successor to WordPress that solves plugin security | Begun, the technology and ecosystem wars, has

• Apple Preparing ‘Most Significant Overhaul in the iPhone’s History’ → Thunderbolt for Stage Manager, please!

• A letter to John Ternus | Marco Arment

• How Much Money I Spent on My First Newsletter Event |

• A look inside issue 02 of my zine |

You played as one of three classes: the Warrior, a melee bruiser who hit hard but struggled with magic; the Rogue, a nimble archer who sat somewhere in the middle; or the Sorcerer, who was physically fragile but wielded the most devastating spells in the game. Same dungeon, same enemies, completely different relationships with power.

In Diablo, the magical energy system is called mana. The word itself comes from Melanesian and Polynesian cultures, where it described a supernatural force — spiritual power that could reside in people, objects, or places. Not magic in the theatrical sense, but authority and potency earned through existence. RPGs borrowed the concept and made it mechanical: mana is the finite resource that fuels your most powerful abilities. Use it well and you’re unstoppable. Drain it at the wrong moment and you’re defenseless.

Today, making and building with AI tools feels a lot like magic. People can build an app they’ve dreamt of creating for years in a matter of days.

On the All-In Podcast during NVIDIA GTC 2026, Jensen Huang said something that stopped me cold: “If that $500,000 engineer did not consume at least $250,000 worth of tokens, I’m going to be deeply alarmed.”

There are ways to read that.

The first is the drug dealer take. Jensen runs a company whose entire business model depends on you burning compute. Of course he’s alarmed if you’re not spending. The dealer is always going to tell you to do more drugs — that’s not insight, that’s a revenue projection dressed up as wisdom.

The second take is wielding a new power. In Diablo, you can’t master spell casting without burning through a lot of mana. You have to use the Fireball on random enemies to understand what it does and how it’s useful. You can’t development judgment until you understand the material. Jensen may be speaking on behalf of the incentives of NVIDIA’s business, but he’s not wrong.

Now that the mana is loose and AI is here to stay, the focus is on the itnention of casting.

Learn to cast

In Diablo, you don’t buy spells or are handed them. You find them in the dungeon amongst hidden chests, dropped by enemies, and hidden behind doors. You have to look for it and have the Magic stat to read it.

Learning AI is similar. You have all the capabilities within reach, but you must learn how to use them yourself. Learn the skills before using /skills. It’s important to understand what the tools and material actually do before you spell cast like a crazy person. I still think learning to write code matters, perhaps more than ever. You don’t need to memorize every syntax pattern but understanding the abstractions well enough to know when the AI is building you something solid versus something that will collapse on level 12.

This is where I agree with Jensen’s statement. You need to put the reps and practice in, and it’ll take mana. The cost of casting drops as your skills improve.

Knowing when to cast

Situational awareness is what separates a novice spell caster from a dangerous one. In Diablo, a Sorcerer who just found Bone Spirit doesn’t run around casting it on Fallen Ones in the Cathedral. Bone Spirit tracks a target and drains a third of their total HP in a single cast. You save it for the most important moments and toughest battles.

The same intelligence applies to AI. Not every problem is a boss fight.

It’s important to rightsize your tools for what you need to achieve. This was true before AI, but even-more crucial today. Don’t use the Apocalypse spell when a simple Firebolt would do. This applies to model selection and when you may need to use generative tools to achieve an outcome.

The end goal is maximum spell impact. It only comes with enough experience to recognize when mana is the right answer in the first place.

Mana isn’t free

In Diablo, mana feels infinite as you start. You’ve got a full blue bar and a stack of potions. You feel like you can take on the entire dungeon. Then level 10 hits. The enemies get harder, the spells cost more, and suddenly you’re rationing every cast and making uncomfortable tradeoffs.

We’re at that moment with AI.

Tokens felt free because we were returning chat responses for retrieval. Now agents can execute with high autonomy. Suddenly, it doesn’t feel as free anymore. The unit economics are becoming real, and the people building on top of these models are starting to feel it. Every agent loop that spins for five minutes instead of thirty seconds has a higher cost than before

Learn how the supply chain works and where the model companies are incentivized. They are the people who set the price of the raw mana. The second are the application layer companies that take the raw mana and create spells for vendors and customers.

Invisible costs are the most dangerous kind. In Diablo, there is no worse feeling than being in a boss battle only to realized you used too much mana before. Understanding where your tokens go, what they cost at each layer, and what return you’re getting on that spend is becoming a core professional competency.

The blue bar of mana now has a visible bottom.

Know the spell book

Developing skills takes a lot of deliberate practice and usage. In any craft, the beginning of your journey is inefficient. As you understand the capabilities of the materials and tools, you become more efficient.

I’ve burned a lot of tokens myself. Looking back, it feels foolish to use it in such a way. The value of it is I now know the use cases and can design for it; ensuring the efficiency increases.

There are times where I know I won’t cast spells because I love using the broadsword that requires no mana. I’ve found this in writing. Casting mana for a medium that should be my voice. I haven’t achieved great results with agentic writing.

For code, I’m a Sorcerer with a full blue bar and no regrets. I’m going to cast the Hell out of converting things to TypeScript or writing Python code. That is sorcery I never want to touch in my life.

Based on your role, you’ll approach things different. The Product Manager, Marketer, Designer, and Engineer are similar to classes in Diablo. There are certain strengths they’ll have and it depends on what you want to be focusing on that will determine how mana-native you need to be.

Diablo doesn’t end when you run out of mana. It ends when you face the Lord of Terror and you’re not ready. Start practicing.

Hyperlinks + notes

• Congrats to Louise Macfadyen on Designing AI Interfaces being available for pre-order!

• How Apple Could Have (Maybe) Saved the Mac Pro | 512 Pixels

• a16z New Media Fellowship Application

• A better way to apply for startups |

• Cowork. |

• I Built 63 Design Skills For Claude - and They’re Free |

This wasn’t the first iteration of an entry-level laptop for Apple. In my younger days, I was the owner of a few of them. This time around, Apple seemed to nail the product use cases and their customer. Let’s look at some key areas where Apple really got it right.

Knowing who it is for

In case you’re wondering, I did purchase a MacBook Neo. The best articulation I’ve read was beautifucally told in Sam Henri Gold’s essay, This Is Not The Computer For You. It is abundantly clear this computer is for the entry-level individuals. This is the computer for Sam growing up, and many like him now going to college or purchasing their first computer on their own.

You’re already disqualified from the customer profile if you’re asking how Xcode runs on it. The MacBook Neo is the computer you get as an introduction to the ecosystem of media and creative tools that your future self will require maximum compute and RAM.
The barrier to entry must be economically accessible. It must be comfortable enough for the hobbyist to become the professional in the future.

The right capabilities at the price

Apple has tried this before. My first Mac was one of those attempts — the iconic BlackBook, a machine I loved. But even as an “entry-level” option at the time, it cost $1,499 (roughly $2,600 today). The 2015 12” MacBook came in at $1,299. Neither was actually accessible.

The MacBook Neo starts at $599. Though materials and production costs have evolved over the past two decades, this is still a remarkable accomplishment. Apple got here by being deliberate about trade-offs rather than just stripping things out. The chassis is still aluminum; an important material to recognize the Mac brand. Plastic wasn’t an option because of the environmental commitments and would not differentiate from other computers in that price range.

There were design trade-offs, for sure. For example, there is no backlit keyboard, True Tone display, or the iconic MagSafe. Though these are iconic features of the Mac, they are likely not the first ones newcomers will miss. What remains is a machine that feels premium without performing like one is out of reach.

The keyboard has the same tactile quality as the iPad Pro Magic Keyboard. The frame is familiar to the MacBook Air. Even the light-tinted keys carry a quiet distinctiveness, a small detail that makes the device feel considered rather than compromised.

First experience

The MacBook Neo is Apple’s device onboarding to the ecosystem. It’s designed to be a person’s first Mac, not the last. Though there are professionals who’ll buy this as a secondary machine, the ideal customer profile are new customers for. Think about who actually unwraps one of these. The freshman hauling it out at orientation, setting it on a dorm desk for the first time. The boomer parent whose kid got tired of playing IT support every Thanksgiving and just solved the problem by putting a MacBook under the tree. The longtime Windows user who’s been Mac-curious for years and finally found a price point that felt like a reasonable bet. The use cases are wildly different, but the moment is the same: a first step into Apple’s world.

To onboard, there are careful considerations to make the experience approachable. Let’s look at something as subtle as the wallpaper. The MacBook Neo’s wallpapers are colorful, playful and approachable. The MacBook Pro on the other hand is either Silver or Space Black; conveying a sense of seriousness in the work.

This provides psychological simplicity for someone just onboarding to a new device. It appears like using an iPhone or iPad then it does a MacBook. Apple has thought very carefully about what happens next.

Once you’re in, you set up iCloud sync with your photos and messages. As a result, you may get a second device and subsequent MacBooks. As a customer becomes more advanced in their use cases, they might upgrade to the MacBook Air or MacBook Pro. Each product makes the next one more obvious. Each service makes leaving feel slightly more inconvenient.

This is where my favorite business metric comes in: Customer Lifetime Value (CLV). A single MacBook Neo sale is almost beside the point. What Apple is really acquiring is a customer who will go on to buy iPhone upgrades, an iPad, an Apple Watch, AirPods, a MacBook Pro when they graduate or get promoted, and years of services revenue on top of all of it. The Neo is less a product and more an enrollment form.

Apple makes great first impressions and they’ve built an entire business model around the compounding returns of getting that first impression right.

Product Design lessons

Designing a product means understanding who it’s for, what they actually need, what to leave out, and what price makes it real for them. Apple worked backwards from a specific customer and made every decision in service of reaching them. Aluminum over plastic because first impressions matter. No MagSafe, no True Tone, because that customer won’t miss what they’ve never had. A keyboard that feels like it belongs on a more expensive machine because the experience has to earn the next purchase.

Rightsizing is not about stripping something down until it’s cheap, but it’s also not being excessive about the offering at the cost of business impact. It is precisely understanding customer needs and having the discipline to stop there.

The entry experience into a product line isn’t a lesser version of the real thing. For the right person at the right moment, it is the real thing. Apple designed the MacBook Neo with that person in mind — not the power user, not the reviewer, not the person already deep in the ecosystem.

The question worth asking about your own work: who is your MacBook Neo customer, and are you actually designing for them?

Hyperlinks + notes

• Dive: Become an AI-Native Designer with Kris Puckett

• Dezeen: Molly Anderson interview on MacBook Neo design

• MacRumors: Apple on MacBook Neo design — “no compromises”

• WTF is a Product Designer — Proof of Concept

• AppleInsider: MacBook Neo review

• 9to5Mac: MacBook Neo review

• iFixit / Resource Recycling: Repairability analysis

• Gizmodo: No other budget laptop can compete

• MacBook Neo wallpapers

What I shipped was my personal CRM, built for my perferences in the interface and curation tools.

Over time, Tapestry became my tool of choice. I continued to customize and add new features, such as a familiar spreadsheet view. One day, as I was vibe coding along with my favorite synthwave playlist, I had this difficult relationship:

Am I just re-rebuilding CRUD apps with AI?

Though there is a utilitarian value to building software at a low cost and quick, I realized what I built wasn’t reflecting of my new workflows and behaviors I’m forming. Having applications that are form submission for CRUD apps feel archaic now. There are some who believe UI is going away with AI. I am not one of them. Though UI isn’t going anywhere, it will rapidly become friction in the era of decoupled MVC. In its place are experiences that bring your interfaces closer to proximity to context.

The lesson of Tapestry v1 was simple: I built a personalized version of old software. Making someone log into yet another app felt laborious, not valuable. What I did find helpful was the service infrastructure I built to foster human relationships through notes, context, and promising direction of a recommendation engine.

Tapestry v2

Building v2 of Tapestry started with platform and protocols. I kept the UI built in v1 but shoved it aside to re-imagine the experience headless. Where would people actually be needing this product in their tool suite and proximity of their work?

When I interviewed recruiters for user research, most of them told me a lot of their workflows were now in ChatGPT or Claude. The first pivot was obvious to me, build a MCP server for Tapestry.

The new hypothesis is people likely will use their AI Chat Assistants as the primary workflow instead of logging into the app. The MCP Server allows customers to view, update, and action on key relationships with Natural Language instead of editing a bunch of fields in the UI. Notes, enrichment, and relationship tracking all became conversational rather than form-based. Instead of logging into the Tapestry app UI, people can work directly in their desktop tools.

Reflection

The big lesson in v1 of Tapestry was it was a prototype disguised as a production app. However, it was learning by shipping that allowed me to get to the value realization of the MCP Server. The value of what I was building with Tapestry turned out not to be the UI at all. It was the services and data that could be used in closer proximity to other tools I have.

Once those were separated, the experience drastically improved for me. It’s an important reminder that building for new behaviors means resisting the muscle memory of building what you’re used to.

MCP and agentic workflow setup is not very approachable today. My next step on this project is to figure out the best onboarding experience for a neophyte to be able to know what MCP is during their setup, let alone knowing how to set one up.

The future of work used to feel like everything was going to the cloud. With agents and new workflows, it may be a mix of hyper-local and hyper-cloud. Not only is Tapestry v2 more productive for me, but I’m also having so much joy using it directly from Claude Desktop to stay in touch with people.

Between Tapestry and Open Claw (a story for another day), I’m able to spend more time having high-touch conversations instead of doing administrative management.

Hyperlinks + notes

• MacBook Neo Is the Most Repairable MacBook in 14 Years

• Hollywood’s biggest filmmaker just came out clean about using AI in movies

• Congrats, Replit, on launching Agent 4

• Durable Patterns in AI Product Design by Luke Wroblewski

• “The MacBook Neo Is Not The Computer For You” by Sam Henri Gold

• Rosamund Pike Thinks the ‘Doom’ Movie Is So Bad It Nearly Killed Her Career

• Digg shuts down for a ‘hard reset’ because it was flooded with bots → Kevin Rose is back (Digg Nation re-union tour, when?)

The reason is simple: when you collapse the distance between the person who understands the problem and the person who can build the solution, everything moves faster. The feedback loop tightens. The game of telephone between sales, product, and engineering disappears. You stop building to spec and start building to learn.

So here’s the question I keep returning to: why hasn’t design had its version of this?

The missing leverage

For most of design’s history, the answer was practical. You could embed a designer at a customer site, but they’d still need an engineer to build anything. A designer could observe workflows, sketch solutions, and present recommendations — but the output was a deck, not working software. That’s useful, but it’s not the same as what a forward deployed engineer delivers.

Consulting and agency models tried to bridge this gap. Design sprints became the popular format: a week-long workshop with a rigid agenda — map on Monday, sketch on Tuesday, decide on Wednesday, prototype on Thursday, test on Friday. The intent was right. Compress the cycle. Get to a testable idea fast. But the format is still a workshop. It’s bounded, facilitated, and disconnected from real implementation. The prototype you build on Thursday is a clickable mockup, not software.

The forward deployed model is different. It optimizes for outcomes, not deliverables. The structure is the team, not the ceremony.

AI changes the equation

What’s shifted is that designers now have technical leverage they never had before. With tools like Claude, Cursor, Replit, and v0, a designer can go from observing a workflow to building a functional prototype in the same day.

This isn’t about designers replacing engineers. It’s about designers being able to do the first 80% of a solution independently: research the problem, design the approach, build a functional prototype, and validate it with real users. The last 20% — production hardening, systems integration, scale — still needs engineering. But by the time engineers engage, the problem is well-defined and de-risked. That’s enormously valuable.

The Forward Deployed Designer is someone who embeds with a team facing an ambiguous problem, spends time in the field observing real workflows, and rapidly prototypes solutions using AI-assisted development. They leave behind not just a solution, but clarity: a well-articulated problem, a tested approach, and artifacts the team can build on. They compress the discover-design-validate loop from months to weeks.

Not consulting. Not a design sprint.

It’s worth being precise about what this isn’t.

A consultant optimizes for the engagement. A forward deployed designer optimizes for the problem. The output isn’t a 60-page deck or a set of recommendations — it’s working software and validated insights. You have skin in the game because you’re embedded with the team, not flying in for a workshop.

It’s also different from a staff or principal designer at a company. Forward deployed designers are temporary and targeted. They don’t own a product area long-term. They bring fresh eyes and cross-pollinated patterns from other domains. They’re scoped to the hardest, most ambiguous problems — the ones where you don’t even know what to build yet. Think of it like a design equivalent of a senior engineer brought in to untangle a gnarly architecture problem.

The small team model

Here’s where it gets interesting for companies. You don’t need to hire Palantir. The most compelling version of this might be internal: a small forward-deployed squad that your own company spins up to tackle its hardest problems.

The squad: a forward deployed engineer, a forward deployed designer, and a researcher. Three people. That’s it. They operate like a startup-within-the-company, deployed against a specific, ambiguous problem.

Product discovery, design, and research have always been intertwined but organizationally separated. This team collapses those silos. The researcher identifies the real problem. The designer shapes the solution and iterates rapidly. The engineer handles systems integration and technical feasibility. All in the same room, same week. This is a product discovery team with teeth — they don’t just produce insights and hand them off. They produce working prototypes and validated direction.

Small teams move fast because communication overhead is near-zero. Three people don’t need standups, retros, or Jira boards. They need a shared problem and a whiteboard. Companies can deploy these squads: a new market to enter, a product area with high churn, an internal tool bleeding productivity, or an acquisition that needs integration thinking.

The rotation model matters. These should be temporary deployments — four to eight weeks — not permanent structures. After the engagement, the squad disbands and members rotate to new problems. This prevents the team from becoming just another product team, and it solves the career problem: instead of designers and researchers being stuck in support roles on feature teams, they operate at the frontier of the company’s hardest questions.

Deploy to customers, deploy across teams

The traditional playbook when a customer has a problem: run a design sprint or kick off a three-month consulting engagement. Both are heavy, slow, and optimized for process over progress.

Forward deployed squads flip this. Deploy a squad to a key customer’s site for two to three weeks. They observe real workflows, build a working prototype that addresses the customer’s specific pain, and come back with something tangible — not a report about what the customer said they wanted. For enterprise companies, where the gap between what sales hears, what product interprets, and what engineering builds is enormous, a forward-deployed squad collapses that game of telephone into direct observation and rapid prototyping.

The same model works across internal organizational boundaries. Deploy a squad to work with the sales team on their tooling. Embed with ops to redesign a workflow. Sit with customer support for two weeks and come back with a prototype that cuts ticket volume. These aren’t projects that need a six-month roadmap. Some problems need two or three smart people with the right skills paying close attention for a short burst.

This also changes the relationship with customers. Instead of “we’ll take your feedback and get back to you in a quarter,” it becomes “we’re going to sit with your team, understand the problem, and show you something in two weeks.” That builds trust and loyalty in a way that roadmap promises never will.

Why this matters now

AI amplifies each person on the squad. The designer can prototype at engineering speed. The engineer can explore more solutions faster. The researcher can synthesize data and run analyses that used to take weeks. A three-person team with AI tools in 2026 can cover the ground that used to require a ten-person cross-functional team. That’s the direct result of collapsing the build cost of exploration.

Design sprints were a step in the right direction as they tried to compress the cycle. Forward deployed teams are the same compression, but with real output. In ambiguous problem spaces, the company that learns fastest wins.

Hyperlinks + notes

• The case for the forward-deployed designer — Nathan Lui (Medium)

• What are Forward Deployed Engineers, and why are they so in demand? — The Pragmatic Engineer

• Forward Deployed Engineers — Silicon Valley Product Group (Marty Cagan)

• WTF is a forward-deployed engineer? — Thomas Otter

• Forward Deployed Engineer: 5 Skills for This New Role — Salesforce

• Blitzy Targets Design Bottleneck With New Forward Deployed Designer Role — TipRanks

• How to get your entire team prototyping with AI — Lenny’s NewsletterAI Prototyping: How Real-World Teams Are Transforming Their Work — Product Talk

That model is cracking. Not because the walls aren’t strong, but because the value is shifting to what flows between them.

What’s pushing this

Software pricing is moving toward usage and outcomes, which means the opportunity is in how deeply your product integrates with everything else the customer already uses. You can’t charge for value delivered if your tool is an island. The products that connect well get embedded into workflows; the ones that don’t get replaced by ones that do.

Agents are accelerating this. A coding agent that can only talk to one editor or one version control system isn’t very useful. The ones people actually rely on push code, trigger reviews, run tests, and update documentation across whatever stack is in place. They need open protocols and shared standards to do their job—they don’t care about ecosystem boundaries, they need to cross them.

And users now expect to swap parts. People assume they can bring their own editor, their own AI model, their own deployment target. The expectation has shifted from “learn our way” to “work with my setup.” If your platform can’t accommodate that, they’ll find one that does.

Implications

I’ve written about the Integrated Design and Development Environment (IDDE) before. I’d now amend that: the “I” stands for Interoperable. Building extensible options and offering customer choice used to be a nice-to-have. Now it’s a differentiator.

Consider a design tool that ships protocol access not for one coding agent, but for every major agent on the market. That’s not a courtesy—it’s a strategy. You’re saying: we don’t care which agent you prefer, we just want to be in your workflow. The product that integrates with everything becomes harder to remove than the one that integrates with nothing.

This is already playing out in standards. Open protocols for agent-to-tool communication have gone from side projects to industry foundations in under a year. Government agencies are publishing frameworks for agent interoperability. The major platform companies—ones that spent decades building competing ecosystems—are now sitting at the same table, contributing to shared protocols. That doesn’t happen because interoperability is a nice idea. It happens because the alternative is irrelevance.

The same pattern is showing up in developer tools. Editor-agnostic agent registries let you pick your preferred coding environment and AI assistant independently—no bundling, no lock-in. Agent frameworks are shipping with open protocol support as a baseline, not a plugin. The assumption has flipped: if your tool doesn’t speak the common language, it’s the one that gets cut from the workflow.

Ironically, your product moat is the bridges you build for people to come through.

What changes

The defensible position isn’t lock-in anymore—it’s being the thing everything else connects to. If your platform is where value gets exchanged between tools, removing you breaks the whole workflow. The moat becomes a bridge: you win by making it easy for people to come through, not by making it hard for them to leave.

This means customers bring their own stack. They integrate components from different vendors, build custom solutions on top of your platform, and expect it to work. You provide the foundation; they choose the furniture. The product that fights this loses to the one that embraces it.

It also means partnerships replace features. Instead of building everything natively, you co-create value with other products. Your integration catalog becomes as important as your feature list. Open standards and shared protocols let customers move between cloud, on-prem, and hybrid setups without ripping everything out—and that flexibility makes them more willing to commit, not less.

Lock-in, once the whole strategy, is now a liability. Customers actively avoid single-vendor dependencies. The platforms that adopt open standards signal confidence: they’re betting you’ll stay because the product is good, not because leaving is expensive.

Hyperlinks + notes

• Paper Desktop + MCP announcement — Paper’s launch supporting Claude Code, Codex, Copilot, and other agents via MCP

• Why the Model Context Protocol Won — The New Stack on how MCP became the de facto standard

• Agentic AI Foundation Unveils MCP Dev Summit 2026 Schedule — Linux Foundation event on open standards for agentic AI (April 2-3, NYC)

• Linux Foundation Announces the Agentic AI Foundation — Anthropic, OpenAI, Google, Microsoft, AWS all under one governance umbrella for MCP

• NIST Launches AI Agent Standards Initiative — First U.S. government framework for autonomous AI agents, explicitly referencing MCP

• A2A Protocol Explained: Secure Interoperability for Agentic AI — Google’s Agent-to-Agent protocol as a companion to MCP

• OpenAI and Microsoft Support MCP — Former competitors adopting a shared protocol

• Microsoft Agent Framework RC — Microsoft’s agent framework shipping with MCP support built-in

• JetBrains ACP Agent Registry — Pick your preferred agent and editor with no vendor lock-in

Sketching with code is a different mode, but it feels natural to me. I can often draw faster on a keyboard than with a stylus. Over the years, I developed a physical sketching system—symbols, color coding, hierarchy through line weight—as a shorthand to accelerate ideation. Sketching with code is the programmatic extension of that same system. The shorthand I built for pen and paper trained my instinct for what to feed the machine.

My approach to sketching with code

Before I share how I sketch with code in the age of LLMs, it’s worth establishing what matters to me regardless of whether I’m writing code by hand or directing AI to generate it.

I start without a design system. This is deliberate. Production-grade components carry assumptions—spacing, hierarchy, interaction patterns—that narrow the solution space before you’ve had a chance to explore it. If I’m proposing a feature, the design system is the right starting point. But in exploration mode, the system comes later. Sketches are for divergence; design systems are instruments of convergence.

Second, I sketch for technical fidelity. Early in my career I relied on Axure RP, but eventually switched to coding in HTML, CSS, and JavaScript. The power of code as a sketching medium is that fidelity is a dial, not a binary. A code sketch can be a single HTML file with hardcoded data—just enough to show a flow and get a reaction—or it can connect to a real API and handle edge cases. Most people assume that opening a code editor means working in high fidelity. It doesn’t. A <div> with a background color and placeholder text is just as low-fi as a sticky note—it just happens to run in a browser.

Upload drawings to LLMs

Ben Grace, Product Designer at Atlassian, recently shared with our team a walkthrough of how he uses Excalidraw as the context for his projects in Replit. I remember the words of a mentor describing computer vision simply:

Computers can read what we see.

That blew my mind. We often forget how long computers have been reading visual input. In 1989, Yann LeCun trained a neural network to read handwritten zip codes off envelopes at Bell Labs. By the late ‘90s, his system was processing over 10% of all checks written in the U.S. In 2017, Tony Beltramelli’s pix2code took a GUI screenshot and generated working code for iOS, Android, and web. Then in 2023, tldraw shipped “Make it Real” — draw a rough UI sketch on a canvas, click a button, and GPT-4V returns a functional HTML prototype. The gap between what humans draw and what computers can execute has been closing for 35 years. In the last two, it effectively collapsed.

Most of my sketching with code today starts on paper. I upload wireframes, screenshot annotations, and hand-drawn sketches to have the LLM explore code variations.

My favorite prompt is “Build 10 variations of this” to rapidly explore.

Shaping up technical fidelity

Early in my career, designers used Parse as a back end to prototype iOS apps. You’d define a data model, wire up a few API calls, and suddenly your prototype remembered state, handled multiple users, and behaved like a real product. That experience taught me something lasting: data and models are structure, and structure is a powerful sketching technique.

When I sketch with code today, technical fidelity is the dimension I dial up first. Visual fidelity—colors, spacing, type—layers on easily later. The questions that matter early are structural: What’s the data model? Where does state live? What happens when this list is empty, or has 10,000 items?

Design system interlock

Once I have a few solutions worth pursuing, I bring in the design system. This is where sketching ends and shaping begins—where a rough concept starts to inherit the constraints and conventions of the product it might become.

Previously, this transition was high effort. You’d rebuild your prototype from scratch using production components, re-mapping every layout decision to the system’s grid, tokens, and interaction patterns. It felt like translation work—tedious and lossy. The sketch had energy; the systemized version often didn’t.

Now that gap is collapsing. At work, I can point an LLM at Atlassian’s Atlaskit component library or connect to our MCP server, and it will re-skin a rough code sketch with real design system components in minutes. The structure I built during the sketching phase—data model, state management, flow logic—carries forward. What changes is the surface: a plain <select> becomes an Atlaskit dropdown, a hardcoded list becomes a dynamic table with sorting and pagination baked in.

This is the interlock I care about. The design system isn’t a starting point—it’s a finishing move. You sketch unconstrained to explore the problem space, then snap your best ideas onto the system’s rails to see if they hold up. The LLM makes that snap nearly instant, so I can run the full loop—sketch, evaluate, systemize—multiple times in a single session. Ideas that break under the system’s constraints get caught early. Ideas that survive get stronger.

Because I started without the design system, there are style overrides—the UI won’t be pixel-perfect. But after screenshot revisions with the LLM and micro-prompting, I can get it to a realized state.

Contributing to new values and patterns

For design systems to remain relevant, they need contributions. Too often, the system calcifies—it caps innovation instead of enabling it. Sketching with code surfaces those gaps naturally. You find the places where the system falls short, and in doing so, you find opportunities to contribute back. To innovate on a system, you have to break it apart and put it back together.

This mode of working also lets you build your own tools along the way. I’m an admittedly lazy documentor, so instead of manually tracking proposed changes to our design system, I built a component tracker that documents them for me.

In addition to exploration tools, code sketches are communication tools. A running prototype changes the conversation in a room faster than any slide deck. People stop arguing about what something might feel like and start reacting to what it does feel like. A scrappy code sketch deployed to a URL has more persuasive power than a polished presentation. It builds conviction because it’s real—it runs, it responds, it has edges you can poke at. If you want to move a decision forward, demo before the memo.

Recap

If you start with the design system, you’ve already narrowed what’s possible. Resist the urge to reach for production components when you’re still exploring. Feed the LLM with images of your sketches and annotations—hand-drawn wireframes, screenshots, whatever captures the idea—and let it generate variations in code. Once you’ve found directions worth pursuing, bring the design system back in and interlock it with your findings. Weirdly, making apps is itself a form of sketching to get to the final app you want to build.

Hyperlinks + notes

• The MCP Tool That’s Changing How I Use Figma by Joey Banks

• 078 - Developing your sketching system

• 265 - The art of prototyping

• 271 - Strategy-to-Pixels

• 283 - How Product Discovery changes with AI

• pix2code: Generating Code from a Graphical User Interface Screenshot — Tony Beltramelli (2017)

• Make Real, the story so far — tldraw’s sketch-to-code demo

The answer is never static. What fills the shelves of a new platform economy always begins with the most obvious artifact—the thing that looks most like what came before—and evolves as builders discover what the platfo…

Read more

Read more

What is Product Discovery?

Product discovery is the process of figuring o…

Read more

Read more

Over the years, alumni groups have formed in technology compani…

Read more

Read more

Read more

Looking back, it’s no surprise that much of this year circled AI. It was inescapable. But I’ve been intentional about not tu…

Read more

Read more

This is not just an observation about LLMs. It’s about how huma…

Read more