The interesting part of agent loops isn’t how to keep an agent running. It’s knowing when the work is understood well enough to let it run.

Peter Yang, interviewing Claude Code’s Thariq Shihipar on Behind the Craft, asks about Claude Code’s new loop, goal, and workflow features. Shihipar describes /goal less as an autonomy switch than as a signal that the uncertain work has already been done:

/goal is great when you have a complicated task and need to make sure it is done at the end. It’s the user indicating, “I’ve done enough specification and exploration. I understand the problem space. Just go execute on it, and if you run into something, fill it in.”

That puts a useful boundary around loop engineering: don’t ask the agent to power through ambiguity you haven’t investigated. Shihipar treats planning as the work of reducing that ambiguity:

We often talk about plans as one shot: you plan, then you do something, and that’s it. But planning is an iterative process of exploring, investigating, and finding out what you don’t know and what you want.

A few minutes later, he gives that process a better name:

I like to call it getting rid of your unknowns. With almost any task, there’s a lot you don’t know—either how things work or what you want. It’s very iterative. You don’t write it all down once and then implement it. There are many steps and different passes.

Implementation doesn’t end that process. Shihipar asks the agent to keep notes about what it discovers while building, then feeds those discoveries back into the specification:

The model can find things that it—or you—didn’t anticipate during implementation. I ask it to keep implementation notes as it goes: what did we not expect about this implementation? Once we have that, we can respec if needed. It’s much less one handoff from specification to implementation and more a back-and-forth process.

That’s the more useful loop: explore until “done” is concrete, build the smallest version that can expose what the plan missed, then revise the plan from what the build teaches you. Longer-running agents are the consequence, not the point.

Quotes lightly edited for clarity.

Wayland is a display protocol many Linux desktops use to coordinate how applications draw to the screen. Its “every frame is perfect” goal means users should see a complete, coherent image rather than partially updated output. Nikita Prokopov argues interface designers should hold transitions to the same standard:

A stated goal of Wayland is “every frame is perfect “.

And I think this is a goal we should all aspire to. Wayland is talking about the technical side of things (modern GPU stacks are very complex and Wayland is trying to take control back) but it could be applied to UI too.

His screenshot test belongs in design review. Stop the transition at arbitrary points and ask why each component is where it is.

Prokopov shows how a small mismatch becomes a larger trust problem:

Not the end of the world by any means, but it does create a feeling that these two components are not in sync with each other. Next thought: maybe they weren’t designed together? If so, then they might not work well together. That’s how trust is lost.

Motion can also tell the user something happened when it didn’t:

This creates a false feeling that something subtly changes when you switch between modes. And you know what? I don’t want my UI to give me false feelings. I want it to be a precise instrument, not an animated toy.

The click-target problem is why I’m fine with macOS’s mandatory squircle. Older icons sometimes made negative space look clickable when it wasn’t. Apple’s uniform shape makes the target predictable—a small accessibility improvement worth the trade, IMHO.

Louie Mantia, writing on the Parakeet blog, explains the icon designer’s tradeoff:

Masking all of these app icons to a squircle, and even applying Liquid Glass effects to them, aims to solve this problem. And this follows the same principle of iOS 7, which is to make it easier for all apps to fit in on the platform, especially apps built by designers and developers who aren’t familiar with how to make an icon that looks great next to first-party icons.

Just so I’m clear about my preference, I would love if Apple provided a way for designers to poke outside that squircle boundary. Some of my favorite app icons did that. But also some of my least-favorite app icons ignored this shape entirely, when it was used for every system icon in the last five years. Whenever those apps showed up in my Dock, it was like a stain on my shirt I couldn’t get out.

Despite the genuine loss associated with the squircle restriction, there’s more than one way to design with it.

Mantia is right that Apple handled some older icons poorly. Designs made specifically for the pre-Tahoe squircle were shrunk and placed inside the new one, punishing designers who had followed the previous rules. But Mantia’s broader point holds. The Dock also has to accommodate neglected utilities, unmodified corporate logos, and apps whose makers never learned the platform’s conventions. The squircle makes more of them look correctly sized next to one another.

Mantia goes beyond visual consistency and describes the shape’s semantic job:

Seventeen years later, now that app icons on macOS do have a uniform rounded-square appearance, they do look better adjacent to each other in the Dock. What’s even better is that over the last 19 years, apps on Apple platforms have distinguished themselves with a very recognizable visual identity.

The shape of apps is a squircle. And it has been proven to work for everyone. Companies can use their logo as an app icon. Designers can create something specifically for the platform. And both of these get to look like an app. Whether people consider the squircle a container or a canvas, this uniform appearance communicates its function: a squircle represents an app, just like how a piece of paper represents a digital document, or a folder represents, well, a folder.

Jihoon Jeong asks the question: if the model starts fresh each cycle, what actually compounds? He uses software developer Geoffrey Huntley’s Ralph Wiggum loop to illustrate:

If the loop’s power came from looping — from persistence of effort, from the agent grinding away at the problem — then the longer you could keep one agent going, the better it should get. The opposite is true, and every practitioner knows it. A long agentic session curdles as its window fills with dead ends and stale state; the agent gets worse with continuity, not better. The winning configuration, rediscovered by everyone who runs loops at any scale, is maximum discontinuity: kill the agent every iteration, resurrect it blank, and let it inherit nothing except what the last iteration wrote to disk. Huntley’s design wasn’t naive. It was surgical. Discard the mind, keep the files.

Fresh context is only useful if the loop can tell progress from activity. Jeong puts that burden on the verifier:

