Makers and builders need time to focus. This is where the first hour of work comes in. How you set the tone determines whether you spend the day fighting thankless fires or doing intentional work.

Sophia Leroy’s research on attention residue explains why switching tasks leaves part of your attention behind. Every time you jump from one thing to the next, a piece of your focus stays stuck on what you just left. As the day progresses and more things compete for you, that residue accumulates, and the attention you can actually bring to any single task erodes.

An hour of intention

If the first voice you hear is the inbox, you’re not starting the day right. Set the first hour aside before you begin tackling tasks. It’s the work before the work. A clear intention in that hour lets you control the momentum instead of inheriting someone else’s.

In baseball, there’s a move called the lead off. A runner on base takes a few steps off the bag in anticipation of the hitter making contact, ready to break for the next base. Sometimes they go further and steal it outright, beating the defense to the bag before the play even develops. The point of the lead off is that you’re already moving before the situation forces you to.

• What matters most to push forward?

• What needs to get done?

• What can wait?

Of the three, what matters most to push forward is essential because your vital few priorities likely are never done. Conserve time to work on those before getting to the checklist. Rituals matter, but they aren’t the driver of intention. They’re reflective and contemplative, and I do mine beforehand. My morning walk, coffee, and journaling are essential, but they aren’t the first hour of work and come before that. Now you’re seeing why I am awake several hours before starting work.

What to avoid

The goal of the first hour is to stay proactive. Avoid lapsing into a reactive state and being at the mercy of your calendar and the Slack messengers. Avoid:

• Check email or Slack

• Do not start by asking “what do I feel like doing?”

• Administrative tasks

The last one is the most dangerous, because it’s the most convincing. Clearing small tasks feels like accomplishment, but it’s not progress to what matters. These things need to get done, but don’t use your valuable headspace to set the tone of the day to do that.

Compounding the focus

I’ve told you what to avoid, so let’s talk about focus. The first hour is about having a proactive day, but it also compounds over time. I don’t work from a backlog in the first hour. I ask myself one question: “What are the three most important things I need to make progress on in the next five years?” Though the timeframe is just a proxy to frame the ambition, it’s a good forcing function to choose work that matters most to make progress.

Here’s how that tends to look day to day:

• Working on the most vital initiatives that lead to outcomes at work

• Writing for my publication

• Fostering long-term relationships that matter most

• Designing or coding the project I’ve wanted to build

The most important aspects of your work don’t have deadlines screaming at you. However, they are eroded by the noise of other things vying for your attention. They’re the things that quietly get crowded out unless I protect the time for them, and they’re also the things that determine where I’ll be in five years.

First hour, first move

The first hour may seem like a small thing, but done daily for years, the value compounds. You’ll feel more prepared and more proactive, pushing your work instead of getting pulled by it. Don’t let what you have to do dictate how you approach what you do.

Work can be never-ending. But if you build systems that let you control the terms of how it gets done, it becomes more fulfilling and more fun. That’s why the first hour is crucial. It’s the one hour you own outright, and everything else compounds from there.

Hyperlinks + notes

• Jira is Turing-Complete

• Investing Superstar Yasmin Razavi Turned A $75 Million Check Into A $3 Billion AI Windfall

• Fuser - Your workspace for evolving ideas

• Burn-9 makes an entire game out of Metal Gear’s Codec scenes

• i used to think that novels were a waste of time

• Code-as-Content Era

I needed to build trust, not with an audience, but myself to write. Since the early days, I have not missed a Sunday morning to share my thoughts on software, creativity, entrepreneurship, and experimentation. Some weeks are better than others, but what’s important to me is showing up and being consistent.

The 200 Series spanned from September 7, 2024 to May 31, 2026. To say there was a big emphasis on AI in the latter parts is an underestimate. Though I try not to write only about AI, it’s a relevant topic for many. Let’s reflect on themes throughout the years and the top posts that resonated with people, which I opened up for free to read.

To get everyone access to the entire archive, here’s a trial for seven days to have access to the archives. If it resonates with you, consider becoming a paid member!

Get one week trial

Themes

The essentialism of craft in the AI era

I truly believe the craft layer is the most important factor that remains when AI becomes normalized and commoditized. Building the best AI product means building the best product, even if it didn’t have AI. In 2023, people were excited to make something end-to-end, regardless of quality. Then the creation became abundant, and AI slop was what you strived to avoid.

