A third of people in managerial positions say they’re currently considering a move back to individual contributor work. That’s 32% in The LeadDev Engineering Leadership Report 2026, up from 24% a year earlier, out of 600 engineers surveyed between March 31 and April 16, 2026. The report puts its own question plainly. Whether this is “a healthy recalibration or a warning sign about sustainability in the leadership pipeline is a question the industry will need to take seriously.”

That’s engineering data. Design has no equivalent number, which is a problem of its own. More than half of this sample manages people, so it’s the closest read available on what’s happening inside the management layer.

The explanation going around is that the craft got good again. James Stanier, chief technology officer at Nordhealth, gives the generous version of it in the report: “Given that most leaders come from an IC path, and now that AI tooling makes it so much easier to contribute, I’m not surprised leaders are getting more hands on.” Chantal Kapani made the fuller case in LeadDev in January, that scope, flattening and a frozen market turned management into a dead end.

The pull theory doesn’t fit the breakdown

If the craft were doing the pulling, the people standing closest to it would move first.

They didn’t. Managers of engineers, one step from the work, went from 30% to 34% in a year. Managers of managers went from 14% to 29%. The group furthest from the craft is the group whose interest in leaving roughly doubled.

Those people aren’t one prototype away from the fun part. They sit two approvals from it, and better tooling does nothing for them. Whatever moved them, it wasn’t Figma getting faster.

What the role picked up instead

The same report holds the other half of it. Just under half of respondents, 45%, work more hours than they did a year ago, up from 38% in 2025 and 35% in 2024. For managers of managers it’s 46%, against 42%. A quarter of them now spend more time on technical tasks than they did last year, up from 18%.

The report’s own summary: AI is “expanding what leaders can do technically and what is expected of them organizationally, without reducing the demands on their time in either dimension.”

Read it as a job description. More hours, more technical work and nothing taken off.

The seat above got scarcer

Across the whole sample the manager count roughly nets out, 22% reporting fewer managerial jobs against 19% reporting more. The shape of the cuts is the part that moved. Where organizations did cut manager roles, the cuts landed on middle management in 65% of cases and line management in 59%. Upper management was significantly hit in 23%, up from 18% in 2025 and 13% in 2024. The report describes a flattening that “is becoming less selective in who it affects.”

Tyler Blackwell scored the forecast behind all of this on October 8, in Layers Not Linear. His grade: the direction was right and organizations are flatter, the size never came close, and the companies that did flatten mostly gave reasons other than AI. One line of his, on a 1993 review of the same question, is the useful part. “The technology didn’t decide it. Who held the decisions did.”

So the work went up, the hours went up, and the layer you would get promoted into started getting cut as well. Working that out takes a spreadsheet, not a mentor.

Design leaders are writing the same job

In AI in Design 2026, 32% of design leaders expect to keep headcount the same while raising output expectations. Another 10% expect to reduce it. Designer Fund and Foundation Capital surveyed more than 900 designers across 60 countries.

That’s the job a design manager is handed this year. Same team, more output, and the decisions that matter sitting one level up.

Doug Powell wrote up design leadership week at UXINDIA on October 5. His research with graduate students at Washington University in St. Louis found no clear playbook for moving into leadership, and gaps in mentorship and leadership development. He’s right about that gap. It’s a gap on the way in.

The 32% is the gap on the way out. Preparation doesn’t touch it, because the people considering the exit are the ones who already know exactly what the job is.

What I give a manager to own

The trade management used to offer was easy to state. You give up most of the making and you get the decisions. Take away the making and leave the decisions a level up, and the role’s a message queue with a title on it.

So when a manager reports to me, I name what ships without me. Not what they run or coordinate or represent in a meeting. What they approve, which surfaces that covers, and where my opinion doesn’t get a vote.

That costs something, and the cost should be said out loud: work goes out that I’d have done differently. A senior product designer on my team at Best Egg ran the button component audit from start to finish, the agent and the remediation both, and the calls inside it were hers. I built and ran the whole-library audit across 296 files and wrote the crawler’s rules. Hers wasn’t a smaller copy of mine with my sign-off at the end. It was hers.

The version of the role without that is a manager who carries the hours and forwards the decisions. That’s the role 32% say they’re thinking about leaving.

The question the report left open

Healthy recalibration or pipeline warning. It’s neither. It’s a price.

The role used to be paid in decision authority. That authority moved up a level or into a queue, and the hours stayed. People are reading the terms and declining. The sharpest jump came from managers of managers, 14% to 29% in one year, who are close enough to the top to see what they would be climbing toward.

The measurement problem with generative interfaces is real, and the field has been straight about it. When the screen gets assembled per person, there’s no fixed A to put against B. The design agency Orizon said it plainly in August: “A/B testing gets harder when there’s no fixed ‘A.‘” Their other line is the sharper one. Time on page means nothing if the page is different every time.

So the answer that’s settled in is to grade the output instead. Score each render with a model, calibrate that model against expert human labels, ship when the agreement is good enough. Statsig’s guide to testing AI products recommends judge scoring for exactly this reason. Arize’s says to compare the judge’s decisions with trusted labels and keep human review involved in defining the rubric.

I’d do the same thing. What I’d argue with is what happens to that rubric once somebody writes “expert human labels” and starts tuning toward them.

What the platform holds still

Start with what the experiment can still do, because it’s narrower than people assume. Optimizely’s bucketing documentation is specific: a user with the same ID always sees the same variation, because the platform hashes user IDs consistently. That’s a guarantee about the variant. It was never a guarantee about the screen.

Which means the test runs fine. Put the generator in one arm and a drawn design in the other, and the number that comes back is about the generator. It says the policy beat the page, on average, for that population, in that window. It says nothing about the screen one applicant got at 11 on a Sunday night.

That isn’t the method failing. It’s the method answering the question you asked it. The design question used to ride along for free, because the thing sitting in the arm was a screen somebody drew and somebody else approved. Now the thing in the arm is a generator and the screens arrive after the result.

The labels don’t agree

So the judge carries the design question by itself, which makes calibration the step worth reading slowly.

In April, Yi-Hao Peng, Samarth Das, Jeffrey Bigham and Jason Wu put 20 trained designers in front of generated mobile interfaces, everyone with at least a year of professional UI experience. Each rated the same 600 pairs. 12,000 labels in total. On the plain question of which interface in a pair was better, their average Cohen’s kappa came out at 0.25, on a scale where 1.0 is perfect agreement and zero is chance.

Agreement that low normally means a sloppy task or careless raters. The authors went and checked. Thirteen of the designers wrote 1,378 rationales on the pairs they’d split over, and the disagreement held up as systematic. They were weighting different design dimensions, not guessing. The authors’ conclusion is the part to take away: a single aggregate judge loses that signal.

A second group reached it from the other side. In July, Zheng Wu and four colleagues wrote that a judge of this kind reflects only one implicit viewpoint, and that a homogeneous one erases disagreement between user subgroups. Replacing the single judge with a panel of grounded personas moved correlation with human ratings from 0.716 to 0.922. Their panelists still agreed on which model was better overall. They diverged on the individual dimensions.

What a deployment threshold actually is

Read the calibration step again with that in hand. Appen sells rubric design for judges and describes the work honestly. An LLM judge is only as reliable as the rubric it’s given. Calibration is the systematic measurement of agreement between judge scores and expert human rater scores on a calibration dataset, and the rubric gets refined until agreement meets your deployment threshold.

Tune a rubric until it agrees with a pool of raters who agree with each other at 0.25, and you haven’t measured design quality. You’ve picked a side in an argument those raters were having. Hierarchy over density, or density over hierarchy. Familiar over faster. The rubric that ships is the one whose weighting got rewarded, and the threshold makes that look like convergence.

Then the ruling runs on every screen the system renders, at a volume no review meeting has ever touched.

Who makes that call

On most teams the rubric belongs to whoever runs evals, with designers brought in as raters. That’s backwards, and the research is already saying so. Hyewon Lee and colleagues, writing in September, start from the position that designers stay responsible for what a generative interface produces while being unable to specify or even see every interface it might produce. Their system trains its scoring model on designers’ own edits.

That responsibility is the job description now. What the scorer rewards is the last design call a person makes before a million screens get rendered without one.

When a team brings me a generated surface, I ask two things before I look at any screens. Which comparison produced the number. And whose judgment is in the label set the scorer was tuned against. If the answer to the second one is the eval team plus whichever raters were available, then the product’s taste got set by a staffing accident.

The trade I work from is that the team owns the method and I own the standard. A scoring rubric is a standard with a number bolted to it, so it’s mine to sign, the same way a design review was. It’s slower than approving screens. It’s also the only part of the work that survives the screens being different every time.

Those 20 designers were not split because one group was wrong. A judge tuned to 0.25 agreement reports one of their weightings as the standard, and the rest get outvoted by a dataset.

The Federal Reserve asked for comment on two stablecoin proposals on September 24, and they hit the Federal Register five days later. Rewards are the right place to look if you’re deciding whether to launch a dollar token. Writing in The Pulse Monitor on October 9, David Annen put the open question on platform rewards: platforms that fund customer rewards with revenue received from issuers “may have to change those payments under the final rules.”

Section E of the same proposal is about something else. The Board took exclusive authority over the GENIUS Act’s tying prohibition for every permitted payment stablecoin issuer in the country, including the ones it doesn’t supervise. The staff memo describes a rule that would stop an issuer from providing services to a customer “on the condition that the customer (i) pay for an additional product or service from the PPSI or its subsidiaries, or (ii) agree not to obtain an additional product or service from a competitor.”

A condition isn’t a line in the terms

Read that as a designer and it’s a spec. What it prohibits isn’t a document. It’s a state: this person couldn’t get the thing they came for without taking the second thing.

That state gets built on a screen. A toggle that starts on. Two products presented as one choice with one button. A decline that drops you back at the top of the flow, or into a support queue, or onto a page that doesn’t say what you still have. None of that turns up in a contract review and all of it is the condition.

The guidance after the proposals landed went the other way. Willkie’s team wrote on October 5 that issuers “should review product-bundling, account-opening, reserve-management, distribution, and commercial-partner arrangements for any conditions that could constitute tying.” That’s sound advice about agreements, and agreements are where the word optional gets written down. The flow is where it’s either true or it isn’t.

One rule leaves a trail

The yield ban is enforceable because somebody paid somebody. The Board’s proposal would presume a violation when the payment reaches holders through certain third parties, matching the approach the OCC took earlier this year. Either way there’s a ledger with the answer in it.

Redemption is the same kind of rule. An issuer has to publicly disclose its redemption policy, and that policy can’t carry a redemption period longer than two business days unless a safe harbor applies. A document to read, a number to check it against. Tying has neither.

This one has failed before

Nellie Liang and William Dudley looked at the Act in March and noted that stablecoin issuers are subject to anti-tying provisions, then added that “enforcement of anti-tying prohibitions has often proven difficult in practice.” Their example of how a firm gets around the interest ban runs on the same machinery. A provider or third party could “bundle the stablecoin offering with ‘free’ ancillary services.”

That difficulty isn’t legal. A condition assembled out of defaults leaves no record behind, so there’s nothing to examine afterward. The screen that created it ships again next quarter with a new layout, and the version the customer saw is gone.

What would make it checkable

Four rules about the screen would cover most of it. Each one can be checked against a build:

• The decline sits on the same screen as the accept, at the same weight, not behind a link or a back button.
• Nothing about the second product is pre-selected.
• Declining continues the first product’s flow instead of restarting it or ending it.
• The second product is named for what it is, including what it isn’t.

An examiner can verify all four in a prototype. None of them needs a lawyer.

What I ask for

When a team brings me a flow that adds a second product, I ask to see the version where the customer says no. Not the accepted path with the offer sitting in it. The refusal, clicked through, end to end. If that path isn’t built, the second product isn’t optional yet, whatever the terms page claims.

On Cross-Sell at Best Egg we put a secured loan in front of people at the worst moment there is, right after a decline. Applicant interviews run before design started said they couldn’t tell what they were being offered: “Best Egg could make it clearer, ‘this is not a title loan’. Somehow or another, you’ve got to get that on a page.” Saying what the product wasn’t did more for that offer than the layout did.

The Board has posed more than 250 questions across the two proposals. The five Willkie’s authors call most consequential are about reserve diversification, interest rate buffers, physical currency as a reserve asset, liquidity treatment and whether tokens tied to reserves are securities. Comments are due on or about November 30, and the provision that will be hardest to enforce is the one that needs somebody to draw a screen.

Remote employers have started designing interviews around the possibility that the candidate is cheating. The Wall Street Journal’s account of the tactics, republished on September 1, goes company by company. One company asks candidates to show their surroundings and wave a hand in front of their face, and checks IP addresses after finding people who said they were in the US and weren’t. Another dropped its take-home assignment once the submissions came back heavily generated, and moved to screen sharing and live exercises. A third requires finalists in person, on a company laptop.

None of that is paranoid. If you hire remotely, identity is a real question now, and the people selling detection didn’t have to invent the demand.

The argument running alongside it is about disclosure. Candidates want to be told when a machine is scoring them, and most think it should be the law. Fifty-seven percent of US candidates told Greenhouse that companies should be legally required to disclose AI evaluation. The remedy on offer is a clearer notice at the top of the funnel. Daniel Chait, who runs Greenhouse, makes the honest version of the case for the tools: “A 15-minute conversation with an AI where a candidate can show who they are is a better front door than a keyword-stuffed resume.” He’s right about the resume.

The number nobody is arguing about

Greenhouse surveyed 2,950 job seekers across the US, UK, Ireland, Germany and Australia for its 2026 Candidate AI Interview Report. Nearly two-thirds of US job seekers, 63%, say they’ve already sat through an AI interview. The finding that should stop a hiring manager is further down the page. “Of US candidates who completed an AI interview, 51% never received an outcome.”