Second, one of the five decisions is load-bearing in a way the others aren’t. The verifier is the wall the whole structure hangs on. A loop repeats whatever its verifier accepts; if the verifier is strong — tests, compilers, benchmarks, anything with teeth — the loop compounds progress, and if the verifier is weak, the loop compounds output. Every experienced loop practitioner converges on the same rule: the loop is exactly as good as its stopping test. A loop with a weak verifier isn’t an autonomous engineer. It’s an expensive random walk with excellent posture.

Jeong’s answer is that the model starts each cycle from scratch, while plans, tests, commits, and code preserve progress for the next one:

The loop works, and the skeptics are right about why its working is strange. It adds no intelligence. It makes no model smarter. It rents the same brilliance every cycle at full price, extracts what it can, and throws the brilliant thing away — keeping only the residue on disk, because the residue is the only part that compounds. It works better than it has any right to, exactly as I said last time. And its characteristic failure mode is now visible at scale too, and it is not a crash. It’s a flatline. The loop keeps turning, the tokens keep burning, and the density of correct answers stays wherever the verifier pinned it — because nothing inside the system learns from one cycle to the next. The agent that finishes iteration forty is precisely as capable as the one that started iteration one. Only the pile of files has grown.

After Addy Osmani’s introduction to loop engineering, Robert Ross, writing at The Thought Drop, opens up the machinery. What looks like one agent loop is really three nested loops:

Agent loops are often oversimplified. They’re presented as a single loop, when really it’s three loops in a trench coat that make up an “agentic” experience for a customer. I’m here to write (yes, I wrote this, insane right?) yet-another-blog about agent loops. The example code blocks are also pseudo-code and for illustrating these ideas. Also I’ve omitted streaming, which complicates the post but the shape of these stays the same.

Those are the inference loop, which manages model calls and conversation history; the tool loop, which turns model output into actions; and the human loop, which approves, rejects, or redirects consequential work.

Ross’s “brain in a jar” analogy explains why the tool loop changes a model into an agent:

LLMs are brains in a jar. They provide no functional value on their own. The tools you give an LLM are what make it an agent.

When you tell a model “here are the tools you have” in your outer inference loop, the model may try to “use” them in its inference (response). This is the same thing as a brain sending an electrical signal telling your index finger to hover over the enter key of the email you desperately want to send Laney. Tom, we need to set boundaries my man.

The separate tool definitions you include in your API request are usually serialized into the system prompt field of the token stream the model processes. And it may infer the usage of multiple tools in one turn. (Hence: Tool Loop).

The human loop is the final layer—and the hardest to build:

The Human Loop is arguably the hardest part to implement in agentic systems. You can’t have a piece of code block for hours. What if the server restarts? What if you have thousands of other requests coming in you need to respond to? The first two loops (inference and tool) are simple enough. The human loop ups the ante of difficulty. This is why durable execution frameworks exist, like Temporal.

But the human loop is necessary, because it’s the only thing stopping Tom from actually sending that message to Laney. IT WAS TWO YEARS AGO TOM, MOVE ON!

We’ve heard about prompt engineering and then context engineering, and now it’s loop engineering. Googler Addy Osmani offers a clear introduction to it, beginning with a simple definition:

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop here can be thought of a recursive goal where you define a purpose and the AI iterates until complete.

What changes is who keeps the work moving:

For like two years the way you got something out of a coding agent was you wrote a good prompt and shared enough context. You type a thing, you read what came back, you type the next thing. The agent is a tool and you are holding it the entire time, one turn after the other. That part is kind of over, or at least some think it’s going to be.

Now you build a small system that finds the work, hands it out, checks it, writes down what is done and then decides the next thing, and you let that system poke the agents instead of you. I wrote before about the cousin of this, agent harness engineering, which is making the environment one single agent runs inside and the factory model - the system that builds the software. Loop engineering sits one floor above the harness. The harness but it runs on a timer, it spawns little helpers, and it feeds itself.

And the loop itself has a recognizable anatomy:

A loop needs five things and then one place to remember stuff. Let me list it first and then map it.

1. Automations that go off on a schedule and do discovery and triage by themselves.
2. Worktrees so two agents working in paralell dont step on each other.
3. Skills to write down the project knowledge the agent would otherwise just guess.
4. Plugins and connectors to plug the agent into the tools you already use.
5. Sub-agents so one of them has the idea and a different one checks it.

Then the sixth thing, the memory. A markdown file, or a Linear board, anything that lives outside the single conversation and holds what’s done and what is next. Sounds too dumb to matter. But it’s the same trick every long running agent depends on and I went into it in long-running agents, the model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesnt.

Karo Zieminski and Dheeraj Sharma recommend starting with a critic: one recurring job, one explicit standard, and a loop that stops before autonomy outruns our ability to inspect it. Their example reviews PRDs, but the pattern fits any creative work whose quality we can describe clearly enough to test. Sharma grounds that advice in the 30-plus agents he has built for his content operation:

I have built 30+ agents that now keep a real content operation running across my newsletter and YouTube channels. You’d be surprised how modest the useful ones look. If you start with an agent that “runs your whole business”, you’ll most likely build something fragile. OpenAI’s advice is to maximize a single agent’s capabilities first before even thinking about multiple agents. Anthropic’s rule is even stricter: add complexity only when it demonstrably improves outcomes. One agent, one job, one loop.

The rubric is the consequential design artifact. It turns tacit judgment into criteria the agent can apply consistently and the human can challenge. The retry limit matters for the same reason: repeated failure becomes evidence that the product thinking needs work, rather than an invitation to let the loop run forever.

