451 posts tagged with “ai”

In Jason Lemkin’s account of SaaStr’s break with Adobe Marketo, the formal cancellation is almost beside the point. SaaStr had already moved most of Marketo’s work elsewhere:

And once you do that once, you start asking the obvious question. We’ve now migrated almost all of Marketo’s functionality onto Salesforce. Not because Salesforce has better features. Because Salesforce has an API our agents can actually use. One day you look up and realize you’re paying $60K a year for a product you’ve already routed around.

That is the new B2B churn motion. It isn’t a feature bake-off. It’s an agent-operability test, and legacy vendors are failing it quietly, one migrated workflow at a time, before they ever show up on the churn report.

I do think this is where a lot of software, especially B2B software is headed. Even in my own day-to-day, I’m loathe to use tools that don’t allow me to connect to one of my AI agents. Zoom out to an enterprise context and now agent operability becomes a product-quality problem that can eventually lead to churn.

Lemkin’s advice:

If you build or run a B2B company, the Marketo story is a checklist of what not to become.

Make your product operable by an agent, now. Not next year. The question is no longer “is our UI good.” It’s “can a customer’s agent do real work against our API without a human babysitting it.” If the answer is no, you are already on a churn clock you can’t see. Webhooks, an SDK, an MCP server, clean auth, real history. This is table stakes in 2026.

Judgment and craft may help a designer survive today’s freelance market. But Madeleine Morley, writing for Fast Company, gives us little reason to believe that either would guarantee economic security.

She interviewed Cari Sekendur, founder of the independent branding and web-design studio Butter.

In Fast Company ’s report, more than half of designers surveyed believe AI is undercutting their rates, and 68% believe it is eroding the value of human creativity.

“Clients now expect more while paying less,” wrote one survey respondent on AI’s effect on the industry. “Many clients are taking advantage of AI to underestimate our professionalism and pricing,” said another.

Morley writes that only 22% of survey respondents reported losing work because of AI. But the lowish number hides a sense that “AI isn’t replacing design, but it is changing how clients perceive it.” A designer can keep getting hired and still lose leverage over what the work pays and demands.

That pressure isn’t distributed evenly. She describes what has happened among illustrators doing smaller jobs:

Eric Carter, an illustrator whose clients include The New York Times, believes the disruption has been most acute at the lower end of the market. “There is this whole gig economy of illustrators doing smaller jobs,” he says from his studio in Los Angeles. “Fiverr was already cheapening everything… the bottom was already pretty low. And then having AI replace that, it just cut it out.”

Carter has been insulated from that shift because, as he puts it, “I get paid to think.” This idea—that a designer’s value is increasingly about their taste and approach as opposed to pure craft or technical ability—reverberates throughout the freelance industry. “You can’t automate taste and creativity,” one survey respondent wrote. Another: “Ideas and taste is what is needed to succeed.” And another: “AI is only as good as the strategy and input.”

Carter’s “I get paid to think” is encouraging, but it comes with a nasty condition. Judgment and recognizable craft offer more protection when clients already know whose judgment they’re buying. I wrote about the same trap in my series on the design talent crisis: entry-level work is how designers develop and prove their judgment, yet it’s the first work the market is stripping away.

Morley concludes:

What is evident across the survey data and multiple interviewers is that the labor of design is increasingly fragmented in today’s creative industry. Designers are forced to sell their labor in multiple markets simply to maintain the same standard of living that they used to and the market is not compensating highly skilled creative work in the way it did even a few years ago.

All of this raises bigger questions. For many years now, the freelance creative has been not only someone who simply sells their craft, but an entrepreneur expected to market themselves and build a personal brand. Diversification and resilience are emerging as absolutely vital and central capacities for freelancers navigating the age of AI. What gets lost in the urgent need to find sources of income and to adapt are questions like: Shouldn’t clients pay more? Why are corporations cutting budgets? The burden, as always, shifts to the individual.

Intent is one of my go-to coding workspaces. By default, it’s spec-driven and uses swarms of agents to execute the work, with a brainy orchestrator agent coordinating it all.

Ryan Mather, interviewing the product lead for Intent, designer-developer Amelia Wattenberger for AI Design Field Guide, asks how she designs when software behavior itself can change:

It’s a new dimension in which apps can be dynamic. We had image maps exported from Photoshop with a certain resolution, and then we were like, “wait, screens are going to be different sizes — this isn’t going to work anymore.” So we needed layout algorithms. Then users could interact and change what’s on the page — so we made them dynamic through time. Users had preferences — so we made them dynamic based on the user. And now there’s an additional dimension where even the app behavior itself can be completely changed - custom to you.