Not a rejection. No outcome at all. They did the round and the process went quiet.

Thirty-eight percent of US candidates have already withdrawn from a hiring process because it included an AI interview. The UK cut of the survey, reported in People Management on April 30, says the safeguard candidates asked for most often was the option of a human interview, at 45%. Only 19% wanted less AI in recruitment at all.

So this isn’t a revolt against the machine. People object to being processed by one and then dropped.

The capacity went to the cheap half

The cost in a hiring loop was never evenly spread. A first-round screen is the most schedulable hour in the company. The expensive step is the one after it, where somebody senior reads the work, forms a view and commits to a yes or a no they’ll defend in a debrief. That step doesn’t scale with tooling. It scales with someone’s attention, and it was the bottleneck before any of this arrived.

An AI interviewer adds throughput to the first step and nothing to the second. Run it and the queue in front of the decision gets longer. Fifty-one percent with no outcome is what that queue looks like from the candidate’s side.

Greenhouse says as much in its own write-up, which is unusual for a vendor describing its own category: “Without clear criteria and consistent evaluation, AI doesn’t improve hiring”. The rest of that sentence is that it “exposes where the process breaks.”

The round design can’t hand off

Design hiring has one round where this bites hardest. A portfolio review isn’t a knowledge test. You’re there to find out which version the candidate killed, why they killed it, and whether the reason survives you pushing on it.

That’s a follow-up question, and the follow-up is the whole instrument. A pre-recorded video, scored after the fact, can’t ask it. Candidates have worked this out: the most common reason US candidates gave for abandoning a process was an AI-scored pre-recorded video with no human present, at 33%.

Generated work raises the stakes on that round. When the screens show up finished, the judgment that picked them is the only thing left to assess.

Where I’d put the hour

I don’t add a round to a loop I can’t close. If there’s no named person who reads what comes out of it and sends an answer inside a stated window, the round doesn’t go in, however cheap it is to run. A round nobody closes isn’t a filter. It’s a backlog with a better front door.

The other half is writing the criteria down before the req opens, rather than after three candidates have been through and the panel is arguing from memory. What good looks like for this specific role, in enough detail that someone who missed the debrief can hold a candidate to it. That’s what makes a structured loop worth running, and it’s what an AI interviewer assumes you’ve already done.

Detection can tell you a candidate used a model. It can’t tell you whether you’d hire them, and it won’t close a single open req.

The arms race over camera pans and hand waves will keep running, and some of it is earned. It still isn’t what’s costing anyone people. Thirty-eight percent of US candidates have walked out of a process over the round that was added to make hiring faster.

Tanner Kohler published the maintenance version of context engineering at Nielsen Norman Group on October 9. The markdown files your agent reads are infrastructure, so they should be short, findable and audited when your work changes. His summary line is that your agent is only as powerful as its context library.

I’d sign all of it. The trouble shows up in the same article, in how the people furthest along actually maintain those files.

They aren’t writing the file

Kohler’s participants rarely typed into their context files at all. They described what they wanted and let Claude do the editing, often across many files in one go. They “rarely checked what Claude had changed”, and judged the result by whether the output got better. Some had global files the agent created without their knowledge. Plenty couldn’t find their own files when they went looking. One library held more than 2,700 of them.

The study underneath that article is worth reading on its own. Kate Moran and Sarah Gibbons ran sessions in June with seven nontechnical people running agentic systems at work. One of them went digging and found a boundaries.md file holding the security and privacy rules for their system. Claude had written it and had been maintaining it. They authorized it after the fact.

Most of the time I will just click “yes” for things that [it] asks me, even if I don’t understand what it means

Participant, Vibe Architects, NN/g, June 2026

That’s a security story in the article. For a design leader it’s a document-control story, and the document happens to be ours.

That file is a spec

Design teams have been handed this exact file and told it’s the new deliverable. Call it DESIGN.md, call it the rules file, call it the system’s instructions for agents. It holds the usage guidance, the sentence that says when not to use the component. That’s the half a machine-readable design system drops first. Whatever ends up in it decides what the generated screens look like for every person who runs the agent after you.

So it’s a spec, and design already knows how a spec behaves when nobody owns it. Somebody adds a paragraph in a review. It contradicts itself by the second quarter. The team stops reading it and goes back to asking the one person who knows what the standard really is.

The loop runs backwards

The part I’d flag hardest isn’t that the agent edits the file. It’s that the edit gets graded on the output.

The rule exists to decide whether the output is right. Grade the rule by the output and the direction reverses. The work the agent produced becomes the evidence for the rule the agent wrote. In a crit you’d catch that in a second. The same author brings the work and the standard it should be held to, and the standard shows up second.

None of this is the tool misbehaving. Anthropic’s documentation is direct about what these files are. Claude “treats them as context, not enforced configuration”. If you want an action blocked no matter what the model decides, the docs send you to a hook. The same page splits its two memory systems on one question, which is who writes it. CLAUDE.md is written by you. Auto memory is written by Claude. The power users in the study rubbed out that line and kept the filename.

What decays

Kohler’s other piece, from October 2, says where this lands. Systems built with nothing forcing a priority turn into what Foote and Yoder called a big ball of mud. One holds up fine until “accumulated complexity makes the system difficult to direct, diagnose, or reconstruct”. One participant lost 45 minutes pulling the wrong files out of an unsorted folder. Another couldn’t rebuild their own system. A third said it in three words: “The systems decay.”

Kohler’s prescription is that “the discipline that matters most is not tidier folders but periodic reflection”. That’s right, and on its own it isn’t enough. Reflection needs something to reflect on. What’s missing isn’t a tidy folder. It’s a record of what changed and who decided it.

A name and a date

When a team brings me screens an agent built, I ask who made the last change to the file the agent read. I want a name and a date.

“The agent suggested it and the output looked better” is a real answer, and it’s the finding. It means the standard moved and no designer was in the room when it did. Then the screens in front of me only tell me the agent agreed with itself.

When I ran the agent audit across the whole Best Egg library, I wrote the crawler’s rules myself. The audit runs again on the first of every month. That setup has one property I’d now call the whole point. When a number moves, either the files changed or a rule changed. I can tell which, because changing a rule is something I did on purpose and wrote down.

A design system ships with an owner, a version history and a note about what changed. That isn’t ceremony. It’s the only reason somebody who wasn’t in the room can hold work to it a year later.

The file that tells the agent how to use that system does the same job now, across more screens and with no changelog. In the study, nearly every participant assumed someone else must be doing this more cleanly. Seven people, and each one believed the clean version of this was sitting in somebody else’s folder.

Hawaii’s kiosks stopped taking cash on October 1. Act 224 makes it an unlawful practice to own, operate or manage a kiosk in the state that accepts United States currency in exchange for a digital financial asset. Selling crypto for cash at one is still fine. The legislature’s findings cite investigations by the attorneys general for the District of Columbia and Iowa that put the fraudulent share of kiosk transactions as high as 90%.

Most states went the other way and wrote rules instead. Both choices are an argument about the machine: whether it should be there, how much it should take in a day, how big the warning on it has to be. The sentence that machine puts in front of a person who is being defrauded right now is not part of the argument.

What the laws actually give back

Warnings and caps don’t return money. The refund right does, and it’s built as a claim with a clock on it.

Arizona’s section 6-1236 took effect on September 26, 2025. A new customer who was fraudulently induced into a transaction gets a full refund including fees, on three conditions: they contact the operator within 30 days, they contact a law enforcement agency or the attorney general within 30 days, and they hand the operator a report from one of those agencies determining that they were fraudulently induced. Attorney General Kris Mayes said in August that 35 people had recovered $171,332 that way.

Florida wrote the same idea with different arithmetic. Section 560.507, effective January 1, 2027, requires a full refund within 72 hours, for the customer’s first virtual currency transaction only, if within 60 days the customer notifies both the kiosk business and a law enforcement or governmental agency and provides proof of the fraud, “such as a police report or a notarized affidavit”.

So the path back runs through two phone calls, a document and a date. Miss any one of them and the statute has nothing for you.

The warning says the opposite

Arizona requires the operator to present two warnings that the customer has to accept before the machine will transact. The second one opens like this: “Losses due to fraudulent or accidental transactions are not recoverable. Transactions in virtual currency are irreversible.”

For a fraudulently induced new customer in Arizona, the first of those two sentences isn’t true. Subsection H of the same statute is why. The legislature appears to have noticed, because subsection I says a fraud victim is eligible for a refund even if the operator provided the disclosures in subsections A and B.

There’s a fair reading that rescues the warning. On the chain nothing is recoverable, and the operator’s refund is a statutory duty rather than a reversal of the transfer. That distinction would hold up in a hearing. The person reading the warning isn’t in a hearing. Arizona’s own text, a few lines earlier, describes who they’re talking to: “communication from someone impersonating a representative of your bank or a law enforcement officer”. The statute names the scam in progress, tells the target the loss is permanent, then gives them 30 days to undo it.

The machine already knows

Eligibility turns on facts the operator holds and the customer doesn’t. A new customer in Arizona is someone who has been a customer of that operator for less than 10 days, and the statute converts them to an existing customer automatically on day 10. Florida’s refund turns on whether this is the customer’s first virtual currency transaction. Both are counters in the operator’s own records.

The screen is already running that kind of logic. Florida’s section 560.504 requires the kiosk to ask the customer to confirm what they’ve transacted at other kiosks that day, and the amounts, so the machine can work out how much it will still accept. It computes a number from the customer’s own history before it takes the cash. It just never says what that same history means for getting the cash back.

Everything a person would need is sitting right there at the moment of the transaction. Whether they’re inside the window. The date the 30 days runs out. The two agencies to call. The phrase “fraudulently induced”, which is what the report has to say. Florida’s receipt is required to carry the business’s refund policy, which is the closest any of these laws get, and a policy isn’t a deadline.

The federal bill returns the fee

The Stop Crypto ATM Scams Act, introduced on June 11, 2026 by Sean Casten and María Elvira Salazar, would set national caps, require warnings and red flags before each transaction, and make operators promptly refund the fees they collected on fraudulent transactions. Full refunds stay a state question, which the bill preserves on purpose.

Hawaii’s legislature wrote down why that matters. Its findings record that operators “have consistently argued that, while the cash may be in the machine, the victim’s money has already been transferred to the scammer, and the operator is unable to assist the victim in recovering the money.” That’s the obligation the refund sections override, and the screen never mentions it.

The FBI’s kiosk supplement to last year’s crime report counted 13,460 complaints in 2025 and $388,981,267 in reported losses, up 23% and 58% from 2024. The bureau notes those losses involve kiosks alongside other transaction types rather than kiosks alone. More than half of the complaints came from people over 50.

What I’d put side by side

At Best Egg the app knew which customers had a lower rate available and showed them a generic invitation anyway, the one saying you’re pre-approved for another loan. I set the design direction for a card that leads with the rate that customer is pre-approved for and sits beside the loan it would replace. Two designers took it through their own product teams, and it shipped in seven weeks, worth $2.6M in additional originations from native mobile since launch on September 8, 2026.

The card wasn’t the hard part. I got product, marketing and compliance to agree on one rule: the offer a customer sees in email, on the web and in the app is the same offer. One rule checked across three surfaces, because the same company had been telling the same person different things depending on where they looked.

That’s the check I’d run on a kiosk. Put three texts next to each other: what the screen says before the transaction, what the receipt says after it and what the statute says the operator owes. In Arizona those three don’t agree.

Hawaii decided the machine shouldn’t take cash at all. In the states that kept the kiosks, the refund right is the consumer protection, and its clock starts the moment the bills go in. The screen that starts that clock is required to say the money isn’t coming back.

Ask design leaders what the ideal product team looks like now and a job title shows up that most orgs didn’t have two years ago. In AI in Design 2026, among the leaders who didn’t select “product designer” as a core role, 72% selected “design engineer” and 44% selected “AI design specialist.” Designer Fund and Foundation Capital surveyed more than 900 designers across 60 countries for it.

The instinct is sound. Designing a screen and building it have collapsed into one motion on a lot of teams, and somebody has to be good at both ends of that.

Then you read the structure question in the same report. Half of respondents, executives and managers and individual contributors alike, say their teams haven’t made significant structural changes. Only 7% added new AI-focused roles.

So the design engineer is the stated ideal of a field that has mostly changed nothing. The gap between those two answers is the interesting part, and it isn’t a budget story.

The receipt is in the collaboration numbers

A third of respondents, 34%, say collaboration has become messier, with roles and ownership less clearly defined than before. Twenty percent say collaboration has decreased outright. In 2025 that number was 5%.

Four times worse in a year. Whatever that is, it didn’t happen because designers got worse at talking to engineers.

The cause isn’t mysterious. The work picked up more authors and nobody moved the ownership to match. “Roles and ownership less clearly defined” is the respondents’ own language, and it describes a definition problem rather than a skill problem.

The capability already spread

One number should settle whether a title is the fix. Half of all respondents have pushed AI-generated code to production, product and brand designers included. Only 20% identify as design engineers.

The hybrid work is already being done by people whose job description says something else. Hiring a design engineer on top of that doesn’t change who ships. It gives one person a title for work half the field is doing without one.

It also tells everyone else their job didn’t change. The AI work routes to the person hired for it, every other role definition stays exactly as it was, and the new capability sits with one hire who can take it with them.

What DoorDash changed instead

Shali Nguyen, head of consumer experience design at DoorDash, describes the other move in the same report. Their pull request process stayed as it was. “Everything goes through GitHub PR approvals, and designers are held to the same production-quality bar as our engineering counterparts.” Then they added one thing: “We’ve added a design review step where designers are tagged to review and approve UI changes before they go to production.”

No new role. A named approval, bolted onto a step that already existed, with designers answerable to the same bar as the engineers next to them.

That’s what a structural change looks like once it’s written down. It survives a resignation. It applies to everyone who touches the surface, including the product manager who generated a screen on Tuesday afternoon.