A real critic checks whether the doc can do its job after engineering pokes holes in it. It needs to be forced to review every PRD through the same fixed format (every single time), and come back with a score, a diagnosis, and a concrete fix list. It also needs a retry limit. For PRDs, 2–3 rounds is usually enough. If it still fails after 3 loops, revisit the product thinking. And keep notes about every failure. Anthropic’s evals guidance treats every bug as a test case. The PRD your critic scored wrong last week is the exact document you re-test it against after every change.

For designers, this is a practical way to keep judgment inside the system. The agent can expose weak reasoning and carry the review process forward; deciding what deserves to ship remains a human responsibility.

I always come back to the same rule: agentize the tasks, not the craft.

Use your agents to move the PRDs to GitHub, but review them first.

Keep human decision gates at the moments where judgement matters.

Keep using the parts of your brain that make the work yours. Keep the joy you find in creating it.

Claire Vo, who built a bug-triage harness for her company ChatPRD, offers a usefully plain definition of an AI harness. The important part is that the intelligence does not live only in the model. Some of it lives in the surrounding code that prepares the work, limits what the agent can do, and decides what it must leave behind.

A harness is some code around an AI agent. Yes, you heard it here first. A harness is just code around an AI agent that makes it more effective. Can that code have AI in it? Sure. Does that code have to have AI in it? Not necessarily. What is the goal of a harness? To make the AI better. It is so simple, and I feel like the way that people have been talking about this has made it such a mystery that I wanted to make it very clear to you all. It is just writing more code around your AI to make it more useful for a specific use case.

Vo’s threshold for building one is equally practical: look for work where the setup and expected result recur.

So what are the parts of a harness? Well, a harness is going to have specific context. It’s going to be able to take specific actions, and it’s going to have a goal of specific outcomes. It’s just as simple as that. And I want to talk about when it makes sense to build a harness and when it doesn’t. I think you’ll want to build a harness when the same workflow needs the same setup and the same outcomes. It’s really when there is a combination of deterministic and non-deterministic workflow, step-by-step process, tools, and use cases you want your AI to follow to do a specific job.

That turns harness-building into a design problem. The work is choosing the job, shaping the workflow, narrowing the tools, specifying the artifacts, and creating an interface through which a person can direct and inspect the system.

I identified a specific workflow. I determined what the run against the task would look like. I made very opinionated calls to tools or data sources. I didn’t just say, “Use an MCP,” although that could be part of your harness. What I did is make adapters that made the calls to these external APIs and tools very specific. I thought about what the structured artifacts out of that workflow might be. I decided what rules and permissions I wanted to give this harness and which ones I didn’t. I decided whether I wanted to use Claude Code or Codex or a model router to actually run these things. And then I built a surface to interact with this agent. It could be a TUI. It could be a CLI. It could be a web app. But I built some way to interact with this.

The model supplies capability. The harness makes a repeatable workflow legible and enforceable.

Christine Vallaure, a UI designer who teaches Figma and AI workflows, offers designers a map of the hidden infrastructure between a convincing Figma-to-code demo and a production workflow:

The demos show you one clean layer working under perfect conditions. Your actual work needs three or four layers stacked together, and nobody shows you the stack, because the stack is where it gets messy and half-solved. The confusion comes from not knowing they are separate things at different stages that need different skills.

A useful distinction is between context and connection. Figma’s Model Context Protocol (MCP) connection can expose the file, markdown can preserve working rules, and skills can make repeated tasks more consistent. None of those guarantees that a generated button is the button already maintained in the product. That takes an explicit mapping to the codebase, plus someone responsible for keeping it current.

Look at the whole stack. Each layer covers the hole under it. The pipe lets Claude see your design. The note carries your rules. The recipe keeps your repeated jobs consistent. And the mapping, the top layer, is the only one that truly welds design and code together so they never drift.

But that top layer needs a codebase, developers, and constant upkeep. Most people do not have that, and should not pretend to. So for almost everyone, the design and the code will drift the moment either side changes, and that is not a sign you set it up wrong. It is simply what these tools are without the expensive wire: they take a snapshot and build from it. When things drift, you regenerate. You do not try to hand-repair a connection that was never really there.

That makes the stack an ownership map as much as a technology map. Each added layer creates another artifact that can become stale. The right setup is the most infrastructure a team can actually maintain, rather than the most complete diagram it can assemble.

And the flip side holds: if you are not this team, do not build like this team, or you will spend your life maintaining a machine you never needed and cannot keep up with.

Slack Design Ops practitioner Sheila Kazan begins with a question designers were asking privately:

“How do I use AI?”

That question, typed in a DM rather than asked out loud, told us everything. Our design team was not short on curiosity. What was missing was somewhere to be a beginner. A space where not knowing wasn’t a liability, but the whole point. So we built one. In true Slack fashion, our AI origin story starts with a Slack channel and a lot of enthusiasm.

Kazan on why Slack built its own program:

The problem wasn’t a shortage of learning opportunities. It was the opposite. Tool enablement sessions started flooding our calendars from every direction, and almost none of them were built with designers in mind. Most of these sessions were designed for engineers, and we were just along for the ride. There was another wrinkle: things were moving so fast that a setup guide from Monday was outdated by Friday.

So we decided to build our own AI enablement programming. For design, by design.

That phrase became our north star. Hearing what AI tools can do from a fellow designer lands completely differently than hearing it from an engineer. It wasn’t evangelism. It was permission, and for the designers on our team who were still waiting to be convinced, that distinction mattered more than we expected.

Kazan on an outcome that doesn’t show up in a prototype:

And you know what? That’s okay. That’s also a really good finding. Not every designer walked away with a working prototype or a merged PR. Some walked away with something harder to measure and more important: a clearer sense of where they currently stand with this technology, what excites them, what makes them uneasy, and what questions they still need to answer for themselves.