So designing now is a dance of, what are the primitives to add to the structure? Are we using bricks or another building block? And then the user can fully configure the app’s behavior, which I think is the only way to build a product now. Otherwise it’ll be stale in five months. Someone else will build a new app that does something around the workflows that people want.

Stable application chrome can provide continuity. In configurable software, Wattenberger locates that continuity in the objects people use to compose a workflow: the workspace that contains a task, the spec that humans and agents edit, and the subtasks that make delegation visible.

She describes what happens when those objects disappear:

I think about a straw that’s really bendy, and someone trying to do a thing with it — it’s just not a very powerful thing. Or clay — you can’t build super big things with clay, and you can’t go really quickly, because it’s infinitely moldable. Anything that’s generic is the jack of all trades, master of none. If you want something really powerful, you need some structure there. You need bones, you need muscles, some affordances. You can’t just be like, “oh, it’s a pile of goop, and stuff arises from the goop, that’s not what we all want.”

Mather then asks how far configurability can go. Wattenberger:

I have a feeling that applications as a paradigm will not last much longer, at least as the main way we interact with computers. Things will be way more modular and definitely decoupled from the data. There will also be a strong remix culture, because people don’t want to create everything they want from scratch, but they also want the ability to customize the things they use. So things are going to get super wacky.

OpenDoc, for example, imagined documents as containers for live, editable components supplied by different tools, rather than files owned by a single monolithic application. Computer scientists have been chasing variations of this modular model for years. AI, and the capabilities it gives users, adds a new dimension: the behavior of the application itself can now be remixed.

Paul Bakaus says he helped turn Impeccable from what he calls a “vibed personal skill” into a design toolkit. He says hundreds of thousands of designers and developers now use it. Three of his techniques show how much of that improvement came from engineering around model behavior instead of polishing a prompt.

The first is “Make them argue · two blind reviewers beat one confident guess”:

For a concrete example, /impeccable critique, Impeccable’s design review command, runs both deterministic checks against your code (to detect stuff like low contrast quickly and decisively) and reviews the design like a human would. But early versions had a major flaw that produced bad critiques: hand the LLM the detector output up front and it skews BOTH ways:

1. detector noisy → condemns a strong page over fixable nits (false alarm)
2. detector silent → rubber-stamps a generic page (meaningless clean bill)

To debias, critique now spawns two sub-agents that never see each other’s work: A = an LLM design director (hierarchy, slop, heuristics), B = the deterministic detector + browser evidence. When the sub-agents finish, the main agent synthesizes (weave, never concatenate) the results from both for a balanced critique. Two blind opinions beat one confident guess.

I agree with the architecture. Review independence matters as much for agents as it does for human teams; the reviewer needs a perspective the maker didn’t already shape.

Bakaus’s second technique is “Force divergence · escape the cluster, don’t chase it with bans”:

Bans just move the model from one region of latent space into another. The escape is sideways, not a longer denylist.

Here are three techniques that produce higher divergence (cheapest but weakest first):

1. Shave the safe picks: make the model name its top 3 fonts, then discard all three. Out-rank yourself.
2. Generate ~50, a blind sub-agent keeps the 5 most distinct. (Lives in Radiant’s codebase, not Impeccable yet.)
3. Seed from outside the model: palette.mjs --from 8f2a starts in a region the model never picks on its own.

This is a better response to repetitive AI aesthetics than accumulating another denylist of fonts and visual effects. The intervention changes the candidate set instead of pleading for a better choice.

The third is “Give them memory · runs that compound instead of restarting”:

Most skill authors treat skills as stateless prompts, but there’s no rule that says a skill can’t have state. Keep in mind that skills can be bundled with scripts that can be run anywhere during the lifecycle of the skill!

Impeccable’s critique and polish commands use this technique quite effectively:

1. /critique writes a snapshot per target (score, P0/P1, markdown + frontmatter)
2. /polish reads the latest snapshot as its fix backlog

One non-obvious detail that makes this work across a team: the snapshot slug comes from the resolved file path, not from how you phrased the request. A teammate pointing at the same file inherits the same memory, and the score trend (24, then 28, then 32) survives across sessions.

This one is immediately practical: save the work on disk, then let the next command pick it up.

If you’re configuring agents for product and design work, start by cleaning up their context. Anthropic’s Thariq Shihipar offers several recommendations; three are especially useful here:

First, replace blanket prohibitions with an instruction that lets the model read the code around it:

In the new system prompt we say: Write code that reads like the surrounding code: match its comment density, naming, and idiom.

That trades a brittle universal rule for a concrete standard the model can inspect.

Second, move specialized guidance out of the always-on context and load it only when the task calls for it:

Since then, Claude Code has gotten very competent at using progressive disclosure- loading the right context at the right times. For example, we moved verification and code review into their own skills that Claude Code could selectively call.