Related posts:

• 218 - The obsession over craft

• 251 - A primer on vibe coding

• 252 - Software craftsmanship

• 265 - The art of prototyping

• 283 - How Product Discovery changes with AI

Software architecture and surfaces are changing

The way we are building software is changing. It’s both terrifying and exciting at the same time. People who never wrote a line of code are now shipping to the app store. Meanwhile, walled gardens and moats are coming down in favor of bridges and partnerships. As a Growth and Ecosystem designer throughout my career, this makes me very excited. It’s now a competitive disadvantaged to build in isolation. Apps and integrations need to go hand-in-hand.

Top posts:

• 250 - A new MVC is emerging

• 260 - Bring Your Own Memory

• 284 - Surfaces, capabilities, extensibility

• 287 - The future of software is interoperability

• 295 - Design Systems are now Inference Systems

Operating and leading

Operators and leaders haven’t been replaced yet. In fact, the ones who can adapt their way of working will compound everyone’s autonomy an agency. It’s a great era for the highly convicted, craft-oriented, and decisive.

Top posts:

• 212 - Operator Mode

• 267 - The three leadership pillars

• 275 - On succession

• 294 - The shape of leadership

• 231 - Making decisions happen

Ship, don’t speculate

Herb Keller, CEO of Southwest Airlines once had a saying, “We have a strategy. It’s called doing things.” As strategy goes from thoughtful planning to retroactively pattern matching what’s working. The iteration cycle is nearly zero, so the way we work needs to drastically change.

Top posts

• 240 - Strategy is compressing

• 268 - Approaching work

• 255 - Astronomer and astronaut

• 271 - Strategy-to-pixels

• 288 - Forward Deployed Designer

Career and people

Finally, there was a heavy theme on career and people. We are in the multi-modal and multi-generational era. I am towards the end of my career and seeing incredibly talented designers and founders rise up in the next generation. Despite the wonderful autonomy, many people want connection and guidance.

Top posts:

• 244 - Career reboot

• 281 - The alumni mindset

• 292 - The protégé problem

• 209 - Taking chances on people

• 243 - Scouting talent

Top posts

The ten most popular issues from this series, made free.

• 240 - Strategy is compressing

• 233 - When everyone can build anything

• 283 - How product discovery changes with AI

• 244 - Career reboot

• 231 - Making decisions happen

• 264 - The art of prototyping

• 218 - The obsession over craft

• 250 - A new MVC is emerging

• 267 - The three leadership pillars

• 241 - Skills are the new currency

Protect human and craft layer as we make sense of AI

Reflecting on the 200 Series, I realized how I am not an AI maximalist at all. I use it daily, work in the field of applied AI, but I’m a cautious optimist, which is what I think every Head of AI Design should be anyway. What’s important to me is to retain the craft and human layer of AI along the way; not because it’s holding on to an old way of working, but the skills of that area are more important than ever.

Whether you started reading from Issue 1 or 299, thank you for your readership; its what keeps me motivated to write the next 100.

Hyperlinks + notes

• AI in Design Report 2026 → Such a well-crafted report by

• Incredible few days at Hatch Leadership Ateliers. My recap

• , Chief Design Officer at Atlassian is now on Substack

• Regardless of what you think of the car, I love Cleo Abraham’s interview with Jony Ive and Flavio Manzoni on the new Ferrari

• AI is a slot machine by

• every book you read becomes a part of how you see by

Habits away from home

Traveling forces you to re-wire what you’re thinking about. You’re away from home, loved ones, and common routines.

Travel also changes your relationship to constraints. In a new place you might not have your usual tools, language, or routines. You improvise—gesturing instead of speaking, sketching instead of writing, using whatever’s at hand. That improvisation trains you to see limitations as prompts rather than barriers, which often leads to more original ideas.

Invoke boredom, let the mind wander

Boredom is one of the most important mental states for creative work. You need time to empty the mind and let it wander a bit. When I’m flying international, I intentionally don’t connect to wifi. No email or online frontier models; just my sketchbook and whatever I stored offline on my iPad. Only these hard constraints will force new perspectives.

