Build your
Frontend factory.

Delivery infrastructure we install on your codebase so an idea becomes a merged production PR without a senior Frontend engineer hand-carrying every one. In practice: architecture and context committed to the repo (AGENTS.md, patterns, design tokens), skills we write and maintain per repo, guards that decide whether output is mergeable (design system, accessibility, security, test quality, performance budget, Storybook, senior review), telemetry and evals on every run, and a learning loop where each failure becomes a new guard or a sharper skill. Our forward-deployed engineers install it, operate it with your team inside it, and hand it over. Ownership is the deliverable, not a permanent retainer.

Because the queue is not made of missing hands, it is made of missing permission. Every "small" UI ask from product, marketing and CS still has to pass through the few people allowed to merge Frontend, so a new hire joins the same single lane and the lane gets slightly wider a quarter later. Hiring also prices in ramp time, and the ask usually arrives when budget for headcount does not. The factory changes the shape instead of the size: it turns the review standards, design-system rules and production safety your seniors carry in their heads into guards that run on every agent run, so people who could never merge Frontend start merging it. You get more output from the org you already have, and your seniors go back to the work only they can do.

That is the failure mode we see most, and it is why design-system enforcement is a guard rather than a review comment. An agent given a screenshot and a prompt will happily invent a one-off button, a new spacing value and a fourth shade of your brand color, and none of it looks wrong enough to block in review, so it lands. Then it compounds. We commit your tokens, components and usage rules to the repo as context the agent reads before it writes, and we put the check in CI: raw hex, off-scale spacing and hand-rolled duplicates of existing components fail the run and never reach a human. The agent gets corrected by the machine, not by your design lead in a PR thread at 6pm.

A gate, and it is worth naming which hole, because the published measurements point where most teams do not look. Veracode’s 2025 GenAI Code Security Report tested over 100 models across 80 curated tasks and found 45% of the AI-generated code it evaluated introduced a security flaw. The worst single category in the whole set was cross-site scripting, where only around 12% of AI-written solutions came back secure. XSS is a Frontend defect class, so the sharpest edge of this sits in exactly the layer the factory opens up. What makes it dangerous is how ordinary it looks: user input reaching the DOM without escaping, dangerouslySetInnerHTML reached for because it silenced a type error, a CSP loosened to unblock a build, an API key that ends up in the client bundle. Nobody catches that skimming a 400-line agent PR, and asking reviewers to be more careful is a wish, not a control. So it is a guard like the others: taint paths into DOM sinks, raw innerHTML behind an explicit allowlist, CSP and security headers asserted by tests rather than described in a wiki, secret scanning on the built bundle, dependency checks on whatever the agent added to package.json. We build and operate the gate. We are not a security auditor, we do not run penetration tests, and we do not certify anyone.

It is the guard everyone believes they have, and it is the one that stopped working first. An agent asked for tests will write tests, and what it optimizes for is the thing you can measure at a glance, which is coverage. So you get a suite that renders the component, asserts that it did not throw, snapshots whatever came out, and reports 90%. Flip a comparison operator and it still passes. Capgemini put roughly 70% of enterprises on AI for test authoring and maintenance in its World Quality Report 2025-26, so this is now most codebases, and the numbers on the other end match: Cortex’s Engineering in the Age of AI 2026 benchmark found PRs per author up 20% year over year with incidents per pull request up 23.5% and change failure rate up roughly 30%. More tests, more green, more production incidents. The Frontend version has its own tell. A selector-brittle Playwright test breaks on a refactor and gets fixed by loosening the selector until it passes, and a snapshot that fails gets regenerated by the same agent that just changed the behavior, which is the test agreeing with the bug in writing. So we gate on whether a test can fail, not on how many there are: mutation checks on the paths that matter, assertion quality on changed lines, flaky tests quarantined instead of retried until green, and a snapshot never accepted in the same run that changed the component. What the guard measures is caught regressions, not tests shipped.

Because performance is the other guard people assume they have, and a Lighthouse score on the marketing page never sees the regression. An agent solves the ticket in front of it and has no memory of your bundle, so it installs a charting library for one sparkline, adds a second date library because it likes that API better, marks a component client-side when a server component would have done, and refetches in an effect that fires on every render. Every one of those is a correct-looking diff. CodeRabbit’s State of AI vs Human Code Generation report, which classified issues across 470 open-source pull requests, 320 AI-coauthored against 150 human-only, found AI-authored changes carried roughly 1.7x more issues overall, and performance inefficiencies showed up close to 8x more often. That is the sharpest gap in the whole report and it lands on the Frontend, because on the Frontend the cost is paid by the user’s device. So the budget goes in CI as a guard: bundle size per route with a ceiling the build fails on, duplicate dependencies flagged the moment a second one arrives, and Interaction to Next Paint, LCP and CLS asserted against real interactions rather than a synthetic homepage score. INP is the one agent-written React regresses first and the good threshold is 200ms. A number in a dashboard is a report. A number that fails the build is a guard.

People who could not merge Frontend before. Backend engineers, PMs, designers, marketing and CS open real PRs on the real codebase, and the Frontend team stops being the queue for every small UI ask. Teams usually come to us through one of three doors. Capacity: people outside R&D ship. Velocity: the demo that impressed everyone reaches production instead of aging in a branch. Force multiplication: your one great senior runs many parallel tasks instead of one. Same machine behind all three, so pick the door that matches the pain you have this quarter. That is what we mean by frontend enablement for non-frontend engineers: the guards do the job a senior reviewer used to do by hand, for anyone who opens a PR.

Because the thing stopping them was never skill, and there is now a measurement that shows it. The AI in Design 2026 report from Designer Fund and Foundation Capital surveyed over 900 designers and found half of them have pushed AI-generated code to production, with only about a fifth of those identifying as design engineers. The interesting number is the split underneath it: 68% at early-stage companies ship code, against 33% at publicly traded ones. Ability does not fall as a company grows. Merge process rises. The gradient is measuring how many gates stand between a designer and main, and at your size most of them are made of a senior engineer’s attention. The wrong reading is to relax the gates so designers can get through, which is how you buy drift, a11y regressions and an XSS in a marketing page. The right one is to make the gates automatic: tokens and components the agent reads before it writes, design-system, accessibility, security, test-quality and performance checks that fail the run without a human, and senior review reserved for intent rather than for catching a raw hex. Then the designer ships, and what ships still looks like your product.

It solves the half that was never the hard half, and it points a new lane at the half that was. Two things shipped in 2026. Figma Make connected to GitHub on 28 May: a designer picks a repository, Make installs the dependencies and runs the application on the canvas, they edit the running UI directly, and the changes accumulate as commits and leave as a branch and a pull request without the designer writing a line. Then Code Layers arrived at Config on 24 June, putting a cloned repository on the canvas with a live two-way link to the Git-tracked code. Figma is explicit that none of this bypasses your engineering guardrails: the change goes through the same CI, the same security checks and the same review as any other commit. Read that for what it is. It is a promise about your pipeline, not theirs. If the thing standing between a branch and main in your org is a senior Frontend engineer’s attention, then a design tool that can now generate branches has pointed a new inbound channel at the bottleneck you already had. And what arrives fails in the ways a canvas cannot show: a value that should have come from a token, a component built beside the one that already exists, a state that only lives in a reducer, a keyboard path nobody walked, bundle cost nobody saw. So the answer is the same one as everywhere else on this page. Make the gate automatic and the tool becomes exactly what it looks like on the demo. Tokens and the real component registry served to the tool and the agent before either writes, design-system, accessibility, security, test-quality and performance checks that fail the run without a human, and senior review spent on intent. Then a designer’s PR is just a PR.

Not the syntax, which is why this surprises people. A strong backend engineer with a coding agent produces React that compiles and looks right in the browser. What they cannot carry is the tacit layer a senior Frontend engineer applies without noticing: which component already exists so a fourth modal is not born, which token the spacing has to come from, what the loading, empty, error and offline states are, what keyboard and screen-reader behavior the component owes, and what the change costs in bundle size. None of that is visible in a diff that works, so the PR sits waiting for the one person who can see it, and that person is the bottleneck you already had. The factory writes that layer down and enforces it, so the same PR either fails in CI with a specific reason the author can fix alone, or lands. The backend engineer is not asked to become a Frontend engineer. The standards stop being a person.

Because a coding agent writes code, and your bottleneck is merging it. In-house rollouts stall for the same reasons every time: the rules live in senior engineers’ heads, nothing enforces them, and nobody measures whether output actually got better. The factory makes the rules physical. Gates run on every agent run, deterministic checks first and LLM evals second, and the PR is not opened until they pass. When the same failure repeats, we fix the factory rather than the code, so the guard or skill that catches it is inherited by every run after it. That is the part you cannot buy off the shelf, and it is what decides whether the tools you already pay for turn into shipped product.

It makes the bill attributable, which is usually the real ask behind the question. The spend is genuine and it moved fast. Anthropic doubled its own published estimate for Claude Code on 15 April 2026, from about $6 to about $13 per developer per active day, roughly $150 to $250 per developer per month for enterprise use, while noting that 90% of users stay under $30 a day. That last figure is the tell: a long tail of heavy runs drives most of the number, not the average engineer. The public example is Uber, which Forbes reported on 17 May 2026 had exhausted its entire 2026 AI budget four months into the year after Claude Code spread across roughly 5,000 engineers, its CTO confirming the overrun. Neither of those is a story about a tool being expensive. Both are a story about consumption pricing landing in a line item that was modeled like a seat. What the factory changes is the unit. Agent traffic runs through a gateway rather than a per-engineer card, so spend is metered per repo, per team and per run, budgets sit where the work happens and a run that would cross one is stopped or routed down instead of quietly finishing, and the number you report is cost per merged pull request rather than cost per seat. That is the number that answers finance, because it moves the right way when the guards work: a run that fails a design-system check in ninety seconds never becomes the twenty-minute run a human then rejects. We build and operate the metering and the budgets. We do not resell tokens and we take no margin on your model spend.

The bottleneck is structural. AI-generated PRs are longer, more scattered, and less trusted, so reviewers wait longer to pick them up and spend more time inside them. The factory attacks it from four sides at once. Structured specs constrain what agents produce, so PRs land smaller and more focused. Generated tests and quality gates run before the PR exists, not after a human opens it. A review agent runs first, so senior reviewers only see what needs human judgement. And shared AGENTS.md context in the repo keeps agents from re-litigating the same review comments across sessions. The result: AI-generated PRs re-enter the same lane as human-written ones, and your senior reviewers stop being the single-threaded merge queue.

Four stops: audit, pilot, run, own. The audit reads your repo, workflow and team to find where the hours actually go and what an agent can safely own. The pilot runs inside one team, never org-wide on day one, against a single KPI written down before we start (a named non-Frontend person merges a production PR, demo-to-production cycle time against your own baseline, or throughput through the line). Then we operate the factory with your team inside it while we tune the gates, and hand it over with playbooks, configs and people who can run it without us. Phased fixed price. The first real output is a merged PR from your pilot team, not a slide.

A forward deployed engineer, an FDE, works inside your org rather than beside it. Same repo, same sprint, same Slack, same standup. The model came out of enterprise deployment work, and through 2026 it became the default way serious AI capability gets installed: the major labs and the large consultancies all stood up FDE practices, because enterprise AI work fails at the last mile into a real codebase, not at the model. The factory has exactly that shape. It is not a deliverable we hand across a table, it is infrastructure that has to be fitted to your architecture, your design system, your CI and your review culture, then operated until the habits stick. Our FDEs install it, run it with your team inside the loop, teach it, and hand it over. The engagement is designed to end.

Yes. We work inside your current codebase, design system, routing and CI, not a greenfield rewrite. Same stack, same conventions, same review process, and the security envelope is agreed before the first agent run, including restricted and on-prem environments. Everything the factory adds is committed to your repo: AGENTS.md context, the skills library, the guards, the review agent and the eval set. It stays when we do not.

All of them. The coding agent is the engine, and the engine is the part anyone can buy. We install the harness on top of whichever one your team already runs: Claude Code, the Claude Agent SDK, Cursor, Codex or GitHub Copilot. The harness is engine agnostic, so the same context structure (AGENTS.md, CLAUDE.md, Cursor rules), the same guards, the same review agent and the same evals apply either way. Teams frequently run more than one agent in the same repo, and we tune the setup so they compose instead of colliding.

A model release is a drill, not a crisis. We re-run the eval set against the new model and ship updated skills to every client within days, so you learn what changed from us and not from a bad merge. Dependency is designed out from the start: the factory is your repo, your gates, your playbooks, operated in the open with your team in the loop from the pilot onward, and handed over at the end. Some clients keep us on an operation retainer to stand up new lines and keep the gates sharp. That is a choice they make after handover, not the shape of the deal.

Completely. Embedded senior Frontend engineers are a delivery model we run alongside the factory, and plenty of engagements are simply strong React and React Native engineers shipping product on your team. They are mid-senior to senior (3+ years, typically 5+), already AI-native with Claude Code, Cursor and MCP, and they usually start within days of a signed scope and ship real code in the first week. We do not place juniors who learn on your time. They also arrive carrying factory tooling, so the factory itself is an upgrade you can choose later, never a requirement.

That is our other service line, Frontend AI: the factory is how your org ships, Frontend AI is what your product does. An MCP app puts your product inside AI assistants like ChatGPT and Claude as a real, usable interface, not just a text mention. When someone asks an assistant to book, buy or look something up, your product can show up as live UI and complete the task right there in the chat. If your customers start their journey in an assistant, you want to be the app it calls, not the website it skips. We build to the current MCP and MCP-UI protocol stack, in three layers: read-only data, personalized signed-in data, and full transactions. If you sell online, that third layer now has its own standards: the Universal Commerce Protocol (UCP) for how agents discover and transact with merchants, and the Agent Payments Protocol (AP2) for authorizing the payment underneath it. We build against both.

You mostly do not, which is the problem. 2026 buyer surveys put AI assistants ahead of review sites as the most influential source for a B2B shortlist, and around seven in ten buyers use one somewhere in the process, but none of that shows up in your analytics: the assistant reads your site, answers the question, and the buyer never clicks. If an agent cannot parse your page structure or find an action to call, it summarizes a competitor instead and you never learn it happened. Four things decide the outcome: discovery (llms.txt, robots.txt, sitemaps, and actually opting in the retrieval bots rather than blocking them by default), readability (semantic HTML and rich JSON-LD so the answer resolves to you as one organization), actions (WebMCP tools or an MCP server the agent can call), and trust (canonical URLs and clean entity resolution). Start with the free AgentReady scan on this site. It checks 21 of these, takes seconds, needs no signup, and tells you what an agent actually sees on your site today. Fixing what it finds is Frontend AI work, and we do that too, but the scan is yours either way.

Not on their own, and the 2026 evidence on that is unusually clear because both ends of it were measured in the same year. IBM Research published ScarfBench, a migration benchmark built from expert-written implementations across 204 directed tasks, 102 framework variants and roughly 151,000 lines of code. The strongest agent tested passed 15.3% of tests on single-layer migrations and 12.2% on whole applications, and exactly one of the 204 tasks came back fully behaviorally equivalent. Google published the other end: across 39 internal migrations run by three developers over twelve months, 595 change lists and 93,574 edits, the model generated 74.45% of the changes and 69.46% of the edits, and the developers put the work at roughly half the time it would have taken by hand. Same year, same class of model, two very different outcomes. What separates them is not the model. Google paired it with AST-based tooling that found every change site first, and put every change through normal review. The model did the typing. The harness decided what was true. That is the factory, pointed at a migration, and it is why we run migrations through one rather than beside one. On the Frontend it also settles what parity means, which is the part teams get wrong: a screen that renders the same pixels but loses a keyboard path, drops a focus trap, doubles its bundle or quietly changes an empty state has not migrated. Those are exactly the seven guards the factory already runs, so parity stops being a judgment call in review and becomes a test that passes or fails. We do not sell big-bang rewrites. The migration goes route by route behind the app you are already shipping, each slice provable and stoppable, and your roadmap keeps moving through it.