For design and product agents, that leaves room for richer task-specific standards without crowding every session with irrelevant rules.

Finally, Shihipar on what belongs in CLAUDE.md:

Keep your CLAUDE.md lightweight and briefly describe what your repo is for, but spend most of the tokens on gotchas inside of the codebase. For example, you may organize your code to keep types in one monolithic file and nowhere else. Avoid stating ‘the obvious’ things Claude should know by looking at your file system or your repo.

Use progressive disclosure heavily, for example if you have several unique instructions on how to verify your work, create a verification skill and reference it from your CLAUDE.md.

Product designer and UX Planet editor-in-chief Nick Babich describes software development shifting from production to direction. The design version is familiar by now: as interface production gets cheaper, the work beyond the artifact is defining the right problem, directing agents, evaluating output, and owning the result. Babich traces the same shift in software:

Software development as manual code production is dying.

Software development as translating detailed tickets into predictable implementation is dying.

Software development as a protected technical craft that non-programmers cannot access is dying.

But software engineering is evolving into something broader:

Problem definition + architecture + agent orchestration + verification + product judgment + accountability

This changes the role of the developer.

The most valuable skill is no longer the ability to write code.

It is the ability to define the right problem, provide agents with the right context, evaluate their decisions, and verify that the final result actually works.

Software developers are becoming software creators.

I agree. Replace code with interface production and developer with designer, and Babich could be describing our profession. But there’s a problem both fields share: judgment is built by doing the low-stakes work AI now handles.

Junior developers were historically hired to complete simple implementation tasks such as:

• Build a basic interface;
• Write repetitive tests;
• Fix small bugs;

and these tasks allow them to learn from experienced colleagues and grow professionally.

But in 2026, these tasks are precisely the tasks coding agents handle best.

The loop engineering theme explained how to replace turn-by-turn prompting with a system that discovers work, assigns it, checks the result, and remembers what comes next. AI engineering writer and former Google engineering leader Addy Osmani scales that idea into a software factory and adds the governing constraint: the work can move only as fast as humans can review it.

A software factory is many harnessed loops running at once, fed by a queue of work and drained through a review gate into production, with humans owning the whole thing from above. It is not a bigger agent; it is an org chart made of loops.

Osmani follows that definition through the factory’s wiring diagram:

By and large, every box in this diagram is almost zero cost: generation, tests, scanning. They all run at scale for negligible cost. There is only one expensive box that proves stubbornly resistant to scaling, and that’s the review gate. That shiny amber box is “judgment”, and where the crux of the argument about whether we can make development faster and more frequent resides.

For Osmani, the review gate sets the pace. More generation only helps when verification scales with it; otherwise the factory manufactures a queue of code no one has the attention to understand. Imagine a conveyor belt of products being assembled together, only to pile up at the end, waiting for a poor human quality checker.

Osmani turns that constraint into architecture:

You might be thinking that all sounds unglamorous. You’re right. The safety net is made up of perfectly ordinary architectural practices we’ve always known about and mostly ignored: good types and method signatures so that mistakes are caught by the compiler instead of in production; test seams where we can pin behavior and make change observable; laying out the code so the next reader, human or model, knows where to find the thing they care about; keeping call stacks short and legible; keeping component boundaries well defined so a change doesn’t have a huge blast radius; and dependency injection so we can swap out one piece for another. None of it is new. We’ve always said we care about good architecture. But now that we’re using automated coding agents, that architecture is finally doing a second job as a cheap and hard-to-fake safety net against the mistakes the agent will make.

Put plainly, structure the work so mistakes are easy to spot and changing one thing doesn’t break everything else.

For designers, that means clear rules for each component, documented states, testable prototypes, and explicit review criteria. Build loops that can keep moving without you, but let them move only as far as those checks can prove the work is sound.

Kate Conger, writing in The New York Times, shows how Google’s AI Mode can include links to the open web while making them mostly irrelevant. The product gathers information from other sites, assembles an answer, and keeps the user inside Google. That goes beyond the earlier drop in publisher referrals linked to AI Overviews: Google is reconstructing the trip across the web inside its own interface.

Conger starts with Google co-founder Larry Page’s 2004 promise and the bargain that made Google powerful:

“We believe a well-functioning society should have abundant, free and unbiased access to high-quality information,” Mr. Page said.

Google fulfilled that responsibility by acting as a gateway to the internet. It answered people’s search queries with lists of hyperlinks, pushing users out to what is known as the “open web” — the millions of websites run by merchants, publishers, universities and others — for more information. In the ensuing decades, Google became one of the planet’s richest and most powerful companies by directing people to the vastness of the open web.