If you’ve ever traveled with Starlink wifi, it’s amazing. The internet speed is faster than the bandwidth I get at home in Palm Springs. But I’d abstain from it. High bandwidth on a plane produces the same thinking as the home office. Without wifi, I ended up watching TV shows and movies only available on my iPad. During this flight to Sydney, I watched every Bruce Lee movie, which inspired me to write about applying Jeet Kune Do to running design orgs and my creative practice.

Though I could inevitably get there, there’s a low chance I would have arrived at that article idea sitting at home. When you’re on the road, let your mind wander to generate new directions.

“Capture or create” method

Travel creates heavy constraints on time, and you have very little of it. You don’t have the luxury of hours at your desk or studio. Unless you’re traveling explicitly for a creative retreat, creative work is secondary to your personal vacation or work trip. With so little time, you have to make the most of it. This is where “capture or create” becomes an important discipline. Forcing the contrast helps you be more effective with what you bring.

Capture mode

Capturing requires smaller equipment than your work or personal laptop. I carry three tools when I’m focused on capturing: my phone, sketchbook, and AI note taker device.

Though I love my Ricoh GRIII, my phone does the trick for photos, video, or scanning my sketches. My sketchbook is old faithful; the Leuchtturm1917 notebook. Despite many attempts at sketching with an iPad or e-ink tablet, the non-electronic notebook helps me completely disconnect. Finally, I recently picked up a Plaud AI note taker. I’m not a meeting recorder—AI summaries don’t work for me—but I do find value in a tool to capture voice recordings of ideas as they happen.

As I’m capturing, my team of AI agents synthesizes everything into my LLM Wiki. The work shapes up while I’m on the go.

Create mode

This is the sacred time when traveling. You need to create pockets of time where you can focus to write, design, code, and do other creative work. When I’m in Sydney, this might mean stopping by Georgie Boy’s Coffee or Regiment before heading to the office, or co-working with friends at Cafe 143 in Bronte Beach.

Unsurprising to regular readers, my go-to creating device is the 11” iPad Pro. Space and weight are critical when traveling, even during creating time. The iPad Pro gives me access to the workflows that matter. It’s the entertainment device that invokes the boredom—the same one that let me binge every Bruce Lee movie1. Consolidating entertainment with work saves a lot of room. It’s also a great Mobile Device Management device that lets me check on work without lugging my work laptop. And with Astropad’s Workbench, I can remotely connect to my Mac mini and laptops, getting the power of code generation without the heavy machines. Truly a three-in-one device.

Closing

The point isn’t to replicate your home setup on the road. It’s to use the friction of travel as a creative input. Boredom on a plane, constraints in your bag, the unfamiliar coffee shop in a city you don’t live in—these are the conditions that produce ideas you wouldn’t have had otherwise. Capture or create gives you a frame for using the small windows of time you do get, but the real shift is treating travel itself as part of the practice rather than an interruption to it. The sketchbook gets thicker, the wiki gets denser, and by the time you’re back home, you’re carrying material that home alone couldn’t have generated.

Hyperlinks + notes

• I’ll be in Amsterdam this week for I’ll be speaking at Hatch Conference’s Leadership Ateliers

• The Future of Design Tools, AI Strategy and Workflow Transformation with David Hoang | Building Iconic

• How structured thinking gives your AI superpowers → Get ready for Carola Pescio Canale’s talk at Config

• Cursor is now available in Jira

• Proof of Concept 253 - The travel work setup

• Proof of Concept 71 - The phone as mobile creative studio

• Proof of Concept 57 - Working on the go

• Proof of Concept 42 - Quick Capture to Maximize Actionability

Down, down-forward, forward, punch.

I didn’t know what those inputs meant the first time I saw a fireball come out of Ryu’s hands. I knew it looked like the most powerful thing a person could do with a quarter.

I became obsessed with fighting games. My brother and I would buy any fighting game we could on our Sega Genesis to unlock the special moves. Going to the arcade became a frequent hobby. Imagine the joy when we discovered an arcade called Nickel Palace, where for a small entry fee you could play any game for 5 cents instead of a quarter.

There was a new game in town: Mortal Kombat. A hyper-realistic and violent challenger to Street Fighter. I decided to give it a try. Of the seven characters available, I picked the blue ninja, because you always pick the ninja. Sub-Zero.