What I ask before opening a role

When someone brings me the case for a new kind of designer, I ask which approval is currently unowned. Not which skill is missing. Which decision gets made today by nobody in particular.

There’s usually an answer, and it’s a step rather than a person. Then the real question is whose name goes on that step and what standard they hold the work to, and I can write that down this week without a requisition.

The trade I work from is that the team owns the method and I own the standard and the decision. The method turns over every quarter now. The standard shouldn’t, because the standard is the part you can hand to somebody who wasn’t in the room.

The cleanest version of that I’ve done is the whole-library audit at Best Egg. I built and ran it across 296 files, wrote the crawler’s rules and directed the remediation. Writing the rules was the actual work. A rule precise enough for a crawler to apply is a standard that no longer needs me sitting in the review. A senior product designer on the team ran the button component audit end to end, agent and remediation, and that one was hers.

Where the title earns its place

The DesignWhine editorial team, writing in April, calls the AI design engineer “a high-value specialization, not a universal career direction” and ties demand for it to specific conditions: a high cost to translate design into code, or AI features built into the product itself. That’s the honest version of the case. Under those conditions I’d hire for it.

What the role can’t do is settle ownership. A specialist makes the hybrid work better where there’s a lot of it. A specialist doesn’t decide who signs off on a screen a product manager generated last night, and that’s the part 34% of the field says got worse.

Adding a role is the half of this problem a leader can solve in a budget conversation. Changing who approves what means editing job descriptions, review steps and somebody’s authority, and that one makes people unhappy in meetings.

Seven percent of teams added the role. Half changed nothing about how work gets approved. The collaboration numbers moved anyway, in the wrong direction, and a title on an org chart has no approval step attached to it.

On October 5 Jakob Nielsen gave the synthetic-user argument its cleanest form. Use AI personas to open up the problem, then put real people in front of the thing before you ship it. He called it syntheticipation and wrote the rule as “Diverge with silicon; validate with carbon.”

He’s right, and he has the receipts for it. When Nielsen Norman Group ran synthetic users against three studies they had already done with real people, the synthetic answers came back agreeable and flat. A real learner said “I didn’t finish all the courses.” The synthetic one said “I completed all the courses I mentioned.” Nielsen’s conclusion from it is “Real users are meaner. Cherish that.”

So the rule guards one door. It decides who answers the questions. It doesn’t say anything about who writes up the answers.

The fight is over the part almost nobody uses

User Interviews surveyed 150 research professionals in May. Eight percent actively use tools that simulate participants. 28% reject the idea outright and 47% call themselves skeptical and want more evidence first.

In the same survey, 80% said they use AI regularly in their work. Maze asked nearly 500 researchers and product people over the new year and found 69% using AI on at least some research projects, up 19 points in a year.

Read those together. The loud argument is about a tool fewer than one in ten researchers has adopted. The quiet default, already in most studies, is a model reading the transcripts and telling you what’s in them.

Trust peaks exactly where it shouldn’t

Lyssna asked 300 practitioners how much they trust AI across the synthesis tasks. Trust falls as the task takes more interpretation: 82.9% for summarizing, down to 25.6% for visualization.

That ranking makes sense if summarizing is compression. It isn’t. Summarizing is selection, and something has to be left out for the summary to be shorter than the thing it summarizes. What matters is what gets cut, and that has now been measured.

What a summary does to an objection

A study published in March benchmarked 18 language models on aggregating opinions and scored how well each summary represented the people in the source. Minority views lost. Bias against them ran 34.4 times larger than random bias, consistently, across every model and every topic they tested. The paper separates people who see themselves as a minority from positions that are semantically in the minority, and finds both under-represented in the generated summaries.

A January paper by Aghaebe and colleagues names the mechanism. Summarizers resolve disagreement while they write. Handed a set of people who don’t agree, the model converges on the dominant view and the dissent comes out the other side as consensus.

The failure here isn’t inaccuracy. The summary is accurate about the majority. The problem is that the one person who said the thing nobody else said is the cheapest line to cut, and that person is usually the reason the study was worth running.

On the Cross-Sell work at Best Egg, applicant interviews before design started turned up this, from someone who had just been declined: “I probably won’t use you again. It made me mad and frustrated.” One person, one sentence, and it set the shape of the work. I put it in the before-state flow next to the dead end and it’s still on the case study. A good themed summary would have filed it under negative sentiment at decline. True, and nothing to design from.

The quote that argues against the recommendation

When a team brings me a synthesis, I ask for the strongest quote that argues against the recommendation. Not the limitations slide. A sentence a real person said that makes the recommendation harder to make.

If nobody can produce one, I don’t assume the finding is wrong. I assume nobody has checked whether the disagreement survived the write-up, and the study goes back until someone has looked. Usually the objection is sitting in a transcript nobody reopened. The check costs an afternoon, because the raw material never left the building.

The same question works in an interview. Not whether a candidate uses the research tools, which everyone does now, but what the inconvenient finding in their last study was and what they did about it.

Where the rule needs extending

Validating with carbon and writing up with silicon gets you a study with real people in it and a deliverable that reads like agreement. The participants were real. The disagreement died in the summary, and the team acted on the summary.

So extend the rule one step past the participant. The objection belongs in the synthesis, in the words the person used, with the recommendation it cuts against named next to it. If it isn’t in there, the study isn’t finished, however many real humans sat for it.

The standard answer to AI underwriting right now is per-feature attribution. Compute each applicant’s contribution scores, rank them, map the top few onto reason codes. That beats the older habit of back-filling a plausible reason from the application form after a score came back, and the people building it aren’t wrong.

It stops one step short of the applicant. The notice is the only part of a credit model a denied person will ever read, and Regulation B lets it be a noun.

The playbooks cite guidance that’s gone

A compliance guide dated May 1, 2026 opens by saying that “CFPB Circulars 2023-03 and 2024-06 require specific, accurate reasons for every adverse action.” Circular 2023-03 was withdrawn on May 12, 2025. So was 2024-06, which covered hiring and employment screening rather than credit. Both went out in one Federal Register notice that withdrew 67 guidance documents at once.

Circular 2022-03 went with them, and that’s the one worth missing. It asked whether a creditor using algorithms complex enough to obscure the reasons still owes the applicant specific ones, and answered that “ECOA and Regulation B do not permit creditors to use complex algorithms when doing so means they cannot provide the specific and accurate reasons for adverse actions.” Its page is still up at the original address. You would have to read the Federal Register to know it no longer applies.

The Bureau’s most recent circular is 2024-07, from December 2024. The notice put its reasoning as removing compliance obligations imposed outside notice-and-comment rulemaking. Whatever you make of that, the documents telling lenders a checkbox isn’t a reason are no longer operative, and at least some 2026 compliance writing still cites them as binding.

What the regulation still asks for

ECOA didn’t change and neither did Regulation B. Section 1002.9(b)(2) requires a statement of reasons that is “specific and indicate the principal reason(s) for the adverse action.” It closes the two easy exits: a creditor can’t point at internal standards or at a failing score.

The official commentary is where the ceiling sits. On quantity, the regulation “does not mandate that a specific number of reasons be disclosed, but disclosure of more than four reasons is not likely to be helpful to the applicant.” On depth, it gives an example. “A creditor need not describe how or why a factor adversely affected an applicant. For example, the notice may say ‘length of residence’ rather than ‘too short a period of residence.‘”

The compliant floor is four nouns, accurate to what the model actually scored, carrying no direction and no size. Length of residence. Someone reading that can’t tell whether they’d lived somewhere too briefly or too long, or whether it shaved a few points off or decided the entire application. A model can be fully interpretable and still produce that notice, because the notice gets written somewhere else by someone else.

The screen isn’t the notice

Here’s the distinction the explainability work skips. The adverse action notice is a formal document on a 30-day clock. The screen where a person finds out is a different artifact, and Regulation B has nothing to say about it.

Best Egg’s decline screen read “Unfortunately, we are unable to approve your application at this time.” Every declined applicant left the funnel there. On Cross-Sell we replaced that dead end with a secured loan offer for the people who qualified, which came to about $40M in Home Secured and $3.7M in Vehicle Equity originations.

I raise it for the sequence, not the number. The applicant reads the screen first and forms a view of what happened. The notice arrives days later, to a person who already decided. Different teams own those two surfaces at most lenders, and neither one treats the pair as a single explanation.

Where this is still enforced

In July 2025 the Massachusetts attorney general settled with Earnest Operations, a student lender, for $2.5 million. The coverage went to the model, fairly. There was a knockout rule that denied applicants on immigration status and a Cohort Default Rate variable that fell harder on Black and Hispanic applicants.

The notices were in there too. Ballard Spahr’s summary of the allegations lists “inaccurate adverse action notices that prevented applicants from understanding their own creditworthiness.” That isn’t a modeling finding. An inaccurate notice is a string that doesn’t match what the system did, which makes it a content and interface problem that ended up inside a $2.5 million settlement.

What I ask for

Before I’ll take a lender’s explainability story seriously I ask for two things: the full list of reason strings the system can send, and how often each one fires. Not the model card. The strings.

A ranked attribution that terminates in a list nobody has opened since the integration shipped explains nothing. If no one in the room owns that list, the interpretability work is decoration. The string that fires most often is the one to rewrite first, because it’s the sentence the largest number of declined people are going to read.

Federal guidance saying a checkbox isn’t a reason has been gone since May 2025. Regulation B still permits “length of residence.” Everything a denied applicant understands above that floor is a design decision, and at most lenders it’s being made by whoever wrote the strings first.

The advice going to design leaders this year is to get your hands back on the tools. Katie Dill, head of design at Stripe, puts it plainly in AI in Design 2026: “If leaders want to understand what’s actually possible and how their teams need to adapt, they have to get close to the makers and hands-on with the tools themselves.”

She’s right, and I’d go further. A design leader who hasn’t built anything with an agent is guessing about the work their team does all day, and the guess shows up in the standard they hold.

The question nobody attaches to the advice is which hours it replaces.

The second job was already there

Gallup put the question to a random sample of 16,442 American managers and leaders. Ninety-seven percent said they carry individual contributor work on top of leading people. The median manager spends 40% of the week on it.

So getting hands-on isn’t a new allocation. It’s a bigger share of a half that was already full.

The same study carries the number being passed around this fall. The average team went from 10.9 direct reports in 2024 to 12.1 in 2025, nearly 50% larger than when Gallup first measured in 2013. The median held at five or six. The average moved because the big teams got bigger, not because every manager woke up with more people.

Span isn’t the variable

Chris Cancialosi made that case well on September 29. Writing about the flattening, he argues that span of control “is not an independent variable. It is a multiplier on a condition set somewhere else.” The condition is the individual contributor load. A manager with four reports and a full delivery queue is in worse shape than one with 14 reports and nothing to build.

His fix goes to human resources. Screen managers on two numbers, team size and estimated time on non-managerial work, then intervene where both run high.

That fix assumes somebody assigned the work. In design, increasingly, nobody did.

The leader picked it up. An agent made producing look free, so the thing that used to take a designer a week now looks like an afternoon on the leader’s own calendar. It doesn’t feel like taking on delivery work. No screen catches it either, because on paper it isn’t a delivery queue. It’s curiosity, and the field is telling leaders to have more of it.

What comes off the calendar instead

The report that carries Dill’s advice also tells teams to “run crits more often, in smaller groups. Shorter, more frequent sessions mean that feedback happens while the work is still in progress.” One team in the study went from weekly crits to 4x weekly crits across sub-groups.

Read those two recommendations next to each other. Both are good. Both are drawn on the same week, and only one of them has a meeting invite with other people’s names on it.

That asymmetry decides which one survives a bad month. Prototyping with an agent is work a leader can do at 9pm with nobody noticing it moved. A crit that gets skipped is visible to eight people, which is exactly why it’s the first thing a leader quietly stops defending when their own build queue fills up. Nobody announces it. The invite stays on the calendar and the quality of what happens inside it drops.

The one finding I’d plan around

Gallup’s most useful result isn’t about team size at all. About seven in 10 employees were highly engaged regardless of team size when they strongly agreed they had received meaningful feedback.

Regardless of team size. Feedback is the part of the job that keeps working at 14 reports. Hands-on tool time is the part that doesn’t scale with anything, because it only ever informs one person.

Manager engagement fell from 27% to 22% between 2024 and 2025, the sharpest year over year drop Gallup has recorded, and nine points below where it sat in 2022. Those are the people now being told to add a build practice.

How I spend the week

Most of my week goes into feedback. Weekly reviews, structured critique and time on specific work with specific people. I’d rather give a little every week than a lot at once, because feedback that arrives in a batch arrives after the decision.

On the cross-sell work there were two products, two roadmaps and two release calendars. I ran the weekly reviews for both myself so the patterns stayed shared across them. That was the expensive choice and it was the right one.

I do the hands-on part too. I built and ran the whole-library audit at Best Egg across 296 files, wrote the crawler’s rules and directed the remediation, which was weeks of my own hands on an agent. I scheduled it around the reviews rather than through them. A senior product designer on the team ran the button component audit end to end, agent and remediation, and that was hers.

Here’s the check I’d run this quarter. Count the hours you spent producing last month against the hours you spent giving feedback, then ask which of the two numbers you’d defend to your team out loud.

What the advice is missing

Get hands-on. The advice is right and the people giving it are right about why. What it leaves out is the trade, and the trade is bad. You learn the tools faster, and your team gets less of the one thing Gallup found holds engagement at any team size.

Ninety-seven percent of managers had a second job before agents made the second job look easy. The hours for the new advice come from somewhere, and the crit is the softest thing on the calendar.