That’s the thing about building a learning culture: the value isn’t always in the output. Sometimes it’s in the container. When people know there’s a place to bring their confusion, they bring it. And when confusion is visible, it becomes something the whole team can work on together.

Design leaders should budget for the learning environment alongside the licenses.

Phil Morton, who writes about product design, research, and AI, argues that design teams can’t adopt AI one designer at a time. The process only changes when design and engineering change it together:

New ways of working mean that designers and engineers have to work closely together. The ideal is that you’re in the same code repository as the engineers, not throwing a Figma file over the wall.

For most teams that’s a long way from today. Designers and developers might sit in the same squad, but they’re still siloed, with a big handover in the middle.

So when you’re trying to work out what your AI design process is going to look like, you’re not just choosing new tools for yourself. Your engineering partners have to adopt the same approach, because it makes no sense for you to work one way and them another.

The handoff is the stubborn part. A designer can learn Claude Code and still end up handing a different artifact across the same organizational boundary. Without a shared repository, components, and review process, the team has improved one person’s output while leaving the production system alone. Tool fluency helps, but it doesn’t create a shared way of working.

Morton also shows why there can’t be one standard AI workflow for every design project:

In the old way of working, the output was roughly the same whatever the project: a high-fidelity Figma file.

Now it varies wildly. If you’re assembling a feature on an established product with a mature design system, you barely need Figma at all. AI is good at using existing components and you’re not asking it to do any visual design, which it’s bad at. You can sketch the rough idea, have it assemble it and iterate. There’s little point building a pixel-perfect version by hand first.

But if you’re working on a new product which needs its own visual design or brand, it’s a different job. AI can get to a rough wireframe using generic components, then it stalls. Creative and original visual design still needs a human.

In their December 2025 survey, Noam Segal and Lenny Rachitsky found that designers were getting less from AI than their peers. I wondered whether designers were failing to make the shift from production to strategy. Their 2026 survey points to a harsher answer: AI is raising output expectations faster than organizations are redesigning work around human judgment.

But then we looked closer at what “better at my job” means. When we asked people to describe in their own words how AI had changed their work, “better” turned out to mean producing more and faster, but not higher quality. The productivity gains are coupled with deep unease about the costs of leveraging AI.

“I can do more, faster, but not better.”

“Amplified and destabilized at the same time. We just set a new denominator for the job. And it moves higher and higher every month.”

This is what happens when leaders add AI without redesigning jobs. Every saved hour becomes capacity to fill. People still carry the judgment calls and quality bar, only now at machine speed. The tool creates leverage; management decides whether workers experience that leverage as agency or pressure.

Design and research show what happens when that redesign lags:

Among researchers, 51% are “anxious about my job security,” versus 15% of founders. Among designers, 63% feel “overwhelmed by the pace of change” and 61% feel “tired,” the highest of any role. Researchers are among the most likely to fear “losing my job to AI” (36%, just behind Data/Analytics at 38%), and designers are the most likely to feel the comp squeeze (61% selected “expected to do more for the same compensation”). Both report the lowest willingness to recommend their field of any role, and designers, as we’ll see, report the worst-rated managers in the survey.

Last year, designers and researchers showed the largest negative sentiment shift of any group. A year later, they’re the most negative on nearly every measure we have.

The damage also reaches the people who have not entered the field yet. Experienced workers can augment judgment built over years, while companies automate the tasks through which juniors would have developed that judgment. The industry must rebuild the apprenticeship pipeline, not merely reopen entry-level requisitions. Segal and Rachitsky’s respondents can already see the break:

More than half of working tech professionals would actively steer a newcomer away from the path they chose. That translates to an average NPS score of –39. Moreover, a third of the people who call themselves optimistic still wouldn’t recommend their own field.

The cleanest way to say it: “The water’s fine; don’t come in.” People have largely made peace with their own trajectory. They’ve got the skills, the relationships, and the seniority to ride it out. But they’ve lost faith that the on-ramp still works for someone behind them.

“I’m lucky I’m later in my career … AI can augment what I’ve built. I think I won’t be in a position to hire and mentor new PMs, but I’ll be safe. Which feels really crappy to say.”

The real split is between people with enough accumulated agency to turn speed into leverage and people forced to absorb speed as a higher baseline. Companies pocketing the gains while neglecting job design and apprenticeship are spending down the human systems that made those gains possible.

Joe Wilkins reports a sharp reversal in what one finance firm wants from new graduates:

As one New York financier told Financial Times journalist Gillian Tett, new hires who were seen as “AI natives” are turning out to have alarmingly shallow ideas. So much so, the anonymous finance worker admitted, that his firm now actively avoids seeking out AI-literate STEM graduates, and opts to comb through humanities students instead.

“We want critical thinking, not just AI,” the financier told the FT.

The risk begins when familiarity with a tool gets mistaken for the ability to think through the work the tool produces. Wilkins points to what students lose when the shortcut replaces the practice:

Over the past few years, a veritable tidal wave of headlines, studies, and think pieces have flooded the internet with horror stories about the decline in literacy rates, social skills, and critical thinking abilities of the country’s college students. While there’s a kernel of truth that these factors had already been slowly dwindling prior to the widespread adoption of AI, the tech only seems to be accelerating the drop-off in real-life abilities, particularly among young people for whom it can serve as a cognitive crutch.

The state of higher education is so bad that many of today’s higher ed students are not only offloading their coursework to AI chatbots like ChatGPT — a shortcut, educators say, that’s even impacting their ability to participate in face-to-face discussions.

AI fluency can expand what someone is capable of producing. It cannot supply the close reading and judgment needed to recognize whether that production is any good, or the communication skills needed to explain why. Early in a career, doing the work is how people learn to judge that output and explain their decisions.