Now in the age of artificial intelligence, Google appears to be shrinking back from the open web — and may be imperiling it.

That enclosure is a product behavior, not a login requirement. Conger gives a simple example:

While someone might once have Googled a soccer player’s World Cup performance and clicked to a sports site or a social media thread for commentary, a bot now crawls the web for that information and returns the player’s statistics to the user, who stays on Google.

Google says it still sends billions of clicks and highlights links to the web. But those links now compete with an answer designed to remove the need for them. Conger ends with the contradiction:

In May, Vox Media, which owns The Verge and other publications, began selling some of its sites. Jim Bankoff, Vox Media’s chief executive, said the “decimation of search traffic” had influenced his decision to explore other ways of reaching readers, like a podcast network, and ultimately to sell about half of the company to James Murdoch. In June, The Verge and several other Vox Media websites were sold to Penske Media.

Google has often said it was “sending out more traffic and the web is bigger than ever,” Mr. Patel said. “And then right next to that is a bunch of publishers whose businesses are getting destroyed.”

I’ve started using AI this way in a lot of my daily work. In my day job, after diving into a problem, I give Claude the right context and iterate with it to get to a problem brief. In my freelance work, I set the parameters—the concept, style, or general functionality—then iterate with the AI.

AI product manager and builder Karo Zieminski, writing in Product with Attitude, calls this “AI-assisted craft”:

AI-assisted craft means the human sets the intention and the standard for the work, then directs how it gets made. AI gets a defined supporting role. Supporting, as in: it does not get to make the decisions. The practice applies across knowledge work and digital creation, from writing and research to coding and design.

Zieminski separates assistance from direction:

AI-assisted. The human is the primary maker. The choices, mistakes, revisions, and final form are theirs. AI is one of the tools they use.

AI-directed. The model produces the work; the human directs it. That direction must be consequential enough to shape the result. One prompt followed by a shrug is generation with supervision theatre.

Both require the human to make consequential choices. In my workflows, that happens throughout the iteration, not only when I write the first prompt.

Zieminski’s bounded-task rule makes that concrete:

“Improve this” is not a bounded task.

Give the model a job with sharp edges: do this, not that.

Research for me, BUT bring me facts, not conclusions. Challenge my assumptions, BUT do that through Socratic questions so I have to do the thinking. Explain this code block, BUT test whether I understood it. Suggest design fixes BUT don’t bleach my personality out of it. Whatever it is, leave space for my judgment.

I agree, with one small addition: setting the boundary starts the work. AI can’t answer the question at the other end for me: Would another change improve it, or is it time to stop asking?

Companies may be cutting the very workers AI helps most.

A Stanford Institute for Economic Policy Research policy brief by Neale Mahoney, Erika McEntarfer, and Karsen Wahal finds no economy-wide “AI jobs apocalypse.” But its early evidence creates a possible paradox: employment among less-experienced workers has declined in AI-exposed roles, even as experiments show that AI often gives them the largest productivity boost.

Recent graduates are facing the most challenging job market in years, with unemployment rates for new grads reaching 5.6 percent in early 2026, up 1.6 percentage points from three years earlier. This rise has fueled concerns that AI is replacing many of the jobs recent graduates once sought. Junior roles often involve routine research, analysis, and writing tasks that can now largely be done with AI. Consistent with this intuition is empirical evidence that AI may be dampening demand for new hires.

In a widely discussed paper, Brynjolfsson, Chandar, and Chen report a notable decline in employment among early-career workers in AI-exposed occupations, notably software developers and customer service representatives, since ChatGPT’s launch in 2022. As shown in Figure 2, by contrast, employment among older workers in those same occupations remained relatively stable or continued to grow. The authors liken these young workers to “canaries in the coal mine,” the first to experience labor market disruption from AI. Other researchers have since identified similar negative effects on the hiring of young AI-exposed workers in the U.S. and the U.K., beginning in 2022.

The authors are careful not to pin the entire decline on AI. The Federal Reserve’s rate hikes, the end of pandemic staffing surges, and weaker on-the-job learning in remote roles all muddy the timeline. But the hiring decline itself is real, and younger workers in AI-exposed jobs are taking the hit.

Design’s vanishing bottom rung looks even more precarious against this evidence. The brief does not study designers specifically or establish that AI caused the decline. But if employers are closing junior roles in anticipation of AI, that is a business decision, not a technical inevitability. And the productivity findings make that logic even stranger:

In experimental settings, generative AI tools — such as chatbots and coding tools — have often been found to disproportionately improve the performance of less experienced and poorer performing workers. In one such study, researchers analyzed the impact of a generative AI assistant on customer support agents in a large call center. The assistant increased overall productivity by 15 percent, with gains highly concentrated among novice and less-skilled workers, who saw a 30 percent improvement in the number of issues resolved per hour. There was no performance improvement among highly skilled customer service agents, whose response quality fell slightly.