Michael Bernstein published a two-page vision paper for UIST last month arguing that interfaces are about to stop being durable things. Software construction is getting cheap enough that we’ll build them at the moment of need instead, which he calls “rapid, discardable, on-demand interfaces tailored to our needs in the moment”. When you’re finished with one, you “tear the interface away like a used sheet of paper, and start your next task on a blank one.”

He takes the obvious objection seriously inside the paper. Just-in-time interfaces break Nielsen’s consistency heuristic, and Microsoft already rolled back adaptive menus once because people couldn’t predict them. His bet is that usefulness wins anyway, the way file sharing won despite terrible affordances. I think he’s probably right, and familiarity is the objection everybody reaches for first.

It’s the sentence about us that should stop a design leader.

we create the levers that shape what gets created and how they operate, but we may never lay hands or eyes on the last-mile interfaces themselves

Michael S. Bernstein, The Interface of Theseus, September 2026

That’s an operations sentence, not a philosophical one. If the designer never lays eyes on the screen that shipped, no one else does either, and the screen is gone by the time anyone wants to discuss it.

The strongest demo was a bank

This isn’t a thought experiment waiting on better models. Google Research ran a within-subject study with 72 participants on Penny, a digital banking prototype, comparing an adaptive generative version against a fixed one. The adaptive version scored 84.38 on the System Usability Scale against 53.96, a gap of 30 points. The authors put it down to cutting what they call the navigation tax.

A separate Google team showed the generation itself holds up. Yaniv Leviathan and 11 colleagues found that generated interfaces are overwhelmingly preferred over the markdown wall of text an LLM normally returns, and at least comparable to expert-crafted work in half of cases. Trond Wuellner has been making the practitioner case for shipping this since May.

So the evidence is real, it’s good, and the place it was measured most convincingly is a banking app, where every screen in the product is a disclosure of some kind.

The record is already in the transport

The fix is cheaper than the problem sounds, because of how these screens travel.

A2UI, the protocol Google opened up for agent-driven interfaces, doesn’t ship code to the client. The agent sends a JSON payload carrying a component tree and its data model, and the client maps that onto its own native widgets. The screen exists as a document before it exists as pixels. Every generated interface in that architecture is already serialized, already small and already passing through a server.

Neither the protocol’s own introduction nor Google’s launch post says anything about storing it, logging it or replaying it. Both are about getting the screen rendered correctly and safely, which is the right job for a spec. What happened afterward is left to whoever builds the client, and right now the default is that it’s gone.

Finance already requires reproduction

The E-Sign Act has had an answer to this since 2000. Under 15 U.S.C. 7001(d)(1), an electronic record kept to satisfy a retention requirement has to accurately reflect the information and stay accessible “in a form that is capable of being accurately reproduced for later reference”.

A rate, a fee schedule or a repayment term assembled for one person at one moment and then thrown away isn’t capable of being reproduced for later reference. It isn’t a design preference that the bank keeps a copy. It’s the condition on doing it electronically at all.

What I ask in a review

When a team brings me a surface that a model composes, the question I ask isn’t whether we can explain the model. It’s what the person taking the call sees when this customer calls back about this screen.

That question has a way of settling arguments fast. If the answer is a transcript, or a reconstruction, or a confident guess from a dashboard, the design isn’t finished no matter how well it tested.

On the document verification work at Best Egg, applicants who had uploaded their files couldn’t tell what was pending, so they called to ask. We gave each document a status they could see, and the verification rate went to 71% against 61% for control in the live A/B test, sized with product and operations at 7,000 fewer support calls a month. The screen was fixed, so the applicant and the agent on the phone were at least describing the same thing. Take that away and the call starts with both people guessing.

Two halves of one deliverable

If Bernstein’s equilibrium shift lands the way he describes it, the design deliverable splits in two.

The first half is the one the field is already building: the catalog, the rules, the signals, the evaluation criteria. The generator. That work is underway and A2UI’s trusted component catalog is a good version of it.

The second half barely has a name yet. It’s the record of what the generator actually produced for a given person at a given moment, kept long enough and structured well enough that a support agent, a reviewer, an accessibility audit or a regulator can put it back on screen. Not analytics about the session. The session’s interface, re-renderable.

Designers are good at arguing for the first half, because it looks like design. The second half reads like a storage bill, so it lands on an engineering backlog and stays there. It’s worth more than that. It’s what makes a generated screen something a company can stand behind after the fact.

The JSON that drew the screen is sitting in the transport layer already. Throwing it away is a decision, and at the moment it’s the one being made by default.

On September 22 six banks published a shared set of principles for trusted agentic commerce: NatWest, ASB Bank, Bank of America, Capital One, Commonwealth Bank of Australia and ING. Hans Overeem, who runs payments at ING, put the point plainly. “As AI agents enter the payments ecosystem, customers must remain in control, understand what the agent is doing, and have confidence that their data and payments are secure.”

A week before that, Mike Lawler and Josh Gottheimer introduced the Stop Rogue AI Act, which hands NIST the job of writing standards so an organization can “allow, deny, or revoke an agent’s access, actions, and interactions at any time, so people have the final say over what it can access or do.”

This is the one thing the whole industry agrees on, and it’s correct. Revocation has to be there.

Both documents treat it as a capability. A capability is something a system has. Revoking is something a person does, at a particular second, usually because they’re alarmed, and what they need at that second is not a switch.

Authorization and the purchase come apart

A team at Southern University of Science and Technology, the Indian Institute of Technology and City University of Hong Kong modeled four agent payment protocols in Tamarin at the end of August: x402, the Machine Payments Protocol, the Agentic Commerce Protocol and AP2. Across 86 verification cases they turned up 40 findings that hadn’t been documented before. One sentence in their introduction explains why this is hard, and it’s about sequence rather than cryptography.

“A user may authorize a task before the final merchant or terms are fixed, so each subsequent step can be locally valid while the transaction as a whole is inconsistent with that authorization.”

Read that as a calendar. The person grants authority on Monday. The agent picks the merchant on Wednesday, the money moves Thursday and the box arrives the week after. Revoking on Wednesday evening lands in the middle of that, and which parts it reaches depends on plumbing the person can’t see.

The specs are detailed about the front of that sequence. AP2’s core concepts give the Intent Mandate a list of authorized payment methods, the shopping criteria and an expiration time. Taking it back isn’t on the page. Visa’s Trusted Agent Protocol announcement, from October 14, 2025, is about how a merchant recognizes an agent it can trust. The consumer’s side of revocation isn’t in it either.

Identity already wrote this down

RFC 7009 is the OAuth token revocation spec, and it’s honest in a way product copy never is. “The invalidation takes place immediately, and the token cannot be used again after the revocation.” Then, a few lines later: “In practice, there could be a propagation delay, for example, in which some servers know about the invalidation while others do not.”

It goes further. “If the authorization server does not support access token revocation, access tokens will not be immediately invalidated when the corresponding refresh token is revoked.” Pull the thing that issues access and the access it already issued can keep working.

That has been in the spec for years, in the plumbing agent payments are built on. The difference now is that the token spends money.

The revoke that counts is the bank’s

There’s also a legal answer to where the switch belongs, and it’s older than any of this. Regulation E says a transfer isn’t unauthorized when it was initiated by “a person who was furnished the access device to the consumer’s account by the consumer, unless the consumer has notified the financial institution that transfers by that person are no longer authorized.”

Everything turns on that last clause. The revocation that changes a person’s position is the one their bank hears about. Switching the agent off inside the agent’s own app, which is where a person would obviously go to do it, is housekeeping.

Six systems out of 21

Alexandra Michael and Franziska Roesner at the University of Washington reviewed 21 agent permission systems proposed between 2024 and 2026, plus five commercial agents. Their finding on this point is blunt. Of the 21, “only six clearly provide ways for users to change or revoke permissions after the policy has been specified,” and two of those six only allow the change between sessions rather than during one.

They name the assumption underneath it. These systems “assume that a one-time decision extrapolates to all future circumstances.”

They’re writing about agents in general, not payments. Payments is where that assumption carries a dollar amount.

What the screen owes a person

Visa’s own research found about half of respondents worried about “decisions made without me.” Asked whether they’d still use a shopping agent without control over their data, 54% said not very or not at all likely. Those were online surveys of card holders who shop online monthly: 1,600 in the United States, 1,600 in Australia and 500 in New Zealand.

A revoke screen that says “Access removed” answers a question about the system. The questions a person actually has are about their money, and there are four. What did my agent already commit me to? Which of those does this switch stop? Which of them is still coming anyway? Where do I go to cancel each one?

That’s a list, and lists are generated from state somebody has to go and fetch: orders placed and not shipped, an authorization approved yesterday that posts on Friday, the subscription the agent started under its own credential at the merchant. None of it is exotic. It just isn’t anybody’s ticket, because the feature shipped when the grant screen worked.

So in any review where a screen hands something authority, I ask to see the second screen in the same session. Not the confirmation. The one where a person takes the authority back, and what it lists when they land on it. The first screen is usually in high fidelity. The second one is usually a line in a backlog.

At Chainlink Labs I directed Staking v0.1, and the call I made there was about where the facts sit. The pool gauge, the reward rate and the remaining allotment went next to the stake action, so nobody had to leave the page to decide.

Charlie Liu, writing Agentic Commerce Daily on October 2, summed up the week as trust and payment infrastructure “hardening around continuous authorization and open standards.” That’s a fair read of what’s being built. Continuous authorization means the grant keeps working while nobody is watching it, which makes the moment somebody wants it to stop more consequential.

The switch most products will ship lives in the agent’s app, because that’s where the agent lives. Regulation E puts the one that changes a person’s legal position at their bank. Somebody is going to decide which of those a person gets, and on current evidence it’s whoever owns the settings page.

Sixty-seven percent of organizations now link AI skills to promotion criteria. Half tie them straight to performance ratings. Both numbers come from HiBob’s 2026 AI skills research, which surveyed 1,200 decision makers across six regions in February and March.

In design the change has a face. An executive at a publicly traded company told the AI in Design 2026 survey that every design role now has AI craft skills in the rubric, “built into our mid-year and annual review cycles to measure where in the percentile each employee sits relative to peers in these new craft skills.” Meta did it at scale first. Janelle Gale, its head of people, told staff last November that AI-driven impact becomes “a core expectation” from 2026.

I don’t think any of that is unreasonable. A leader who watches the work change this fast and leaves the ladder untouched is pretending nothing happened.

The part the rubric doesn’t touch

HiBob’s own write-up in Charter, published September 22, names the gap this way: “AI skills are entering performance reviews before many companies have defined what ‘good’ actually looks like.” The proposed fix is clearer standards.

Define the competency better and you still have the older problem underneath it. A performance review is an evidence exercise. You read the work, you read your notes, you decide. The work used to carry authorship on its face. It doesn’t now.

Designers say so themselves, in the same AI in Design survey. Forty percent call the direction and judgment fully theirs. Another 43% say the work is mostly theirs while they’re aware AI shaped outcomes they didn’t fully control. Nine percent say it’s “genuinely hard to separate” their contribution from the tool’s.

Read that as a measurement problem rather than an identity one. When the person who made the file isn’t sure which parts were their call, a manager opening that file eight months later is not going to recover it.

Someone already named this

Keyuri Anand wrote the sharpest line on it in August: “Your promotion did not disappear. The evidence you used to earn it did.” She calls it the proxy collapsing. Polished artifacts stopped signaling judgment because they got cheap.

Her advice goes to the designer. Own a system, stop shipping tasks, build something that proves judgment. That’s good advice and it’s aimed at the wrong person. A designer can’t fix the evidence base a company promotes from. The manager owns that, and right now the manager is being handed a new rubric line and the same broken packet.

Tommy Geoco made the structural version of this point at UX Tools last week. Writing about design career ladders, he argues that most technology panic “isn’t about the tool. It’s about what happens when the old path to competence disappears before anyone builds a new one.” The path up was also the path along which a manager could watch someone’s judgment develop. Both of them went at the same time.

The behavior they ranked first

The same research has a finding that didn’t travel. Asked which everyday AI behaviors matter most, decision makers put two at the top, tied at 52%: proactively reviewing output quality, and documenting workflow decisions.

So the field already knows what it needs. Neither of those is a proficiency. Both are records. You can’t percentile-rank someone on documenting workflow decisions, which is probably why 67% of organizations wired promotion to AI skills instead.

One more finding from the same research. Only 36% of organizations that expect managers to build AI capability see those managers as highly prepared to do it.

What my review notes carry now

I run weekly design reviews, and what changed is what leaves the meeting written down. The call, the reason it went that way and the name of the person who made it. Not the file. The decision.

It takes four or five lines. The reason I bother is that a promotion case assembled in November from work done in March is a reconstruction, and a reconstruction favors whoever talks about their work most fluently. Notes taken at the time favor whoever was right.

At Best Egg I wrote the crawler’s rules for the whole-library audit before the agent touched a file, across 296 files. Those rules are the artifact that shows what I thought good meant. The 28 fixes a run produced show that the agent worked. Separately, a senior product designer on the team ran the button component audit start to finish, agent and remediation, and that sentence is in my notes because in eight months the files won’t say it.

The 13% who changed something

Betterworks surveyed 2,387 HR leaders, managers and employees this year and found executives six times more likely than employees to believe performance reviews and goal setting have kept up with AI-driven work. In the same study 49% of HR leaders rank AI use as a top influence on performance. Nine percent of employees think it matters to their success.

That spread is what a rubric change looks like from underneath. The line gets added, the cycle runs, and the people being measured can’t tell what it bought them.

In design, 13% of leaders have updated official performance review metrics or hiring practices at all. The ones who did mostly added a skill. The evidence their reviews run on hasn’t changed, and it no longer records who decided what.

The standard answer to generated interfaces is review. A model writes the screen, someone looks at it before it ships, and the bar holds because a person was in the loop.

That works for the defects a person can see.