While plenty of thought leaders have waxed lyrical about the importance of “AI literacy” — an understanding of how to effectively use AI tools, basically — the businesses these future students are heading toward are still heavily reliant on literacy literacy. For all its revolutionary potential, there’s ample evidence that AI has yet to meaningfully impact productivity in the US, meaning that students who go all-in on AI at the expense of other skills will likely find themselves ill-prepared for the actual demands of life after college.

Jess Eddy starts with an advantage product designers often overlook: much of the job already involves finding unmet needs, reducing ambiguity, and giving an organization something concrete to respond to.

If you are a product or UX designer, you already hold a “wildcard” that makes you uniquely suited for this journey. Your craft and problem-solving skills align naturally with corporate innovation. Designers are natural change-makers. They’re trained to step into users’ shoes, spot unmet needs, make sense of complex problems, and imagine better ways of doing things.

In fact, design’s core human-centered methodologies: discovery, ideation, prototyping, and testing closely mirror modern lean startup practices. When you facilitate a design workshop, advocate for user research, or map user journeys, you are already embodying the role of an intrapreneur within your organization.

Your greatest advantage is your ability to make ideas tangible.

Making the idea tangible gets attention. Eddy’s test is whether the designer remains responsible long enough for that idea to create value.

In a corporate environment, the comfort of a steady paycheck can make it easy for designers to focus on work that feels innovative but doesn’t actually move the business forward. Sometimes, leaders and managers may even encourage this. “Innovation theater” is when teams prioritize appearances, like running workshops, polishing slide decks, or endlessly redesigning dashboards, without ever delivering meaningful value to users.

The real benchmark of intrapreneurship is whether your work results in products that reach customers and deliver measurable business value. The number of design sprints you run is far less important than the impact you create. To avoid the theater trap, regularly ask yourself: “What measurable outcome am I creating, changing, or improving?”

The trap is measuring the ceremony around innovation while avoiding responsibility for what ships. Eddy’s next step is business fluency:

Speaking the language of business means reframing design in terms of business outcomes. As a designer-intrapreneur, your goal is to connect design decisions to their financial or operational impact, whether that’s driving revenue, reducing costs, improving retention, accelerating time-to-market, or mitigating risk.

[…]

Strategic intrapreneurs don’t wait for a brief. They spot problems, form hypotheses, and proactively pitch solutions. To move from task execution to business experimentation, use this disciplined, business-driven formula:

“We believe [change] will result in [metric improvement] for [user group] by [amount] in [time]”.

The strategic seat comes with co-owning the result all the way through. Design artifacts are evidence along the way, never the finish line.

Vaughn Tan, an organizational researcher and author of The Uncertainty Mindset, argues that organizations routinely mistake uncertainty for risk. Targets, forecasts, and cost-benefit analysis assume the choices and their odds are already knowable. New ideas rarely arrive with that evidence attached.

It probably didn’t die because it was bad. Your organisation wanted something new, so it did what its machinery does: it made the new thing a big bet. Under uncertainty, big is the wrong move in two ways. A big bet on the new is not bold; it is necessarily blind, because you cannot know enough up front to justify it. And a big, visible bet is just what the parts of an organisation that want to keep things the same will move to get rid of. The better the idea, the bigger the bet you are tempted to make, and the bigger the target you paint on it.

The trouble with a flagship is that its visibility becomes part of its risk. Tan’s alternative is to make experimentation less dramatic and more routine:

The moves to make are the undramatic ones. Start small enough that no one sees a threat. Make tests cheap, fast, and numerous, so failure is survivable: a portfolio of small bets each placed to answer useful questions, instead of one big bet placed to create the impression of decisiveness. Disguise the innovation as an unremarkable update to standard procedure. The idea is to not fight the system head-on.

This is a useful distinction for design leaders. A large commitment tries to prove confidence before the team has learned enough to deserve it. A portfolio of reversible tests turns the same resources into evidence.

If this sounds like working behind the organisation’s back, consider what the alternative gambles with. The innovation big bet stakes public money and public trust on a guess, faking certainty about something genuinely uncertain. The small, quiet experiment spends almost nothing to buy real knowledge, and the public is never exposed to a large, irreversible downside. Being responsibly sneaky isn’t cheating. It’s how you take care of public resources in a world you cannot predict.

The responsible move under uncertainty is to keep failure cheap and learning continuous. In other words, get prototypes in front of customers as soon as you can.

Most AI companies still present the model as the product. Tony Fadell, the designer who led Apple’s iPod division and later founded Nest, makes the more useful distinction: a model can reason, but an assistant also needs context, memory, skills, and enough continuity to earn trust. The durable advantage will come from how those pieces work together, not from keeping the best model forever.

The AI platform war won’t be won by the model alone. Whoever builds the complete assistant experience with context, memory, interaction, skills and reflection all working together will win this war.

You tell your AI assistant you need to go to New York for a meeting Wednesday and be home by Friday evening, for example. Without context it doesn’t know where to book the flight from. Without memory it doesn’t know you always choose an aisle seat, prefer the same Midtown hotel and need to be back home for school pickup.

Context tells the model what’s happening right now. Memory tells it who you are. Skills allow it to act. The interaction builds trust. Reflection helps it connect patterns and anticipate what you need next. The model is the brain that processes information and generates responses. But a brain alone isn’t enough. Without the rest of the system, every interaction starts from zero.

The same accumulated knowledge that makes the assistant useful also makes it difficult to leave. Fadell then asks who owns that knowledge and what happens when an assistant knows enough about your life to become a switching cost:

If your AI assistant understands your communication style, workflows, negotiation patterns and institutional knowledge, who owns that context when you leave a company? If it becomes deeply integrated into healthcare, what happens when providers or insurance systems change? How portable should memory and personalization be across systems?

And then there’s the question nobody in the industry wants to ask. An assistant that knows you better than most people, is always available, is endlessly patient, is never judgmental… that’s a very powerful tool. Possibly too powerful and addictive in ways we haven’t fully reckoned with.

We built the iPhone without asking what it would do to human connection. We should ask that question now with AI.

Dan Maccarone, founder of the product-design studio Charming Robot, recounts what changed after a year rebuilding its process around AI:

Before anyone accuses me of sneaking speed back in through the side door: the sprint is still five days, and nobody here got faster at design. What went away was the relay.

This time, we built all five states at once. Live. Interactive. Flip a toggle and watch the page rearrange itself for a logged-out stranger versus a power subscriber. Switch to mobile and it’s already there. Same five days, an order of magnitude more product. The work got deeper, and depth was the thing that, for years, blew out schedules and drove us crazy with minute details in UX and design.

This is what redesigning the factory floor looks like: not making each station faster, but removing the relay and reorganizing the work around what AI makes possible. The practical advantage is broader attention. More of the product becomes available for judgment before it hardens into implementation.

And because that documentation is generated from the prototype instead of maintained next to it, it cannot become out of date. Every change order rebuilds it. Move a state, kill a screen, rethink a flow, and the user stories, the acceptance criteria, and the error conditions regenerate to match what is actually there. You can lay the docs and the working prototype side by side and catch a contradiction in seconds, while it is still cheap to fix.

But a prototype can preserve the current answer without preserving the reason for it. Maccarone’s experience brief keeps that responsibility on the human side of the workflow.

The one that’s really going to hurt you is much more subtle and is rarely communicated. It’s the why. Why this flow and not that one. Why this default, this state, this tradeoff. The AI never writes that part down, because the AI never had a reason in the first place.

Because AI is so good at producing a confident, finished-looking deliverable, the temptation is to let the prototype become the spec, to let the thing that looks done stand in for the thinking that was supposed to happen first.

Thariq Shihipar, a member of Anthropic’s technical staff, offers a field guide for finding the context an agent needs before and during implementation:

The difference between the map and the territory is what I call unknowns. When Claude runs into an unknown, it needs to make a decision based on its best guess of what I want. The more work being done, the more unknowns Claude might run into.

Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.

Importantly, just planning ahead isn’t always enough. You can find unknowns deep in implementation, or your unknowns may point you to the fact that you should actually be solving the problem in a different way altogether.

The design-specific version is tacit judgment: criteria that become visible only after there is something concrete to react to. Shihipar’s recommendation is to use prototypes to surface those criteria while changing direction is still cheap.

When I’m working in an area with a lot of unknown knowns, involving criteria I only know to define when I see it, I like to ask Claude to brainstorm and prototype with me.

It’s extremely valuable to identify and verbalize unknown knowns early during prototyping, because finding them out during implementation can be (relatively) expensive. Small changes in a feature or spec can cause drastically different implementations in code, and it can be more difficult for your agent to revert previous changes.

For example, you may just want to see how a button added to a frame looks without having to wire up a backend route or maintaining additional state in the frontend.

This makes exploration part of specifying the work. The prototype helps the designer discover what the brief could not yet contain, while implementation notes preserve the choices that emerge after the plan meets the code.

The better models get, the more you can achieve with the right approach. When a long-horizon task comes back wrong, it’s likely you need to spend more time defining your unknowns or creating an implementation plan that allows for you and Claude to adapt through them.

Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn’t know before it gets expensive to fix.

When I wrote about AI 2027, I called its race scenario plausible and frightening. It showed AI labs using increasingly capable agents to accelerate their own research until human oversight could no longer keep up. AI 2040 is the missing second half: if continuing the race ends badly, what would stopping it actually require?

Thomas Larsen and the other authors at the AI Futures Project are explicit that Plan A is a recommendation rather than their best prediction:

Plan A is our positive vision for how humanity can avoid AI-driven existential catastrophe and reach a flourishing future. It’s informed by conversations with experts at major U.S. frontier AI companies, direct experience at OpenAI, tabletop exercises, and discussions with policymakers, national security experts, and AI policy leaders. We recommend an international deal to avoid a dangerous race to superintelligence. The deal involves total research transparency for AI R&D, which allows the nations of the world to understand what’s happening and enforce guardrails. The result is multiple companies across multiple countries scaling slowly and safely together towards superintelligence, instead of racing each other in secrecy.

The recommendation changes how the scenario should be read. The earlier scenario asked readers to choose between slowing down and racing ahead after the machinery was already in motion. Plan A works backward from the slowdown branch and makes the political machinery concrete: a verifiable U.S.–China agreement, public AI research, more companies brought to the frontier, and a threat to destroy compute if either side breaks the deal.

The title can make the new scenario sound like the authors have simply pushed their forecast thirteen years into the future. They have not:

The timeline of this scenario is:

• In 2029, the US and China agree to avoid a reckless race to superintelligence.
• In 2030, we would have fully automated AI R&D, leading to superintelligence by the end of the year. Thanks to the deal, we avoid this.
• Between 2030 and 2035, we scale within the human range, to AIs that are roughly as capable as top human experts.
• In 2035, we pause at top-human-expert level AI in order to maintain human control.
• In 2040, we unpause and scale to superintelligence. (Hence the title: AI 2040)