Other studies also show that AI tools generally speed up task completion, though the effects vary by task, context, and skill level. Figure 3 summarizes research findings on the impact of AI tools on speed across a variety of tasks. In software development, the use of GitHub Copilot — an AI tool that suggests code and functions — allowed tasks to be completed 56 percent faster, with gains concentrated among less-experienced programmers. More modest impacts on software development were found in a separate paper, with effects ranging from 10 percent to 30 percent, depending on the firm where it was deployed.

If companies stop hiring the people who benefit most from these tools, who exactly do they expect to become tomorrow’s senior talent?

Most software companies organize product work around squads. Users don’t care. Their workflows cut across the boundaries we draw between teams, so a local decision about a table, filter, or bulk action can become a product-wide inconsistency.

In my conversation with Denis Cristea on UX Spotlight by Userlytics, I described how this happens:

We have this notion in modern software companies around squads and how a squad will own a particular surface area in a product. You’ve got your product manager, product designer, engineering lead, and then a bunch of engineers. So that’s your classic triad and team makeup. Theoretically everyone owns their roadmaps, talks to customers, and decides what to build.

Users don’t just work in one module. Users often work in multiple modules. So they’re already crossing the org chart, if you will. […] When thinking about the entire user experience, you already have to coordinate across different teams.

Meanwhile, you’ve got another module, another group, another team who wants to work on something similar, but they’re not talking to each other. When that happens, that’s when you get the inconsistent user experience. They might solve the same interaction differently.

A design system standardizes the components each squad uses. Weekly critique lets designers see the decisions being made across those squads before separate implementations harden.

I used the example of bulk actions at BuildOps:

The other thing that we’ve been doing a lot on my team at BuildOps, the design team, is the weekly design crit. That’s a way for us to keep the connective tissue together and ensure that the experience across the different modules stays as consistent as we can.

Going back to the bulk actions example, if one team needs it and a designer builds that experience, other designers will see it and say, “Okay, that will actually help my area too. After you design it and create the components, let me take that and put it in my area too, and argue with my product manager to prioritize that work.”

Critique coordinates the product while the squads remain autonomous. It gives teams a shared view of unfinished decisions and a place to resolve them before users have to deal with the seams.

Product managers can use the same ritual:

I would recommend that product managers think about implementing something that designers do, which is critiques. I don’t think product managers have this ritual of sharing what they’re working on and how they’re thinking through problems.

When you build a culture of sharing and oversharing, and also wanting to make everyone else’s work better by giving them good constructive feedback, that’s when the whole product is going to get lifted up.

Quotes lightly edited for clarity.

Yennie Jun, writing for Art Fish Intelligence, asks which parts of thinking we surrender along with the task. Her example shows the difference between asking AI to answer a question and asking it to test thinking we’ve already begun:

I suggested (with only a little bit of initial resistance) that we pause and think about why this might be. I suggested a few theories. Perhaps it was Portugal’s relative homogeneity and religiousness, compared to the US’s diversity of immigrants. Perhaps Portugal clung on to so-called “Age of Exploration” as one of the most prominent chapters in its national story. We wondered, postulated, made wild guesses, backtracked, connected our ideas, disagreed, and remembered historical details we learned in high school many years ago. We drew on our collective memories, knowledge, understanding of the world, and critical thinking skills. We knew we were speculating, and some of our theories were probably wrong; that was part of the exercise.

Eventually, we asked the same question to AI. Its response corroborated many of our theories and supplied several explanations we had missed. It also omitted a few possibilities we still found plausible. We had begun with a question, generated hypotheses, and only then used AI to test and extend our thinking. I relished the exercise.

The backtracking is the point. A finished answer can save time, but repeatedly skipping the work of forming and testing a hypothesis also skips the practice that builds judgment. For designers, that’s the work we should keep, even as it accelerates production.

We still need to use trial and error to learn what to ask or try next. Otherwise, faster production leaves us less able to tell whether what we made is any good.

Jun turns from productivity to autonomy:

Am I any different from the Microphone Man? Perhaps what differentiates me is that I still collected and curated the data, formulated the questions I wanted answered, and evaluated the end results? Or that the data was my own, instead of recording other people’s conversations? There will always have to be some balance between automating menial tasks to free up time for rewarding endeavors, and doing the work yourself as a learning experience.

Jenny, another character in Ken Liu’s story, aims to counterpoint the main character’s over-reliance on his AI assistant. She exclaims, “Tilly doesn’t just tell you what you want! She tells you what to think. Do you even know what you really want anymore?” Our autonomy depends, at least in part, on continuing to participate in forming our own desires. But when we offload thinking about what we want (What music should I listen to? What movies should I watch? What food should I eat? What shoes should I wear?), who do we become?