In February, WebAIM ran its yearly scan of a million home pages. It found detected WCAG failures on 95.9% of them, up from 94.8% a year earlier, and 56.1 errors on the average page, up 10.1%. Nearly every one of those pages belongs to a team that would tell you it reviews its work.

What looking can’t find

Focus order. Accessible names on icon buttons. Whether a modal traps focus or drops the keyboard behind it. Contrast ratios. An error state carried by a red border and nothing else.

Writing on DEV on September 26, a developer publishing as LXSAIHUB worked through the mechanism: those are the defects that survive a screenshot and survive a code review read at normal speed. Their dashboard example is three icon buttons with no accessible name, a button wrapped around an SVG and nothing else.

None of that is a judgment call. It’s a set of facts about the markup, and a person looking at a rendered screen has no way to check any of them. Color, hierarchy, copy and layout review fine from a screenshot. Everything in the list above needs a keyboard or a script.

Mikhail Prosmitskiy made the engineering version of this argument in Smashing Magazine on June 30. Accessibility is an operational capability, like reliability or security, and models produce inaccessible markup by default. He’s right, and the tooling he points at is the right tooling. The part his piece doesn’t have to deal with is that a lot of this markup no longer arrives through engineering at all.

The markup for a screen increasingly comes out of a tool a designer is driving, and designers brought a review method with them that was built for pictures. It’s a good method. It catches the things it was built to catch. It has never had a step where somebody touches a keyboard, because it never needed one.

The tool’s explanation isn’t the build

There’s a second failure underneath. If you can’t see the defect, the reasonable fallback is to read what the tool says it did.

A paper submitted on July 24 by Kashif Imteyaz and five co-authors benchmarked exactly that. They ran 24 UI generation tasks across five generative UI tools, 120 interfaces in total, and compared each stated design rationale against the interface that actually came out.

A quarter of the rationales weren’t implemented. For functional requirements it was 34%. On average the tools recognized 54% of the UX principles written into the prompts, and four of the five implemented 6% or fewer of the functional ones. The authors call it design theater: a plausible explanation with no dependable connection to the code.

So the rationale isn’t review either. It’s a second artifact that needs checking.

The code works anyway

This isn’t a story about weak models. In April, Syed Mohammad Kashif and six colleagues had Cursor build 10 large projects, averaging 16,965 lines and 114 files each, then ran static analysis across them. Average functional correctness came in at 91%. The same projects carried 1,305 design issues by one analyzer and 3,193 by another, with accessibility among the most prevalent categories.

The code runs and the markup is wrong at the same time. A demo won’t surface that and a passing test suite won’t flag it.

A check that can fail the build

I’ve argued on this blog that the judgment in a design system is the part you can’t automate, and I still think that. This is the other case. Accessible names, focus order, contrast and landmarks are mechanical, checkable and dull, which is why leaving them to a human eye is hard to defend once the volume goes up.

At Best Egg I built and ran an audit across the whole component library. I wrote the crawler’s rules and directed the remediation that came out of it. The report wasn’t the useful part. The rules being written down was, because the same check could run again and the answer didn’t depend on who was looking that day.

That’s the shape I’d ask for: the check runs on every build and it can fail the build. Not a review-day checklist and not an audit at the end of a quarter. Prosmitskiy’s version of this is that accessibility should depend on process instead of memory.

In the review itself

In a design review I ask whoever’s presenting to put the trackpad down and tab through the screen while everyone watches. It takes about 20 seconds. It finds the focus trap, the control that announces nothing and the step you can’t reach without a mouse. Nobody enjoys it the first time.

The written standard matters more than which linter you pick. If no one on the team can say what good means for a disabled state or an error message, no tool will decide it, and whatever the model produced becomes the standard by default.

WebAIM’s scan and that static analysis run both turned these defects up with no person in the room. That’s the clearest argument available for putting the same kind of check in the pipeline and letting it stop a release.

Theodore Sterling, writing at chargeback.io on August 21, 2026, named the gap in agentic commerce disputes: “Today’s tools can’t capture the mandate that proves an agent stayed inside the customer’s limits.” Three things are missing, he says. The customer’s authorization, the agent’s identity and a tamper-resistant record tying the two together.

Networks and dispute vendors are building all three. It’s the right work, and it lands one step too late.

Somebody picks the reason first

A card dispute doesn’t reach an investigator as an open question. It arrives with a label already on it. The cardholder opens the app or calls the number, and the first thing they’re asked is what kind of problem this is. Their answer becomes a reason code, and that code decides which rules run, what the merchant gets asked for and how long everyone has.

Sterling names the codes an agent purchase lands under today: “A disputed agent purchase files under a reason code you already work with, most often Visa 10.4, 13.1, or 13.3.” Other fraud in a card-absent environment. Merchandise not received. Not as described.

Now read that list as somebody whose shopping agent bought a $400 espresso machine they never asked for. The machine arrived, so it isn’t a not received claim. It’s exactly as described, so it isn’t that one either. Nobody stole the card. The only box left says a person used the card without permission, and that isn’t true, because they set the agent up themselves.

The box most people will pick

They’ll pick fraud anyway. It’s the closest thing on the list to “I didn’t want this,” and it’s the box with a trapdoor in it.

Regulation E defines an unauthorized electronic fund transfer as one “initiated by a person other than the consumer without actual authority to initiate the transfer and from which the consumer receives no benefit.” It then excludes a transfer initiated by “a person who was furnished the access device to the consumer’s account by the consumer, unless the consumer has notified the financial institution that transfers by that person are no longer authorized.”

You furnished the access device. On purpose, to your agent, in a setup flow that almost certainly called it connecting your card.

Whether that exclusion reaches software at all is unsettled. Eli Clemens argued at ITIF on March 23, 2026 that Regulation E “provides no clear framework for how to handle disputes in agentic commerce,” and that the CFPB should say plainly that “consumer-authorized agents do not waive all error resolution rights.” Nobody has said it yet. So the person at the intake screen is making a legal argument they don’t know they’re making, by tapping the least wrong option on a menu.

The clock starts at the statement

The timing rules don’t help either. Under 1005.11 the notice has to reach the institution “no later than 60 days after the institution sends the periodic statement.” The bank then has 10 business days to investigate, or up to 45 if it puts a provisional credit on the account, and up to 90 for point-of-sale debit claims.

Those clocks run from the statement date, not from the day the person noticed. An agent buying quietly through a month gets most of that window before anyone reads a line of it.

Amex built a second path

One network has done something a customer can actually see. American Express commits that “if a Card Member authorizes a registered AI agent to make a purchase, and that agent sends American Express the customer’s authenticated purchase intent, American Express will protect eligible customers from charges related to AI agent error.” It says that protection sits “in addition to ordinary course dispute resolution processes.”

That’s a real commitment, and it tells you something. Amex built a second path because the first one has nowhere to put this. Look at the conditions too: a registered agent, and authenticated intent that actually got sent. Miss either one and the customer is back at the reason list with everyone else.

What I look at first

On any product where money can go wrong, I ask to see the list of reasons a person can pick from when they report a problem, before I look at the flow being demoed. That list is short, usually inherited, and usually owned by nobody in the room. It’s also the only place a person gets to say what happened to them, and everything downstream is decided by which line they tap.

If the true reason isn’t on the list, the product has decided that problem doesn’t exist.

I’ve watched what a screen with no honest option does to people. At Best Egg the decline page told applicants their application couldn’t be approved and stopped there. One of them told us in an interview, “I probably won’t use you again. It made me mad and frustrated.” The fix wasn’t better wording. I set a cross-sell framework for the funnel, and the team replaced “Rejected” with a few questions about the vehicle, so a declined applicant could say something about their situation and get a secured offer instead of a dead end.

The mandate record is worth building, and it’ll get read after a case that was already sorted into the wrong pile by someone choosing from three options, none of which described what happened. That list is a design surface. Right now it’s inherited from a world where the only thing that went wrong was a stolen card.

On September 25, Dan Graves, chief product officer at WitnessAI, published an account of how his product team works now. Seven people, each managing a role-based agent with subagents under it. A product design agent called Muffin turns mockups into working code. An orchestrator called PacMan routes tickets. Release velocity doubled. By the team’s own weekly measure, interfaces designed, each user experience designer now produces what three used to.

It’s the most specific writeup of an agent-run product team I’ve read this year, and he’s candid about what broke. Muffin’s early designs “looked right on the surface but used the wrong components and missed our branding”, and developers reworked half the output. A senior designer picked “finish the load animations” off a list of options just to point Muffin at the task, and Muffin started building. That’s a real account, not a case study with the failures sanded off.

The sentence I keep going back to sits in the middle of it. “We’ve since automated the path from specification to ship, which only moved the constraint. The human reviewers are now the bottleneck.”

Then he says where the money went

Further down the same piece: “Together, these gains have let us defer hiring new staff.”

He’s right on both counts, and the two point opposite ways. The team found its constraint and then spent the surplus everywhere except on it. Output at the designer level went up three times. The number of people who can look at that output and say no stayed at seven.

I don’t read that as carelessness. It’s what a throughput gain feels like from the inside. The queue gets longer at the last step, which is the least visible place for it to get longer, and the savings from not hiring land this quarter while the cost of a thin review lands in something that ships wrong two quarters from now.

It isn’t one team’s problem

Two days before that piece ran, Qodo published a Censuswide survey of 500 American software developers and 300 American engineering leaders, all at companies where AI already does real work in the development lifecycle. The two groups answered separate questionnaires and never saw each other’s answers. Asked to name the primary constraint in their delivery pipeline, both picked reviewing and validating AI-generated code, at 26% each. It outranked trusting the output, integration, security and compliance, context retrieval and cost in both samples.

Two audiences with different incentives, one answer. The report’s line for it is that “generation scaled across the entire lifecycle, and verification never scaled with it”. In the same research, 89% of organizations reported an AI-related production incident, and 3.7% of engineering leaders said their current processes are enough to hold quality as agents take on more work.

That’s engineering data. The design version is on the same curve now, because design output goes into the same pipeline. When an agent hands a reviewer finished frontend code with the mockups attached, the reviewer’s problem is the one those 800 people just described.

Teaching agents to out-review humans

Graves’s answer to his own bottleneck is to push the review down to the agents. His team aggregates everyone’s review questions into a checklist the agents run every time, then asks Claude for other industry review practices and teaches those too. “Eventually, an agent reviews things 100 ways automatically, leaving less that requires a human eye.”

Half of that is right and it’s the half nobody should be arguing with. If a check can be written down as a rule, a person should never run it twice. Component use, contrast, the naming, whether the empty state was drawn at all: that work belongs to an agent running at three in the morning.

The other half files a hundred checks and one decision under the same word. A checklist can tell you the screen conforms. It can’t tell you the screen shouldn’t exist, that the flow asks an applicant for a document they won’t have on a Sunday, or that the answer is correct and still wrong for this customer. Automating the first job doesn’t create capacity for the second. It clears the desk faster and leaves the same people holding the part that was always scarce.

The hire you already paid for

Box’s 2026 State of AI in the Enterprise surveyed 1,640 information technology decision makers across the United States, United Kingdom, France and Japan in early May. 58% expect headcount to rise over the next three years. Among the most mature adopters, 79% do. The companies furthest into this are not the ones planning to be smaller.

So deferring a hire is a choice, and it deserves to be argued as one. A team that triples its output has earned the case for another person who can decide. Making that case is harder than banking the saving, because the deferred hire is a line a finance partner can see and a thin review is not.

How I plan a team now

I size a team by what it can decide in a week rather than what it can produce. When I ran the whole-library audit of Best Egg’s design system, the plan divided at write access: specs and lists to the agent, every edit to the library to one senior product designer, and the order set by who could act. The agent was never the constraint. One read-only run produced 28 fixes with deep links into Figma. Write access was the constraint, and we built the schedule around it instead of finding out later.

Before anyone on my team adds an agent, I ask two things. Who signs this off, and what else is already on that person’s desk. If the answer is someone already at capacity, the agent isn’t adding throughput. It’s adding a queue with their name on it.

Graves knows exactly what his agents cost. He publishes the figure: $2,000 to $5,000 per person per month. The review those agents generate doesn’t appear on any invoice, which is most of the reason it’s the easy thing to defer.

Nielsen Norman Group published a framework last week for deciding when to tell people AI was involved in your work. Taylor Dykes calls it PACED: policy, audience, context, expectations and degree of use.

It’s careful work and it names the awkward part honestly. People say they want disclosure and then think less of the person who gives it.

I’d use that framework tomorrow. I also think the question underneath it’s set up wrong, and a good framework built on a bad question inherits the problem.

“AI was used here” is a fact about a tool. Nobody on the receiving end is asking about the tool.

The label costs something and says nothing

Envato surveyed 1,780 creative professionals for Beyond Adoption. Fifty-eight percent have used AI on client work without telling the client. Only 31% always disclose.

The more interesting number is the reason. Of the people who said nothing, 48% said they don’t see why they should have to disclose every tool. That gets read as a rationalization. It’s half right.

Nobody itemizes Figma, the stock license, the plugin or the Slack thread where the idea actually came from. A tool name has never told a client whether the work is any good.

And the penalty for saying this particular tool name is measurable. Dykes cites the studies: ratings drop as the disclosed share of AI involvement goes up. The research Florida International University wrote up from Joel Carnevale, Anand Benegal and Lynne Vincent is the part that should stop people. Listeners marked a composition down when they were told AI was involved, and the hit landed whether they believed the piece came from Hans Zimmer or from a first-year music student.

The same penalty fell on a master and a beginner.

A signal that can’t tell those two apart isn’t carrying information about the work. It’s carrying a reaction to a category, and we’re building policy on top of it.

Provenance is not review

Article 50 of the EU AI Act became applicable on August 2, 2026. Synthetic audio, image, video and text have to be marked in a machine-readable format and detectable as artificially generated. Deepfakes get disclosed. A chatbot has to say what it is.