I had zero onboarding. No manual on the carpet, no time to study a move list. The controls were a bit different than Street Fighter, but I tried the Hadouken input anyway.

Down, down-forward, forward, low punch.

Sub-Zero threw a freeze projectile and froze my opponent in place. That moment did something to my eight-year-old brain that I didn’t have the vocabulary for at the time. The input wasn’t a Street Fighter thing. It was a grammar. A motion that meant “throw something” across an entire genre. The move list in the manual had been teaching me the wrong lesson; I thought I was memorizing facts about Ryu. I was actually learning a language.

Special moves are shortcuts and patterns

The same grammar shows up far outside the arcade. Early Photoshop users found their Hadouken moment when they learned keyboard shortcuts. Cmd-J to duplicate a layer. Cmd-Option-Shift-E to stamp visible. The first time you string them together to flatten a comp, dupe it, run a filter, and mask the result without ever touching the mouse, you feel the same thing the kid felt pulling off a fireball in the arcade. The action collapses in time. Six menu trips become one fluid motion.

Macros are where that fluency turns into combos. Actions in Photoshop, snippets in code editors, Shortcuts on the iPhone, custom skills for Claude. A sequence of moves you can fire as one. Designers wiring up multi-step prompts to a hotkey are running the same playbook as the Killer Instinct kid memorizing a 47-hit Ultra, finding the inputs that, in sequence, produce a result larger than the sum of their parts.

The cognitive science calls this chunking. With enough repetition, what used to be a string of discrete keystrokes becomes a single learned phrase. The hand stops asking what comes next; it already knows. The work migrates out of working memory, where every step costs you attention, and settles into procedural memory, where the sequence runs on its own. Your mind is freed up for the thing the hand is in service of.

Special moves and combos are patterns made portable. Skills you’ve practiced enough times that they no longer cost you attention.

Developing your move set

Your move set develops the way any craft does: through experimentation and practice, figuring out which moves fit your style of work. A Design Engineer’s move set looks different from an Icon Designer’s. A researcher synthesizing interviews works from a different vocabulary than a brand designer kerning a wordmark. The moves are shaped by the surface area of the craft.

The way you build a move set is the same way the arcade kids built theirs. You try things. You fail a lot. You watch people who are better than you and steal what they do. You read the manual. You spend a stretch of time being deliberately bad at something in order to be quietly good at it later.

Deliberate practice is the part nobody romanticizes. Anders Ericsson’s work on expertise pointed at something specific: the people who get great at something practice harder on the parts they’re worst at, with feedback they can act on. Competence is where most people stop. For experts, it’s where the real work starts. You don’t become an expert unless you’ve been a novice for a long time.

Mastery without mashing buttons

Every fighting game player started by mashing buttons. Random inputs, hoping a fireball would come out, occasionally winning by accident. Mashing is how you find the inputs in the first place; it’s the entry point to noticing that some sequences do things and most don’t.

Pick a move. Practice the input until your hand knows it. Find the next one. String them together.

Here’s the truth. It’s a lot of fun. It’s exhilarating to see the agents thinking and co-building with them. It feels like a productive high instead of doom scrolling social media, but it has similar effects. I remember going to a dinner with friends. Over an incredible omakase meal, we all naturally took a bit of a break to check our phones. It wasn’t a social media break. It was an agent orchestration break.

It’s a lot of fun, but it’s exhausting. Ironically, as the agents are thinking, I found myself having less time to think. This is where I changed my toolchain in hopes to get time back. Before I jump in, let’s elaborate on what Human in the Loop (HITL) and Human on the Loop (HOTL) are, what the difference in the methodologies are, and examples of how I’m changing my schedule and rituals to get more focus time all the while building with agents.

Human in and on the loop

Human-in-the-loop (HITL) means the system cannot proceed without you. The human is a gate in the causal chain. You approve every draft and proposal. The agent waits for a response and won’t do anything until the human inputs something. The term traces back to flight simulation and was adopted by the Department of Defense in 2012 to describe semi-autonomous weapons that could not engage a target without human authorization.

