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.