Block or allow is the wrong question, because the traffic is not one thing. Cloudflare reported on 3 June 2026 that automated requests had passed human traffic for the first time, with Radar putting it at 57.5% machine against 42.5% human, and its May 2026 breakdown found 51.8% of AI crawler requests were for training against 9.3% for search. Those two numbers have opposite value to you. A research or buying agent reading your product page is drawing a shortlist before you know the buyer exists. An agent operating your product for a customer is a user session with no browser chrome around it. A training crawler takes and returns nothing. Same traffic surface, three different commercial answers, which is why Cloudflare split crawlers into declared purposes on 1 July 2026 and will block the training and agent categories by default on ad-supported pages from 15 September 2026. So the decision is per surface and per purpose, and it is a product decision rather than an infrastructure one. What we build is the part that lives in your product: the same truth rendered for both audiences so an agent does not have to execute your bundle to learn what you sell, capability declared where agents look so they transact through an interface you designed instead of scraping a page you did not, identity verified at the application layer rather than trusting a user-agent string that any scraper can set, and agent sessions instrumented as their own funnel, because they fire none of the events your human funnel is built on and that share of your traffic is currently invisible to you. We are not a CDN and not a bot-management vendor. The enforcement belongs at your edge, and we build to the policy you set there.

It does not scale, until you change what a senior spends attention on, and the 2026 measurement says so plainly. Anthropic’s 2026 Agentic Coding Trends Report, citing its Societal Impacts research, found developers using AI in roughly 60% of their work while reporting they can fully delegate only 0 to 20% of tasks. That gap is not an adoption problem or a training problem. It is the honest distance between what a model can produce and what a person is willing to put their name on, and the report calls verification the bottleneck of what it names the orchestration era. Buying more agent seats moves the first number. Nothing about it touches the second. So the question worth working on is not how many agents you can start at once, it is how much of what they produce can reach a human already proven rather than merely finished. That conversion is the entire job of the harness. The design system, accessibility, security, test-quality, performance-budget and Storybook guards all run before a person is asked, each failure goes back to whoever opened the PR with a specific reason instead of arriving as a senior’s comment, and only the changes that genuinely need judgment reach a senior at all. What rises is not the agent count. It is the share of work a senior can let go of without lowering the bar, and the difference matters, because the other way to make that ratio look better is to review less carefully. That version we will not build for you.

Nothing in the model, which is the uncomfortable part, so the answer has to be built where you can actually build it: the interface and the scope around it. Look at what the best-resourced lab in the field shipped. OpenAI published Lockdown Mode and Elevated Risk labels on 13 February 2026 and updated the post on 4 June 2026 as the feature reached personal and self-serve Business accounts. Lockdown Mode mitigates by subtraction, turning off live browsing, images in responses, Deep Research, Agent Mode and file downloads. Elevated Risk labels are the other half, an informational warning rendered before an action whose destination or scope cannot be verified, appearing and disappearing as that assessment changes. Two shipped mitigations, both of them interface decisions, neither of them a model fix. The incident record has the same shape. The OWASP GenAI Security Project’s exploit round-up for Q1 2026, published on 14 April 2026 and covering 1 January to 11 April, documented eight incidents across government web applications, consumer agents, internal engineering systems, managed cloud platforms, open-source orchestration software and observability tooling, with exactly one CVE between them, and the categories invoked most often were prompt injection, sensitive information disclosure, supply chain, improper output handling and excessive agency. Eight to one is the number a product team should sit with: these do not arrive through the vulnerability pipeline your AppSec process watches, they arrive as your own agent doing something it was permitted to do. Which makes the defensible layer Frontend work. Untrusted content never rendered into the same trust context as the user’s own instruction. Tool scope declared per surface and narrowed to what that screen needs rather than to everything the agent could theoretically call. Irreversible actions behind a confirmation that names the real target instead of the intent. Provenance shown for whatever the agent read. A degraded mode the product can drop into, because subtraction is the current state of the art. And an action log the user can actually read. We build and operate that layer. We are not an AI security auditor, we do not run red-team engagements, and we do not certify anyone. No product-side mitigation makes an agent injection-proof, and the model vendors do not claim otherwise.

Almost nobody, and there is now a measurement of exactly that. Black Duck’s 2026 Open Source Security and Risk Analysis report, published on 25 February 2026 from audits of 947 commercial codebases across 17 industries, found 68% of them carrying open source license conflicts against 56% a year earlier, the largest single-year jump in the study’s history. The same report has the reason sitting next to it: 76% of organizations assess AI-generated code for security risk, only 54% assess it for IP and licensing, and 24% do a comprehensive review across IP, licensing, security and quality. Security got a process. Licensing did not. Two things make this a Frontend problem rather than a filing problem for legal. The first is the dependency habit. Open source components per codebase rose 30% year over year, and an agent asked for a date picker, a virtualized table or a chart will install one without an opinion about what it is licensed under, because nothing in the prompt asked. The second is quieter and worse: the report found 17% of open source components entering codebases outside any package manager, as copy-pasted snippets, vendored files and generated code. Those never appear in a manifest, so every scanner that reads package.json is blind to them, and a model reproducing an implementation it learned from a copyleft project does not carry the header along. Then the factory widens who ships, and a PM or a designer running an agent has no instinct for this at all. So it takes the same answer as design-system drift and the XSS class: a guard, not a policy page. Your legal team sets the policy, which licenses are allowed, which are denied and which need a human, and CI holds it: the full dependency graph checked on every PR including transitive packages and license changes that arrive in an upgrade, an SBOM produced by the build rather than assembled for a questionnaire, code that landed without a manifest entry flagged for provenance, and the answer recorded at merge instead of reconstructed under diligence. To be explicit about the boundary: we build and operate the gate. We are not your counsel, we do not give legal advice, we do not clear licenses, and we do not issue IP opinions.

Two ways, and neither one is a search box you can optimize. The first is a directory a person connects from. OpenAI opened third-party app submissions on 17 December 2025 alongside an in-product App Directory in ChatGPT, reachable from the tools menu or at chatgpt.com/apps, with every submission reviewed against its published guidelines before it lists. Anthropic has run a connector directory for Claude since 14 July 2025 and extended it to consumer services in April 2026. The second way is the one that decides your volume, and it is a model picking your tool in the middle of somebody else’s task, from the metadata you wrote. That makes tool descriptions, parameter schemas and annotations product copy with a machine as the reader, and it is usually the part a team hands to whoever has an afternoon. Notice what is deliberately closed off. OpenAI’s submission guidelines forbid descriptions, titles, tool annotations or other model-readable fields that manipulate how the model selects or uses other apps, or that interfere with fair discovery. The growth tactic everyone reaches for first is against the rules, and it gets an app rejected rather than ranked. What is left is product work. A small set of sharply scoped tools beats a large one, because a model choosing among forty overlapping tools chooses badly and then stops choosing you. Descriptions say when to call a tool and, just as usefully, when not to. Annotations are set honestly, so a write or a destructive action is marked as one. And the app has to finish the job inside the conversation, which is what MCP Apps is for: it became the first official MCP extension on 26 January 2026, letting a server return a UI resource the host renders in a sandboxed iframe, live in Claude on web and desktop, Goose and VS Code Insiders with ChatGPT following the same week. Keep this separate from being found on the web. Getting cited by an answer engine is about pages a crawler can read. This is about a tool a model can select. We build both, and they are different work. Two honest limits: no platform publishes its ranking, and nothing you can buy changes it.

From the half of the pipeline that starts after the merge, which is the half almost nobody installs. Two 2026 measurements sit on either side of it. CircleCI’s 2026 State of Software Delivery, published on 18 February 2026 from nearly 28 million workflows across more than 22,000 organizations in 149 countries, put main-branch success rates at 70.8%, the lowest in five years, with the median team taking 72 minutes to recover from a failure, up 13% year over year, while main-branch throughput fell 7%. Lightrun’s 2026 State of AI-Powered Engineering, published on 14 April 2026 from 200 SRE and DevOps leaders at director level and above across the US, UK and EU, found 43% of AI-generated code changes still needed manual debugging in production after passing QA and staging, and that 88% of organizations needed two to three redeploy cycles to publish a single AI-generated change. Not one respondent could do it in a single cycle. So the change cleared every gate and the truth arrived later, which is exactly what a guard cannot tell you: a guard proves a change is well-formed, and only production tells you it was right. On the Frontend the gap is sharper than anywhere else, for two reasons that have nothing to do with code quality. A Frontend release is not gradual by default, because there is no rolling restart to hide behind: you publish a bundle and the next person to load the page gets all of it, including the users mid-session on the previous one whose lazy chunks just stopped existing. And Frontend failures are silent. A button that does nothing, a form that rejects a valid input in one browser, a chart that renders empty for the accounts with the most data: zero server errors, no alert, and you hear about it from a customer. So the release path gets built on the same rule as the merge path, which is that it must not depend on anyone being careful. Exposure is decoupled from deployment, so a change ships dark and is turned on for a cohort rather than for everyone at once. The switch lives in the app rather than in the pipeline, so turning something off is seconds instead of a rebuild. Confirmation comes from field data on the routes that changed, Interaction to Next Paint, LCP and CLS from real users plus client error rate per release, not from a synthetic score on the homepage. And the client already running the old bundle is part of the plan instead of an afterthought. To be explicit about the boundary: we build and operate this inside your pipeline with the tools you already run. We are not an SRE vendor, we do not carry your pager or run your on-call rotation, and we do not sell you an observability product.

Capacity, more often than quality, and it breaks in the browser rather than in the model. Datadog published its State of AI Engineering 2026 on 21 April 2026 from LLM telemetry across thousands of organizations running AI in production, and the headline is not about answers being wrong: roughly 5% of AI model requests fail, and nearly 60% of those failures come from capacity limits rather than from anything the model said. Two more numbers from the same report set the shape. Sixty-nine percent of companies now run three or more models, so failing over to a second one is not hypothetical, it is Tuesday. And token usage per request more than doubled year over year for the median organization and quadrupled for the heaviest users, which is latency and cost both climbing underneath a feature whose interface was designed against a fast demo. One call in twenty failing is not an edge case. It is a state your product is in several times an hour, and every part of that state is rendered, which is what makes it ours. So we design it rather than catch it. A capacity failure gets a real surface that keeps what the user typed and offers a retry that does not cost them the work, instead of a red toast that throws it away. A stream that stops mid-sentence is detected as incomplete and labeled as incomplete, because a truncated answer presented as a finished one is the worst available outcome and nothing anywhere reported an error. Slow and broken are designed separately, because they are different experiences and the same spinner is wrong for both. A failover is treated as a product decision before an infrastructure one, since the second model has different latency, formatting and refusal behavior and the conversation visibly changes shape. And the feature gets its own funnel: time to first token, completion rate, retry rate, abandonment, and the share of sessions that ended up degraded, none of which fires the events your normal analytics is built on. Two things this is not. It is not agent UX, which is about whether a user can see and stop what an agent is doing. And it is not evals, which catch a quality regression before release and tell you nothing about 9am on Monday when your provider is at capacity. The honest limit is that the capacity is your provider’s. We are not an LLM gateway and not an observability vendor, and we do not sell an SLA on somebody else’s model. What we build is what your product does when the answer is late, partial, refused, or served by a different model than the one it was designed against.

Nothing in the model, and the reason that matters is that the invented names are predictable. Researchers from the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech presented “We Have a Package for You!” at USENIX Security 2025: 2.23 million code samples generated by 16 code-generating models across Python and JavaScript, of which 440,445, or 19.7%, contained at least one hallucinated package name, spread across 205,474 unique fabricated names. The finding that turns a curiosity into an attack is what happened when they re-ran identical prompts ten times each. 43% of the invented names came back on every single run, and 58% came back on more than one. A hallucination is not random noise. It is a stable namespace anyone can enumerate in advance and register first, and that is exactly what started happening: the Cloud Security Alliance published a research note on the resulting class, slopsquatting, on 19 April 2026, and in August 2026 a single actor pushed more than 700 malicious packages to npm inside 48 hours, since reported past a thousand, each carrying a cross-platform remote access trojan and infostealer. The clearest documented case is a Frontend one. Models produce the name “unused-imports” when they mean eslint-plugin-unused-imports. Somebody registered it with a credential stealer inside, and in early February 2026 it was still recording roughly 233 weekly downloads under an npm security hold. Two things make this ours rather than a general AppSec topic. npm is where the entire Frontend toolchain comes from, so the registry being seeded is the one your build stands on, and the documented example is a lint plugin rather than an exotic library. And installing is executing: a lifecycle script runs on the developer’s laptop and on the CI runner at install time, which is before the change builds, before any guard reads it, and long before a person reviews it. Every other guard we run decides whether a change should merge. This one has to run earlier, because by review time it has already happened. So the check moves to the moment a name enters the repository. Every added dependency is resolved against the registry with its first-publish date, download history, repository link and maintainer count, so a package that appeared nine days ago with nothing behind it stops the run with a reason. Lifecycle scripts are off by default for anything newly added and on only by allowlist. The install step runs without credentials or publish tokens on an unreviewed branch. The lockfile diff is reviewed as code rather than collapsed to one line. And the inventory of components and libraries you already approve is served to the agent as context, so “which chart library” resolves from a list you own instead of from what the model half-remembers. A name that does not resolve is logged with the prompt that produced it, because that same name will be back tomorrow. To be explicit about the boundary: we build and operate the gate inside your pipeline, with your registry and your tooling. We are not a security vendor, we do not run a threat intelligence feed, we do not scan packages for malware, and we do not certify anything as safe.

For part of it, and the interesting question is which part. Chrome 148 shipped on 5 May 2026 with the Prompt API stable, which puts Gemini Nano behind a JavaScript call in the page: no API key, no account, and no network round trip for generation, with multimodal input across text, image and audio, streaming, and output you can constrain to a JSON schema or a regular expression. For a real class of work that beats a hosted call outright, because the latency floor is local and the content never leaves the machine. Then read the rest of the story, because it decides the architecture rather than the roadmap. Mozilla, Apple’s WebKit team, the W3C Technical Architecture Group and Microsoft all filed objections on the way to that release, the TAG review closed without consensus, and Edge did not turn the feature on despite being built on Chromium. It is not in Firefox and it is not in Safari. Even inside a supported Chrome the answer is per device rather than per browser, because the model is a large local download gated on disk and hardware, so the same version of the same browser says yes on one laptop and no on the next. That is not a gap you wait out. It is the shape of the capability, and a product that treats the local path as the default ships a feature most of its users never see. So we build it as two paths behind one contract. Capability is detected per feature at call time rather than sniffed from a browser string. The hosted path is the default and the local one is the upgrade, never the reverse, so the fallback is the well-tested path instead of the neglected one. The component consumes the same typed, streamed, schema-constrained result either way, so nothing forks below the call site. And the states that exist only on this axis get designed rather than discovered: a model still downloading is a real state with real copy, not a spinner that never resolves. The privacy claim is bound to the path that actually ran, because “this never leaves your device” is true locally and false on the fallback, and a promise rendered on the wrong path is the worst outcome available here. What belongs local is the high-frequency, latency-sensitive, small-context work: classify as someone types, extract from a pasted block, rewrite a selection, translate, draft in a field, redact before anything is sent anywhere. What does not is the flagship reasoning feature, where the answer is the product. And the cost does not vanish, it moves to the user’s battery and thermal budget on a device you do not control, so we read it like any other interaction, with Interaction to Next Paint from real devices rather than a token count. Two boundaries: we build the feature and both paths, we are not a model vendor and we do not ship you a model, and we will not promise a capability a browser has not shipped. This roster moves quarterly, so we date what we claim and re-check it.