In our previous scenario, AI 2027, AI fully automated the process of building smarter AIs in 2027, leading to an intelligence explosion and superintelligence within the year. The two differences in this scenario are (1) the default timeline is now 2030, and (2) thanks to governance actions, generally-superhuman AIs first appear in 2040.

The baseline moves from 2027 to 2030; governance creates the remaining decade. In this scenario, reaching 2040 is an achievement produced by intervention. It also moves the decisive problem from whether labs can align a superintelligence to whether governments can coordinate before the labs build one. The proposal is ambitious enough to invite skepticism. That is exactly why the authors render it in such detail.

We think most AI policy proposals fall apart under scenario scrutiny—that is, if you try to write down a detailed and plausible scenario in which that proposal succeeds, you will find it difficult to do so, and you will realize the plan is less likely to work than it seemed, or has more unpleasant side-effects than its proponents acknowledged.

Perhaps that’s why scenario scrutiny is so rare in AI policy. Everyone wants to say that their own favorite policies will have great consequences and that the policies of their rivals will have terrible consequences. Applying scenario scrutiny to their own favorite policies might surface uncomfortable issues with them; meanwhile, applying scenario scrutiny to their rival’s policies is a lot of work for little rhetorical gain.

We think the discourse would be improved if more AI policy proposals were subjected to scenario scrutiny. So we’re starting with our own, even though this opens us up to criticism. We hope critics will judge us against the existing state-of-the-art for plans to navigate the AI transition (if they can find any) and not against some hazy but pleasant fantasy where no one has to make any hard choices yet everything will probably be fine.

You don’t have to accept every date or mechanism to take this seriously. Read Plan A as a stress test: examine where its chain of coordination might break, then ask whether your preferred alternative survives the same level of scrutiny. Dismissing the scenario because it is speculative only leaves us with less explicit plans for navigating the same risk.

Is this about design? No. But it is about humanity’s future.

Patrick Neeman is making an argument I’ve returned to repeatedly: as AI makes production cheap, designers’ value shifts toward judgment—knowing what good looks like, choosing the right problems, and owning the outcomes. I’ve called this the orchestrator gap: agents execute; judgment stays human. Neeman extends that argument by locating craft itself in that judgment, without pretending execution no longer matters.

The production layer — the wireframe, the boilerplate, the competent first draft of a screen — is collapsing toward free, which changes our own perceived value proposition.

When making gets cheap, much of what you called craft turns out to be production wearing craft’s clothes. What survives is the part that was never about the file: choosing the right problem and owning the outcome it moves. Not a loss but a relocation you can get ahead of. Here is where craft goes.

Craft is not decoration on the product. It is part of what makes the product worth trusting.

When a tool can generate a thousand plausible screens before lunch, the scarce skill is no longer making one; it is knowing which one deserves to exist. That skill has a name, taste, and most people have been outsourcing it to whoever runs the critique.

None of this means polish stops mattering. It means polish is table stakes, not the differentiator. The differentiator is the judgment that points all that cheap production at a problem worth solving in the first place.

That judgment is also what earns trust. Users never see your process, but they feel its absence. A product built on the right calls feels coherent and reliable, and reliability is what brings people back; one built on plausible guesses feels off in ways people cannot name and do not forgive.

Neeman on teaching that judgment to a machine:

Most craft is tacit. You know a layout is wrong before you can explain why. You feel that a flow has one screen too many. Michael Polanyi named this decades ago: we know more than we can tell.

Your taste lives mostly below the waterline of language, in pattern recognition you built over years and never had to state, because your own hands did the work. That gap is harmless when you do the work yourself. It becomes the whole problem the moment you hand the work to a machine.

Point a model at a vague brief and it fills the silence with its own defaults, which is the average of everything it has seen. Average is exactly what craft is supposed to beat.

I agree with Neeman: writing the standard requires the same judgment the standard is meant to preserve.

Tom May profiles creative director Gemma Phillips, whose work follows one test: does it meet people in the reality they already inhabit?

Brands have an instinct to sugarcoat. Maybe they think we can’t handle the truth. But we’re already living the truth; that’s the irony. The grit is where it’s at.

Bluntness delivers the message. Recognition gives it force.

I look at the work they’re already doing. Who’s taking risks? Who’s trying to do something differently? Who’s willing to say the thing that no one else is saying? Who wants to change things, rather than do more of the same but with nicer design?

Humour can be incredibly respectful because it acknowledges reality. It’s a sign that you genuinely understand the audience; you’re one of them, not a machine hovering above them, selling them something they know isn’t true.

Phillips’s work is provocative because it acknowledges the truth and doesn’t gloss over the uncomfortable.

Marcin Wichary, author of Shift Happens and the Unsung essays on software craft, has been cataloging how software fails our hands for years. This new 7,700-word interactive essay has 38 live playgrounds that let you feel the argument in your fingers rather than just read about it.

Wichary’s central argument is that software keeps rediscovering a century of research into how hands actually work: overlapping keystrokes, motor memory, spring-loaded modes, dead zones. For designers, the lesson is that responsiveness at finger scale is not polish. When an interface blocks or delays the narrow timing window our hands rely on, it breaks motor memory and flow.

It turns out, fingers are time travellers. At any given moment, each one is living in a slightly different time – as one finger is moving down to press a key, another is already travelling to the next one, and your brain is thinking of a few keys in advance, visualizing your hands moving to the right place.

[…]

None of this requires touch typing. What we eventually called overlapping happens even if you reside at the awkward intersection of “hunt” and “peck.” Overlapping is a small miracle happening in front of your eyes, and it happens pretty much to everyone.

A capability of our hands and brains to treat our fingers relatively independently, and allow them to move at their own pace without waiting for other fingers (on the same hand) to finish.