What are we automating? Human work or human agency? Human tasks or human thinking?

Designers still have to decide what deserves to exist before asking AI to make it.

Om Prakash, writing for UX Collective, argues that chat should handle ambiguous intent rather than replace graphical interfaces:

This is a distinction Erika Hall draws precisely in Conversational Design (A Book Apart, 2018) — arguably the sharpest book written on this subject. Hall argues that conversation is the right design choice only when the system needs to negotiate meaning with the user. When the user already knows what they want — “add to cart,” “filter by price,” “submit the form” — conversation is overhead. Structure is faster, more accurate, and less exhausting. Conversation earns its place only when intent is genuinely ambiguous: when the user is exploring, when their goal is fuzzy, when they need the system to meet them partway.

This framework changes how you evaluate chat implementations in the wild. The products that figured it out early didn’t go all-in on chat. They built hybrid interfaces , structured UI for known, predictable tasks; conversational AI for open-ended, exploratory ones.

For designers, the practical choice comes before any screen or prompt: how clear is the user’s intent?

Choosing the interaction mode becomes more consequential when software can act. A form submission can usually be corrected; an agent may send an email or book a flight before the user realizes it misunderstood. Prakash shifts from intent to oversight:

The UX problem this creates is the most interesting one in our field right now: how do you design an interface for an agent that doesn’t need an interface to do its job, but whose users absolutely need one to trust it?

Ben Shneiderman, in Human-Centered AI (MIT Press, 2022), has been asking a version of this question for years. He argues that the dominant framing of AI as an autonomous agent replacing human judgment is both technically premature and ethically dangerous — and proposes instead a framework of high human control combined with high automation. Not one at the expense of the other. The goal is not to minimize human involvement; it’s to make human oversight legible, accessible, and non-burdensome. Shneiderman’s model is the right north star for agentic UX: not autonomy versus control, but autonomy with control — designed into the system from the start.

This is the transparency paradox of agentic design. An agent that operates silently is efficient and terrifying. An agent that narrates every action is trustworthy and exhausting. The design challenge is finding the right level of visibility — enough that users feel in control, not so much that they’re overwhelmed by a stream of system-generated activity logs.

Jakob Nielsen’s AI-generated illustrations do his work no favors. His visual taste is, to put it kindly, not mine. But Jakob Nielsen has done something few technology forecasters ever do: he pulled out papers from 1993 and 1996, scored 23 predictions against computing in 2026, and published the misses alongside the hits.

The 71% headline is Nielsen’s own grade, and he acknowledges the obvious conflict:

Two clarifications. First, timing gets no separate penalty because the delay affects nearly every row. Neither paper promised a full system within a decade; Noncommand explicitly said such a system was unlikely “within the next ten years, which is about as far as one can predict in the computer field with a minimum of credibility.” The vision nonetheless took 30 years to become a widely shipped product pattern, a delay I return to in the lessons.

Second, I’m grading my own homework, which is an obvious conflict of interest. I’ve tried to score against what shipped and stuck, not against what demos well, and I show every score so you can regrade me.

So I wouldn’t get hung up on whether 71% is exactly right. Nielsen and his late co-author, computer scientist Don Gentner, still saw an intent-driven interface decades before machine learning made one practical. Some of the details are uncanny; others reveal how a sound principle can survive the failure of its original mechanism.

Nielsen on one of those switcheroos:

In 1993, I described moving an on-screen object “by selecting it by looking at it and then pressing a selection button (to prevent accidental selection).” In February 2024, Apple shipped Vision Pro with the same core selection pattern: look at a target, then pinch to commit. The prediction reappeared three decades later with its confirmation step intact. Of course, the Vision Pro remains a niche product, which is why the bandwidth and interaction-stream rows score in the middle of the scale: the high-bandwidth immersive future arrived, but as a sideshow. The main stage went to the lowest-bandwidth input device imaginable: an empty text field.

The physical channel narrowed while the semantic channel widened. Our mistake was measuring the interface by how much raw data crossed it rather than by how much work each user token could trigger. The better metric for AI is intent leverage: useful output divided by the effort required to specify the goal.

And this 1996 sentence comes remarkably close to describing the interface designers should be building beyond the prompt box:

We assumed users already knew what they wanted and just needed a better way to say it. Conversational AI revealed that human intent is rarely a pre-formed cognitive object just waiting to be translated; rather, intent is fluid and often discovers itself through the act of conversation. Current AI user interfaces do little to help users figure out their intent, but even primitive AI UX already supports some degree of iterative co-articulation.