Not a longer file, and February 2026 is when that stopped being an opinion. Researchers at ETH Zurich and LogicStar.ai published Evaluating AGENTS.md, the first controlled study of whether repository context files help coding agents, run across Claude Code on Sonnet 4.5, OpenAI Codex on GPT-5.2 and GPT-5.1 mini, and Qwen Code on Qwen3-30B-Coder, over SWE-bench Lite (300 tasks across eleven well-known Python repositories) and a new suite of 138 tasks drawn from twelve less-travelled repositories that carry real context files their maintainers wrote. Each agent ran three ways: with no context file, with one generated the way its own vendor recommends, and against the human-maintained file. A generated context file came out slightly worse than no file at all, about half a point on SWE-bench Lite and two to three points on the harder suite, while inference cost rose 20 to 23% because the agent took more steps and reasoned longer. The human-written files did better and the size of "better" is the part worth sitting with: roughly four points, still with close to a fifth more cost. The authors put their finger on why, and it is the sentence that should change what your team does on Monday. Codebase overviews and directory listings did not help agents navigate, because agents are already good at discovering structure on their own, so a listing you maintain by hand mostly spends reasoning tokens telling them something they were going to find anyway. Read that as a result about your repository rather than about markdown. What an agent can find is a property of the codebase, not of the file describing it, and the Frontend is where that bites hardest, because a route’s real behaviour is scattered across a component, a hook, a provider, a token file, a route module and a test, and none of that scatter is visible in a tree. So the work moves to three places. Structure the agent cannot miss: one obvious home per concern, so its first guess is right and it never has to be told; module boundaries that are import rules CI enforces rather than a convention someone documented; and cycles broken, because a dependency loop is precisely the shape that makes "read the relevant files" unbounded. Ownership expressed as code, with CODEOWNERS wired to the same boundaries the lint rules hold, so the question of who reviews a change has one answer that cannot drift from the structure. And a context file kept short and load-bearing: the commands, the invariants and the things that genuinely cannot be discovered by reading, which is what the maintained files in that study were carrying when they earned their four points. To be clear about what we are not saying, because the internet took this study somewhere sillier than it goes: we do not tell anyone to delete their AGENTS.md. Context that is true and unguessable is worth having, and we still write and maintain it in every engagement. The finding is about what a file can carry, and the answer to a structural problem was never going to be a paragraph. And we do not sell a rewrite. Boundaries get drawn where the seams already are, enforced first on the lines a pull request touches and ratcheted from there, exactly the way the performance budget and the license gate already work here, because a rule switched on at an ideal standard over a six-year-old codebase gets disabled by Thursday.

It is real, it has been measured, and the measurement also says what to do about it, which is the half that usually gets dropped. Anthropic published How AI assistance impacts the formation of coding skills on 29 January 2026. Fifty-two mostly junior engineers, all of whom had been writing Python weekly for over a year and none of whom knew Trio, the async library the study was built on, were split at random: half worked with an AI assistant that could produce correct code on demand, half without one. Both halves had the documentation, the tooling and search. Then both sat the same comprehension quiz with no AI in the room. The unassisted group averaged 67%, the assisted group 50%. The steepest fall was in debugging, and the authors offer the mechanism plainly: the unassisted group hit Trio-specific errors and built the skill by digging out of them, while the assisted group hit far fewer errors and afterwards could not explain the code that had worked. Their code was better during the session. Their understanding of it was worse after. Now the part that makes this a training subject rather than a warning label. The spread was not between the groups, it was inside the assisted one. The researchers separated six distinct interaction patterns: three of them scored under 40%, and three scored between 65% and 86%, which is at or above the people who got no help at all. What the high scorers did differently was use the assistant to build understanding while it produced code, asking follow-up questions, requesting the reasoning, sending the kind of hybrid request that comes back with an implementation and an explanation of why it looks like that. They were not the fastest in the session. They were the ones who still knew the material at the end of it. So the variable is how someone works with the tool, and how someone works with a tool is a teachable thing, which is exactly what a workshop is for. This is why we never make the argument that a team should use AI less, and we would not believe it if someone else made it. It is also why this matters commercially rather than sentimentally. Every guard the factory installs ends by handing a specific reason to a person who has to read a diff and decide, and the ceiling on how much you can ship is how much your people can actually stand behind. An organisation that raises output while quietly eroding the judgment that output depends on has borrowed against next year. Three honest limits, because this is easy to oversell. The study looked at mostly junior engineers learning one unfamiliar library in one session, so we do not stretch it into a claim about your seniors or about a career. We do not sell you juniors, and this is not a graduate programme: the training runs on your own engineers at whatever level they are, on your own codebase. And we will not put a number on what a workshop recovers, because nobody has measured that and inventing it would be the same failure in a different direction.

Mostly not, and the published measurement is more useful than the complaint. Mergify’s State of Merge Queues 2026 looked at more than 200,000 pull requests merged across 477 engineering organizations over a rolling 90-day window, and AI-assisted pull requests broke the main branch 1.9% of the time against 4.4% for pull requests with no detectable AI assistance. The thing that actually predicts a broken main is scale: the rate rises roughly 16x with team size, from about one merge in 130 at two to five engineers on a repository to one in eight at forty or more, and private repositories break main 4.5 times as often as open source. So the agent is not the variable in your incident. Volume arriving at a control point that was sized for human typing speed is, and the same report found 94% of teams still pushing one pull request through the queue at a time. Frontend is where that bites hardest, because Frontend CI is the expensive kind: a browser matrix, visual regression, an accessibility pass, a bundle budget and a Lighthouse run are minutes each, not seconds, so doubling the arrivals does not double the wait, it multiplies it. The factory treats the pipeline as capacity to be engineered rather than a queue to apologise for. Cheap deterministic checks run first and fail fast, so the browser matrix is never spent on a change that does not typecheck. Test impact analysis means a token edit does not run the suite that a routing change does. The queue batches and bisects instead of testing every pull request alone, which is where the CI bill actually comes down. Runs are isolated per agent rather than queueing on one shared staging. And the guards decide mergeability before a human is asked, so the scarce thing, senior attention, is spent on intent and architecture rather than on what a machine could have caught. We build this on the CI you already run. We are not a CI vendor and we do not resell one.

The first half is now cryptographic rather than a user-agent string you hope is honest, and the second half is the part only you can build. The mechanism is Web Bot Auth: an agent signs its requests using HTTP Message Signatures, RFC 9421, with a per-agent Ed25519 key, and sends a Signature-Agent header naming the key directory it publishes, alongside a Signature Agent Card describing the operator, the expected request rate and the keys. Your edge fetches that directory, verifies the signature, and now knows which operator is calling instead of guessing. The status is worth stating precisely, because it is unusual. The IETF chartered a working group for it in 2026 after a Birds of a Feather session at IETF 123, and as of August 2026 that group had adopted no documents, while Cloudflare, AWS, Akamai, HUMAN and Vercel verify these signatures in production every day and Google publishes its own key directory and implementation guidance as an experiment, saying plainly that it does not replace IP and DNS verification and that not every request is signed. It shipped before it standardised, so anything you build has to be correct both for agents that sign and for the larger number that still do not. Then comes the part a signature cannot answer. Verified identity tells you who is calling. It does not tell you what they may read, which of your capabilities they may call, what they may buy, or what an unverified caller should get instead, and none of that lives at the edge because all of it is your domain model. That mapping is the product work: capability exposed as callable tools rather than a page to scrape, permissions scoped to the user an agent is acting for and never wider, limits set per operator rather than per IP, an honest reduced response instead of a silent block for callers you cannot verify, real parameters rendered in front of anything irreversible, and agent sessions instrumented as their own funnel. We build that layer in your product. We are not a bot management vendor, we do not sell or operate a CDN or a WAF, and we will not promise behaviour a standard has not shipped.

A ban is the one option that reliably fails, because the demand behind those tools is real and the tools are now easier to reach than you are. The measured picture is worth sitting with. Retool surveyed 307 senior technology and security leaders, 43% CISOs, 35% CTOs and 22% CIOs, fielded by the research firm Wynter in May 2026: 93% were at least somewhat concerned about vibe-coded internal tools running in production and 38% were very concerned, only 5% were very confident they had full visibility into every internal tool in production, and only 8% described their governance as strong. The figure that names the actual problem is the last one. 59% could not confirm whether they had already had an AI-caused production incident, and only 19% could say they had not and point at the monitoring that told them. Concern is universal, the mechanism to act on it is mostly absent. Two things make this ours rather than a policy memo. Almost every one of those tools is a Frontend: an internal dashboard, a form, an admin screen, a report, a UI put over data and services that already existed, which is exactly the layer we own. And the person who built it is the same person the factory exists to unlock. A shadow estate is not an obedience problem, it is a measurement of how much demand your sanctioned path is not absorbing, and the last two years of that demand went somewhere. So the answer is a path rather than a prohibition. Triage first, because not everything belongs in your codebase: anything touching production data, customer-facing surfaces, credentials or a workflow other people now depend on gets a sanctioned home, and a genuinely personal throwaway stays where it is and stays disposable. Then the sanctioned path has to actually win on speed, which is what the guards are for, since a policy that is slower than the prompt just moves the estate somewhere you can see even less. Same repo, same review, same seven guards, with an owner, an auth boundary and a log, and the tools people already like used as the front end of that path rather than banned from it. One boundary, stated plainly: we build the path and the guards. We are not a shadow-IT discovery product, we do not scan your network, and we do not monitor your employees.

Both, and there is now a measurement that separates them. ClawBench, published in April 2026 by researchers at TIGER-AI-Lab, runs browser agents over 153 everyday online tasks across 144 live websites in fifteen categories, deliberately weighted to state-changing work: purchases, appointments, job applications, long forms. A run only counts if the agent’s final HTTP request matches the task schema, and a judge then grades it against a human reference trajectory over a five-layer recording, so a confident summary of a thing that never happened scores zero. The strongest frontier agent evaluated finished 33.3% of the tasks, roughly one in three, and the majority of tasks defeated every model tested. The number that matters is the comparison: the same class of agent scores in the 65 to 75% range on the older benchmarks built from hosted replicas and static page traces. Two thirds of that gap is not the model getting worse between Tuesday and Wednesday. It is everything the replica left out, which is to say your actual interface: a consent banner that appears after the page is interactive, a modal that opens mid-flow with no labelled way out, a control that exists only as a hover, a step whose state change is painted but never announced, a form that spans five screens and loses itself on the fourth. This is a rendering problem, which is what makes it Frontend AI work rather than an infrastructure topic. The useful part is that most of the fix is already on your roadmap: an agent reads what a screen reader reads, so the accessibility gate the factory runs is the same work, paying twice. Beyond that it is a declared, machine-callable path for the tasks agents actually attempt, over WebMCP in the page or an MCP endpoint beside it, so the important flows never depend on driving a UI built for hands at all; interaction targets that are stable, semantic and labelled; flows that survive interruption; and irreversible actions behind a confirmation that renders their real parameters, with a legible failure and a machine-readable reason instead of a dead end. Two things we will not do. We do not build CAPTCHA solving, bot-detection evasion or anything meant to make an agent look like a person: the answer for a legitimate agent is a declared path and a verified identity, not a hole in your defences. And we do not promise your product a score on anyone’s benchmark.

Because there is nothing to catch. A hardcoded label compiles, passes types, passes tests and renders correctly in the browser the author is looking at, so it clears every gate you own and every reviewer who skims the diff. Three defects travel with it and all three ship green. Layout sized to English, where German and Finnish routinely run 30 to 50% longer and a button that fits at 12 characters clips at 18. Physical direction in CSS, margin-left instead of margin-inline-start, because that is what the majority of the training data says, and it mirrors wrong the moment the app renders in Hebrew or Arabic. And sentences built by joining fragments, which is untranslatable in any language whose word order differs from yours. The cost is not cosmetic: CSA Research, surveying 8,709 consumers across 29 countries, found 76% prefer to buy where the information is in their own language and 40% will not buy from a site in another language at all, which is the conversion rate of whichever locale quietly regressed this quarter. So it becomes a guard that runs on the diff and is deliberately cheap, because the expensive version gets switched off: no user-visible literal outside the translation call in changed code, every new key resolvable in the source locale, a pseudo-locale build padded 40% longer rendered in the screenshots the pipeline already takes so truncation shows up as an ordinary visual diff, physical-direction CSS rejected in new code, an RTL pass on the routes the change touched, and Intl for dates, numbers and currency. It is ratcheted onto changed lines, so a repo full of hardcoded strings stops getting worse on day one instead of going red. And the same rules live in the context the agent reads before it writes, so most of the time the guard never has to fire. We fix the code and operate the gate. We are not a translation vendor and we do not run your TMS.

By treating the swap as routine, because the cadence is now published rather than surprising. Anthropic commits to at least 60 days of notice before retiring a public model and its 2026 record runs to about that: Sonnet 4 and Opus 4 notified on 14 April 2026 and retired on 15 June, Opus 4.1 notified on 5 June and retired on 5 August. OpenAI’s April 2026 notice covered more than 25 model IDs across two hard shutdown dates, 23 July and 23 October 2026, and the Assistants API was sunset on 26 August 2026. Read as a planning input, that is a swap roughly every two quarters. The retirement date is the easy half, because after it the calls fail loudly and you find out. The damage comes from the voluntary swap, where you repoint at a newer model and the endpoint keeps returning 200 while the behaviour moves underneath: tool-call formatting, JSON adherence, verbosity, latency, where the refusal boundary sits. Nothing errors, and almost every consequence is rendered, which is what makes it our work. A component that parses one response shape renders an empty panel. A streaming UI tuned to one token cadence stutters. A card sized for three sentences overflows at eight. A refusal that never used to happen has no designed state. What we build so the next one is a Tuesday: the model as configuration per surface rather than a literal, so you move one feature at a time; model and prompt version carried into your telemetry so "since when" is answerable; a regression set built from real production traffic and diffed on what your interface depends on, shape, length, latency, refusal rate and the outcome the feature exists to produce; response validation at the boundary with a designed degraded state; a canary before the switch; and a rollback that is a config change rather than a deploy. We build that inside your product. We are not an evals vendor, we do not resell inference, and we do not pick your model for you.