Human-on-the-loop (HOTL) means the system runs on its own and the human supervises. You watch the dashboard, you check the alerts, you sample the work, you intervene when something looks wrong. The classic example is a Phalanx air defense system that can engage an incoming missile faster than any human could authorize the shot; a person is on the loop, not in it, because the speed of the engagement makes a true gate impossible.

I know. We went from missile defense to your Tuesday afternoon pretty quickly. The vocabulary comes from a domain where the stakes are absolute, which is exactly why it is useful for thinking about everyday AI work — it forces you to be specific about where the human actually sits, instead of waving at “oversight” and hoping it counts. Stanford HAI reframed all of this for AI design as a Human-Computer Interaction problem rather than an automation problem, which is the right move. The checkpoints and considerations carry over. The stakes are different. You are not authorizing a strike. You are deciding whether to approve a pull request, ship a draft, or let an agent reorganize your inbox. The framework still asks the same question: what is the human doing here, and is that the right place for them to be.

The agentic equivalent of doom scrolling

At times, HITL agent orchestration feels addictive like Candy Crush or scrolling social media. Every prompt shows a stream of tokens and visible progress being made. You sit and wait to hit the number 2 or continue prompting. Instead of doom scrolling, you’re doom building; a sense of productivity which leaves you not doing anything else.

To be abundantly clear, I’m not against HITL and it’s a great way to build. What I’m saying is the massive productivity gains take a toll on you. I’ve shipped real work this way; being locked in for entire afternoons and evenings to prompt sessions. Sometimes I get good outputs and other times I don’t get anything valuable.

The orchestration tax is like the coordination tax at work. I’m feeling like I’m building but really air traffic controlling in parallel. You are reading partial outputs, deciding which to merge, which to discard, which to re-prompt. It’s a job, and an important one, but it’s not the deep work in design, writing, or thinking I need to do.

That is a real job. It is not, however, the same job as design or writing or thinking. It uses a different part of you and it depletes a different reservoir. By the time I sit down to actually draw something or write a paragraph that matters, the reservoir is empty.

I orchestrated my way out of having anything to say.

Agentic manager and maker schedule

Paul Graham has an infamous blog post about Maker Schedule vs. Manager Schedule. With agents, I’m doing both and it’s important to re-design my schedule around it. I need time for deep thinking and work with limited distractions; HITL agent orchestration is the opposite of that. This is when I change my agent workflow to foster HOTL as much as possible.

I set up Ren Talon, my OpenClaw, as a local orchestrator agent: one conversational front door that can route work to specialized sidecar agents for writing, creative exploration, personal assistance, Australian context, and knowledge work1. Each sidecar has its own workspace, memory, skills, and permissions, so Ren can delegate without blending contexts or leaking sensitive information across domains. The result is a small multi-agent operating system running on my own hardware. Ren handles intake from chat and tools, decides which agent should think through the work, then reviews and composes the response before anything goes back to me, Trello, Discord, Obsidian, or eventually Jira.

Human-on-the-loop only works if the supervision is real. Human Rights Watch made this point about weapons systems and it is just as true for knowledge work: a person who is technically on the loop but is supervising a dozen autonomous systems at once is, functionally, out of the loop.

If I am going to delegate project management to an agent, I need a real review cadence; a time on the calendar where I actually look at the work.

This is the agentic manager schedule.

Here is what that looks like in practice. The old way: I’d kick off a Rovo Dev session to triage open issues, then sit there reading the stream, nudging it mid-thought, asking follow-ups, watching it work. Multiply that by four other agents on four other tasks and the morning was gone. The new way: I launch the same session with a clear scope and a definition of done, close the window, and put a 4pm review block on the calendar. At 4pm I open every agent at once, read what shipped, accept or redirect, and close them out. The work gets done. I get the day back.

The shift is from watching to bracketing. Agents need start conditions and end conditions, not a babysitter in between.

So the practice is two things at once. Move more work out of synchronous attention to focus on deep work. Build real review surfaces for the work you moved. Both halves matter. The first without the second is abdication. The second without the first is just human-in-the-loop with extra steps.

Picking the vital few to stay in the loop

I am moving the default from in-the-loop to on-the-loop for everything that is not creative work. Knowledge management, project management, status updates, meeting prep, research synthesis, calendar logistics, repository hygiene, and anything I can have agents run asynchronously to I can spend time on creativity and elevating the human experience.

