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.