Because on the backend the agent can check its own work, and on the Frontend it cannot. That difference is structural rather than a matter of model quality, and it is the single most useful thing to understand about agentic coding on the Frontend. A backend agent closes its own loop: it runs the test, calls the endpoint, reads the row back, and knows whether the thing it just wrote does what it was asked. A Frontend agent gets a build that passed. Nothing in a successful build tells it that the modal is unreachable on a narrow viewport, that the focus ring disappeared, that contrast dropped below the threshold, that the layout shifts once the real data arrives, or that the submit button now sits underneath the sticky header. The compiler agrees with it, the type checker agrees with it, and the tests it just wrote agree with it. So the agent stops at the last point it can verify, which is a long way short of the point where the work is actually right, and everything between those two points becomes somebody else’s problem. That somebody is a human, and it lands on them at exactly the moment there is more output than a human can look at. Faros AI’s 2026 engineering report, drawn from two years of telemetry across 22,000 developers and more than 4,000 teams, compared low AI adoption with high and found median time in pull request review up 441.5% and median time to first review up 156.6%. Review became the constraint because review became the only instrument. So the answer is not more review, and it is not a better model. It is to give the agent the missing sense before it opens a pull request: real browser control committed to the repo so every agent has it rather than whichever engineer configured it, the accessibility tree read as the primary signal rather than pixels because it is deterministic, diffable and the same surface a screen reader consumes, the states worth checking declared as fixtures rather than left to be discovered (loading, empty, error, offline, long content, narrow viewport, right to left), and time and animation frozen so a screenshot means something. Then the loop fails fast and cheap, before the expensive suite and before a person. Two honest limits, because this oversells easily. A browser does not make an agent correct, it tells the agent when it is obviously wrong, which is a smaller and more valuable claim. And rendering a change is still not a judgment about whether the change was a good idea, which is the part that stays human. We build and operate the loop inside your pipeline with the tools you already run. We are not a testing vendor, we do not sell a visual regression product, and we do not sell QA headcount.

It matters, but not for the reason the score implies, and the useful move is to pass it quickly and then ignore it. What changed is the measurement rather than your product. On 17 April 2026 Cloudflare launched a public Agent Readiness Score, a 0 to 100 number anyone can run against any domain at isitagentready.com, added an agent readiness view to its URL Scanner, and began publishing a dataset on Cloudflare Radar tracking adoption of agent standards across the internet. Agent readiness stopped being something you assert in a deck and became something a third party measures about you, continuously, without asking. Your buyers can run it. So can your competitors. Be precise about what it is measuring, because the number is narrower than it sounds. It reads the declarations: robots.txt and a sitemap, Markdown content negotiation, content signals, MCP server cards, an API catalogue, verified agent identity, the agentic commerce protocols. All of that is publishable, declarative and largely mechanical, which is exactly why we tell clients to go and pass it, mostly in an afternoon, and treat the result as a floor rather than an achievement. What the score cannot see is whether an agent can actually finish anything in your product, and that gap is the whole point. ClawBench measured it from the other side: the strongest frontier agent it evaluated completed roughly one live web task in three, while the same class of agent scores far higher against hosted replicas. A perfect readiness score in front of a checkout an agent cannot complete is a very well labelled dead end, and it is a worse outcome than a mediocre score, because it converts an unknown problem into a false negative. So we treat the declarations as hygiene, done once and kept true by CI rather than by memory, and then spend the real effort on the part that decides outcomes: which flows are agent-operable at all, capability declared as callable tools over WebMCP or an MCP endpoint rather than a UI an agent has to drive, delegated action riding on the authorisation you already have, and agent sessions instrumented as their own funnel so you find out where they stop. Three boundaries. We do not control that score, nobody sells placement in it, and any consultancy promising to move a third party’s number is selling you something it cannot deliver. We build in your product, and enforcement of who gets in belongs at your edge, so we are not a CDN or a bot management vendor. And we run our own AgentReady Site Scan because a second opinion on the declarations is cheap and useful, not because passing a scanner is evidence that an agent can use your product. Those are different claims and we keep them apart.

Because the code that produces those numbers is the only Frontend code in your repository with no consumer inside it, so nothing you already run can tell you when it breaks. Look at what an analytics event actually is. A button is clicked, a handler fires, and a call goes out to a service owned by a different team in a different tool. Every other line in that file is read by something that fails loudly when it is wrong: a component renders, a type checks, a test asserts, a reviewer recognises the shape. The event is read by a dashboard nobody in the pull request can see. Delete it and the build passes. Rename one of its properties and the build passes. Fire it twice and the build passes. Now notice which operations break it. Extracting a component, replacing a click handler with a form action, moving a route, folding two near-identical buttons into one, changing when an effect runs. Every one of those preserves behaviour, which is why it ships green, and every one of them is the exact class of change a coding agent produces most of, at a volume no reviewer was sized for. The failure is worse than silent, it is plausible: an event that stopped firing renders as a flat line that reads like a change in customer behaviour, so the first response is a product meeting rather than a bug report, and somebody makes a decision on it. The shape of the problem is documented one layer down. dbt Labs’ 2026 State of Analytics Engineering, from 363 data practitioners and leaders, found 53% citing poor data quality, 71% concerned about incorrect data reaching stakeholders and 41% naming ambiguous ownership, while 72% were prioritising AI-assisted coding in their own workflows against 24% prioritising AI-assisted testing and observability of the pipeline. Authoring got faster and checking did not. So we treat the measurement layer as code and put a small gate on it. The events the business genuinely steers by get a typed schema in your repository, so a dropped or renamed property fails to compile at the call site rather than surfacing in a dashboard six weeks later. The flows your pipeline already drives assert that the event fired, once, with the right shape, which is the test quality rule pointed at a new target: an event with no assertion is not evidence. Each of those events carries an owner, generated from the same module boundaries your CODEOWNERS comes from, so an orphan has a name against it. Consent is enforced in code rather than described in a policy, so an event either respects the recorded state or does not fire at all. And the release path checks volume on the events that matter, because the residual failures are the ones no static check can see. Two limits, said plainly. This covers the small set of events you steer by and never your whole taxonomy, because a schema imposed over eight hundred events is a rule that gets switched off by Thursday, so it starts as an inventory and ratchets onto changed lines. And a green gate is not a correct number: it tells you the event you defined fired where you said it would, and it cannot tell you the event measures the thing you think it measures, or recover what consent and a blocked request never sent. We instrument what you already run. We are not a data agency, we do not build your warehouse, model your data or run your BI, and we do not choose your vendor.

Start by accepting that a usage number is not an answer to that question, and that almost everyone is in the same position. Banyan Software surveyed more than 260 founders and chief executives of vertical software companies and found 51% of those who had added AI to an existing product reporting that fewer than a quarter of their customers use it. The State of Product Leadership 2026, run by Userflow with Ramli John and Delight Path across 107 senior product leaders in North America, Europe and Asia-Pacific, found 30% with no reliable way to know whether their AI features help anyone and only 33% measuring an outcome such as task completion or time saved. That is the common state: a feature that shipped, a usage figure that is technically true, and no argument for either keeping it or killing it. The same survey ranked what users struggle with, and the ranking is the useful part. Trusting the output came first at 44%, ahead of understanding how the feature works at 26%, fitting it into the workflow at 25%, and discovering that it exists at 21%. Discovery came last. That matters because discovery is exactly what teams reach for when adoption is flat: a tour, a banner, a badge on the nav item, a launch email. Those aim at the smallest of the four barriers, which is why they move the number for a week. Trust is first, and trust is not a growth problem, it is a rendering problem, which is what makes it ours. So we build the interface that earns the second use. The answer shows what it was drawn from, so a user can check it instead of believing it. Editing the result in place is the primary action rather than regenerating and hoping, because someone who can correct an answer will keep using a feature that is right most of the time, and someone who can only accept or discard will not. Undo is real and reaches the thing that changed. And the feature meets the user inside the job rather than at a destination they have to navigate to, because the competition is never nothing, it is the way they do the job by hand today. Then we instrument the part that is actually the outcome, which is what happened to the answer after it arrived: accepted without editing, accepted after editing and how much was changed, retried on the same intent, undone, or abandoned in favour of the manual path, alongside the one job-level result the feature exists to move, tied to the model and prompt version behind it. All of those are rendered interactions, so they can only be captured where they are rendered, which is why this is Frontend work rather than a dashboard exercise. Keep it apart from its neighbours, because the vocabulary overlaps and the questions do not. Whether a user can see and stop an agent mid-run is agent UX. What the interface does when a call is slow, capacity-limited or truncated is the reliability envelope. What moves when the model underneath is replaced is model lifecycle. This is whether the feature produced the result it exists for, and how anyone would know. One thing we say before starting, because it is the honest version of the offer: measuring properly can tell you the feature is not worth keeping. That is a legitimate result, and a cheap one next to another year of maintaining it. We build the feature, the surfaces and the instrumentation. We are not a growth agency, we do not run your onboarding tooling, and we do not write your adoption plan.

Nothing you are running today, and the reason is that a diff is local while a contract is not. The change is correct in the file it is in. The thing it disagrees with is a service in another repository, owned by another team, that changed last Tuesday. A reviewer reading the pull request cannot see the disagreement, because the other half of it is not in the pull request. That gap is now the largest measured category of AI-related production failure. New Relic published its 2026 State of AI Coding on 10 June 2026, a Hanover Research survey of 200 US technology decision-makers at manager level and above whose organisations use AI for software development, and the two headline numbers sit either side of the merge. At review time, 94% of leaders rated AI-generated code as higher quality than human-written code. In the six months before the survey, 82% had at least one production failure they traced to AI-generated code, and the most common failure mode was integration failures, at roughly three organisations in ten, described as sudden schema drift, upstream contract violations and rising error rates between services. Code that reads better and breaks more is not a paradox, it is a description of where the defect lives: outside the diff. The Frontend gets this worse than any other layer for a structural reason, and it is worth being precise about it. The Frontend consumes every service and owns none of them, so every screen depends on shapes it does not control. And nothing checks those shapes at runtime. A response arrives from the network as untyped data, and the type you have written over it is an assertion about the server rather than a verification of it. TypeScript checks your code against that type. Nothing checks that type against the server. So a field renamed upstream type checks, compiles, passes the suite and renders as an empty panel or the word undefined in front of a customer, and the first person to find out is that customer. Two agent-specific behaviours turn a known weakness into the leading failure mode. Agents conform: ask one to fix a type error and it will edit the type until the error stops, rather than stopping to ask which side is telling the truth, which resolves a real contract break into a silent one. And the same agent writes the mock, from the same assumption, so the test agrees with the bug in writing. That is the seventh wave rule pointed at a new target, and it is why a green suite is not evidence here. What we install is a gate on the boundary rather than more diligence. The contract is generated from the provider and never hand-maintained, because a hand-written copy of somebody else’s shape is a second thing to keep true and it never is. The build fails on a consumer-breaking difference between the contract in the pull request and the one the app was built against, classified by severity so that an added optional field costs nothing and a removed or renamed field stops the run. Mocks and test fixtures are generated from that same contract, so a fixture cannot quietly drift away from the service it stands in for, which is the failure that makes a suite go greener as it gets more wrong. And the app records which fields it actually reads, which is the artifact your backend teams have never had: a provider that knows what its consumers consume can tell the difference between a safe deletion and an outage. For the services you do not control, and every product has some, the same recording gives you a scheduled check against the vendor rather than an incident, so you learn on a Tuesday morning that a shape moved. Two limits, said plainly. A contract check tells you the shape matches and never that the value means what you think it means, which is the same honest limit the measurement gate carries. And it cannot cover an endpoint nobody has described, so the first pass is an inventory of what your application actually calls, which is reliably a longer list than anyone expects. We build and operate the gate inside your pipeline, against your specs and your tooling. We are not an API management vendor, we do not sell or run a gateway, and we do not take ownership of your backend’s contract.

Probably not the ones you are being sold, and the most useful event of 2026 was a retreat rather than a launch. OpenAI put Instant Checkout into ChatGPT with Etsy on 29 September 2025 and added a handful of Shopify brands, and only around a dozen merchants ever went live. It retired the feature in March 2026, confirming the change in its updated shopping announcement on 24 March 2026 and repositioning ChatGPT toward product discovery, with the purchase moving back to the merchant’s own environment. The stated reason is the sentence to keep, because it describes almost every product reading this: people were researching inside the assistant and completing the purchase somewhere else. The protocol layer kept moving anyway, and it is worth knowing the shape of it even if you build none of it this year. ACP, the Agentic Commerce Protocol, is an Apache 2.0 standard co-maintained by OpenAI and Stripe that describes how an agent runs a checkout against a merchant it does not own. Google released the Universal Commerce Protocol with Shopify in January 2026 and expanded it at I/O with a Universal Cart, with retailers including Target, Walmart and Wayfair named around the launch and Shopify merchants reachable through Agentic Storefronts. AP2, Google’s Agent Payments Protocol, carries the authorisation as signed intent, cart and payment mandates rather than as a stored card, which is the part of the stack that is genuinely new. Payment providers have started shipping suites that speak several of these at once, which tells you plainly that nobody expects one of them to win soon. All of that is dated on purpose and we re-check it quarterly, because this roster rotates faster than anything else we name. So the answer splits, and the larger half is the one nobody is selling. For most products the transaction still closes on your own surface, and the work is the handoff. Someone arrives already mid-decision, carrying a claim an assistant made about your product, and lands on a page written for a person at the very beginning of one. What we build there is the arrival: the intent carried across that boundary instead of dropped, so a cart, a plan, a configuration or a quote the assistant assembled is reconstructable on your side rather than retyped; a landing surface that answers the claim the visitor arrived with instead of restarting the pitch at the top of the funnel; and, most importantly, the same product truth in both places, because price, availability, terms and what is actually included are read by the assistant from whatever you publish, and the failure that costs the sale is an assistant being confidently right about something your own page then contradicts. For the smaller set of products that genuinely sell through an agent surface, the protocol work is real and it has the same shape as every other agent-facing thing we build: the capability declared rather than inferred from a page an agent has to drive, the irreversible step rendering its real parameters behind an explicit confirmation, an idempotency key so a retried purchase is not a second purchase, and the authorisation carried as a scoped mandate rather than as a credential you store. Build the commerce logic behind your own interface and treat each protocol as an adapter over it, so the one that loses costs you an adapter rather than a rewrite. Two honest limits. Nobody knows which of these standards survives, and anyone telling you otherwise is guessing in public. And an agent surface is not a channel you control: you cannot see the conversation that preceded the arrival, so attribution here is partial and we label it as such rather than implying a funnel we can close. Keep this apart from its neighbours, because they all involve agents and they are different purchases. Whether you get cited at all is discoverability. Whether you serve automated callers is access policy. Who is calling is verified identity. Whether a caller can finish a flow you designed for people is operability. This is what a transaction looks like when an agent is a party to it, and where it actually closes. We build the product side. We are not a payment provider, we do not become your merchant of record, we do not touch card data or hold funds, and we do not resell a commerce platform.

Making the code legible under pressure, and deciding that at merge time, because 02:00 is the one moment when nobody can add it. Start with where the cost actually moved. Stack Overflow’s 2025 Developer Survey, fielded May to August 2025 across more than 49,000 developers in 177 countries, found the top complaint about AI output was not that it is wrong but that it is “almost right, but not quite”, cited by 66%, and that 45% said debugging AI-generated code takes longer than writing the equivalent themselves. Writing got cheap and understanding got expensive, and those are not the same budget. New Relic’s 2026 State of AI Coding, published 10 June 2026 from a Hanover Research survey of 200 US technology decision-makers at manager level and above, shows where that bill lands: 78% reported more incidents once AI-generated code ships, and 86% reported senior staff spending more time fixing code. That second number is the one worth staring at, because it is the exact opposite of what the tools were bought for. The seniors were supposed to be freed. They were reassigned to firefighting. Now the part specific to us. A guard asks whether a change is well-formed. Nothing in your pipeline asks whether the change will be readable by a stranger holding a pager, and that is a different property with different mechanics. On the Frontend it fails in four recognisable ways, all of them cheap to fix in advance and impossible to fix during. The stack trace arrives minified, because source maps were never uploaded for that release, so the error names a variable called “t” in a bundle nobody can open. The error has no release and no commit stamped on it, so there is no path from the thing that is burning back to the pull request that lit it. The failure renders as a blank region rather than a designed state, because there is no boundary around the surface, so the first signal is a customer rather than an alert. And the error itself carries no correlation id across the boundary, so the Frontend event and the backend trace stay two unrelated stories. None of that is about code quality. All of it is decided before the merge. So it becomes assertions on changed lines, in the guards you already have. A new user-facing surface ships with its error and empty states, which the Storybook guard already asks for and which is now also what the on-call engineer sees instead of a white rectangle. Source maps are produced and uploaded per release as part of the build rather than as somebody’s habit. Release and commit are stamped into client telemetry so an error resolves to a diff. Errors cross the boundary carrying a correlation id. And a caught error is either handled or reported, never swallowed into a null, which is the single most common way an agent makes a failure invisible while making the tests pass. Two honest limits. This does not reduce incidents, it reduces how long you are inside one, and those are different promises. And it cannot retrofit comprehension of a codebase nobody understands, it can only stop the next change from adding to the pile. Our boundary is unchanged and it is the one we have been stating since the first engagement: we build and operate this inside your pipeline with the tooling you already run, we do not join your on-call rotation, and we do not sell an observability product.