With the focus time, I can design by hand, write emails personally to people, and other work I want to spend intentional time on.

Writing, sketching, design critique, code I actually want to learn from — I go the other direction, hard. Full human-in-the-loop, with intention. The agent becomes an instrument I am playing, not a stream I am moderating. I keep the longhand notebook open. I draw before I prompt. I treat the model as the second pass on a thought I have already committed to paper.

I’m not trying to increase productivity. I’m trying to increase my effectiveness. I’m re-designing where my attention sits in the system. I push my agentic work to HOTL because most work does not benefit from my synchronous involvement and actively suffers from it. Some of the day I want to be deeply, deliberately in the loop, because that is where taste develops and where original work happens — the kind that has my fingerprints on it, not just my approval.

Keep the agents running, but focus your attention on the vital few tasks that matter.

Hyperlinks + notes

• Atlassian Team ’26: Meet the AI-Native Organization → Monster effort by the team to make this happen; incredible week

• How to stay calm on a hectic day

• Every Harness Will Become A Claw → Bullish on sentient lobsters

It couldn’t be more wrong. The people who think design is the first casualty only want the output of something they couldn’t do. Let’s look at the fast production problem and why good draftsmanship will save us. First, let’s look at the various forms of draftsmanship across various crafts.

In architecture, draftsmanship comes from the section drawing and plan. It forces three-dimensional spatial thinking onto two dimensions. You can’t draw a building without understanding every single floor and detail. Industrial designers commonly use foam models along with the sketch. In game design, companies such as Valve are notorious for paper prototypes. Instead of writing any code, game developers would print out cards and make tokens to play the game. In film, iconic directors such as Ridley Scott and Stanley Kubrick drew almost every frame before shooting. Ridley Scott calls the storyboard “the first look at the film.”

When I write, I keep a longhand notebook and outline to sketch my ideas. The act of writing by hand slows down my thinking enough to find the actual argument. It’s the only counter-measure I have to agentic orchestration and the chaos of a company Slack thread. Drawing is reasoning for humans.

Good draftsmanship sharpens the craft

Draftsmanship develops the cognitive muscle behind the work; something a prompt can’t do for you. The first skill draftsmanship builds is diagnostic capability. Drafting is how you see problems early. You can’t catch what you never had to work through. Teams that skip the draft lose the ability to identify structural issues before they become structural problems, and by then, they’re expensive.

Then there is taste and judgment. People talk about this being a differentiator, but many spend the time to develop it. Skills aren’t a plugin or a markdown file but forged through critiquing and evaluating work. It calibrates through practice, and practice requires you to do the work.

If you start from the prompt, you’re likely curating someone else’s existing output. It’s a different cognitive relationship to the work. If you start drafting, even if you’re inspired by other ideas, you’re starting your point of ownership. If you begin with your origin point, you can communicate, defend, and explain every decisions.

The final way draftsmanship sharpens your craft is it opens serendipity. The act of working opens thoughts and ideas you otherwise might not have pursued. Great ideas throughout history spawned from the moments of feeling stuck, sketching through it, and getting to that spark of inspiration. The generative friction of drafting is where original thinking happens. If you skip it, you skip discovery.

The draft is the prompt spect

The draft is the prompt spec. And in many cases, the drawing is the literal input.

When you photograph a hand-drawn wireframe and drop it into Claude, v0, or Cursor, something interesting happens. The sketch doesn’t need to be precise — it needs to be structurally clear. A lo-fi drawing carries spatial information that a paragraph of description rarely achieves. The tool reads the intent; you supplied the thinking.

The same holds for identity work. A pencil sketch of a mark fed into an image tool captures the essential gesture of the idea in a way that words can’t. The hand found the idea. The tool built it. That’s a meaningful division of labor — but only if the hand went first.

Game designers who draw flow diagrams of their mechanics before writing rules documents get cleaner output than those who describe the system in prose. The diagram forces systems clarity. It makes the relationships between components explicit in a way that language tends to obscure. An LLM reading a well-drawn game loop diagram produces better rules text than one reading a well-written description of the same loop.

The same logic applies to data modeling. A whiteboard Entity Relationship Diagram photographed and prompted into a schema produces cleaner architecture than a described one. Engineers who draft their data models by hand before prompting consistently produce better output — because the drawing resolved the ambiguity before the tool had to guess at it.