One sentence from 1996 aged better than everything else Don and I wrote: “Real expressive power comes from the combination of language, examples, and pointing.” That’s a working definition of multimodal prompting: type your intent, paste an example of what you want, and point by uploading an image or selecting a region. If I could grade a single sentence at 100%, this is the one.

Language is best for leaping across a large solution space: “make this calmer,” “compare these contracts,” or “plan a week in Kyoto.” Pointing is best for local correction: this paragraph, that number, the face in the upper-right corner. Examples communicate qualities users can’t easily name. The winning AI interface will therefore let language propose, examples constrain, and pointing repair.

Nielsen and Gentner’s prediction worked because the underlying idea was stronger than the technologies they had available. They got the vehicle and timing wrong. They also expected expert users to benefit most. Yet language, examples, and pointing still sound like a better creative interface than an empty text field.

Ben Callahan on what a design system can and can’t guarantee:

A design system can only raise the quality floor. It sets the baseline below which nothing should ship. An accessible-by-default button, a holistic and thoughtful approach to spacing, a template that starts a consuming team ten steps ahead.

But a design system alone can’t raise the quality ceiling. That’s not something you can do by delivering assets. The worst product teams can make awful experiences with the best design systems. That’s because the quality ceiling is set by the choices product teams make with what you give them. It’s their restraint, it’s where they push, and it’s knowing when to deviate from the standard because the standard isn’t serving the end user.

Callahan’s title invokes AI, though the essay only touches it indirectly. The connection follows from his distinction: faster generation and stronger defaults can produce more acceptable work, but neither can decide when the standard is failing the user. That decision still requires careful judgment.

Callahan on the loop:

And, of course, this loop just continues to run. Over time, the quality floor and the quality ceiling are raised.

The most important step here isn’t the shipping of a new component. It’s the time in conversation that results in alignment on a definition of quality.

Your system sets the floor. The way your system is used sets the ceiling. If you’ve poured everything into the first and bowed out of the second, it’s time to step back into ring.

Patrick Neeman, writing for UX Collective, compares today’s AI interfaces to the browser wars:

[Jeffrey] Zeldman did not invent the specifications, he did something harder: He convinced an entire industry that shared conventions were worth fighting for, and he won. Zeldman changed the world with a stance, not a specification and we should thank him for it.

We are living through that moment again, this time for the interfaces we wrap around models, the skills we scaffold on top of them and representations they mean.

The browsers have new names: ChatGPT, Claude, Gemini, and Copilot each handle the same task their own way, with their own conventions for parsing content, showing reasoning, citing a source, and asking permission before they act.

The connection to design systems is structural. Browser standards gave different products a shared foundation without forcing them to look identical. Neeman doesn’t claim that the conventions for AI interfaces are settled; he proposes design systems as the way practitioners can develop and share them:

The core move was to pull structure, presentation, and behavior into distinct layers so each could change without breaking the others. That one idea outlived every specific technology it was built on.

It is why a design system works at all.

When Brad Frost introduced atomic design, he was extending the same instinct: stop shipping pages, start composing interfaces from small, shared, recombinable parts. Design systems are the standards movement’s direct descendant, and they are the closest thing we have to a working model for AI interface conventions.

That working model is already appearing in the Markdown files agents use as project-level contracts:

Agents increasingly take their instructions from plain text files that sit beside the work — AGENTS.md for how an agent should behave in a project, SKILL.md for what a capability can do, README.md for the context around both.

This is the new semantic layer. It is markup again, written in Markdown and read by a model instead of a browser.

[…]

A design.md that carries your design system’s patterns, tokens, and rules into every agent that touches the product. An accessibility.md that states the non-negotiables in language a model can follow. A content.md that fixes voice, terminology, and the content model.

Neeman also points to a broader protocol stack taking shape:

You are not waiting for this to begin. It has begun. A partial map of the standards taking shape right now:

• Model Context Protocol — a shared way for a model to reach tools, data, and context, already adopted across rival platforms and now stewarded by a neutral foundation.
• A2UI — a declarative protocol for agents to describe interfaces that render natively across web, mobile, and desktop, keeping what the interface is separate from how each client draws it.
• Agent2Agent — an open protocol for agents to discover one another and collaborate across frameworks and vendors, launched by Google and handed to the Linux Foundation.
• The W3C AI Agent Protocol Community Group — a grassroots group drafting open rules for a trustworthy web of agents.
• Agent identity work — cross-body efforts, at the W3C and beyond, to verify who an agent is and what it is allowed to do before it acts.

None of these is finished, and that is the opening. The conventions are still soft enough to shape, which is exactly where Zeldman’s coalition made its difference.