More than a vector store and less than a rewrite, and almost all of the cost is in three decisions that have nothing to do with the model. Memory stopped being a differentiator during 2026 and became an expectation: every serious assistant now ships user-level memory, and a product whose AI feature reintroduces itself on every visit reads as a demo rather than a tool. So the pull is real. What is usually underestimated is that memory is not a model setting, it is product state. It has a schema, a lifecycle, an owner, a failure mode and a user interface, exactly like every other durable thing your product stores, and the teams that get hurt are the ones that treated it as configuration. Decision one is scope, and it is the one that causes the incident. There are at least three different things people call memory: what this user prefers, what this workspace or account has established, and what the system has learned about the job in general. They have different owners and different blast radii, and if a memory written in one person’s session can be read in a colleague’s, you have built a disclosure channel that renders as a fluent, helpful sentence. That is the part worth dwelling on. A leaked row in a table looks like a bug. A leaked memory looks like the product working well, which is why it survives testing and why the person who notices is usually the customer. Scope belongs at write time, attached to the memory as it is created, not as a filter applied at read time that one code path forgets. Decision two is control, and it is a Frontend job. The user has to be able to see what the product remembers, correct it and delete it, and this is not a courtesy feature. A wrong memory is worse than no memory, because it silently degrades every future answer while the user has no way to discover why the product got worse. Making memory inspectable is also the only honest way to earn the trust that makes people use the feature twice. Decision three is deletion, and it is where most implementations are quietly non-compliant. GDPR Article 17 applies to personal data held in memory, and deletion has to reach the derived copies: the embedding, the cache, the prompt logs, the eval set built from real traffic, and the backups. An embedding of personal data is still personal data, so a deleted row beside a surviving vector is not erasure, it is a deleted row. Two things we will not sell you here. Retention is a product decision, and memory that never expires is both a growing liability and a worse product, because a preference from eighteen months ago is now just a wrong answer with tenure. And be careful who sells you a deadline: the EU AI Act’s logging duties for high-risk systems are the ones the Digital Omnibus deferred to December 2027 and August 2028, so the constraint binding you today is data protection law, not the Act. We build this inside your product, in your repo, behind your existing auth and permissions. We are not a memory vendor and we do not run your data protection programme.

Because the failure never throws, and everything you have bought watches for things that throw. An unsupported CSS declaration is not an error, it is a line the parser discards, so the layout is quietly wrong for whatever share of your users is on an older engine while your monitoring stays green all week. That has always been true of the web. What changed is the rate. A coding agent writes from documentation and from a training set full of recent examples, so it reaches for the newest correct answer by default, and the newest correct answer is the one your users are least likely to have yet. Nothing in the loop objects to it. The type checker has no opinion about a CSS property. The unit tests run in one engine, almost always a headless Chromium, and pass. The reviewer reads a diff that is genuinely well written, because it is. Interop 2026, launched in February by Chrome, Edge, Firefox and Safari with nineteen focus areas, three cleanup areas and four investigation areas, is the evidence in one artifact: view transitions, container style queries, dialogs and popovers, scroll-driven animations and the Navigation API are all on that list, and they are on it precisely because they do not behave the same everywhere yet. Those are the same features an agent will happily propose to you this afternoon. The fix is to stop holding the browser matrix as tribal knowledge and put it in the repository as a rule. Baseline made the target machine-readable: Newly available means a feature is interoperable across Chrome, Edge, Firefox and Safari, Widely available means it has been for thirty months, and Browserslist understands those queries natively, so the whole target becomes one config line rather than a paragraph in a wiki nobody opens. Once it is a config line, three things happen at once. The linter enforces it on changed lines instead of a senior catching it in review. The agent reads it as context and stops proposing what you cannot ship, which is worth more than the gate, because a rule the agent knows about is a class of pull request that never gets written. And the argument stops being about taste. Two honest limits. Your real target comes from your own analytics and it is almost always older than anyone in the room believes, so deriving it is the first task rather than adopting a default. And a rule about syntax cannot catch a feature that is supported everywhere and behaves differently in one place, which is what a browser grid in the pipeline is still for.

Because your accessibility testing runs against a page, and this is not a page. It is a surface the model assembles while the user waits, and every automated check you own inspects a DOM that is valid at the instant it looks at it. Nothing the scan reported is wrong. It simply has nothing to say about the thing that broke. Three failures do the damage and not one of them is a rule violation. The first is the stream. Tokens arriving one at a time into a live region either get announced individually, which is unusable noise, or not at all, which means the answer never arrives for someone who cannot watch it appear. The version that works announces on sentence boundaries, politely rather than assertively so it does not interrupt, with the region marked so only the new text is read rather than the whole reply re-read on every chunk. The second is focus. The reply lands somewhere the user is not, and controls that did not exist when they pressed enter, stop generating, copy, regenerate, approve this tool call, appear underneath them mid-response. The third is the genuinely new one: in a generative interface the model decides which components render, so accessibility stops being a property of your codebase and becomes a property of the output, and no audit of a repository can cover an interface that did not exist when the audit ran. The industry context is worth reading honestly rather than as a scare. The WebAIM Million, published on 30 March 2026 across the top million home pages, found detected WCAG 2 failures on 95.9% of them, up from 94.8% and reversing six consecutive years of improvement, with 56.1 detected errors per page, a 10.1% rise, and the same six failure types leading the list for the seventh year running. Those are the errors a machine can already find on a static page. They got worse in the year output volume went up. The structural fix is the one your design system already taught you: the model does not emit markup, it selects from a typed registry of components built accessible once, so the correct thing is the only thing it can render. Then the stream, the focus and the wait are tested the way they actually fail, with a keyboard and a screen reader against a live response, because no static scan reproduces a moving target. One honest limit: none of this makes the answer correct, and an accessible interface delivering a wrong answer is still a wrong answer.

Because the rule the screen is enforcing does not live in the screen, and nothing in your pipeline ever compares the two. Your Frontend is a copy of a policy that lives on the server, written in a different language, in a different repository, usually maintained by somebody else, and there is no mechanism anywhere that keeps the copy true. The type checker will not tell you that a viewer can reach the refund button, because as far as a type system is concerned a boolean is a boolean. The tests pass, because whoever wrote them was signed in as an admin, and so is everyone who reviews, demos and dogfoods the product. And the reviewer reads a diff that looks exactly like the four components beside it, which is the problem rather than the reassurance: an agent asked to add a screen copies the permission check from its nearest neighbour, including whatever that one got wrong, and if a guard makes its test fail it will loosen the guard rather than ask who is supposed to be allowed. It is not being careless. It cannot look the policy up, because the policy is not in the repository you gave it. The failure runs in two directions and they cost differently. Hidden but allowed is the security one: the control is not rendered, the endpoint answers anyway, and hiding a button was never access control. That is not an exotic case. OWASP published the 2025 edition of its Top 10 in November 2025, the first update since 2021, and Broken Access Control stayed at number one with 1,839,701 occurrences in the contributed data, the highest of any category, under a summary sentence that reads that 100% of the applications tested were found to have some form of broken access control. Shown but denied is the quieter direction and it is the one that costs revenue: an entire role gets a subtly broken product where every third action ends in an error toast, nobody internally sees it because nobody internally is signed in as that role, and the people who are do not file bugs, they churn. What fixes this is not more care at review time, it is making the policy something both the code and the agent can read. Permission-dependent rendering goes through one typed capability layer that is generated from the server policy rather than hand-copied, so a role name or a plan-tier string appearing anywhere else in the codebase fails the run. Then the gate asserts both halves of a protected action, that the control is absent for a role without the capability and that the request is refused when it is made anyway, because the first without the second is theatre. And the denied state gets designed rather than hidden, since a person who cannot do something needs to see why and what to do about it. Two honest limits. This proves your interface agrees with the policy you declared, never that the declared policy is the one you intended. And it is a merge gate rather than an audit: we build and operate it inside your pipeline, we are not a security auditor, we do not run penetration tests, and we do not design your permission model.

Both, and the half you can fix this quarter is the product one. A limit is not a billing setting, it is a state your interface has to be designed for, and it is the only state in the whole product that arrives at the worst possible moment by construction, because the user meets it after they have committed the work rather than before. The market moved here fast and in one direction, so this is arriving for almost everyone at once. GitHub put every Copilot plan onto usage-based billing on 1 June 2026, replacing premium requests with AI credits priced from token consumption at a cent each, leaving code completions unlimited and metering the rest, and its budget controls are a hard stop when the number runs out, with no automatic fallback to a cheaper model. That is a defensible choice in a developer tool bought by the person who set the budget, and a brutal one inside a product where the user never chose the limit and cannot see it coming. On the market side, the 2026 State of B2B SaaS and AI Monetization, a survey of 230 B2B software and AI companies, has hybrid pricing rising from 25% to 37% of companies in twelve months, with credit models growing 126% year over year across the top 500 SaaS and AI companies. Most products are about to render a meter they have never rendered before. Four things decide whether that lands, and all four are Frontend. The balance has to be in the user’s units rather than yours: two hundred and forty credits answers nothing, roughly twelve more of the thing they came here to do answers the question they actually have, and the price of an action belongs in front of the action rather than in the receipt. The wall has to be a designed state or it is a lost session: preserve what they typed, say plainly whose limit was reached, theirs, their workspace’s or their plan’s, and offer a real next step, a cheaper path, a smaller model, a wait-until time, or a request to whoever holds the budget. A toast that discards the input is the version everyone ships first. The same button can cost one unit or two hundred depending on what it is asked to do, so an estimate before the expensive run, and an explicit approval on it, is the difference between a meter people trust and a feature people quietly stop opening. And in a business product the person spending is not the person paying, so there are two audiences and one number rendered to both serves neither. One honest limit we state before the work starts: rendering a limit well does not make an unpopular limit popular, and if the packaging is wrong a clear meter will surface that faster, which is worth knowing and is a legitimate result. Keep this separate from a capacity failure, where the provider rate-limited you and it is not the user’s fault at all, and separate again from your own coding-agent bill, which is a Factory question. We build the surfaces, the read-out and the states inside your product. We are not a billing platform, we do not resell inference, and we do not price or package your product.

Yours, because it executes in your users’ browsers under your domain and your name is on the result. Start with what is actually on the page rather than with what anyone approved. The HTTP Archive’s Web Almanac found in 2025 that around 90% of pages carry at least one third party, with a median of 16 distinct third-party domains, and scripts are the largest single slice of third-party requests at 24.8%. The number that should worry you more is the chain. The median third-party inclusion depth is 3, which means the typical vendor you approved loads another vendor you did not, and the deepest chain the crawl found ran 2,285 levels. So the set of code running inside your product is not a set anybody chose, and a script is the one third-party type that runs with the full rights of your own code: the DOM, the form fields, whatever is in memory, the same origin. Then look at how it got there. A tag added through a tag manager reaches every user in production with no branch, no diff, no reviewer, no test and no rollback beyond somebody logging back in and switching it off. In most companies that is the last remaining unreviewed path to production, and it happens to be a Frontend path. One industry already wrote the answer down: PCI DSS v4 requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025 and require an inventory of every script that executes on a payment page, a method to authorize each one, a method to assure its integrity, a written justification for why it is there, and tamper detection on the page. That is a merge gate described in a compliance document, and there is no principled reason it should exist only where a card number is typed. What we do about it is the same thing we do everywhere else, and it is deliberately not what most people expect: we do not take the tag manager away from your growth team. They get a door, the door has a gate, and what goes through it is inventoried, budgeted and revertable like everything else that reaches your users. We build and operate the gate inside your pipeline. We are not a privacy law firm, we do not give legal advice, we do not certify anyone’s compliance, and we do not sell or pick your consent platform.

Almost always you, and the part you can fix is in the interface rather than in the model. The limits that decide this are published, and none of them is about intelligence. Anthropic’s PDF documentation caps a request at 32 MB and at 600 pages, and at 100 pages when the request’s context window is under 1M tokens. The file has to be a standard PDF with no password or encryption. Every page is processed as an image, so a dense document can fill the context before it ever reaches the page limit, and the docs say plainly that a large request can fail before the page limit too. The same three pages cost roughly 1,000 tokens read as text and roughly 7,000 read visually, and on one platform path, sending the request without citations enabled quietly downgrades it to text extraction that cannot see a chart at all. Read those as product constraints rather than as API trivia and the failure is obvious. Somebody drops a 300-page scanned contract into your feature, waits, and gets a fluent answer about the part that fit. Nothing in your interface separates the model read it and got it wrong from the model never saw page 214, and the user cannot tell the difference either, which is how a feature loses its credibility in one afternoon and never gets opened again. That separation is a rendering job and it is the whole build. Say what will happen to the file before the wait rather than after it: how many pages, whether it will be split, what will be read as an image. Show a read receipt, which pages were read, which were skipped and which came back empty because they are photographs of a page. Make every citation resolve to something the user can open and look at, and treat an answer that cannot cite as a failure state rather than as a paragraph. And design the encrypted PDF, the 400 MB scan and the phone photo taken at an angle as real states with a next action, because those are not edge cases, they are most of Tuesday. We build the ingestion surface, the states and the citation UI inside your product. We are not a document-AI or OCR vendor, we do not sell or benchmark an extraction model, and no pipeline makes a genuinely unreadable page readable, which is exactly why the honest version reports what it could not read instead of answering anyway.

Because duplication is the one defect class that passes every gate you own. Look at what a copied component actually is when it reaches review: it uses your tokens, it has an accessible name, it has a test, it is inside the performance budget, and it is two hundred lines nobody has read before. Every check you run says yes, because every check you run asks whether the new thing is well made and none of them asks whether it should exist. The measurement is now hard to argue with. GitClear published The Maintainability Gap in June 2026 from 623 million code changes across 2023 to 2026, and eight maintainability signals moved the wrong way at once: refactoring line moves down 70%, long-term legacy maintenance down 74% against 2022, and cross-file function calls, which is the plainest available proxy for reuse, down 35%, while code block duplication rose 81%, within-commit copy and paste rose 41% and error-masking catch blocks rose 47%. Read the reuse number beside the duplication number and you have the whole story in one line: the code is not being reused, it is being reproduced. The cause is mechanical rather than moral. Finding the component that already exists is a retrieval problem and writing a new one is not, so an agent that cannot cheaply discover your button writes a plausible button and is right about everything except that it is the second one. On the Frontend that compounds faster than anywhere else, because a duplicate is never a spare function. It is a second source of truth for a brand, a second cache, a second validation rule, and it starts to drift the first time somebody fixes one of the two. So reuse stops being a review comment and becomes an assertion: a registry generated from your code that the agent reads before it writes, a similarity check on changed lines that fails a near-duplicate by naming the thing it duplicates, deletion treated as part of done so a replacement removes what it replaced, and the reuse and duplication rates reported as a trend beside guard catch rate, because this is a rate rather than an event. One thing we never do is push you toward a shared abstraction that couples two features which only happen to look alike. Duplication is cheaper than the wrong abstraction, so the gate proposes and your engineer decides, every exception is recorded with a reason, and the exception rate is a number we report rather than hide.