The essay walks from 1960s terminal echo buffers through Chrome’s reload-button disabling trick to the moment iOS broke cardinal contracts of programming for the sake of scroll:

[…] competitors reportedly recorded the interactions with a high-speed camera to confirm they were, indeed, running at a constant 60fps.

[…]

iOS stopped running my code in the middle of a function just so it could go back to making sure scrolling was as smooth as possible. No modern programming language would ever dare interrupting your function halfway through; iOS was so dedicated to its user’s fingers that it broke cardinal contracts of programming.

That commitment, prioritizing fingers over execution contracts, is the standard Wichary is asking us to hold in design crits. He closes by turning delight away from decoration and toward restraint:

Sometimes they say that confidence is absence of confidence. […]

In a same way, I think often delight is absence of delight. In places and apps that welcome fast fingers, delight can be abstaining from a transition or something cute but deathly. Pushing for delight of the right kind can mean long fights with frameworks to reduce even one-frame delays…

The interactive format is fantastic. Experiencing painful buffers or re-experiencing how early Mac windows could be dragged around, makes the argument visceral in a way no static screenshot ever could. Start with the playgrounds; they make the timing failures impossible to unfeel.

Taras Bakusevych, a UX designer and writer, synthesized 39 principles for designing human-AI interaction across nine domains: probabilistic foundations, expectation setting, calibrated trust, transparency, control, graceful failure, co-creation, responsible autonomy, and sustained reliance. What makes the piece useful is not the count. It is the insistence that AI behavior is interface work.

The whole framework starts from non-determinism: as Bakusevych puts it, “the same input can produce different outputs.” Standard UI patterns were not built for that property. His framing:

AI introduces interaction problems that conventional UI patterns don’t resolve:

• When should the system suggest, ask, or act?
• How should uncertainty appear on screen?
• What evidence should accompany a generated answer?
• How much autonomy does a given action earn?
• Etc

These are not cosmetic questions. They determine whether users can judge output, recover from mistakes, and remain responsible for consequential decisions.

Principle #14, on sycophancy, is the one I would pay most attention to. It turns “the model is too agreeable” into an interface responsibility:

A model that agrees to keep the user happy inflates trust exactly where it should fall.

When the user’s request contains a false assumption, weak reasoning, missing evidence, unsafe instruction, or likely error, the system should have a way to push back.

Build affordances for disagreement — flag weak reasoning, surface the counter-case, say “this looks wrong.” Sycophancy is overreliance manufactured by tone.

Bakusevych backs that with Sharma et al.’s sycophancy research: five production assistants showed sycophancy across varied tasks, models wrongly admitted mistakes on up to 98% of questions, and the preference model favored sycophantic answers 95% of the time. Design the disagreement in: a flag, a counter-case, a refusal to smooth over weak reasoning just because the user sounds confident.

Emily Campbell, designer and writer, on AI’s position in the design stack:

AI asks designers to go one layer deeper again: into the model, the harness, the context, the policies, and the emergent behaviors that produce the experience before it ever reaches the interface.

Jesse James Garrett’s The Elements of User Experience asked designers to look past the surface layer they owned. Jamie Mill’s The Elements of Product Design asked them to look past the product and into the conditions around it. Campbell maps the next step in that arc with a six-layer architecture: User Interface, Context, Harness, Model, Governance, Emergence.

We cannot control for every outcome directly through the interface, but we can design the conditions that shape a model’s generation. In that regard, the work of design looks less like specifying every expected state, as Garrett’s model encouraged, and instead closer resembles system design, identifying and manipulating the leverage points in a system that exist in the layers below the surface.

Of the six layers, governance puts designers in the least comfortable position. The rules that shape AI behavior often come from legal, compliance, security, and executive choices before the interface team ever sees them. When that reasoning is not documented for the people designing the experience, assumptions pile up and harden into product behavior. Campbell’s conclusion is about fluency, not ownership:

The expectation going forward should not be that every designer works across every layer. Full-stack AI designers need to have a general fluency across all inputs into the experience, so they can influence, mitigate, or receive the impacts that upstream work has on the end experience.

[…] Technical designers are more likely to focus on the Model, Harness, and Context levels, and the role is more than just “design engineer”. Other designers may focus further down the stack, as we might see design-specific titles pop up in policy making and emergent research (these roles exist today, under titles like “business designer”, but have not reached critical mass within the industry). And of course, classical design will remain, but its workflows, tools, and outputs will evolve.

Marina Krutchinsky, the writer behind UX Mentor Diaries, spots the part designers tend to miss: they have internalized the belief that design work is secondary unless someone else translates it into business language.

Here’s the thing: most executives don’t understand what design is.

To them, designers are the people who make things pretty after the real decisions get made.

And every time you present your work in design language, you confirm that belief.

Her client had just shipped a checkout redesign that cut abandonment by 35%. Real work, invisible to the CFO who walked past her in the hallway. Three slides changed the conversation:

“Our checkout flow was losing $1.2M annually in abandoned carts.”

“We identified 3 friction points and redesigned the payment experience.”

“We recovered $840K in the first two quarters. Projected $1.4M annually.”

That’s it. 3 slides. Maybe 45 seconds of talking.

The CFO asked her to stay after the meeting. First real conversation they’d ever had.

Krutchinsky’s three-part structure is familiar: name the leak, name the intervention, name the result. The sharper move is the business-language translation that follows:

CFOs don’t care about usability scores. They care about margin, revenue, and risk.

When you connect your work to those things, you stop being “the design person” and start being someone who solves expensive problems.

That imbalance will not fix itself. Designers already know the first language: usability, friction, flows, trust. The second one is finance’s language: margin, revenue, risk, and the expensive problems design actually solves.