428 posts tagged with “ai”

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.

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.

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.

Ethan Mollick, Wharton professor and author of Co-Intelligence, has been running careful benchmarks across models and workflows. His main finding for designers: the shift from chatbots to agents rewards domain expertise, not job title.

What actually mattered was not the profession of the user, but their expertise. The more domain experience someone had, the more successful they were in using Claude Code in that domain. And, even more interestingly, the more useful output they got from Claude from each prompt.

That framing reorients the usual anxiety (“will AI replace designers?”) into a different question: how deep is your domain knowledge, and are you using agents to extend it or to paper over gaps? The underlying shift Mollick is describing:

We are moving from a world where non-experts use chatbots to fill in gaps to one in which experts use agents to get work done. And the best way to use agents is to think of yourself as a manager.

[…]

Being on an exponential means each change over a fixed window is larger than the one before it. If your organization wrote an AI plan any time before the winter of 2025, it described a system that could do a couple of hours of work with a fairly high error rate. A few months later, you can get sixteen hours or more of work from a single prompt. This is why AI keeps feeling like it is making leaps, even though it is a curve on a graph, we keep experiencing a steady doubling of capability as a series of shocks. We are very bad at feeling exponentials from the inside, and we are currently inside one.

The management framing also carries a real cognitive cost. Running multiple agent streams and deciding what to keep draw from the same finite attention budget as the design work itself. Orchestration is its own job.

Drew Breunig, an analyst and developer who writes about AI infrastructure, has a name for the slow accumulation of fixes, workarounds, and escalating all-caps instructions that eventually choke an AI application: prompt debt.

The plain-English prompt that makes prototypes effortless turns out to be a poor way to specify how a system should behave, and the bill arrives slowly, disguised as ordinary progress, until the application can barely move. The problem is not any single prompt. It is that natural language was never meant to be a specification language for engineering, and treating it as one quietly caps what you can build.

Breunig’s model-lock-in evidence is the warning sign. A recent Datadog report shows GPT-4o is still the most-used model in observed traffic; Breunig also says multiple large inference providers put GPT-4o and similar-vintage models above 50% of all calls. His proposed escape hatch is to stop treating hand-written prompts as the durable layer:

Every mature engineering discipline eventually stops doing by hand the very thing it once prided itself on doing by hand. Assembly gave way to compilers, hand-tuned queries gave way to planners, and manual memory management gave way (mostly) to machines that do it better. Prompt-writing is no different.

Coaxing the model with exactly the right words is a real skill, and for one-off tasks it’s often optimal. But to build reliable, improvable, and portable systems we should not be hand-tuning prompts.

For designers, the useful warning is not that prompt craft goes away. It is that fragile prompt craft stops scaling once the AI behavior becomes part of the product. If the system has to survive a model upgrade, the design work has to move into measurements and typed specifications: schemas or contracts that constrain what the model can produce and give the next model something stable to inherit.

In June 2026, Stack Overflow unveiled a full rebrand by studio Koto, repositioning from Q&A platform to “the world’s most vital source for technologists” right as monthly new questions on the site are down roughly 77% since ChatGPT launched. The brand investment and the traffic freefall are happening simultaneously. That is the context for Ishan Gupta, a software engineer at Amazon, and his five-phase history of how the old engineering workflow collapsed.

Software engineering was a craft you absorbed slowly, then practiced in a long, predictable sequence: Dive deep on the technology, write the code, ask Stack Overflow when stuck, escalate to a senior engineer when Stack Overflow failed, ship the ticket. The product manager owned the funnel. The engineer owned the build. Both sides treated this division as physics.

That division is dissolving. Gupta traces it through the IDE-native era (e.g., GitHub Copilot and Cursor), the spec-driven era, and the Claude Code Routines era (Anthropic’s scheduled, persistent agents). At each step, another piece of work that used to require a human gets handed off. Gupta’s diagnosis:

Anthropic recently told its growth team to hire more product managers, not fewer. The reason, as reported in industry coverage, was that Claude Code had quietly turned its engineering org into a team that ships at roughly three times its actual headcount, and the bottleneck moved from the integrated development environment (IDE) to the people deciding what to build.

That detail is easy to miss in the noise of every AI productivity claim. It is also the structural shift the rest of the industry is now living through. The bottleneck in software is no longer typing. It is deciding what to type. And the engineers who treat that as someone else’s problem are about to plateau.

That same shift is what Koto’s rebrand is responding to. Cat Hill, senior strategist at Koto, put the rebrand angle plainly: “In the AI era, everyone wants faster answers. But speed is useful only if the knowledge underneath is trusted.” For designers, that is the opening: the product-thinking gap is no longer a soft skill around the edge of engineering work. It is where the work is moving.

Gupta’s clearest description of the new engineering identity is also the case for why product judgment matters more:

The 2026 version of a great engineer is not the one who writes the most code. It is the one who knows what to build, can prove it is worth building, and has the agent fleet plus the review discipline to ship it without the system collapsing under its own velocity.

Heenesh Patel links Apple’s WWDC 2026 moves (Siri now able to invoke app functions without the user ever opening an app) to a larger skill shift for designers. The polished-UI moment isn’t ending, he argues; its shelf life is just shorter than we think.

This moment might be shorter lived than expected, as we enable agents to execute more tasks on our behalf, screen-based flows fold in on themselves to intents, replaced by API calls and lightweight confirmations. Here the beautifully crafted experience still matters, but it’s not where the experience lives.

As designers continue to rapidly evolve their skills in an AI first world, taste judgement can elevate the experience but only so far and the real differentiator in app design becomes the overall experience architecture, and how flexible and robust apps are in embedding into the platform.

Patel locates the new value in how flexibly and robustly an app’s functions embed into the platform. That is a systems problem before it is a screen-design problem.

Taste is the skill of this moment. Systems thinking is the skill that will become indispensable in the next chapter of design. Designers who start building that capability now will be the ones setting the standard when the shift arrives in full.

The uncomfortable implication in Patel’s urgency: Job Stories (a way to frame user intent in context) and state charts (maps of the states an experience can reach) have been in the UX toolkit for years. What changes is the operating system. If Siri can trigger app functions directly, and if users can move through an experience by intent instead of by screen, designers need to understand the states, permissions, handoffs, and failure paths that sit behind the interface.

The web is forking. Sara Guaglione reports that publishers are starting to build one version of their sites for humans and another for agents. The phrase that matters is Time chief operating officer Mark Howard’s “separating out that traffic.”

“[The bots are] just getting the content itself and the metadata, but they’re not getting the full page experience, and we’re routing all the humans to the full page experience. So we’re separating out that traffic,” Howard said.

“Now we’re starting to think about, as the volume of bot traffic continues to increase significantly – and we see through a number of our vendor partners that we have very high domain authority with AI bot traffic – there’s value in that,” he added.

Howard is making the operational case. Toshit Panigrahi, co-founder and CEO of TollBit, makes the economics explicit:

“Part of onboarding to TollBit is we create your agent site for you,” said Toshit Panigrahi, co-founder and CEO of TollBit. “It really comes down to the token economy. Websites have a lot of HTML tags and JavaScript and CSS and things that don’t have to do with the content. That creates a big bloat in the actual size of the page.”

Markdown can make websites “friendlier” to agents, he added. “AI can comprehend more of your article because they’re not spending money parsing out other HTML that’s on the page. We see, on average, a 90% reduction in tokens, because we have converted the content to markdown.”

That efficiency argument is real. But independent publisher consultant Scott Messer, principal of Messer Media, pushes back:

Yet, even as more publishers quietly spin up agent-friendly feeds, stripped down pages and custom schemes, not everyone is convinced they should be racing to re-architect the web for bots. Independent publisher consultant Scott Messer, principal of Messer Media, argues that building for agents should be a highly qualified decision, not the default. His reasoning: traffic isn’t the reward in an agentic environment – if there is no click, no ad impression and no check, the build is pure cost.

“If you believe there’s a value to being discovered by these bots and agents, then you should build them. If you don’t believe [that], I would ask, why would you build them?,” he said.

That is the question under all of this. The rendering layer—the HTML, CSS, and JavaScript that turn server content into pages—is exactly the surface designers build, and publishers and content creators are now deciding which parts of that surface matter when the visitor is no longer a person.

I’d argue that RSS can be easily consumed by agents too.

We haven’t talked too much about AI and e-commerce here on this blog, but as much as any other area in our digital life, AI agents will change how we shop online.

Elizabeth Pizzuti, writing on the Automattic Design blog, explains the two definitions for how “agent” can be used in the e-commerce context.

The word “agent” is overloaded in 2026 commerce.

Two unrelated things share it:

1. Agentic commerce: AI shoppers buying from stores.
2. Agentic merchant operations: AI workers operating for the merchant.

The distinction matters because the two sides ask designers to make different things legible. On the machine-buyer side, Pizzuti’s first principle is basically agent readiness applied to commerce:

AI agents don’t browse websites like humans, they read structured data from the backend. Considerations here include providing an “AI readiness” score or dashboard for a clear, visual indicator of product catalog health, and a preview of how the AI agent sees that data. This demystifies the structure and allows the merchant to see exactly what an algorithm is evaluating. Additionally, make sure that context is part of the catalog—blog posts, buying guides, FAQs, and reviews all determine sentiment and trust and should be linked to the product schema.

For merchant-side coworkers, the problem flips. The interface is there to help a human judge whether the system did the right work. Pizzuti on the interface merchants use to judge and approve the agent’s work:

Designing for trust means exposing the agent’s backend homework. A merchant will never click “Approve” out of blind faith, especially in high-risk areas like pricing or inventory replenishment. Every automated recommendation must include the underlying context and trigger. Instead of “Drop price of item X by 10%”, the UI should show the reasoning chain:

• Observation: Competitor price drop detected.
  • Impact: Your listing’s conversion rate fell by 14% over the last 48 hours.
  • Reasoning: Lowering the price by 10% restores your competitiveness while preserving an 18% net margin.

That’s the right design shape for AI coworkers: controllable over perfect, with proof of work, a visible undo path, and enough context for the merchant to approve the change without pretending the system is magic.

Nolen Royalty, a software maker who writes at eieio.games, gets at a problem with AI-generated work that shows up before judgment: the effort signal. His examples include tldraw, the collaborative drawing tool, closing AI-generated pull requests, warm-cream Claude websites, and record collecting, but the point is simple. Polish used to be a proxy for care. Now it isn’t.

What software (and writing, to an extent) is missing now is legibility of effort - the ability to tell at a glance whether something took a human meaningful work.

Until recently, “someone cared enough to write this” was an ok heuristic. Plenty of writing on the internet was bad, but you could convince me that you cared about something just by writing it down.

Of course, generating plausible-looking text - or a plausible-looking website - is trivial now.

For designers, that broken proxy is already visible on the surface. We can all spot the default Claude style now, which is funny until you realize that a visual pattern has become an accusation about how much thought went into the site.

There’s nothing objectively wrong with making a website with a warm-cream background and hero text in a sans-serif font with a single accent word that uses an eye-catching color and a different font.

But when I see a website that has the default Claude style I assume that the author put ~no thought into how the site should look. And I often assume that the author didn’t put too much thought into the rest of the site either.

That’s not fair of me! But “someone made this website” is no longer enough to tell me that the website was important to them. So “default Claude style” is one of my new heuristics.

Taste sounds less mystical when you put it this way. A designer doesn’t make a screen human by avoiding beige or picking a stranger typeface. The work is in the decisions: why this hierarchy, why this contrast, why this interaction, why this amount of friction.