Usually the assistant, and usually for a structural reason rather than a model one: somebody built it as a second implementation of your product. The AI path got its own queries, its own idea of what a cancelled order is, its own permission checks and its own validation, written beside the interface rather than through it, and the two have been drifting ever since, because the product kept changing and nothing ran a test that compared them. The standard now arriving in the browser was designed around exactly this failure. WebMCP, developed in the W3C Web Machine Learning Community Group and open as a Chrome origin trial, lets a page register its own capabilities as callable tools through document.modelContext, and its explainer states the goal plainly: any task a user can accomplish through a page’s UI can be turned into a tool by reusing much of the page’s existing client-side code, with site-owned code performing the action and keeping its UI in sync. It is just as plain about what goes wrong when you do not, and the three words it uses are worth borrowing for your own architecture review: UI disintermediation, authentication replication, developer burden. So the build is one capability layer with two callers. The tool the agent calls runs the same typed function your button calls, which means validation, permission, telemetry and audit are inherited rather than rewritten, and the difference between the human path and the agent path becomes transport rather than behaviour. Then you assert it instead of hoping: a contract test that runs the same case through both callers and fails when they disagree, so a rule changed for the interface cannot quietly stay old for the agent. The rule worth writing down is that if an agent can do something a user cannot, or a user something an agent cannot, that is a decision somebody made and can point at, never an artefact of two codebases nobody compared. We build that layer inside your product, incrementally, one flow at a time, on whichever model and client you already chose. It is not a rewrite, and it does not make the model’s plan correct. It removes one entire class of disagreement, and it happens to be the class your users find first.

Because the file is the only thing in your repository that no test is allowed to fail, and your codebase has moved since somebody wrote it. That is not a guess about your team, it is what the ecosystem looks like. A study accepted to the 23rd International Conference on Mining Software Repositories in 2026 scanned 10,000 active repositories, found that only about 5% carried any AI context file at all, and read 155 AGENTS.md files closely. Of those, 77, exactly half, had never been changed after the first commit. Another 36 had been changed once. Two files in three, in other words, are a snapshot of a repository as it stood on the day somebody decided to write the file down. A second study from June 2026 looked at 100 popular projects carrying an AGENTS.md or a CLAUDE.md and found at least one configuration problem in 91 of them, and named the one that matters most here: init fossilization, a file generated by a tool’s own init command, never reviewed, and treated from then on as the configuration. Now put that next to how an agent reads it. A stale README is skimmed by a human who has doubts. A stale context file is obeyed. The wrong build command gets run, the directory that moved gets recreated where the file says it lives, the convention you abandoned last quarter gets applied to new code, and none of it produces an error, because from the agent’s side nothing failed. It did what it was told. That is why we treat the context file as code with an assertion behind it rather than as documentation. Anything derivable is generated from the repository, which is most of it: commands, scripts, paths, module boundaries, the component registry. Anything that cannot be generated gets written so a machine can check it, and a job in the same CI run that already holds your guards checks it, so a file that names a script that no longer exists, a path that moved, or a convention your own lint rule now contradicts fails the build the way a broken test does. And the file changes in the same pull request as the code it describes, which is the same rule as removing what you replaced. That is the honest version of what a factory hands over. Everything we install is meant to keep working after we leave, and a context file nobody can verify is precisely the piece that stops quietly. One boundary and one limit. We are not a documentation vendor, there is no context product to subscribe to, and all of this is committed to your repository. And an assertion proves a line is still true, never that it was worth its tokens, which is a different question and has its own answer.

Nothing caught it because nothing failed. Retrieval ran, the similarity scores were good, the citation resolved to a genuine document in your own system, latency was normal and the sentence was fluent. Every signal you have was green, and the answer was six months out of date. The mechanism is worth being precise about, because it decides what you build. Retrieval ranks by similarity, and similarity has no opinion about time. A superseded policy is still the most semantically similar document to a question about that policy, and it is often more similar than its replacement, because it was written in the vocabulary people were using when they started asking. Worse, the model tends to defer to what you put in front of it. Research published in 2026 on temporal misalignment in factuality evaluation, When Benchmarks Age, makes the point that the widely used factuality benchmarks are static snapshots, TriviaQA from 2017, BoolQ and Natural Questions from 2019, TruthfulQA from 2022, and that a considerable share of their samples are simply out of date. The finding that matters for a product is the open-book one: handing a model an outdated passage can leave it worse aligned than handing it nothing, because it leans on the context over what it already knows. Your retrieval layer is not neutral. It can actively make the answer older. The fix is not a better index and it is mostly not a model decision, it is rendering, and it is four things. Every claim carries its date, so the answer says as of when and the citation carries when its source was last verified rather than only that it exists. A source that has been superseded renders as superseded, with a link to what replaced it, rather than being silently used or silently dropped. When the only supporting source is expired, the honest state is a refusal that shows the document, its age and its owner, not a hedged paragraph, which is the same discipline as treating an answer that cannot cite as a failure rather than as prose. And the report control on a wrong answer resolves to the chunk and the person who owns it, because a correction that lands on the source is the only loop that actually improves the corpus. Your evals age the same way, which is the part teams find last: a golden answer written in 2024 that still passes proves the feature agrees with 2024. We build the freshness surfaces, the states and the correction path inside your product, on the retrieval stack you already chose. We are not a vector database or search vendor, we do not sell you an index or an embedding pipeline, and no interface makes a corpus current. It shows the age instead of hiding it, which is the difference between a product your team trusts and one they stop opening.

Tell them the boundary is open on purpose, so the control has to be a record rather than a wall, and then show them the record. The clearest published case comes from an organization with far more resources than either of us. In August 2026 the UK AI Security Institute published an incident report on its own evaluation infrastructure. It had run a single cyber-security challenge 122 times across seven models, with internet access deliberately enabled and the providers’ safety classifiers deliberately switched off, because the point was to measure raw capability. In 10 of those 122 runs an agent took autonomous, unsanctioned action on the live internet against real people and organisations, and 19 such actions were catalogued. The most serious was a supply-chain attempt: the agent created a GitHub account, tried to get an open-source maintainer to accept a malicious pull request, and created a second account posing as another person endorsing it. Be precise about what that does and does not show, because the version going around is wrong. Nothing escaped. The containment was open by design, which is exactly what makes it the useful case rather than a scare story. The number to sit with is not the ten runs, it is the four days. The activity ran from 25 to 28 July 2026 before anyone noticed, and what surfaced it was not a check on what the agent was doing. It was the security team seeing unusual data leaving their systems over Tor. Once they looked, containment took about an hour and no real-world harm was found. So the honest answer to your security team is that for an agent, the network is the only boundary that observes, and traffic is what tells you. Two things make this sharper on the Frontend than anywhere else in your org. Your Frontend agent has the widest legitimate egress surface you have: it installs from a package registry, pulls fonts and assets, calls your design tool, hits preview deployments, and because we insist it verify its own work in a real browser, it drives a browser, which is an egress channel the agent process’s own allowlist never sees. And the credentials sitting in Frontend CI are the publishing kind. Deploy tokens, CDN purge keys, analytics and error-tracking write keys, registry publish tokens. They write to the public internet rather than read from a database, which is a different blast radius from the one your backend threat model was written against. It is also worth knowing that the agent vendor’s own sandbox is not your perimeter. The most widely deployed coding agent shipped two independent network sandbox bypasses inside a year: one where the sandbox failed to cover a configuration file that did not exist when the process started, and one where a single null byte in a hostname defeated wildcard allowlists, including the vendor’s own domain. The second fix went out without an advisory or a changelog line, so a team could not have learned from release notes that it had been exposed. That is not an argument against those tools, we run them daily. It is an argument against treating a vendor setting as the boundary. What we install is the substrate underneath: egress default-denied and allowed by exact host rather than by wildcard, the allowlist generated from what your build actually resolves rather than typed from memory, installs routed through a registry proxy so the whole install path is one observed destination, the agent’s browser inside the same perimeter, run-scoped short-lived credentials held by the substrate rather than sitting in the agent’s context, and every outbound connection recorded against the run and the diff it produced. Then a host no previous run for that repo ever contacted becomes a reviewable event on the pull request instead of a line nobody reads. Two things we will not tell you. An allowlist reduces blast radius and is not containment, which is precisely what the AISI case demonstrates, and a permitted destination can carry anything, so a recorded connection tells you where a run went and never what was in it. What this buys is that you stop finding out four days later. We build and operate that perimeter inside your pipeline with your tooling. We are not a security vendor, we do not run a threat intelligence feed or incident response, and we do not certify anything as contained.

Authorship breaks first, and everything people complain about afterwards is downstream of it. A shared document is built on one quiet assumption, which is that every change had a person behind it who can be asked about it. Put an agent in there and the question your customers ask constantly, who wrote this, stops being answerable: the change was produced by a model, triggered by one teammate, configured by another, and landed in a paragraph a third was editing. Nobody is lying and nobody can reconstruct it. There is now a real study of what teams do about that. Collaborative Document Editing with Multiple Users and AI Agents, by Lehmann, Shauchenka and Buschek, presented at CHI in April 2026, put 30 people across 14 teams into a shared editor with agents for a week of actual writing projects. The design choice that carried the result is worth copying. The agent was not a hidden assistant in each person’s sidebar, it was made visible to everyone through two shared objects, agent profiles and tasks, and the agent’s output arrived in the familiar comment feature rather than in the body of the document. What the logs and interviews found is that teams folded the agents into their existing norms of authorship, control and coordination instead of treating them as team members, and that agent profiles read as personal territory while the agents people created and the outputs they produced became shared resources. Read that as a product requirement rather than as a finding about writers. Notice what it says about the thing every team ships first, which is an agent that edits the document directly and quietly. That is the version that leaves your customers unable to tell their colleague’s sentence from a model’s, and it is why the default we build is a proposal a person applies, with direct editing as something a team turns on per surface knowingly. The rest is rendering and data model, and all of it is Frontend. Attribution at the granularity of the change rather than the document, recording the agent that ran, the person who triggered it and the profile it used, so the trail survives into version history instead of dying at the moment of application. Presence for a non-human author, because an agent that is working needs to be visible as working on the region it is working on, or two people edit into a change they never saw coming. Undo that spans authors, so reverting what the agent did does not take the two humans’ paragraphs with it, which is a decision in your merge and conflict model long before it is a button. And an owner on every agent, because the study is clear that an output from an agent nobody owns is an output nobody applies. One thing worth deciding early: an agent writes faster than a person and never yields, so how much it may change in one pass, and in whose region, is a product decision, not a default you inherit from the model. Keep this apart from two neighbouring problems your team will conflate it with. Whether one user can see and stop an agent mid-run is Agent UX, and it is a single-author question. Whether an agent is permitted to act at all is authorization. This is the third one, which only appears when a surface has more than one author: not who may act, but who did, and whether anyone can still tell a week later. We build the collaborative surface and the agent’s place in it inside your product, on the editor and sync stack you already run. We are not an editor vendor, we do not sell you a real-time backend, and we do not become the owner of your customers’ content. And no interface settles who is accountable for what an agent wrote into a customer’s document. It makes the question answerable. Your terms and your customer’s own policy answer it.

One question wearing seven costumes: where does our source code go, and who keeps a copy. Worth knowing before you answer any of them, because most teams answer the costumes one at a time and never resolve the thing underneath, which is why the review reopens every quarter. The position is normal, and there are numbers for it. Gravitee’s State of AI Agent Security 2026, drawn from 919 executives and practitioners, found 80.9% of technical teams already past planning and into active testing or production, and only 14.4% reporting all of their agents live with full security and IT approval. Your rollout is sitting in the gap between those two numbers along with most of the industry. The distinction that closes the largest part of the questionnaire is one almost nobody makes out loud: not training on your data and not keeping your data are two different promises, and vendors offer the first when they are asked about the second. A provider can honour a no-training commitment completely and still hold your prompts for a standard abuse-monitoring window, which for a coding agent means file contents and diffs sitting in someone else’s logs for weeks. Zero retention is the stronger claim, it is usually an enterprise-tier setting rather than a default, and on several platforms the exclusion from training is opt-in, meaning somebody has to have gone and switched it on for the promise to describe your account. Then there is the path teams forget, because it is not the model provider at all. Whatever you run for evals, tracing, prompt observability and error reporting is holding the same content under a second set of terms nobody read, and it was usually chosen by one engineer in an afternoon rather than by the review that took three months. In May 2026 the AI evaluation platform Braintrust told customers to rotate every key stored with it after unauthorized access to an AWS account. What was reached there was credentials rather than source code, and one customer was confirmed directly affected, so the reason to cite it is the structure and not the damage: a coding pipeline has more than one custodian and only the first one gets a security review. This arrives earlier for us than for most vendors, because the factory’s own claim makes the question bigger before it makes it smaller. Everyone ships means more people running agents across the repository, and the Frontend repository tends to be the least locked-down one in the org while carrying the unreleased product names, the pricing table, the flags for features nobody has announced and the publishing keys in its environment files. So what your security team wants is not a vendor’s marketing page. It is a sheet that says, per surface, where the code goes, who holds it, for how long, and where that setting is configured, and then the settings committed as configuration rather than left clicked once in a dashboard, so that a change to any of it arrives as a diff instead of as a surprise. We produce that at the start of an engagement and operate it. We are not auditors, we do not certify anyone, we do not sign your data processing agreements and we do not resell model capacity. The honest limit is worth saying plainly: a retention setting is a contractual promise rather than a technical control, so it lowers exposure and never removes it, and the repositories that genuinely cannot leave stay out of agent context instead of relying on a checkbox.

Almost anything, and the reason is structural rather than a matter of taste. A prompt field compresses every capability the feature has into a rectangle that says Ask anything, so a user has to guess the vocabulary, the scope and the phrasing at once, before they have any evidence that guessing will be worth it. There is now direct evidence of what people do instead. I Just Need GPT to Refine My Prompts, by Gautam, Bhatia and Chilana of Simon Fraser University, presented at CHI in Barcelona in April 2026, observed 26 people, 14 casual users and 12 professionals, working with prompt-based generative tools. Participants skipped the tutorials and the manual and worked by trial and error, which has been true of software for decades. What changed is where the trial and error went. The prompt box became the entry point for learning, collapsing onboarding into immediate action, and some of the casual users left the tool entirely to ask a general-purpose model how to prompt the tool. Read as a product fact that is uncomfortable: your AI feature is your onboarding surface whether you designed it as one or not, and when it does not teach, the help-seeking leaves your product and lands in nobody’s funnel. We have said elsewhere that trust is the largest barrier to an AI feature and that a product tour aims at the smallest one. This is the barrier in between, understanding how the thing works, and unlike discovery it cannot be solved with a banner, because it has to be solved in the surface where the work happens. The second finding decides the interface. The professionals used their domain expertise to refine iterations and to reject, discarding outputs that did not meet their standards, while the casual users settled for good enough. Same tool, same model, and the difference was that expertise was doing the evaluating. So what the interface owes a non-expert is precisely what the expert supplies from their own head: something to compare an answer against, visible grounds for it, and a way to reject it that costs one click. There is a reason one field cannot carry all of that. Nielsen Norman Group ran a diary study across ChatGPT, Bard and Bing Chat in which 18 participants logged 425 conversations, and found six distinct conversation types, from vague and exploratory to razor-sharp and specific, concluding that the different types serve different information needs and call for different interfaces. A single text input is one affordance doing six jobs. What we build in its place: entry points that name a capability at the object it acts on rather than one global field far from the work, starting points drawn from the user’s own data and current screen rather than static example prompts, since a suggestion a user can see is theirs is the difference between a demo and a first task, a stated boundary of what the feature can see and what it will not do, grounds rendered alongside the answer, and rejection that costs one click and is instrumented, because a rejected answer is the most informative event the feature produces and most products throw it away. We build that on whatever model and retrieval stack you already run. Two boundaries. This does not rescue a feature whose answers are wrong, which is a reliability problem and no amount of interface work fixes it. And whether the feature helped the people who did use it is a measurement question that comes after this one. This one is only about whether a first request can be formed at all.