That’s provenance and it’s worth having. It answers whether a machine made the pixels, which is a real question for a voice in an ad or a face in a video.

It doesn’t answer the question a client, a reviewer or a design lead is actually asking. That question is whether anyone competent looked at this, and what they were looking for.

The review is happening off the books

In AI in Design 2026, the survey Designer Fund and Foundation Capital ran with 900 designers across 60 countries, 80% say they rely on their own quality judgment over the model’s. Half have pushed AI-generated code to production. Forty percent claim full ownership of AI-assisted work and another 43% say it’s mostly theirs.

So the review exists. It happens in one person’s head, it takes real skill, and it leaves nothing behind that anybody else can inspect.

Patrick Neeman got close to this in Craft Still Matters, arguing that you describe your standards and keep humans reviewing. What I’d add is that the describing has to land somewhere a reader can find it.

What I write instead

Nothing I hand over carries the words “AI-assisted”. The line I write instead says what I checked and what came back wrong.

Three sentences, at the top, before the work: here’s what I checked this against, here’s where it failed, here’s what I changed. If I can’t write those three sentences, naming the tool doesn’t rescue the handoff, and naming the tool is the only thing most disclosure policies ask me for.

I ran a whole-library audit at Best Egg and wrote the crawler’s rules myself. The rules are the reason anyone could argue with the output. A flag was checkable because the rule behind it was on paper, which meant the interesting conversation was about the rule and not about the crawler.

In an interview I ask for one piece of work and the thing the model got wrong on it. Not whether they use the tools. What the first answer was, why they threw it out and what they held it up against. A candidate who can’t answer that has been shipping unreviewed work, and no disclosure label would have told me.

Who stays quiet, and why

Dykes is right that being caught out hurts more than telling people yourself, and that’s a good reason to disclose when policy is pointed at you. It’s also why disclosure gets heard as a confession. A confession is a bad container for a claim about quality.

The Envato rates break along exposure. Agency and studio owners disclose least at 28%, behind freelancers at 31% and in-house designers at 35%. Europe is highest at 39% and the Middle East and Africa lowest at 22%.

The people with the most staff and the most to lose say the least. That’s what a label looks like when it carries risk and no upside.

You don’t fix that with a better decision tree about when to say the word. You fix it by changing what gets said, from a fact about the tool to a record of the judgment. A record gets more useful as the tools spread. The tool name is heading for describing everything, and a label that describes everything sorts nothing.

Fifty-eight percent are already not saying it. Arguing them into compliance is a smaller win than it looks. What a client can act on is the check, and not one of the frameworks in this argument asks anyone to write the check down.

On September 20 the European Payments Council’s Verification of Payee rulebook moved to version 1.1. It was an urgent release, fixing problems that surfaced once the service went live.

In Britain the Payment Systems Regulator is consulting on removing the expiry date from the direction that requires Confirmation of Payee, so the rule doesn’t lapse on 1 November. In the US the Federal Reserve sells banks Payee Name Verification, which checks a name against a routing and account number before the money goes.

The shared position is reasonable: checking the name on the account is fraud prevention. It is, for one kind of fraud. The trouble starts with the word the screen uses to report it.

The check does what it says

Uptake isn’t in question. Over 320 payment service providers offer the check in the UK, more than 99% of firms initiating a Faster Payment now offer it, and over 2 million checks complete every day.

It works. Pay.UK found a 59% drop in claims for payments sent to the wrong account, and losses down between 20% and 40% for some types of fraud. The regulator adds that a transaction where the name doesn’t match is 25 times more likely to be fraudulent.

A mismatch is one of the strongest single signals in retail payments. The check surfaces it before the money moves, which is why I’m not arguing against it.

What a match cannot tell you

The PSR’s own account of the rule is careful about the distinction. Confirmation of Payee “was introduced to stop misdirected payments”. Then: “There was also an expectation that it would reduce the number of authorised push payment (APP) scams.”

The first happened. The second hasn’t shown up in the totals. UK Finance reported £576.4 million lost to authorized push payment fraud in 2025, up 19%, across 248,070 cases. Banks reimbursed £354.3 million of it, about 61%.

No causal claim there. The reason the check can’t reach those scams is in the mechanism, not the rollout.

The check compares the name the payer typed with the name on the account. When someone is being talked into a payment, the same person supplies both. The fake seller gives you the name on the real account they control. The invoice arrives with new details on a letterhead you know. Both sides of the comparison come from the fraudster, so the check agrees with them.

The Federal Reserve is careful about this in its own marketing copy. Its service “may help to reduce the occurrences of Authorized Push Payment fraud where an imposter is impersonating an individual”. May help. Impersonating an individual. That’s one scam, not the category.

The rulebook stops at the screen

The European rulebook runs to 68 pages and it’s precise where it needs to be. A responding provider returns one of five outcomes: match, no match, close match with the counterparty’s actual name, identification code not supported or verification not possible.

Then it says this about the person: “It should be noted that the way the Requester is informed and the content of the notification messages are left to the discretion of the Requesting PSP.”

So the machine-to-machine part is specified to the field. The part a human reads is a matter of taste. Sixty-eight pages on the message, one sentence on the screen.

The wording carries the liability

This isn’t a copy quibble, because the European regulation already attached money to that screen. On a mismatch the payer’s provider must say that authorizing the transfer “might lead to transferring the funds to a payment account not held by the payee indicated by the payer”.

The provider also may not stop the payer going ahead. And it has to explain “the implications for PSP liability and PSU refund rights resulting from a decision by PSUs to ignore a notification”.

Read that in order. The bank warns you, can’t stop you, and your refund rights change if you continue. The sentence deciding all of that’s being written by whoever owns the string file.

Two things I would hold the screen to

The first is a labeling rule. A check gets named for what it checked, so “this account is in the name you typed” is true and boring. “Payee verified” is a claim about the payment, and it’s the screen a fraudster wants glowing behind their phone call. A name check is a fact about an account, not a judgment about a person.

The second is the no-match state, which needs something to do. Today, in RedCompass Labs’ summary of European go-live, the payer “can either proceed, amend, or stop the payment altogether”. Three doors and no help choosing between them, at the exact moment somebody may be on the phone explaining which one to pick.

My question in review is always the same. What can this person do in the next 10 seconds, and does the screen still work if they’re being coached while they read it?

I got that from the expensive end. At Best Egg I redesigned document verification so an applicant sees a status the moment a file lands, and the opportunity we sized was 7,000 fewer support calls a month. A status that doesn’t say what happens next produces a phone call. On a payment screen it produces a payment.

At Auth0 the same lesson arrived in a different vocabulary. A check that returns true is an engineering result. Turning it into “verified” is a product decision, and it’s usually made by nobody in particular.

Europe will run this check on every euro credit transfer. Britain looks set to keep its version for good, and the Fed is selling one by the transaction. None of the three specifies what the payer reads. That leaves the most load-bearing word in the flow to whoever writes it, which today is a designer working without a rulebook.

Satisfaction with stakeholder buy-in for design systems fell to 32% this year, down from 42%. The share of practitioners calling themselves dissatisfied went from 23% to 40%. Both numbers come from zeroheight’s fifth annual report, which surveyed 147 people who run a design system.

In the same survey, 56% named a lack of resourcing or staffing as their biggest problem. So the people holding the budget are less convinced than they were, and the teams have fewer people than they need.

The answer the field reached for

The field’s answer is to get better at the business case. Figma’s new business case for design systems, published in January, argues that systems “have evolved from static libraries to key drivers of business revenue, customer loyalty, and product strategy”. It comes with receipts. Freshworks cut customer service costs 28%. Grammarly saved its design and development teams 25% of a work week.

That’s a fair position. I’d rather a design system lead walked into a budget review talking about revenue than about component counts.

The trouble is sitting in the other half of the zeroheight report. Only 5% of teams measure return on investment at all. Just 41% track adoption. The field is being told to argue from evidence most of it has never collected.

So the case gets built out of somebody else’s numbers. Freshworks did the work and published it, and the slide borrows it. Nobody in your finance review is funding your team on Grammarly’s week.

The hours nobody followed

Shane P Williams put the sharpest version of this on September 14. Teams are good at counting the hours a system gives back and bad at saying where those hours went. “Two thousand reclaimed hours is only a win if you can name what they bought,” he writes. If they went into shipping more of the same, faster, “then what the system funded is volume”.

He’s right, and I’d push it one step further back. Most teams can’t name what the hours bought because they never had the hours. The saving came out of a spreadsheet, not a measurement.

And when a team does go and measure, the first number they reach for is the one that hides the problem.

Adoption rate is a flattering number

Adoption answers one question: are people using our components. That’s the number a system team hopes to see, which is most of the reason it gets picked.

It’s also the number the tools hand you. The report found measurement scattered across Figma analytics, surveys, code repository tracking and spreadsheets, with 37% of teams using Figma analytics. Adoption is what comes out of the box, so adoption is what gets reported.

When I measured our library at Best Egg, adoption came back at 90.7% across 1.15 million instances in 296 files. Read on its own, that number says the work is finished.

The same audit found 844,333 values hand-set in files where a published token was sitting right there, unwired. It found 770 components with zero instances. Half the standalone library turned out to be illustrations that every designer scrolls past on the way to a button.

Adoption was 90.7% and the library still cost the team something every day. One of those numbers is an argument for leaving us alone. The other is an argument for funding us.

Count the drift

Drift is what the system failed to prevent. It’s countable, and it’s the only design system number I have watched change a staffing conversation.

• Hand-set values that already have a token. Every one is a decision the system was supposed to have made for somebody.
• Components with no instances. Maintenance you pay for that sits unused.
• Ties the data can’t break. The value 10px appeared 1,834 times in our files and 12px 1,796. Nothing in the counts picks one. A person has to, and that person costs money.

A number like 844,333 does something an adoption rate can’t. It hands the person holding the budget a quantity they can multiply by a cost, and it names the work that would bring it down.

Make the number harder to like

My test for a measurement is whether it can embarrass me.

Ours nearly wasn’t. The adoption formula had a name-match heuristic in it, counting a layer as on-system when its name looked close enough to a real component. I took it out. I excluded the archives and the library’s own file, and reported Brand Studio separately, because marketing collateral doesn’t instance a dropdown.

Every one of those choices pushed my own number down. That’s the point. An adoption rate that only ever goes up is a marketing asset, and the people reading it can tell.

The other half of the test is the calendar. The audit runs again on the first of every month, so drift has a trend and not a snapshot. One reading is a claim. Twelve of them is a line on a chart, and a line is what survives a budget review full of people who don’t design.

Where the 56% comes from

Put the two findings next to each other. Resourcing is the top challenge, named by 56% of teams. Return on investment is measured by 5%.

Those are the same fact. Design system teams are asking for headcount in a currency they never minted. The business case advice isn’t wrong. It’s out of order. Instrument the thing, find out what it’s failing to prevent, and the case is yours instead of borrowed.

Seven percent of the teams in that survey report full adoption. Another 22% say the system reaches few teams. Somewhere in the gap between those two lines is a number with a dollar sign on it, and only about one team in 20 has gone and counted it.

Jakob Nielsen made the case in Vibe Coding and Vibe Design, quoting a line from Kshitij Agrawal that the field has more or less adopted.

mockups existed because coding was difficult; now that coding is easy, the future is prototypes

Kshitij Agrawal, quoted by Jakob Nielsen, March 2025

Go straight to something that runs. Test the real interaction instead of a picture of it. I agree with all of that. The conclusion skips a step, and the step it skips is the one that made prototypes work.

A high fidelity prototype used to cost about a week of somebody’s time. That price did a job nobody assigned to it. It forced a conversation before the build, because no team spends a week without asking what the week is for. The question came first because the budget made it come first.

The deliverable ate the question

Forty-three percent of designers say their company now expects a working prototype as the deliverable, according to AI in Design 2026, a survey of more than 900 designers in 60 countries. Half have pushed AI-generated code to production. In the State of Prototyping survey run by Tommy Geoco and UX Tools, 1,478 responses collected this spring, 43.8% now spend more than half their building time on code a model wrote.

A deliverable and a prototype have different jobs. A deliverable gets accepted. A prototype gets built to be wrong in a particular way that somebody named in advance, and the whole point is that it might come back wrong.

When the artifact arrives before the question, the question gets written afterward, if anyone writes it at all. A question written after the build is a rationalization with a sample size attached.

What gets approved is average

Ninety-two people were shown AI-generated and human-made prototypes without being told which was which, and rated them on the short user experience questionnaire. The results split cleanly. Positive on the pragmatic side: usable, efficient, clear. Neutral to negative on originality and innovation. The authors called it usable but conventional.

Nielsen Norman Group ran their own version, rebuilding one of their training pages with three kinds of prompt. The detailed prompts got close to the human original. The outputs still missed visual hierarchy, color contrast and consistent margins, which is why they land on these tools being better for ideation than for production.

So the thing showing up in your review is competent, conventional and finished-looking. All three at once is very hard to argue with. That’s the problem, not the achievement. In Figma’s State of the Designer 2026, 58% of designers define craft as visual polish, ahead of thoughtful problem solving at 47%. Polish is the part that just became free.

One line at the top

Nothing goes into a design review without one line at the top of it: the belief this is built to kill, and what we would be looking at if that belief were wrong.

I want that line before the build, not in the deck afterward. If nobody on the team can write it, we’re building a demo, and I’d rather we call it a demo and put it on the calendar as one. Demos are useful. They’re just not evidence.

The first question in the review is the same question. What would this look like if we were wrong? If the honest answer is “about the same”, the prototype tested nothing and the next 40 minutes are a conversation about taste. Sometimes that’s the meeting you needed. It shouldn’t be the meeting you thought you were having.

At Best Egg, applicants uploaded their documents and then the dashboard went quiet. What we were testing was whether telling them the status after the upload changed how many finished, not whether the screen looked better. That version of the question has a result. It went through an A/B test before rollout and came back with one.