The proliferation of digital music and streaming made having a music collection easy and frictionless. And so a subculture evolved to re-add that friction.

And in small ways I think you see the same things happening now.

I’ve seen people joke about adding typos to emails to prove that they wrote them. MS Paint-style image macros read as more human than detailed, funny images (the image could be AI slop). Websites that look intentionally bad are more interesting than websites that look beautifully bland.

The easy story about AI in creative work is that it closes distance: idea, prompt, output, iteration, all compressed. It’s Nice That gets at the more designerly version of that question by putting creative technology’s appetite for “happy accidents” next to design’s need for control:

“From the technology approach, the metaphor I equate it to is the classic ‘happy accidents’ you have when you are in a design tool,” Seth says, finding expected moments of creativity. “The best happy accidents aren’t just between a person and a tool; they happen between people.” It’s perhaps in this notion that co-creation is at its most visible, not in the technology itself, but rather in the conversations and unexpected developments that occur when people with different perspectives work closely together. For Talia, however, this isn’t the case. “Nothing we do is experimental by nature,” Talia says, “everything is incredibly controlled – or, better yet, ‘designed’,” stressing the importance of the role of the designer and the meaning behind design itself. “Design is about creating solutions; there is a sense of control, there is a purpose, there is a function,” she continues, “even the beauty is controlled to a degree.” An example is the generative motion graphics system that Talia created, in collaboration with Mother, for the Crypto coin USDC.

Designer and coder Talia Cotton’s line clarifies the whole piece: “controlled – or, better yet, ‘designed’.” Cotton’s point is that the speed of generation only makes the designer’s eye more important, because someone still has to decide the boundaries before the machine starts producing variations.

Cotton’s USDC system makes that concrete:

Within the visual identity, Talia developed a custom tool that generated guilloché patterns, in reference to the historical patterns used in traditional finance. Alongside set, systematic parameters – including height, width, density, and speed – Talia had to create algorithmically constrained rules within those limitations. “As you adjusted one parameter, another parameter would automatically change its available range,” Talia says, “that ensured every possible output looked good.” As Talia suggests, especially considering the ease with which people can generate things, the “designer’s eye” is now more important than ever. “The designer’s job is to create an airtight generative system that considers every possible case and every possible output,” she says, “so that every single output always looks great, no matter how different it is.”

Karo Zieminski, in her newsletter Product with Attitude, is writing for builders, founders, and PMs, but the design translation is straightforward: AI fluency without critique is just a faster way to lose your ability to evaluate the output for yourself.

She draws the distinction:

Plain AI literacy means knowing how to use AI tools. It means learning to prompt, create automations, and bring AI into your workflows.

Critical AI literacy goes further. It adds systems awareness: understanding that AI is not just a tool on your screen, but part of a larger system of model choices, product decisions, business incentives, policy constraints, ethical tradeoffs, and human consequences.

Attitude is the posture that turns AI literacy into critical AI literacy.

That word, posture, matters. It is the same split in not outsourcing the learning: the tool doesn’t determine whether you get sharper or softer; the way you use it does.

Zieminski puts research behind that concern:

The data is on the table now. Microsoft Research surveyed 319 knowledge workers in 2025 and found that higher confidence in the AI is associated with less critical thinking, while higher confidence in yourself is associated with more. MIT Media Lab’s “Your Brain on ChatGPT” study measured the same erosion at the level of brain activity. The muscle is real, and it atrophies on schedule.

For designers, the warning is: don’t let the tool do so much of the looking, choosing, and checking that you stop building those muscles yourself.

Zieminski defines the working posture plainly:

AI with attitude means using AI with judgment, boundaries, curiosity, and scrutiny. You enjoy powerful tools without worshipping them, panicking about them, or letting them decide how you think, work, create, and learn.

Tiina Golub, writing in UX Collective, points at the right version of “personalization” for enterprise software:

I have spent most of my career working on the large-scale computer programs designed to operate and automate complex business processes for big organisations, known as enterprise software. Due to their size and complexity, these products are often slow to innovate, relying on outdated usability principles and legacy systems long after the rest of the industry has moved on. However, recent technological advances (yes, I’m mostly talking about AI) have both enabled and compelled them to evolve at an unprecedented pace. No one can tell for sure what the future will look like, but there are some clear trends reshaping the user experience of enterprise software right now.

The interesting part is not that enterprise tools should start feeling like consumer apps. That usually leads to dashboards with the user’s name on them and a recommendation panel nobody asked for. The better version is software that understands the work well enough to reduce how much process the user has to remember.

That makes AI less useful as a standalone feature and more useful as embedded guidance:

No longer a stand-alone feature, AI is increasingly woven into the fabric of the interface, deeply embedded into every workflow, and offering contextual guidance right when the user needs it.

That is the useful frame: enterprise personalization is not taste. It is role, permission, workflow state, and organizational context. The product gets “personal” when it knows what kind of decision the user is trying to make, what constraints surround that decision, and what help belongs at that exact moment.

Jenny Xie, writing for Figma, collects a set of community sketches about what AI-native software might feel like. The useful part is how concrete the sketches get: controls that appear only when they’re needed, systems that change pace when the user is overwhelmed, and interfaces that treat intent as the starting point instead of the final prompt.

Figma Weave marketing director Itay Schiff starts with creative tools:

When you’re working with a creative tool, select an element—a frame, a sentence, a scene—and state what you need to do. The right controls appear around it, surfacing only what’s relevant to that moment. No hunting through menus, no memorizing where things live. When you’re done, they disappear. Someone editing a video that feels too slow selects a clip and sees options for timing, pacing, alternate cuts, and sound bridges. You’re not losing touch with your craft, but accessing the right controls more directly, through context. This bridges the gap between how people think and how tools are structured. Creative work starts with intent—make this clearer, more nuanced, more intense—but traditional software is organized around persistent menus, panels, and modes. When users can focus on decisions rather than mechanics, the conversation shifts from what buttons we pressed to what we changed, and why.

This extends the generative UI debate from generated content into the surrounding interface: what controls appear, when they appear, and when they disappear.

Anna Oh, Head of Product and Design at Norbert Health, pushes the same idea into domains where software has to adapt to the person using it:

An intelligent system continuously adjusts how it communicates and acts based on how you respond. It offers structured guidance when you seem lost, steps back when you don’t need it, and shifts between voice, text, and visuals based on the context. It controls pacing, simplifies language, or breaks down information into smaller steps to reduce overwhelm. For decades, humans have had to adapt to machines. The mismatch between system capability and human readiness has only grown more visible as software becomes more powerful, and in domains like healthcare and education, especially with an aging global population, that gap has real consequences. As AI becomes the intelligence layer, this reverses: Systems meet people where they are, instead of the other way around.

For design teams, that means pacing, language, modality, and restraint become interface decisions, not polish applied after the workflow is done.

Tech anthropologist Jésabel DC shifts from adaptive behavior to the sensory cues that help people understand where they are in a product:

Sound, motion, and pacing are reintroduced as signals that orient you inside an experience. In the early 2000s, digital interfaces were full of these situational cues: the dial-up sound as you went online, the progress bar acting as a passage to the world you were entering, the voice announcing “You’ve got mail.” As technology became faster and more seamless, these cues disappeared, replaced by notifications engineered to grab attention rather than provide orientation. Because our users’ overall tech experience is already so dysregulating, it’s not enough to design something that isn’t overwhelming. We have to actively design experiences that counterbalance the rest of our users’ tech stack—otherwise, we risk losing users not because our product is bad, but because their nervous systems are already maxed out before they arrive. Think: always visible progress bars, sounds that mark transitions, and consistent visual language.