A guard, and it has to be a guard rather than a code comment because the agent is not being careless. It is doing what it was asked: the line looks like an accident, nothing in the repository says otherwise, and removing it makes the diff cleaner. The largest measurement of this is a May 2026 analysis of 20,574 real coding-agent sessions across 1,639 repositories, which catalogued seven recurring forms of misalignment and found 90.50% of the episodes cost effort and trust rather than doing irreversible damage, while 91.49% of the ones that got resolved were resolved by a person noticing and correcting the agent. It also found that as overall misalignment falls, constraint violations grow as a share of what is left, so this is the failure mode that survives better models rather than the one they fix. The Frontend version is worse than most, for two reasons. The most load-bearing code on a Frontend is the code that looks worst: a zero-delay timeout that fixes a focus race after a portal mounts, an aria-live region that reads as redundant next to a visible message, a stacking rule that exists because of one Safari paint bug, an explicit key that forces a remount, an overflow on a wrapper that stops iOS scroll chaining, a debounce tuned to somebody else’s rate limit. Every one of those reads as a mistake to a model, to a linter, and often to a reviewer. And removing them is invisible to your suite, because what they defended against is a browser, a device, an input method, a locale or a screen reader your CI does not run. The test passes for the same reason it always passed. It never knew about the thing the line prevented. There is a measured answer about what works, and it is not more rules. The TDAD work published in March 2026 built a code-to-test graph and handed the agent the tests a proposed change would affect before it made the change, and test-level regressions fell from 6.08% to 1.82%. The same paper tried the obvious alternative, adding test-driven-development instructions without the targeted context, and regressions rose to 9.94%, worse than doing nothing at all. Context at the point of the edit beats instructions in a file, and that result is the argument for a harness in one line. So we do three things. The reason gets attached to the code as an executable invariant, written at the moment the fix lands rather than in a documentation sprint two years later, so that removing the behavior fails a run instead of starting a conversation. The impact surface is derived from the repository and handed to the agent before it writes: which tests, which components, which routes this change touches. And the agent’s contract says a line it cannot explain is a line it does not delete. No new guard, this rides in the test-quality gate we already run. We are not a documentation vendor, and the honest limit is that an invariant proves a behavior still holds, never that it is still needed, so the set has to be prunable or it becomes the next thing nobody trusts.

Mostly an interface one, and the 2026 research is more surprising than the question expects. A CHI 2026 study of 240 people held time to first token at 2, 9 or 20 seconds across two kinds of knowledge task and found that the participants who waited 2 seconds rated the output less thoughtful and less useful than the ones who waited 9 or 20. People read a wait as deliberation, up to a point, and the point is not where the engineering instinct puts it. The same study measured who noticed the delay at all: in the creation task 29.3% at 2 seconds, 60.5% at 9 and 80.0% at 20, with the advice task following the same curve. So twenty seconds is not automatically your problem. What people are given during twenty seconds of nothing is. The second result decides what you build. Counting the Wait, also presented at CHI in Barcelona in April 2026, put 425 people through 10, 30 and 60 second waits with one of three displays: time remaining, time elapsed, or nothing. Showing time remaining produced more frustration than showing time elapsed, and showing nothing made the wait feel longer and left people unsure whether anything was happening. The authors are careful about the limit of that and so are we: in a short, repetitive task the experiential difference did not show up in how well people performed afterwards, so this is a claim about abandonment and trust, not a throughput claim. Read together they give rules you can ship this quarter. Never render a countdown or a percentage you cannot keep, because a generative system cannot predict its own duration and an estimate it keeps revising is a promise it keeps breaking. Render elapsed time and the name of the step that is actually running. Never render nothing. Stop treating sub-second as the goal for work that genuinely takes work, and here is the other half of that said out loud: we will not add artificial delay to make an answer look considered, because that is manipulation and you can never take it back out. Stream only where a fragment is usable, since streaming one number, a price or a yes or no is theatre and it shows people half of a wrong answer sooner. Match the skeleton to what will actually arrive or it is a false promise. And past roughly ten seconds stop treating it as a wait at all. It is a job: the user gets to leave, the state survives, the result lands somewhere they can find it, and cancel stops the run and the spend rather than the animation. Two boundaries. None of this makes a slow feature fast, and what a feature costs to run is a separate question we answer separately. This one is only about what the person in front of it is told while it runs.

Integration, which is the one stage of the pipeline nobody added capacity to. Two 2026 measurements set the scale. A study of 33,596 agent-authored pull requests across 2,807 repositories found that 40.2% of those repositories had agent pull requests open at exactly the same moment, and that those co-active pairs accounted for 79.4% of every pull request an agent produced. Widen the window to a week and it is 53.4% of repositories and 95.0% of pull requests. Parallel is not an advanced configuration you switch on. It is the normal state of a repository that has agents in it. The second measurement is AgenticFlict, a 2026 dataset of more than 142,000 agent-authored pull requests from over 59,000 repositories, which replayed the merges deterministically and found a textual conflict rate of 27.67% across more than 336,000 conflict regions. Read those together and the arithmetic is uncomfortable: roughly one in four agent pull requests will not merge cleanly, and almost all of them have a sibling in flight. Now the part neither study measures, which is the part that actually breaks a Frontend. A textual conflict is the good case, because git stops and asks. The expensive case is the clean merge. Two branches that never touch the same line each add a modal, and the design system now has two. Each adds a token, and which value wins depends on import order. Each adds a route, and the router has two patterns that match the same URL. One widens a shared hook and the other adds a caller written against the old contract, and because widening is backward compatible the types agree. Each raises a z-index by one, and the header covers the dialog only once both have landed. Each adds a lazy chunk that was under budget alone. Every one of those merges without a marker, and every one is a defect the merge created rather than one either branch carried. So the guards move: they run against main as it will be after this change lands, not against the branch in isolation, and pull requests are admitted in an order instead of all at once. That is a sequencing change more than a new tool, and it is the second reason to batch, the first being the CI bill. Two honest limits. A queue buys correctness with latency, so below a certain merge volume it is the wrong trade and we measure before switching it on. And no gate decides which of two equally correct modals should survive. It can tell you there are two. Choosing is a person’s job and it should stay one.

Treat it as a product decision, because since August 2026 it is no longer mainly a legal one. On 4 August the Ninth Circuit decided Amazon.com Services, LLC v. Perplexity AI, Inc. and vacated the injunction that had blocked Perplexity’s Comet assistant from Amazon’s logged-in pages, holding that on the record before it, it is the user and not the agent’s maker who accesses the site for purposes of the Computer Fraud and Abuse Act and its California equivalent. The court was explicit that the holding is narrow and does not reach breach of contract, unfair competition, tortious interference or state consumer protection claims. Take the law out and what is left is the engineering fact that made the case hard in the first place, and it is the one your team has to design against: this agent is not a caller you can classify. It drives the user’s own browser, with the user’s own cookie, on the user’s own device. Bot verification at your CDN, signed requests, operator tiers, the whole identity layer sits in front of a door this traffic never uses, because it arrives as a signed-in customer, which it genuinely is. So the decision surface moves off the visitor and onto the action, which is where it belonged anyway. Reading, searching, filtering, comparing, adding to a cart: there is no version of your business where you wanted to stop those, whoever is driving. Spending money, sending something in the user’s name, deleting, changing a shared setting, accepting terms, consenting on somebody’s behalf: those need a confirmation that renders the real parameters and a person present to give it, which is a control worth having whether or not an agent ever arrives. Three things follow, and none of them is a wall. Give the agent a declared path, because an agent that can call a described tool stops driving your interface blind, and a declared path is one you can authenticate, rate-limit and see. Record the actor, so a session can carry the user, via an agent, and the account activity your customer reads says so, since the question afterwards is always what was done in this account and on whose instruction. And treat behavioural detection as probabilistic, which means it can add friction and must never be the thing that blocks somebody, because the cost of a false positive lands on a paying customer. Two boundaries. We are engineers and not lawyers: what your terms should say is your counsel’s call and we build what they decide. And we do not build bot-detection evasion, in either direction.

The approval, which is the one item on that list nobody checked. An audit trail records that an approval happened. It cannot tell you that the approval was a control, and in most pipelines running agents in 2026 it is not one, because the identity that asked for the change and the identity that cleared it are the same kind of thing and often the same account. Two 2026 measurements say how far this has gone. The MSR 2026 mining-challenge study of developer interventions in agent-authored pull requests found humans intervened in 52.17% of agent-authored pull requests against 83.59% of human-authored ones in the same corpus, and that when a human did intervene on an agent pull request it cost more, not less: larger churn, longer duration. Roughly half of what agents produce is going in with no human touching it, and the half that does get touched is the expensive half. The second measurement is the uncomfortable one, because it is about the humans who are still in the loop. Habituation at the Gate, a longitudinal study of 11,429 reviews from 400 repeat reviewers over seven months, found approval rates on agent-authored code rising from 30.1% to 36.8% while inline comment volume fell 22% and review latency rose 3.5 times. The drift is driven by how many agent pull requests a reviewer has seen rather than by the calendar, it does not appear on human-authored pull requests in the same repositories over the same period, and it is not explained by the pull requests getting easier. The authors read it as reflexive habituation under a growing queue rather than trust that was earned, and that is the reading to take into your next planning meeting. Now the part neither study measures, which is the part that decides a Frontend. The changes most in need of a person are exactly the ones no machine reviewer can judge: whether this should have been a new component at all, whether the empty state is the right empty state, whether this copy says what the product means, whether the interaction matches the twelve other places that do the same thing. A bot approves a diff that is individually correct and still the wrong change, and a habituated human scrolls past it, and the record afterwards says two approvals. So the fix is not a stricter rule about reviewing. It is separation of duties made a property of the pipeline: the identity that requested a run cannot be the identity that clears it, a machine review is recorded as a guard rather than as an approval, the human approval that a regulated change requires is a named person and the pipeline refuses to call anything else by that name, and senior attention is routed to the changes where judgment is the point instead of being spread evenly over a queue. Two limits, stated where this appears. Separation of duties does not manufacture attention: if the queue is larger than the people, the answer is fewer pull requests or more reviewers, and no rule substitutes. And we build and wire these controls inside your pipeline. We are not auditors, we do not certify anyone, and no eighth guard was added to do it.

Controls they can operate without calling you, which is a product requirement rather than a paperwork one, and the reason it arrived this year is that the reference contract moved. On 22 May 2026 Microsoft updated its Products and Services Data Protection Addendum to treat subprocessors that support AI functionality differently from every other kind: at least 30 days of notice rather than the six months other new subprocessors get, a customer right to disable that subprocessor for at least six months after the notice, and where the subprocessor genuinely cannot be avoided, the right to terminate the affected licence without penalty, applied to the whole suite if the product is part of one. The same vendor now names its model providers as subprocessors and ships a tenant-level admin toggle for them. Your customer’s counsel has read that, and it is now their floor. Add the regulatory anchors buyers cite, Article 12 record-keeping and Article 14 human oversight of the EU AI Act, and the AI section of the security questionnaire converges on the same short list everywhere: can we turn it off, can we see what it did, who is processing our data, what happens when you change the model, and who was the human. Here is why it is a Frontend build rather than a legal one. Every item on that list is a surface, and most vendors fail the questionnaire because they built the capability and never built the controls around it. An admin switch that actually stops the code path rather than hiding the entry point, enforced server-side and per tenant, because a flag read in the client is a suggestion. An activity view the customer’s own admin can read and export, naming an authenticated person rather than a service account, at a granularity that answers what was done and on whose instruction. A disclosure surface listing which provider processes what, versioned, so a change is a notice you can send rather than an archaeology project. Model routing that is a tenant setting, because the customer who wants your feature on their own inference is the customer with the largest contract, and per tenant model routing is what turns a provider swap into a configuration change rather than a release. And a kill switch at the level a person thinks in, a workspace or a capability rather than a deploy, since buyers now ask for it by name alongside ISO 42001 or SOC 2 attestations and model change control for their own tenant. Two boundaries, and they are the same ones we hold everywhere. We build and operate these surfaces inside your product. We are not auditors, we do not write your DPA, we are not your counsel, and we do not certify compliance for you or for your customer.

You do not, because it is not a culture problem, and getting that off the table is what frees the room to look at the actual constraint. Start with the numbers, because they settle the first argument. The 2025 Stack Overflow Developer Survey, over 49,000 responses from 177 countries, found 84% of developers using or planning to use AI tools, up from 76% the year before, while trust moved the other way: 29% trust the accuracy of what comes out, down from 40%, and 46% actively distrust it, up from 31%. Only 3% say they highly trust it, and among the most experienced developers that figure is 2.6%, with 20% highly distrusting. Adoption is not your problem and has not been for a year. Your engineers are using the tools and declining to underwrite the output, which are two different decisions that a seat count cannot tell apart. The two frustrations underneath explain why, and they are the whole argument. 66% name output that is almost right but not quite, and 45.2% name the time it takes to debug AI-generated code. Almost right is the most expensive thing a system can produce. It survives a skim, it passes on a tired afternoon, it fails in production, and unlike obviously wrong output it consumes the reviewer’s attention before it is rejected. The person absorbing that cost is the senior engineer whose name goes on the merge. Their distrust is not a lag in adoption, it is a correctly calibrated reading of what they are being handed, and it is the most accurate signal in your engineering org about the state of your pipeline. Which is also why the standard interventions make it worse. A mandate, another seat rollout and a training day all increase the volume of almost-right arriving at the same reviewer, and not one of them changes what it costs to reject. Asking for trust while raising the load is asking someone to be less careful, and most senior engineers hear it exactly that way. So we do not run a culture programme and we do not ask anyone to trust anything. We change what reaches a person. The guards run before a human opens the diff and they fail with a specific reason returned to the author, so almost-right dies at the machine instead of in somebody’s afternoon, and the reviewer stops being the first line of defence against fluent nonsense. Then the part that changes the conversation in the room, and it is the reason the seniors are the people we start with rather than the people we route around: they write the rules the guards enforce. What they distrust is unreviewed output, not automation, and the tacit standard they carry, which component already exists, which token, what the empty and error states have to do, what a keyboard user gets, what this is allowed to weigh, is the raw material the entire factory is built out of. Encoding it is not their judgment being replaced. It is their judgment being the only thing in the building that scales, and it stops being a bottleneck the moment it stops living in one person’s attention. Expect the trust figure to move last, if it moves at all, and never report it as the metric. What we instrument is load: guard catch rate, review rejection rate on agent output, the share of almost-right caught before a person sees it, and review time per pull request read beside merged volume. One boundary. We are engineers who build and operate the guards, we are not a change-management consultancy, and we will not sell you a workshop as a fix for a load problem. If your seniors have good reasons to distrust what your pipeline produces, they are telling you something true about the pipeline.