The forcing function has to come from a person now

Eighty percent of designers say they still rely on their own quality meter over the model’s. I believe them, and I don’t think a quality meter is the thing under threat here. Judgment about whether a screen is good survives cheap production fine.

What doesn’t survive is the part of the process that used to happen on its own because building was expensive. Somebody named the uncertainty. The team agreed ahead of time on what a bad result would look like. And before anyone opened a tool, everyone knew which of the plausible directions the build was there to rule out.

None of that was ever a method. It was a side effect of the price, and the price is gone. Which means it’s now somebody’s job, in writing, or it doesn’t happen.

The teams that get this wrong aren’t going to look slow. They’re going to look extremely fast, and they’re going to ship a lot of usable, conventional, well-spaced work that nobody in the building ever had the standing to question.

The junior designer argument came around again this week, from both sides. On Tuesday Patrick Neeman made the case that the field survives on leaders who keep hiring juniors, because every senior designer was once a bet somebody made. On Wednesday CNBC quoted Tobias Green, founder of the London ad agency Catalyst, making the opposite case: “If AI removes the grunt work, then the grunt work is no longer relevant.”

I’m with Neeman on the hire. I think both of them have the training wrong.

Hiring them is the easy half

The hiring numbers aren’t subtle. In Figma’s 2026 hiring study, 56% of hiring managers reported rising demand for senior designers. Only 25% were hiring for junior roles. A working paper from two Harvard researchers tracked 62 million workers at 285,000 American firms through their résumés. Junior employment fell sharply at companies that adopted generative AI, while senior employment barely moved. The drop came from slower hiring, not from people being let go.

Nobody announced the end of junior hiring. The requisitions just stopped getting opened. Neeman’s answer is to open the requisition anyway, and he is right. Every senior designer was a junior somewhere first.

The weak part of his argument is the reason he gives for why now is a good time. He cites the Brynjolfsson, Li and Raymond study of support agents, where novices with an AI assistant improved 34% and the most experienced barely changed. His conclusion is that the tools compress the time it takes a new person to become useful.

Useful is not the same as trained

Look at what that study measured: issues resolved per hour. It’s an output number. The authors’ own explanation is that the model “disseminates the best practices of more able workers” to the new ones. The novices got faster because they were carrying someone else’s practice, not because they had formed their own.

That’s fine in a support queue. In a design team it switches off the oldest signal a lead has. A junior who needed help used to show it in the work: the muddled hierarchy, the empty state nobody drew, the flow that fell apart on the third screen. Weak output was the alarm.

Now a junior with a good model hands in a competent screen in their first week. It looks like progress. It might be. Or the model did the part that used to teach them, and they approved it.

Cheney Hamilton of the research firm Bloor named the gap in the same CNBC piece. AI raises what a junior can produce, she said, but it “doesn’t give them the judgement to know when the output is wrong”. That judgment came from repetition and consequence, and those are exactly the parts the tool now absorbs.

The player-coach has no time for screens

The standard answer is that seniors will teach the judgment on purpose. The org chart is moving the other way. In May Coinbase cut about 14% of its staff and capped the company at five layers below the chief executive and chief operating officer. Leaders would carry as many as 15 or more direct reports. There are no pure managers left. Every leader is also meant to be an active individual contributor.

A player-coach with 15 reports and their own work to ship can’t sit beside a junior and critique every frame. A small interview study of software engineers in South Korea gave the pattern a name: absorption. Entry-level work gets pulled into senior workflows running on AI, and juniors skip the struggle that used to build expertise. The seniors and juniors it interviewed didn’t even see the problem the same way.

So the training has to happen somewhere cheaper than a screen-by-screen review. And it has to leave a trace a busy lead can read.

What I review instead

In my reviews, a junior’s work comes with what they threw away. The options the model gave them that they killed, and one line on why each one died, written against the team’s standard.

I read the reasons before I look at the screen. The order matters, because it separates two juniors who hand in the same competent work.

• Right reasons, rough screen. That’s a craft gap. It closes with practice, and the tools help.
• Polished screen, thin reasons. The model got it right and the junior agreed. That’s where my time goes, because nothing in the output would have told me.

None of this works unless the standard is written down. A junior can’t explain why an option fails an unstated bar, and a lead can’t check the explanation against a mood. Adam Elman made a related case about AI products at Nielsen Norman Group in June: the designer’s job shifts toward defining what good does and doesn’t look like.

The rejection notes also test the standard. Where it has gaps, they show up as reasons the team can’t give.

And it gives the review a unit a player-coach can afford. A paragraph of reasons can be read between meetings. A file full of frames can’t.

The grunt work was never the point

Green is right that nobody should keep juniors on busywork for its own sake. He is wrong that the skill it built stopped mattering. Grunt work taught judgment because every piece of it came back with a verdict. Somebody said no, and said why.

A model rarely tells a junior no. It hands them another option. The only person left to say no is the junior, and the only way to know whether they can is to have them do it in writing, where someone will read it.

So hire the junior, and review what they reject.

The design system is now the thing the model reads. In a July survey of 21 open-source design systems, Kaelig Deloumeau-Prigent found that 18 ship an official MCP server so coding agents can query them directly. Figma describes its new agent as having “deep context on your components, tokens, standards, and best practices”.

The position behind all of this is reasonable. Give the agent your system and it builds on your system. The components and tokens become the guardrail, and on-brand output follows.

I think that gets the guardrail half right and drops the half that matters.

What the machine-readable half enforces

The same survey catalogs 165 techniques teams use to keep models on their real components and tokens. The biggest groups are validation loops (31), prohibitions like “never invent components” (28), tool-gating that makes a fake component impossible to produce (22) and token enforcement that fails the build on a raw hex value (15).

That’s serious engineering, and it works. It also has a clear shape. Most of them answer one question: is this a real part of the system, used the way its API allows?

That’s spelling. An agent can pass all of it and still put a primary button in every row of a table, because every one of those buttons is a real button with a real token.

The part that got cut first

Atlassian tested Google’s DESIGN.md format against its own MCP server and skills and wrote up what happened. To fit the design system into one portable file, the team says it “had to remove much of the usage guidance from our 50+ components”. Agents given the file then went digging through component code to find the guidance that was missing.

Usage guidance is where the judgment lives. It’s the paragraph that says when not to use the thing. Nord, one of the systems in the survey, ships it to agents in exactly that form: “Don’t use a primary button in every row of a table.” No linter catches that sentence being ignored. It’s also what went first when Atlassian needed the file smaller.

Tokens are cheap to write down. They’re values with names. The reasons behind the choices are expensive, and the reasons are the part a designer was actually hired to supply.

Frequency is not a standard

When an agent has no reason to go on, it falls back on what’s common. Figma says its agent “uses your most frequently and recently used components as a starting point”. That’s a sensible default for a tool and a poor definition of good.

I have seen why. When I ran an agent audit across a whole design library, I wrote the crawler’s rules, and it counted every value we had. It couldn’t tell me which of two established values was right. Somebody had to decide, and the decision was nowhere in the data.

Nurkhon Akhmedov puts the failure mode well in a July post on this: five screens in a hundred ship off-system, and “the next agent reads those five as if they were the library.” A system that learns from its own output drifts toward whatever it did most, right or wrong.

Gated on spelling, trusted on judgment

The survey also looked for whether teams measure any of this. Eight of the 21 records mention evaluation work at all. The report calls its validation loops the closest thing the field has, and describes them as “checks that fail a build, rather than evals that score a model.”

So the mechanical half is gated and the judgment half is trusted. Akhmedov’s version is blunter: whether the agent picked the right component for what the user is trying to do is a question “you can’t grep for.”

Where the missing half comes from

Akhmedov argues the rubric is now the deliverable. I agree, and I’d go one step further on where it comes from.

Nobody writes good usage guidance in the abstract. Try to list every wrong way to use a button in advance and you get a style guide nobody reads. The useful rules show up one at a time, when someone looks at a screen an agent built and says no.

That moment is the raw material, and it’s easy to lose. The rejection happens in a review, the agent gets a new prompt, the screen gets fixed and the reason lives in one person’s head until they leave.

A rejection without a written reason is wasted. The reason goes into the system the agent reads, in the form Nord already uses: the choice that was wrong, the one that was right and why. Written that way, the next agent can be held to it and so can the next designer.

What the design system team is for now

For years the visible output of a design system team was the library. This year the industry made that library readable and enforceable for agents. That work was worth doing.

It was also the easy half. A system that only knows its own vocabulary will produce fluent, valid, wrong screens at whatever speed you let it. The half that decides whether a screen is right is still mostly sitting in people’s heads, and in at least one case it was trimmed out on purpose to make a file fit.

On September 15 the Senate failed to advance the Clarity Act, 49 to 50. American Banker called the extent to which stablecoin companies could offer yield-like products the leading issue of the debate. The day before, eight banking groups were still pushing for tighter limits on rewards, arguing they work like deposit interest.

Within three days, two Substack writers read the same failure in opposite directions. Anndy Lian headlined that stablecoin yields survive. Andrew Dresner argued the failure counts as a win for banks, because the tighter GENIUS Act restrictions now govern.

Both sides share one assumption, and it’s a fair one: what a person earns for holding a stablecoin decides whether they move money into it. I agree with it. It’s still the wrong screen to fight over.

The bad day is already written down

The GENIUS Act already bans issuers from paying holders any form of interest or yield in section 4(a)(11). Section 4 also requires a public redemption policy with procedures for “timely redemption”. The statute never says how timely. The regulators do.

The Office of the Comptroller of the Currency (OCC) proposed its rule in March. Its section 15.12 puts timely at two business days. Then it defines the bad day. If redemption requests pass 10% of an issuer’s outstanding issuance in a single 24-hour period, the window becomes seven calendar days. That applies to every request already in line and every one after it. Only the OCC can shorten it, and the OCC can also extend it further.

The rule is defensible. Regulators need some way to slow a run, and compliance isn’t the problem here.

The problem is what the person sees. Section 15.12 has the issuer notify the OCC within 24 hours. What it asks the issuer to tell holders is a statement in the redemption policy explaining when the period can stretch. So the one moment a stablecoin behaves least like a dollar is covered by a paragraph on a policy page.

Mechanism, labeled as transparency

The disclosures the law does require are real and useful. Once the law takes effect, an issuer publishes its outstanding supply every month, along with the composition of its reserves, down to the average tenor and where each category of reserve is held. The OCC’s draft puts a link to that report in the same disclosure as the fees.

That report is for analysts. A person holding stablecoins in an app has one question on the bad day: when does my money land, and what would make it later? A reserve breakdown answers a different question, and putting it on the screen is how the industry keeps exposing its machinery and calling it transparency.

It gets harder, because a person holding a stablecoin in an exchange app may never deal with the issuer at all. As Liam Wright wrote in CryptoSlate on the day of the vote, a faster exit depends on the service converting the coin, which has to pay out before the issuer pays it. So the wait a person feels is set by whoever sits between them and the issuer. That’s the same kind of platform whose rewards the Senate just fought over.

The states a balance can be in

Read the statute as a product spec and a stablecoin balance can be in four states a rewards banner never mentions. Each one needs a screen.

• Pending. Redemption requested, due within two business days under the draft rule.
• Extended. The 10% line was crossed by other people, and the person’s own request now waits seven days.
• Frozen. Issuers must be able to seize, freeze, burn or block transfer of coins under a lawful order, section 4(a)(6)(B).
• In insolvency. Holders get priority on the required reserves, and section 11 asks the bankruptcy court to use best efforts to begin distributions within 14 days of the hearing.

The extended state is the one that should worry product teams. Nothing the person did caused it, and nothing on a normal balance screen would explain it.

Lending already paid for this lesson

At Best Egg, loan applicants uploaded their documents and then the dashboard went quiet. Nothing said whether a file was pending, accepted or still needed, so they called to ask. We replaced it with a status for every document, sized at 7,000 fewer support calls a month.

Stablecoin redemption is that screen with the person’s own money behind it. A silent “processing” on day four of a seven-day extension doesn’t read as a rule working as designed. It reads as a freeze. Jayson Derrick wrote about the trigger in May and pictured retail holders opening their apps on a Sunday night to find “a locked gate.” That’s the screen to draw first.

The screen I ask for first

Put a stablecoin product in front of me and the first screen I’d ask for is the balance on day four of an extended redemption. What does it say happened, what does it say happens next and on what date?

If the team shows me the rewards rate instead, the product has been designed for the day money arrives and not for the day it tries to leave.

Comptroller Jonathan Gould said in August that the OCC wants a final rule out by November. Under section 20 the law takes effect no later than January 18, 2027. The rewards fight, American Banker reports, starts over in the next Congress. The redemption screen gets built before then either way.

JPMorgan Chase now charges data aggregators like Plaid for the requests its systems answer. The fee applies to each call rather than a monthly total, a JPMorgan managing director told a panel in December. The Consumer Financial Protection Bureau’s rewrite of the Section 1033 open banking rule went to the White House for review in August, and it is expected to let banks charge for access the 2024 version made free.

The fight is being argued as a question of who pays. The Financial Technology Association says the costs “will be passed directly on to American consumers and small businesses,” and that data access is a legal entitlement, “not a conditional right contingent upon paying access fees.” That’s a serious argument about competition. This post doesn’t argue the price.

It argues about the screen, because a price changes what the screen is for.

Both sides agree the product sets the volume

Listen to what each side says about volume and they land in the same place. On that December panel, JPMorgan’s Kate Prochaska said: “Once people actually have to pay for things, they start thinking about, ‘Well, do I need to ping this often?‘” The association’s Angelena Bradfield answered that how much data an app pulls is a function of the user’s experience. People check their apps, and the app checks the bank.

PNC put the bank case more bluntly in its comment letter to the bureau, as quoted by Payments Dive: “When third party access to consumer data is free and unlimited, third parties have little incentive to minimize cadence, scope, or retention of data they do not need and will not use.”