Storyboard frames as reference images for video generation. Rough floor plans fed into Vizcom or Spline for spatial exploration. In each case the drawing sets the structural intent and the tool handles execution. The sketch is not a precursor to the real work. It is the spec.

Drafting is the rapid alignment tool

As the speed of execution increases, the risk of team misalignment also does. Drafting is the rapid alignment tool to ensure teams are building the same thing. Before a building goes up, everyone looks at the same drawing. The blueprint is what makes collective thinking possible because it’s a shared artifact between architect, engineer, the contractor, and client; all reacting to the same thing. The drawing makes disagreements visible before they’re structural. You can argue about a line on paper. You can’t argue about a poured foundation.

When teams skip the draft blueprints, everyone has a different alignment assumption in their mind. There is nothing to mark up together. Prompt responses don’t create that moment as it arrives too complete and polished for real interrogation. As a result, teams feel it’s pointless to debate something already built. The conversation the sketch would have resolved that.

I’ve seen this in product work. The wireframe artifact that reveals two people had completely different mental models of the same feature. The whiteboard data model where the flaw in the architecture becomes obvious to everyone in the room at the same time. The paper prototype that exposes the broken mechanic before anyone wrote a line of code. These aren’t slow moments. They’re the moments that prevent the expensive ones.

AI is very good at accelerating individual output. It has no native mechanism for what happens when a team gathers around a drawing. The sketch does that. Lo-fi, unfinished, open — it holds the space for collective thinking in a way that a finished output never can.

The teams that draft together stay coherent as speed increases around them. Not because they’re slower. Because they’re looking at the same drawing.

Think before you generate

The best use of AI is as a collaborator after you’ve drafted. Your thinking goes in, sharper output comes out. The tool earns its place in the process because the process was real. Most people prompt before they’ve thought and accept the result as thinking. The blank page gets filled, the build gets faster, and what’s lost is invisible — the cognitive work that would have made the output good, the diagnostic pass that would have caught the problem early, the shared drawing that would have kept the team pointed at the same thing.

Draftsmanship was never about producing artifacts. It was about producing understanding. The drawing was how you found the idea, stress-tested it, and brought other people into it. That hasn’t changed. What’s changed is how easy it is to skip it.

I still keep the notebook. I still sketch before I build. Not because I’m resistant to the tools — I use them constantly — but because the thinking I do on paper shows up in the work in ways I can’t fully replicate by prompting alone. The drawing finds things what you miss to prompt.

Keep draftsmanship sacred.

Hyperlinks + notes

• friendship is a series of affordances offered and accepted by

• Research Week

• Introducing the a16z Design Engineer Fellowship

• Yeah, Andy Serkis didn’t really know who Snoke was while filming Star Wars, either → Hilarious!

• Spirit Airlines Officially Shuts Down After 34 Years of Operation

• OpenAI introduces AI-generated pets for its Codex app

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 |

Read more

This wasn’t the first iteration …

Read more

Read more

Read more

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 mo…

Read more

Ske…

Read more

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 out what to build before you build it. It’s how teams de-risk the question mark between having a goal and deciding to build.

The key risks teams seek to understand:

• Desirability: Do customers actually want this?

• Viability: Does it work for the business?

• Feasibility: Can we build it?

• Usability: Can customers figure out how to use it?

The process operates in two interconnected loops:

Exploration of the Problem Space — the divergent phase, where you expand possibilities. You research to understand the problem space, ideate to generate potential solutions, and evaluate to narrow down which directions have merit. This loop is about opening up.

Validation of the Solution Space — the convergent phase, where you test assumptions. You prototype to make ideas tangible, test with real users to gather evidence, and learn to inform what’s next. This loop is about closing in onthe truth.

Both loops orbit around the central uncertainty: What should we build? The Goal informs where you’re headed. The Build is the outcome of successfully navigating that uncertainty.

Teresa Torres wrote the playbook on this with Continuous Discovery Habits—weaving customer input into daily product decisions rather than treating research as a phase.

How AI shifts the balance

In Jenny Wen’s talk at Hatch Conference in 2025, “Don’t Trust the Process,” she raises an important point: the processes we’ve established are rapidly becoming lagging indicators. Process is important, but it should work for you, not the other way around.