Kai Wong asked 32 design leaders what they do when companies mistake faster production for faster design. He begins with a plumber:

Imagine a plumber walks into your house, looks at the pipes for a few minutes, tightens one valve, and hands you a bill for $300. Your first reaction might be, “Anybody could have turned that valve.”

Wong borrows a distinction from neuroscientist and Tiny Experiments author Anne-Laure Le Cunff: “the ancient Greeks had two words for time, not one.”

The first is chronos: time as quantity. The number of hours in a day, the number of weeks in a year. This is the time your projects are based on.

The second is kairos: time as quality. Not how much, but how good. Le Cunff frames it not just as better quality time: it’s having the time to recognize a pattern from everything you’ve seen before and know it’s the right time to act.

[…]

Design runs on Kairos. AI might have made things faster, but businesses don’t need 500 screens by lunchtime.

They need the right solution to their problem. And that comes from the quality of thinking that happens along the way.

Wong closes:

When AI is your competition, the temptation is to compete on its terms. Faster. Cheaper. More. You’ll lose that race. And you’ll produce worse work while you lose it.

Compete on the thing AI doesn’t have. Judgment.

Generation is chronos, and chronos is cheap now. Judgment is kairos, and kairos is the whole job. Protect it. Make it visible. When someone asks you to cut the timeline in half, be ready to explain clearly what they’d actually be cutting.

Laura Summers, writing for the Pydantic blog, describes the strange math of coding agents: the work can run in parallel, but our attention can’t.

Marcelo, another Pydantic colleague, when asked about his Claude Code session freezing said: “just open 5 claude sessions. You’ll never notice because you’re busy giving feedback to the others.” He was joking. I think. But it captures something true about the current moment. The parallelism is exhilarating and kind of feral. The number of things you can start has dramatically increased. The number of things you can thoughtfully finish hasn’t changed at all, because that part still requires the one resource we can’t parallelise: your brain.

The design version is easy to recognize: an agent can generate dozens of screens and states while one brain still has to judge the product intent and every edge case. You may spend less time drawing the interface, but every state still demands a decision.

Summers calls the emotional cost “the human reward function problem”:

Here’s a term for what I think is happening: the human reward function problem. In machine learning, a reward function tells an agent what good looks like. Writing code by hand was never easy, but it was full of small rewards. Solving a problem in your head. Understanding a gnarly bit of logic. Watching the code compile. The feeling of control. LLM-assisted programming has automated much of the work that generated those dopamine hits and replaced it with the cognitive load of review and supervision. The satisfying part shrank. The exhausting part grew. And there are no new rewards to fill the gap.

If you’re feeling like your work is simultaneously more productive and less satisfying, you’re not broken. The feedback loop is broken. And I think we need to start treating that as an engineering problem in its own right, not a personal failure.

I’ve intentionally covered loops a lot this week. It’s been the talk of the virtual town of late, so it’s an important concept to understand as AI-assisted software design and development continues to mature.

MC Dean pulls it all together practically for designers in this piece. She reminds us that designers need to stay in the conversation; be in the room where it happens:

The conversation about AI and design tends to run in one direction: here are tools you can use to do your job faster. That framing keeps designers in the task loop. Tools help you execute. The loop stack shows you where the real work is.

The real work is authoring the system loop. Writing the specifications that constrain how AI behaves. Encoding the quality standards that define what good output looks like. Making the judgment calls that no loop below the oversight layer can make on its own.

Taking a “loop stack” built by engineers, she adapts it for designers:

At the base: the execution loop. The model fires, tool calls happen, tokens generate. This is genuinely not your concern. You don’t need to understand transformer architecture to design well with AI, any more than you need to understand TCP/IP to design a good website.

One layer up: the task loop. The agent works on a specific thing until a condition is met, then stops. Who defines that condition? You do. “The task is complete when the output meets the brief” is a design decision. What counts as meeting the brief is yours to specify.

Then the product loop. This is the experience layer, the thing a person actually encounters. Does the flow hold together? Does the output feel like it belongs to a coherent system? Does it match the quality bar? Every heuristic you’ve ever learned, every design principle you’ve internalized, lives here.

Then the system loop. This is where the AI gets better, or doesn’t. The patterns it learns, the constraints it operates within, the values it embodies. Design systems, behavioral specifications, brand guidelines, content principles, tone of voice. Everything you’ve encoded about what good looks like. This is the layer that trains the loops below it.

At the top: the oversight loop. This is where human judgment lives permanently. Not as a checkpoint at the end. Not as a review gate before launch. As a continuous presence that can redirect anything in the stack at any time.

This is what we call “craft”.

In the full post, she shares a prompt for you to try that illustrates how the loop actually works. Go try it.

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.

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.