One side calls the volume waste. The other calls it the product working. Both are saying that how often an app looks at a bank account is a product decision. Neither has said where the person whose account it’s gets to see that decision.

Frequency was never on the screen

The 2024 rule came closer than anything before it. It told apps to limit collection to what is “reasonably necessary” for the product the person asked for, and it defined collection to include “the scope of covered data requested and the duration and frequency of collection.” It capped every authorization at one year before the app had to ask again.

Now look at what the same rule required the person to be shown. The authorization disclosure lists the app, the bank, the product, the categories of data and the expected duration. Frequency isn’t on the list. The one variable a bank can now put a price on is the one the strictest version of the rule never asked anyone to show.

That rule isn’t in force either. A federal court in Kentucky has blocked enforcement while the bureau reconsiders it, and the reconsideration notice asks whether banks should be able to “recover a reasonable rate” for answering requests.

The invoice decides if the screen doesn’t

Today the answer to “how often” lives on a signup screen nobody reads twice. CNBC reported an internal JPMorgan memo complaining that aggregators access data “multiple times daily, even when the customer is not actively using the app.” Plaid’s answer was that all of that activity begins with the permission a customer grants at signup, and that background calls are how people get “critical alerts for overdraft fees or suspicious activity.”

Plaid is right that those alerts matter. That’s the problem. The pull that catches an overdraft is the same kind of pull a bank now bills for, and the person who wanted the alert agreed to it with one tap that never mentioned it.

So far the meter has stayed out of sight. When Plaid and JPMorgan renewed their agreement, Plaid told clients that current contracts and customer fees remain unchanged. The cost sits in a contract between two companies, and JPMorgan says the trimming has started there: once it announced fees, Prochaska said, “people are more judicious and thoughtful about it.”

If a balance that used to refresh in the background starts refreshing only when the app opens, the overdraft warning arrives after the overdraft. Nobody chose that on a screen. It got chosen in a contract. That’s the failure state worth worrying about, and it isn’t a breach. It’s a downgrade the person never agreed to and has no way to see.

Identity already has a word for this

OpenID Connect, the identity layer under most modern login flows, treats access while you’re away as its own grant. The spec defines an offline_access scope and says the provider “MUST always obtain consent” before issuing the token that allows it. It adds that “a previously saved user consent is not always sufficient,” because access when the user isn’t present poses greater privacy risk.

At Auth0 I worked inside that model, where consent is granted scope by scope and each scope has a name. Open banking consent still bundles “while I’m using the app” and “while I’m asleep” into a single tap. Identity split those two apart years ago, and a price per pull is a good reason for open banking to do the same.

What the screen should say

The lazy version of this screen is a number. “This app may request your data up to 12 times a day” is accurate, and it’s a mechanism dressed as a disclosure. You can’t make a decision with it.

The version a person can decide on names what the looking buys them and what stops if they say no. Check my balance in the background so you can warn me before an overdraft. Or only update when I open the app. Two choices, each with its consequence, and the app lives with whichever one the person picks.

That forces the product team to do what the price is already forcing on the business side: say which pulls are the product and which are habit. A pull that can’t be explained on that screen in one plain sentence is a pull the app should stop making.

The question I’d put to any background access in a design review is simple. What does the person get from us looking while they’re not here? If the team can’t answer in a sentence the person would recognize, the access goes, not the sentence.

Whatever the bureau publishes, the meter is already running at the largest bank in the country. Where the decision about how often gets made is still open. It can be made on the consent screen, where the person sees it, or in a contract they’ll never read.

Here are two numbers from a survey of more than 900 designers. Peer learning went from 24% to 70% in a year. The share of designers taking recommendations from their leadership went from 32% to 16%.

The first number gets quoted constantly, usually as a feel-good line about community. The second one barely gets quoted at all, and it’s the one that should be keeping design leaders up.

The comfortable reading is wrong

The comfortable reading is that this is a culture problem. Teams got scattered, people stopped looking up, leaders need to communicate better and be more present.

I don’t think that’s what happened. I think the method started turning over faster than any management chain can carry it.

The average designer’s toolstack went from three tools to seven in 12 months. When the useful knowledge has a shelf life measured in weeks, the person three levels up is structurally the last to hear it. Not because they’re disengaged. Because that’s what a hierarchy does to information that expires: it delays it.

Your team didn’t lose respect for you. They found a faster path, and they were right to take it.

The expensive mistake

The expensive mistake is trying to win method authority back.

It looks reasonable from the inside. You block time, you learn the tools, you show up to the design review with a working prototype you built yourself. And it does buy you something real, which is that you stop being illegible to your own team.

But you can’t win that race. There are eight of them and one of you, they’re in the tools all day, and whatever you learn this quarter is half wrong by the next. Meanwhile the thing only you can do is sitting there not getting done.

I watch leaders spend their scarce hours becoming the fourth-best prototyper on a team of six. It’s the most sympathetic failure mode I know and it’s still a failure mode.

Make the trade explicit

The trade I have settled on is that the team owns the method and I own the standard and the decision.

Owning the standard means I’m accountable for writing down what good means here, precisely enough that someone who wasn’t in the room can hold work to it. Not a mood, not a principle poster. The actual bar, in words, that a person or a model can be measured against.

Owning the decision means the calls that need a name on them stay with me. Which of two entrenched options we standardize on. What we deprecate when the data is tied. Anything where somebody’s work is on the other end of the answer.

When I audited our design library this year, the analysis came back saying one spacing value appeared 1,834 times and the competing one 1,796. Nothing in the data was ever going to break that tie. Somebody had to pick, say so out loud, and then go make the other one wrong. That isn’t a job you can delegate downward or automate, and it’s the job.

What I don’t do any more is pretend I know the best way to get from a brief to a prototype this month. They know. I ask.

What this looks like on a calendar

Three things I actually changed, in case the principle is too tidy to be useful.

• I ask what changed in your method, every one-on-one. Not as a check-in, as intake. It’s how I find out what the team knows before the quarter is over. Half of what I now believe about working with agents came off that question.
• Whoever found the better way presents it, not me. The moment a leader relays somebody else’s discovery, two things break: the credit and the accuracy.
• I write the standard down before anyone touches a tool. If the team can’t say in a paragraph what a correct component looks like, no amount of tooling discovers it. It averages whatever is already there and hands it back with confidence.

The part few leaders have done

The same survey found that only 28% of leaders made any formal change to evaluation, pay or hiring. Just 8% changed performance metrics and 4% touched compensation.

So the work changed, who people learn from changed, and what we reward stayed exactly where it was. That gap is where good designers quietly decide their leadership isn’t paying attention, and it’s a gap leaders can close without permission from anyone.

Start with the review template. If it still rewards volume of screens, it’s measuring the part of the job that got cheap.

The same report has 80% of designers still trusting their own quality judgment over the model’s. Taste didn’t go anywhere. What went is the assumption that it flows downhill from the person with the biggest title.

Fifty percent of design leaders now emphasize AI fluency when they hire, according to AI in Design 2026, a survey of more than 900 designers. Systems thinking and strategic skills come right behind it. I understand the instinct completely and I think the practice is close to useless.

Over the same year, the average designer’s toolstack went from three tools to seven. Ninety-one percent of designers now use AI weekly. A habit that 91% of the field already has, in tools that keep turning over, isn’t a filter. It’s a coin flip wearing a rubric.

What the screen actually selects for

When you screen for AI fluency, the candidate who wins is the one who most recently had time to play.

That correlates with some things you do want, like curiosity. It correlates with some things you should be careful about, like having been between jobs, or having worked somewhere with slack in the schedule, or simply being young enough that nobody at home needed them on a Saturday.

It doesn’t correlate with judgment, and judgment is the entire reason you’re hiring a designer rather than buying a seat.

There’s a version of the screen that works, and it isn’t “which tools do you use”. It is “show me something the model gave you that you threw away, and tell me why”. That question can’t be studied for. It has no right answer available on a podcast. And it goes directly at the thing you actually need to know.

The job got wider, not deeper

Sixty-five percent of designers report taking on more product or engineering responsibility. Forty percent say product managers and engineers now contribute more to design work. Seventy-three percent feel rising expectations for output, quality and speed, all at once.

Read those together and the shape is clear. The boundaries around the discipline dissolved in both directions. Designers are writing production code and specifying systems. Everybody else is making design decisions, because the tools let them and nobody stopped them.

The common read is that this is design losing ground. I think that’s exactly backwards, and it misses what actually got scarce.

When anyone can generate a competent screen, the constraint moves from production to specification. Somebody has to say which of the 40 plausible things is the right one, and say it precisely enough that it holds when they leave the room. That job didn’t exist as a distinct skill when producing the option was itself the hard part. It was bundled inside the craft, invisible, and a lot of people were doing it without a name for it.

It has a name now, because the bundle came apart.

What I screen for instead

Three things, in this order.

Can they write a standard down. I ask for something they have written that another person had to work from: a component spec, a critique doc, a definition of done. Then I read it for whether a stranger could apply it without asking a follow-up question. Most portfolios contain no such artifact, which is itself information.

Can they say why they rejected something. Not what they chose. What they killed, and on what grounds. Katie Dill at Stripe frames the check as asking whether you would be happy with this if it had taken you a week to make. A designer who can’t articulate the rejection is a designer who will approve the model’s first answer.

Can they be specific about what was theirs. Forty percent of designers say they feel full ownership of AI-assisted work and 9% say it’s genuinely difficult to separate their contribution from the model’s. That isn’t a moral failing, it’s a new and confusing condition. But a candidate who can walk me through which decisions were theirs is telling me they were paying attention to their own judgment while they worked. That’s the whole signal.

The thing I would not do

I wouldn’t test tool proficiency in an interview loop. Not because it’s unmeasurable, but because it’s the cheapest thing on the list to teach after someone starts.

Hire someone with judgment and no Cursor experience and they’re productive in two weeks. Hire someone fluent in every tool on the market who can’t tell you why one option is better than another, and you have bought a very fast way to produce work nobody can defend in a review.

Eighty percent of designers still trust their own quality judgment over the model’s, and their most common complaint about AI is unreliable output quality. Only 5% of leaders say they’re placing less emphasis on execution craft. That’s where designers think their value sits, and hiring should catch up to it.

In June, Mastercard launched Agent Pay for Machines with more than 30 partners, credentialing agents through what it calls Verifiable Intent, across both cards and stablecoins. Visa’s Trusted Agent Protocol lets merchants recognize the AI agents shopping on a person’s behalf. The IMF published a note on how this reshapes payments.

The infrastructure question is being answered quickly and competently. The design question has barely been asked.

Liability follows authorization

The IMF note says liability in a dispute depends on whether the agent acted within its authority, and admits the legal lines are still unclear. If the agent stayed inside the scope its principal authorized, the loss flows one way. If it went outside, it flows the other.

Which means the moment a person grants that scope is the moment that decides who eats a bad outcome months later. In a card dispute, the question won’t be whether the agent behaved reasonably. It will be what the person agreed to, and whether they can be said to have understood it. Fenwick notes it’s still unresolved whether giving an agent your payment credentials even counts as authorization under Regulation E.

That’s a screen. Somebody is designing it right now, probably in a sprint, probably under an engineer’s ticket, and it will determine the financial exposure of everyone who uses the product.

I have watched this exact thing get treated as paperwork before. It never is.

The mistake the industry just finished making

Crypto spent a decade answering “people cannot use this” with better documentation, and the answer turned out to be that the product was exposing its own machinery and calling it transparency. Seed phrases, gas, chain IDs. Account abstraction finally fixed it, and it fixed it by deciding what a person never needs to see rather than by explaining it better.

Agentic payments are set up to repeat that, and the early patterns already look familiar. Scoped spend limits, cryptographic identity checks, circuit breakers. Every one of those is the right control. Every one of them is also a mechanism, and mechanisms have a way of arriving on the first screen because that’s where they’re easiest to put.

“Grant this agent a $500 monthly limit with merchant category restrictions” is a control panel. It isn’t a decision a person can actually make, because it asks them to predict which categories a shopping agent will need before they have watched one work.

The honest version of that screen is closer to what it would say out loud: what’s this thing allowed to do without asking me, what will it always ask about, and how do I find out fast when it does something I didn’t expect.

Three states nobody is designing

Delegation isn’t one moment, it’s three, and the industry is building the first and ignoring the rest.

• The grant. Where scope is set. Currently drifting toward a permissions matrix, which is how you get consent that’s legally valid and practically uninformed.
• The notice. What reaches a person while the agent is acting. If every action pings them, they turn notifications off and the audit trail is theater. If nothing does, the first they hear of it’s the statement.
• The dispute. The one that matters. Something went wrong, and the person has to reconstruct what their agent did and on whose authority. Almost nothing I have seen treats this as a product surface at all. Fenwick warns that consumers could be left without standard dispute rights when contesting agentic purchases.

That last one is where trust actually gets decided, and it’s always designed last, by whoever has time, after the demo has already been approved.

Why I keep coming back to this

I have spent 13 years in three fields that are now converging on exactly this problem. In consumer lending the lesson was paid for expensively: when a screen goes quiet after somebody has money on the line, they don’t wait patiently, they call. At Chainlink Labs and Auth0 the lesson was that a credential isn’t a special category of thing that deserves its own frightening vocabulary. It’s a credential, and it should behave like every other one.

Agentic payments need both lessons at once, and the people building the rails are mostly coming from neither tradition.

The question to ask

For any agent that acts on someone’s behalf: when this goes wrong, can the person tell what happened, prove what they authorized, and stop it happening again?

If the answer is no, adding a clearer consent dialog at the start doesn’t fix it. The dialog is what gets written when the decision has been made not to design the rest.

The rails are getting built either way. Whether the consent is real is still open, and that part is ours.