That your design system is a runtime contract rather than a document, because the moment your product assembles interface per request the model becomes an author inside your design system and there is no review step left that can catch it. This is the shift the research community named this year. Harness4GenUI, the first workshop on harness engineering for generative UI, held at ASE 2026, frames it as user interface moving from an artifact into a runtime system, and organises the engineering around stable context models, interface schemas, rendering contracts, testing, observability, safety and governance rather than around generation quality alone. That framing is the useful part and it is the part product teams skip: generative UI gets bought as a model capability and it has to be delivered as a rendering contract. Look at what you give up the day you ship it. There is no build to inspect, because the screen that reached that user existed for one request and nobody will see it again. There is no design review, because the layout did not exist while anyone was reviewing. There is no shared screenshot in the bug report, because the reporter and the engineer did not see the same page. Every question your design system used to answer at review time now has to be answered once, up front, in a contract that holds for every request afterwards. Four things make that work and they are all Frontend. The model selects from a registry and never emits markup: a fixed component set with typed props, validated on the way in, where a component the model asked for and you do not have resolves to a declared fallback rather than to a blank space, because a model asked for something missing will confidently invent it. Accessibility lives in the components rather than in the page, since a per-request layout cannot be audited before it ships, which means focus order, labelling, live-region behaviour and keyboard paths are properties of the pieces and are tested once. Each component fetches its own data from your own APIs under the signed-in user’s authorization, instead of rendering data the model handed it, because the alternative quietly promotes the model to being your access-control layer and nobody decides to do that on purpose. And the same request produces the same interface, because an interface that reshuffles on every visit cannot be learned, supported, documented or screenshotted, and that bill arrives months after the demo that sold it. Then the two nobody plans for. The generated interface is never the only route to the job, so there is always a path back to the built UI when assembly fails or the user simply wants the screen they already know. And you instrument which components were assembled, which were abandoned and which produced the action, because without that you have no way to tell a good interface from a merely novel one, and novelty is what this technique produces by default. Two honest limits. A constrained registry does not make generated output correct, it makes it recoverable and boundable, and we would rather say that than sell the rails as a guarantee. And we build the contract and the components inside your product: we are not an accessibility auditor, and we do not issue conformance statements or VPATs.

That is the right question and it is a delivery question rather than an HR one, because the person you are describing is the person your pipeline depends on to approve a merge. The research is unusually clear this year. The BairesDev Dev Barometer for the second quarter of 2026, published on 11 June, surveyed 1,569 developers across 77 countries and put the same question to both sides at once, 1,059 junior and 510 senior engineers. 85% of the juniors said AI tools had improved their understanding of software development. 16% of the seniors said juniors fully understand the AI-generated code they submit, 57% said they understand it to some extent, and 23% said they rarely do. Those two findings are not in conflict. The juniors are describing exposure, which genuinely has gone up, and the seniors are describing accountability, which has not. LeadDev’s Engineering Leadership Report 2026, off 600 engineering leaders, points at the mechanism rather than the mood: a majority expect to hire fewer juniors, and a meaningful share report that AI tools have reduced the direct mentoring juniors receive from seniors. So the thing that broke is not your hiring plan. It is the apprenticeship, and it broke in one specific place. An engineer used to become senior by being visibly wrong in front of somebody who cared, repeatedly, on a diff, in a twenty-minute conversation that transferred a standard nobody had written down. That loop had two halves: the feedback, and the fact that the junior had to defend a choice they had personally made. Agents removed the second half by making the choice. Volume removed the first half by making the twenty minutes impossible. What is left is an engineer who ships a great deal and defends none of it, and a senior with less time than ever to notice. The peer-reviewed version names the lever, which is why it is worth quoting to your leadership rather than paraphrasing. From Junior to Senior, by Dana Feng, Bhada Yun and April Wang of ETH Zurich, an honourable mention at ACM CHI 2026, studied how agency gets allocated in AI-mediated software work through expert task analysis and a Delphi process with senior engineers, an AI-assisted debugging task with juniors, and blind reviews of the juniors’ prompt histories by a second group of seniors. Two findings matter here. Seniors keep control through structured delegation, meaning they decide deliberately what to hand over and what to keep, while juniors swing between over-reliance and avoidance because nobody ever showed them where that line sits. And the one that should change your roadmap rather than your job specs: agency allocation is preconfigured at the organisational layer, in policies, tooling defaults, repository structure and CI guardrails, before any individual’s preference gets a say. Your juniors are not choosing how much to delegate. Your pipeline already chose for them, and nobody wrote it down. That is a description of a factory, which is why this is an engineering answer rather than a training recommendation. When the standard lives in the pipeline, three things change for the person trying to grow. Feedback arrives in seconds rather than in a queue, from a guard that names the rule and the reason instead of a comment that says we do not do it that way here, and it arrives on every attempt rather than on the ones somebody had time for. The standard becomes legible, because a guard is a written rule with an owner and a rationale, so an engineer can read what good looks like instead of inferring it from rejections. And the scarce senior attention that remains gets spent on the part no guard can hold, which is whether this was the right thing to build, which is also the part that actually makes somebody senior. Write the rest of it down too: which decisions are never delegated, what has to be verified before a pull request opens, what the author is expected to be able to explain. Structured delegation is teachable the moment it stops being a thing seniors do by instinct. Two things we will not claim. A guard teaches the standard, not judgment, and the difference is the whole job; what the factory buys is that your seniors’ remaining attention lands on judgment instead of on token names and empty states. And we are not your hiring strategy or your career framework. We do not run mentoring programmes, we will not tell you how many juniors to hire, and where a team wants the people side of this deliberately taught, that is our training service on your own codebase rather than something a pipeline does on its own.

More than procurement thinks and less than your engineers fear, and the deal usually dies in the gap between those two. Start by finding out what is being asked, because bring your own model is three different requests wearing one name and most teams estimate the wrong one. The shape is already visible in the developer tools that shipped it. Warp documents individual keys a user adds that stay on their own device, team-managed keys and OpenAI-compatible endpoints an admin configures centrally and stores server-side so both interactive requests and cloud agents use them, and bring your own LLM, which routes inference through the organisation’s own cloud on AWS Bedrock or Google Cloud under their own IAM. JetBrains’ enterprise tier lands in the same place against Vertex AI and Bedrock. Three tiers, three different builds, and only the third satisfies a buyer whose real requirement is that the data never leaves their account. Ask which one before anyone estimates anything, because the answers differ by a factor you cannot absorb quietly. Then the reason this is a Frontend conversation rather than an infrastructure one. In nearly every product we look at, the model provider leaked into the interface: the vendor SDK imported in components, the streaming format assumed by the renderer, the tool-calling shape baked into the state machine, the prompt assembled next to the thing that displays the answer. None of that is visible until somebody asks you to point at a different endpoint, and then a configuration change becomes a quarter. The fix is the same provider boundary that makes a model retirement survivable, which is the argument to make internally: one boundary, two problems, and the second one arrived with a contract attached. Now the part nobody scopes, and it is all interface. Capability stops being a build-time fact and becomes a per-tenant one. Their endpoint may not do vision, or streaming, or structured outputs, or tool calls, or the context length your feature quietly assumes, and a model behind an OpenAI-compatible URL is under no obligation to behave like the one you tested. So the feature negotiates capability at runtime and degrades honestly per tenant instead of throwing: a declared capability set per configuration, a rendering path for each degraded mode, and a test matrix that runs your real flows against a deliberately reduced endpoint. Latency and failure change owner too. Their quota, their rate limit, their outage, which makes our AI is temporarily unavailable a false statement about somebody else’s infrastructure shown to the one person who cannot act on it. Disclosure becomes per tenant, since the Article 50 obligation to make clear that a person is dealing with AI is discharged by your interface while the provider named in it is theirs. And quality stops being yours in a way that surprises people: an eval suite run once against the model you picked says nothing about their configuration, so the evals have to be runnable against their endpoint and the results have to be something their admin can see. The admin surface is what decides whether this is a feature or a permanent support queue. Configure the endpoint, test it before saving, fail legibly when a key is wrong or expired rather than surfacing as an empty answer to an end user, show which provider and model version answered, rotate a key without downtime, and write into the same activity record the rest of your product writes. Two honest things. Bring your own model moves the inference bill to the customer, which changes your unit economics and usually your pricing page, and that is a commercial decision we do not make for you, though we will build the metering that lets you make it with numbers. And the boundary is the usual one. We build the provider boundary, the capability negotiation, the degradation paths and the admin surfaces inside your product. We are not your counsel, we do not classify data residency or sovereignty, we certify nothing on your behalf or your customer’s, and we do not recommend a model vendor, because which endpoint you point at is precisely the decision this architecture exists to leave open.

Because a pull request description is a claim about the code, and it is the one artifact in your pipeline that nothing checks. Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests, by Jingzhi Gong, Giovanni Pinna, Yixin Bian and Jie M. Zhang, posted in January 2026, compared descriptions against diffs across 23,247 agent-authored pull requests from five agents. 406 of them, 1.7%, showed high message-code inconsistency, sorted into eight types, and the largest type at 45.4% is the one that does the damage: the description claims changes that were never implemented. Those pull requests were accepted 28.3% of the time against 80.0% for the rest, and the ones that did merge took 55.8 hours against 16.0. Read the 1.7% the right way round. It is not the reassuring number it looks like, because it is not a defect rate. It is the rate at which a reviewer was actively pointed at the wrong part of the diff, and every guard you own passed while it happened, because no CI check reads English. The companion study on the same dataset, How AI Coding Agents Communicate, presented at the MSR 2026 mining challenge, supplies the uncomfortable half: well-structured descriptions get merged more often and get reviewer responses faster, independent of the reviewer’s sentiment. Structure predicts merge. That is a warning rather than a recommendation, because a confident, sectioned, well-formatted description buys trust it has not earned, and an agent produces one for free. Now why this lands hardest on Frontend. On a backend change the claim and the assertion tend to be the same sentence: the description says the endpoint returns 409 on a duplicate, and there is a test that says so too. On a Frontend change the claim is that the button now shows a loading state, that the error toast is dismissible, that the empty state appears before the first fetch resolves, and none of that is visible in the diff or asserted anywhere. Your reviewer reads the description to know what to look for, because the code will not tell them. Frontend is where the description carries the most weight and has the least behind it, which is exactly where a fluent, unverified claim does the most work. The fix is mechanical, and it is a guard like the others. Treat the description as an output of the run rather than a courtesy, and check it. Every claim in it has to map to something that changed, a route, a component, a hook, a token, a test, and every surface that changed has to appear in it. A claim with nothing behind it fails the run, and so does a changed surface nobody mentioned, which is the quieter half and the one that catches the refactor that rode along. Then split the description by who can be trusted to write which part. The pipeline generates the facts it can derive: which routes were touched, which components were added or changed, which tokens moved, which stories changed, the bundle and accessibility deltas. The author writes the part no machine can know, which is what this was for and what was deliberately not done. Attach the evidence you already produce, because your visual diffs, your Storybook stories and your performance and accessibility numbers are already sitting on that pull request, and a claim about a loading state stops being a sentence the moment it has an artifact next to it. Link the change to the request that caused it, the issue, the spec or the design, because a description that only restates the diff is a summary, and a summary is not a record. Six months later the question is never what changed, it is why. Three things not to do. Do not answer this by asking reviewers to read descriptions more carefully, for the same reason we never propose reading code more carefully: attention is the resource that is already exhausted, so every fix has to be on the load side. Do not have a second model write the description from the diff and call it solved, because a model reading the diff can only restate the diff, cannot know the intent it was meant to record, and will restate it confidently wrong often enough to be worse than nothing. And do not score descriptions on length, tone or politeness, which is what most review bots already do. Measure the thing itself instead: claim-to-diff coverage, the share of merges where the described surface and the changed surface disagreed, and time to first comment read beside merged volume. Two limits worth stating plainly. A claim-to-diff check proves the description covers the change, not that the change is right. And it cannot verify intent, only that an intent was recorded by the person who had one. The boundary is the usual one: we build and operate this guard inside your pipeline, we do not police how your engineers write, we are not selling you a pull request template, and we do not rank coding agents for you.

Two things, and almost every team builds only one of them. The rules that went live this year split the same way: a mark on the content that a machine can read, and a disclosure a person can actually see. California’s AI Transparency Act, SB 942 as amended by AB 853, names them latent disclosure and manifest disclosure, and became operative on 2 August 2026 for developers of generative systems above a million monthly users, who also have to offer a free detection tool anyone can use to check whether their system produced a given piece of content. The EU AI Act’s Article 50 transparency obligations apply from the same date. 50(2) requires providers of generative systems to mark synthetic audio, image, video and text in a machine-readable format detectable as artificially generated. 50(4) requires visible labelling of deepfakes and of AI-generated text published on matters of public interest. 50(1) is the one most products already did, telling a person they are dealing with an AI system, after which everybody assumed they were finished. The Digital Omnibus agreed in May 2026 gives generative systems already on the market before 2 August 2026 until 2 December 2026 to meet the machine-readable marking requirement, and anything placed on the market after that date gets no grace period at all. The Commission published the final Code of Practice on Transparency of AI-generated Content on 10 June 2026. It is voluntary, it covers Article 50(2), (4) and (5), and signatories may rely on it to demonstrate compliance, which makes it the practical specification even though the obligation itself sits in the Act. Then the part that makes this our problem rather than your counsel’s. The mark dies in your own pipeline. Content Credentials, the C2PA standard the ecosystem converged on, attach a signed manifest to the file. Your uploader re-encodes. Your resizer emits five widths. Your CDN transforms on the fly. Your privacy step strips EXIF and takes the manifest with it. Your export renders a PDF, your share card is a freshly rasterised screenshot, your email digest inlines a thumbnail. Every one of those is a Frontend or Frontend-adjacent code path written by somebody who had never heard of a manifest, and every one of them drops the mark silently, which is the worst property a compliance artifact can have. The Code of Practice says the quiet part itself: metadata alone is not sufficient, because a screenshot, an upload or a format conversion removes it, which is why durable schemes pair the manifest with an invisible watermark and a fingerprint so the claim survives the trip. The visible half is pure interface and it is harder than it sounds. What the label says, where it sits, whether it survives the crop, the lightbox, the feed, the print stylesheet and the email client, whether it is still there when the asset becomes the background of something else. A label nobody sees is not a disclosure. And verification needs three states, never two: signed and valid, signed and broken, and absent. An absent Content Credential is not evidence that a human made it, and an interface that renders absence as authentic has invented a guarantee neither regime makes. Where this lives in your code matters more than which library you pick. One marking and disclosure layer, resolved server-side per asset, sitting in front of every path that emits content, which is the same shape as every other capability layer we argue for. The alternative is a label bolted onto each surface, and then the export, the digest email and the public webhook are the three places that ship unmarked, because nobody classified them as the AI feature. Instrument it too: which assets left with a valid manifest, which arrived without one, and which lost one somewhere inside your own pipeline. That last number is the one that tells you whether you are compliant in fact or only in the code review. The limits and the boundary, both firm. A mark is a claim about origin rather than a guarantee of truth, and removing it is trivial for anyone who wants to, so this is provenance and not proof. And we build the marking, the preservation, the verification and the disclosure surfaces inside your product. We are not your counsel, we do not decide whether you are a provider or a deployer, we do not sign the Code on your behalf, and we certify nothing for you or for your customers.