People worshipped the process artifacts, not the final result. We’re in a moment where the moment you document a process, it becomes irrelevant. I don’t believe it’ll be like this forever, but until software is completely rewritten with AI as a core capability, it’s going to be like this for a while.

So, where does Product Discovery change? Let’s revisit those four risks.

Feasibility: dramatically reduced. Building software used to be the hard part. A feature that would have taken a team two sprints can now be prototyped in an afternoon. I recently built the first version of Tapestry in a few hours—something that would have taken weeks before.

Viability: easier to test. When you can deploy a working prototype to production cheaply, you can get real market signals faster. You’re not guessing whether something could work as a business; you can find out.

Usability: faster iteration. You can generate multiple UI variations, test them, and refine quickly. The feedback loop tightens.

Desirability: unchanged. This is the one AI doesn’t solve. No amount of synthetic personas or simulated user research replaces the insight you get from watching a real person struggle with your product, or hearing them describe a problem you hadn’t considered. Desirability still requires humans talking to humans.

The implication: when three of four risks become cheaper to address, the remaining one—desirability—becomes the differentiator.

My evolving approach

Product Discovery is more important than ever, but my process, methods, and tools have changed drastically.

Sketching with code

I still start with pen and paper. That hasn’t changed. But the paper sketch isn’t what I put in front of people anymore. I sketch with code at various fidelities.

Here’s what I mean: a “low-fidelity” code sketch might be a simple HTML page with hardcoded data—enough to show the flow and get a reaction. A “high-fidelity” code sketch connects to real APIs and handles edge cases. The napkin sketch and paper prototypes are still how I think through problems, but code is how I communicate them.

At One Medical, this looked like building quick prototypes for the Labs experience during a Google Ventures design sprint. At Webflow, it was creating functional proofs-of-concept for layout features before committing engineering resources.

Prototyping in production

When I was a Design Technologist, the best prototype was one I could build off a branch of the functional app with a staging server. Now I prototype in production environments.

Take my project Tapestry. I built my hypothesis as a Replit app and deployed it to production. The first version was a traditional CRM with AI capabilities layered on top. I built it in a few hours—I would never have done this in my old approach because it would have taken too long.

I invited a few people to use it. I got feedback in a production environment—real data, real usage patterns, plus their qualitative feedback. From those insights, I’m now pivoting Tapestry to be more decoupled from the CRUD app. The focus is shifting to a service and an MCP server so people can use their LLM of choice to manage their relationships.

Important distinction: having something in production doesn’t mean you’re releasing the product or going to market. It can remain a closed beta. Production is just a better testing environment than staging. In the new world of Product Discover with AI, you can pivot dozens of times before you ever launch the product vs. after the fact.

Spending most of my time on desirability

Since AI compresses the time I spend on feasibility and viability, I now spend most of my time on desirability—talking to people, understanding their problems, and watching how they react to prototypes.

There are AI tools that claim to provide signals about virtual customer personas. I don’t use them for primary research. I spend my time with humans. The hard part was never synthesizing research findings; it was getting the right insights in the first place.

The new question

Product Discovery with applied AI is going to feel uncomfortable. It will feel like seeking a solution, looking for a problem, because the prototype and build is no longer a phase but a nearly-immediate loop.

In my talk for Maze’s Disco conference in 2022, I argued that Product Discovery is a method, a capability, a culture, and a navigation tool. That’s still true. But the emphasis shifts.

When AI can build almost anything quickly, the question changes from “Can we build this?” to “Should this exist?” And that’s a question only customer insight can answer.

As the ability to build anything becomes immediate and inexpensive, Product Discovery is more important than ever. Spend the majority of your time on understanding desirability.

Hyperlinks + notes

• Join our AI Design team!

• A Practical Guide for Product Teams by Tim Herbig

• Continuous Discovery Habits: Book Summary by Reshuka Jain

• This tiny pocket-friendly e-reader is packed with frustration and potential → What is this, an e-reader for ants?

• Moltbook → I am absolutely not sending my OpenClaw agent here, but this is fascinating

• Maddie Reese’s OpenClaw gets a body to create a Tamagotchi-like experience → The metaphor of a lobster is quite fitting as AIs seek their shell

Read more