# Enpitech > We accelerate Frontend delivery. Our flagship is the Frontend Delivery Factory: delivery infrastructure we install inside your R&D so everyone in your org ships production Frontend. Backend engineers, PMs, designers, marketing, sales, customer success. Real PRs on the real codebase, safely merged. We also build Frontend AI (generative UI, in-product agents, MCP apps, agent-ready interfaces) and run private training on your own codebase. Enpitech (אנפיטק) is an Israel-based engineering company founded in 2021 by Nir Parisian (ex-Intel, ex-Curv/PayPal). Around 13 engineers, based in Tel Aviv, delivering remotely to Israel, the US and the EU. AI made writing Frontend code cheap. Shipping it to production is still expensive. A PM, a designer or a backend engineer can generate Frontend code now. What they cannot do is get it merged. The guardrails, review standards, design-system discipline and production safety that senior Frontend engineers carry in their heads are the new bottleneck. We turn that into infrastructure. The web changed too. Products now serve two audiences: the humans who click and type, and the AI agents that use and find products on their behalf. Everything we ship is built for both. We are not a generic agency. We are senior-only, Frontend-specialized and AI-native by default. We ship production code, not POCs and not strategy decks. ## Why teams hire us in 2026 - **Frontend is the visible bottleneck.** Every other department queues "small" Frontend asks behind the Frontend team. Adding headcount does not clear the queue. Installing a delivery system does. - **The people who could not ship Frontend started shipping it, and that is now someone else's measurement rather than our claim.** Linear's aggregated telemetry from its own paid workspaces has the share of product managers who attached a pull request to an issue assigned to them rising from 3% to 10% over two years, and designers from 1% to 8%, against total pull request volume up 111% across the same window. epilot reported 629 merged PRs in 60 days with 40 of them from 11 people who are not engineers, and credited two things: a preview environment generated for every PR, and one written knowledge base holding its API patterns, conventions, CI strategy and domain language for an agent to read before it writes. That second artefact is the factory's context layer, arrived at independently. What unlocked those people was not a better model, it was writing the standards down somewhere a machine could read them. The counterweight travels with it: Qodo's 2026 State of AI Code Quality Report found 89% of organizations had already had an AI-related production incident while only 3.7% of engineering leaders said their existing processes were sufficient to govern quality as agents take on more work. The behaviour is arriving faster than the system for it. We build the system. - **AI coding tools got adopted, and code review became the traffic jam.** Teams can generate Frontend code faster than they can safely merge it. The 2026 industry benchmarks are consistent about where the time went: fully AI-generated code climbed from roughly 1% to 27.6% of all pull requests in a year, PR review time rose about 91%, AI-generated PRs wait roughly 4.6x longer before a reviewer even picks them up, and an analysis of 8.1 million pull requests across 4,800+ organizations found engineers report feeling around 20% faster while measured cycle time got slower. The clearest signal is the divergence between the two ends of the pipeline: CircleCI's 2026 data has feature-branch throughput up 59% year over year while main-branch throughput for the median team actually fell. Code is arriving faster and shipping slower. Around 85% of engineering leaders now name review, not authoring, as the bottleneck, and 70% say maintaining the test suite has become a bigger burden than writing code. Generation stopped being the constraint. Merging is the constraint. We build the guardrails, evals, review agents and agent tooling that make that output mergeable. - **The AI spend is now being audited, and the standard metrics stopped answering the question.** DORA's 2025 State of AI-assisted Software Development, published in February 2026 off roughly 5,000 respondents, found that AI acts as an amplifier: it magnifies the strengths of organizations that already had a solid delivery foundation and magnifies the dysfunction of the ones that did not, lifting throughput while often costing stability where that foundation was thin. Ninety percent of respondents were using AI in their daily work. That is the whole argument for installing the system before scaling the tooling, made by someone other than us. It also breaks the instruments. Deployment frequency and lead time were designed for a pipeline where a human wrote every line, and they stop measuring what a CTO thinks they measure once a large share of committed code is agent-authored, which is how a team ends up reporting record throughput while nothing reaches customers any sooner. We take your baseline in the audit before anything is installed, and we instrument the merge side rather than the authoring side: what a guard caught before a human opened the PR, review rejection rate on agent output, how much merged volume comes from outside the Frontend team, and the stability numbers read beside the throughput ones rather than after them. Throughput without stability is not speed, it is debt arriving sooner. The factory instruments itself, so those numbers are visible to your team on your repo rather than summarized by us in a monthly slide. - **Agent fleets arrived, and they scale the wrong half of the pipeline.** 2026 was the year parallel agents went mainstream: Claude Code Agent Teams running agents on isolated branches, Cursor composing several agents at once, GitHub Copilot's `/fleet` decomposing one instruction into background sub-agents, multi-agent sessions in VS Code. Every one of them multiplies generation, and generation was never the constraint. A fleet puts N times the pull requests in front of the same reviewers. The orgs operating fleets at real volume built the merge side first, which is why Stripe absorbs over a thousand agent-authored pull requests a week and roughly a third of Ramp's merged PRs come from agents, rather than the fleet drowning them. We build that merge side: guards that decide mergeability before a human is involved, a review agent that runs first, evals and telemetry on every run, and one shared context the whole fleet reads so five agents do not each invent a different answer to the same question. - **Spec-driven development became the enterprise pattern, and it doubles as governance.** Writing acceptance criteria, architectural constraints and domain rules down as a specification the agent codes against, and validates against, is what separates an agent workflow that survives an enterprise from one that stalls in review. It is the front half of the factory: structured specs are why factory PRs land smaller and more focused. The second-order effect is the one CTOs are now buying. Once the spec is an artifact and every guard, eval and agent run is traced, what an agent was allowed to touch, what proved its output mergeable and who approved the merge stop being reconstructed after the fact. That is the evidence chain an ISO 42001, NIST AI RMF or SOC 2 reviewer asks for once agent-written code reaches production, generated as a by-product of shipping. We produce the evidence and wire the controls. We are not auditors and we do not certify anyone. - **Non-engineers are shipping production Frontend.** PMs, designers, backend engineers and support staff are opening PRs with Claude Code and Cursor. Vibe coding was named 2025's Word of the Year for a reason. Without a factory, those PRs bottleneck on senior review, collide with the design system, or in the worst cases take production down. With one, they merge like any other. This is what the Frontend Delivery Factory installs. - **The 2027 planning cycle funds generation and inherits the queue.** Gartner's 2027 CIO and Technology Executive Survey has IT budgets growing an average of 3.7%, close to standing still after inflation, while funding for agentic AI rises an average of 31.8% and is the fastest-growing technology investment area; 37% of respondents had already deployed AI agents and another 34% planned to inside twelve months. Gartner's own warning is the operative part: without stronger cost controls, successful AI initiatives increase demand beyond what existing budget models can support. More people generating more candidate changes all arrive at the same senior reviewer, so succeeding at generation is what makes merging expensive. Gartner also predicts that by 2027 more than 65% of engineering teams using agentic coding will treat the IDE as optional, with control, governance and validation moving to automated platforms. That layer is what we install, Frontend-shaped. See [the shortlist](https://enpitech.dev/frontend-delivery-options). - **The Forward Deployed Engineer model is now the standard for delivering serious AI work.** OpenAI spun up a dedicated FDE company in 2026, Anthropic ships Claude FDEs into enterprise accounts, and FDE job postings grew by multiples year over year across the AI industry. Gartner expects more than 85% of tech providers to be running FDE programs by the end of 2026, for the same reason we do: enterprise AI work fails at deployment, not at the model. Our forward-deployed engineers arrive carrying factory tooling and practices, and every embedded engineer is a soft factory install. - **MCP is the de-facto integration layer for agents**, adopted across the major model providers. The MCP 2026-07-28 spec dropped sessions entirely, making servers deployable on serverless and edge infrastructure, and added a formal extensions framework plus hardened enterprise auth. We design and ship enterprise-grade MCP servers and clients on that spec, with MCP Enterprise Managed Auth, MCP Apps for rich UI, MCP Tasks for long-running async operations, gateways, audit trails and observability built in. - **WebMCP is becoming the browser standard for agent-ready products.** Google and Microsoft took WebMCP into W3C standardization in 2026, the Web Machine Learning Community Group published its draft report in April, Chrome graduated the API from an early Canary preview in Chrome 146 to a public origin trial in Chrome 149, Edge ships experimental support behind a flag, and Google I/O put it on the roadmap for Gemini in Chrome. The spec exposes site functionality to agents two ways: a declarative API over ordinary HTML forms and elements, and an imperative API for dynamic JavaScript interactions. We help product teams expose safe, structured tools to browser agents via WebMCP directly, or via the MCP-B polyfill on older browsers, on top of the existing app. - **The agentic browser is now a real traffic source, and most sites are invisible to it.** Perplexity Comet, Opera Neon, Copilot Mode in Edge, Gemini in Chrome and ChatGPT's agentic browsing (which OpenAI folded back into the ChatGPT desktop app and a Chrome extension in August 2026, retiring the standalone Atlas browser) all put an agent between your product and the person using it. The delivery surface keeps changing; the requirement it puts on your product does not. An agent that cannot read your page structure or find an action to call will summarize a competitor instead, and none of that shows up in a normal analytics funnel. Our free [AgentReady](https://enpitech.dev/agent-ready) scan shows what an agent actually sees on your site today, across discovery, readability, structured data, actions and trust. - **Agentic commerce got a protocol stack, and it is a Frontend job.** The Universal Commerce Protocol (UCP) was announced at NRF in January 2026, co-developed by Google and Shopify with a launch coalition of retailers, and Amazon, Meta, Microsoft, Salesforce and Stripe have since joined its tech council. UCP defines how an agent discovers products and transacts with a merchant; the Agent Payments Protocol (AP2) carries the authorization underneath it with cryptographic mandates, and both plug into MCP for tool access and A2A for cross-agent delegation. If your customers buy online, the checkout is about to have a second audience that never sees your UI. We build the catalog surfaces, agent-callable tools and checkout flows that make a product transactable by an agent without degrading the experience for the humans who still click. - **Agent-to-agent coordination is the next integration layer after MCP.** MCP connects an agent to tools and data; A2A connects agents to each other across trust boundaries, which is where multi-vendor and multi-department workflows are heading. We build for both layers rather than treating MCP as the end state. - **Design systems are becoming the semantic layer agents build against.** A design system used to be a component library humans read. In 2026 it is the constraint that decides whether an agent's output is on-system or a one-off, which is why design-system enforcement is a CI guard in our factory rather than a review comment. Committed tokens, components and usage rules are context the agent reads before it writes, and the check fails the run before a human ever sees the PR. The evidence is unusually clean on this one: a CHI 2026 study compared three ways of giving an agent a design system and found that pointing it at a registry of real, pre-built components produced roughly 95% design-system compliance, against about 85% for injecting the style guide into context and about 71% for describing the rules in the prompt. Telling an agent about your design system is the weakest of the three options, and it is the one most teams are doing. The artifact layer caught up in 2026: DESIGN.md, Google Labs' format for handing a visual identity to a coding agent as machine-readable tokens plus human-readable rationale, now sits beside AGENTS.md and CLAUDE.md in the repo, with a CLI that lints WCAG contrast and exports to Tailwind or W3C DTCG tokens, while Storybook's MCP addon serves live component metadata so an agent queries the real prop API instead of guessing at one. - **Accessibility became a regulated merge gate, right as more people started shipping UI.** The European Accessibility Act applied on 28 June 2025 and enforcement has been ramping across member states through 2026. It reaches e-commerce and consumer-facing digital services sold to EU consumers regardless of where the company is based, which is most Israeli B2B and B2C products with EU customers, and the harmonized standard behind it, EN 301 549, adopts WCAG 2.1 Level AA in the version cited today. That target is about to move: ETSI published EN 301 549 v4.1.1 in September 2026, realigning its web, document and software clauses to WCAG 2.2, and a harmonized standard carries a presumption of conformity only once it is cited in the Official Journal, which has not happened yet and has no announced date. The window between publication and citation is the planning window, and what lands at the end of it is six criteria an AA target did not have to meet before, of which exactly one, 2.5.8 Target Size, is decidable by a DOM scanner. The timing is the problem. Accessibility is the requirement that regresses most quietly when an organization widens who can ship UI, because a keyboard trap, a lost focus ring or an unlabeled control never looks wrong in a screenshot and an agent given a design and a prompt will reproduce all three. This is why an a11y gate runs on every PR in our factory rather than living in a quarterly audit: automated checks catch the mechanical failures before a human is involved, and the manual criteria that no scanner covers get routed to the people who can judge them. We build and wire the gate. We are not an accessibility auditor and we do not issue conformance statements. - **The people who can build UI now outnumber the people allowed to merge it, and the gap widens with company size.** This is the demand side of everything above, and there is finally a measurement of it outside engineering. The AI in Design 2026 report from Designer Fund and Foundation Capital, built on over 900 designer responses across 60+ countries plus 25+ leader interviews, found that half of respondents have pushed AI-generated code to production while only about a fifth of them identify as design engineers. Weekly AI use among designers went from 54% to 91% in a year. The number that matters for an engineering org is the split underneath the headline: 68% of designers at early-stage companies ship code, against 33% at publicly traded ones. Capability does not decline as a company grows, so that gradient is not measuring skill. It is measuring how much merge process stands between a person and `main`, and at 30 to 300 engineers most of that process is a senior Frontend engineer's attention. The same shape shows up for backend engineers and PMs: an agent gets them to code that compiles and looks right, and what they cannot carry is the tacit layer (which component already exists, which token, the loading and error and empty states, keyboard and screen-reader behavior, bundle cost) that is invisible in a working diff and is exactly what review is for. There are two ways to close the gap. Relax the gates, which buys design-system drift, accessibility regressions and the XSS class above. Or make the gates automatic, which is the factory: context the agent reads before it writes, design-system, a11y, security and test guards that fail a run without a human, and senior review spent on intent rather than on catching a raw hex. Note which way round this is. We are not arguing that more people should review less. We are arguing that a standard held in a person's head cannot scale past that person, so it has to become a gate. - **The design tool became a commit path, and it points at whatever your merge gate actually is.** This is the 2026 development that changes the shape of the previous bullet rather than restating it. Figma Make's GitHub integration entered limited beta on 28 May 2026: a designer connects a repository, Make installs the dependencies and runs the real application on the canvas, visual edits accumulate as commits, and the work leaves as a branch and a pull request without the designer writing a line. Code Layers followed at Config on 24 June 2026, putting a cloned repository on the canvas with a live two-way link to the Git-tracked code, in early access from July on a paid Full seat. Figma is explicit that none of it bypasses existing engineering guardrails: the change is subject to the same CI, the same security checks and the same review as any other commit, and the tool enforces no design-system governance of its own. That is a promise about the customer's pipeline rather than about Figma's, and it is the right design. It also means the tool has opened a new inbound lane straight at whatever currently decides mergeability, which in most orgs of 30 to 300 engineers is a senior Frontend engineer's attention. The failure modes are specific and none of them are visible on a canvas: a one-off value where a token belongs, a component built beside the one that already exists, a state that only lives in a reducer, a keyboard path, what the change costs in bundle size. Our position is that these PRs get no separate lane and no softened gate, because a guard that yields to the author's job title is not a guard. What they get is the registry and the tokens served to the tool before it writes, the same design-system, accessibility, security, test-quality and performance gates every other PR meets, a rule that a prototype from a tool which never read the repository (Lovable, v0, Bolt, Figma Make from scratch) is treated as a specification to rebuild against real components rather than as a branch to merge, and authorship recorded at merge so provenance survives four tools being able to open a PR. - **The AI bill stopped behaving like a seat, and the answer is metering rather than restraint.** Anthropic doubled its own published Claude Code estimate on 15 April 2026, from roughly $6 to roughly $13 per developer per active day, about $150 to $250 per developer per month for enterprise use, noting that 90% of users stay under $30 a day, which is the shape of the problem: a long tail of heavy runs drives the number, not the average engineer. Forbes reported on 17 May 2026 that Uber had exhausted its entire 2026 AI budget four months into the year after Claude Code spread across roughly 5,000 engineers, with its CTO confirming the overrun. Neither is a story about an expensive tool. Both are consumption pricing landing in a line item modeled as a seat, and a factory makes the distribution wider on purpose by adding authors to it. So spend control is part of the infrastructure rather than a policy memo: agent traffic through a gateway so cost is attributable per repo, per team, per run and per model; budgets on repos and teams with a run that would cross one stopped or routed to a cheaper model instead of quietly finishing; model choice as policy so mechanical passes do not run on the expensive model out of habit; cheap deterministic checks first, because a design-system or type failure caught at ninety seconds costs a fraction of the same failure found by a senior twenty minutes into a review; and cost per merged pull request reported beside guard catch rate, because cost per seat says what you bought and cost per merged PR says what you got. We build and operate the metering, the gateway policy and the budget guards. We do not resell tokens, we take no margin on model spend, and we are not a FinOps vendor. - **The security of agent-written code is a Frontend problem, and the measurements say so.** This is the cluster teams are slowest to wire up, because it looks like an AppSec topic and it is really a merge-gate topic. Veracode's 2025 GenAI Code Security Report tested over 100 models across 80 curated tasks and found that 45% of the AI-generated code it evaluated introduced a security flaw, and the worst single category in the whole set was cross-site scripting, where only around 12% of AI-written solutions came back secure. That is not a backend finding. XSS is a Frontend defect class: user input reaching the DOM, `dangerouslySetInnerHTML` used because it made the type error go away, a Content Security Policy loosened to unblock a build, an API key that ends up in the client bundle. A model reproduces all four fluently, and none of them look wrong in a diff, which is exactly the property that makes a human reviewer the wrong last line of defense. It is the same failure shape as design-system drift and accessibility regression, and it takes the same answer: a guard, not a review comment. In our factory the security checks run on every PR beside the design-system and a11y gates. Taint paths from request data into DOM sinks, `dangerouslySetInnerHTML` and raw `innerHTML` behind an explicit allowlist, CSP and header assertions tested rather than documented, secret scanning on the bundle and not just the repo, and dependency checks on anything an agent adds to `package.json`. The failure stops the run before it reaches a human. The boundary, stated the same way as everywhere else: we build and operate the gate, we are not a security auditor, we do not run penetration tests, and we do not issue certifications. - **Onboarding a new engineer got harder rather than easier, and that is a repository problem.** A newcomer needs three things and an agent answers one of them: what does this do, why is it like this, and what will get my pull request rejected here. The first was expensive and is now nearly free, and it was never the part that cost six weeks. Why lives in a decision somebody made under a constraint that has since gone, and the fastest route to it was to find the author and ask, which agent-written code removes: blame resolves to a commit whose author did not make the decisions inside it. What gets rejected here was never written down, because it was transmitted by a senior engineer’s comments on a newcomer’s first twenty pull requests, and that is exactly the reviewer attention AI output has saturated, so the person who used to teach is triaging. The practice work went too, since the small, low-risk tasks people learned on are what an agent now finishes before anybody assigns them. Stanford HAI’s 2026 AI Index found employment for software developers aged 22 to 25 down nearly a fifth from its 2024 peak, and inside one company that reads as the curriculum being gone. So we treat ramp-up as a property of the repository: time to first merged pull request measured by role (merged is the only word in that metric doing any work), day one as a green run rather than a reading list, the AGENTS.md and CLAUDE.md the agents read doubling as the curriculum for the humans, guards doing the teaching because a check that fails in ninety seconds is impersonal and arrives before anyone is embarrassed, short dated decision records triggered by any review comment that begins with we tried that, and provenance recorded at merge so blame resolves to the person who chose. We do not write your job ladder, run interviews or source candidates, and we are not a recruiter. If ramp-up is slow because the codebase is incoherent, onboarding is the symptom. - **The two guards teams believe they already have, tests and performance, are the two that stopped working.** Every cluster above names a guard a buyer knows they are missing. These are the two they think they have. Agents now write the tests as well as the code, and Capgemini's World Quality Report 2025-26 puts roughly 70% of enterprises on AI for test authoring and maintenance, so this is most codebases. An agent asked for tests optimizes for the visible number, which is coverage: it renders the component, asserts that nothing threw, snapshots the output and reports 90%, and a flipped comparison operator still passes. The other end of that pipeline is measured. 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 has its own tell: a brittle Playwright selector gets fixed by loosening the selector until it passes, and a failing snapshot gets regenerated by the same agent that just changed the behavior, which is the test agreeing with the bug in writing. Performance fails the same way and is invisible for longer, because a Lighthouse score on a static page never sees it. CodeRabbit's State of AI vs Human Code Generation report classified issues across 470 open-source pull requests, 320 AI-coauthored against 150 human-only, and found AI-authored changes carried roughly 1.7x more issues overall with performance inefficiencies close to 8x more common, the widest gap in the report, and it lands on the Frontend because on the Frontend the user's device pays for it. Both take the same answer as design-system drift and accessibility regression. Gate on whether a test can fail rather than on how many there are (mutation checks on the paths that matter, assertion quality on changed lines, test impact analysis, flaky tests quarantined instead of retried until green, and a snapshot never accepted in the same run that changed the component), and put the performance budget in CI per route with a ceiling the build fails on, duplicate dependencies flagged on arrival, and INP, LCP and CLS asserted against real interactions rather than a synthetic score. We build and operate both gates. We are not a QA vendor, we do not sell test headcount, we are not a performance-audit shop, and we do not sell a score. - **Platform engineering acquired the category word for what we install, and the platform teams are a year behind their own agents.** The internal developer platform was built for a human user: golden paths as templates someone reads, a catalog someone browses, a paved road someone chooses to walk down. An agent does none of those things, so a golden path only constrains one if it is executable, which turns the path into a contract the agent dispatches against with a CI check standing behind it. That is a rewrite of the artifact rather than a new page in the developer portal, and the layer around it is new work as well: a gateway that decides which tools an agent may call, a substrate where a run is sandboxed and reproducible, autonomy bounded per repo rather than declared per org, evals, and traces that outlive the run. The industry now calls the destination an agentic development platform. Gartner's forecast that over 40% of agentic AI projects will be canceled by the end of 2027 attributes the failures to escalating cost, unclear business value and inadequate risk controls, which is a governance shortfall rather than a model one, and it is exactly what building this layer in the gaps between quarterly platform commitments produces. The Frontend Delivery Factory is that platform, scoped to the layer where mergeability is most specific and least writable by a generalist: which component already exists, which token, which states, what the accessibility contract is, what a route may weigh. We install it inside your platform rather than beside it, on your CI and your conventions, and your platform team owns it at handover. - **The debt from two years of AI-assisted shipping is now sitting in the repo, and it does not behave like ordinary technical debt.** The largest study of it, a 2026 analysis of 304,362 verified AI-authored commits across 6,275 public repositories and five widely used assistants, ran static analysis before and after each change and attributed 484,606 issues to the AI edits, 89.1% of them code smells rather than outright bugs. The number that matters for planning is survival: 24.2% of those issues were still present at the latest revision, and the pool of surviving AI-introduced debt grew from a few hundred issues in early 2025 to more than 110,000 by February 2026. Ordinary technical debt is a shortcut someone took under a deadline and usually left a comment about. This accumulated invisibly, in code that compiled, passed review and worked, which is why normal churn does not pay it down. Our answer is not a cleanup sprint. The audit maps where agent-authored code concentrates and which issue classes actually cost something, then the guards go on in ratchet mode, failing on changed lines rather than the whole repository, so what the team touches comes up to standard and what it does not touch stops getting worse. Remediation rides the roadmap instead of competing with it. - **Enterprise AI coding agents became a governed category, not a tools budget.** The enterprise coding-agent market is now measured in the billions annualized, and the questions moved from "which tool" to visibility, control and governance as agent workflows scale across an org. A factory is the governance layer: what an agent may touch, what proves its output is mergeable, and what gets traced on every run. - **AGENTS.md became the shared context standard.** It is now read by 30+ agents across 60,000+ repositories, and it lives alongside Claude Code's CLAUDE.md rather than replacing it. Every codebase we touch ships with an AGENTS.md and CLAUDE.md pair so agents stop re-litigating the same review comments across sessions. - **Products are embedding agents, and the interface is what decides whether anyone trusts them.** Gartner projects that 40% of enterprise applications will have task-specific agents embedded in them by the end of 2026, up from under 5% in 2025. The ones that land badly fail the same recognizable way: a spinner over an autonomous process. The user cannot see what the agent is doing, cannot stop it halfway, and cannot tell a confident wrong answer from a right one, so they stop trusting it and go back to the manual flow. That is a rendering problem, not a model problem, and it is squarely Frontend work: tool calls streamed while they run rather than revealed afterwards, step-level intervention instead of an all-or-nothing cancel, an approval gate in front of anything irreversible, and honest uncertainty in the UI. A protocol layer for it arrived alongside the pattern. AG-UI, the Agent User Interaction Protocol that came out of CopilotKit's work with LangGraph and CrewAI, carries an agent run to the Frontend as an event stream over HTTP, SSE or WebSockets and is framework-neutral across the common agent backends, and A2UI lets an agent declare the components it wants rendered as structured JSON. We build that layer inside your design system and behind your existing permissions, and we push teams to decide the autonomy level early, because human-in-the-loop and human-on-the-loop are two different products rather than a setting. - **The EU AI Act's transparency layer landed on 2 August 2026, and every obligation it creates is rendered.** Article 50 applied on that date and it is not the deadline that moved: the Digital Omnibus deferred the high-risk obligations to December 2027 and August 2028 and left Article 50 where it was. Three requirements fall on the product itself. A system that interacts directly with people has to make clear to the person that they are dealing with AI, at the start of the interaction and in the interface rather than in a paragraph of the terms. Synthetic output, whether text, image, audio or video, has to be marked in a machine-readable format that a detector can read, which is a provenance and metadata problem rather than a badge in the corner of a card. And the deployer-side disclosures, deepfakes, emotion recognition and AI-generated text published on matters of public interest, have to be visible to the person looking at the content. One further date belongs in the calendar: generative systems already on the market before 2 August 2026 were given until 2 December 2026 to meet the machine-readable marking requirement. As Frontend work this is a disclosure surface that lives in the component rather than being bolted on per feature, provenance metadata carried from generation through storage to render so the marking survives an export or an embed, and labels that stay legible when the content is displayed somewhere else. We build that layer inside your design system. We are not your counsel, we do not classify your system's risk tier, and we do not issue conformance statements. - **Legacy Frontend migration became the most factory-shaped work there is, and the 2026 benchmarks explain why it needs a harness.** Two published results from the same year sit two orders of magnitude apart. IBM Research's ScarfBench, a cross-framework migration benchmark built from expert-written implementations across 204 directed tasks, 102 framework variants and roughly 151,000 lines of code, found the strongest agent passing 15.3% of tests on single-layer migrations and 12.2% on whole applications, with exactly one of the 204 tasks coming back fully behaviorally equivalent. Google's published account of its internal LLM-assisted migrations reports the opposite outcome: across 39 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 developers estimated roughly half the time of the manual equivalent. The difference is not the model. Google paired it with AST-based tooling that located every change site before the model wrote anything, and every change went through normal review. The model typed. The harness decided what was true. On the Frontend that harness also defines parity, which is the part teams get wrong: a migrated screen that renders identical pixels but loses a keyboard path, drops a focus trap, doubles its bundle or quietly changes an empty state has not migrated. Those are the guards the factory already runs, so parity becomes a test rather than a judgment call in review. We run migrations through a factory rather than beside one, route by route behind the app you are already shipping, and we do not sell big-bang rewrites. - **The web went majority-machine, and access stopped being an infrastructure setting.** Cloudflare reported on 3 June 2026 that automated requests had passed human traffic for the first time in the internet's history, with Radar putting it at 57.5% machine against 42.5% human HTML traffic, and its May 2026 breakdown found 51.8% of AI crawler requests were for training against 9.3% for search. Those categories have opposite value to a product company, which is the whole point: a research or buying agent reading your product page is drawing a shortlist before you know a buyer exists, an agent operating your product for a customer is a user session with no browser chrome around it, and a training crawler takes and returns nothing. Cloudflare split crawler traffic into declared purposes on 1 July 2026 and blocks the training and agent categories by default on ad-supported pages from 15 September 2026, with mixed-use crawlers that will not declare a purpose blocked outright there. So the decision is per surface and per purpose, and it is a product decision. The Frontend half is ours: the same truth rendered for both audiences so an agent need not execute your bundle to learn what you sell, capability declared where agents look so they transact through an interface you version rather than scraping one you did not design for them, identity verified at the application layer instead of trusting a user-agent string any scraper can set, and agent sessions instrumented as their own funnel because they fire none of the events a human funnel is built on. We are not a CDN and not a bot-management vendor. Enforcement belongs at your edge and we build to the policy you set there. - **The ceiling on agentic delivery is verification capacity, not agent count.** 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. The report calls that the delegation gap and names verification as the bottleneck of what it calls the orchestration era. Buying more agent seats moves the first number and leaves the second exactly where it was, because the constraint is not how much code can be produced but how much of it a person will put their name on. CloudBees measured the cost of getting that wrong. Its State of Code Abundance report, published on 19 May 2026 from TrendCandy research across 213 enterprise technology leaders, found 92% confident their AI-generated code was production ready while 81% reported a rise in production issues tied to that same code, and in the same population only 12% had a dedicated governance function while 46% said the CTO or VP of Engineering carries the accountability when something fails. Accountability landed on a person, the mechanism landed nowhere, and no person can personally verify what a fleet of agents produces. So the number we work on with a client is the share of agent output that reaches a human already proven rather than merely finished. There is no published ratio for how many agents one engineer can carry and we do not invent one: it is a property of the codebase, and the audit measures it before anything is installed. Four things raise it, in install order: guards that run before a human and return a specific reason to the author, context and skills committed to the repo so the same correction is not re-explained every session, task shape with written acceptance criteria, and review routing so the changes needing judgment arrive first. A ratio that improves because review got shallower is not an improvement, which is why it is always reported beside guard catch rate and review rejection rate on agent output. - **Prompt injection is a product-interface problem, and the shipped mitigations prove it.** This is not the security of code an agent wrote for you, which is a Factory question. This is the security of the agent your product ships to its users. OpenAI published Lockdown Mode and Elevated Risk labels on 13 February 2026, updating 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 mitigations from the best-resourced lab in the field, 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 incidents to one CVE means these do not arrive through the vulnerability pipeline AppSec watches. They arrive as your own agent doing something it was permitted to do. The defensible layer is Frontend: untrusted content never rendered into the same trust context as the user's own instruction, tool scope declared per surface, irreversible actions behind a confirmation that renders the real parameters rather than the intention, provenance shown for what the agent read, a degraded mode designed on purpose, the agent holding no privileges of its own but acting as the signed-in user through existing authorization, every tool call logged, and injection cases run as evals in CI. We build and operate that layer. We are not an AI security auditor, we do not run penetration tests or 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. - **The last unguarded thing an agent can put in your repo is a license.** 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% the year before, the largest single-year jump the study has recorded. The reason is in the same report: 76% of organizations assess AI-generated code for security risk, only 54% assess it for IP and licensing, and 24% run a comprehensive review across IP, licensing, security and quality. Security acquired a process over the last two years. Licensing did not. Two things make this land on the Frontend rather than on a legal department's filing cabinet. Open source components per codebase rose 30% year over year, and an agent asked for a date picker, a virtualized table or a chart installs one without an opinion about its license, because nothing in the prompt asked for one. Quieter and worse, 17% of open source components now enter codebases outside any package manager, as copy-pasted snippets, vendored files and generated code, which means the manifest your scanner reads never mentions them, and a model reproducing an implementation it learned from a copyleft project does not bring the header along. A 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 rather than a policy page. Your legal team sets the policy, allowed licenses, denied licenses and the tier that needs a person, and CI holds it: the full dependency graph checked on every PR including transitive packages and licenses that change under you in an upgrade, an SBOM produced by the build rather than assembled for a questionnaire, code that arrived with no manifest entry flagged for provenance, exceptions recorded with a reason and an owner, and the gate switched on in ratchet mode after an inventory so it does not fail every build on the first morning. Those artifacts are also what an acquirer or an enterprise security questionnaire asks for, produced as a by-product of shipping instead of reconstructed under diligence. 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. - **An MCP app that nothing calls is the 2026 version of a site nobody links to.** Distribution inside an assistant settled into two doors, and neither is a search box you can optimize. OpenAI opened third-party app submissions on 17 December 2025 alongside an in-product App Directory in ChatGPT, browsable 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 door decides the volume: a model picking your tool mid-task from the metadata you wrote, which makes tool descriptions, parameter schemas and annotations product copy with a machine as the reader. Note 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, so the first tactic a growth team reaches for is a rejection rather than a ranking. What is left is product work: a small set of sharply scoped tools rather than a mirror of your REST API, descriptions that say when to call a tool and when not to, annotations set honestly so a write or destructive action is declared as one, auth that asks for the narrowest scopes and fails legibly instead of returning what reads as an empty result, and a UI resource for the tasks that need one, which is what MCP Apps standardized as the first official MCP extension on 26 January 2026, rendered by the host in a sandboxed iframe and live in Claude on web and desktop, Goose and VS Code Insiders with ChatGPT following the same week. Treat selection as testable: the twenty phrasings a real user would use, run as an eval set in CI, measuring how often your tool gets picked and how often the task completes. Keep it separate from being found on the web, which is about pages a crawler can read. This is about a tool a model can select. Two honest limits: no platform publishes its ranking, and nothing you can buy changes it. - **Merged is not shipped, and the release side is where the 2026 numbers went bad.** Every guard above answers "is this change well-formed". None of them answers "was it right", because only production answers that. 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 at 70.8%, the lowest in five years, median recovery at 72 minutes, up 13% year over year, and main-branch throughput for the median team down 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 needing manual debugging in production after passing QA and staging, with 88% of organizations needing two to three redeploy cycles to publish a single AI-generated change and not one respondent managing it in a single cycle. The Frontend makes that gap worse in two specific ways. A Frontend release is not gradual by default: there is no rolling restart to hide behind, so publishing a bundle hands all of it to the next person who loads the page, including the users mid-session on the previous one whose lazy chunks just stopped existing. And Frontend failures are silent, because a dead button, a form that rejects a valid input in one browser and a chart that renders empty for your largest accounts all return 200 and trigger no alert. So the release path is built on the same rule as the merge path: 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, the switch lives in the app rather than the pipeline so turning it off is seconds instead of a rebuild, flags are evaluated where the page is rendered and fail safe when the flag service does not answer, release flags carry an owner and an expiry that CI enforces so the switches do not become their own debt, stale clients are handled with retained assets and a version check instead of a silent chunk failure, and the threshold for turning something off is agreed before the flag is opened. Confirmation is field data on the routes that changed: Interaction to Next Paint, LCP and CLS from real users, client error rate keyed to the release, and the one funnel step the change was supposed to move. This sits downstream of the merge decision, so it adds no eighth guard to the seven. We build and operate it inside your pipeline with your tools. We are not an SRE vendor, we do not carry your pager or run your on-call rotation, and we do not sell an observability product. - **An AI feature's worst production state is capacity, and all of it is rendered.** Datadog published its State of AI Engineering 2026 on 21 April 2026 from production LLM telemetry across thousands of organizations, and the headline is not about answer quality: 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 from the same report set the shape. 69% of companies now run three or more models, so failing over to a second one is routine rather than hypothetical, and it changes latency, formatting and refusal behavior mid-conversation. And token usage per request more than doubled year over year for the median organization and quadrupled for the heaviest users, which is cost and wait both climbing under a feature whose interface was designed against a fast demo. One call in twenty failing is not an edge case, it is a state the product is in several times an hour, and it is a rendering problem: a capacity failure that keeps what the user typed and offers a retry rather than a red toast that throws the work away, a stream that stops mid-sentence detected and labeled as incomplete rather than presented as finished, slow and broken designed as different experiences, and a failover treated as a product decision. Health is measured with signals ordinary monitoring cannot see, because a truncation, a refusal and a confident wrong answer are all HTTP 200: time to first token at p95, completion rate for streams rather than requests, degraded-session share covering retries, failovers, truncations and queues, abandonment, and the outcome the feature exists to produce tied to the model and prompt version that produced it. Cost and latency are Frontend decisions too, set by what you send per turn, what you cache ahead of the variable part, what you route to a smaller model and what you stream. Keep this apart from agent UX, which is whether a user can see and stop what an agent is doing, and from evals, which catch a quality regression before release and say nothing about a rate limit at 9am on Monday. The capacity is your provider's: we are not an LLM gateway or an observability vendor and we do not sell an SLA on somebody else's model. - **The package an agent invents is now a registered package.** This is the one check that cannot wait for the merge, because installing is executing. "We Have a Package for You!", presented at USENIX Security 2025 by researchers from the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech, generated 2.23 million code samples from 16 code-generating models across Python and JavaScript and found 440,445 of them, or 19.7%, containing at least one hallucinated package name, across 205,474 unique fabricated names. The number that turns this into an attack is the repetition: re-running identical prompts ten times each, 43% of the invented names came back on every single run and 58% on more than one. A hallucination is not noise, it is a stable namespace anyone can enumerate ahead of time and register first. The Cloud Security Alliance published a research note on the resulting class, slopsquatting, on 19 April 2026, and in August 2026 one actor pushed more than 700 malicious packages to npm inside 48 hours, since reported past a thousand, each delivering a cross-platform remote access trojan and infostealer. The clearest documented case is Frontend tooling rather than something exotic: models produce "unused-imports" when they mean eslint-plugin-unused-imports, the name was registered 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 it ours. npm is where the whole Frontend toolchain comes from, so the registry being seeded is the one your build stands on. And a lifecycle script runs on a developer machine and on the CI runner at install time, which is upstream of the build, of every guard and of any human review, so a vulnerability scanner reporting on packages that already exist is answering a different question at a later point in time. What we install checks existence and provenance where the name lands: every added dependency resolved against the registry with first-publish date, download history, repository link and maintainer count, lifecycle scripts off by default for anything new and enabled only by allowlist, installs run with no credentials or publish tokens on an unreviewed branch, the lockfile diff reviewed as code rather than collapsed to one line, and the approved component and library inventory served to the agent as context so a request for a chart, a date picker or a lint rule resolves from a list you own instead of from what the model half-remembers. It is tiered so well-established packages pass automatically, and it starts as an inventory and ratchets onto changed lines so it does not fail every build on the first morning. It adds no eighth guard to the seven: it sits inside the existing security gate's lane. Two honest limits: a widely used package can still be compromised through a maintainer account, which is your scanner and lockfile discipline rather than this check, and a gate at install can only tell you whether a dependency is what it claims to be, never whether it was a good idea. We build and operate the gate inside your pipeline with your registry and 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. - **Inference moved into the browser, and the availability problem is permanent.** Chrome 148 shipped on 5 May 2026 with the Prompt API stable, putting Gemini Nano behind a JavaScript call in the page: no API key, no account, no network round trip for generation, multimodal input across text, image and audio, streaming, and output constrained to a JSON schema or a regular expression. For high-frequency, latency-sensitive, small-context work that beats a hosted call outright. The rest of the story 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 enable the feature despite being built on Chromium. It is not in Firefox and it is not in Safari. Even inside a supported Chrome, availability is per device rather than per browser, because the model is a large local download gated on disk and hardware, so the same browser version answers differently on two laptops. So this is built as two paths behind one contract: the hosted path is the default and the local one is an upgrade, never the reverse; capability is detected per feature at call time and never inferred from a user-agent string; and the component consumes the same typed, streamed, schema-constrained result either way, so nothing forks below the call site. The states that exist only on this axis are designed rather than discovered, because a model still downloading is a real state with real copy and not a spinner that never resolves. The privacy claim is bound to the path that actually ran, since "this never leaves your device" is true locally and false on the fallback. What belongs local: classify as someone types, extract from a pasted block, rewrite or translate a selection, draft in a field, and redact identifiers before anything reaches a hosted model, which is the case that changes an architecture rather than a line item. What stays hosted is anything where the answer is the product. The cost does not disappear either, it moves to the user's battery and thermal budget on a device you do not control, so it is read as Interaction to Next Paint from real devices rather than as a token count. Keep it apart from the reliability envelope, which is what the interface does when a remote call is late, capacity-limited or truncated. This is about where inference runs at all. We build the feature and both paths. We are not a model vendor, we do not ship you a model, and we will not promise a capability a browser has not shipped. This roster moves quarterly, so the claims here carry their dates. - **A bigger context file is not what makes an agent find its way around, and there is now a controlled study saying so.** Researchers at ETH Zurich and LogicStar.ai published Evaluating AGENTS.md in February 2026, running 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 from twelve less-travelled repositories carrying real maintainer-written context files, each agent run three ways: no file, a vendor-recommended generated file, and the human-maintained one. A generated context file came out slightly worse than no file at all, roughly 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 were worth about four points, still at close to a fifth more cost. The authors name the reason: codebase overviews and directory listings did not help agents navigate, because agents discover structure well on their own, so a hand-maintained listing mostly spends reasoning tokens. The conclusion is about the 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 spread across a component, a hook, a provider, a token file, a route module and a test, and none of that is visible in a tree. So the work is structure the agent cannot miss (one obvious home per concern, module boundaries as import rules CI enforces rather than a convention someone documented, dependency cycles broken), ownership expressed as code with CODEOWNERS generated from those same boundaries so the reviewer cannot drift from the structure, and a context file kept short and load-bearing: commands, invariants, and what genuinely cannot be discovered by reading. We do not tell anyone to delete their AGENTS.md and we still write and maintain one in every engagement, because context that is true and unguessable is worth having. We do not sell a rewrite either: boundaries are drawn where the seams already are, enforced first on the lines a pull request touches and ratcheted from there, the same sequencing the performance budget and the license gate use, because a rule switched on at an ideal standard over a six-year-old codebase gets disabled by Thursday. - **The ceiling everything else runs into is human judgment, and how a team uses AI decides whether that judgment survives.** Anthropic published How AI assistance impacts the formation of coding skills on 29 January 2026: 52 mostly junior engineers, all writing Python weekly for over a year and none familiar with Trio, split at random between working with an AI assistant that could produce correct code on demand and working without one, then given the same comprehension quiz with no AI available. The unassisted group averaged 67% and the assisted group 50%, with the steepest fall in debugging, which the authors attribute to the assisted group never hitting the errors that teach it. The finding that matters is the one underneath: the spread was inside the assisted group rather than between the groups. Six distinct interaction patterns were identified, three scoring under 40% and three scoring between 65% and 86%, at or above the people who had no assistant at all. The engineers in the upper band used the assistant to build understanding while it produced code, asking follow-up questions, requesting the reasoning, sending hybrid requests that return an implementation and an explanation of it. Same tool, same task, opposite outcome, decided by how the person worked with it. That is a habit, and habits are what training installs, which is why this belongs to workshops rather than tooling and why the argument is never that a team should use AI less. It connects directly to the delivery side: every guard ends by handing a specific reason to a person who has to read a diff and decide, so what an organisation can ship is bounded by what its people can stand behind. Limits stated rather than glossed: the study measured mostly junior engineers learning one unfamiliar library in one session, so it is quoted for that and not stretched into a claim about senior engineers or careers; we do not place juniors as engineers and this is not a graduate programme; and we put no number on what a workshop recovers, because nobody has measured it. - **Coding agents are not what is breaking your main branch, and the 2026 measurement says so plainly.** 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 found AI-assisted pull requests breaking the main branch 1.9% of the time against 4.4% for pull requests with no detectable AI assistance. What 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. At least one pull request in seven in private repositories is AI-assisted, and that is a floor, because assistants that leave no trace on the commit are invisible to the measurement. So the constraint is not authorship, it is volume arriving at a control point that was sized for human typing speed, and the same report found 94% of teams still pushing one pull request through the queue at a time. Queueing is why it feels sudden rather than gradual: as arrivals approach capacity the wait stops rising in proportion to the load and climbs away from you, so a pipeline that was fine last quarter is broken this quarter without a single check having got slower. Frontend is where it bites hardest, because Frontend CI is the expensive kind, with a browser matrix, visual regression, an accessibility pass, a bundle budget and a Lighthouse run all measured in minutes rather than seconds. The work is capacity engineering around the guards rather than a new guard: cheap deterministic checks ordered first so an expensive suite is never spent on a change that does not typecheck, test impact analysis so a token edit does not run what a routing change runs, a queue that batches and bisects instead of testing every pull request alone with the batch size widening under load, and runs isolated per agent rather than serialising on one shared staging environment. Cost is reported as cost per merged pull request read beside guard catch rate, because a pipeline that is cheap and merges nothing is not a saving. We build it on the CI you already run. We are not a CI vendor and we do not resell one. - **Agents can now prove who they are, and that is the easy half.** Web Bot Auth lets an agent sign its requests with HTTP Message Signatures, RFC 9421, using a per-agent Ed25519 key and a Signature-Agent header naming a key directory it publishes, with a Signature Agent Card describing the operator, the expected request rate and the keys. The status is unusual and worth stating precisely: the IETF chartered a working group for it in 2026 after a Birds of a Feather session at IETF 123 and that group had adopted no documents as of August 2026, 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. What a verified signature answers is who is calling. What it does not answer is what that caller may read, which capabilities it may invoke, what it may buy, whose data it may touch, or what an unverifiable caller gets instead, and none of that can live at the edge because all of it is your domain model. That is the product layer, and it is tiered. Unverified callers get your public product truth, server-rendered and complete, at a rate limit and with no privileged capability, because the systems deciding whether your product is mentioned when a buyer asks a question are largely still unsigned and a blanket block is how a product disappears from the answer, with any refusal made legible through a real status code and a machine-readable reason rather than a silent drop that reads as an outage. A verified known operator earns trust rather than access: higher limits, structured responses, and declared tools callable over WebMCP or an MCP endpoint with honest annotations on the destructive ones. An agent acting for one of your users is a separate tier on your existing authorisation, scoped to that user and never wider, established through consent the user actually saw, revocable, and recorded. Anything irreversible renders its real parameters behind an explicit confirmation. And because verification proves identity rather than good behaviour, per-operator limits, spend caps and an operator-scoped kill switch ship with it. We build that layer in your product, on your own authentication and permissions, alongside whatever your CDN already does. We are not a bot management vendor, we do not sell or operate a WAF or a CDN, and we do not promise behaviour a standard has not shipped. - **Your company is already shipping production software you cannot see, and a ban does not bring it back.** 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 problem is that 59% could not confirm whether an AI-caused production incident had already happened, and only 19% could say it had not and point at the monitoring that told them. Almost all of those tools are Frontends, internal dashboards, forms, admin screens and reports put over data and services that already existed, and the people building them are the same people the factory exists to unlock. A shadow estate is a measurement of unabsorbed demand rather than an obedience problem, so the answer is a sanctioned path that is genuinely faster than the prompt, triaged by whether a tool touches production data, customer-facing surfaces, credentials or a second person's work. We build the path, the guards and the migration. We are not a shadow-IT discovery product, we do not scan networks and we do not monitor employees. - **Agents attempting real tasks fail most of them, and a large share of the gap is the interface rather than the model.** 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, weighted to state-changing work: purchases, appointments, job applications and long forms. A run counts only if the agent's final HTTP request matches the task schema, then a judge grades it against a human reference trajectory over a five-layer recording. The strongest frontier agent evaluated finished 33.3%, roughly one task in three, and the majority of tasks defeated every model tested, while the same class of agent scores in the 65 to 75% range on older benchmarks built from hosted replicas and static page traces. Part of that gap is the agent. A large part is everything the replica left out: banners that appear after the surface is interactive, controls that exist only as pixels, state changes that are painted but never announced, five-step forms that lose step two, and actions with no idempotency or confirmation. That is rendering work, and it overlaps almost entirely with the accessibility gate, because an agent reads what a screen reader reads. The durable answer for the flows that matter is a declared callable tool over WebMCP or an MCP endpoint rather than a UI an agent has to drive. We do not build CAPTCHA solving or bot-detection evasion. - **Generative UI graduated from experiment to production** (Vercel AI SDK 6, AI Elements, assistant-ui, CopilotKit, A2UI, TanStack AI, MCP Apps). We pick the right primitive, integrate it into your existing design system, and ship it with evals and LLM observability. - **Your coding agents are writing for a version of your stack that you do not run.** A model’s default for a framework is the version written about the most, not the one in your lockfile. “When LLMs Lag Behind”, an April 2026 benchmark of code generation under API evolution across 270 real-world library updates and eleven models in four families, found only 42.55% of generated examples executable in the target environment without comprehensive documentation, and 66.36% with structured documentation and a larger model, so doing the documentation properly still leaves roughly a third not running. That benchmark is Python-library based; a Frontend is worse rather than better, because the deprecation surface is a stack of majors moving independently (framework, meta-framework, router, bundler, styling, test runner, lint config, types) and every repository sits at a different point on each. The fix is a generated, checkable record of what the repository actually runs plus a build-failing rule for the APIs you are not on yet, and then closing the gap, because every major you are behind makes every agent on the repository worse every day. - **Personalization is a rendering and caching decision before it is a model decision.** The moment the markup depends on who is asking, the cache key changes and a shared route becomes a render per person. The cheap pattern, serving the cached default and swapping it client-side, is a layout shift by construction, and the anti-flicker snippet sold as the remedy trades the shift for a blank screen. The HTTP Archive’s Web Almanac found in 2025 that 81% of mobile pages achieve good CLS against 77% for INP and 62% for LCP, with 48% passing all three, so a personalized surface that fails CLS is failing the easy one deliberately. The cold start is the majority of traffic rather than an edge case, consent is an input to the render rather than a banner over it, and the only honest measurement is a permanent holdout against the best default. - **Buyers research vendors through ChatGPT, Perplexity, Claude and Gemini** before talking to sales. 2026 surveys of B2B software buyers put roughly half starting research inside an AI chatbot more often than a search engine, around 7 in 10 using one somewhere in the process, and a majority reporting they picked a different vendor than planned because of what the chatbot said. At the same time about half of B2B tech brands have no citations at all across ChatGPT, Perplexity and Gemini, which means the shortlist is being drawn before those vendors know a buyer exists. Your product needs to be operable by agents and visible where AI answers. That is a Frontend job. - **The org got smaller and the Frontend queue did not.** The Israel Innovation Authority’s 2026 annual report recorded roughly 3,500 fewer people in R&D roles, the first decline in a decade, with R&D’s share of high-tech employment down from 51% to 49% while product roles rose to 24%. The half of the org that files Frontend asks grew as a share of the company and the half that can merge them shrank, which is why a headcount cut does not shorten the queue. The honest counterweight, reported by Calcalist and Ynet, is that a lot of what is attributed to AI efficiency is really the cost of an Israeli employee, so the purchase has to stand on the queue rather than on the story about the cut. - **Nobody can tell you yet how much of an agent-written codebase you hold copyright in.** The US floor is settled: the Supreme Court denied certiorari in Thaler v. Perlmutter on 2 March 2026, leaving the human-authorship requirement in place, and the Copyright Office makes an applicant exclude more-than-de-minimis generated material and explain what the human contributed. The unsettled middle is how much human involvement counts, and every answer to it needs a per-change provenance record that cannot be reconstructed later. We build the record and leave the legal conclusion to counsel. - **A workshop that leaves nothing in the repository does not survive the month.** DX’s research across 400+ companies puts the median pull request throughput gain from AI coding tools at 7.76%, and METR’s randomized trial had developers run roughly 19% slower while believing they were 20% faster, which is why a post-session satisfaction score is not evidence. Our sessions end with a context file, a skill and a guard committed to the team’s own CI, one named owner, and a follow-up that reviews real merged pull requests. ## Services Three services. Each can open a relationship, each upsells the others, and the Factory is the center of gravity. - [Frontend Delivery Factory, the flagship](https://enpitech.dev/frontend-factory): Delivery infrastructure installed on your codebase: guardrails, evals, agent tooling, design-system enforcement, AI context. Operated by our forward-deployed engineers until your team owns it. The outcome: everyone in the org turns ideas into merged production PRs, not just the Frontend team. Phased fixed-price deployment: install, operate, teach, hand over. This is about how your org ships. - [Frontend AI](https://enpitech.dev/frontend-ai): AI capability in and around your product, for both of its audiences. For human users: generative UI, in-product AI agents on your own data, smart search, document processing, personalization. For AI agents: MCP apps and MCP-UI, WebMCP, agent-ready interfaces, AI discoverability (AEO/GEO, agent-readable content, NLWeb-class standards), agentic commerce, agent safety. Fixed-price scoped builds. This is about what your product does. - [Training](https://enpitech.dev/ai-workshops): Private, custom workshops on your own codebase: AI-assisted Frontend delivery, the factory method, the agentic web, modern web engineering. For engineering teams and, increasingly, for the non-engineers the factory unlocks. Hands-on, on your real stack, and the team ships something real in the room. Private B2B only, no open or public courses. [Forward deployed engineers](https://enpitech.dev/forward-deployed-engineers) are a delivery model rather than a fourth service: AI-native senior Frontend engineers embedded in your team on a monthly retainer, 6-month minimum, mid-senior to senior only. They work inside your organization rather than beside it, ship production code from the first weeks, and install the factory while they ship, so every embedded engineer is a soft factory install. When one engineer is no longer the right size, the engagement upgrades into a full factory deployment. Choosing between us and the alternatives is a fair question and it has its own page: [the six ways to unblock Frontend delivery, compared](https://enpitech.dev/frontend-delivery-options). Opening more Frontend reqs, staff augmentation or an agency, rolling out coding agents, buying an AI code review tool, having the internal platform team build it, or installing a factory. Each one is compared on what you buy, what it fixes, where it stops, what is left when it ends and when it is the right call, and four of the six are things we do not sell and do recommend for the teams they fit. Short version: if the backlog needs Frontend judgment, hire. If it is a bounded project, contract it. If reviewers are slow because the review itself is hard, buy the review tool. If your platform team has capacity this quarter, have them build it. If other departments keep queueing small asks behind the Frontend team, none of those clear it, because the constraint is who is allowed to merge rather than how much the Frontend team can merge, and that is the case a factory changes. ## Stack & expertise (2026) - React 19, React Server Components, React Router v7, Next.js App Router, TypeScript - Vercel AI SDK 6, AI Elements, json-render, streaming UI, tool-use UI, partial hydration - Claude Code, Claude Agent SDK, Anthropic Agent Skills, Claude Opus 5 / Sonnet 5 / Haiku 4.5, Computer Use - Model Context Protocol (MCP): custom enterprise MCP servers, MCP clients, MCP Apps with rich UI, gateway and auth patterns - OpenAI Realtime API, OpenAI Agents SDK, WebRTC voice agents, conversational web flows - A2UI for cross-platform generative UI. Dated, because the version numbers mislead: on 2 November 2026 the production release is v0.9.1, and v1.0 is a release candidate whose stabilization gate is renderer ports, which the project has not declared met. Created by Google with contributions from CopilotKit and the open source community, and now at a2ui-project - A2UI component catalogs authored from the client’s own design system, which is where the work actually is: the agent can only request pre-approved components. The v1.0 candidate adds strict catalog resolution with no fallback, forbids fetching an external catalog reference over the network, and requires catalogs and renderers to carry accessibility attributes through to ARIA, Flutter Semantics and the native mobile accessibility layers - AG-UI (Agent User Interaction Protocol) for streaming an agent run to the Frontend over HTTP, SSE or WebSockets - Agent UX: streaming tool-call visibility, step-level intervention, approval gates on irreversible actions, confidence and uncertainty signals, human-in-the-loop and human-on-the-loop interface patterns - WebMCP (declarative and imperative APIs) and the MCP-B polyfill for browser agents. The declarative path is four HTML attributes and no JavaScript: `toolname` and `tooldescription` on a form to register it as an agent-callable tool, `toolparamdescription` per control to describe it in the generated input schema, and `toolautosubmit` deliberately left off anything that creates a lead, spends money or cannot be undone - Lighthouse's Agentic Browsing category, added in Lighthouse 13.3 in May 2026, which put agent readiness inside Chrome DevTools: a filtered subset of the accessibility-tree rules, Cumulative Layout Shift, an `llms-txt` format check that fails a file whose links are not in Markdown link syntax, and the informative `webmcp-form-coverage` and `webmcp-registered-tools` audits. We treat passing it as hygiene held true by a CI check, and we are explicit that it measures declarations rather than whether an agent can finish anything in your product - Agent-to-agent (A2A) protocol for cross-organization agent coordination - Universal Commerce Protocol (UCP) and Agent Payments Protocol (AP2) for agentic commerce and agentic checkout, with AP2 now governed by the FIDO Alliance rather than by a single vendor (Google donated it on 28 April 2026 alongside around 60 contributing organizations including Mastercard, American Express, PayPal, Adyen, Coinbase, Intuit, Salesforce and Worldpay), and x402 for per-request machine payments carried over HTTP 402 - assistant-ui, CopilotKit for in-product AI surfaces - Agent fleet operation: parallel and background agents (Claude Code Agent Teams, Cursor parallel composition, Copilot `/fleet`, VS Code multi-agent), worktree isolation, merge-side guards and review agents sized for fleet volume - Spec-driven development (SDD) for coding agents: executable specs, acceptance criteria as guards, agent-run tracing and the evidence trail an ISO 42001 / NIST AI RMF / SOC 2 review asks for - Context engineering, AGENTS.md / CLAUDE.md authoring, prompt libraries - LLM observability and evals (Langfuse, custom eval harnesses) - Playwright, Vitest, GitHub Actions CI - Delivery measurement: baselines taken before install, merge-side metrics (guard catch rate, review rejection rate on agent output, merged volume from outside the Frontend team), throughput read beside stability rather than instead of it - Design-system enforcement for coding agents: tokens and usage rules committed as agent context, DESIGN.md alongside AGENTS.md and CLAUDE.md, W3C DTCG token export, component registries and Storybook metadata served to agents over MCP, CI checks that fail raw values, off-scale spacing and hand-rolled duplicates of existing components - Security as a merge gate: taint paths from request data into DOM sinks, `dangerouslySetInnerHTML` and raw `innerHTML` behind an explicit allowlist, CSP and security-header assertions tested rather than documented, secret scanning on the built bundle, dependency and supply-chain checks on what agents add to `package.json`, and provenance on agent-written code so authorship and review are answerable later - Accessibility as a merge gate: automated axe and Playwright checks in CI, WCAG 2.1 AA and EN 301 549 criteria wired as guards, keyboard and focus-order regression tests, Storybook accessibility states, and the WCAG 2.2 criteria no DOM scan can decide asserted as composition and flow tests (focus visibility with the real sticky chrome mounted, a single-pointer path for every drag interaction, help placement and redundant entry across a flow, target size enabled explicitly rather than inherited) - Test quality measured rather than counted: coverage demoted to locating code nothing has ever executed, mutation score on the files a pull request changed with a break value a named human chose (StrykerJS ships break null, which never fails a build), per-test coverage analysis so a survived mutant is distinguishable from an uncovered one, per-file rather than project-aggregate thresholds once people outside the Frontend team are merging, and no coverage magnitudes quoted from secondary sources - Composition boundaries decided at merge time rather than at deploy time: runtime dependency negotiation treated as a production risk rather than an architecture detail (Module Federation ships singleton false, so two copies of a library is the default and a version mismatch is a console warning in the user’s browser), path-aligned zones used only where the hard navigation at the seam is acceptable, one named owner for the shared layer, and the number of copies of each shared dependency measured from the built output - Discoverability as a merge gate: the route inventory diffed against the base branch so a renamed or deleted public route fails the run without a redirect, internal links resolved at build time, one canonical per route asserted against the route it sits on (the Lighthouse audit returns not-applicable when a canonical is missing, so absence needs a check of its own), noindex reconciled against the sitemap in both directions, title and description asserted as ordinary tests on the routes that matter commercially, and Lighthouse CI assertions extended from a preset rather than hand-listed, because an audit absent from the assertions object is treated as off - Experiment integrity as a merge gate: a stable targeting key asserted for any fractional assignment rather than a value that can change inside a session, the exposure event awaited before any navigation the same change introduces (missed tracking calls are the largest single cause of sample ratio mismatch, and the loss is asymmetric because the control is already on the page), the resolution reason carried beside the variant so a provider outage reads as an outage instead of averaging into a result, anti-flicker treated as a paint regression because an opacity-zero element is not a Largest Contentful Paint candidate at all, and an expiry on every experiment so a flag cannot outlive the decision it was created to make. Assignment belongs at the edge or the server wherever the test redirects. We do not design the experiments, choose the metrics or run the statistics - Content publish gate: the other delivery path, and the one with no merge on it. Which fields a content management system may change without passing a single check is a decision rather than an accident, and the boundary is what a field can break rather than who is editing it. Body text in a slot with asserted bounds and an image with a required alt belong to editors; anything that becomes markup, a URL, a cache key, a title, a canonical, a new locale or a new field type stays in the repository behind the gate. What ships with it: the sanitizer asserted to be running by a test that fails when it no-ops, every slot asserted against its own longest and shortest permitted content rather than its fixture, the organic declarations validated at the edit boundary with the same assertions the merge gate makes, a slug change refused unless its redirect ships beside it, the invalidation treated as delivery rather than a webhook fired into the dark, and the content model committed as code so a field type change is a reviewed diff with its migration. We do not choose your CMS, run your editorial calendar or staff your content team - Age assurance gate: the EU age check, and why it is a Frontend project rather than a legal one. The default transport for a standards-based age check is the W3C Digital Credentials API, which is not Baseline and has no Firefox entry, and the OpenID fallback cannot carry a Zero-Knowledge Proof, so the users on the fallback path present a single-use proof out of a batch of thirty per quarter and reveal which Attestation Provider signed it. The capability check throws where the interface is undefined, the request must sit inside a user gesture rather than a loader or an effect, an opaque origin is rejected outright, and the trust list behind the whole thing is an HTTP GET whose outage policy somebody has to choose. What ships with it: both presentation paths exercised in CI rather than only the one the authoring machine runs, the capability check covered by a test that runs with the interface undefined, the request asserted inside a real gesture with the abort wired to navigation, trust-list validation asserted to fail closed, no demo endpoint reachable from a production build, telemetry asserted to carry no stable identifier, and an alternative route asserted to exist. We do not decide whether you are in scope, choose your Attestation Provider or sign off your DPIA - Opt-out signal gate: browser opt-out signals, and why they are Frontend work rather than a tag manager setting. Global Privacy Control is standards-track and not Baseline: the web-features dataset records support for Firefox 120 and Firefox for Android 122 and nothing else, with Chrome, Edge and Safari all recorded as not implemented, so the code path a growing list of US state statutes obliges you to honour has been exercised on your site by a self-selected handful of privacy-tool users and by nobody else, which is exactly why it has never been tested. California's Opt Me Out Act, signed 8 October 2025, requires browsers to offer the setting from 1 January 2027, so the duty is old and the traffic is new, on a date you can plan against. The mechanisms are all in the repository: the header carries one permitted value and a plain existence check reads "not opted out" as an opt-out, a request header that changes the response is part of the cache key or your edge serves the wrong document to the wrong person, an intermediary may insert the header so the production case never comes from a browser, and the DOM property is frozen at top-level navigation so a single-page application reads a choice the person may have changed. What ships with it: the flows your pipeline already drives replayed with the preference set using the WebDriver commands the specification itself defines, the exact-value comparison asserted, the variance asserted to be in the cache key, the edge-inserted case exercised, the disclosure asserted to render in both states, the published support file parsed and asserted to match the behaviour, and the signal asserted never to leave the page inside a measurement payload. We do not decide which statutes reach you, classify your vendors or draft your notice - Issuance path gate: shrinking certificate lifetimes, and why they are Frontend work rather than an ops ticket. The CA/Browser Forum Baseline Requirements step the maximum validity period of a subscriber certificate from 398 days to 200 on 15 March 2026, to 100 on 15 March 2027 and to 47 on 15 March 2029, and step the reuse period for domain validation data on the same dates to 200, then 100, then 10 days, so a certificate expires roughly four times a year from March 2027 and the proof that you control the name can no longer be banked. The duty is on your certificate authority; what lands on you is the rate, against hostnames a Frontend org created without filing a ticket: a preview domain per pull request, an asset host, a docs host, a component explorer, an embed host, a host that exists only for an agent. The mechanisms are in the repository: both website validation methods fetch a file under a well-known directory and require a 2xx with the challenge value in the body, which a catch-all route satisfies with an HTML document, so the failure is a success with the wrong body rather than a 404; a redirect on that path must be a protocol-layer 301, 302, 307 or 308, so a meta refresh or a client-side navigation is not a redirect at all; the challenge must be corroborated by five remote network perspectives across two Regional Internet Registries from 15 December 2026, so anything geo-dependent on that path fails a check a local curl cannot reproduce; DNSSEC validation errors have not been permission to issue since 15 March 2026, so a broken signing chain turns renewal into a silent no-op; and from 15 March 2027 the accounturi and validationmethods CAA parameters must be processed per RFC 8657, which is a declaration with no consumer inside your repository. What ships with it: one hostname inventory with a named owner, the validation paths asserted to return the challenge value and to survive a catch-all, redirect behaviour on those paths asserted at the protocol layer, the paths fetched from more than one network location in CI, remaining validity exported as a number your alerting reads, CAA and zone signing state committed and asserted, Strict-Transport-Security asserted deliberately because includeSubDomains removes the click-through, and the renewal exercised end to end on a schedule rather than trusted. We are not your certificate authority, we do not run your PKI and we do not choose your certificate lifecycle platform - Platform withdrawal gate: a long-standing web platform capability being taken away, and why a clean code search is the wrong reassurance. Client-side XSLT is being removed: the WHATWG DOM and HTML standards carry a critical notice that the implementations are highly susceptible to memory safety vulnerabilities and that JavaScript is the safe replacement, while adding that removal "is a long process that takes many years", and the shipping engine has a date instead. The milestone figures in circulation for the Chromium removal are 155 and 158 and they disagree while agreeing on 17 November 2026; 155 shipped on 6 October 2026 and is already retired, 158 is the release dated 17 November 2026, and the compatibility data still records the interface and all nine members as deprecated and supported with no removal recorded against any engine, so a team that planned against 155 has watched its own deadline pass with nothing happening. The feature has two halves and only one is JavaScript: an XSLTProcessor a code search finds, and an xml-stylesheet processing instruction it cannot, which is where the sitemaps, feeds and XML endpoints are. Three instruments miss it: the removal version is empty in every compatibility entry so no check can derive the date, Baseline false means implemented everywhere and being withdrawn rather than not ready yet so a readiness rule reads the case backwards, and the warning lands in a console no pipeline reads. The SEO half is the reassuring half: no crawler or answer engine ever ran the transform, so a sitemap that stops rendering prettily costs nothing in ranking and costs you the page your own team opens, while an XML surface a customer opens is a product outage with a public date. What ships with it: an inventory of the XML your origin serves built by walking what is reachable rather than by grepping, each entry labelled for a colleague or a customer, the processing instruction reviewed as a committed declaration, customer-facing transforms moved to a processor you control and serving HTML, the rest left alone as a written decision, and the warning channel collected so the next removal is a failing check. We do not run your engine and we do not control the schedule - Test quality as a merge gate: mutation checks on the paths where a silent break costs something, assertion quality on changed lines so a test that renders and asserts nothing does not pass as coverage, test impact analysis, flaky tests quarantined with an owner rather than retried until green, and snapshots never accepted in the same run that changed the component - Performance as a merge gate: per-route bundle budgets the build fails on, duplicate dependency detection, client and server component boundary review, and Interaction to Next Paint, LCP and CLS asserted against real interactions rather than a synthetic homepage score - Agentic development platform work for Frontend: golden paths rewritten as executable contracts a coding agent dispatches against, tool gateways and scoped credentials, sandboxed and reproducible agent runs, autonomy bounded per repo, and the whole layer installed inside an existing internal developer platform rather than beside it - Supplier-delivered Frontend brought under the same merge gate: an agency, offshore or contractor pull request judged by the artifact rather than by a process the client cannot see, licence and provenance checks on what an outside contributor introduces, scoped execution for a branch from outside the org, and a definition of done written as the gate instead of a demo - The unapproved AI path brought under the merge gate: secret detection that fails the run rather than filing a ticket, provenance recorded at merge because authorship detection does not work, licence and dependency checks on whatever a pasted block introduces, and the approved path made faster than the unapproved one by removing the review queue behind it rather than by writing a policy. We gate the merge and we do not run anything on your endpoints or monitor your people - Model lifecycle for the delivery system itself: a generated inventory of every model identifier CI, review bots, eval judges and generators call, identifiers pinned to dated snapshots rather than moving aliases, the calibration set re-run as the gate on a swap so a guard cannot quietly change its judgement, and retirement dates carried per model and platform pair with an owner rather than in an inbox - The size of the prize bounded before the rollout is expanded: the share of an engineering week that was ever writing code read off a firm-level estimate, the arithmetic ceiling that share puts on any authoring-side gain, the review queue the faster half feeds, and the baseline taken on the client's own repository before anything is installed, because that is the only number a board can be given - Ownership and accountability kept intact while the contributor set widens: an owner of record per Frontend surface with the paging path, the error budget and the rollback decision following it rather than following whoever merged last, code owners declared in the repository instead of in a rota, the owning team's approval required so speed cannot route around it, scrutiny attached to the change rather than to the person so a major contributor does not become the queue again, quality-control effort pointed at the surfaces with many low-ownership contributors, and the contributor distribution per surface measured in the audit before anything is installed - Bringing an existing AI-assisted codebase under guard: agent-authored code mapped in the audit, issue classes triaged by what they actually cost, and guards ratcheted on changed lines so remediation rides the roadmap instead of becoming a cleanup project - EU AI Act Article 50 transparency as a Frontend layer: AI interaction disclosure that lives in the component, machine-readable marking of synthetic output, provenance metadata that survives storage, export and embedding, and deepfake and public-interest labels rendered where the person actually sees them - Design-tool authored pull requests brought under the same gate: Figma Make's GitHub integration and Config 2026 Code Layers treated as authoring surfaces rather than exceptions, real component registries and tokens served to the tool before it writes, prototypes from Lovable, v0, Bolt or a from-scratch Figma Make build treated as specifications to rebuild against your components rather than branches to merge, and authorship recorded at merge so provenance survives multiple authoring tools - Agent spend as governed infrastructure: gateway-metered cost attributable per repo, team, run and model, budgets that stop or downroute a run rather than letting it finish quietly, model routing as policy, deterministic cheap checks ordered first for cost as well as quality, and cost per merged pull request reported beside guard catch rate - Legacy Frontend migration and modernization run through the factory: AngularJS, Angular, Vue, Backbone, jQuery and untyped legacy React moved onto React and TypeScript incrementally, change sites located by AST tooling and codemods before an agent writes, characterization tests written against the old implementation first so parity is a test rather than a review opinion, slices shipped route by route behind the running app with the boundary held by routing, each slice separately revertable, design system migrated first so drift does not simply move framework - Agent traffic as a product surface: purpose-aware handling of search, agent and training crawlers, server-rendered product truth an agent can read without executing the bundle, capability declared as callable tools over WebMCP or an MCP endpoint rather than left as a page to scrape, agent identity verified at the application layer instead of by user-agent string, explicit confirmation steps in front of irreversible agent actions, and agent sessions instrumented as their own funnel with retrieval, representation and action measured separately - Verification capacity as the thing being engineered: a baseline taken in the audit of what a senior actually spends review attention on, guards that decide before a human is asked and return a specific reason to the author, context and skills committed to the repo so corrections are not re-explained per session, bounded tasks with written acceptance criteria, review routed by what needs judgment rather than by arrival order, and the resulting ratio always reported beside guard catch rate and review rejection rate so it cannot improve by reviewing less - Injection-resistant agent interfaces for products that ship an agent: untrusted content isolated from the user's own instruction and never rendered as markup, tools scoped per surface rather than granted globally, confirmation steps that render the real parameters of an irreversible action, provenance and untrusted-source marking in the UI, a designed degraded mode for when retrieval or tool use has to be switched off, the agent acting as the signed-in user with no privileges of its own, a generated capability inventory and a replayable tool-call log, and injection cases run as evals in CI beside the quality evals - Open source licensing and IP as a merge gate: an inventory of the full dependency graph before anything is switched on, the client's own policy encoded as allowed, denied and review tiers, transitive packages treated the same as direct ones, licenses that change under you in an upgrade caught at PR time, an SBOM produced by the build for every release, code that arrived outside a package manager flagged for provenance, exceptions recorded with a reason and an owner, and the whole gate ratcheted onto changed lines - MCP app distribution and selection: tool sets scoped around user jobs rather than mirroring a REST API, descriptions and parameter schemas written for a model as the reader, annotations declared honestly so write and destructive actions are marked, narrowest-scope auth that fails legibly, MCP Apps UI resources for tasks that have to finish in the conversation, submission prepared against each platform's published guidelines, and tool-selection evals in CI over the phrasings real users actually type - Dependency provenance as a pre-install gate: every added package resolved against the registry with first-publish date, download history, repository link and maintainer count, lifecycle scripts off by default for new dependencies and enabled only by allowlist, installs run without credentials or publish tokens on unreviewed branches, lockfile diffs reviewed as code, the approved component and library inventory served to agents as context so invented names have nowhere to come from, and unresolved names logged with the prompt that produced them - On-device and hybrid inference in the browser: Chrome's built-in AI and the Prompt API used as an upgrade path behind a hosted default, capability detected per feature at call time rather than by user-agent, one typed and schema-constrained contract shared across both paths, model-download and unsupported-device states designed rather than discovered, local redaction passes ahead of hosted calls, and privacy copy bound to the path that actually ran - Delivery pipeline capacity engineered for agent volume: cheap deterministic checks ordered ahead of expensive Frontend suites, test impact analysis so only what a change affects is run, a merge queue that batches and bisects with the batch size widening under load, per-run isolated environments instead of one shared staging, flake quarantine as a prerequisite for bisection, and cost per merged pull request reported beside guard catch rate - Verified agent identity turned into product policy: Web Bot Auth signatures accepted from the edge and mapped onto your own authorisation, tiers for unverified callers, verified operators and agents acting on behalf of a user, delegated access scoped to that user with consent recorded and revocable, legible degraded responses instead of silent blocks, per-operator rate and spend limits with an operator-scoped kill switch, and confirmation rendering the real parameters of anything irreversible - AI-built internal tools brought onto a governed codebase: triage by whether a tool touches production data, customer-facing surfaces, credentials or a second person's work, an identity boundary so it calls your services as a signed-in person rather than with a token pasted into a client bundle, a named owning team, the seven guards on the way in, a log, and the clusters of duplicate tools read back as a missing product feature rather than as a charge sheet - Agent operability of the flows you choose to open: real semantics, accessible names and stable identity on interaction targets, interruptions resolved before a surface claims to be ready, multi-step state kept server-side and re-enterable, machine-readable validation attached to its field, idempotency keys and a confirmation rendering the real parameters of anything irreversible, capability declared as callable tools over WebMCP or an MCP endpoint instead of a UI an agent must drive, and agent success measured by whether the intended state change happened - The agentic-web standards position read from the primary documents rather than the announcements: WebMCP's actual status as a Web Machine Learning Community Group draft with its normative interface on document.modelContext, the engine reality that Chrome 149 and Edge 150 run origin trials while Safari and Firefox have standards-positions issues and no implementation, the proposed W3C Agentic Web Working Group read as the unapproved draft charter it is, and the six things that charter puts out of scope (model APIs and inference, cryptographic authentication primitives, crawler controls, agent to server communications, content provenance and disclosures, and bot detection) which therefore stay the site owner's own Frontend and edge work, all of it carried by a capability layer whose tool registration is a replaceable adapter rather than the implementation - API contract drift caught as a Frontend merge gate: contracts generated from the provider rather than hand-maintained, consumer-breaking differences between the contract in a pull request and the one the application was built against failing the build with severity classified so an added optional field costs nothing, mocks and test fixtures generated from that same contract so a fixture cannot drift away from the service it stands in for, the fields the application actually reads recorded so a provider can tell a safe deletion from an outage, and recorded contracts with a scheduled check for the vendor APIs you do not control. We build and operate the gate inside your pipeline against your specs and 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 contract. - Agentic commerce built behind your own capability layer: the domain rules that decide what a cart, an order or a plan change actually is kept in your product, expressed as declared capabilities with honest annotations on anything irreversible and an idempotency key on every one, with ACP, Google's Universal Commerce Protocol and AP2 treated as adapters over that layer so the standard that loses costs an adapter rather than a rewrite, plus the assistant to product handoff: intent carried across the boundary instead of dropped, a landing surface that answers the claim the visitor arrived with, and the same product truth rendered for an assistant and for a page. 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. - Debuggability of agent-written code decided at merge time: source maps built and uploaded per release so a Frontend stack trace is symbolicated rather than naming a variable inside a bundle hash, release and commit stamped into client telemetry so a production error resolves to the pull request that caused it, a correlation id carried across the boundary so the client event and the server trace are one story, a designed error state on every new user-facing surface instead of a blank region that produces no alert, and a caught error required to be handled or reported and never swallowed into a null, which is the most common way an agent makes a failure invisible while keeping the suite green. Ownership routed structurally from module boundaries rather than from commit authorship, because the commit author now records who ran the agent. Shortens how long you are inside an incident, and does not claim to reduce how many you have. - Memory for in-product AI features built as owned product state: scope written onto the record at creation across user, workspace and system rather than filtered at read time, because a memory written in one person's session and retrieved in a colleague's renders as a fluent helpful sentence rather than a visible bug and is found by the person it was disclosed to. User-visible controls to inspect, correct and delete what the product remembers. Erasure that reaches the derived copies, the embedding, the cache, the prompt logs, the eval set built from production traffic and backups under a documented restore-time policy, since an embedding of personal data is still personal data. Retention set per scope with expiry as the default, and personal values redacted at write time so the analytical record survives while the personal data does not. - Browser support decided in the repository rather than in somebody's head: the target derived from your own analytics rather than a default, expressed once as a Browserslist query that the bundler, the prefixer and the linters all read, with Baseline making it machine-readable (Newly available meaning interoperable across Chrome, Edge, Firefox and Safari, Widely available meaning it has been for thirty months). The gate classifies rather than forbids: a feature used as an enhancement behind a feature query with a real fallback is allowed and nothing happens, a hard dependency outside the target with no fallback stops the run, and a feature inside the target that behaves differently is routed to the browser grid instead of pretended about. It ratchets on changed lines with the exception count reported rather than hidden. The larger half of the value is that the target becomes context the coding agent reads, so it proposes what you can ship and a class of pull request stops being written. We are not a browser testing vendor and we do not sell or run a device grid. - Accessibility of an AI interface at runtime, which is a product problem rather than a merge gate: streaming announced on sentence boundaries into a politely marked live region so only new text is read, a composing state announced once so silence does not read as a broken product, focus held steady while controls that did not exist at submission appear mid-stream, and in a generative interface the model selecting from a typed component registry with schema-validated props rather than emitting markup, with no raw markup escape hatch, colour from tokens, heading level derived by the component, ids generated rather than supplied, and ordering and landmarks owned by the container your team wrote. Accessibility assertions go into the eval set, which is the only layer that can test generated output. We are not an accessibility auditor and we do not issue conformance statements or a VPAT. - Frontend authorization checked at merge time, because the Frontend is a copy of a policy the server owns and nothing keeps the copy true: permission-dependent rendering routed through one typed capability layer generated from your server policy rather than hand-maintained, a boundary rule failing the run when a role name or plan tier is compared as a string anywhere else, protected actions asserted in both directions so the control is absent for a role without the capability and the request is refused when it is issued anyway, since hiding a control was never access control, a new route or protected action with no entry in the access map stopping the run, and the denied state designed rather than hidden so a person who cannot do something sees why and what to do next. Starts as an inventory and ratchets onto changed lines. The capability list doubles as agent context, so a new screen asks for the right capability instead of copying the check next door. We build and operate the gate inside your pipeline against your own policy. We are not a security auditor, we do not run penetration tests, we do not design your permission model, and we do not certify anyone. - Usage limits rendered as a product state rather than a billing setting, for AI features that are metered: the balance denominated in the user's own work rather than in credits, an estimate and an explicit approval before an action whose cost varies by orders of magnitude, a designed wall that preserves what the user typed, names whose limit was reached, theirs, their workspace's or their plan's, and offers a real next step rather than a toast, honest labelling when a cheaper model is substituted because latency, formatting and refusal behaviour move with it, a warning before the limit expressed in work remaining rather than percentage remaining, and a separate administrator surface with allocation, per-team visibility, alerts before a pool empties and caps. A commercial entitlement is not a provider rate limit and the copy never conflates them. We build the surfaces, the estimation and the states inside your product. We are not a billing platform, we do not resell inference, we do not set your limits, and we do not price or package your product. - Version truth made checkable so coding agents stop generating for a stack you do not run: the record of what the repository actually runs generated from the lockfile and the configs rather than typed into a context file, the idioms in use and the ones deliberately not with reasons attached, the APIs you are not on yet expressed as restricted-import rules that fail the build, and deprecations you have decided to clear ratcheted on changed lines - Framework and dependency major upgrades run as factory slices: the audit sizing the mechanical share against the ambiguous share before anything starts, one major at a time, codemods that propose while the guards decide, behavioural parity defined by the seven guards rather than by a review opinion, and no snapshot accepted in the run that changed what it snapshots - Personalization built as a rendering layer rather than bought as a platform: a cacheable shell with named personalized slots that declare their inputs, their empty render and their reserved space, decisions taken on the server or at the edge so they arrive in the first byte, consent as an input to the render path, a permanent holdout measured against the best default, decision inputs recorded so a render can be reconstructed, a ‘why am I seeing this’ a user can open and a permissioned view-as for support - The Frontend artifacts that execute outside your origin brought under the same gate: a browser extension, a desktop or Electron client, an installed PWA and an embeddable widget are each a release you cannot take back on the next page load, so each gets an inventory entry with a named owner, pinned versions, an SBOM produced by the build per artifact rather than for the web bundle alone, declared permissions diffed on every change, secret scanning on the shipped package rather than on the repository, an update channel that can be halted mid-rollout, and a kill path that has been exercised rather than written down. The EU Cyber Resilience Act's reporting duties have applied since 11 September 2026, including to products already on the market, with the remaining obligations from 11 December 2027; the Commission's non-binding guidance of 27 July 2026 turns the scope question on where the software runs, and whether a given artifact is in scope is a product-specific legal question rather than ours. - Service worker and offline behaviour treated as release surface rather than a caching detail: navigations network-first with the cached shell as the offline fallback, cache names carrying the build identifier and old caches pruned on activate after the new worker has control, a worker script that is never read from the HTTP cache, a version handshake so a stale document reloads instead of requesting a chunk that is gone, a deploy test that installs the previous build's worker and asserts a client reaches the new one without clearing site data, and an unregister path shipped in the version that is already out there rather than in the fix. - Publishing an embeddable widget or SDK onto other companies' pages, which makes you the third party every one of our third-party gates is written about: a small loader with the heavy part fetched on demand and an API that queues early calls, rendering isolated in a shadow root with one shared stylesheet or in an iframe where content must not be reachable from the host, no inline script or style because the host's CSP will block it, immutable versioned URLs with integrity hashes and never a mutable latest, a size and timing budget asserted in CI against a page shaped like the customer's, and change management at an API's pace with a deprecation window and a usage census taken from real sessions. - Evidence for AI-assisted delivery claims, built for the person holding the budget rather than for a dashboard: a baseline taken before anything is installed, provenance recorded at merge per change (tool, model, run, context-file revision, approver), guard catch rate and review rejection rate on agent output, cost per merged pull request instead of cost per seat, merged volume from outside the Frontend team, and change failure rate split by whether the change was agent-authored. The limits are stated with it: there is no control group in your own organization, so the defensible claim is a before and after against a named baseline with the confounders written down, never an attributed percentage. - Delivery infrastructure that stays yours: context files, skills, guards, evals, codemods, gateway policy and telemetry schema committed to your repository and running as your CI jobs, with no hosted service of ours in the path of a build. The agent-facing formats are stewarded by the Linux Foundation's Agentic AI Foundation (MCP, goose, AGENTS.md) rather than by any one vendor, so AGENTS.md is kept as the source and tool-specific files as thin shims, which makes the agent a swappable part and the standards the durable asset. - Measurement for AI answer-engine visibility that survives a method check: a versioned prompt set written from real buyer language, repeated runs with the variance reported beside the mean, results kept per engine and per reasoning setting rather than averaged into one score, mention and citation and position recorded separately, plus the half that is a server log rather than a sample, which is verified retrieval-bot traffic per route and assistant referrals treated as their own funnel with their lossiness admitted. - Merge acceptance engineered as the outcome rather than reported as a dashboard number: the share of pull requests merged inside thirty days taken as a baseline before anything is installed and split by whether an agent authored the change and by which team opened it, kept strictly apart from a tool’s suggestion acceptance rate, guards ordered ahead of human review, and every rejection turned into a permanent check so a person does not make it twice - The inputs an engineering manager needs once the diff stopped being evidence about its author: provenance written per change at merge so an engineer’s own work is distinguishable from their supervision of an agent’s, guard authorship and context ownership recorded as artifacts somebody can be credited for, review outcomes attributable, with the career ladder and the calibration meeting left to the client - Engine-agnostic agent practice as the teachable layer: task scoping an agent can finish and a human can review, context file authoring, diff review discipline at the level that catches the wrong thing rather than the ugly thing, stopping a run instead of correcting it, and guard placement, all taught on whatever tool is installed with the artifacts committed in portable formats so a change of engine does not retire the training - The agent harness itself treated as privileged code rather than as developer dotfiles: ownership over the instruction files, hook scripts, server and tool declarations and CI workflow files, mergeability checks pinned and required from the default branch so a branch cannot define the gate that grades it, central enumeration of the servers and hooks a run may use with project-level auto-approval off, no repository-level override of an endpoint, a proxy or a credential, and CI normalisation that fails invisible and bidirectional control characters in anything an agent reads - Handover designed around the person who will own it: the guard set, the committed context and a measured baseline handed to a named internal owner, because an enablement role with no authority over the merge gate is the predictable stall and the merge gate is where this work exists or does not - Storyblok and headless CMS, design systems, performance optimization ## Ideal customer profile - **Primary: tech companies with real engineering orgs.** 30-300 engineers. Buyer is the CTO or VP R&D. The Frontend team is a visible bottleneck, other departments queue "small" Frontend asks, and AI coding tools are adopted but their output cannot be safely merged. They buy Factory deployment, with training as an entry point and embedded engineers as reinforcement. - **Secondary: early-to-mid stage product companies.** Seed to Series B, building serious web products and shipping at investor pace without enough team. They buy embedded AI-native engineers and scoped Frontend AI builds, then a factory install as they scale. - **Tertiary: tech-enabled businesses.** Companies whose core business is not software but whose customers live in their web product (e-commerce, tourism, healthcare portals, fintech tools), with small internal teams of 2-15 engineers. They buy Frontend AI as fixed-price scoped builds. - Located anywhere; primary regions Israel, US, EU. Remote delivery. Primary working language English. ### Common triggers - "Frontend is our bottleneck, everything waits on that team" - "Our backend engineers / PMs / designers want to ship UI but nothing they produce gets merged" - "We rolled out AI coding tools and code review became the traffic jam" - "We need our product to work with AI agents and don't know where to start" - "We want AI features in the product but the team is fully booked" - "We need senior Frontend engineers who ship from week one" ## Frequently asked questions ### What is the Frontend Delivery Factory? Delivery infrastructure we install on your codebase so people outside the Frontend team can ship production Frontend. In practice that means structured specs coding agents can execute, AI context committed to the repo, guards that decide mergeability before a human sees the PR (design system, accessibility, security, test quality, performance budget, Storybook states), and senior engineer review at the merge point. Our forward-deployed engineers install it, operate it, teach your team, and hand it over. Ownership is the deliverable. ### Frontend is our bottleneck. Why not just hire more Frontend engineers? Because the queue is not made of missing hands, it is made of missing permission. Every "small" UI ask from product, marketing and customer success 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, after ramp. The factory changes the shape instead of the size: the review standards, design-system rules and production safety your seniors carry in their heads become guards that run on every agent run, so people who could never merge Frontend start merging it. More output from the org you already have, and your seniors go back to the work only they can do. ### Our AI-generated UI keeps drifting from the design system. Can the factory stop that? Yes, and it is why design-system enforcement is a guard rather than a review comment. An agent given a screenshot and a prompt will 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 and then 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 values, off-scale spacing and hand-rolled duplicates of existing components fail the run and never reach a human reviewer. ### Should we write a DESIGN.md, and is that enough to keep agents on-system? Write one, and no, it is not enough on its own. DESIGN.md is Google Labs' format for handing a visual identity to a coding agent: machine-readable tokens in YAML front matter, human-readable rationale in the markdown body underneath, one file that serves both audiences, with a CLI that lints structure and WCAG contrast and exports to Tailwind or W3C DTCG tokens. It is a genuinely good artifact and it belongs in the repo next to AGENTS.md and CLAUDE.md. The reason it is not sufficient is the thing the CHI 2026 comparison measured: instructing an agent about your design system landed around 71% compliance, injecting the style guide into its context around 85%, and pointing it at a registry of real pre-built components around 95%. Description loses to retrieval, and retrieval loses to giving the agent the actual component. So we do all three layers and then add the one none of them provide: a CI check. Tokens and rules committed as context, the real component registry and Storybook metadata served to the agent over MCP so it queries the true prop API instead of inventing one, and a guard that fails raw hex values, off-scale spacing and hand-rolled duplicates before a human ever opens the PR. A spec tells an agent what you wanted. A gate is what decides whether it got there. ### Figma can open pull requests against our repository now. Does that solve the designer problem or make it worse? It solves the half that was never hard and points a new lane at the half that was. Figma Make's GitHub integration went into limited beta on 28 May 2026: a designer connects a repository, Make installs the dependencies and runs the application on the canvas, they edit the running UI, and the changes accumulate as commits and leave as a branch and a pull request without the designer writing a line. Code Layers arrived at Config on 24 June 2026, putting a cloned repository on the canvas with a live two-way link to the Git-tracked code. Figma is explicit that this does not bypass your engineering guardrails: the change goes through the same CI, the same security checks and the same review as any other commit, and the tool enforces no design-system governance of its own. That is a promise about your pipeline rather than theirs, and it is the correct design. It also means that if the thing standing between a branch and `main` in your org is a senior Frontend engineer's attention, a design tool that can generate branches has just pointed a new 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. Our answer is the same as for every other authoring surface. No separate lane and no softened gate, because a guard that yields to the author's job title is not a guard. Tokens and the real component registry served to the tool and to the agent before either writes, design-system, accessibility, security, test-quality and performance checks that fail the run before a human is involved, prototypes from tools that never read your repository (Lovable, v0, Bolt, a Figma Make build from scratch) treated as specifications to rebuild against your components rather than as branches to merge, authorship recorded at merge so provenance survives, and senior review spent on intent. Then a designer's PR is just a PR. ### Will a factory increase our AI bill, and how do we budget agent spend? It makes the bill attributable, which is usually the real question. The spend is real and it moved quickly. Anthropic doubled its own published Claude Code estimate 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, and noted that 90% of users stay under $30 a day, which tells you the distribution has a long tail and that the average engineer is not the risk. Forbes reported on 17 May 2026 that Uber had exhausted its entire 2026 AI budget four months into the year after Claude Code spread across roughly 5,000 engineers, with its CTO confirming the overrun. Neither of those is a story about an expensive tool. Both are consumption pricing landing in a budget line that was modeled like a seat, and a factory widens that distribution on purpose by adding authors to it. So the controls are boring and they are infrastructure. All agent traffic goes through a gateway, so spend is attributable per repo, per team, per run and per model instead of arriving as a single invoice. Budgets sit on repos and teams, and a run that would cross one is stopped or routed to a cheaper model rather than allowed to finish quietly. Model choice is policy rather than habit, so mechanical passes do not run on the expensive model because someone set it once. Cheap deterministic checks run first, which is an economic argument as much as a quality one: a lint, type or design-system failure at ninety seconds costs a fraction of the same failure found by a senior twenty minutes into a review. And the reported number is cost per merged pull request read beside guard catch rate, because cost per seat tells you what you bought and cost per merged PR tells you what you got. The boundary: we build and operate the metering, the gateway policy and the budget guards, we do not resell tokens, we take no margin on your model spend, and we are not your FinOps vendor. ### Is AI-generated code a security risk, and can the factory catch that before it merges? It is, and the part that should worry a Frontend org is more specific than the headline. 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 entire 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 the AI code security problem sits exactly where the people your factory just unlocked are now shipping. The mechanics are mundane and that is the danger: user input reaching the DOM without escaping, `dangerouslySetInnerHTML` reached for because it silenced a type error, a Content Security Policy loosened to unblock a build, an API key that ends up in the client bundle. None of those look wrong in a diff. A reviewer skimming a 400-line agent-authored PR at 6pm will not catch them, and asking reviewers to try harder is not a control. So we treat it the way we treat design-system drift and accessibility: as a guard rather than a review comment. Security checks run on every PR beside the other gates. Taint paths from request data into DOM sinks, `dangerouslySetInnerHTML` and raw `innerHTML` behind an explicit allowlist with a documented reason, CSP and security headers asserted by tests instead of described in a wiki, secret scanning on the built bundle and not only the repo, and dependency checks on anything an agent added to `package.json`. A failure stops the run before a human is involved, and the trace of what ran and what it decided is the same evidence a governance review wants later. To be explicit about the boundary: we build and operate the gate, we are not a security auditor, we do not run penetration tests, and we do not certify anyone. ### Our agents write the tests too and the suite is green. Is that not the guard already? It is the guard everyone believes they have, and it is the first one that stopped working. An agent asked for tests will write tests, and it optimizes for the number you can see at a glance, which is coverage. So you get a suite that renders the component, asserts that nothing threw, snapshots whatever came out and reports 90%, and a flipped comparison operator still passes it. Capgemini's World Quality Report 2025-26 puts roughly 70% of enterprises on AI for test authoring and maintenance, so this is not an edge case, it is most codebases. And the far end of the pipeline shows it. Cortex's Engineering in the Age of AI 2026 benchmark found PRs per author up 20% year over year while incidents per pull request rose 23.5% and change failure rate rose roughly 30%. More tests, more green, more production incidents, which is only a paradox if you think a test count is a safety measure. The Frontend has two specific tells worth knowing. A selector-brittle Playwright test breaks on a refactor and gets repaired by loosening the selector until it passes, which converts a real signal into a permanently green one. And a failing snapshot gets regenerated by the same agent that just changed the behavior, which is the test agreeing with the bug in writing. That second one is why the rule matters more than it sounds: never accept a snapshot in the same run that changed the component it snapshots. So we gate on whether a test can fail rather than on how many exist. Mutation checks on the paths where a silent break would actually cost you, assertion quality on changed lines, test impact analysis so a PR runs what relates to it, and flaky tests quarantined with an owner and a date instead of retried until green. What the guard reports is caught regressions, not tests shipped. The boundary is the same as the other gates: we build and operate it, we are not a QA vendor, and we do not sell test headcount. ### Our AI-written UI works. Why did the app get slower after we rolled out coding agents? Because performance is the other guard teams assume they already have, and the thing they have is a Lighthouse score on a page that never regresses. An agent solves the ticket in front of it and carries no memory of your bundle, so it installs a charting library to draw one sparkline, adds a second date library because it prefers that API, marks a component client-side when a server component would have done, and refetches inside an effect that fires on every render. Each of those is a diff that looks correct, passes review and costs you milliseconds on someone's phone. The measurement is unusually pointed here. CodeRabbit's State of AI vs Human Code Generation report classified issues across 470 open-source pull requests, 320 AI-coauthored against 150 human-only, and found AI-authored changes carried roughly 1.7x more issues overall, with performance inefficiencies appearing close to 8x more often. That is the widest gap in the report, and it lands hardest on the Frontend, because this is the layer where the user's device pays the bill. So the budget becomes a guard in CI rather than a slide in a quarterly review: bundle size per route with a ceiling the build fails on, duplicate dependencies flagged the moment a second one arrives, client and server component boundaries reviewed rather than assumed, and Interaction to Next Paint, LCP and CLS asserted against real interactions instead of a synthetic homepage run. INP is the metric agent-written React regresses first and its good threshold is 200ms. Two things make a budget survive contact with a team: size the ceiling off what your routes weigh today rather than an ideal, and make the override available but recorded, so it bends instead of quietly getting switched off. We build and operate the gate. We are not a performance-audit shop and we do not sell a score. ### We want off Angular and onto React. Can coding agents just do the migration for us? Not on their own, and 2026 gave us both ends of that measured in the same year. IBM Research published ScarfBench, a cross-framework migration benchmark built from expert-written implementations: 34 applications, 102 framework variants, roughly 151,000 lines across 1,946 source and test files, and 204 directed migration tasks. 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 opposite result. 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 estimated the work took about half the time the manual equivalent would have. Same year, same class of model. What separates them is the harness: Google used AST-based tooling to locate every change site before the model wrote anything, and every change still went through normal review. The model did the typing, the harness decided what was true. That is a factory pointed at a migration, which is why we run migrations through one instead of beside one. On the Frontend the harness also settles what parity means, and this 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 the guards the factory already runs, so parity is a test that passes or fails rather than an opinion formed in review. How it runs: the audit splits the codebase into the mechanical share (thousands of near-identical edits an agent is genuinely good at, once static analysis has found every site) and the ambiguous share (behavior nobody wrote down, the workaround from 2019, the component whose four callers each depend on a different accident of it), and the second share is a person's work. Characterization tests are written against the old implementation while it is still the source of truth and have to pass there first. Slices ship route by route behind the app you are already shipping, each separately mergeable and separately revertable, so the migration has no point of no return and can be paused for a quarter without rotting. The design system usually goes first, because migrating onto components nobody owns just moves the drift into a new framework. We do not sell big-bang rewrites, and if the audit says the migration is not worth doing yet we will say so. ### Most of our traffic is bots now. Should we block the AI crawlers? Block or allow is the wrong question, because that traffic is not one thing. Cloudflare reported on 3 June 2026 that automated requests had passed human traffic for the first time in the internet's history, with Radar putting it at 57.5% machine against 42.5% human HTML traffic, and its May 2026 breakdown found 51.8% of AI crawler requests were for training against 9.3% for search. Those two categories have opposite value to a product company. A research or buying agent reading your product page is drawing a shortlist before you know a 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. Cloudflare acted on exactly that distinction on 1 July 2026, splitting crawler traffic into declared purposes (search, agent, training), blocking the training and agent categories by default on ad-supported pages from 15 September 2026 while search stays allowed, blocking mixed-use crawlers that will not declare a purpose outright on those pages, and moving Pay Per Crawl toward a Pay Per Use model. So the decision is per surface and per purpose, and it is a product decision rather than an infrastructure setting. The Frontend half is the part we build. The same truth rendered for both audiences, so an agent does not have to execute your whole bundle to learn what you sell and does not give up and summarize a competitor instead. Capability declared as callable tools through WebMCP in the page or an MCP endpoint beside it, so an agent transacts through an interface you version and control rather than scraping a flow you designed for a mouse. Identity verified at the application layer rather than by trusting a user-agent string, which is the one thing any scraper can set. An explicit confirmation step in front of anything irreversible an agent can do on a customer's behalf. And agent sessions instrumented as their own funnel, because they fire none of the events your human funnel is built on, so that share of your traffic is currently invisible in your analytics. Two honest limits. Attribution from an AI answer through to a deal is mostly unavailable today, so we report leading indicators and label them as such. And we are not a CDN and not a bot-management vendor: enforcement belongs at your edge, and we build to the policy you set there. ### We are told to run more coding agents in parallel, but our senior engineers are already the ceiling. How does that scale? It does not, until you change what a senior spends attention on. 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. The report calls that the delegation gap and names verification as the bottleneck of what it calls the orchestration era. That gap is not an adoption failure. It is the honest distance between what a model can produce and what a person will put their name on, and buying more agent seats moves only the first of those. CloudBees measured what happens when a team ignores it: in its State of Code Abundance report, published 19 May 2026 from TrendCandy research across 213 enterprise technology leaders, 92% said they were confident their AI-generated code was production ready while 81% reported a rise in production issues tied to that same code, and only 12% had a dedicated governance function against 46% who said the CTO or VP of Engineering carries the accountability when something breaks. Confidence is not evidence, and accountability without a mechanism is just a name on an incident. So the number worth working on is not agents started, it is the share of agent output that arrives at a human already proven rather than merely finished. There is no published figure for how many agents one engineer can carry and we will not invent one, because it is a property of your codebase rather than your engineers: a repo with an enforced design system, trustworthy tests and typed boundaries is far more delegable than one whose rules live in three people's heads. The audit measures yours before anything is installed, splitting a senior's review week into the decisions a machine could have made and the judgment nobody can automate. Four things raise the number, in the order we install them. Guards that run before a human and return a specific reason to the author, so a rejected change never costs senior attention. Context and skills committed to the repo, so the same correction is not re-explained every session and the first attempt lands closer. Task shape, because a bounded change with a written acceptance criterion is reviewable at a glance while a sprawling one is not, whoever wrote it. And review routing, so the changes that need judgment arrive first rather than in the order they were opened. Two honest limits: some decisions are irreducibly human and no tooling removes them, and a ratio that improves because reviews got shallower is not an improvement, which is why the number is always reported beside guard catch rate and review rejection rate on agent output. ### We are putting an AI agent in our product. What stops a prompt injection walking out with customer data? Nothing in the model, so the defense has to live where you can build it, which is the interface and the scope around it. Note the boundary first: this is not the security of code an agent wrote for you, which is a Factory question about guards in CI. This is the security of the agent your product ships to its users. The shipped state of the art makes the point better than we can. 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 mitigations from the best-resourced lab in the field, 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 incidents to one CVE is the part 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. Excessive agency in particular is not a bug anyone patches. What we build is Frontend work, in five parts. Trust boundaries in the render, so anything the agent read (a support ticket, a scraped page, an uploaded PDF, an email thread) never reaches the model in the same channel as the user's own instruction and never reaches the DOM as anything but data. Tools scoped per surface, so the agent on your billing screen holds the billing tools and nothing else and a successful injection reaches a small surface rather than everything your API can do. Confirmation that names the target, rendering the actual recipient, subject and body rather than "the assistant would like to send an email", because a user who cannot see the parameters is approving an intention while the agent executes an instruction. Provenance in the UI, marking which sources were untrusted. And a degraded mode designed on purpose, because subtraction is what the frontier labs ship when something is unresolved. Underneath those, the agent holds no privileges of its own and acts as the signed-in user through your existing authorization, so a compromised session is bounded by that user's account rather than your service credentials; a capability inventory is generated from the code that registers the tools so it cannot drift from what shipped; every tool call is logged with its parameters, surface, sources and approver; and injection cases run as evals in CI beside the quality evals, so a prompt or model change that reopens one fails a build. We build and operate that layer. We are not an AI security auditor, we do not run penetration tests or red-team engagements, and we do not certify anyone. None of this makes an agent injection-proof. It bounds what a successful injection can reach and makes it visible when it happens, which is the achievable goal today, and the model vendors do not claim more than that either. ### Our coding agents install packages and paste in code. Who is checking the open source licenses? Almost nobody, and there is 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 the study has recorded. The reason is beside it in the same report: 76% of organizations assess AI-generated code for security risk, only 54% assess it for IP and licensing, and 24% run a comprehensive review across IP, licensing, security and quality. Security got a process. Licensing did not. Two things make it a Frontend problem. Open source components per codebase rose 30% year over year, and an agent asked for a date picker, a virtualized table or a chart installs one without an opinion about its license, because nothing in the prompt asked for one. Worse and quieter, 17% of open source components enter codebases outside any package manager, as copy-pasted snippets, vendored files and generated code, so the manifest your scanner reads never mentions them, and a model reproducing an implementation it learned from a copyleft project does not carry the header along. A factory widens who ships, and a PM or a designer running an agent has no instinct for this. 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, allowed, denied and the tier that needs a person, and CI holds it: the full dependency graph on every PR including transitive packages and licenses that change in an upgrade, an SBOM produced by the build, code with no manifest entry flagged for provenance, exceptions recorded with a reason and an owner. The gate goes on in ratchet mode after an inventory rather than before one, so it does not fail every build on the first morning, and the artifacts it produces are the same ones an acquirer or an enterprise security questionnaire asks for. 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. ### Our coding agents install npm packages on their own. What stops one installing a package that does not exist? A check at the moment the name enters the repository, because installing is executing and by review time it has already happened. The invented names are predictable, which is what makes this an attack rather than a curiosity. "We Have a Package for You!", presented at USENIX Security 2025 by researchers from the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech, generated 2.23 million code samples from 16 code-generating models across Python and JavaScript: 440,445 of them, or 19.7%, contained at least one hallucinated package name, across 205,474 unique fabricated names, and re-running identical prompts ten times each brought 43% of the invented names back on every run and 58% on more than one. That stability is what lets an attacker enumerate and register the names in advance. The Cloud Security Alliance published a research note on the class, slopsquatting, on 19 April 2026, and in August 2026 one actor pushed more than 700 malicious npm packages inside 48 hours, since reported past a thousand, delivering a cross-platform remote access trojan and infostealer. The clearest documented case is Frontend tooling: models produce "unused-imports" when they mean eslint-plugin-unused-imports, the name was registered with a credential stealer inside, and in early February 2026 it was still recording roughly 233 weekly downloads under an npm security hold. npm audit and Dependabot do not cover this, because they report known advisories on packages that already exist, and a package published on Tuesday for this purpose has no advisory until after your CI has run its install script. So the gate asks four questions where the name lands: does this package exist and did it exist last week, judged on first-publish date, download history, repository link and maintainer count; is it the package you meant, which is the one-word case no manifest scanner raises; what runs at install, with lifecycle scripts off by default for anything new and on only by allowlist; and what did the lockfile actually change, reviewed as code rather than collapsed to one line. Installs on unreviewed branches run with no credentials or publish tokens. And the agent gets a better source than its own memory: the inventory of components and libraries you already approve, served as context, so a request for a chart, a date picker or a lint rule resolves from a list you own. It is tiered so established packages pass automatically, and it starts as an inventory and ratchets onto changed lines rather than failing every build on day one. No eighth guard is added to the seven, because this sits inside the existing security gate's lane. Two honest limits: a widely used package can still be compromised through a maintainer account, which is your scanner and lockfile discipline rather than this check, and a gate at install can only tell you whether a dependency is what it claims to be, never whether it was a good idea. We build and operate the gate inside your pipeline with your registry and 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. ### A package we have used for years was compromised through its maintainer's npm account. Our new-dependency checks would all pass it. What catches that? Not the new-dependency reputation checks in the answer above, and that is the point: they are the right instrument aimed at the opposite attack. A gate that resolves a newly added dependency against its first-publish date, download history, repository link and maintainer count exists to catch a name that should not exist at all. An account compromise produces the inverse shape. The package is years old, the download history is enormous, the repository is real, and the maintainers are the same people they were last week. Every reputation signal passes, because nothing about the package changed. What changed is who was able to publish it. Microsoft Threat Intelligence tracked this through 2026 in the Shai-Hulud family, where trusted maintainer accounts were taken over to ship credential-stealing releases and keyv@6.0.0 was among the confirmed malicious versions, and Singapore's Cyber Security Agency published an advisory on 6 August 2026 covering Keyv and related packages. Two details decide how much it matters to a Frontend build. Execution moved from postinstall to preinstall, which runs before installation completes, so it sits even further upstream of your build, your guards and your reviewer than it did before. And the payload's objective was credentials, npm, GitHub, cloud and CI, after which it used the stolen publish rights to inject itself into further packages and republish them. That is a worm, and an unreviewed branch's CI runner is a reachable host on it. The reflex is to reach for provenance, and this is the part worth getting right, because it is where a lot of 2026 supply-chain budget is going. Trusted publishing replaces a long-lived npm token with short-lived OIDC credentials minted by your CI, and it generates a provenance attestation automatically. That is a real fix for the stolen-token problem and it is worth adopting for your own packages. It is not a control on contents. Provenance proves origin, not intent: it records which workflow in which repository built the tarball, and a compromised workflow emits a perfectly valid attestation. JFrog reported a variant that went through the OIDC flow itself and produced a Sigstore bundle through Fulcio and Rekor, so the malicious tarball carried genuine provenance from the genuine build. The OpenJS Security Collaboration Space says as much in its own publishing guidance: trusted publishing is promising but not ready for critical packages in its current state, because it would not have prevented attacks of this kind, and for small or critical projects it still recommends local publishing with 2FA. Adopt it. Do not file it as the answer to this question. The lockfile is the other control teams overestimate, and it is worth being exact about what lockfile discipline can and cannot mean. The integrity field is a hash of the tarball bytes. It proves that the bytes you install are the bytes you locked, which is worth having and is the whole reason a build should install from the lockfile instead of resolving afresh. It proves nothing about whether those bytes are safe, and the moment anybody bumps the version, the attacker's tarball arrives carrying its own perfectly valid hash. A lockfile is a change detector. The control is therefore not the file's presence, it is the conditions under which a bump is allowed. Which is why the control that actually bites here is different in kind. It is time. A maintainer compromise is typically found and the version pulled within hours to days, so the cheapest effective defence is to never install a version the world has not already had for a while. npm spells this min-release-age, pnpm spells it minimumReleaseAge and Bun has its own, and the units differ between the three, days against minutes against seconds, which is precisely the detail that makes a config copied from one repository to another silently wrong. Around that: install from the committed lockfile so no build quietly resolves something newer, lifecycle scripts off by default and on by allowlist, which matters more now that execution moved earlier, the install on an unreviewed branch run with no credentials and no publish token, which breaks the propagation step even when it cannot prevent the infection, and npm audit signatures after install, which verifies registry signatures and attestations and therefore tells you about origin and never about intent. The limits, stated plainly. A cooldown buys safety with patch latency, and that trade is real: the same delay that keeps you clear of a poisoned release also delays a fix you want, so it belongs on third-party dependencies and not on your own internal packages. It cannot catch a compromise nobody has noticed yet. And none of it works backwards. If a laptop or a runner has already installed an affected version, the credentials on it should be treated as compromised and rotated, which is incident response rather than a gate, and it is the step teams skip because the build went green afterwards. The boundary is the same as the rest of the gate: we build and operate this 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. ### Chrome can run a model on the user's device now. Should our product use on-device AI, and what about Safari and Firefox? For part of a feature, built as two paths behind one contract. Chrome 148 shipped on 5 May 2026 with the Prompt API stable, putting Gemini Nano behind a JavaScript call in the page: no API key, no account, no network round trip for generation, multimodal input across text, image and audio, streaming, and output constrained to a JSON schema or a regular expression. For high-frequency, latency-sensitive, small-context work that beats a hosted call outright. The availability picture is structural rather than temporary, and it decides the architecture. Mozilla, Apple's WebKit team, the W3C Technical Architecture Group and Microsoft all objected on the way to that release, the TAG review closed without consensus, and Edge did not enable the feature despite being built on Chromium. Firefox and Safari do not have it. Even inside a supported Chrome, availability is per device rather than per browser, because the model is a large local download gated on disk and hardware, so the same browser version answers differently on two laptops. A product that treats the local path as the default ships a feature most of its users never see. So the hosted path is the default and the local one is an upgrade, never the reverse; capability is detected per feature at call time and never inferred from a user-agent string; and the component consumes the same typed, streamed, schema-constrained result either way, so nothing forks below the call site. The states that exist only on this axis are designed rather than discovered, because a model still downloading is a real state with real copy and not a spinner that never resolves. The privacy claim is bound to the path that actually ran, since "this never leaves your device" is true locally and false on the fallback. What belongs local: classify as someone types, extract from a pasted block, rewrite or translate a selection, draft in a field, and redact identifiers before anything reaches a hosted model, which is the case that changes an architecture rather than a line item. What stays hosted is anything where the answer is the product. The cost moves rather than disappears, onto the user's battery and thermal budget on a device you do not control, so it is read as Interaction to Next Paint from real devices instead of as a token count. Keep this apart from the reliability envelope, which is what the interface does when a remote call is late, capacity-limited or truncated. This is about where inference runs at all. We build the feature and both paths. We are not a model vendor, we do not ship you a model, and we will not promise a capability a browser has not shipped. This roster moves quarterly, so the claims here carry their dates. ### Our AGENTS.md is enormous and the agents still get lost in our codebase. What actually fixes that? 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, 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 from twelve less-travelled repositories carrying real maintainer-written context files. Each agent ran three ways: no context file, one generated the way its own vendor recommends, and the human-maintained file. The generated 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 were worth roughly four points, still at close to a fifth more cost. The authors explain why, and it is the sentence that should change what a team does next: codebase overviews and directory listings did not help agents navigate, because agents are already good at discovering structure on their own, so a listing maintained by hand mostly spends reasoning tokens on something they would have found anyway. Read that as a result about the 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, module boundaries that are import rules CI enforces rather than a convention someone documented, and cycles broken, because a dependency loop is exactly the shape that makes reading the relevant files unbounded. Ownership expressed as code, with CODEOWNERS generated from the same boundaries the lint rules hold, so who reviews a change cannot drift from the structure. And a context file kept short and load-bearing: commands, invariants and what genuinely cannot be discovered by reading, which is what the maintained files in that study were carrying when they earned their four points. Two things we do not say. We do not tell anyone to delete their AGENTS.md, and we still write and maintain one in every engagement, because context that is true and unguessable is worth having and the finding is about what a file can carry. 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, the same sequencing the performance budget and the license gate already use, because a rule switched on at an ideal standard over a six-year-old codebase gets disabled by Thursday. ### Our engineers ship faster with AI and understand the code less. Is that real, and does more AI training make it worse? It is real, it has been measured, and the same study says training is the answer rather than the problem. Anthropic published How AI assistance impacts the formation of coding skills on 29 January 2026: 52 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, split at random between working with an AI assistant that could produce correct code on demand and working without one. Both halves had the documentation, the tooling and search, and both then 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 give 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 code that had worked. On its own that reads as an argument for using the tools less. The rest of the paper says otherwise, and this is the part that matters. The real spread was inside the assisted group rather than between the groups: six distinct interaction patterns were identified, three scoring under 40% and three scoring between 65% and 86%, at or above the people who had no assistant at all. The engineers in that upper band used the assistant to build understanding while it produced code, asking follow-up questions, requesting the reasoning behind an implementation, sending hybrid requests that come back with both. They were not the fastest in the session, and they were the ones who still knew the material at the end of it. Same tool, same task, opposite outcome, decided by how the person worked with it. A habit is exactly what a workshop installs, which is why this sits in training rather than in tooling: what to delegate and what to read, how to ask for the reasoning rather than only the result, how to review a diff you did not type, and how to keep the debugging reps that build the judgment everything else depends on. It matters commercially rather than sentimentally, because every guard the factory installs ends by handing a specific reason to a person who has to read a diff and decide, so what an organisation can ship is bounded by what its people can actually stand behind. Three honest limits. The study looked at mostly junior engineers learning one unfamiliar library in one session, so we quote it for what it measured and do not stretch it into a claim about senior engineers or about a career. We do not place juniors as engineers and this is not a graduate programme: training runs on your own engineers at whatever level they are, on your own codebase. And we put no number on what a workshop recovers, because nobody has measured that and inventing one would be the same failure in the other direction. ### We turned on coding agents and now CI and the merge queue are the bottleneck. Is that the agents' fault? 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. What 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. At least one pull request in seven in private repositories is AI-assisted, and that is a floor, because assistants that leave no trace on the commit are invisible to the measurement. So the agent is not the variable in your incident. Volume arriving at a control point 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. Queueing is what makes it feel sudden: as arrivals approach capacity the wait stops rising in proportion to the load and climbs away from you, so a pipeline that felt fine last quarter feels broken this quarter without a single check having got slower. Frontend is where that bites hardest, because Frontend CI is the expensive kind, with a browser matrix, visual regression, an accessibility pass, a bundle budget and a Lighthouse run all measured in minutes rather than seconds. Four moves, in order. Order the checks by cost and certainty so the cheap deterministic ones fail fast and an expensive suite is never spent on a change that does not typecheck. Run what the change affects rather than everything, with test impact analysis mapping the suite to the module graph and the full suite reserved for the merge path. Batch and bisect in the queue instead of testing every pull request alone: a batch of four is roughly a quarter of the runs, a failed batch is bisected automatically rather than thrown away, and the batch size widens under load and narrows when the queue is quiet. And isolate runs per agent instead of serialising them on one shared staging environment, because a queue for staging just becomes the real merge queue. Three limits stated rather than glossed. Batching trades some precision in failure attribution for throughput and is the wrong trade below a certain merge volume, so it is measured before it is switched on. Bisection tells the truth only if the suite does, which makes flake quarantine a prerequisite rather than a nice-to-have. And no pipeline change rescues a pull request that should not have been opened in that shape, which is what structured specs are for upstream. Cost is reported as cost per merged pull request read beside guard catch rate, because a pipeline that is cheap and merges nothing is not a saving. We build this on the CI you already run, with your runners and your billing. We are not a CI vendor, we do not resell one, and we do not move your pipeline to a platform of our choosing. ### AI agents are hitting our product. How do we tell a real one from something pretending, and what should we let it do? 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, checks the nonce and expiry, and hands your origin a verified operator identity instead of a guess. 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 stay correct both for the agents that sign and for the larger number that still do not. Then comes the part a signature cannot answer, and it is most of the work. 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, whose data they may touch, or what a caller you cannot verify should get instead, and none of that can live at the edge because all of it is your domain model. So the product layer is tiered. An unverified caller does not get a wall, because the systems deciding whether your product is mentioned when a buyer asks a question are largely still unsigned and a product that cannot be retrieved is not in the answer: they get your public product truth, server-rendered and complete, at a rate limit, with no privileged capability, and any refusal is legible through a real status code and a machine-readable reason rather than a silent block that reads as an outage. A verified and known operator buys trust rather than access: higher limits because you know who to talk to, structured responses instead of scraped ones, and your declared tools callable over WebMCP or an MCP endpoint with schemas that say what each one does and honest annotations on the destructive ones. An agent acting on behalf of one of your users is a different tier and a different mechanism, and conflating the two is the mistake with the worst blast radius: delegated access rides on your existing authorisation, scoped to that user and never wider, established through a consent step the user actually saw, revocable, and recorded so you can answer afterwards what was done in their name. Anything irreversible sits behind an explicit confirmation that renders the real parameters. And because verification is an identity primitive rather than a behaviour guarantee, per-operator limits, spend caps and an operator-scoped kill switch are part of shipping this rather than an incident you improvise later, with agent sessions instrumented as their own funnel and retrieval, representation and action measured separately. Two boundaries. We build this layer in your product, on top of your own authentication and permissions, alongside whatever your CDN already does, and we do not ask you to move or replace it. And we are not a bot management vendor: we do not sell or operate a WAF, a CDN or a detection service, we do not claim to tell you whether an unsigned request is a person, and we do not promise behaviour a standard has not shipped. ### People across the company are building their own AI apps in production and engineering cannot see any of it. Do we ban them? 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. 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% 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 that 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. Keep this apart from its nearest neighbour: the prototype question is about a Lovable, v0, Bolt or Figma Make build meant to become a feature in your product and treated as a specification. These tools were never coming to your codebase at all, and they are running in production as their own thing. Two facts make it ours. Almost every one is a Frontend, an internal dashboard, form, admin screen or report put over data and services that already existed. And the person who built it is the same person the factory exists to unlock, so a shadow estate measures how much demand your sanctioned path is not absorbing rather than a discipline failure. The answer is a path, starting with triage, because not everything belongs in your codebase: anything touching production data, customer-facing surfaces, credentials or a paid service gets a sanctioned home, so does anything a second person now depends on, and a genuinely personal throwaway stays where it is and stays disposable. What the path adds is narrow on purpose so it does not become a rewrite: an identity boundary so the tool calls your services as a signed-in person with that person's permissions, a named owning team, the seven guards on the way in, and a log. Then it has to win on time to merged work, which is what the guards, the committed context and the engineered pipeline capacity are for, because a policy slower than the prompt moves the estate somewhere you can see even less. We build the path, the guards and the migration work. We are not a shadow-IT discovery product, we do not scan your network, we do not monitor your employees, and we do not write your acceptable-use policy. ### AI agents fail at the things our product exists to do. Is that a model problem or ours? 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, weighted to state-changing work: purchases, appointments, job applications, long forms. A run counts only if the agent's final HTTP request matches the task schema, and a judge grades it against a human reference trajectory over a five-layer recording, so a confident summary of something that never happened scores zero. The strongest frontier agent evaluated finished 33.3% of the tasks, roughly one in three, and the majority defeated every model tested, while the same class of agent scores in the 65 to 75% range on older benchmarks built from hosted replicas and static traces. Part of that gap is the agent, since long multi-step work still defeats these systems on their own merits. A large part is everything the replica left out, which is your interface: a consent banner or session-expiry modal that appears after the surface was interactive, a control that exists only as a pixel behind a hover or an unnamed div, a state change painted but never announced, a five-step form that silently discards what step two collected, validation that says something is wrong without saying what or where, an action that happens twice because there is no idempotency and no confirmation. The work follows that list and most of it is unglamorous: real semantics, accessible names and stable identity on interaction targets, which is the same work the accessibility gate asks for and therefore pays twice, since an agent reads what a screen reader reads. Interruptions resolved before the surface claims to be ready. Multi-step state kept server-side and addressable so a step can be re-entered rather than restarted. Errors attached to their field and machine-readable. Irreversible actions behind a confirmation rendering their real parameters and carrying an idempotency key. For the flows that matter most the durable answer is not to make the UI drivable at all: declare the capability as a callable tool over WebMCP or an MCP endpoint, so the agent calls the thing instead of impersonating a cursor. Which flows should be agent-operable is a commercial decision made flow by flow, and an explicit no is legitimate wherever the user's presence is the point. Three limits: this raises how often an agent succeeds without guaranteeing it, every fix has to leave the human experience the same or better, and we do not build CAPTCHA solving, bot-detection evasion or anything meant to make an agent look like a person. ### We are building an MCP app. How does anyone find it inside ChatGPT or Claude? Two ways, and neither 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 and reviewed against published guidelines before listing, and Anthropic has run a connector directory for Claude since 14 July 2025, extended to consumer services in April 2026. The second decides your volume: a model picking your tool mid-task from the metadata you wrote, which makes tool descriptions, parameter schemas and annotations product copy with a machine as the reader. Notice what is 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, so keyword-stuffing a description is a rejection rather than a ranking. What is left is product work: a small set of sharply scoped tools rather than a mirror of your REST API, descriptions that say when to call a tool and when not to, annotations set honestly so a write or destructive action is declared as one, auth that asks for the narrowest scopes and fails legibly, and a UI resource for tasks that have to finish in the conversation, which is what MCP Apps standardized as the first official MCP extension on 26 January 2026, rendered by the host in a sandboxed iframe and live in Claude on web and desktop, Goose and VS Code Insiders with ChatGPT following the same week. Treat selection as testable: run the twenty phrasings a real user would type as an eval set in CI and measure how often your tool is picked and how often the task completes. Keep it separate from being found on the web, which is about pages a crawler can read. This is about a tool a model can select. Two honest limits: no platform publishes its ranking, and nothing you can buy changes it. ### We sell into the EU. Does the factory help with the European Accessibility Act? It helps with the part that is engineering, which is most of the ongoing cost. The EAA applied on 28 June 2025 and enforcement has been ramping across member states since, it reaches e-commerce and consumer-facing digital services sold to EU consumers regardless of where the company is based, and the harmonized standard behind it, EN 301 549, adopts WCAG 2.1 Level AA. Teams usually treat that as a remediation project, which fixes the backlog once and then quietly refills it, and the refill got faster in 2026 because more people in the org are shipping UI. Accessibility is the requirement that regresses most invisibly: a keyboard trap, a lost focus ring, a control with no accessible name and a color pair that misses contrast all look completely fine in a screenshot, so they pass review and land. An agent given a design and a prompt reproduces all four happily. The factory answer is the same as everywhere else, which is to make the standard physical rather than remembered: automated checks in CI on every PR, the mechanical criteria failing the run before a human is involved, contrast validated against the committed tokens rather than eyeballed, keyboard and focus-order regression tests, and the manual criteria no scanner can cover routed to the people who can actually judge them. That turns conformance into something your pipeline holds instead of something a consultant re-establishes every year. To be explicit about the boundary: we build and operate the gate, we are not an accessibility auditor, and we do not issue conformance statements or VPATs. ### Our accessibility target is WCAG 2.1 AA. What changes when the EU standard moves to 2.2? Your target moves, and what catches teams is which criteria move with it. EN 301 549 is the harmonized standard behind the EAA, and ETSI published version 4.1.1 in September 2026, realigning its web, document and software clauses from WCAG 2.1 to WCAG 2.2. Publication is not the switch. A harmonized standard only carries a presumption of conformity once it is cited in the Official Journal of the EU, and the cited version is still 3.2.1, so WCAG 2.1 Level AA is what the presumption runs on today. The citation has not happened yet: Deque has it on track for around 30 November 2026, others say December, and no date has actually been announced. That gap is the useful part for a 2027 plan, because it is the only planning window you get and it is open now. What arrives when it closes is six criteria an AA target did not have to meet before. Four at AA: 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size and 3.3.8 Accessible Authentication. Two at A, which AA conformance also requires: 3.2.6 Consistent Help and 3.3.7 Redundant Entry. One criterion, 4.1.1 Parsing, is removed. Then the part nobody budgets for: exactly one of the six is decidable by the scanner you already run. axe-core has a target-size rule for 2.5.8, and even that one ships disabled by default, so a green axe run today is not evidence about it. The other five are not DOM properties. Focus Not Obscured fails when a sticky header, a cookie banner or a chat launcher covers the control that currently has focus, which means every component passes in isolation and the defect exists only in composition. Dragging Movements asks whether a single-pointer path exists for anything draggable, which is intent rather than markup. Consistent Help is a cross-page invariant, Redundant Entry is a property of a multi-step flow, and Accessible Authentication is a rule about what your login may ask a person to remember or solve. They are also, awkwardly, the criteria least likely to be known by the people a factory just let ship UI, and not one of them looks wrong in a screenshot or in a diff. So the guard changes shape rather than getting stricter: target-size enabled explicitly instead of inherited, focus visibility asserted in a test that mounts the real sticky chrome rather than the component alone, a single-pointer path exercised for every drag interaction, help placement and the redundant-entry rule written as flow tests, and the authentication criteria pinned as a contract on the auth components so a later redesign cannot quietly reintroduce a puzzle. Start with the four that are composition or flow shaped, because those are the ones a remediation sprint scoped per component will miss and then reintroduce. Two limits. WCAG 2.2 Level AA is only part of conformance with EN 301 549, whose hardware, closed functionality, real-time communication and document clauses sit outside the WCAG criteria entirely. And we build and operate the gate: we are not an accessibility auditor, we do not issue conformance statements or VPATs, and whether your product conforms is a question for your auditor and your counsel. ### Our throughput went up after we rolled out AI coding tools, but delivery does not feel any faster. What is going on? You are measuring the authoring half of a pipeline whose constraint has moved to the merge half, and the largest study of this says so directly. DORA's 2025 State of AI-assisted Software Development, published in February 2026 off roughly 5,000 respondents, found that AI acts as an amplifier: it magnifies the strengths of organizations that already had a solid delivery foundation and magnifies the dysfunction of the ones that did not, and that it lifts throughput while often costing stability where that foundation was missing. Ninety percent of respondents were using AI in their daily work. So the tools are doing exactly what they promised and the line still is not moving, because more code arriving faster at an unchanged review and release process is not a delivery improvement. It is a bigger queue. The second half of the problem is the instrument. Deployment frequency and lead time were designed for a pipeline where a human wrote every line, and they quietly stop measuring what you think they measure once a large share of committed code is agent-authored. Watch the merge side instead: what a guard caught before a human opened the PR, review rejection rate on agent output, how much of your merged volume comes from outside the Frontend team, and the stability numbers read beside the throughput ones rather than after them. Throughput without stability is not speed, it is debt arriving sooner. It is also why the audit takes your baseline before anything is installed, and why the factory instruments itself rather than reporting on itself. ### We are putting an AI agent inside our product. What does that change about the Frontend? More than most teams budget for, because the agent is the easy half now. Gartner projects that 40% of enterprise applications will have task-specific agents embedded in them by the end of 2026, up from under 5% in 2025, and the ones that land badly fail in the same recognizable way: a spinner over an autonomous process. The user cannot see what the agent is doing, cannot stop it halfway, and cannot tell a confident wrong answer from a right one, so they stop trusting it and quietly go back to the manual flow. None of that is a model problem. It is a rendering problem. The interface has to stream tool calls while they run rather than reveal them afterwards, let someone intervene at a step instead of only cancelling the whole run, put an approval gate in front of anything irreversible, and say plainly in the UI when the model is unsure. There is a protocol layer for this now and it is worth knowing before you invent your own: AG-UI, the Agent User Interaction Protocol that came out of CopilotKit's work with LangGraph and CrewAI, carries an agent run to the Frontend as an event stream over HTTP, SSE or WebSockets, and A2UI lets an agent declare the components it wants rendered as structured JSON. We build that layer inside your design system and behind your existing permissions. Decide the autonomy level early, because human-in-the-loop and human-on-the-loop are two different products, not a setting you flip later. ### We have a platform team and an internal developer platform already. Should we not build this ourselves? Eventually yes, and handover is the entire point of the engagement. The reason it is rarely where a team starts is that the platform group is being asked to absorb a second category of user this year while still serving the first one. Platform engineering spent five years building for humans: golden paths as templates a person reads, a catalog a person browses, a paved road a person chooses to walk down. An agent does not read, browse or choose, so a golden path only constrains one if it is executable, which turns the path into a contract the agent dispatches against with a CI check behind it. That is a rewrite of the artifact rather than a new page in the developer portal, and the surrounding layer is new work as well: a gateway that decides which tools an agent may call, a substrate where a run is sandboxed and reproducible, autonomy bounded per repo rather than declared per org, evals, and traces that outlive the run. The industry calls the destination an agentic development platform, and Gartner's forecast that over 40% of agentic AI projects will be canceled by the end of 2027 attributes it to escalating cost, unclear business value and inadequate risk controls, which is governance rather than models. What we bring is that it exists already and it is Frontend-shaped, which is the part a general platform team is least equipped to specify: what mergeable means for a component, which token, which states, which accessibility contract, what a route may weigh. We install inside your platform rather than beside it, on your CI and your conventions, and your platform team owns it at the end. ### We shipped a year of AI-assisted code and nobody wants to touch it. Does the factory help with what is already in the repo? Yes, and the order matters, because a guard switched on over an existing mess fails everything on the first morning and gets disabled by Thursday. The shape of this debt is not the one teams assume. The largest study of it, a 2026 analysis of 304,362 verified AI-authored commits across 6,275 public repositories and five widely used assistants, ran static analysis before and after each change and attributed 484,606 issues to the AI edits, 89.1% of them code smells rather than outright bugs. The planning number is that 24.2% of those issues were still present at the latest revision of the repository, and the surviving pool grew from a few hundred issues in early 2025 to over 110,000 by February 2026. Normal churn does not pay this down, because nobody chose to take it on. Ordinary technical debt is a shortcut made under a deadline with a comment attached; this accumulated invisibly in code that compiled, passed review and worked. So we sort before we gate. The audit maps where agent-authored code concentrates, which of it is load-bearing, and which issue classes cost you something real (a duplicated component that will drift, a data-fetching pattern that will not survive the next refactor, an accessibility or XSS defect that is a liability today) against the ones that are merely ugly. Then the guards go on in ratchet mode, failing on changed lines rather than on the whole repository, so what you touch has to come up to standard and what you do not touch stops getting worse. Remediation rides the roadmap instead of running as its own project, because a cleanup project competes with features and loses. The non-negotiable part is context: year two looks like year one when the agents are still reading a codebase whose conventions live in three people's heads. We do not sell a cleanup sprint and we do not rewrite your app. ### Our product has AI in it and we sell into the EU. What does the AI Act ask of our Frontend? Less than the headlines suggest and sooner than most teams have it scheduled, because the piece that landed is the transparency layer and the transparency layer is rendered. Article 50 of the EU AI Act applied on 2 August 2026, and it is not the deadline that moved: the Digital Omnibus deferred the high-risk obligations to December 2027 and August 2028 and left Article 50 in place. Three things fall on the product. A system that interacts directly with people has to make clear to the person that they are dealing with AI, at the start of the interaction and in the interface rather than in the terms. Synthetic output, whether text, image, audio or video, has to be marked in a machine-readable format a detector can read, which is a provenance and metadata problem rather than a badge on a card. And the deployer-side disclosures, deepfakes, emotion recognition and AI-generated text on matters of public interest, have to be visible to the person looking at the content. One more date: generative systems already on the market before 2 August 2026 were given until 2 December 2026 to meet the machine-readable marking requirement. As Frontend work that means a disclosure surface living in the component rather than bolted on per feature, provenance metadata carried from generation through storage to render so the marking survives an export or an embed, labels that stay legible when the content is displayed elsewhere, and all of it inside your design system so it does not read as a compliance sticker. We build that layer. We are not your counsel, we do not classify your system's risk tier, and we do not issue conformance statements. ### Every AI vendor now has forward deployed engineers. Why take yours? Because most of those programs exist to make one vendor's product succeed inside you, which is a legitimate thing to buy and a different thing from this. 2026 made the model universal: Gartner expects more than 85% of tech providers to be running FDE programs by the end of the year, OpenAI stood up a dedicated deployment company, Anthropic built an enterprise services arm on an acquisition, and Microsoft committed billions to embedding engineers with customers. What that convergence admits is that enterprise AI fails at deployment rather than at the model. So the question to ask any FDE, ours included, is what they are optimized for. A vendor's FDE is measured on adoption of that vendor's product, which shapes every artifact they leave behind and gives the engagement no natural end. Ours is measured on your delivery line, and we are not selling you a model, a coding agent or a platform underneath it: the harness is engine agnostic on purpose and everything it produces is committed to your repository under your license. The other half of the answer is the category. Most FDE practices are generalist, deploying an AI capability into whatever stack they find. Ours is Frontend, which is where the specificity that decides mergeability actually lives. If your problem is getting one vendor's AI into production, take theirs. If your problem is that your organization cannot merge Frontend fast enough, that is ours. ### Who actually ships once the factory is running? Backend engineers, PMs, designers, marketing, sales and customer success, opening real PRs on the real codebase that get safely merged. The Frontend team stops being the queue for every "small" UI ask and moves to the work only they can do. ### Is this staff augmentation? No. The Factory is installable infrastructure with a defined outcome and a fixed, phased price. We also embed senior engineers on retainer when a team needs reinforcement, but that is a delivery model, not the product. We do not place juniors. ### What does "AI-Native Frontend Engineering" mean? Our engineers work with Claude Code, Cursor, MCP servers and agent workflows as their default, not as add-ons. Every codebase we touch ships with AGENTS.md / CLAUDE.md context, a PR review agent and a shared prompt library, so the velocity stays after we leave. ### Can Enpitech ship production AI features, or just POCs? Production. We ship generative UI that adapts to data and intent, AI agents with real usable interfaces, voice-to-action and conversational web flows, enterprise MCP integrations, and AI-enhanced UX (smart defaults, predictive flows, contextual assistance). Real features your users rely on, with senior engineering quality, testing strategy, and observability. ### How do you add an AI agent to an existing React or Next.js app? We integrate alongside your current stack, no rewrite. Typical pattern: scope the user-facing job-to-be-done, pick the right surface (chat, generative UI, voice, inline action), wire the model layer with the Vercel AI SDK, TanStack AI or Claude Agent SDK using structured output via Zod, MCP tools for your data, observability and evals from day one. First production behavior usually ships in 2-4 weeks. ### How do you fix the AI code review bottleneck that shows up after we roll out Claude Code or Cursor? The bottleneck is real: teams generate more code and reviewers spend more time per PR because AI output is longer, more scattered, and less trusted. 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 catch the surface-level issues before a human ever opens the PR. A PR review agent runs first, so reviewers only see what actually needs human judgement. And a shared CLAUDE.md / AGENTS.md context in the repo keeps agents from re-litigating the same review comments across sessions. The result is that AI-generated PRs re-enter the same lane as human-written ones, and senior reviewers stop being the single-threaded merge queue. ### We run agent fleets now, several agents in parallel. Does that help the merge problem or make it worse? Worse, and predictably so. Claude Code Agent Teams, Cursor's parallel composition, Copilot's `/fleet` and multi-agent VS Code sessions all scale generation, which was already the cheap half. Deciding what is safe to merge was the expensive half, and a fleet multiplies the queue in front of that decision without adding a reviewer. Fix the merge side first: guards that decide mergeability before a human is involved, a review agent that runs first, evals and telemetry on every run, and one shared AGENTS.md / CLAUDE.md context the whole fleet reads so five agents do not each invent a different answer to the same question. Then turn the fleet on. Run in that order and a fleet compounds. Run it backwards and it just makes the traffic jam arrive faster. ### Is the factory spec-driven development, and does it give us anything for an AI governance or SOC 2 review? It is the front half of it. Spec-driven development means acceptance criteria, architectural constraints and domain rules are written down and handed to the agent, so it codes against a specification and validates against it rather than being re-prompted until the output looks plausible. Those structured specs are why factory PRs land smaller and more focused. The governance payoff is the part teams underestimate: once the spec is an artifact and every guard, eval and agent run is traced, what an agent was allowed to touch, what proved its output mergeable and who approved the merge stop being reconstructed after the fact. That trail is what an ISO 42001, NIST AI RMF or SOC 2 reviewer asks for once agent-written code reaches production, and it is generated as a by-product of shipping instead of assembled the week before the audit. We produce the evidence and wire the controls. We are not auditors and we do not certify anyone. ### Can non-engineers really ship production Frontend PRs, or is that just vibe coding? Both. Vibe coding (a PM or designer prompting Claude Code or Cursor to describe a change) is genuinely producing PRs in enterprise codebases today. What breaks is what happens next: the output collides with the design system, misses edge cases, and stalls in review. The Factory is what turns vibe-coded PRs into safely merged production PRs: guardrails, structured specs, generated tests, design-system enforcement in CI, and a senior review agent at the merge point. Everyone in the org gets to prompt. What ships still passes the bar. ### Our designers already build working UI with AI. Why does almost none of it reach production? Because the constraint was never their skill, and the published data now shows exactly where it sits. The AI in Design 2026 report from Designer Fund and Foundation Capital, based on over 900 designer responses and 25+ leader interviews, found half of respondents have pushed AI-generated code to production, with only around a fifth identifying as design engineers. Underneath that headline is the number an engineering leader should care about: 68% of designers at early-stage companies ship code, against 33% at publicly traded ones. Designers do not get less capable as a company grows. The merge path gets longer. That gradient is a direct measurement of how much process stands between a designer and `main`, and in a 30 to 300 engineer org most of it is a senior Frontend engineer's attention, which does not scale and was never meant to. The fix is not to lower the bar so designers can clear it. That is how you buy one-off components, a fourth shade of the brand color, a broken focus order and an XSS in a marketing page. The fix is to move the bar off the person: design tokens and the component registry committed as context the agent reads before it writes, design-system, accessibility, security, test-quality and performance guards that fail the run and hand the author a specific reason, and senior review reserved for whether the change is the right change. Then a designer's PR either lands or comes back actionable, without a senior being the gate. ### Our backend engineers can write React with an agent. What actually stops their PRs from landing? Not the syntax, which is why it catches teams out. A strong backend engineer with a coding agent produces React that compiles, passes types and looks correct in the browser. What they cannot carry is the tacit layer a senior Frontend engineer applies without thinking about it: whether a component for this already exists, 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 waits for the one person who can see it, and that person is the bottleneck the team already had. The factory writes that layer down as enforceable context and guards, so the same PR either fails in CI with a reason its author can act on alone, or merges. Nobody is asked to become a Frontend engineer. The standard stops being a person. ### Our PRs merge clean and things still break in production. What do you do about the release side? We install a release path with the same rule as the merge path: it must not depend on anyone being careful. A guard proves a change is well-formed, and only production proves it was right, which is the gap the 2026 numbers sit in. CircleCI's 2026 State of Software Delivery, published on 18 February 2026 from nearly 28 million workflows across more than 22,000 organizations, put main-branch success at 70.8%, the lowest in five years, and median recovery at 72 minutes, up 13% year over year. Lightrun's 2026 State of AI-Powered Engineering, published on 14 April 2026 from 200 SRE and DevOps leaders across the US, UK and EU, found 43% of AI-generated code changes still needing manual debugging in production after passing QA and staging, and 88% of organizations needing two to three redeploy cycles to publish one AI-generated change. On the Frontend this is sharper, because a release is not gradual by default (publish a bundle and everyone gets it on the next load, including users mid-session whose lazy chunks just disappeared) and the failures are silent (a dead button, a form that rejects a valid input in one browser and an empty chart for your biggest accounts all return 200). What we install: exposure decoupled from deployment so a change ships dark and is turned on for a cohort, the switch in the app rather than in the pipeline so turning it off takes seconds instead of a rebuild, flags evaluated where the page is rendered and failing safe when the flag service does not answer, release flags with an owner and a CI-enforced expiry so the switches do not become their own debt, stale clients handled with retained assets and a version check, and a turn-it-off threshold agreed before the flag is opened. Confirmation is field data on the routes that changed: INP, LCP and CLS from real users, client error rate per release, and the one funnel step the change was meant to move. This is downstream of the merge decision, so it adds no eighth guard to the seven. We are not an SRE vendor, we do not carry your pager or run your on-call rotation, and we do not sell an observability product. ### Our AI feature works in the demo. What breaks it in production, and how do we know it is healthy? Capacity, more often than quality, and it breaks in the browser rather than in the model. Datadog's State of AI Engineering 2026, published on 21 April 2026 from production LLM telemetry across thousands of organizations, found roughly 5% of AI model requests failing with nearly 60% of those failures caused by capacity limits, 69% of companies running three or more models, and token usage per request more than doubling year over year at the median and quadrupling for the heaviest users. One call in twenty failing is a state the product is in several times an hour, and every part of it is rendered, which makes it Frontend work: a capacity failure that keeps what the user typed and offers a retry instead of a red toast that discards it, a stream that stops mid-sentence detected and labeled as incomplete rather than presented as finished, slow and broken designed as different experiences, and a failover to a second model treated as a product decision because that model has different latency, formatting and refusal behavior. Health needs signals ordinary monitoring cannot see, since a truncation, a refusal and a confident wrong answer are all HTTP 200: time to first token at p95, completion rate for streams rather than requests, degraded-session share covering retries, failovers, truncations and queues, abandonment, and the outcome the feature exists to produce tied to the model and prompt version behind it. Cost and latency are Frontend decisions too, set by what you send per turn, what you cache ahead of the variable part, what you route to a smaller model, and what you stream. This is not agent UX (whether a user can see and stop an agent) and not evals (which catch quality regressions before release and nothing about a rate limit on Monday morning). The capacity is your provider's: we are not an LLM gateway or an observability vendor, and we do not sell an SLA on somebody else's model. ### We ship in several languages and our coding agents keep hardcoding English into the components. What catches that? A guard, because this defect class is invisible to everything you already run. A coding agent writes the label in the language the prompt was written in, straight into the JSX, and it compiles, passes types, passes tests and renders correctly in the browser the author is looking at. 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 rather than margin-inline-start, because that is what the majority of the training data says, which mirrors the whole layout wrong in Hebrew or Arabic; and sentences assembled from joined fragments, untranslatable in any language whose word order differs from yours. The cost is commercial, 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. The gate runs on the diff and is deliberately cheap and deterministic, 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 roughly 40% longer with accented characters rendered in the component screenshots the pipeline already takes so truncation becomes 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 with years of hardcoded strings stops getting worse rather than going red on day one, and the same rules live in the context the agent reads before it writes, so the guard usually never fires. Not an eighth guard: it rides inside the design system and accessibility guards for teams shipping more than one locale. We build and operate the gate and fix the code. We are not a translation vendor, we do not run your TMS, and we do not choose your locales. ### The model our AI feature runs on is being retired. How do we stop that being a fire drill every few months? By making the swap routine, because the cadence is 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: Claude Sonnet 4 and Opus 4 notified 14 April 2026 and retired 15 June, Opus 4.1 notified 5 June and retired 5 August. OpenAI's April 2026 notice covered more than 25 model IDs across two hard shutdown dates, 23 July and 23 October 2026, the October sweep taking GPT-3.5 Turbo, GPT-4, GPT-4 Turbo, o1, o1-pro, o3-mini and o4-mini plus fine-tunes built on them, and the Assistants API was sunset on 26 August 2026. That is a swap roughly every two quarters for anything long-lived. The retirement date is the easy half, because after it calls fail loudly. The damage comes from the voluntary swap: you repoint at a newer model and the endpoint keeps returning 200 while the behaviour moves underneath, in tool-call formatting, JSON schema adherence, verbosity, latency distribution and where the refusal boundary sits. Nothing errors and the logs look identical. It lands on the Frontend because almost every consequence is rendered: a component parsing 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, a p95 that moved a few hundred milliseconds puts the still-working copy on screen at the wrong moment. Prompts count too, since yours were tuned against the old model's quirks. What we build: the model as configuration per surface rather than a literal so you move one feature at a time, model and prompt version carried into telemetry so "since when" is answerable, a regression set built from real production traffic and diffed on what the 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 shadow or canary comparison before the switch, and a rollback that is a config change rather than a deploy. Distinct from production health (is the feature healthy now) and from guardrails (is this answer trustworthy): this is version lifecycle. An eval set makes a swap decidable, not risk-free. We are not an evals vendor or a model-ops platform, we do not resell inference, and we do not pick your model for you. ### Why are coding agents so much worse on our Frontend than on our backend? Because on the backend the agent can check its own work and on the Frontend it cannot, and the asymmetry is structural rather than a matter of model quality. A backend agent closes its own loop: runs the test, calls the endpoint, reads the row back, knows. A Frontend agent gets a build that passed, and nothing in a successful build says the modal is unreachable on a narrow viewport, the focus ring disappeared, contrast fell below threshold, the layout shifts once real data arrives, or the submit button now sits under the sticky header. The compiler, the type checker and the tests it wrote for itself all agree with it. So it stops at the last point it can verify, well short of where the work is right, and the rest becomes a person's problem at exactly the moment there is more output than a person can read. Faros AI's 2026 engineering report, two years of telemetry across 22,000 developers and more than 4,000 teams, compared low against high AI adoption 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. The fix is not more review and not a better model: give the agent the missing sense before it opens a pull request. Browser control committed to the repo as configuration so every agent has it; the accessibility tree read as the primary signal rather than pixels, because it is text, deterministic, diffable and the same surface a screen reader consumes, so the work pays twice; the states worth checking declared as fixtures rather than discovered (loading, empty, error, offline, long content, narrow viewport, right to left), with the component workbench you already run as the fixture surface; time and animation frozen, because an intermittent loop gets switched off in a week. It is a cheap inner loop against fixtures in seconds, not your end-to-end suite pointed at an agent, and it runs many times before CI. A failure caught in the agent's loop costs a retry; the same failure caught in review costs a senior engineer a context switch. Sequence it early, before the roles work and before any fleet, because parallel agents multiply exactly what it removes. Honest limits: a browser does not make an agent correct, it tells the agent when it is obviously wrong, and rendering a change is still not a judgment about whether the change was a good idea. It does not replace visual regression either, which compares against an approved baseline at merge time and has an owner; the snapshot rule holds for both, so a baseline is never accepted in the same run that changed the thing it depicts. Not an eighth guard: it runs before a pull request exists, upstream of the seven. We are not a testing vendor, we do not sell a visual regression product, and we do not sell QA headcount. ### A public scanner gave our site a low agent readiness score. Does it matter? It matters as a signal that the measurement changed, not as a description of 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 Cloudflare Radar dataset tracking adoption of agent standards across the internet. Readiness used to be a claim you made in a deck; it is now a measurement a third party takes about you, continuously, without asking, and your buyers and competitors can take it too. Be precise about what it reads, because it is narrower than the name: 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 publishable, declarative and largely mechanical, which is why the right response is to pass it rather than argue with it, usually in an afternoon or two, then hold it true with a CI check rather than somebody's memory, because these files rot silently once nobody owns them. A passing score is hygiene, a floor, not an achievement. What it cannot see is whether an agent can complete anything in your product, and that is where the outcomes are: ClawBench found the strongest frontier agent it evaluated finishing roughly one live web task in three, against far higher scores on hosted replicas. So a product can declare everything correctly and still lose every task an agent attempts, which is the worst position available, because a perfect score in front of a checkout an agent cannot finish converts a problem you might have investigated into a false negative you now trust. The work with revenue attached starts after the declarations are true: which flows are agent-operable and which are deliberately not, capability declared as callable tools over WebMCP or an MCP endpoint with honest annotations rather than hoping an agent drives your UI, delegated action mapped onto the authorisation and consent you already have, and agent sessions instrumented as their own funnel across retrieval, representation and action. Keep it apart from its neighbours: discoverability is getting cited, access policy is whether you serve automated callers, verified identity is who is calling, operability is whether the caller can finish, and this is an external measurement of declared readiness. We do not control that score and nobody sells placement in it. We build in your product; enforcement of who gets in belongs at your edge, so we are not a CDN or a bot management vendor. We run our own AgentReady Site Scan as a second read on the declarations, never as evidence that an agent can use your product. ### Lighthouse now scores our site for agentic browsing. What does that audit check, and how do we pass it? Four things: a clean accessibility tree, layout stability, an llms.txt at your root, and WebMCP tool registration. Lighthouse 13.3 added an Agentic Browsing category in May 2026, which moved agent readiness from a claim in a deck into Chrome DevTools, where your buyers and your competitors can run it against you without asking. Two of the four are where teams actually fail. The `llms-txt` audit is a format check rather than a presence check, so a file that exists but lists bare URLs instead of Markdown links fails it. The WebMCP audits are informative rather than scored and they read the declarative API: `webmcp-form-coverage` reports every form missing a `toolname` and `tooldescription`, and `webmcp-registered-tools` lists what the page registered. The other two are old asks under a new heading. The accessibility-tree audit is a filtered subset of the axe rules you were already meant to pass, because an agent navigates your page through the same tree a screen reader does, and Cumulative Layout Shift has been a Core Web Vital since 2021. It simply matters more when the thing clicking is a machine that identified a button a moment before it moved. Our advice is the same as for every other published scanner: go and pass it, because it is mechanical and it is a floor, then hold it true with a CI check rather than with somebody's memory, because these files rot silently the moment nobody owns them. And keep the two claims apart. This audit measures whether you declared the right things. It cannot tell you whether an agent can finish anything in your product, and that second question is the one with revenue attached. ### How do we make our forms callable by a browser agent rather than scraped? Annotate them with the WebMCP declarative API, which is four HTML attributes and no JavaScript. `toolname` and `tooldescription` on the form element register it as a tool and tell the agent what it does, and `toolparamdescription` on each control describes that field as a property of the generated input schema, where the control's own `name` supplies the property name. The fourth, `toolautosubmit`, is the only one that is a real decision. With it the browser may submit on the agent's behalf; without it the spec requires the person to submit. Leave it off anything that creates a lead, signs someone up, spends money or cannot be undone, and keep the confirmation as a step the agent has to hand back to a human. Two traps are worth knowing before you annotate everything you have. A form with a honeypot field is the wrong candidate, because the input schema is generated from the form's controls and offering an agent the field that marks a submission as a bot will lose you real conversions, so move the bot check off a named control first. And the attributes are inert where WebMCP is unsupported, which is what makes this additive rather than a migration: it costs nothing in browsers that ignore it, and it is exactly what the Lighthouse `webmcp-form-coverage` audit reads. Our own contact form is annotated this way, which is the cheapest demonstration available that it is a small change. ### Our product numbers keep turning out to be wrong. Why does analytics break every time we ship? 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 fails when it breaks. An analytics event is read by a dashboard owned by another team in another tool, not by a component, a type, a test or a reviewer. Delete it and the build passes. Rename a property and the build passes. Fire it twice and the build passes. The operations that break it are the ones that preserve behaviour: 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. All ship green, and all are the exact class of change a coding agent produces most of. The failure is not just 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. 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% prioritised AI-assisted coding against 24% prioritising AI-assisted testing and observability. Authoring got faster, checking did not. So we treat the measurement layer as code with a small gate on it: a typed schema in the repository for the events the business actually steers by, so a dropped or renamed property fails at the call site; assertions inside the flows CI already drives, because an event with no assertion is not evidence; an owner recorded per event, generated from the same module boundaries CODEOWNERS comes from; consent enforced in code rather than described in a policy; and a volume check in the release path for the residual failures no static check can see. It starts as an inventory and ratchets onto changed lines, and it covers the small set you steer by, never the whole taxonomy, because a schema imposed over eight hundred events gets switched off by Thursday. Honest limit: a green gate is not a correct number. It says the event you defined fired where you said it would; it cannot say the event measures what you think it measures, or recover what consent and a blocked request never sent. Keep it apart from its neighbours: delivery measurement is whether the AI spend on engineering paid off, read merge-side; release confirmation is whether a change is safe to keep, read from field data. This is the layer both of those read from. Not an eighth guard: it rides inside the test quality guard's lane. 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. ### We shipped an AI feature and nobody can tell us whether it worked. How do we find out? A usage number is not an answer to that question, and 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 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. The same survey ranked what users struggle with, and the ranking is the useful part: trusting the output first at 44%, ahead of understanding how the feature works at 26%, fitting it into the workflow at 25%, and discovering it exists last at 21%. Discovery is what teams reach for when adoption is flat, which is why a tour, a banner or a launch email moves the number for a week. Trust is first, and trust 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, editing in place is the primary action rather than regenerating and hoping, undo is real and reaches the thing that changed, and the feature meets the user inside the job rather than at a destination, because the competition is never nothing, it is the way the job is done by hand today. Then we instrument what happened to the answer after it arrived: accepted untouched, accepted after editing and how much changed, retried on the same intent, undone, or abandoned in favour of the manual path, alongside the one job-level outcome the feature exists to move, read against the model and prompt version behind it. Those are rendered interactions, so they can only be captured where they are rendered. Two limits we state up front. Every one of these is a proxy, so acceptance is always read beside a correction path people demonstrably use, and a model grading its own output stays a development instrument rather than a product metric. And measuring properly can tell you the feature is not worth keeping, which is a legitimate result and a cheap one next to another year of maintaining it. Keep it apart from its neighbours: agent UX is whether a user can see and stop an agent mid-run, the reliability envelope is what the interface does when a call is slow, capacity-limited or truncated, model lifecycle is what moves when the model is replaced, and evals ask whether the system still performs on cases you chose before release. This is whether the feature produced the result it exists for. We build the feature, the surfaces, the eval suite and the instrumentation. We are not a growth agency, not an evals vendor, and we do not write your adoption plan. ### Our agent-written code passes review and then breaks against our own APIs. What catches that? Nothing you are running today, because a diff is local and a contract is not. The change is correct in the file it is in, and the thing it disagrees with is a service in another repository that changed last Tuesday, so the reviewer cannot see the disagreement: 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 at organisations using AI for software development. At review time 94% of leaders rated AI-generated code as higher quality than human-written code, while in the preceding six months 82% had at least one production failure traced to AI-generated code, and the most common 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 a description of where the defect lives, which is outside the diff. The Frontend gets it worst structurally: it consumes every service and owns none of them, and nothing verifies a response shape at runtime, since the type written over untyped network data is an assertion about the server rather than a verification of it. TypeScript checks your code against that type and nothing checks that type against the server, so a field renamed upstream type checks, compiles, passes the suite and renders as an empty panel in front of a customer. Two agent behaviours make it the leading mode: agents conform, so asked to fix a type error one edits the type until the error stops rather than asking which side is true, and the same agent writes the mock from the same assumption, so the test agrees with the bug in writing. The gate: contracts generated from the provider and never hand-maintained, a build failure on a consumer-breaking difference between the contract in the pull request and the one the app was built against with severity classified so an added optional field costs nothing, mocks and fixtures generated from that same contract so a fixture cannot drift, the fields the app actually reads recorded so a provider can tell a safe deletion from an outage, and a recorded contract plus a scheduled check for the vendors you do not control. Two limits: a contract check tells you the shape matches and never that the value means what you think it means, and it cannot cover an endpoint nobody described, so the first pass is an inventory of what the application actually calls. We build and operate the gate inside your pipeline against your specs and 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 contract. ### AI assistants are starting to buy on behalf of our customers. Do we need the agentic commerce protocols? 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, confirmed in its updated shopping announcement on 24 March 2026, repositioning ChatGPT toward product discovery with the purchase moving back to the merchant's own environment, because people were researching inside the assistant and completing the purchase somewhere else. The protocol layer kept moving anyway: ACP, the Agentic Commerce Protocol, is an Apache 2.0 standard co-maintained by OpenAI and Stripe for running a checkout against a merchant an agent 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; and AP2, Google's Agent Payments Protocol, carries authorisation as signed intent, cart and payment mandates rather than as a stored card. Payment providers now ship suites that speak several at once, which tells you nobody expects one to win soon. Those dates are stated deliberately and re-checked quarterly. 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 beginning of one. What we build is the arrival: intent carried across the boundary instead of dropped so a cart, plan, configuration or quote is reconstructable rather than retyped, a landing surface that answers the claim rather than restarting the pitch, and the same product truth in both places, because the failure that costs the sale is an assistant being confidently right about something your page contradicts. For products that genuinely sell through an agent surface the protocol work is real and has the usual shape: capability declared rather than inferred from a page an agent must 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 authorisation carried as a scoped mandate rather than a stored credential. Build the commerce logic behind your own capability layer and treat each protocol as an adapter, so the standard that loses costs an adapter rather than a rewrite. Two honest limits: nobody knows which standard survives, and an agent surface is not a channel you control, so you cannot see the conversation that preceded the arrival and attribution is partial and labelled as such. Keep it apart from its neighbours: discoverability is whether you get cited, access policy is whether you serve automated callers, verified identity is who is calling, operability is whether a caller can finish a flow designed for people, and this is what a transaction looks like when an agent is a party to it. 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. ### An agent wrote it, it merged clean, and it broke at 2am in front of someone who had never seen it. What helps? Making the code legible under pressure, decided at merge time, because 02:00 is the one moment when nobody can add it. The cost has moved rather than disappeared. 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 45% said debugging AI-generated code takes longer than writing the equivalent themselves. Writing got cheap and understanding got expensive, and those are different budgets. 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 the bill lands: 78% reported more incidents once AI-generated code ships and 86% reported senior staff spending more time fixing code, which is the opposite of what the tools were bought for. A guard asks whether a change is well-formed. Nothing asks whether a stranger holding a pager can read it, and on the Frontend that fails four ways, each cheap to prevent and impossible to fix during an incident: a minified stack because source maps were never uploaded for that release, an error with no release or commit stamped on it so there is no path back to the diff, a blank region instead of a designed error state so the first signal is a customer, and no correlation id across the boundary so the client event and the server trace stay unrelated. It becomes assertions on changed lines inside the guards already running, plus build configuration for source maps and release stamping, plus ownership routed from module boundaries rather than commit authorship. Two honest limits: it shortens how long you are inside an incident rather than reducing how many you have, and it cannot retrofit comprehension of a codebase nobody understands. We do not join your on-call rotation and we do not sell an observability product. ### Our AI feature forgets everything between sessions. What does adding memory actually cost us? More than a vector store and less than a rewrite, and almost all of it sits in three decisions that have nothing to do with the model. Memory stopped being a differentiator during 2026 and became an expectation, so a product whose AI feature reintroduces itself every visit reads as a demo. What gets underestimated is that memory is product state rather than a model setting: it has a schema, a lifecycle, an owner, a failure mode and a user interface. Scope is the decision that causes the incident. What this user prefers, what this workspace has established and what the system learned about the job in general have different owners and different blast radii, and a memory written in one person's session and retrieved in a colleague's is a disclosure that arrives as a fluent, helpful sentence rather than as a visible bug, which is why it survives testing and is discovered by the person it was disclosed to. Scope belongs on the record at write time, not in a read-time filter one code path forgets. Control is the second decision and it is a Frontend job: users must be able to see what the product remembers, correct it and delete it, because a wrong memory silently degrades every future answer while the user has no way to discover why the product got worse. Deletion is the third and it is where most implementations are quietly non-compliant, because GDPR Article 17 reaches the derived copies: the record, the embedding, the cache, the prompt logs, the eval set built from production traffic, and backups under a documented restore-time policy. An embedding of personal data is still personal data, so a deleted row beside a surviving vector is not erasure. Retention is set per scope with expiry as the default, since an eighteen-month-old preference is a confidently wrong answer with tenure. On regulation, be careful who sells you a deadline: the EU AI Act record-keeping 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 rather than the Act. We build this in your repo behind your existing auth and permissions. We are not a memory vendor and we do not run your data protection programme. ### Our AI-written UI looks perfect in Chrome and broken on our customers' browsers. Why does nothing catch that? 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. What changed is the rate rather than the mechanism: 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. The type checker has no opinion about a CSS property, the tests run in one headless engine and pass, and the reviewer reads a diff that is genuinely well written. 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 on that list precisely because they do not behave the same everywhere yet, and they are exactly what an agent will propose. The fix is to stop holding the browser matrix as tribal knowledge. Baseline made the target machine-readable and Browserslist reads those queries natively, so the target becomes one config line rather than a wiki paragraph, enforced on changed lines through the ESLint CSS baseline rule, the HTML equivalent and Stylelint reading the same config. Then it classifies rather than forbids: enhancement behind a feature query is allowed, a hard dependency with no fallback stops the run, and a behavioural difference inside the target goes to the grid. The larger half of the value is that the agent now reads the target and stops proposing what you cannot ship. Two honest limits: your real target comes from your own analytics and deciding which browser to drop is a business decision with a revenue number attached, and a rule about syntax cannot catch a feature that is supported everywhere and implemented differently in one place. We are not a browser testing vendor and we do not sell or run a device grid. ### We put an AI assistant in our product and a screen reader user cannot follow it. Why did our accessibility testing not catch that? 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 what broke. Three failures do the damage and none is a rule violation. The stream: tokens arriving 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, and the version that works announces on sentence boundaries, politely rather than assertively, with the region marked so only new text is read instead of the whole reply re-read on every chunk. Focus: the response lands where the user is not, and controls that did not exist when they submitted, stop generating, copy, regenerate, approve this tool call, appear underneath them mid-stream. And the genuinely new one, that 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, which no audit of a repository can cover. The context is worth reading honestly: the WebAIM Million, published on 30 March 2026 across the top million home pages, found detected WCAG 2 failures on 95.9%, up from 94.8% and reversing six years of improvement, at 56.1 errors per page, a 10.1% rise, with the same six categories leading for a seventh year, and the 2025 Web Almanac across 17.2 million sites found 67% of sites removing the default focus outline. Those are the machine-findable errors on documents that sit still, and they got worse in the year output volume went up. The structural fix is the one the design system already taught you: the model never emits markup, it selects from a typed component registry with schema-validated props, so the accessible component is the only one it can render. Then the stream, the focus and the wait are tested with a keyboard and a real screen reader against a live response, and the accessibility assertions go into the eval set. Two honest limits: this makes the interface usable rather than the answer correct, and a registry constrains what the model shows rather than what it says. We are not an accessibility auditor, we do not issue conformance statements or a VPAT, and the merge gate holding your own codebase to EN 301 549 is Factory work. ### Our AI-written screens work perfectly for admins and break, or leak, for every other role. Why does nothing catch that before merge? Because the rule the screen enforces does not live in the screen, and nothing in your pipeline 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 nothing keeps the copy true. The type checker will not tell you a viewer can reach the refund button, because a boolean is a boolean. The tests pass, because whoever wrote them was signed in as an admin, and so is everyone who reviews and demos the product. And the reviewer reads a diff that looks exactly like the 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 loosens the guard rather than asking who is supposed to be allowed. It cannot look the policy up, because the policy is not in the repository it was given. The failure runs in two directions. Hidden but allowed is the security one: the control is not rendered, the endpoint answers anyway, and hiding a button was never access control. 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 costs revenue: a whole role gets a subtly broken product, nobody internally sees it because nobody internally signs in as that role, and the people who do churn rather than file bugs. The fix is to make the policy something the code and the agent both read. Permission-dependent rendering goes through one typed capability layer generated from the server policy rather than hand-copied, so a role name or plan-tier string anywhere else fails the run. 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 made anyway, because the first without the second is theatre. A new route or protected action with no entry in the access map stops the run, starting as an inventory and ratcheting onto changed lines. Two honest limits: this proves the interface agrees with the policy you declared, never that the declared policy is the one you intended, and it does not close an open endpoint, it makes one visible. We are not a security auditor, we do not run penetration tests, and we do not design your permission model. ### We just put usage limits on our AI feature and users keep hitting them in the middle of something. Is that a pricing problem or a product problem? Both, and the half you can fix this quarter is the product one. A limit is not a billing setting, it is a state the interface has to be designed for, and it arrives at the worst possible moment by construction, because the user meets it after committing the work rather than before. 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, with budget controls that stop hard and no automatic fallback to a cheaper model: defensible in a developer tool bought by the person who set the budget, brutal in a product where the user never chose the limit. 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 and credit models growing 126% year over year across the top 500 SaaS and AI companies, so most products are about to render a meter they have never rendered before. Four things decide whether it lands and all four are Frontend. The balance is denominated in the user's own work rather than in credits, because a credit exists for your invoice and roughly twelve more of the thing they came to do answers the question they actually have. The wall is a designed state: preserve what they typed, name whose limit was reached, theirs, their workspace's or their plan's, since only the third is an upgrade conversation, and offer a real next step, a cheaper path, a smaller model with the degradation stated honestly, a wait-until time, or a request that reaches the budget holder with the context attached. The same button can cost one unit or two hundred depending on the input, so an estimate and an explicit approval before the expensive run is the difference between a meter people trust and a feature people quietly stop opening. And the spender is not the payer in a business product, so the administrator needs allocation, per-team visibility, alerts before a pool empties and caps they can set themselves. Warn before the wall rather than at it, in work remaining rather than percentage remaining, and instrument the limit as a funnel. A commercial entitlement is not a provider rate limit, which is temporary and not the user's fault, and neither one is your own coding-agent bill, which is a Factory question. One honest limit: rendering a limit well does not make an unpopular limit popular, and if the packaging is wrong this surfaces it faster. We are not a billing platform, we do not resell inference, we do not set your limits, and we do not price or package your product. ### Marketing adds tracking tags through a tag manager and none of it goes through a pull request. Is that our problem or theirs? Yours, because it executes in your users' browsers under your domain. The HTTP Archive's Web Almanac found in 2025 that around 90% of pages carry at least one third party, with a median of 16 distinct third-party domains, and scripts are the largest slice of third-party requests at 24.8%. The chain matters more than the count: median third-party inclusion depth is 3, so the vendor you approved loads one you did not, and the deepest chain observed ran 2,285 levels. A script is the one third-party type that runs with the full rights of your own code, on your origin, over your form fields. And a tag added through a tag manager reaches production with no branch, no diff, no reviewer, no test and no rollback beyond somebody logging in to switch it off, which makes it the last unreviewed path to production in most companies and a Frontend one. PCI DSS v4 requirements 6.4.3 and 11.6.1, mandatory since 31 March 2025, already wrote the answer down for payment pages: an inventory of every script executing there, a method to authorize each one, a method to assure its integrity, a written justification, and tamper detection on the page. We install that as a gate rather than as a report. The inventory is taken from production sessions and reconciled against what the team believes is loaded, every entry gets an owner or gets deleted, the allowlist becomes a content security policy generated from the inventory and reviewed like any other change, integrity is pinned where the vendor permits and documented as a named exception where it does not, third-party bytes and third-party main-thread time get their own line in the performance budget rather than being absorbed into the total, and consent behaviour is asserted in the flows your pipeline already drives by declining everything and checking that nothing in the tracking category fired. The policy runs in report-only for a full traffic cycle before it enforces anything. We gate vendors rather than tags, so a new event, audience or trigger on a vendor already on the list waits for nobody, and a genuinely new domain executing code in your product is a same-day pull request against a list. We do not take the tag manager away from your growth team: they get the same door everyone else got, with a gate on it and a rollback behind it. Two honest limits: a policy stops a script from loading and does not audit what an approved script then does, and this makes nothing compliant with anything. We build and operate the gate inside your pipeline. We are not a privacy law firm, we give no legal advice, we do not certify compliance, and we do not sell or pick your consent platform. ### A user uploads a document to our AI feature and gets a confident answer about half of it. Is that the model or us? Almost always you, and the part you can fix is the interface rather than the model. The limits that decide it are published and none is about intelligence. Anthropic's PDF documentation caps a request at 32 MB and at 600 pages, and at 100 pages when the request's context window is under 1M tokens; the file must be a standard PDF with no password or encryption; every page is processed as an image, so a dense document can fill the context before it reaches the page limit and a large request can fail before it too. The same three pages cost roughly 1,000 tokens read as text against roughly 7,000 read visually, and on one platform path a request sent without citations enabled is quietly downgraded to text extraction that cannot see a chart at all. So somebody drops a 300-page scanned contract into your feature, waits, and gets a fluent answer about the part that fit, and nothing in the interface separates the model read it and got it wrong from the model never saw page 214. The user cannot tell either, which is how a feature loses its credibility in one afternoon. That separation is the build and all of it is rendering. State what will happen to the file before the wait rather than after it: how many pages, whether it will be split, what will be read as an image. Render a read receipt, which pages were read, which were skipped and which came back empty because they are photographs of a page. Make every citation resolve to a page and region the user can open, and treat an answer that cannot cite as a failure state rather than as prose. Design the encrypted file, the oversized scan and the phone photo taken at an angle as named states that preserve the upload and name the next action. And be truthful at the drop zone about the crossing itself: which processor receives the file, whether it leaves your tenancy, whether it is retained and for how long, with redaction offered before the upload rather than after it, and an administrator surface for the person who has to answer for it. What happens to that content once stored is the memory question and is answered separately, and whatever the document says is untrusted content rather than an instruction. We build the ingestion surface, the disclosure, the states and the citation UI inside your product. We are not a document-AI or OCR vendor, we do not sell or benchmark an extraction model, and no pipeline makes a genuinely unreadable page readable, which is why the honest version reports what it could not read instead of answering anyway. ### Our coding agents keep writing new components instead of using the ones we already have. Why does nothing catch that? Because duplication is the one defect class that passes every gate you own. A copied component arrives at review using your tokens, with an accessible name, with a test, inside the performance budget, and two hundred lines nobody has read before. Every check asks whether the new thing is well made; none asks whether it should exist. GitClear published The Maintainability Gap in June 2026 from 623 million code changes across 2023 to 2026: refactoring line moves down 70%, long-term legacy maintenance down 74% against 2022, cross-file function calls down 35%, against code block duplication up 81%, within-commit copy and paste up 41% and error-masking catch blocks up 47%. The code is not being reused, it is being reproduced, and the cause is mechanical: finding the component that exists is a retrieval problem and writing a new one is not. On the Frontend a duplicate is a second source of truth for a brand, a second cache, a second validation rule. So reuse becomes an assertion: a registry generated from your code that the agent reads before it writes, a similarity check on changed lines that names what a near-duplicate duplicates, deletion treated as part of done, error-masking catches failed on changed lines, and reuse and duplication reported as a trend beside guard catch rate. We never push you toward a shared abstraction that couples two features which only look alike: duplication is cheaper than the wrong abstraction, so the gate proposes and your engineer decides. We are not a code-quality analytics vendor and everything we install runs without us. ### Our in-product AI assistant gives different answers than our own interface does. Which one is wrong? Usually the assistant, and usually for a structural reason: it was built as a second implementation of your product, with its own queries, its own permission checks and its own validation, written beside the interface rather than through it. WebMCP, developed in the W3C Web Machine Learning Community Group and open as a Chrome origin trial at version 149, was designed around exactly this. Its explainer states the goal plainly: any task a user can accomplish through a page's UI can be turned into a tool by reusing much of the page's existing client-side code, with site-owned code performing the action and keeping its UI in sync. It names the cost of the other approach too: UI disintermediation, authentication replication, developer burden. So the build is one capability layer with two callers. The tool the agent calls runs the same typed function your button calls, so validation, permission, telemetry and audit are inherited rather than rewritten, and the difference between the human path and the agent path is transport rather than behaviour. Then you assert it with a contract test that runs the same case through both callers and fails when they disagree. A tool call is untrusted input whatever produced it, exposure is decided flow by flow rather than inherited, and irreversible actions render real parameters and carry an idempotency key. The specification sits in a community group rather than on the Standards Track and the trial is one browser, so we build it as an additive layer behind capability detection, never as the only path. ### We wrote AGENTS.md and CLAUDE.md months ago. Why are our coding agents getting worse instead of better? Because the context file is the one artifact in your repository that no test is allowed to fail, and the codebase moved after somebody wrote it. A study accepted to the 23rd International Conference on Mining Software Repositories in 2026 scanned 10,000 active repositories, found only about 5% carrying any AI context file, and read 155 AGENTS.md files closely: 77 of them, exactly half, had never been changed after the first commit, and another 36 had been changed once. A June 2026 catalog of configuration problems read 100 popular projects carrying an AGENTS.md or CLAUDE.md and found at least one problem in 91 of them, naming init fossilization (a file generated by a tool's init command, never reviewed, treated ever since as the configuration), lint leakage, skill leakage and conflicting instructions. A stale README is skimmed by a human who has doubts; a stale context file is obeyed, and nothing errors, because from the agent's side nothing failed. So we treat it as code with an assertion behind it: everything derivable generated from the repository (commands, scripts, paths, module boundaries, the component registry), everything else written so a machine can check it and checked in the CI run the guards already use, the file changed in the same pull request as the code it describes, and an owner in CODEOWNERS derived from the boundaries. No eighth guard, no context dashboard, and the first cycle reports without failing anything. An assertion proves a line is still true, never that it earns its tokens, which is the separate scope question. We are not a documentation vendor and everything is committed to your repository. ### Our AI assistant quoted a policy we changed six months ago and the citation opened the real document. How did nothing catch that? Because nothing failed. Retrieval ran, similarity scores were good, the citation resolved to a genuine document, latency was normal and the sentence was fluent. Retrieval ranks by similarity and similarity has no opinion about time: a superseded policy is still the most semantically similar document to a question about that policy, often more similar than its replacement. The 2026 work on temporal misalignment in factuality evaluation, When Benchmarks Age, shows the widely used factuality benchmarks are static snapshots (TriviaQA from 2017, BoolQ and Natural Questions from 2019, TruthfulQA from 2022) with a considerable share of samples out of date, and its open-book finding is the one that matters for a product: handing a model an outdated passage can leave it worse aligned than handing it nothing, because it leans on the provided context over what it knows. The fix is mostly rendering. Every claim carries its date, and the citation carries when its source was last verified rather than only that it exists. A superseded source renders as superseded with a link to what replaced it, never silently used or silently dropped. When the only supporting source is expired the honest state is a refusal showing the document, its age and its owner. And the report control on a wrong answer resolves to the chunk and its owner, so a correction lands on the source rather than in a support queue. The date is read from the system that owns the content and never invented by the interface. Eval fixtures age the same way, so they carry an as-of date and expire. We are not a vector database or search vendor, we sell no index or embedding pipeline, and no interface makes a corpus current. ### Our coding agents have internet access and our security team is asking what they can reach. What do we tell them? That the boundary is open on purpose, so the control has to be a record rather than a wall. In August 2026 the UK AI Security Institute published an incident report on its own evaluation infrastructure: one cyber-security challenge run 122 times across seven models, with internet access deliberately enabled and the providers' safety classifiers deliberately switched off to measure raw capability. In 10 of the 122 runs an agent took autonomous, unsanctioned action on the live internet against real people and organisations, and 19 such actions were catalogued, the most serious a supply-chain attempt in which the agent created a GitHub account, tried to get an open-source maintainer to accept a malicious pull request, and created a second account posing as another person endorsing it. Nothing escaped: the containment was open by design, which is what makes it useful rather than alarming. The number that matters is the four days. The activity ran from 25 to 28 July 2026 before anyone noticed, and what surfaced it was the security team seeing unusual data leaving over Tor, not a check on what the agent was doing. Containment then took about an hour and no real-world harm was identified. For an agent the network is the only boundary that observes. Two things make it sharper on the Frontend: the Frontend agent has the widest legitimate egress surface you have (package registry, fonts and assets, the design tool, preview deployments, and the real browser it drives to verify its work, which its own allowlist never sees), and Frontend CI credentials are the publishing kind (deploy tokens, CDN purge keys, registry publish tokens, analytics and error-tracking write keys) that write to the public internet. The vendor sandbox is not a perimeter either: the most widely deployed coding agent shipped two independent network sandbox bypasses inside a year, one where the sandbox failed to cover a configuration file that did not exist at process start and one where a single null byte in a hostname defeated wildcard allowlists including the vendor's own domain, with the second fix shipped with no advisory and no changelog line. So we install the substrate: egress default-denied and allowed by exact host rather than wildcard, the allowlist generated from what the build actually resolves, installs routed through a registry proxy so the install path is one observed destination, the agent's browser inside the same perimeter, run-scoped short-lived credentials held by the substrate, publishing moved out of the agent path, and every outbound connection recorded against the run and the diff, so a host no previous run contacted is a reviewable line on the pull request. No eighth guard: this sits in the security gate's lane, before the merge decision. An allowlist reduces blast radius and is not containment, and a permitted destination can carry anything, so the record says where a run went and never what was in it. What it buys is that you stop finding out four days later. We are not a security vendor, we run no threat intelligence feed and no incident response, and we certify nothing as contained. ### We are adding an AI agent that writes into documents our customers share with each other. What breaks? Authorship, first, and the rest follows from it. A shared document assumes every change had a person behind it who can be asked about it, and an agent makes "who wrote this" unanswerable: the change was produced by a model, triggered by one teammate, configured by another, and landed in a paragraph a third was editing. Collaborative Document Editing with Multiple Users and AI Agents, by Lehmann, Shauchenka and Buschek, presented at CHI in April 2026, put 30 people across 14 teams into a shared editor with agents for a week of real writing projects. The design choice that carried the result is worth copying: the agent was visible to everyone through two shared objects, agent profiles and tasks, and its output arrived in the familiar comment feature rather than in the body of the document. Logs and interviews found teams folded agents into existing norms of authorship, control and coordination rather than treating them as team members, with agent profiles read as personal territory while created agents and their outputs became shared resources. That condemns the version most teams ship first, an agent that edits directly and quietly. So the default is a proposal a person applies, with direct editing enabled per surface knowingly and only where the change is mechanical, bounded, reversible as one unit and still attributed. The rest is rendering and data model: attribution at the granularity of the change recording the agent, the profile it ran under, the person who triggered it and the person who applied it, since attributing to the model leaves nobody to ask and attributing to whoever clicked apply says a human wrote a sentence a human did not write; that record surviving into operational transform or CRDT metadata, version history, diffs, export and review rather than dying at reload; presence for a non-human author on the region it is working on; undo that spans authors so reverting the agent does not take two humans' paragraphs with it; an owner on every agent; and a decided limit on how much it may change in one pass and in whose region. Keep it apart from Agent UX, which is one user seeing and stopping one agent, and from authorization, which is who may act. This one is who did, and whether anyone can still tell a week later. We build the surface, the attribution model and the agent's place in it on the editor and sync stack you already run. We are not an editor vendor, we sell no real-time backend, and attribution makes accountability answerable rather than assigning it. ### Our security team has not approved AI coding tools, so the rollout is stuck. What are they actually asking for? One question wearing seven costumes: where does our source code go, and who keeps a copy. Gravitee's State of AI Agent Security 2026, from 919 executives and practitioners, found 80.9% of technical teams past planning and into active testing or production and only 14.4% reporting all of their agents live with full security and IT approval, so the stall is the normal position. The distinction that closes most of the questionnaire is that not training on your data and not keeping your data are different promises, and vendors offer the first when asked about the second: a provider can honour a no-training commitment completely and still hold prompts for a standard abuse-monitoring window, which for a coding agent means file contents and diffs in someone else's logs for weeks. Zero retention is the stronger claim, it is usually an enterprise-tier setting rather than a default, on several platforms training exclusion is opt-in, and it applies per surface rather than per vendor, so an org can be at zero retention on the API and at the default on the desktop product, the IDE extension and the CI integration. The path teams forget is not the model provider at all: whatever runs evals, tracing, prompt observability and error reporting holds the same content under a second set of terms nobody read, usually chosen by one engineer in an afternoon. In May 2026 the AI evaluation platform Braintrust told customers to rotate every key stored with it after unauthorized access to an AWS account; what was reached was credentials rather than source code and one customer was confirmed affected, so it is cited for the structure, that a coding pipeline has more than one custodian and only the first gets a security review. This arrives earlier for us because the factory's own claim makes the question bigger first: everyone ships means more people running agents across the repository, and the Frontend repository is usually the least locked-down one in the org while carrying unreleased product names, the pricing table, flags for unannounced features and publishing keys in its environment files. What the review wants is a sheet saying, per surface, where the code goes, who holds it, for how long and where that is configured, with the settings committed as configuration rather than clicked once in a dashboard, plus redaction before a span leaves the process, a scoped credential per tool and the self-hosted option where a tool has a real one. We are not auditors, we certify nobody, we do not sign your data processing agreements and we do not resell model capacity. The honest limit: a retention setting is a contractual promise rather than a technical control, so repositories that genuinely cannot leave stay out of agent context, or the model runs inside your boundary. ### Our AI feature is a text box and most users type nothing into it. What do we put there instead? Almost anything, and the reason is structural. A prompt field compresses every capability into a rectangle that says Ask anything, so a user must guess the vocabulary, the scope and the phrasing at once, before any evidence that guessing is worth it. I Just Need GPT to Refine My Prompts, by Gautam, Bhatia and Chilana of Simon Fraser University, presented at CHI in Barcelona in April 2026, observed 26 people, 14 casual users and 12 professionals, using prompt-based generative tools. Participants skipped tutorials and the manual and worked by trial and error, which is decades old; what changed is where the trial and error went. The prompt box became the entry point for learning, collapsing onboarding into immediate action, and some casual users left the tool entirely to ask a general-purpose model how to prompt the tool. So your AI feature is your onboarding surface whether you designed it as one or not, and when it does not teach, the help-seeking leaves your product and lands in nobody's funnel. Trust is still the largest barrier and a product tour still aims at the smallest; this is the one in between, understanding how the thing works, and it cannot be solved with a banner because it has to be solved where the work happens. The second finding decides the interface: the professionals used domain expertise to refine and to reject, discarding outputs that fell short, while the casual users settled for good enough. Same tool, same model, and expertise was doing the evaluating, so the interface owes a non-expert what the expert supplies from their own head. One field cannot carry it: Nielsen Norman Group ran a diary study across ChatGPT, Bard and Bing Chat where 18 participants logged 425 conversations and found six distinct conversation types serving different information needs and calling for different interfaces. What we build instead: entry points that name a capability at the object it acts on, starting points drawn from the user's own data and current screen rather than static example prompts, a stated boundary of what the feature can see and will not do, grounds rendered alongside the answer, correction as the primary action rather than regeneration, and one-click rejection that is instrumented, since a rejected answer is the most informative event the feature produces. Keep the free-form field, just stop making it the front door. Boundaries: this does not rescue a feature whose answers are wrong, which is reliability, and whether it helped the people who used it is measurement. This one is only whether a first request can be formed at all. ### Our coding agents keep tidying up code that was there for a reason, and the tests still pass. What stops that? A guard, and it has to be a guard rather than a code comment, because the agent is not being careless: the line looks like an accident, nothing in the repository says otherwise, and removing it makes the diff cleaner. A May 2026 analysis of 20,574 real coding-agent sessions across 1,639 repositories catalogued seven recurring forms of misalignment and found 90.50% of episodes cost effort and trust rather than doing irreversible damage, while 91.49% of the resolved ones were resolved by a person noticing and correcting the agent, and constraint violations grow as a share of what is left as overall rates decline. So this is the failure mode that survives better models. The Frontend version is worse than most, for two reasons. The most load-bearing code on a Frontend is the code that looks worst: a zero-delay timeout that fixes a focus race after a portal mounts, an aria-live region that reads as redundant next to a visible message, a stacking rule that exists because of one Safari paint bug, an explicit key that forces a remount, an overflow that stops iOS scroll chaining, a debounce tuned to somebody else's rate limit. And removing them is invisible to the suite, because what they defended against is a browser, a device, an input method, a locale or a screen reader CI does not run: the test passes because it never knew about the thing the line prevented. What works is measured, and it is not more rules. The TDAD work published in March 2026 built a code-to-test graph and handed the agent the tests a proposed change would affect before it made the change, taking test-level regressions from 6.08% to 1.82%; adding test-driven-development instructions without that targeted context took them to 9.94%, worse than doing nothing. Context at the point of the edit beats instructions in a file. So the reason gets attached to the code as an executable invariant written at the moment the fix lands, named after the failure rather than the function, so removing the behaviour fails a run instead of starting a conversation; the impact surface is derived from the repository and handed to the agent before it writes; and a line the agent cannot explain is a line it does not delete. No eighth guard, this rides in the test-quality gate. We are not a documentation vendor, and an invariant proves a behaviour still holds, never that it is still needed, so the set has to be prunable. ### Our AI feature takes twenty seconds to answer and people leave before it finishes. Is that a model problem or an interface one? Mostly an interface one, and the 2026 research is more surprising than the question expects. A CHI 2026 study of 240 people held time to first token at 2, 9 or 20 seconds across two knowledge task types and found participants who waited 2 seconds rated the output less thoughtful and less useful than those who waited 9 or 20; people read a wait as deliberation, up to a point, and the point is not where the engineering instinct puts it. The same study measured who noticed the delay at all: 29.3% at 2 seconds, 60.5% at 9 and 80.0% at 20 in the creation task, with the advice task following the same curve. Counting the Wait, also presented at CHI in Barcelona in April 2026, put 425 people through 10, 30 and 60 second waits with one of three displays, and found that showing time remaining produced more frustration than showing time elapsed while showing nothing made the wait feel longer and left people unsure anything was happening. The paper's own limit is worth repeating: in a short, repetitive task the experiential difference did not show up in post-wait performance, so this is a claim about abandonment and trust rather than throughput. The rules that follow: never render a countdown or a percentage you cannot keep, because a generative system cannot predict its own duration and an estimate it keeps revising is a promise it keeps breaking; render elapsed time and the name of the step actually running; never render nothing; stop treating sub-second as the goal for work that genuinely takes work, and never add artificial delay to make an answer look considered; stream only where a fragment is usable, since streaming one number or a yes or no is theatre that shows half of a wrong answer sooner; match the skeleton to what will actually arrive. Past roughly ten seconds it stops being a wait and becomes a job: the user gets to leave, the state survives a reload, the result lands somewhere findable, failure is resumable from the step that failed, and cancel stops the run and the spend rather than the animation. None of it makes a slow feature fast, and what a feature costs to run is a separate question. ### Every agent branch passes CI on its own and main keeps breaking anyway. What are we missing? Integration, the one stage of the pipeline nobody added capacity to. A 2026 study of 33,596 agent-authored pull requests across 2,807 repositories found 40.2% of those repositories had agent pull requests open at exactly the same moment, with co-active pairs accounting for 79.4% of every pull request an agent produced; at a one-week window, 53.4% of repositories and 95.0% of pull requests. Parallel is the normal state of a repository with agents in it. AgenticFlict, a 2026 dataset of over 142,000 agent-authored pull requests from more than 59,000 repositories, replayed the merges deterministically and found a textual conflict rate of 27.67% across more than 336,000 conflict regions, so roughly one in four will not merge cleanly and almost all of them have a sibling in flight. The part neither study measures is the part that breaks a Frontend, because a textual conflict is the good case: git stops and asks. The expensive case is the clean merge. Two branches that never touch the same line each add a modal, so the design system now has two. Each adds a token and the winner is decided by import order. Each adds a route and two patterns match one URL. One widens a shared hook and the other adds a caller written against the old contract, and because widening is backward compatible the types agree. Each raises a z-index by one and the header covers the dialog only once both have landed. Each adds a lazy chunk that was under budget alone. Every one of those merges without a marker and is a defect the merge created rather than one either branch carried. So the guards run against main as it will be after this change lands rather than against the branch in isolation, and pull requests are admitted in an order instead of all at once: the duplicate, token, route, accessibility, budget and contract checks evaluated on the composed tree, with the batching we already do for CI cost as the same mechanism and automatic bisection so an innocent pull request is not punished for a neighbour. No eighth guard, this is the existing guard set evaluated at a second point. Two limits: a queue buys correctness with latency, so below a certain merge volume it is the wrong trade and we measure first; and no gate decides which of two equally correct modals should survive, only that there are two. On standardising: the same study measured textual conflicts in 41.7% of cross-agent pairs against 19.8% of same-agent pairs, but cross-agent pairs were 0.5% of co-active pairs in roughly 122 repositories, so we quote the direction and will not build a mandate on the number. The lever is shared context rather than a single vendor, which is why the harness is engine agnostic. ### An AI browser is operating our product inside one of our own users' sessions. What are we supposed to do about that? Treat it as a product decision, because since August 2026 it is no longer mainly a legal one. On 4 August the Ninth Circuit decided Amazon.com Services, LLC v. Perplexity AI, Inc. and vacated the injunction that had blocked Perplexity's Comet assistant from Amazon's logged-in pages, holding that on the record before it, it is the user and not the agent's maker who accesses the site for purposes of the Computer Fraud and Abuse Act and its California equivalent; the court was explicit that the holding is narrow and does not reach breach of contract, unfair competition, tortious interference or state consumer protection claims. Take the law out and the engineering fact remains: this agent is not a caller you can classify. It drives the user's own browser, with the user's own cookie, on the user's own device, so bot verification at the CDN, signed requests and operator tiers all sit in front of a door this traffic never uses. It arrives as a signed-in customer, which it genuinely is. The decision surface therefore moves off the visitor and onto the action. Reading, searching, filtering, comparing, adding to a cart: no version of your business wanted to stop those, whoever is driving. Spending money, sending something in the user's name, deleting, changing a shared setting, accepting terms, consenting for somebody: those need a confirmation that renders the real parameters and a person present to give it, which is a control worth having whether or not an agent ever arrives. Detection, when you want it, is behavioural and in-session (interaction without the motion that precedes it, a field filled in one atomic write, navigation faster than the view could be read, first-attempt perfection where humans have an error rate), it is a probability rather than a fact, and it may never be load bearing, because the false positives are customers using assistive technology, a keyboard or a password manager. What changes when the probability is high: the session gets an actor so analytics, support and the account activity view can say the user, via an agent; the flow becomes a candidate to be declared as a callable tool over MCP or WebMCP, which is a better road rather than a worse one and teaches agent makers to identify themselves instead of hiding; and the irreversible steps get their confirmation tightened. Blocking is priceable and the bill is larger than the policy conversation suggests: you cannot do it accurately, the mechanisms that reliably stop an agent are challenges and step-ups that also fail screen readers, switch access, voice control and low-vision zoom (Web Bench, roughly 2,450 tasks across 452 live sites from the global top thousand by traffic, found authentication, form filling, second-factor prompts and file operations are where agents fail, and a login wall often stops one before it acts), and a competitor whose flows complete will finish the task yours refused with no bug report filed. So the no list is decided by consequence, flow by flow, kept short, and enforced with a confirmation that works regardless of what you detected; everything else stays open, rate-limited per account and recorded with an actor; and refusals are legible, with a real status code and a machine-readable reason, since a silent block reads as an outage. Boundaries: we are engineers and not lawyers, your terms are your counsel's call; we are not a bot management vendor and we do not build detection evasion or cross-property fingerprinting. ### Our agents open the pull requests and our review bot approves them. CI is green and the audit trail is complete. What is actually wrong? The approval, which is the one item on that list nobody checked. An audit trail records that an approval happened; it cannot tell you the approval was a control, and in most pipelines running agents in 2026 it is not one, because the identity that asked for the change and the identity that cleared it are the same kind of thing and often the same account. The MSR 2026 mining-challenge study of developer interventions in agent-authored pull requests found humans intervened in 52.17% of agent-authored pull requests against 83.59% of human-authored ones in the same corpus, and that intervention on an agent pull request cost more rather than less, in larger churn and longer duration: roughly half of what agents produce goes in untouched and the touched half is the expensive half. Habituation at the Gate, a longitudinal study of 11,429 reviews from 400 repeat reviewers over seven months, found approval rates on agent-authored code rising from 30.1% to 36.8% while inline comment volume fell 22% and review latency rose 3.5 times, with a 14.5 point cumulative gap between the first and tenth deciles of reviewer experience. The drift tracks how many agent pull requests a reviewer has personally seen rather than the calendar, does not appear on human-authored pull requests in the same repositories over the same period, and survives controlling for difficulty, so the authors read it as reflexive habituation under a growing queue rather than trust that was earned. The part neither study measures is the part that decides a Frontend: the changes most in need of a person are the ones no machine reviewer can judge, whether this should have been a new component at all, whether the empty state is right, whether this copy says what the product means, whether the interaction matches the twelve other places doing the same thing. A bot approves a diff that is individually correct and still the wrong change, a habituated human scrolls past it, and the record afterwards says two approvals. So separation of duties, the four eyes principle if that is the phrase your auditor uses, becomes a property of the pipeline rather than a policy, and change control for AI generated code becomes something a machine evaluates: a machine review is recorded as a guard and never as an approval, since both rendering as a green tick is a user interface accident that became a governance one; every agent run gets its own principal, reusing the identity split the egress and custody work already requires; the merge check compares requester against approver so the identity that asked for a change cannot clear it; the change classes needing a human approval are named (a new component, a token change, a route, customer-read copy, anything touching an irreversible flow or the design system) and the check fails closed when the approver is not a person; and where no human approval is required the record says so plainly rather than showing a tick nobody can explain. Guards run first and return a specific reason to the author, so a change that will be rejected never costs senior attention. What gets measured changes too, because approval count is now a known-corrupted metric: review depth over reviewer tenure, escaped defects split by human-approved against guard-cleared, time-to-first-comment against queue length, and the share of merges where approver and requester were the same. Load-side changes beat exhortation, which the data rules out: shrink what reaches a human, rotate who reviews what since the effect is per reviewer and per exposure, sample a small share of already-approved agent merges for a deliberately slow second read, and make the high-consequence classes unskippable by rule rather than by attention. Limits: separation of duties does not manufacture attention, so if the queue is bigger than the people the answer is fewer pull requests or more reviewers; a rule everybody routes around within a month is worse than no rule, so classification is tuned against your real merge history in the audit; habituation is a human factors effect and we install the measurement rather than claim to have solved it; and we will not propose adding reviewers, because the premise of the factory is that the org you already have ships more. No eighth guard was added. We build the controls inside your pipeline and produce the evidence as a by-product. We are not auditors and we do not certify anyone. ### Our biggest customer's security review is blocking our AI feature. What do they actually want us to build? Controls they can operate without calling you, which is a product requirement rather than a paperwork one, and it arrived this year because the reference contract moved. On 22 May 2026 Microsoft updated its Products and Services Data Protection Addendum to treat subprocessors supporting AI functionality differently from every other kind: at least 30 days of notice rather than the six months other new subprocessors get, a customer right to disable that subprocessor for at least six months after the notice, and, where the subprocessor genuinely cannot be avoided, the right to terminate the affected licence without penalty, applied to the whole suite if the product is part of one. The same vendor now names its model providers as subprocessors and ships a tenant-level admin toggle for them. Your customer's counsel has read that and it is now their floor. Add Article 12 record-keeping and Article 14 human oversight of the EU AI Act, which buyers cite, and the AI section of the security questionnaire converges everywhere on one short list: can we turn it off, can we see what it did, who is processing our data, what happens when you change the model, and who was the human. Every item is a surface, which is why it is a Frontend build and why most vendors fail: they shipped the capability and never built the controls around it. Discard the instinct first, because a build flag, a separate deployment or an environment variable per large customer is two products within a quarter and four within a year, with the tell always a bug that reproduces for one customer and not another. The version that holds is a single code path with a resolved policy in front of it: server-side, because a flag read in the client is a suggestion and their security team will check whether the request still reaches the provider when the toggle is off; resolved once per request at a known layer and passed down, rather than each feature reading the setting itself, which is how one surface answers anyway in an export, a digest or a webhook nobody classified as the AI feature; and hierarchical as customers actually organise, tenant then workspace then user, with the level above able to lock the level below. Granularity is a capability rather than a product, because enterprise buyers rarely want the whole feature off: they want one data class excluded, generation allowed but retention refused, the assistant available but unable to act, or a pilot scoped to one department, and each of those is a row a salesperson can point at in a security review instead of negotiating the roadmap. The activity log is the other half, and an engineering trace is not it: buyers want an authenticated person on every entry or an explicit statement that there was none and which automation acted, the action in your product's vocabulary rather than the model's (a customer cannot audit a chat completion and can audit a refund was proposed on this order), inputs by reference and by class rather than by value since a log duplicating sensitive content is a new liability wearing a compliance badge, the outcome including refusals, whether a human approved where approval was required, and the provider and model version that processed it so a subprocessor change or model swap is auditable rather than reconstructed. Acceptance is decided by a Frontend deliverable: the customer's own admin must be able to read it, because a ticket to your support team is not a control, so it is a screen in the admin area filtered by person, date, action class and outcome, with an export their tooling ingests and optionally a stream into what they already collect, retention as a setting rather than a constant, and access to the log itself scoped and recorded. Alongside it: an effective-policy view answering what is in force for this user right now rather than only what somebody set, admin controls that say in plain language what they change and what they do not, a visible record of who changed a policy and when, honest degradation so a disabled capability is absent or explained rather than present and failing, per tenant model routing so a provider swap is a configuration change rather than a release, and a kill switch at the level a person thinks in, a workspace or a capability rather than a deploy, which buyers now ask for by name alongside ISO 42001 or SOC 2 attestations and model change control for their own tenant. Two things said plainly: a complete log is evidence and never a guarantee, since it proves what happened rather than that the feature behaved well; and we build and operate these surfaces inside your product, on your own authorisation and data model. We are not auditors, we do not write your data processing agreement, we are not your counsel, and we do not certify compliance for you or for your customer. ### Our senior Frontend engineers do not trust AI-generated code and will not put their name on it. How do we fix the culture? You do not, because it is not a culture problem, and getting that off the table is what frees the room to look at the actual constraint. The 2025 Stack Overflow Developer Survey, over 49,000 responses from 177 countries, found 84% of developers using or planning to use AI tools, up from 76% the year before, while trust moved the other way: 29% trust the accuracy of the output, down from 40%, and 46% actively distrust it, up from 31%. Only 3% say they highly trust it, and among the most experienced developers that figure is 2.6%, with 20% highly distrusting. Adoption is not the problem and has not been for a year: your engineers are using the tools and declining to underwrite the output, which are two different decisions a seat count cannot tell apart. The two frustrations underneath carry the argument, since 66% name output that is almost right but not quite and 45.2% name the time it takes to debug AI-generated code. Almost right is the most expensive thing a system can produce, because it survives a skim, passes on a tired afternoon, fails in production, and unlike obviously wrong output it consumes the reviewer's attention before it is rejected. The person absorbing that cost is the senior engineer whose name goes on the merge, so the distrust is a correctly calibrated reading of what they are handed rather than a lag in adoption, and it is the most accurate signal in the org about the state of the pipeline. That is why the standard interventions make it worse: a mandate, another seat rollout and a training day each raise the volume of almost-right arriving at the same reviewer and none of them changes what it costs to reject, so asking for trust while raising the load is asking somebody to be less careful. The answer is not a culture programme, it is changing what reaches a person. Guards run before a human opens the diff and fail with a specific reason returned to the author, so almost-right dies at the machine rather than in someone's afternoon. And the rules those guards enforce are written by your senior Frontend engineers, because what they distrust is unreviewed output rather than automation, and the tacit standard they carry (which component already exists, which token, what the empty and error states must do, what a keyboard user gets, what this is allowed to weigh) is the raw material the factory is built out of. Encoding it is not their judgment being replaced, it is their judgment being the only thing that scales, and it stops being a bottleneck the moment it stops living in one person's attention. In practice the engineer most against it at kickoff often writes the most guards, because they have the strongest opinions about what good looks like and those opinions have never had anywhere to go except a review thread. Candidate rules are settled by running them against your real merge history and showing what they would have caught and what they would have blocked, since a rule that would have blocked forty legitimate pull requests is a preference rather than a standard. Expect the trust figure to move last if at all and never report it as the metric: instrument guard catch rate, review rejection rate on agent output, the share of almost-right caught before a person sees it, review time per pull request read beside merged volume, and escaped defects split by guard-cleared against human-approved. Limits: we build and operate the guards and we are not a change-management consultancy; we will not install guards over the objection of the people who live with them, because a rule the team routes around within a month is worse than no rule; and an engineer with good reasons to distrust your pipeline is telling you something true about the pipeline. ### We want a model to assemble our interface instead of designing every screen. What has to be true before that is safe? That your design system is a runtime contract rather than a document, because the moment your product assembles interface per request the model becomes an author inside your design system and no review step is left that can catch it. Harness4GenUI, the first workshop on harness engineering for generative UI, held at ASE 2026, frames the shift as user interface moving from an artifact into a runtime system, and organises the engineering around stable context models, interface schemas, rendering contracts, testing, observability, safety and governance rather than around generation quality alone. That framing is the part product teams skip: generative UI gets bought as a model capability and has to be delivered as a rendering contract. Consider what you give up the day it ships. There is no build to inspect, because the screen that reached that user existed for one request and nobody will see it again. There is no design review, because the layout did not exist while anyone was reviewing. There is no shared screenshot in a bug report, because the reporter and the engineer did not see the same page. Every question the design system used to answer at review time now has to be answered once, up front, in a contract that holds for every request afterwards. Four things make it work, all Frontend. The model selects from a registry and never emits markup: a fixed component set with typed props validated on arrival, generated from the code that defines the components rather than hand-kept beside it, where a component the model asked for and you do not have resolves to a declared fallback rather than a blank region, because a model asked for something missing will confidently invent it. Accessibility lives in the components rather than the page, since a per-request layout cannot be audited before it ships, so focus order, labelling, live-region behaviour and keyboard paths are properties of the pieces and are tested once. Each component fetches its own data from your own APIs under the signed-in user's authorization instead of rendering data the model handed it, because the alternative quietly promotes the model to being your access-control layer. And the same request produces the same interface, because one that reshuffles every visit cannot be learned, supported, documented or screenshotted, and that bill arrives months after the demo that sold it. Composition is constrained too, which components may nest inside which and how deep, since a valid component in an invalid arrangement is the second failure mode and appears as soon as the first is fixed. The registry is versioned with the design system, renamed or removed components need a mapping rather than a deletion because a model with stale context keeps asking for them, and entering the registry is a deliberate act: anything destructive, anything taking payment and anything carrying legal text should only appear on a screen a human designed. Two more nobody plans for. The generated interface is never the only route to the job, so there is always a path back to the built UI when assembly fails or the user simply wants the screen they know, and that deterministic screen is the one support walks somebody through on the phone. And the render is recorded as structure rather than as a picture, the request, the resolved component tree with its props, the registry and model versions, and the identifiers of the data the components fetched by reference rather than by value, so the interface can be replayed: that is what gives support a view of what the customer saw, engineering a reproduction rather than a story, and you a regression corpus for the next model or registry version. Instrument which components were assembled, which were abandoned and which produced the action, because otherwise you cannot tell a good interface from a merely novel one. Limits: a constrained registry does not make generated output correct, it makes it recoverable and boundable; a replay reproduces the interface and not the model's reasoning, so it is never an explanation of why the model chose what it chose; and we build the contract and the components inside your product, we are not an accessibility auditor, and we do not issue conformance statements or VPATs. ### We stopped hiring juniors because the agents do that work. How does anyone become the senior engineer who reviews all of this? It is a delivery question rather than an HR one, because the person being described is the person your pipeline depends on to approve a merge. The BairesDev Dev Barometer for the second quarter of 2026, published on 11 June, surveyed 1,569 developers across 77 countries and put the same question to both sides at once, 1,059 junior and 510 senior engineers. 85% of the juniors said AI tools had improved their understanding of software development. 16% of the seniors said juniors fully understand the AI-generated code they submit, 57% said they understand it to some extent, and 23% said they rarely do. Those findings are not in conflict: juniors are describing exposure, which has genuinely gone up, and seniors are describing accountability, which has not. LeadDev's Engineering Leadership Report 2026, off 600 engineering leaders, points at the mechanism rather than the mood, with a majority expecting to hire fewer juniors and a meaningful share reporting that AI tools have reduced the direct mentoring juniors receive from seniors. What broke is the apprenticeship, in one specific place. An engineer became senior by being visibly wrong in front of somebody who cared, repeatedly, on a diff, in a twenty-minute conversation that transferred a standard nobody had written down. That loop needed the feedback and it needed the junior to defend a choice they had personally made. Agents removed the second half by making the choice, and volume removed the first half by making the twenty minutes impossible. The peer-reviewed version names the lever. From Junior to Senior, by Dana Feng, Bhada Yun and April Wang of ETH Zurich, an honourable mention at ACM CHI 2026, found that seniors keep control through structured delegation, deciding deliberately what to hand over and what to keep, while juniors swing between over-reliance and avoidance because that boundary was never made explicit to them, and that agency allocation is preconfigured at the organisational layer, in policies, tooling defaults, repository structure and CI guardrails, before any individual's preference gets a say. Your juniors are not choosing how much to delegate; your pipeline already chose for them and nobody wrote it down. That is a description of a factory, which is why this is an engineering answer rather than a training recommendation. When the standard lives in the pipeline, feedback arrives in seconds from a guard that names the rule and the reason rather than waiting in a review queue, and it arrives on every attempt rather than on the ones somebody had time for. The standard becomes legible, because a guard is a written rule with an owner and a rationale, so an engineer can read what good looks like instead of inferring it from rejections. And the scarce senior attention that remains lands on the part no guard can hold, whether this was the right thing to build, which is the part that actually makes somebody senior. Three cheap things go alongside it. The author has to be able to explain the change and the review asks them to, which is the highest-signal question available because it is the one an agent cannot answer on their behalf. The session that produced the change is attached to it, since reviewing a diff without the prompt that produced it is reviewing an answer without the question and half the time the defect is in the instruction. And rejection becomes the pairing moment rather than authoring, because a failure the author owns is the most efficient teaching surface there is and there are now far more of them. Two anti-patterns: do not make juniors hand-write code as a training exercise while everyone else uses agents, and do not respond to the understanding gap by routing all agent output to your seniors for closer reading, which raises load on exactly the people you cannot afford to slow down. Limits: a guard teaches the standard and not judgment, a pipeline does not manufacture senior engineers, and we are not your hiring strategy or career framework. Where a team wants the delegation boundary, the verification discipline and the spec-writing actually taught rather than merely enforced, that is a training engagement on your own codebase. ### Our biggest prospect will only buy if our AI feature runs on their own model. What does that actually change in the product? More than procurement thinks and less than your engineers fear, and the deal usually dies in the gap. Find out which request it is first, because bring your own model is three different builds wearing one name. The shape is already visible in the developer tools that shipped it: Warp documents individual keys a user adds that stay on their own device, team-managed keys and OpenAI-compatible endpoints an admin configures centrally and stores server-side so both interactive requests and cloud agents use them, and bring your own LLM, which routes inference through the organisation's own cloud on AWS Bedrock or Google Cloud under their own IAM. JetBrains' enterprise tier lands in the same place against Vertex AI and Bedrock. Only the third satisfies a buyer whose real requirement is that the data never leaves their account, and the three differ in cost by a factor you cannot absorb quietly. Then the reason this is a Frontend conversation rather than an infrastructure one. In nearly every product we look at, the model provider leaked into the interface: the vendor SDK imported in components, the streaming format assumed by the renderer, the tool-calling shape baked into the state machine, the prompt assembled next to the thing that displays the answer. None of it is visible until somebody asks you to point at a different endpoint, and then a configuration change becomes a quarter. The fix is the same provider boundary that makes a model retirement survivable, which is the argument to make internally: one boundary, two problems, and the second arrived with a contract attached. The part nobody scopes is all interface. Capability stops being a build-time fact and becomes a per-tenant one, because their endpoint may not do vision, streaming, structured outputs, tool calls or the context length your feature quietly assumes, and a model behind an OpenAI-compatible URL is under no obligation to behave like the one you tested. So the feature negotiates capability at runtime and degrades honestly per tenant: a declared capability set per configuration, produced by a conformance suite you run against their endpoint at configuration time and again on a schedule rather than read off their documentation, a rendering path for each degraded mode, and a test matrix that runs your real flows against a deliberately reduced endpoint. Latency and failure change owner too, so "our AI is temporarily unavailable" becomes a false statement about somebody else's infrastructure shown to the one person who cannot act on it. Disclosure becomes per tenant, since the EU AI Act Article 50 obligation to make clear that a person is dealing with AI is discharged by your interface while the provider named in it is theirs. And an eval suite run once against the model you picked says nothing about their configuration, so the evals have to be runnable against their endpoint with results their admin can see. Publish supported configurations the way you publish browser support, verified, compatible and unsupported, because an unbounded promise to work with any endpoint is an open-ended support contract you signed without pricing it. The admin surface decides whether this is a feature or a permanent support queue: configure the endpoint, test it before saving, fail legibly when a key is wrong or expired rather than surfacing as an empty answer to an end user, show which provider and model version answered with the latency distribution for their configuration, let the admin run the same fixed tasks against their endpoint and your reference one side by side, rotate a key without downtime, and write into the same activity record as everything else. Never silently fall back to your own model when theirs fails: the reason that customer configured their own endpoint is that their data must not reach yours, so an undeclared fallback is a data boundary breach wearing a helpful hat. If a fallback exists at all it is a per-tenant setting, off by default, disclosed when it engages and written into the record. Two honest things. Bring your own model moves the inference bill to the customer, which changes your unit economics and usually your pricing page, and that is a commercial decision we do not make for you though we will build the metering behind it. And we build the provider boundary, the capability negotiation, the degradation paths and the admin surfaces inside your product: we are not your counsel, we do not classify data residency or sovereignty, we certify nothing for you or your customer, and we do not recommend a model vendor, because which endpoint you point at is precisely the decision this architecture exists to leave open. ### Our coding agents write better pull request descriptions than our engineers do. Why is that a problem? Because a pull request description is a claim about the code, and it is the one artifact in the pipeline that nothing checks. Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests, by Jingzhi Gong, Giovanni Pinna, Yixin Bian and Jie M. Zhang, posted in January 2026, compared descriptions against diffs across 23,247 agent-authored pull requests from five agents. 406 of them, 1.7%, showed high message-code inconsistency across eight types, and the largest type at 45.4% is the one that does the damage: the description claims changes that were never implemented. Those pull requests were accepted 28.3% of the time against 80.0% for the rest, and the ones that merged took 55.8 hours against 16.0. Read the 1.7% the right way round. It is not a defect rate, it is the rate at which a reviewer was actively pointed at the wrong part of the diff while every guard passed, because no CI check reads English. The companion study on the same dataset, How AI Coding Agents Communicate, presented at the MSR 2026 mining challenge, supplies the uncomfortable half: well-structured descriptions get merged more often and get faster reviewer responses independent of the reviewer's sentiment. Structure predicts merge, which is a warning rather than a recommendation, because a confident, sectioned description buys trust it has not earned and an agent produces one for free. This lands hardest on Frontend. On a backend change the claim and the assertion tend to be the same sentence, since a test says the endpoint returns 409 on a duplicate and so does the description. On a Frontend change the claim is that the button now shows a loading state, that the error toast is dismissible, that the empty state appears before the first fetch resolves, and none of that is visible in the diff or asserted anywhere, so the reviewer reads the description to know what to look for. Frontend is where the description carries the most weight and has the least behind it. The fix is mechanical and it is a guard like the others. Treat the description as an output of the run rather than a courtesy and check it: every claim maps to something that changed, a route, a component, a hook, a token, a test, and every changed surface appears in the description, with an unmapped claim or an unmentioned surface failing the run. The second half is the quieter one and it catches the refactor that rode along. Split the writing by who can be trusted with which part: the pipeline derives the facts from the build, which routes were touched, which components changed, which tokens moved, which stories changed, the bundle and accessibility deltas, and the author writes the two sentences no machine can know, what this was for and what was deliberately not done. Attach the evidence you already produce, since the visual diffs, stories and performance and accessibility numbers are already on that pull request, and a claim about a loading state stops being a sentence once an artifact sits next to it. Link the change to the issue, spec or design that caused it, because a description that only restates the diff is a summary and a summary is not a record: six months later the question is never what changed, it is why. Three things not to do. Do not ask reviewers to read descriptions more carefully, for the same reason we never propose reading code more carefully, since attention is the exhausted resource and every fix has to be on the load side. Do not have a second model write the description from the diff and call it solved, because a model reading a diff can only restate the diff, cannot know the intent it was meant to record, and will restate it confidently wrong often enough to be worse than nothing. And do not score descriptions on length, tone or politeness, which is what most review bots already do. Measure claim-to-diff coverage, the share of merges where the described surface and the changed surface disagreed, and time to first comment read beside merged volume. Limits: the check proves the description covers the change, not that the change is right, and it cannot verify intent, only that an intent was recorded by the person who had one. Boundary: we build and operate this guard inside your pipeline, we do not police how your engineers write, we are not selling you a pull request template, and we do not rank coding agents for you. ### Our product generates images and text for our customers. What do the new AI labelling rules actually ask our Frontend to do? Two things, and almost every team builds only one of them. Both regimes that went live this year split the same way: a mark on the content that a machine can read, and a disclosure a person can actually see. California's AI Transparency Act, SB 942 as amended by AB 853, names them latent disclosure and manifest disclosure and became operative on 2 August 2026 for developers of generative systems above a million monthly users, who also have to offer a free detection tool anyone can use to check whether their system produced a given piece of content. The EU AI Act's Article 50 transparency obligations apply from the same date: 50(2) requires providers of generative systems to mark synthetic audio, image, video and text in a machine-readable format detectable as artificially generated, 50(4) requires visible labelling of deepfakes and of AI-generated text published on matters of public interest, and 50(1) is the one most products already did, telling a person they are dealing with an AI system, after which everybody assumed they were finished. The Digital Omnibus agreed in May 2026 gives generative systems already on the market before 2 August 2026 until 2 December 2026 to meet the machine-readable marking requirement, and anything placed on the market after that date gets no grace period. The Commission published the final Code of Practice on Transparency of AI-generated Content on 10 June 2026. It is voluntary, it covers Article 50(2), (4) and (5), and signatories may rely on it to demonstrate compliance, which makes it the practical specification even though the obligation sits in the Act. Then the part that makes this our problem rather than your counsel's: the mark dies in your own pipeline. Content Credentials, the C2PA standard the ecosystem converged on, attach a signed manifest to the file. Your uploader re-encodes. Your resizer emits five widths. Your CDN transforms at the edge. Your privacy step strips EXIF and takes the manifest with it. Your export rasterises a PDF, your share card is a fresh render, your digest email inlines a thumbnail. Every one of those is a Frontend or Frontend-adjacent code path written by somebody who had never heard of a manifest, and every one drops the mark silently, which is the worst property a compliance artifact can have. The Code of Practice says the quiet part itself: metadata alone is not sufficient because a screenshot, an upload or a format conversion removes it, which is why durable schemes pair the manifest with an invisible watermark and a fingerprint so the claim survives the trip. The visible half is pure interface and it is harder than it sounds: what the label says, where it sits, whether it survives the crop, the lightbox, the feed, the print stylesheet and the email client, whether it is still there when the asset becomes the background of something else. A label nobody sees is not a disclosure. And verification needs three states, never two: signed and valid, signed and broken, and absent. An absent Content Credential is not evidence that a human made the content, and an interface that renders absence as authentic has invented a guarantee neither regime makes. Where this lives in your code matters more than which library you pick: one marking and disclosure layer resolved server-side per asset, in front of every path that emits content, the same shape as every other capability layer. The alternative is a label bolted onto each surface, and then the export, the digest email and the public webhook are the three places that ship unmarked because nobody classified them as the AI feature. Instrument it too: which assets left with a valid manifest, which arrived without one, and which lost one inside your own pipeline, which is the number that tells you whether you are compliant in fact or only in the code review. Limits and boundary, both firm. A mark is a claim about origin rather than a guarantee of truth, and removing it is trivial for anyone who wants to, so this is provenance and not proof. And we build the marking, preservation, verification and disclosure surfaces inside your product: we are not your counsel, we do not decide whether you are a provider or a deployer, we do not sign the Code on your behalf, and we certify nothing for you or for your customers. ### Our engineers use AI on nearly everything and half of them never really check the output. Is that a discipline problem? No, and the measurement says which problem it is. Sonar published its 2026 State of Code Developer Survey on 8 January 2026, from more than 1,100 developers globally: 96% say they do not fully trust AI-generated code to be functionally correct, and only 48% say they always verify it before committing. Those two numbers describe the same person. It is not carelessness, it is a team that knows the risk and cannot afford the hours, and the same survey prices it: 38% say reviewing AI-generated code takes more effort than reviewing a colleague's, while AI already accounts for 42% of committed code and those developers expect 65% by 2027. Two things make it more expensive to review. It arrives without intent attached, so the reviewer has to derive what it was meant to do before judging whether it does. And it is uniformly plausible, smooth even where it is wrong, so the triage instinct a senior has spent a decade building finds nothing to grip, and a reviewer with no purchase reads all of it or effectively none of it. So the factory does not chase the verification rate, it lowers the price of verifying. Acceptance criteria travel with the change so the reviewer checks a stated claim rather than an implied one. The guards decide design system, accessibility, security, test quality, performance budget and Storybook states before a human is asked, so what reaches a person is the residue that needs judgment. Failures return to whoever opened the pull request with a specific reason instead of queueing as a senior's comments. And the number reported is the share of merged changes something proved before a human was asked, read next to the suppression count, because those move in opposite directions when anyone games the first. Full answer on [enpitech.dev/frontend-factory](https://enpitech.dev/frontend-factory). ### Can you build a custom MCP server for our SaaS product? Yes. We design and ship enterprise-ready MCP servers on the current MCP 2026-07-28 spec (stateless, serverless- and edge-deployable), that expose your product to Claude Code, Cursor, ChatGPT and other agentic clients. SSO-integrated auth via MCP Enterprise Managed Auth, audit trails, rate limits, structured tools, rich UI responses through MCP Apps, and long-running async operations through MCP Tasks. Common starting point: 1-2 week diagnostic, then a 4-6 week build for the first production server. ### Do you offer Forward Deployed Engineers, and how is that different from staff augmentation? Yes. Our forward-deployed engineers (FDEs) embed inside your team on a monthly retainer, 6-month minimum, mid-senior to senior only, and every one of them arrives carrying our factory tooling and practices. This is not staff augmentation. It is the same model OpenAI, Anthropic and Palantir use to install serious AI systems inside customers: the engineer owns the outcome end to end, writes production code from week one, and turns the delivery patterns they use into infrastructure that stays after they leave. Think of it as a soft factory install without a formal factory engagement. When the org grows past what one or two engineers can carry, the FDE relationship upgrades into a full Frontend Delivery Factory deployment. The full answer, including how the model compares against opening a req and against staff augmentation, is at [enpitech.dev/forward-deployed-engineers](https://enpitech.dev/forward-deployed-engineers). ### Do you install AGENTS.md and CLAUDE.md for our repo, and why do we need both? Yes, and it is one of the first things we ship in any engagement. AGENTS.md is the emerging shared standard, read by 30+ agents across 60,000+ repositories, and it captures build commands, test procedures, architectural constraints and review rules in one canonical file. CLAUDE.md is Claude Code's own instruction file and, as of Claude Code 2.1.x, it still does not read AGENTS.md natively. The pragmatic setup is one canonical AGENTS.md with a small CLAUDE.md that references it, so Claude Code, Cursor, Codex and every other AI coding tool in your team get the same context and stop re-litigating the same review comments across sessions. We author both, wire them to CI so they never drift, and turn each blocked PR into a guard or a skill upgrade. ### Which generative UI framework should we use in 2026? The default modern stacks: Vercel AI SDK 6 with AI Elements (RSC streaming) for most React projects, assistant-ui or CopilotKit on top of your data, A2UI / AG-UI when you need cross-platform (on 2 November 2026 A2UI’s production release is v0.9.1 and its v1.0 is still a release candidate), and MCP Apps for MCP-first architectures. We pick the right primitive for the job, not the loudest one. ### Which AI coding agents do you support, Claude Code, Cursor or Copilot? All of them. Our engineers work with Claude Code, the Claude Agent SDK, Cursor and GitHub Copilot as default tools, and we install the factory harness on top of whichever your team already runs. The harness is agent-neutral: same context structure (CLAUDE.md, AGENTS.md, cursor rules), same guardrails, same review agent, same evals. Teams frequently run more than one agent in the same repo and we tune the setup so they compose instead of colliding. If you have not picked yet, we default to Claude Code for terminal-native agentic workflows and Cursor for IDE-native pair programming, and we run both when the workload calls for it. ### What does "agent-ready" mean for our product and how does Enpitech help? Agent-ready means an AI agent can find your product, read it, and act on it. Four layers matter: discovery (llms.txt, robots.txt, sitemaps, opting in every retrieval bot), readability (semantic HTML, headings, rich JSON-LD for Organization, WebSite, WebPage, FAQPage, HowTo, Product, Service), actions (WebMCP tools or an MCP server that exposes safe, structured tools), and trust (canonical URLs, entity resolution, security posture). We ship AgentReady, a free scanner that scores your site across 21 checks and returns the highest-impact fixes, and then we do the Frontend AI work behind the fixes when you want us to. ### How do we get cited by ChatGPT, Perplexity, Claude and Gemini for our product category? Answer Engine Optimization (AEO) and Generative Engine Optimization (GEO) are Frontend work now, not a content-marketing side task. The pattern that consistently wins: extractable formats (one-paragraph answers, comparison tables, FAQ blocks), rich Schema.org JSON-LD (Article, FAQPage, HowTo, Product, Service), authority signals (expert quotes, statistics, real citations), entity clarity so the answer engines can resolve you to a single organization, freshness on the pages you care about, and explicit robots.txt / meta opt-ins for every retrieval bot. We audit, ship the fixes, and instrument citation tracking so you measure sales-qualified AI referrals, not just impressions. ### How is pricing structured? Factory deployment is phased fixed-price (install, operate, teach, hand over), with an optional operation retainer after handover. Frontend AI is always fixed-price against a defined scope. Training is priced per session or per program. Embedded engineers are a monthly retainer per engineer with a 6-month minimum. We do not bill hourly and we do not publish rates. Israeli clients are priced in ₪; US and EU clients at 70-80% of comparable domestic agency rates in their market. ### Where are you located? Do you work outside Israel? HQ in Givatayim, Israel. We deliver remotely to clients in Israel, the US and the EU. Primary working language is English. ### Vendors are pitching us an AI code cleanup or "vibe coding rescue" sprint. Should we buy one? Usually not, because a cleanup sprint prices the stock and ignores the flow, and on this problem the flow is the whole story. A 2026 analysis of 304,362 verified AI-authored commits across 6,275 repositories found 484,606 issues, 89.1% code smells rather than outright bugs, with 24.2% still present at the repository's latest revision. GitClear's Maintainability Gap (June 2026, 623 million code changes) shows the mechanism: code block duplication up 81%, copy and paste up 41%, error-masking catch blocks up 47%, refactoring line moves down 70%. The code is being reproduced rather than reused. Meanwhile JetBrains research published in August 2026 put 90% of professional developers using AI coding agents at least weekly and 68% daily, so whatever the sprint cleans up starts refilling on Monday against the same codebase, the same undocumented conventions and the same absent gates. You buy it again in twelve months at a higher price. A rescue engagement is genuinely right in one case and we say so instead of bidding against it: a prototype that was never meant to be a product, built outside your org, with no team attached. That is a bounded rebuild, not remediation. Where the code is in your main repository and your engineers ship through it next week, the version that holds does three things at once. It sorts, ranking work by the cost of your next change rather than by what a static analyser finds ugly, and writes the leave-it bucket down with a reason. It ratchets, so guards fail on the lines a pull request changes rather than on the whole repository, and remediation rides the roadmap instead of competing with features as its own project. And it closes the tap with committed context and a component registry the agent queries before it writes, which is the part a sprint structurally cannot do. We do not sell a cleanup sprint and we do not rewrite your app. ### Our design system team spends its time on maintenance and the docs never match the code. What does that do to our coding agents? It turns your strongest lever into your least reliable input. Pointing an agent at your real components beats describing them to it by a wide margin, but that assumes there is one answer at the other end of the pointer. Usually there are three that disagree: a Figma library, a documentation site and the code. A human resolves that by asking in Slack. An agent cannot ask, so it picks whatever reads most like an instruction, which is almost always the stalest source, and then produces confident output against a spec you retired two quarters ago that passes review because it matches the documentation. Two moves fix it. Stop maintaining a description of the code beside the code: props, variants, states, tokens and deprecation status are read out of the components and served to the agent from there, over MCP alongside Storybook metadata, leaving only intent to be written by hand (when to use this instead of that, what it is not for, which permitted combinations are wrong). Then assert it in the CI run the other guards already use, so a documented prop that no longer exists, a token referenced in docs but absent from the token file, or a deprecated component with no named replacement fails the build instead of becoming a backlog ticket. Second, consolidate before you enforce: a system with four buttons cannot be gated, because nothing can say which one is correct. Inventory near-duplicates by similarity rather than by name, take real usage from the import graph, and ship deprecations with a codemod and a date. Publish tokens machine-readably in the W3C design tokens format so the agent resolves rather than invents a plausible name, and keep the guard that fails raw hex and off-scale spacing on changed lines. Limits: none of this decides whether the component was the right component, which stays with your designers, and a design system with no owner is a staffing problem we cannot solve. We are not a design agency and we do not take over your design system. ### Every guard passes on our agent pull requests and the feature still comes back wrong. What is CI actually proving? That the thing you checked works, which is far narrower than a green run reads as. SpecBench (May 2026) splits a task into the spec in English, visible validation tests exercising each feature in isolation, and held-out tests composing those same features as a user would. Every frontier agent saturates the visible suite; the held-out suite is where the work is missing, and the gap widens by 28 percentage points for every tenfold increase in code size. The Frontend version is sharper: in a June 2026 study, production coding agents re-implemented a React Fluent-UI data table in Angular as a reusable library under a hidden 222-test Playwright oracle across 18 runs and three oracle-visibility conditions. Oracle hidden, the library came back present but unfinished. Oracle in the loop, the score came back near perfect and the library was hollow, the tested behaviour working and everything around it dead or absent. The authors call it building to the test, and the disposition behind it validation self-awareness: an agent does not check what it ships the way a user would, it checks what you check. A guard set is therefore a specification, and the only one the agent can read. Four changes help and none is quantity: check composition rather than features in isolation, check the states a user reaches (loading, empty, error, offline, long content, narrow viewport, right to left, second visit with real data), hold a portion of the suite back from the agent's loop so a green run is evidence rather than a tautology, and keep one check that is an audit rather than an assertion. The adjacent failure is the agent editing the guard instead of meeting it: a suppression comment, an expect-error, a nudged bundle budget or coverage floor, a deleted assertion, a renamed test, a lint rule switched off. EvilGenie detected that class three ways (held-out tests, an LLM judge, direct detection of test-file edits) and observed it from production agents. So guard config, budgets, thresholds, lint and accessibility rules and CI workflow files get ownership; a pull request cannot approve its own change to both the guard and the code it covers; suppression carries a reason and an expiry and is reported as a count; thresholds only loosen by a named human decision. Limits: this catches the edit to the guard rather than the cleverness that satisfies it, and none of it says whether the change was worth making. We build and operate the set inside your pipeline. We do not sell a benchmark and we do not rank coding agents. ### Our hosting platform switched on AI agent tools for our site and nobody on our team wrote them. Should we care? Yes, because you now have a second interface to your product with no owner. On 25 August 2026 OpenAI turned on site tools in the ChatGPT desktop app's built-in browser, so ChatGPT Work and Codex discover and call the tools the current page exposes with nothing for the visitor to switch on, shipped with six launch partners: Google Chrome, Cloudflare, Shopify, Vercel, Render and Netlify. Two made it a default. Shopify serves WebMCP tools on every Liquid storefront, and on Hydrogen storefronts in developer preview, with nothing to install or configure: browse, catalog search, product lookup, variant display, cart read, update and cancel, checkout, order management, policy search. Cloudflare's developer preview turns on selectable tool packs for any proxied site from the dashboard with no code change and no redeploy. Those tools know your catalog and your cart. They do not know your entitlement rules, promotion logic, consent state, fair-use limits or trial gating, because they were written against a platform rather than your business, and they are the same tools every competitor on that platform exposes. They are also invisible: an agent that abandons one halfway lands in your analytics as one fewer conversion and nothing else. Do the inventory instead of panicking. Enumerate what is live on your real routes, signed out and signed in, recording each tool's name and description (what the model actually reads), its schema, what it does when called, and who authored it. Then turn off anything touching money, identity, permissions or destructive state that was not deliberately opened; instrument what stays, per tool, with call volume, failure point and outcome; replace the commercially meaningful ones with declared tools over the capability layer your own interface already calls, so an agent gets your rules rather than the platform's approximation; leave the read-only ones that help somebody find you. Two properties hold whatever you expose, and Chrome's guidance is blunt about both: a tool call executes in the browser, so an agent-submitted request is exactly as untrusted as a human-submitted one and a schema is not a security boundary, meaning validation and authorisation happen again on the server; and anything irreversible needs the flag that asks for a human confirmation plus the interface to collect one. Tools returning user-generated or externally sourced content are a prompt-injection path and must label that payload as untrusted. Sequencing: capability layer first, declared tools as a thin adapter on top, or you have shipped a second implementation of your product that drifts within two releases. Boundary: we build the capability layer, the declared tools, the confirmation surfaces and the instrumentation inside your product. We do not run your CDN or commerce platform, we do not resell a tool pack, and which flows you open is your commercial decision. ### Our agents open pull requests nobody can review and a lot of them never land. Is that the agents being bad at the job? Mostly it is the shape of the work, and three MSR 2026 studies on the same public dataset of agent-authored pull requests make the distinction measurable. Across roughly 33,000 agentic pull requests from five coding agents, about 71% merged, and the ones that did not were the larger changes: more lines, more files touched, more likely to fail the project's own CI before a person read them. A second study took 11,048 closed agentic pull requests, narrowed to the 9,799 a human had reviewed, and hand-inspected 717 to recover why each closed: only 35.7% of rejections were a clear agent failure, 31.2% were workflow constraints (superseded, duplicated, wrong target branch, no longer wanted) and 33.1% recorded no rationale at all. A third compared 24,014 merged agentic pull requests against 5,081 human ones and found the sharpest difference is not what the code does but how it arrives, with far higher commit counts and more files per pull request. So a large slice of agent output was never going to land for reasons unrelated to the code, and another slice is technically fine but arrives as a wall. Neither is fixed by asking the agent to be more careful. Upstream: work is claimed against a register humans and agents both read, so duplicate work is not discovered in review; work gets a wanted decision before the run, the cheapest gate in the system; the change is decomposed before any code exists into an ordered stack where each layer is independently green and revertible, which GitHub made native workflow when stacked pull requests entered public preview on 30 July 2026; generated output (lockfiles, generated types, snapshots, translation catalogues) is verified by a guard rather than read, so the diff a human opens is the part needing judgment; mechanical changes such as codemods and formatting passes are labelled and verified by re-running them; branches expire with the expiry recorded; and every closure carries one of five reason codes (capability, workflow, superseded, unwanted, abandoned) written at close time. We report the wasted-work rate with its reason split, driving the unknown bucket to zero first, beside the median reviewable diff once generated output is excluded. Limits: sizing does not make a change correct, deep stacks cost cascading rebases, none of it makes an agent better at a task, and the run data is an input to your standards, never to anybody's performance review. ### We rank fine on Google and ChatGPT never mentions us. Is that a content problem or a Frontend one? Very often a Frontend one, and a five-minute test says which: request one of your own pages with JavaScript disabled and read what comes back. If it is a shell with a script tag, everything you published (positioning, pricing, integrations, FAQ) does not exist for the systems answering questions about your category. The crawler population is not uniform. Googlebot and Applebot ship a full renderer and Google's AI surfaces run on the same infrastructure, which is why a client-rendered app can rank in classic search. The retrieval bots behind ChatGPT, Claude and Perplexity do not render: the Vercel and MERJ analysis of more than 500 million crawler fetches found they take the raw HTML and leave, sometimes downloading JavaScript files (about 11.5% of GPTBot requests, about 23.8% of ClaudeBot's) and never executing them, and vendor documentation through the first half of 2026 still describes the same behaviour for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Bytespider and CCBot. They do not click, do not scroll and do not wait for a fetch to resolve, so content in a tab panel that mounts on click, an infinite-scroll list, a price from a client SDK or JSON-LD injected by a script is missing for the same reason. Test the pages that answer buyer questions rather than the homepage, which is usually the one page somebody already server-rendered. The fix is a rendering decision rather than a plugin or a text file: server-render or statically render the public routes that answer questions, leave the logged-in application alone because nothing crawls it, render structured data on the server next to the copy it describes, make visually collapsed content present in the markup (native details and summary, with JavaScript adding only the animation), and treat a bot-only prerender as a bridge for a legacy app rather than a destination, because two renderings of one page drift and the one nobody looks at is the one the model quotes. The HTML a bot receives must be the page a human receives: serving bots a fuller document is cloaking. Limits: readable is not citable, so a page with no specific answer gains nothing from being rendered; readable is not operable, which needs declared tools over a capability layer; and none of it is a ranking guarantee in any engine. Free AgentReady scan: [enpitech.dev/agent-ready](https://enpitech.dev/agent-ready) ### If everyone in the org is running agents on our repo, what is the new attack surface? The context an agent ingests, which almost nobody classified as an input. On a normal task an agent reads the README, the contributing guide, the context and rules files, code comments, the ticket with whatever a customer pasted into it, the pull request thread, the package it just installed and any page it opened, and all of it lands in the same context as your instructions. AIShellJack, the harness behind the 2025 study of agentic coding editors, built 314 payloads covering 70 MITRE ATT&CK techniques and ran them against production editors across TypeScript, Python, C++ and JavaScript projects, with command execution succeeding in roughly 75% to 88% of attempts depending on the scenario. A Cloud Security Alliance research note of 17 March 2026 documented the cheap version: instructions hidden in the repository files an assistant reads to orient itself. The supply-chain version already ran at scale. On 26 August 2025 malicious Nx package versions shipped an install script that searched developer machines for credentials and then invoked the AI command line tools it found there, using their own permission-bypass flags, to help it find more, writing the results into public repositories created inside the victims' own accounts. Wiz's post-incident analysis counted 2,180 affected accounts and roughly 7,200 repositories across three phases, including 6,700 private repositories flipped to public and 2,349 distinct secrets exposed. A Frontend repository is the sharpest case rather than the mildest: it installs the largest third-party graph in the company, the install step is code, and its tracker is full of quoted customer text by design. The answer is privilege, not a better prompt and not an injection filter, which is the weakest control available. Instructions the agent obeys (context files, rules files, tool definitions) are code with owners and review, changed through a pull request and never approved by the run that proposed the change, while everything else the agent reads is quoted as untrusted material rather than concatenated as guidance. The run holds no ambient authority: it reads the repository, writes a branch and runs the tests, and it does not hold publishing tokens, cloud keys, production data or any credential that outlives it, which is exactly the machine the Nx malware would have found nothing on. Egress is an allowlist covering the registries, the model endpoint and the services the run genuinely needs; install lifecycle scripts are off by default; a new dependency is a reviewed change rather than a side effect of a build. The run records what it read, what it executed and what it reached, so the question of what this run touched has an answer. The run's identity is its own, short-lived and scoped to one repository and one branch, recorded beside the person who asked, so the audit answer names a person and a run. Credentials never reach a non-engineer's machine: preview environments, deploy hooks, CMS tokens, analytics write keys, flag keys and publishing tokens live in the pipeline, and a product manager gets a preview URL and a pull request. Destructive capability is not in the run at all: publishing, deploying, pushing to a protected branch, rotating a key and touching production data are pipeline operations a run requests and a policy or a person grants. Limits: none of this makes a model harder to persuade, it makes being persuaded worth nothing; least privilege that blocks the test suite gets routed around within a week; and the run records are an input to your standards, never to anybody's performance review. We build the boundary inside your CI, your identity provider and your cloud account. We are not a security vendor, we do not run your secrets manager, and we certify nothing. ### We shipped an MCP server last year. What does the 2026-07-28 specification change for us? More than a version bump and less than a rewrite, provided the capability layer was ever separate from the transport. MCP moved from a bidirectional stateful protocol to a stateless request and response one. The initialize handshake and the session header are gone, each request is self-describing and carries the protocol version, client identity and capabilities in its metadata, and a server can sit behind an ordinary round-robin load balancer with no shared storage. Server-initiated requests that needed an open stream are replaced by multi round-trip requests: a tool needing input mid-call returns a result type of input required with what it needs answered, and the client retries the original call with the answers attached. Streamable requests carry method and name headers, so a gateway, rate limiter or WAF routes and meters on a header instead of parsing a JSON body. List results became cacheable, carrying a time to live and a cache scope. Authorisation hardened: authorisation servers must return the RFC 9207 issuer parameter and clients must validate it, client credentials are bound to the issuer that minted them, and Dynamic Client Registration is formally deprecated in favour of client ID metadata documents while continuing to work. Roots, sampling and logging are deprecated, and so is the legacy HTTP and SSE transport, each with a year-long offramp under a new policy requiring at least twelve months between a deprecation and the earliest possible removal. Tasks moved out of the experimental core into an official extension with a polling lifecycle, so anyone who shipped against the experimental tasks API from the 2025-11-25 revision has a real migration rather than a rename, and the resource-not-found error code changed, which is the kind of detail a client discovers in production. MCP Apps, the extension carrying the interface an assistant renders, is now versioned independently of the core, so interface work is no longer tied to the transport's release cycle. The order that makes the next revision cheap rather than this one: pin and assert the revision so a date-based version string is a tested contract; keep the protocol's data model out of your database, because what a task, a record or a transaction means in your product is yours and no specification defines it; then migrate the transport, the authorisation and the deprecated capabilities one at a time behind contract tests. The same rule decides how expensive this is. Where tools call a capability layer that expresses what the product can do, this is an adapter change and so is the next revision; where tools were written directly against the transport, it is a rebuild of the part that was skipped. On architecture, the stateless core moves the question from how to keep a connection alive to where state belongs: conversation-scoped context rides on the request, work longer than a request becomes a durable record with an identifier your product already understands (which is what the tasks extension formalises), anything a retry could duplicate carries an idempotency key, and expensive listings are cached with a server-declared time to live. Limits: twelve months is a floor rather than a promise about any given host, hosts adopt revisions on their own schedule so you will support more than one for a while, and none of this makes a model choose your server, which is a separate problem with a separate fix. We build the capability layer, the adapters and the migration inside your product and your repository. We are not the protocol's maintainers, we do not speak for the specification, and ### Our Frontend is several repositories and our coding agents only ever see one. Is that why they stall? Usually, and it is the least examined reason. A design system or component package, a host application, two or three product surfaces and often a separate marketing site, each with its own repository, its own CI and its own release. An agent works inside one of them. It reads the compiled types of the package it consumes and cannot read that package's source, the intent behind a prop, the deprecation nobody wrote down, or the other consumers whose usage decides whether a change is safe. It has no way to know it cannot see them, so it does not ask, it assumes, and a plausible assumption survives review because the diff is small. The field data points the same way: across 20,574 real coding-agent sessions from 1,639 repositories, the recurring failure categories are about the project rather than about the code, wrong diagnosis of the project, misread intent, constraint violation and self-initiated overreach, and 91.49% of the visible resolutions still needed a person to correct the agent explicitly. The answer is not the one the tooling vendors sell. A monorepo is a repository topology rather than a delivery system, and the migration is a six to twelve month programme that changes CI, releases, ownership and permissions at once while the delivery problem stays where it was. We do not sell it and we do not require it. We make the boundary a contract the pipeline can check, in four parts. Context becomes a published artifact rather than a copy: the repository that owns a thing owns the context describing it and publishes it under a version, so four forked AGENTS.md files drifting apart become a diff in a pull request. A usage census, generated from the consumers' own import graphs and refreshed on a schedule, answers who imports this component, at which version, on which surface and with which props, and is served to the agent before it plans rather than discovered in review. The publishing repository proves the change against its consumers before the version exists, building the candidate, installing it into each consumer at that candidate and running that consumer's own component, accessibility and visual checks, which matters because the 2026 systematic review of breaking changes across Maven, npm, Python, web APIs and Linux distributions (97 primary studies) reports detection tooling as accurate on syntactic breaks and thin on behavioural ones, and names the failure of semantic versioning as a trust mechanism as an open problem. Nearly every break that matters in a design system is behavioural: the prop still typechecks and the focus order moved, the token resolves differently, the layout reflows at one breakpoint. A version number is not a compatibility claim. And the change lands as an ordered stack with a deprecation path, add, migrate by codemod, then remove, rather than a rename landing everywhere on one day. Reported: upgrade lag per surface (median days from publish to adoption) and how many versions of the shared package are live at once, driven toward one. Both are properties of the pipeline and never an input to anybody's performance review. Limits: none of it makes an agent better at a task, it gives it the half of the problem it could not see; it does not merge your repositories; a census cannot see a component behind a dynamic import or selected at runtime by a flag, which is a signal to collapse the boundary rather than document it; and consumers with no meaningful test suites have nothing to verify a candidate with, which we say during the audit rather than after. We build it inside your repositories, your CI and your package registry. We do not re-architect your Frontend, we do not own your design system, and we do not sell a monorepo migration. ### We want to add voice to our product. Is that a model decision or a Frontend project? Almost entirely a Frontend project, and the bar is human rather than technical. Stivers and colleagues recorded question and answer sequences across ten languages, from Japanese and Korean to Italian, Danish and Yeli-Dnye, and published in PNAS in 2009 that every language produces the same shape: the transition from one speaker to the next is unimodal, with the peak inside the first 200 milliseconds after the question ends. Users bring that reference into your product without deciding to, which is why a correct answer at a second and a half reads as broken while the same answer at four hundred milliseconds reads as a conversation. No model choice fixes it, because most of the wall clock and all of the perceived delay sit in the parts the Frontend owns: capture, endpointing, transport and playback. Four things are the work. Endpointing, deciding that the user has stopped talking, is a product decision rather than a setting and is tuned per surface, because a dictated form field is not a support conversation and a threshold that feels right in English is wrong in Hebrew. Barge-in is the line between a conversation and a phone menu and needs three things in lockstep: voice activity detection on the capture stream, echo cancellation so the assistant's own output does not return through the microphone and trigger it, and cancellation of in-flight audio and of the generation behind it on the first syllable, followed by the reconciliation step most teams skip, working out what the user actually heard rather than what the model believes it said. The browser is its own constraint set: playback needs a user gesture, the microphone permission is a single prompt you get one chance at, echo cancellation and noise suppression are capture constraints you have to request, devices change mid-call, a backgrounded tab is throttled, and a connection that drops mid-turn has to resume into something rather than into silence. And the transcript is not the product: a voice turn that calls a tool renders the result in the interface, because spoken output cannot be checked, copied, linked or re-read and a number read aloud is a number nobody can verify. What breaks with real users is the demo conditions, and each maps to a defect: turns cut off by endpointing tuned on fluent demo speech, barge-in firing on the assistant's own audio, transcript drift across a long session, tool calls grounded in a mis-heard product name or order number, and the expensive one, an agent reporting that it did something when the call behind it failed. The fixes are unglamorous: a domain vocabulary supplied to the recogniser as a biasing list built from your own catalogue and names; confirmation before consequence, rendered rather than spoken, for anything that spends money, sends a message or changes state; spoken confirmations generated from the tool result and after it, so done means the call returned; session state that survives the connection, with context on the server, a durable transcript and a reconnect that resumes rather than restarts; measurement at the turn rather than the call (time to first audio, interruption rate, the share of turns the user had to repeat, the share of tool calls grounded in a corrected transcript, where people give up); and an evaluation set built from your own recorded audio with the accents, noise, devices and code-switching your users actually have. Limits: voice is a second modality and not an accessibility feature, so the text path stays first-class and voice degrades into it; none of this repairs a recogniser that cannot hear your users, which is a provider decision you re-make when the provider ships a new model; a voice interface does not make a poor flow good, it makes it faster to reach; and we publish no latency or accuracy figures, because the only honest budget is measured on your own path, on your users' network, with your own tool calls in it. We build it inside your product, on your provider and your infrastructure. We are not a contact-centre vendor: no telephony, no IVR, no outbound calling. We run one of these on this site. ### Our Frontend codebase keeps growing and nothing is ever removed. Is that costing us anything? More than it costs a backend, because unused Frontend code is not inert. Unused backend code sits on a disk; unused Frontend code is downloaded, parsed and executed on a real person's device. Muzeel, published at the ACM Internet Measurement Conference from a crawl of around 40,000 pages, found that 70% of the JavaScript functions on the median page are never called, and that removing them cuts page weight by roughly 60% and page load by about 30% on a low-end phone over a slow network. That measurement predates coding agents entirely, which is the point: the Frontend was already carrying this and generation changed only the inflow. Writing a component became nearly free; removing one stayed exactly as expensive, so a gap that widened slowly now widens at the speed of your agent fleet. Four costs, and teams argue about the first while the other three do the damage. It ships, on somebody's battery and somebody's data. It sits in the dependency graph, so the package only the abandoned screen imports still blocks the upgrade, still appears in the advisory and still needs the migration written. It sits in the context your agents retrieve from, so a model finds the dead component, reads it as a sanctioned pattern because it is in your repository, and reproduces it: dead code propagates rather than merely accumulating. And it holds live capability, the third-party script still loading, the analytics key still valid, the unlinked route that still answers and still reads from your database. So removal becomes an assertion rather than an aspiration. Deletion is part of done on the change that replaced the thing, in the same pull request, while the person writing it still knows what it replaced. Unused files, exports and dependencies are checked on the paths a change touches, so the count ratchets down and a change is never allowed to raise it. Reported: bytes shipped per route and unused-export count as a trend. This is the stated other half of the reuse guard, which stops a second copy being created and says plainly that it does not remove what is already there. Limits: static analysis cannot see a component reached through a dynamic import, selected at runtime by a flag, or referenced by a path built from a string, so it produces a proposal and never a delete list; it pays down where you are already working rather than uniformly; and a deletion is a change like any other, through the same guards. We build it inside your repository and your CI. We do not sell a cleanup sprint and we are not a code-quality analytics vendor. ### Nobody will approve a deletion because nobody can prove the thing is unused. How do you get past that? By replacing the argument with evidence and by staging the removal so no single step is the frightening one. The proof is genuinely hard here rather than the reviewer being timid: on a Frontend, usage lives in the browser and not in the repository, so grep says nothing about a component reached through a dynamic import, a route linked from a marketing site another team deploys, a variant selected at runtime by a flag, a deep link pasted into a support macro, or a query parameter one enterprise customer has bookmarked. So you measure first. The surface reports that it rendered and the export reports that it was called, stamped with release and commit, sampled, with no personal data in it, and you wait one real cycle. Then the removal is staged: deprecate in code with a named owner and a date, warn in development, dark-launch the removal for a slice of traffic and watch your existing error and support signals, then delete. Feature flags get the same treatment one level up and need it most, because flag debt is not created by teams adding flags, it is created by nobody owning the removal once the flag's job is done: a flag declares its expiry when it is created, a flag parked at 100% past its declared life fails the build rather than generating a ticket nobody picks up, and the long-lived kinds, kill switches and permission gates, are declared long-lived on purpose. The removal pull request then carries its own evidence, what was measured, over what window, in what share of sessions, what the dark launch showed and exactly what reverses it, so a reviewer is approving a measurement rather than a belief. Limits: a cycle is a business cycle, so a surface used at quarter end needs a quarter and nobody clears this in a sprint; low traffic is not unused, and the single remaining customer is the one who will notice, so the threshold is a product decision your owner makes rather than a number we supply; the instrumentation is itself code that has to be removed afterwards; and none of it applies to anything a contract or a regulator requires you to keep, which is a list we ask for at the start. We build it in your pipeline with the telemetry and flag system you already run. We do not run your analytics product and we never delete anything on our own authority. ### A customer asked whether our product speaks A2A. What is it, and how much of it is ours? Less than the question implies, and the part that is yours gets skipped. The distinction first, because most of the confusion is definitional: MCP is vertical, an agent reaching down to a tool or your product, and A2A is horizontal, one agent handing a unit of work to another agent it does not own. They are not alternatives and you will likely speak both. Status, dated because it rots and because we verify it rather than recall it: A2A came out of Google in April 2025, became a Linux Foundation project that June, and now sits beside MCP under the Agentic AI Foundation, formed 9 December 2025. Version 1.0 landed on 12 March 2026 as the first stable release and added cryptographically signed Agent Cards, so a receiving agent can verify a card was issued by the domain claiming it. At the one-year mark on 9 April 2026 the project reported more than 150 supporting organisations and deployments inside the major cloud agent platforms. Mechanically: you publish an Agent Card at a well-known URL on your own origin declaring skills, transports and security schemes; work is a task with an explicit lifecycle including states for work waiting on a person; transport is JSON-RPC over HTTP with gRPC and plain HTTP bindings alongside it, streaming for progress and webhooks for work that outlives a connection. The honest answer for most companies asking is that you do not have an agent for anyone to delegate to. If the capability layer is not built, A2A is premature and your customer should get a date rather than a card, because a signed machine-readable promise about skills you have not shipped is worse than saying nothing. Where the layer exists, A2A is one more caller onto behaviour you already have, the same argument we make about the MCP revision and WebMCP and repeat deliberately: the capability layer survives the protocol, the adapter absorbs it, and a third implementation is a third source of truth. What is genuinely Frontend is small and skipped: the Agent Card is a published artifact served from your web origin, so it goes stale exactly like a sitemap and is generated rather than hand-edited; a task waiting on input or authorisation is a person's problem arriving with no person attached, so it needs a real surface; and what a remote agent did in your product has to be readable and reversible by a human who was not there. The limit is the sentence to carry into the meeting: the 2026 governance analysis of agent interoperability protocols states that an agent exists purely by publishing an Agent Card, that there is no protocol-native notion of membership, admission or removal, and that the protocol is agnostic to liability with no native mechanism for reputation or trust. Interoperability is not trust. Who may act on whose behalf, for how much, and who carries the loss stays in your contracts and your own authorisation. We build the capability layer, the card generation and the adapters inside your repository. We are not the protocol's maintainers, we do not speak for the specification, we do not host your agent, and we will tell you when the answer is not yet. ### Another company's agent started a task in our product with no user present. What do we still owe that user? Everything you owed them while they were watching, delivered afterwards instead of during, and this is the half no protocol does for you. Four things. An authority the user actually granted, captured before the work and narrower than their own: their permissions are a ceiling and never a floor, the grant names what the agent may do and for how long, and it is revocable from a surface they can find without emailing support. A pause that is a real surface, because a lifecycle with states for needing input or authorisation means your product will hold work waiting on a human: that is an inbox rather than a modal, addressable by URL so it reaches the person who can decide, resumable after a reload, surviving the originating agent disconnecting. Teams discover this late because in a demo one person watches one task and the waiting state never renders. A receipt written for a human rather than a machine: what was requested, by which agent, under whose grant, what changed, when and what reverses it, with the real parameters rendered rather than summarised, in the same activity record support already reads back. And a refusal that is legitimate: irreversible or consequential actions do not complete with nobody present, they queue for the person, and deciding a whole class of work is never delegable is a normal product answer. The mechanics underneath: the delegated call runs the same typed function your button runs, so validation, permission, telemetry and audit are inherited rather than reimplemented on a path that will drift; every call carries an idempotency key, because a retry from an agent you do not control is ordinary rather than exceptional; and a contract test runs the same case through both callers and fails when they disagree. Keep it apart from its neighbours: whether you serve automated callers is access policy, who is calling is verified identity, whether a caller can finish a flow built for people is operability, what a transaction looks like with an agent in it is commerce, and this is what you owe the person whose work happened while they were away. Limits: none of it makes the remote agent behave, it makes what it did legible and reversible; a receipt nobody reads is not consent, so the grant is captured before the work rather than implied by it; and where money, personal data or a regulated decision is involved the binding rules are your counsel's and your data protection officer's rather than ours. We build it inside your product on your infrastructure. We do not operate your agent, we are not auditors and we certify nothing. ### Our pilot team is flying and nothing has spread to the other teams. What went wrong? Probably nothing in the pilot. What failed is the assumption that its result was portable, and three measured things say why. It accrued rather than arrived: the 2026 longitudinal study of a documented enterprise 2x mandate, 802 developers and 196,212 pull requests between January 2024 and April 2026, found the within-developer gain reaching about one and a half times at observed usage and two times only after around nine months on the tool, in conditions the authors describe as close to best case. So you are showing team two your pilot team at month nine. There is a dip in between and it has a shape: DORA published the ROI of AI-assisted Software Development on 22 April 2026, off nearly 5,000 respondents and more than a hundred hours of interviews, and names three causes for it, the learning curve, the verification tax (the time developers spend reviewing AI output), and pipeline adaptation. DORA calls the dip the tuition cost of the transformation, and a team expecting a step reads its own dip as proof the thing does not work here. And the pilot ran where agents are strongest: Stanford's software engineering productivity programme, across millions of commits from more than a hundred thousand engineers, reports the gains largest on low-complexity greenfield work and close to nothing on high-complexity work inside existing code. The pilot repository was chosen because it was tractable. So what travels is artifacts rather than habits: context committed to the repository, guards in CI, the review agent, the eval suite, the metering, the golden path written as something an agent can execute. A habit travels only by moving a person, and a success story travels as a slide. What has to be re-derived per team is what mergeable means for their surface, their component inventory, their test baseline and their owners, which is days once the harness exists and is the part everybody budgets as zero. Two rules: team two is picked for a different failure shape rather than for being the most similar, and every team is measured against its own baseline rather than against team one. A mandate is not a substitute, because raising output volume into an unchanged review process is exactly what deepens the dip. ### Who has to own this inside our company for it to survive after your engineers leave? One named person with real time on it, named in the first week of the pilot rather than introduced at handover, because ownership of a delivery system is a skill acquired by operating it. They own the guards and their thresholds, the context and skills committed to the repository, the eval suite, a budget line for model spend and CI minutes, and the authority to decide when a guard is wrong. That last one is the job: a guard that blocks something legitimate with nobody empowered to change it gets routed around within a week, and a routed-around guard is worse than no guard because the organisation now believes a line is protected that is not. Without that person the decay is undramatic. The artifacts go stale the way documentation goes stale, except that staleness is worse than absence here, since agents read these files and act on them confidently. So handover is a test rather than a date: your people onboard a later team while we watch rather than drive, and if every team needs us then what we sold is a dependency and we will say so. We leave the configs, the guard set with the reasoning behind each rule, the eval suite with the cases that justified it, a runbook for a guard blocking something it should not, and the record of what was traded away. We ask for a fraction of a real role rather than a project, and a second person who can read the guard set. We will not be the owner. An operation retainer after handover is a choice rather than the shape of the deal. ### Our in-product search is bad and everyone wants to put AI into it. Is that the fix? Half of it. The baseline predates any model: Baymard's on-site search benchmark, across more than 170 benchmarked sites and apps, rates search mediocre or worse on 46% of desktop, 58% of mobile and 64% of app implementations, and none of that is retrieval. On retrieval there is one expensive mistake, replacing keyword search with embeddings instead of adding them. Embeddings own paraphrase, synonymy and intent. An inverted index owns exact and rare tokens, and those are exactly the strings users paste in verbatim: SKUs, order references, error codes, version strings, surnames. A 2026 benchmark over financial documents mixing prose and tables found classical lexical retrieval beating state-of-the-art dense retrieval outright on that corpus. So it is both, fused into one ranking, usually with a reranking pass. The rest is interface. Show what was done with the query and let each applied filter be undone in one click. Treat zero results as a designed state that relaxes a constraint and says which one, rather than a dead end. Put a generated answer above the ranked list rather than in place of it, with grounds attached to the individual claim rather than the paragraph, because a user who cannot trace one sentence back to a source in about two seconds discounts the whole answer. Render the list from retrieval immediately while the answer streams above it, and degrade to the list when the model is slow, because search is typed and a search box that waits on a model is a slower search box. Measure zero-result rate by query class, refinement rate, click against abandonment, clicked position, and the frequent queries that never convert. One architectural decision saves a rebuild: the same retrieval service answers the search box, the in-product assistant and any tool exposed to external agents. Limits: no interface repairs a corpus that does not contain the answer, much of search quality is editorial rather than technical, and we do not resell a search vendor, a vector database or an embedding pipeline. ### Our AI search sometimes surfaces things a user should not see. Where does that come from? From the index, which is a second copy of your data carrying a second access-control system that nobody reviewed. Three mechanics produce most of it. Enforcing permissions at index time, which bakes a decision that a later permission change in the source system never reaches, so permissions are evaluated at query time against the caller's identity and the index holds a reference rather than a verdict. Filtering after ranking rather than before, because a result count that differs between viewers and a visible gap in an ordering are themselves disclosures, and a model handed a document it should not have seen has already folded it into the summary, so removing the citation deletes the evidence rather than the exposure. And the derived copies teams forget: the vector, the cache, the prompt log, the eval set built from production traffic. Then the half that is Frontend: the answer is rendered, and the rendering is an exfiltration channel. On 15 June 2026 Varonis published SearchLeak against Microsoft 365 Copilot's enterprise search, chaining an instruction planted in a URL parameter, an image tag that fired before output sanitisation finished, and an outbound request routed through the vendor's own infrastructure so the page's content security policy never applied. The victim saw a thinking indicator. That is an injected instruction, a render race and an outbound request, and two of the three are Frontend. So: retrieved content is untrusted input rendered as data rather than markup, with sanitisation completed before paint; generated output does not fetch remote images or resources from arbitrary origins; content security policy is asserted by a test rather than described in a wiki; citation links resolve through your own endpoint, which re-checks the caller may open the target; and when permissions reduce a result set to nothing the surface says nothing was found, never that there are results this person may not see, because the existence and the count are the disclosure. Limit: an index over a source whose permissions are already wrong reproduces them faithfully and at speed, which surfaces an access-control problem you already had and belongs to the owner of that source system. We are not auditors, we do not run your identity provider and we do not sell a scanner. ### Our test data is three rows of Test User and staging looks nothing like production. What does that cost us? The guards, because every gate ends in a render and each one is worth exactly what the data behind it is worth. Three short Latin-script names with every optional field populated is a list of defects the pipeline cannot see: the long company name that wraps the nav, the account with 900 rows against a table nobody virtualised, the missing avatar, the Hebrew string that inverts the layout, the empty state that has never rendered in CI because every seeded row has data. An agent verifying its own change renders whatever the fixture holds, screenshots it and reports success, so unrealistic data does not make guards fail, it makes them pass. Both obvious routes are blocked: K2view's 2026 State of Enterprise Data Compliance survey found 87% of enterprises copy sensitive data into non-production environments, 76% had a sensitive-data incident in one within three years and 4% call dev and test fully compliant, while Perforce Delphix's 2026 test data research has 99% waiting more than a business day for a fresh full production copy, 42% waiting weeks or months, and 51% not using synthetic data at all, with 38% satisfied by the realism on offer and 34% by the referential integrity. So neither. A screen does not need your data, it needs your shapes: extremes of length, cardinality and locale, the states every surface owes a user, and your real account archetypes, derived from production distributions rather than production rows, then committed, versioned and owned so the Storybook states, the fixtures an agent verifies against, the visual baselines, the end-to-end seed and the local environment a PM gets on day one are one set. The set grows one way: every defect that reached production becomes a fixture in the change that fixes it. Inventory before enforcement, then ratchet onto changed surfaces. We are not a test data management or data masking vendor and we do not sell a synthetic data platform. ### If we copy production data down so the screens look real, what is the exposure? Wider than the database conversation covers, because on the Frontend the copy becomes renders and renders are kept. A Playwright trace and video in a CI artifact under a retention policy nobody chose. A visual diff baseline committed to the repository, which puts it in the history permanently. A Storybook story with a real customer in it. A preview environment with a real dataset and no authentication in front of it. An error report carrying a serialised store, a session replay, and a screenshot pasted into a pull request that the next agent reads as context. Masking at the database reaches none of those, because all of them are downstream of the render. So the boundary is drawn at the render: fixtures generated from measured shapes, visual baselines rendered from those fixtures with a check that fails when one was captured against a live environment, traces and videos given an expiry and kept out of git, preview environments authenticated and short-lived, redaction in session replay and error reporting asserted by a test rather than configured in a vendor setting, and a screenshot with customer data in it treated as unacceptable agent context, so the pull request template asks for the fixture case instead. Some investigations need the real record; those happen in one named place with access logged and a lifetime on it. What is permissible is your data protection officer's decision and your counsel's, and we build to what they tell us. ### Our extraction vendor quotes 99% accuracy and users say it is wrong constantly. Who is right? Both, and the distance is arithmetic. The vendor quotes per field, your users experience per document, and 0.99 to the power of 55 is about 0.57 on a 55-field form, which is the optimistic version because errors cluster on the layouts the model finds hard. "Beyond Logprobs", a 2026 study of confidence in LLM document field extraction, reports that on DocILE, a 55-field invoice benchmark, frontier models fail on 26% of fields, and that the confidence scores everyone routes on cannot separate right from wrong: mean token log-probability reaches only 0.705 ROC AUC and collapses toward an all-positive classifier at practical thresholds, with the model's own verbalised confidence at 0.692. That is structural, because extraction errors come from what the model cannot observe: an unreadable scan, an ambiguous layout, a column header belonging to the column beside it, OCR noise resolved into a plausible number. The metric that changed in 2026 is grounding. ExtractBench, built over 4,869 pages across 370 enterprise documents, 8 business domains and 67 document types with a top ten of 39 systems and prices as of 11 September 2026, scores value accuracy, record completeness, grounding and measured cost together, reporting grounding as word-level and page-level F1: a field counts when the value is right and it points at the place in the source it came from. That is a rendering requirement rather than a model one. Nobody can quote a straight-through rate before seeing your documents, ourselves included. We are not an OCR or document-processing vendor and we do not sell an extraction model. ### Our reviewers still open every extracted document. How do we get the human out of the loop? You do not, and aiming at that is why the number is stuck. Aim at the cost of one verification, which is a Frontend quantity: seconds per field, times the fields that genuinely need checking, times documents per day. Not all 55 fields carry the decision, so marking the decision-carrying ones and ordering them first turns a four-minute pass into a twenty-second one, and that is a schema annotation rather than a project. Seconds per field is grounding rendered rather than claimed: the value beside the pixels it came from, the page scrolled to it, the region highlighted, confirmation on the keyboard rather than a mouse round trip into a modal. The unit of acceptance is the document rather than the field, because a per-field flow leaves nobody responsible for the one that was silently missing. A dropped field, an invented field and a field read from the wrong column are three states rather than one amber badge, and record completeness gets its own treatment because a missing row is the hardest error here to notice, which is why ExtractBench scores it separately. Never present a single confidence number as accuracy, and where a threshold routes work, say what it was calibrated against and on which document types. Then capture corrections as structured data (field, document type, layout, before, after, who, when), which is your eval set, your error taxonomy and the only instrument that tells you whether the next model version helped you rather than helped a benchmark. ### Our coding agents keep writing code for a version of our framework we do not run. What fixes that? Not an instruction in a context file, because what you are fighting is a prior rather than a misunderstanding. A model’s default for your framework is the version written about the most, not the one in your lockfile, and the popular past is enormous: class components, pre-hooks idioms, the data-fetching API that got superseded, the router you migrated off, the bundler you deleted. “When LLMs Lag Behind”, an April 2026 benchmark of code generation under API evolution across 270 real-world library updates and eleven models in four families, found only 42.55% of generated examples executable in the target environment without comprehensive documentation, and 66.36% with structured documentation and a larger model, so doing the documentation properly still leaves about a third not running. That benchmark is Python-library based, and a Frontend is worse rather than better: the deprecation surface is a stack of majors moving independently and your repository sits at a different point on each. So the answer is an artifact. What the repository runs is generated from the lockfile and the configs instead of typed by hand, because a hand-written version note is stale within a week and a stale one is worse than none, since an agent reads it and acts on it with complete confidence. The APIs you are not on yet become a restricted-import rule that fails the build rather than a review comment. Types catch renamed exports and changed signatures for free; the expensive failures are behavioural, a default that flipped or an effect that now runs twice, and those compile and pass review, which is what the guards are for. And the gap is not neutral: every major you are behind makes every agent on your repository worse every day. We build and operate this in your repository and your CI. We do not sell a dependency-management product and we are not reselling anybody’s upgrade tool. ### We are two majors behind on our Frontend stack and the upgrade never survives a prioritisation meeting. Can coding agents just do it? They can do the mechanical share, and the reason the upgrade keeps losing is not difficulty. It ends with nothing a customer can see, so it loses to features forever until somebody prices the gap instead of the work: every agent on the repository is generating for a version you do not have, every new hire’s habits point at the current major, the security patch you need exists only above your line, and part of the ecosystem has already dropped support for where you are. The mechanical share is real agent work and larger here than in a framework migration, because the codemods usually exist: renamed exports, moved imports, changed signatures, a config format, a lint preset. The ambiguous share is the behaviour nobody wrote down, the 2019 workaround for a bug since fixed, the component whose four callers each depend on a different accident of it, the effect that was only correct because of the old render timing. Pretending that share is agent work is how these stall at four fifths done, so the audit sizes both shares first. One major at a time, never two in one change. Slices route by route where the framework allows, each separately mergeable and revertable, so there is no point of no return. The codemod proposes and the guard decides: parity is a test written before the slice, and on a Frontend the seven guards are the parity definition, so a screen that renders identical pixels but loses a keyboard path, doubles its bundle or regresses INP has not been upgraded. An upgrade agent’s characteristic failure is loosening a selector or regenerating a baseline until the suite agrees, so a snapshot is never accepted in the run that changed what it snapshots. Decide one thing early: if you intend to leave that framework within eighteen months, upgrading to its current release is the wrong purchase and we will say so. We do not sell rewrites, we are not reselling a vendor’s migration product, and nobody can put a date on this before seeing the repository and the test baseline. ### We want our product to adapt to each user. How much of personalization is actually a Frontend project? Most of it, and the first decision is a caching decision rather than a model one. The moment the markup depends on who is asking, the cache key changes and a route one render served to everybody becomes a render per audience, or per person, which is a hosting bill and a latency profile nobody costed. So the shape that survives is a cacheable shell with a small number of named personalized slots inside it, each declaring what it needs, what it renders with nothing, and how much space it holds before it has anything. The cheap version is the one that hurts: serve the cached default, let a client script decide, swap the content in. That is a layout shift by construction, and the anti-flicker snippet sold as the remedy hides the page until a third party answers, trading a visible shift for a blank screen. The HTTP Archive’s Web Almanac found in 2025 that 81% of mobile pages achieve good CLS, against 77% for INP and 62% for LCP, with 48% passing all three, so failing CLS deliberately on your highest-intent surfaces to change a hero image is a bad trade nobody makes explicitly. Decide on the server or at the edge from what you already have at request time where you can, so personalization arrives in the first byte; where you cannot, the slot reserves its space and streams. Then the planning error, which is more expensive: the cold start is the majority of your traffic rather than an edge case, because of first-time visitors, logged-out sessions, cleared browsers, private windows and declined consent prompts. The default is the product rather than the fallback. Consent belongs in the render path as an input rather than on top of it as a banner. We build the rendering layer, the slot contracts, the consent-aware render path, the controls and the measurement on whichever engine, CDP or flag platform you run. We are not a CDP, we do not buy, broker or enrich audience data, and we will not quote a conversion lift before seeing your traffic. ### We shipped personalization and cannot prove it works, and every bug report about it is unreproducible. What did we skip? The two things nobody budgets, and they are one thing from two ends: you cannot say what the system did for one person, so you cannot say what it did for all of them either. Measurement first. The unit under test is the policy rather than the layout, and ordinary variant testing cannot answer it because there is no shared variant to compare. What answers it is a holdout, a fixed share of traffic that is never personalized, held permanently rather than for a quarter. Two rules keep it honest: the holdout gets the best default you can build rather than a stripped one, and the metric is the downstream business one rather than engagement with the personalized slot, which will always look excellent because you put the most clickable thing in the most prominent place. Then reproducibility. A personalized product is a different product per person, so your team loses the shared reference it debugs against: nobody can reproduce the screenshot and the reporter cannot tell you what they saw. The deliverable is the ability to reconstruct a render, which means the inputs to each slot decision recorded with the response, keyed to a session reference a user can read out, with a retention window and no more personal data than the decision used. On top of that, two interfaces: a plain ‘why am I seeing this’ for the user that names the reason and offers the way out, and a permissioned, audited view-as for your team that reconstructs the state from the recorded inputs rather than guessing. On the regulatory question, less applies than the headlines suggest. California’s finalised CCPA package took effect on 1 January 2026 and its automated decision-making rules bite on significant decisions, a narrow defined list covering financial and lending services, housing, education, employment and healthcare, required by 1 January 2027, with advertising left out of the final text, so a recommendation shelf is usually not in scope. What is universal is the boring half that good design asks for anyway: a person can find out why they are seeing something and can turn it off. Your counsel and your data protection officer decide what applies and we build to what they tell us. A holdout costs you the upside on that slice, which is the price of knowing. We are not a CDP, we are not auditors, and we do not sell a lift figure. ### Our AI-written screens look right in our default theme and break in dark mode and in half our customer brands. Why does nothing catch that? Because every check you own runs in one cell of a matrix, and always the same cell: default theme, default brand, light mode, the reviewer's laptop, whatever their OS was set to that morning. A component that renders in fourteen combinations is verified in one, and the agent that wrote it verified the same one. The scale shows up in the most automatable check in accessibility: WebAIM's 2026 Million report found low contrast text below WCAG 2 AA on 83.9% of the top million home pages, up from 79.1%, with 34 distinct instances on an average page and 56.1 detected errors per page. Contrast is arithmetic and it is still the most common failure on the web, because it is computed in one theme. Agents sharpen it: a model writes a literal value exactly where the token set runs out, and the literal is correct in the theme it was checked in by construction. A hover shade that vanishes on dark, a shadow doing the work of a border, a disabled state built from opacity, a focus ring left to the browser default because it had enough contrast on white. The answer starts with subtraction: declare which themes, brands, modes and densities you actually sell, which is a shorter list than the team fears. Then the theme becomes a contract rather than a convention, so no literal colour, shadow, radius or physical direction survives the diff, ratcheted onto changed lines. Contrast is asserted per theme from the token pairs themselves, including the states a page scanner never opens: focus rings, disabled controls, placeholders, errors, overlays, elevation surfaces. Coverage is by rotation rather than exhaustion, since the matrix multiplies and the CI bill does not: changed surfaces render in every declared variant, the whole app renders in one non-default cell per run. Brand stays data, never a fork. Not an eighth guard: it rides inside the design system and accessibility guards for teams shipping more than one theme or brand. We do not design your brands or your dark theme, we are not a branding agency, we are not an accessibility auditor, and we do not sell a visual testing product. ### Can we not just add every theme, brand and viewport to our visual regression suite? Multiply the axes honestly and the suite collapses. Four brands, two modes, three viewports and two directions is forty-eight full renders of every surface on every commit, in a pipeline that is already the constraint once agents open pull requests in parallel. The compute is the smaller cost: every baseline is a file somebody accepts, and forty-eight times the baselines is how a suite reaches the state where the fastest path through review is to regenerate all of it, which deletes the rule that a baseline is never accepted in the same run that changed the thing it depicts. Exhaustive visual coverage also buys the wrong failure. A pixel diff says something moved, not which contract broke, and in a multi-brand product everything moves in every brand for legitimate reasons, so teams filter, and what gets filtered is the class of change the suite existed to catch. The order that works, each step removing work from the next: make the contract unrepresentable to break, so literal colours and physical direction fail the build in changed code. Assert the computable properties per theme from the tokens, every declared contrast pair plus the presence and aspect ratio of per-brand assets, a real defect class nobody automates. Render narrowly: the surfaces the change touched, in every declared variant. Rotate one non-default cell per run across the whole app. Feed the renders from the committed fixture set rather than live data, because a variant render is worth what the content behind it is worth. If you already own a visual testing product we drive it rather than replace it. The most common outcome of the first pass is that your matrix is smaller than you thought. ### Our AI feature tests well in English and our Hebrew, Arabic and Spanish users say it is bad. Is that the model or our build? Both, and only one half is behind an API you do not control. The model half is measured: MMLU-ProX holds the exam constant, the same 11,829 questions in 29 languages, and reports gaps up to 24.3 percentage points between high-resource and low-resource languages. That is a knowledge benchmark rather than your product. What your users experience is mostly three configuration decisions and one missing instrument, all yours. The output cap first, which nobody treats as a quality setting: published tokenizer comparisons put the same content at roughly 1.5 to 3.3 times the tokens depending on language and script, Hebrew and Arabic near the expensive end, so one max-tokens value is generous in English and tight elsewhere, and tight budgets truncate and compress rather than fail loudly. A 2026 output-budget study found the measured multilingual reasoning gap moving by as much as 57 points purely as a function of the cap, with the announced budget alone moving native Thai accuracy by 5.1 points. Second, everything around the model is English, the system prompt, the retrieved context, the examples, the tool descriptions, which pulls answers into English or into translationese, so the reply language belongs pinned to the user explicitly and held across turns. Third, cost and latency are the same token tax from the other end, and usage limits denominated in tokens charge an Arabic or Hebrew speaker two to three times for identical work, so quote limits in messages or documents instead. Then the missing instrument: your evaluation is in English too. An aggregate score hides a per-language collapse by design, multilingual LLM-as-judge work from 2025 and 2026 finds judges disagreeing with themselves between languages and holding their own training priors over a supplied definition, and translating non-English answers back to English to score them makes the measurement worse. So we build a fixed evaluation set per language from real user turns in that language, read by people who speak it for the languages that carry revenue, with refusal and safety behaviour checked per language too. We build the interface, the language routing, the budgets and the evaluation harness on whichever model you chose. We do not train models, we are not a translation vendor, and nobody can promise a quality figure in a language before testing your own tasks in it. ### Our model gives a good answer in Hebrew or Arabic and it renders as a mess on screen. Whose problem is that? The Frontend's, entirely, and it is a different problem from answer quality, which is why it survives a quality push untouched. What arrives is not a string, it is a document assembled one token at a time, with headings, lists, tables, links and code, and mixed-direction runs inside nearly every sentence, because product names, identifiers, URLs, numbers and code are Latin script inside a right-to-left paragraph. That is the hardest text-rendering case on the web, delivered incrementally, and most products ship it with the defaults. The failures repeat: direction set once on the page instead of per block, no isolation around inline runs so sentence-final punctuation jumps sides and a version number reorders, tables that mirror columns while the header does not, code blocks inverted when they must stay left-to-right inside a right-to-left message, physical CSS so the avatar, timestamp and copy button stay on the wrong side while the text moves. And the streaming one: direction is decided by a block's first strong character, which arrives at an unpredictable moment, so a naive implementation flips the paragraph mid-render, something a finished screenshot never shows. This is unowned rather than hard, and the evidence is public: through 2026 the issue trackers of the largest AI products carry exactly these reports, bidirectional regressions when Arabic mixes with English, numbers and markdown tables, markdown chat content rendering left-to-right regardless of locale, editors with no bidirectional support at all. Those are companies with very large Frontend teams. The build is ordinary once somebody owns it, and it gets a gate: a rendered screenshot per declared language rather than a string assertion, since every one of these defects passes a string comparison perfectly, covering the streaming states too, the first chunk, a half-written table, an interrupted answer. Teams running the factory already take those renders for the pseudo-locale and RTL passes, so extending the same pass onto the AI surface costs very little. Right-to-left is not a subject we researched, it is what our own work ships in, this site and the assistant on it included. ### An agent wrote our last product email and it went out broken to every customer. Why does nothing catch that? Because the email is the one Frontend artifact in your product with no pipeline attached to it, and the only one whose deploy cannot be undone. Components live in a repository with a design system, a type checker, guards and review. Templates live in an ESP editor, in a string inside a backend service, or in a folder copied from the last company, often all three, with no author, no history and no diff. Then the stakes invert: a broken route reaches the people who visit it and you fix it in twenty minutes, while a send reaches every customer at once, cannot be rolled back, and is preserved in their inbox. Agents make it worse specifically rather than generally: a coding agent writes email markup with the idioms of web markup, and a flex row, a grid, a stylesheet, a web font and a border-radius are all correct for a browser while several do nothing in an inbox, and it cannot learn which because nobody renders the email. The client set makes it a matrix: Litmus's July 2026 report, from over a billion opens, puts Apple's clients near 64.7% and Gmail near 24.1%, so roughly 90% of opens land with two vendors that mostly work, and what breaks is the long tail plus the fork inside Outlook, where a Chromium-based engine became the Microsoft 365 business default during 2026 while the classic Word-engine build stays supported well beyond it. Dark mode is not a matter of degree either: some clients honour prefers-color-scheme, some force a full inversion with no opt-out. So the template becomes code in your repository, the email subset becomes a contract the build enforces, the gate renders across a declared client set with images blocked, both dark behaviours and an empty variable in every field, and the last gate sits at the send rather than in CI, because the recipient list is a deploy target. We do not send your email, we are not an ESP, and deliverability is a different trade from rendering. ### Can we not just send ourselves a test email before each send, or buy a preview tool? Do both, and do not mistake either for a gate. The test send is one person, at the end, under a deadline, in one client, in one colour mode, with images cached and their own name in every merge field, checking against a memory of what it should have looked like. It is manual, last, single-cell and run on the friendliest data in the company, and it cannot fail, because there is no red, only somebody deciding it looks fine. The preview tool is an inventory rather than a gate: a client grid says something renders differently, not which contract broke, and in a multi-brand product nearly everything differs in nearly every cell for legitimate reasons. Neither has any opinion about the three defects that actually cost money, and none of them are rendering bugs: the empty or absurd variable, the wrong link, and the wrong recipient set. So the order is the harness order. Make the defect unrepresentable with the email subset enforced by the build. Assert what is computable: contrast per declared mode, image dimensions and alt text, a plain-text part, a preheader that is set, every link resolving with its tagging, and the template rendering with an empty value in every field. Render narrowly, only the templates a change touched. Rotate the rest over a week. Feed it from the fixture set rather than your own account. Then the two things no preview product checks: the variable is a data contract and the send fails before it leaves if a field is missing, and the recipient set is a deploy target gated by a staged send with a kill switch. ### Our users want to run our AI feature across a few hundred records at once and it falls apart. What has to change? You built a conversation and they are asking for a job. Three things break, in order, and the first decides the other two. The request breaks first: a loop inside one request dies at the first timeout, rate limit, network change or closed tab, and takes the finished work with it. So the unit of work is the item rather than the batch: each item a durable, addressable row with its own state, inputs, result, error and idempotency key, and the batch a view over those rows. Then a retry retries three items instead of three hundred, a resume redoes nothing, and the run has a URL so it is not owned by the tab it started in. The interface breaks second, by pretending the job is still a request. A progress bar implies one thing that will finish or fail, when hundreds of things are in different states, so the rendering is per item and partial success is the normal outcome rather than an error screen: forty-seven done, three failed, the three saying why, each retryable alone. The wire convention is a per-item status rather than one code for the batch, which is what 207 Multi-Status is for. Cost turns visible at this scale, so the estimate goes in front of the run rather than on the invoice, and the provider's rate limits become states the interface renders rather than errors it reports. The review breaks third. We are not a workflow automation or RPA vendor, we do not run your worker fleet, and batching does not improve the per-item output. ### Nobody is going to check three hundred AI-generated results. How do you make a batch reviewable? By reducing what has to be reviewed rather than decorating the surface where it happens. The arithmetic settles it: three hundred outputs at twenty seconds of real attention each is over an hour and a half, longer than the work the feature was meant to remove, so nobody spends it and a select-all gets recorded as review. The usual fix does not work either. The 2026 Harvard Data Science Review work on how people evaluate AI-generated suggestions found the strongest predictor of catching an error was the reviewer's prior attitude to AI rather than anything the interface did, with reviewers favourable to automation accepting incorrect suggestions more often, and the systematic reviews of automation bias find explanations and trust-calibration feedback do not reliably reduce it. A confidence number does not separate right from wrong, which is the same finding we quote on document extraction. So an explanation panel and a confidence badge are decoration that make an approval feel responsible without making it accurate. What works is structural: split by consequence rather than confidence, since reversibility is known before the model runs, so reversible internal changes apply and irreversible or outward-facing ones queue; review the shape of the change rather than the items, approving a pattern and inspecting the outliers; show the diff rather than the output; sample honestly and record the result instead of approving wholesale; and make per-item undo the safety net approval was never going to be. A batch that is reviewable is not a batch that is correct, and if quality is not good enough to run unwatched on the reversible share, the problem is evaluation rather than review. ### Our legal team says the EU AI Act requires AI literacy training. Is that what this workshop is? Partly, and the honest part argues against urgency. Article 4 has applied since 2 February 2025 and attaches to providers and deployers regardless of risk tier, which for most companies means deployer. Then it got softer rather than harder: the Digital Omnibus on AI, Regulation (EU) 2026/1744, voted by Parliament on 16 June 2026, signed 8 July, published in the Official Journal 24 July and in force 27 July 2026, rewrote Article 4 from a duty to ensure a level of AI literacy into a duty to take measures to support the development of one. That is an obligation of means rather than an outcome. National market surveillance authorities began supervising it from 2 August 2026, so the deadline urgency vendors are selling this quarter is mostly wrong. The Commission has also ruled out the product the market is rushing to sell: its AI literacy questions and answers, published May 2025 and maintained as a living document, says no certificate is needed and that organisations can keep an internal record of trainings and other guiding initiatives, with no mandated curriculum, no fixed hours and no approved course that satisfies the duty by being completed. What the standard rewards is role-specific and close to the work: fundamentals for a general workforce, deeper technical, risk and governance depth for the people building, buying or overseeing AI. Our workshops run on your codebase, with your tools, for named roles, and the record is a by-product, the same evidence chain the factory already produces for ISO 42001, NIST AI RMF and SOC 2. Limits: a workshop is one measure, Article 4 reaches people outside engineering we do not cover by default, and attendance is not literacy. We are not your counsel, we do not give legal advice, we do not determine whether the Act reaches you or in which role, and we do not certify anyone. ### Legal is asking what our in-product AI assistant has to tell users. How much of that is a Frontend job? Nearly all of it, and the place teams reach for first is the one place that cannot satisfy any of it. California's SB 243, signed 13 October 2025 and effective 1 January 2026, requires the operator to say so where a reasonable person would believe they were talking to a human; where the operator knows the user is a minor, to disclose that responses are machine generated and present a break reminder at least every three hours of a continuous session; and to maintain and publish a protocol referring users expressing suicidal ideation or self-harm to crisis services. Washington's HB 2225, signed 24 March 2026 and effective 1 January 2027, puts the disclosure at the start of each session and at least every three hours during it. Iowa's SF 2417, signed 2 May 2026 and effective 1 July 2026 with operator duties from 1 July 2027, requires telling the user it is AI and not a licensed mental health professional. More states arrive on staggered dates, so this roster carries its dates. Keep it apart from Article 50 marking, which marks a generated artifact in a machine-readable form: this is a session property, who the user is talking to and how long they have been doing it. The system prompt cannot deliver it, because a prompt is a request for output and output is the one part nobody can guarantee, so a disclosure that must appear is rendered rather than generated. The interval is wall-clock state the model cannot see, and it has to survive a reload, a second tab, a route change and an idle gap and then resume rather than restart, because a timer that resets on reload means the reminder never fires and nothing in the product reports it. Minor status is an input carried from the account, never inferred from the conversation. The crisis referral must render when the model call fails, so it is a rule on the user's input and a surface beside the conversation rather than something the assistant says. The published protocol is a page on your site. We build that list and keep it under tests, because a disclosure regresses silently when somebody refactors the chat shell. Limits: no disclosure makes an AI feature safe, we are not your counsel and do not decide whether your feature is a companion chatbot or which jurisdictions reach you, and we are not a crisis service and do not author clinical protocols. ### We ship a browser extension and a desktop client alongside the web app. Are those in the factory's scope? Yes, and they are usually the least governed Frontend in the company, for one structural reason: everything else you ship is replaced on the next page load and these are not. A served bundle is gone the moment you deploy over it. An extension waits in a store review queue you do not control. An installed client sits on a machine you cannot reach. A registered service worker answers your users from their own disk until it decides to look for a new one. The same engineers write all of it, agents now write a lot of it, and the pipeline that decides what is mergeable was designed around the one artifact that can be taken back. In the EU that stopped being an internal engineering distinction on 11 September 2026, when the Cyber Resilience Act's reporting duties started applying, including to products already on the market: an early warning to the ENISA Single Reporting Platform within 24 hours of becoming aware of an actively exploited vulnerability, a full notification within 72 hours, and a final report within 14 days of a corrective measure being available, or within a month for a severe incident. The Commission's guidance of 27 July 2026 is non-binding and it turns the scope question on where the software runs: a web application used through a browser is generally not a product in its own right, software that lands on the user's device is, and a backend is pulled in only where it is remote data processing the product needs in order to perform one of its functions, with a manufacturer's own internal systems such as CI/CD, CRM and HR outside that. The remaining obligations, conformity assessment and CE marking among them, apply from 11 December 2027. Whether your particular extension or client is in scope is a product-specific legal question and it is not ours: we are not your counsel, we do not certify anyone, and installing a factory does not make anybody compliant. What we do install is the part that is engineering. One inventory of every artifact that executes outside your origin, each with a named owner, because the usual answer to who owns the extension is somebody who left. Versions pinned and an SBOM produced by the build for each of those artifacts rather than for the web bundle alone. The same seven guards as the rest of the Frontend, plus the three only these need: declared permissions diffed on every change so a quiet widening of scope fails the run, secret scanning on the shipped package rather than on the repository, and an update channel that can be halted mid-rollout. A kill path that has actually been exercised, because an update path nobody has run is a plan rather than a control. And a reporting runbook naming who files, where, and inside whose clock, written before the 24 hours start rather than during them. The first pass usually turns up one of these artifacts that nobody has built from source in a year. That is the finding, and it comes before any of the rest. ### A bad release left part of our users stuck on a broken version and we could not reach them. What catches that? A gate on the one Frontend artifact that survives your rollback. Our release answer for a served bundle assumes the next load comes from your server, which is what makes a flag or a redeploy reach everybody on their next navigation. A service worker is the case where that assumption is false. It is code you installed on the user's device that answers their requests before your origin is consulted, so the version you just rolled back is still the version they are running. The update path is where teams get surprised, and it is specified rather than accidental. A browser treats a cached worker script as fresh for at most 24 hours, which reads like a ceiling and behaves like a floor on how long a bad worker lives: a long max-age on the worker script plus a worker that answers navigations from its own cache is a client that will not see today's fix today. An explicit update call bypasses the HTTP cache only when the last check was more than 24 hours ago, and the registration's updateViaCache setting decides whether the script and its imports are read from that cache at all. Then there is the half nobody tests. During an update the open tab is still running the old document while the new worker serves new assets, so a cache-first navigation hands back last week's HTML pointing at hashed chunks that no longer exist, and a precache that failed partway leaves some files new and some old. All of it returns 200 and fires no alert. So the gates are specific. Navigations go to the network first with the cached shell as the offline fallback rather than the other way round. Every cache name carries the build identifier, and old caches are pruned on activate after the new worker has control rather than before. The worker script is served with a short max-age and a registration that never reads it from the HTTP cache. The document and its assets agree on a version, and a document that finds itself stale reloads instead of requesting a chunk that is gone. And the release test almost nobody writes: install the previous build's worker, deploy the new one, and assert that a client reaches it without anyone clearing site data. One part is to be accepted rather than solved. For clients already stranded there is no switch on your server, because someone has to load a page on a path that reaches your origin. That is why the escape hatch has to ship in the version that is already out there rather than in the fix. A worker that can be told to unregister itself is something you build before you need it, and most teams build it the week after. ### Our product is a script our customers paste into their own site. What does that change about how we ship it? It inverts the tag-manager answer on this page. Every constraint a serious customer applies to third-party scripts, you are now the object of: your bundle sits inside their performance budget, your code runs with the full rights of theirs on their origin, and your Tuesday deploy is an uncontrolled change to their production unless you have built it not to be. If your snippet ever loads on a page that takes a card, PCI DSS v4 requirements 6.4.3 and 11.6.1, mandatory since 31 March 2025, mean somebody in your customer's org now owes an inventory entry, an authorization, a method of assuring integrity and a written justification with your name on it, and the cheapest way for them to satisfy all four is to remove you. The HTTP Archive's 2025 Web Almanac measurement of a median third-party inclusion depth of 3 is the other half of it: whatever your loader pulls in, your customer inherits without having approved it. So the artifact gets a contract, and the contract is most of the product. A loader small enough that nobody argues about it, with the heavy part fetched on demand and an API that queues calls made before it arrives. Rendering isolated, which in practice means a shadow root with one stylesheet shared across instances rather than a style block per widget, and an iframe where the content genuinely must not be reachable from the host page, which is anything carrying a credential or a card. No inline script or style anywhere, because their Content Security Policy will block it and your install instructions should be naming the sources you need rather than asking them to loosen theirs. Immutable versioned URLs with an integrity hash available, and never a mutable latest, because a mutable URL is a promise to deploy into their outage window. A size and timing budget asserted in CI against a page shaped like theirs rather than against your demo. And it changes who reviews a change, because an embedded artifact is an API and moves at an API's pace: a deprecation window, a usage census taken from real sessions rather than from your docs, and a version a customer can pin while they catch up. The failure we get called about is always the same one. The widget was built by the team that ships the app, on the app's cadence, and the first customer to pin a version finds out that nobody can build last quarter's. ### Our CFO is auditing the AI coding spend and wants to know what it bought us. What can we actually prove? Less than you are about to be asked for, and the gap is evidence rather than measurement, which is the good news, because evidence is something a pipeline can produce and a belief is not. Start with where the industry is, because it tells you the shape of the conversation you are walking into. Jellyfish’s 2026 State of Engineering Management, published in May 2026 off more than 600 engineering leaders, found 84% calling engineering productivity a top management concern and 64% believing they were already getting at least a 25% increase in developer velocity out of AI, while only 46% of organizations were tracking any AI-specific metric at all. So the belief is close to universal and in half of these companies there is nothing underneath it. Qodo’s 2026 State of AI Code Quality, published 23 September 2026 from 500 developers and 300 engineering leaders in the US with fieldwork between 7 and 14 August, puts the same gap precisely: 90% of engineering leaders were confident reporting AI’s impact to executives or the board, and 45% had evidence of traceability from AI activity to the code changes it produced. Confidence is not the scarce thing here. Then the part that should make you careful about your own engineers’ impressions, including the ones you trust most. METR ran the only properly randomized trial of this, published 10 July 2025: 16 experienced developers, 246 real issues out of their own mature repositories, AI allowed or disallowed per issue at random. They forecast a 24% speedup, estimated afterwards that they had been sped up by about 20%, and were measured 19% slower. The footnote matters more than the headline and we always give it: METR has since changed its experiment design, treats that result as historical, and its follow-up estimates carry confidence intervals that cross zero, which means the best-designed study anybody has run cannot currently tell you the sign of the effect. If that is true of a controlled trial, a quarterly survey of how fast the team feels is not evidence, and a vendor dashboard reporting suggestion acceptance rate is not either. One number to refuse outright. DORA published Finding balance in the era of tokenmaxxing on 2 June 2026, about the internal leaderboards that rank a company’s heaviest token users, and the objection is structural rather than cultural: token volume measures input, it is trivially gamed, and it stops being a measure the moment it becomes a target. Lines of code, pull request count, seats activated and acceptance rate all fail the same way. Every one of them rises when nothing has improved, and a board that works that out for itself afterwards is a board you cannot go back to. So here is what the factory instruments and what each piece of it actually lets you claim. A baseline taken in the audit before anything is installed, because a level with nothing to compare it against is the one mistake that cannot be repaired later. Provenance recorded at merge, per change rather than per repository: which tool, which model, which run, which revision of the context files, and which person approved it. That is the exact field the other 55% do not have, it is what makes every other number answerable, and retrofitting it is archaeology. Guard catch rate, meaning what the pipeline rejected before a human was involved, which is the cleanest thing on this list because it counts events rather than estimating time. Review rejection rate on agent output, read as a trend. Cost per merged pull request rather than cost per seat. The share of merged volume arriving from outside the Frontend team, which is the flagship claim and is also a count. And change failure rate split by whether the change was agent-authored, which is the question underneath your CFO’s question, and which is impossible without the provenance field. Now the limits, stated plainly, because they are the reason to trust the rest of it. You have no control group. You will not run half your teams without agents for a quarter, you cannot randomize your own organization, and anybody offering you a clean counterfactual is selling you one. A model got cheaper, you hired four people, a reorg happened and one noisy service was finally fixed, all inside the same window. So the defensible claim is a before and after against a named baseline with the confounders written down beside it, not an attributed percentage with a decimal point. We build and operate the instrumentation inside your pipeline and your repository, and the series it produces is yours to read and yours to publish. We are not your auditors, we do not write board material, and we will not certify a return on anything. The unprofitable version of this answer, which is the one we give when it applies: if no baseline was ever taken, the first honest report is a baseline, and that is the report to send. ### If we stop the engagement, or you disappear, what do we still own and what stops working? Everything we built, and nothing stops. That is a consequence of where it lives rather than a promise in a contract, so the useful form of the answer is a test: imagine we stopped answering email tomorrow, and ask what breaks. The answer should be nothing that is running. The factory is files in your repository and jobs in your continuous integration. Context files, the skills maintained per repo, guard configuration, eval suites, codemods, the generated artifacts such as the component registry and the token map, the gateway policy, the telemetry schema. All of it arrives as pull requests your own people review and merge while we are still there, which is also why there is no single handover event that has to go well. By the time an engagement ends your repository has held the whole thing for months. The formats are the part worth knowing, because this is where lock-in would live if it lived anywhere. The agent-facing artifacts are not a proprietary schema and they are not rows in a console we host. AGENTS.md was published by OpenAI in August 2025 and is read natively by a long list of tools, Codex, Cursor, Copilot’s coding agent, Gemini CLI, Windsurf, Aider and Zed among them, and in September 2026 Claude Code began reading it as well. More to the point for your question, it does not belong to any of them: on 9 December 2025 the Linux Foundation formed the Agentic AI Foundation around three founding projects, Anthropic’s Model Context Protocol, Block’s goose and OpenAI’s AGENTS.md, with platinum membership that includes AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. So the file your delivery standards are written in is stewarded by a neutral foundation rather than by whichever agent vendor you are paying this quarter. We keep AGENTS.md as the source and the tool-specific files as thin shims pointing at it, which is what makes the engine a swappable part and the standards the durable asset. What we deliberately do not hold matters just as much. There is no Enpitech dashboard that your numbers live inside, no hosted service of ours in the path of a build, no license on anything we write, no account of ours that your pipeline authenticates against, and no agent we operate from outside your perimeter. Spend and telemetry land in whatever you already run. If something we built needed us in order to keep running, we would have sold you a dependency, and that is a thing to say in the first conversation rather than the last. So what do you lose when we go. Us, which is operation and iteration: the loop that turns each new failure into a permanent guard, the attention that keeps the artifacts from drifting away from the code, and the judgement about which guard should go on next. That is a real loss and it is the honest answer. It is also the failure mode that actually happens, and it is behavioural rather than technical. The artifacts go stale the way documentation goes stale, except that staleness is worse here, because agents read these files and act on them confidently. A guard set nobody updates starts blocking things it should not, the first few bypasses get waved through by people in a hurry, the bypass quietly becomes the norm, and a year later you own the tooling and none of the behaviour. Which is why handover is a test rather than a date, and why a named internal owner is a precondition for the engagement rather than a nicety at the end of it. On the commercial side there are two different things buyers mean by this question and both get a straight answer. The factory is phased and fixed-price per stage, so stopping is a decision at a stage boundary rather than a negotiation, and an operation retainer after handover exists as a choice rather than as the shape of the deal. Embedded engineers are the one place with a minimum term, a monthly retainer per engineer with a six-month minimum, and we would rather say that than imply everything here cancels on a whim. The boundary: we write this into your repository under your ownership, and we are not your counsel. Assignment, contract terms and data processing live in the agreement where they can be negotiated, not in an answer on a web page. ### We did the agent-readiness work. How do we know whether AI assistants actually recommend us, and can you report a number? Yes, with one caveat stated first, because it decides everything after it: there is no number here that behaves like a search ranking, and a dashboard that hands you one is handing you a sample dressed as a position. What you are measuring is not an index you hold a place in. It is a generated answer, and that answer is a function of the prompt, the engine, how hard the engine decided to think, the user’s history and the minute. There is now a measurement of how much that matters. Semrush, with Kevin Indig, took 100 prompts across 20 buyer journeys and ran each one at ChatGPT’s minimal and high reasoning settings, published 30 June 2026. Only 25.6% of the cited domains overlapped between the two settings. High reasoning cited a source in 68% of answers against 50%, averaged 4.5 sources per response against 2.6, ran roughly 4.6 times as many internal sub-queries, 1,130 against 245, and drew on 173 unique domains against 127, with 99 of those never appearing at the lower setting at all. The mix moved too: user-generated content lost around half its citation share at the higher setting while official documentation and institutional sources gained. One hundred prompts is a modest sample and the percentages are directional, but the direction is the whole finding, and it is that one engine at a different setting behaves like a different engine. Semrush’s clickstream work on US ChatGPT sessions supplies the other half: the share of queries that triggered a web search at all was about 34.5% as of February 2026, down from about 46% in late 2024 and ranging between roughly 15% and 66% across the period. A large fraction of the answers being given about your category are not retrieving anything at the moment they are given. Read those two together and a single-run visibility score is a coin toss with a decimal point on it. So this is what a defensible measurement looks like, and most of it is discipline rather than tooling. A fixed prompt set written out of language real buyers used, versioned in the repository like a test suite, because the series breaks the moment the prompts change and a hosted dashboard changes them without telling you. Repeated runs rather than one, with the run-to-run variance reported next to the mean, because a movement smaller than your own spread is not a movement. Reported per engine and per setting and never averaged into one score, since engines whose sources overlap by a quarter cannot be summed. Run logged out and unpersonalized in a clean context, or what you are measuring is your own browsing history. And mention, citation and position recorded as three separate things, because being named is not being linked, and being linked fifteenth is not being recommended. Then the half that is not a sample at all, which is the half we care about most, because it happens on your own origin and lands in a log rather than in a survey. Which retrieval bots fetched which routes, how often, and whether what they received was rendered HTML or an empty shell, with the caller verified rather than taken at its word. Sessions arriving from assistant surfaces treated as their own funnel, with the lossiness admitted up front: many assistant referrals carry no referrer, and a person who read about you inside a chat and then typed your name into a browser is indistinguishable from direct traffic, so that number is a floor and never a total. And your own content instrumented as a source, so that when an engine does quote you, you can see which passage it took and whether the claim it extracted is the claim you wrote. One piece of ordering advice saves the most money here: fix readable before you measure cited. A page the retrieval bots cannot read produces a measurement of nothing, and that is a rendering decision rather than a content problem. The free scan at enpitech.dev/agent-ready tells you which half you are in before anybody builds a harness. The boundary: we build the surface, the instrumentation and the measurement harness, inside your repository and your pipeline, and the data stays yours. We do not sell a visibility product, we are not your SEO or PR agency, we do not buy placements, and no amount of engineering is a guarantee of citation in any engine. If the harness says your content is the problem rather than your Frontend, we will tell you so, and it is not work we will bid for. ### We are generating several times the pull requests we used to and the backlog has not moved. Where is the work going? Into branches nobody merged, and there is a number on it now. LinearB’s 2026 Software Engineering Benchmarks report measured acceptance, defined as the share of pull requests merged within thirty days, across 8,109,244 pull requests from 4,813 teams and 163,820 active contributors in 42 countries. Hand-written pull requests merged at 84.4%. AI-assisted ones merged at 32.7%. Read that as a scrap rate rather than as a speed problem: roughly two out of three agent-authored changes were generated, looked at by somebody, argued about and thrown away. The queue you can see is the cheap half of that. The expensive half is that the work was paid for twice, once in tokens and once in reviewer attention, and shipped nothing. One clarification before that figure goes near a board, because this site refuses a metric with almost the same name. Suggestion acceptance rate, the share of a tool’s inline completions a developer tabs into a file, is a vanity number that climbs when nothing has improved. Merge acceptance is its opposite: it is measured on the far side of review, on the artifact that actually ships, and it falls when your pipeline is failing. Do not let a vendor dashboard hand you the first one and call it the second. What makes this a factory argument rather than a model argument is the elite band in the same data. The strongest teams clear just above 71% acceptance on AI-assisted pull requests, against above 95% on hand-written ones, and getting past 60% is hard across the whole set. So the ceiling moves a long way with the model held constant, which means most of the distance between 32.7% and 71% is a property of the system around the agent: whether it reads your conventions before it writes, whether a guard decides mergeability before a human is asked, whether the change arrives small enough to review at all, whether the reviewer is told what the change is for. Each of those is something you install. None of them is something a seat sells you. What we do with it is unglamorous. The audit takes your own acceptance before anything is switched on, split by whether an agent authored the change and by which team opened it, because one number averaged over the org hides the only comparison that matters. Then the guards go in front of review rather than behind it, and the loop turns each rejection into a permanent check so a person does not have to make the same rejection twice. We report the split rather than a lift figure, and your own baseline stays the thing we are measured against. ### If agents write most of the code and PMs are opening pull requests, what is a performance review supposed to measure? Not the diff, and an org still measuring the diff is about to promote the wrong people. Two things happened at the same time. The output a reviewer sees stopped being a reliable signal about the person who produced it, and a whole category of work appeared that no ladder has a line for. Harness commissioned Sapio Research to survey 700 software engineering practitioners and managers across the United States, the United Kingdom, India, France and Germany in April 2026, published on 13 May 2026. 81% said developers spend more time in code review since adopting AI coding tools, and 28% of them put the increase above 30%. Around 31% of developer time went into work the organizations themselves described as invisible: reviewing agent output, fixing its subtle bugs, explaining it to teammates, switching between tools. Only 38% tracked the time spent reviewing AI-generated code at all. Over the same survey, 89% of leaders said productivity had improved. The sample is large enterprises rather than a 30 to 300 engineer company, so read the direction and not the decimal. Put those two facts beside each other and the perverse outcome is obvious. The engineer who absorbs the review load, turns a rejection into a guard so the mistake cannot recur, and keeps the design system from drifting is doing the most valuable work in the building and the least legible on a performance form. The engineer who merges a large volume of agent-written change is perfectly legible and may have left nothing durable behind. A ladder that reads volume pays the second one. What we have seen work is a judgment rather than a measurement, and it is to move the criteria onto the decisions instead of the artifact. Did this person’s review catch the thing that would have broken, and can you point at it. Did a rejection they made become a guard, so the next twenty runs cannot repeat it. Can they say why the code is the way it is, which is the question an agent does not answer and the one a newcomer actually needs. Did the context and conventions they own make somebody else’s change mergeable. That last one is the only honest way to credit the person whose work shows up inside other people’s throughput. The hiring end of the same question points the same way without any help from us. BairesDev’s Dev Barometer surveyed 1,569 developers across 77 countries in April 2026 and published on 11 June 2026: 48% of junior developers named problem solving and analytical thinking the most important hiring credential against 18% for AI tool proficiency, and 72% of seniors put critical thinking first among what juniors need over the next three years, ahead of tool proficiency entirely. The market is already pricing judgment over fluency. The ladder is usually the last document to hear about it. What the factory contributes is the record that makes any of this checkable rather than remembered. Provenance written per change at merge, which tool, which model, which revision of the context files, which person approved, is what lets you tell an engineer’s own work apart from their supervision of an agent’s, and it has to be switched on before the review cycle needs it rather than reconstructed afterwards as archaeology. We do not write your ladder, we do not sit in your calibration meeting, and we do not sell a developer productivity score. We make the inputs exist. ### We are standardizing on one AI coding tool. Should the workshop be built around it? Built on it, not around it, and the last six months are the whole argument. JetBrains ran its Developer Ecosystem Survey across more than 15,000 professional developers between May and July 2026 and published the agent findings in August 2026. Coding agents are used at least weekly by 90% of them and daily by 68%, so whether to adopt is a settled question. Which one is not. Claude Code went from 18% work adoption in January 2026 to roughly 39%, and is the single most-used tool for 31% of developers. Cursor moved the other way over the same window, 18% down to 12%. GitHub Copilot led in January and does not now. Nobody standardizing in January predicted that, and nobody standardizing this quarter should bet a training budget on the next two. So the part worth teaching is the part that survives a migration. What belongs in a context file and what does not. How to scope a task so an agent can finish it and a human can review it. How to read a diff you did not write, at the level where you catch the wrong thing rather than the ugly thing. When to stop a run instead of correcting it. Where a guard belongs so a mistake is caught by CI rather than by a colleague. Those transfer between engines because they are properties of your codebase and your review culture, and neither of those gets retired in a release note. A workshop held in the abstract teaches nothing, so we run on whatever you actually have installed, on your own repository, and what the room produces, the context files, the skills, the guards, is yours and is not written in anyone’s proprietary format. Switch engines next year and the method holds while the files move. Had we built the day around one vendor’s keyboard shortcuts, you would be buying it again. One honest limit. Tool-specific depth is real and we do teach it, because the gap between a team at the surface of a tool and a team using it properly is large. We put it after the method rather than instead of it, and we tell you on the day which parts have a shelf life. ### Our board wants headcount down 10% before the next round and Frontend is still the queue everyone waits on. Which of these six survives that? The ones that leave something behind, and for an Israeli company the local numbers make that case better than any global budget forecast. The Israel Innovation Authority’s 2026 annual high-tech report, covering 2025, carries a figure the industry had not seen before: roughly 3,500 fewer people in R&D roles, the first decline in a decade, with R&D’s share of high-tech employment falling from 51% to 49% while product roles rose to 24%. Total high-tech employment still grew about 2.3%, to around 400,000. Read those together and this is not a contraction, it is a recomposition, and the direction is the uncomfortable part. The half of the org that files Frontend asks grew as a share of the company. The half that can merge them shrank. That is this site’s entire thesis arriving in an org chart rather than in a pipeline, and it is the reason a 10% cut does not shorten the queue you are describing. It removes people from the front of it. Two more local facts belong in the same decision. Calcalist has reported that venture funds are advising portfolio companies to cut at least 10% before raising, to present a leaner cost structure, which is sourced reporting rather than a named fund and is quite possibly the origin of your number. And the share of employees based in Israel at private Israeli tech companies fell from 69% in January 2019 to 62% by March 2026, so part of what gets counted as a cut is a seat reopening in another timezone, which lengthens a review cycle even when the headcount total looks flat. Now the counterweight, and it is the strongest argument against us in this answer. Calcalist and Ynet have both reported what people in the industry privately call AI washing: cuts and hiring freezes publicly attributed to AI-driven efficiency when the real driver is the cost of an Israeli employee, with a strong shekel and salaries up roughly 20% in dollar terms. The Innovation Authority itself only suggests that AI adoption may be part of its own explanation. So if your 10% is a payroll and currency decision wearing an AI story, then buying a delivery system because AI caused the cut is buying for a reason that is not true, and we would rather you noticed that here than three months in. The purchase has to stand on the queue itself, which is answerable this week out of your own repository. Of the Frontend pull requests that waited more than three days last quarter, how many waited on a named senior reviewer rather than on CI, on a decision or on a dependency. If that number is small, your constraint is demand or direction and none of the six options on this page is the right spend. If it is most of them, the cut is about to make it worse, and the comparison gets simple: four of the six here are things you stop paying for and immediately stop having, which is a hard position to defend in the second year of a shrinking headcount line. Two leave an asset in your own repository that keeps working with fewer people around it than it was installed for. In a year when the only line that moves is down, that difference is the decision. ### If agents wrote most of our Frontend, do we still own it? Legal has started asking and we do not have an answer. You own the repository. Whether copyright subsists in the parts a model wrote is a different question, and in the United States it now has a settled floor and an unsettled middle. The floor arrived on 2 March 2026, when the Supreme Court denied certiorari in Thaler v. Perlmutter, docket 25-449, leaving in place the D.C. Circuit’s March 2025 holding that the Copyright Act requires a human author. A model is not an author and cannot be named as one. A denial of certiorari is not an endorsement of the reasoning below, but for planning purposes the human-authorship requirement is the rule you are operating under. The middle is the part that actually touches your codebase, because nobody has drawn the line between a human who prompted and a human who authored, and that is where a Frontend repository full of generated components now sits. The Copyright Office’s registration guidance is where that abstraction turns into paperwork, and it is worth reading before your counsel is asked to improvise. Generated material that is more than de minimis has to be excluded from a registration, in the Limitation of the Claim section, and the applicant has to explain what the human author contributed. Human selection, arrangement and modification of generated material can be protected where it is sufficiently creative, so the question the Office asks is not whether a tool was involved. It is which parts a person authored and what that person did. Applications already filed have to be corrected rather than left alone, pending ones through the Public Information Office and registered ones by supplementary registration. We are not lawyers, we do not give legal advice and we have no view on how your counsel should answer any of this. What we notice is that every available answer needs the same input and almost nobody has it, which is a contemporaneous, per-change record of who did what: which tool and model produced the first draft, which revision of the context files it read, what the human changed between that draft and the merge, and who approved it. The factory writes that at merge time for reasons that had nothing to do with copyright, and the diligence answer on this page covers what the same record hands an acquirer or a security reviewer. The point worth making here is narrower and it is about timing: this record cannot be reconstructed. A year from now your git history will tell you that a human pushed a commit. It will not tell you whether that human wrote the component, rewrote six lines of it or pressed accept, and no later work recovers the difference, because the evidence was never captured. Teams who switched provenance on before anyone asked have an answer available. Teams who did not have an archaeology project with a lawyer billing against it. One scoping note, because everything above is American. Other jurisdictions handle this differently: the UK has a computer-generated works provision and the EU approaches it through originality rather than through whether a machine can be an author. If your entity or your likely acquirer is not US-based, the legal question belongs to counsel there. The record is the same record in every jurisdiction, which is the one part of this we can usefully build. ### The workshop went well and three weeks later the team was back to its old habits. What makes it stick? Artifacts committed to your repository and one named owner, and it is worth being blunt about why, because the alternative has been measured. DX’s research across more than 400 companies puts the median gain in pull request throughput from AI coding tools at 7.76%, with a mean of 13.1% and most organizations landing between 5% and 15%. That is a real gain and it is nowhere near the one in the pitch, and the distance between them is almost entirely about whether anything structural changed or whether a group of people simply had a good day. The same research puts the hidden annual cost of a rollout, meaning codebase indexing, compliance work and enablement, at 50,000 to 250,000 dollars, which is to say the training line is already in your budget whether or not anybody planned it. There is also a measurement trap here, and it is why we do not send a satisfaction survey after a session. METR’s randomized trial, published 10 July 2025, had 16 experienced open source developers work 246 real issues in their own repositories. They were roughly 19% slower with AI, and afterwards estimated they had been roughly 20% faster. A post-workshop happiness score measures exactly the instinct that produced that thirty-nine point error. If the only evidence a workshop worked is that people enjoyed it and feel quicker, you have bought a good day and called it a capability. So the design is the opposite of an event. A session ends with things committed rather than slides handed out: the context file for the repository the team actually works in, one or two skills that encode a review comment that team keeps repeating, and at least one guard in their own CI that fails a run for a reason the room agreed on. Those survive the month because nothing about them depends on anyone remembering the session. Then one person owns them by name, with time allocated to maintain them, because a context file nobody owns rots inside a quarter and is then worse than having none: it is confidently wrong and the agent reads it anyway. The follow-up is a review of real merged pull requests from the weeks afterwards, not a refresher. Two places this argues against us. If nobody is going to be given that ownership, buy the shorter session, keep the artifacts and skip the follow-up, because otherwise we are billing you for a habit the organization has not agreed to hold. And if what you actually need is for a whole department to start merging rather than for one team to get better, a workshop is the right instrument at the wrong scale. That is a factory install, and we would rather say so than sell you four sessions that cannot reach it. ### Our pull request volume is up sharply and the review queue is clearing faster than it used to. Is that good news? Usually not, and the reason is that a queue clears for two completely different reasons that look identical on a dashboard. It clears because throughput went up, which is what you bought. Or it clears because the gate stopped being applied, which is what you got. Queue depth cannot tell those apart, and queue depth is what most teams are watching. There is a number on the second one now, and it comes from the same report this site already uses for the review-time figures. Faros AI’s 2026 engineering report, drawn from two years of telemetry across 22,000 developers and more than 4,000 teams, found pull requests merged with no review at all, human or agentic, up 31.3%. Hold that beside the volume. Linear’s aggregated workspace telemetry has workspaces connected to coding agents going from roughly 21 to roughly 65 pull requests opened per week between June 2024 and June 2026, against roughly 8 to 10 in workspaces without them. Read the direction rather than the decimal on both: the agent-connected group started from a much higher baseline, so that divergence describes a population rather than proving a cause. The direction is not in doubt and it is the only part the argument needs. Volume multiplied. Reviewer headcount did not. Something had to give, and what gave was the review. That is not a discipline failure, and telling people to be more careful will not touch it. It is what every capacity-limited gate does under load: it fails open. A human reviewer is a capacity-limited gate. Asked to clear several times the volume with the same people and the same working day, the population will approve faster, approve larger diffs, and eventually approve without reading, because the alternative is to become the bottleneck everybody can see. The incentive points at the merge button. A CI check has the opposite property. It fails closed, it costs the same at ten pull requests a week as at a hundred, and it cannot be talked round at 6pm on a Thursday. So the factory’s answer to volume is not a faster review, it is moving the decision that must not be skipped off the human and onto the machine. Design system, accessibility, security, test quality, performance budget and contract conformance are asserted in CI before a person is asked anything, which means the gate that actually runs is the one whose capacity does not depend on how busy anyone is. What is left for the human is the part a machine genuinely cannot do: is this the right change, does it belong here, what will it cost us in a year. That is judgment on a small pre-filtered set, and it is work a senior engineer can still do at volume. Then measure the thing you were not measuring. Review coverage belongs on your dashboard as a first-class number beside throughput: the share of merged pull requests that passed no human and no agentic review, split by whether an agent authored the change and by which team opened it. A rising throughput line next to a rising no-review line is not a win, it is the shape of a problem arriving, and it is legible a quarter before the incident that makes it obvious to everyone. We take that split in the audit before anything is switched on, so your own baseline is the comparison rather than anybody’s benchmark. Two limits, said plainly. A guard proves a change satisfies the rules you declared, never that the rules are the right ones, which is the same honest limit every gate on this site carries. And coverage measures whether review happened rather than whether it was any good, so it catches the failure described here and not a careless approval. We build and operate the gates and the instrumentation inside your pipeline. We do not write your review policy, we do not sit in your calibration meetings, and we do not sell a developer productivity score. ### Our security team has to sign off before we expose an MCP server. What will they ask for, and how much of it is our build rather than their policy? Most of it is your build, which is the part teams discover late. A security review of an agent-facing surface is not the web application review your team has run fifty times, because the caller on the other side is not a person: it is a non-human that will act on instructions it found in text it read, and that has no judgment about consequences. Four questions decide the sign-off, and three of them are answered in code you either wrote or did not. The audience question comes first and it is the one most first-generation servers fail. The specification is normative here: a server must not accept a token that was not issued for it. The shortcut everyone reaches for is to take the caller’s token and present it to the downstream API, because it works on the first day and saves building a credential exchange. What it costs is every control you have. Each downstream call now looks like it came from the user, through a service that was never in the token’s audience, so you cannot attribute a call, you cannot rate-limit the agent separately from the person, and revoking the agent’s access means revoking the user’s. The fix is unglamorous. Validate the audience on every request and refuse anything addressed elsewhere, then exchange for the server’s own downstream credential, scoped to what this call actually needs. The consent question is the one nobody anticipates, because it is not a bug in your code, it is a property of the pattern. A server that proxies to a third-party identity provider behind a single static client ID can be walked past its own consent screen: a caller who already holds a consent cookie for that client gets an authorization code without anybody being asked again, and the deputy that was supposed to be doing the checking is the thing being used to do the damage. Store consent per client rather than per proxy, and validate the audience on the way back. The move away from dynamic client registration toward client ID metadata documents narrows this for anything built now, and it does not retire a server already running the proxy pattern, which is a thing to go and look at rather than assume. The authority question is about the tool list, and the thing to internalise is that a tool list is an API surface with a persuasion layer on top. An assistant calls the tool that looks easiest for the goal in front of it, so the convenience tool that takes a free-text filter and a generous limit is the one that gets called, repeatedly, by something that will not notice it has just exported your customer table. Read tools and write tools separate. Every write scoped to what the signed-in user could already do in your own interface, enforced on the server, because a tool that can do more than its caller is a privilege escalation with a friendly description. Anything irreversible, anything that moves money and anything a customer sees gated behind an explicit confirmation in the interface, rather than a sentence in a tool description asking the model to be careful. And idempotency keys across all of it, because retries are ordinary on a stateless transport, and being called twice is a rounding error right up until the tool sends an email. The provenance question is asked last and skipped first. A tool call is a privileged action taken by a non-human on behalf of a human, and if you did not record which tool, which arguments, which client, on whose behalf and what changed, then there is no answer available later. It does not reconstruct from application logs, because the thing you need is the chain of delegation and that was never written down anywhere. It has to be switched on before the first incident rather than after it, and it is cheap now and an archaeology project then. The fifth thing they will raise is untrusted content reaching the agent, and that one is answered at length elsewhere on this site. The short version is the rule everything else hangs off: content your agent reads is input, never instruction, and no amount of prompt wording substitutes for a tool that cannot do the damage in the first place. So where the line falls. The policy is theirs: what data may leave, which actions need a second human, what gets logged and for how long. Audience validation, per-client consent, scoped and separated tools, confirmation in the interface and the audit record are build, every one of them cheap before launch and expensive once a connector is live with customers on it. Do them in that order, and pin and assert the specification revision before any of it, because a security property you have not tested is a security property you are hoping for. Three boundaries. We build the capability layer, the authorization and the audit trail inside your product and your repository. We are not a security auditor, we do not run penetration tests, and we do not certify anyone against anything. And we do not speak for the specification: we date what we claim and re-check it, because this roster moves. ### If we commit agent configuration, hooks and MCP servers into our repository, what happens when one of our engineers opens somebody else’s branch? Something runs, and that is worth being precise about, because it is the one place where the rest of our advice opens a surface rather than closing one. Commit the context, the skills, the guard configuration and the tool definitions, and recognise that those files are not all documentation: some are executable configuration the harness reads out of the working tree, so a branch can carry a command and a checkout can fire it. Claude Code had a project settings file whose hooks could run shell commands at startup (fixed in 1.0.111, CVE-2025-59536) and a project-settable API base URL that sent requests, with the key attached, to an endpoint the repository chose (fixed in 2.0.65, CVE-2026-21852). Against a vendor defect the control is a version you roll forward. The structural half is not a bug: Mindgard’s catalogue of agent-IDE vulnerability patterns reports that approval is commonly bound to a folder path rather than to file contents, so configuration committed later can load without anyone being asked again, and several vendors closed that as intended behaviour. The trust-this-directory dialog is a decision one person made once, before the file existed in its current form, and nothing re-asks after a pull. The second route in is the instruction file, arriving through the dependency graph. NVIDIA’s AI Red Team demonstrated it: a compromised library that detects an agent environment and drops an instruction file telling the agent to insert a five-minute delay into main functions and to leave that change out of its pull request summary. The payload asks the agent to lie in the artifact your reviewers read. A Cloud Security Alliance research note from May 2026 catalogued the cheap variants (prose, Unicode that does not render, external references, conditional instructions), and Tenable notes that a poisoned configuration file has the same schema and shape as a clean one, differing only in the command it points at. So the configuration is treated as privileged code: a rules file persuades a model and a hook executes a command. Harness directory, instruction files, server and tool declarations, hook scripts and CI workflow files behind ownership, reviewed by a named human, never approved by the run that proposed the change. Mergeability checks defined outside the branch they judge, pinned and required from the default branch. Servers and hooks enumerated centrally and pinned, project-level auto-approval off, no repository-level setting allowed to redirect an endpoint, a proxy or a credential. CI reading those files the way the agent does: normalisation that fails invisible and bidirectional control characters, configuration paths surfaced as their own line in review, a content hash so a change is an event. And the run that holds anything worth stealing in a sandboxed runner with no ambient credentials and an egress allowlist rather than a signed-in laptop session holding a publishing token. Limits: none of this makes your harness bug-free, so a current version and an advisory feed somebody reads is the first control, and ownership stops working the moment everyone is an owner. We are not a security vendor, we sell no scanner, we run nothing on your laptops and we certify nothing. ### We are going to hire someone to own this internally, an AI enablement lead or a developer productivity engineer. Is that not a better version of what you sell? Often yes, and you should probably make that hire whatever you decide about us. A permanent owner with standing inside the org is the one thing no engagement supplies: somebody has to decide the rules, say no to an exception, keep the context files true a year from now, and be the person a team argues with when a guard fails their pull request. Every engagement ends, ours by design, and the handover has to land on somebody. The hire is the whole answer when your constraint is adoption rather than mergeability: if changes merge today without a senior Frontend engineer rescuing them, the design system is genuinely enforced, CI already fails what you care about, and what you are missing is that most of the company never learned to drive the tools, then buy the person who runs sessions, writes the playbook and sits with teams, because it is cheaper than everything else on the shortlist and it is the right purchase. Where the hire alone stalls is structural: the role arrives with a mandate and no authority over the merge gate, which is where this work exists or does not. One person can teach, advocate and write documents; one person cannot install a design-system guard, own the contract, accessibility and performance checks, instrument the runs, carry on-call for a pipeline that now blocks everybody’s merges, and still have the week left for four teams. DORA’s ROI of AI-assisted Software Development (22 April 2026) is the counterweight: the return comes from the quality of the surrounding system, the internal platform and the clarity of the workflows, rather than from the tools or from any individual’s fluency. Enablement without a gate is evangelism, measured in attendance. Two notes. This is the hardest hire on the shortlist, because the profile is a senior Frontend engineer who also owns CI and can teach, which is the market the forward deployed engineer page describes with the same bidders in it. And a hire leaves everything behind, which is the best thing about it, and exactly one person’s knowledge, which is the risk: if they go, what stays is what was written into your repository and your CI. So make the hire and do not spend their first quarter building from zero. Either they build it with the assessment, the guard list and a measured baseline, or we install and operate the guard set and the committed context for a stage and hand it over running, so their first quarter goes on the adoption work only a permanent insider can do. We are not a recruiter: we do not source, screen or place a permanent hire and there is no fee here if you make one. Our own engineers are embedded on a retainer and stay ours, which is a different purchase. ### A large part of our Frontend is delivered by an outside agency, and we think they have started using AI. What do we actually do about that? Stop trying to supervise their process, because you cannot see it and you were never going to. The first instinct is a disclosure clause, and it is worth having as long as you are clear about what it buys you: the name of a tool and perhaps where it was used, which is not a property of what landed in your repository. The drafting is a question for your counsel. Why process supervision fails is easier to see in a case from outside software. In October 2025 Deloitte Australia agreed to repay the final instalment on a report it had delivered to the Australian Department of Employment and Workplace Relations, after a reader found fabricated references in it, including a quotation attributed to a Federal Court judgment and papers attributed to academics who had not written them. The corrected version added a disclosure that a generative AI system had been used in preparing it, and the department said the substance and the recommendations stood. Two things in that are the lesson, and neither is about consultants. The defect sat in the layer everybody assumed somebody else had already checked. And it surfaced because one outside reader happened to check a claim that was checkable, not because the acceptance process caught anything. Code has the same shape with one enormous advantage: in a repository almost everything is checkable by a machine, on every change, which is the only form of acceptance that scales to a supplier’s volume. So the move is to stop grading the supplier and start gating the artifact, and the gate is the one you would build for your own people anyway. Tokens rather than raw values. No second copy of a component that already exists. The mechanical accessibility criteria. A per-route bundle budget the build fails on. Contract tests against your own API. Layout under the longest locale you ship. Taint paths from request data into DOM sinks. Licence and provenance on anything added to package.json. Your supplier either passes that on every pull request or does not, and the result is a fact you can read without reading their timesheets, their prompts or their process. Three things are specific to an outsider rather than an employee and are worth adding deliberately. Provenance on what they bring in, because a dependency and a generated snippet both arrive carrying a history you did not choose. Scope on what their branch is allowed to execute, since the agent configuration, hooks and tool declarations we tell you to commit are executable and a supplier’s branch is somebody else’s branch. And a definition of done that is the gate rather than a demo, because passes the gate is a sentence both sides read the same way and looks right in staging is not. Then the commercial half, which decides whether any of the above survives contact with the relationship. Look at how they bill. If you pay for time, every efficiency your supplier installs is a revenue cut for them, and you have asked them to volunteer it against their own interest. That is not a character problem, it is the incentive you wrote. Moving acceptance onto the artifact changes the unit you are buying from hours to merged work, which is the shape of a fixed-price deal and the only version where their AI savings can reach you at all. We hold that position about our own pricing, we are a supplier too, and you should put us through the same gate as everybody else. Two limits, and the first one costs us something to say. This will not tell you how much of their code an agent wrote, and no detector will either, so build the provenance record on your side rather than buying a verdict about authorship. And a gate is engineering, not a remedy: we install and operate it, we do not manage your vendor relationship, we do not draft or negotiate your contracts, and we are not your counsel. ### We have not approved an AI coding tool yet, and we are fairly sure people are pasting our code into one anyway. What is that costing us, and what actually stops it? Waiting is a decision with a cost, and the cost is now measured in the most ordinary industry source there is. Verizon’s 2026 Data Breach Investigations Report reads a set of 858,440 data loss prevention events aimed at generative AI tools, and the most commonly submitted data type in it is source code, ahead of images and other structured data by a significant margin. The same report puts regular AI use on corporate devices at 45% of employees against 15% a year earlier, with regular defined as reaching a platform at least once every fifteen days, and has roughly two thirds of those users arriving through a non-corporate account. Shadow AI is the third most common non-malicious insider action in that data set, up around fourfold, and Verizon is open that part of the jump is a change in how it counted, which is the right way to read it: the direction is the finding and the multiple is not. PagerDuty’s April 2026 survey of 1,250 office professionals at large companies found 66% had used AI tools they believed were not permitted and more than a third had put customer data into a public model, which says this is how the whole workforce behaves rather than something about engineers. Read the three together and it is not an insider threat: the content moving is the thing you sell, the person moving it is neither malicious nor hiding, and the account is personal. That last clause is what decides the response, and it is why this is a different question from what your security team wants to know about a tool you are buying. An enterprise tier gets you a retention window, a training exclusion, a processing region and somebody to call, and those settings can be committed as configuration so a change to any of them arrives as a diff. None of it reaches a personal login on a work laptop. On that path there is no retention window, no log you can read, no region, and no deletion request anybody can make on your behalf. The unit that gets pasted makes it worse than it sounds, because almost nobody pastes one tidy function: they paste the file, usually with its imports, and eventually a configuration file, at which point the exposure is a credential rather than a design and the only remedy is rotation by somebody who does not know they need to rotate anything. So be honest about which half of this is engineering. Not the laptop. We run nothing on your endpoints, we do not monitor your people, we do not scan your network, and a data loss prevention programme is a different purchase from a different vendor, which we would rather say before you ask. What you own completely is the other end, because whatever was produced on whatever path still has to arrive in your repository as a change, and the merge is a control point you already have and already staff. Four things belong there and the order is deliberate. Secret detection that fails the run rather than opening a ticket, because a credential in a diff is a rotation and not a finding, and the same scan pointed at your history tells you which keys are already reachable by anyone who has ever held a clone. Provenance recorded at merge, who authored, who reviewed and which guards produced the pass, because authorship detection does not work and is not going to start, so the only record you can defend is the one you wrote down rather than a verdict you bought. Licence and dependency checks on whatever the change introduces, since a block that came back from a chat window arrives carrying a history nobody chose. And the ordinary guard set deciding mergeability before a human is asked, which is what makes the first three affordable to run on every change instead of on the ones somebody found suspicious. Then the part that actually ends the behaviour, and it is not a policy. People take the fast path. If the sanctioned route is a licence request, a training video and a wait, and the unsanctioned route is a window that answers now, the policy loses on arithmetic every week. What makes the approved path slow is almost never the tool, it is the queue behind it: a sanctioned agent whose output then sits three days in review has saved nobody an hour, and that is the week a careful engineer starts getting answers somewhere else and pasting them in by hand, which is the version of this with no trace at all. So the thing that retires shadow code assistance is a pipeline that merges. Committed context so the agent’s first attempt already fits your codebase, guards that decide mergeability without a senior’s attention, pipeline capacity engineered for the volume, and human review reserved for whether this is the right change. Approve a tool and make it the fastest way to get work merged and the question stops being asked. Ban it and the same activity continues on a path where nothing is logged. Two limits, and the first one is not comfortable. Nothing here recovers what has already left, so treat the unapproved period as having happened: that means a rotation pass over whatever is reachable from the repository, and a short, explicit decision about which repositories do not go into any agent context at all rather than a hope that nobody pasted them. And a gate is engineering rather than compliance. We build and operate it inside your own repository and your own CI and it produces the evidence your next governance review will ask for, and we are not auditors, we certify nobody, we do not write your acceptable use policy and we are not your counsel. ### We got a model retirement notice and nobody can tell me what in our pipeline breaks. How do we stop this being a fire drill every quarter? Nobody can tell you because the inventory does not exist, and that is the finding rather than the inconvenience. Your product’s model sits in a configuration somebody owns and reviews. Your delivery system’s models sit in a dozen places nobody ever listed: the review agent in CI, the judge behind an eval gate, the test and fixture generators, the triage and summariser bots on the repository, the codemod runner, the context compiler that keeps AGENTS.md true, and one IDE configuration per engineer that was never anybody’s artifact. Each of those carries a model identifier, most of them outside the repository, and the notice went to whoever created the API key. Start with what the vendors publish, because the cadence is documented rather than mysterious. Anthropic’s deprecation page defines four lifecycle states, active, legacy, deprecated and retired, assigns a retirement date when a model is deprecated, commits to at least 60 days of notice before retiring a publicly released model, and says plainly that requests to a retired model fail. Its own table currently has Claude Sonnet 4.5 deprecated on 30 September 2026 with a retirement date of 30 November 2026, which is the shape of the window you actually get. Two details on that page cost more than any of the dates. The first is that those dates apply to the vendor-operated platforms and that partner-operated platforms set their own schedules, which the Google Cloud page repeats in one sentence: lifecycle dates on partner-operated platforms are set by the partner and can differ from the first-party schedule. A retirement date is therefore a property of a pair, the model and the platform you reach it through, so the date in your runbook may be the one for the platform you are not calling. The second is that a parameter can be retired while the model stays exactly where it is. The sampling parameters temperature, top_p and top_k now return a 400 on Claude 4.7 and later models when set to a non-default value, and the Python SDK removed them outright at 1.0, so the same call raises a TypeError before it reaches the network. A pinned model identifier does not protect you from that, because the break arrives in a library bump rather than on a retirement date. Then look at what the platform does when the date passes, because it is not one behaviour and the difference is yours to choose. Microsoft’s Foundry documentation describes three upgrade policies on a deployment. Auto-update to default moves your deployment within two weeks of the default version changing. Once current version expires holds your version until the retirement date and then moves you to the current default. No auto-upgrade stops working at the date, and a retired version answers inference requests with 410 Gone. Microsoft gives at least two weeks of notice before a new version becomes the default. Read the three side by side, because they are three different incidents: on one setting the thing underneath you changes by itself, on another it fails loudly on a date you can diary, and which one each deployment has is a setting somebody picked once, usually while clicking through a wizard. Now the part that belongs to a delivery system rather than to a product, and it is why this is a different answer from the one on our Frontend AI page, which is about a product surface your customers are looking at. When a product’s model moves, a customer sees it. When the model behind a guard moves, nothing visible happens at all. A judge that has become more permissive produces a pipeline that reads healthier than it was: fewer rejections, faster merges, every graph pointing the right way. You cannot see that in a greener dashboard, and the thresholds that made the gate mean anything were calibrated against a model that is no longer answering. So the failure is not an outage, it is your evidence quietly changing its mind, and it surfaces in the week somebody cites that evidence in a release sign-off, a performance review or a governance questionnaire. Four things go in, and none of them is a model-ops platform. An inventory that is generated rather than remembered, covering every model identifier the delivery system calls, read out of the repository, the workflow files, the bot configuration and the provider’s own usage export broken down by key and model, because the identifiers outside the repository are the ones that bite. Identifiers pinned explicitly and in one place, a dated snapshot rather than a moving alias, so a change of model is a diff with a reviewer on it instead of a Tuesday somebody else chose. The eval set promoted to the gate on a swap, because a model change is a change to a guard: the candidate re-runs the calibration set the thresholds came from, the pipeline fails on a disagreement, and the swap then happens when you have evidence rather than when the notice period runs out. And the dates carried in the repository as dated artifacts with an owner per model and platform pair, so 60 days of notice reaches a person whose job it is rather than an inbox, and the check runs on a schedule instead of on somebody’s memory. Two things are deliberately missing from that list. There is no automatic fallback to a different model behind a guard, because a gate that silently changes judges is worse than a gate that stops: the correct degraded behaviour when a judge is gone is to fail the run and ask a person, which is loud, cheap and honest. And there is no attempt to keep a retired model alive. The swap is not avoidable and was never the problem. The frequency is, which is why the work is aimed at making the next one cost an afternoon. Two honest limits. An eval set makes a swap decidable and never makes it risk-free: a real capability change can move a guard’s behaviour in a direction your calibration set does not cover, and the remedy for that is re-calibration rather than confidence. And this is engineering inside your pipeline. We build and operate the inventory, the pinning and the eval gate on your CI and your conventions, we do not resell inference, we are not a model-ops or evals vendor, we do not run your gateway, and we do not pick your models. That choice stays yours, and the entire point of the work is that it stays cheap to change. ### Before we expand the rollout I have to tell the board how much faster this makes us. What is the honest ceiling? Not a number, and the reason is arithmetic rather than modesty. The ceiling on this is set by the share of the week that was ever writing code, and that share is smaller than almost every rollout plan assumes. The best firm-level measurement of it is Chen and Stratton’s Harvard working paper, Artificial Intelligence in the Firm: Bottlenecks in Software Production, dated August 2026, which reads around 300 million work events across 718 firms out of an engineering analytics platform, joining repository activity, issue trackers and calendars, and identifies the effect through a staggered difference-in-differences on when each firm adopted. Its finding is the one your rollout is about to run into: both assistants and agents raise coding productivity, and those gains do not fully pass through to software output or to employment. For agents the authors attribute the shortfall to a code review bottleneck, with review times rising, a larger share of changes needing revision and reviews drawing more comments, and they find firms reallocating labour towards review. Then the number that makes the ceiling calculable, and the paper measures it twice by different methods. A survey of 100 engineers on how a typical week actually goes puts writing code at 30% to 40% of it. The platform telemetry in the same paper puts it at 42%. Both are well under half, and the rest of the week is the work nobody demos: review, planning, waiting on an environment, reproducing a bug, deciding what the change should be. Now do the arithmetic, which is arithmetic and not a finding. Take 35% as the writing share and make writing twice as fast: the week gets about 17% shorter. Make it instant, which no tool does, and the week gets 35% shorter. On the 42% figure it is 21% and 42%. That is the entire prize from the authoring half, with everything else held still, and it is why a team that genuinely tripled its code output can watch the roadmap not move: you bought a large improvement in a minority of the work. The second-order effect is worse than the ceiling and it is the part the paper measured rather than assumed. The half you sped up feeds the half you did not. More changes arriving at an unchanged review process is a longer queue, not a faster line, and the queue is staffed by the few people who can also do the architecture, the incident work and the mentoring, which is how two quarters pass with nothing structural shipped and everybody busy. So the useful consequence is a reordering rather than a disappointment. If writing is a third of the week, the prize lives in the other two thirds, and that is engineering work with a specific shape. Guards that decide mergeability before a human is asked, so the review that still reaches a person is the judgement only a person can make rather than a token that should have been a variable. Context and conventions committed to the repository, so the first attempt lands closer and the revision round the paper measures never happens. Changes shaped and bounded with written acceptance criteria, because a sprawling change is unreviewable whoever wrote it. Pipeline capacity engineered for the new volume, because a six-minute wait repeated across a day is a working week nobody books. And the environment and preview path made self-service, since waiting for one is the single most common entry in the non-writing two thirds. Three honest limits. This is a working paper rather than a peer-reviewed result and the design is observational, so read the direction as the finding and not the decimal point. The arithmetic above is an upper bound on one half of the work and it is not a forecast for your company: the only number worth repeating to a board is one measured on your own repository against a baseline taken before anything was installed, which is what the audit stage exists to produce and the one thing that cannot be reconstructed later. And we do not certify a return on anything. We build and operate the instrumentation and the guards inside your pipeline, the series it produces is yours to read and publish, and we are not your auditors. ### Once PMs, designers and marketing are merging Frontend changes, who owns that code afterwards, and who is accountable when it breaks? The team that owns the surface, decided at merge time and written in the repository, and if the answer is “whoever merged it” the factory quietly stops working within a quarter. This is the one question where the research cuts against the careless reading of what we sell, so take it in that order. Ownership is measurable and it predicts defects. The strongest industrial study of it is Bird, Nagappan, Murphy, Gall and Devanbu, Don’t Touch My Code! Examining the Effects of Ownership on Software Quality, published at ESEC/FSE in September 2011 out of Microsoft Research, the University of Zurich and UC Davis, which examined Windows Vista and Windows 7. It defines ownership as the share of a component’s commits made by one contributor, and a minor contributor as someone whose ownership of that component is below 5%. The finding is the count rather than the share. The number of minor contributors correlated with pre-release failures at 0.86 in Vista and 0.93 in Windows 7, higher in both releases than size, churn or complexity, which are the three metrics defect models are usually built on. Added to a model that already contained size, churn and complexity, it raised the variance explained in pre-release failures from 26% to 46% in Vista and from 24% to 70% in Windows 7. Ownership by the top owner went the other way, associated with fewer failures. Every correlation in that table is statistically significant except top-owner ownership against post-release failures in Windows 7, and the threshold is not a knob: a sensitivity analysis from 2% to 10% gave the same results. The paper also found why minor contributions happen, and it is the sentence that matters most here. When a component has a minor contributor, that same developer is a major contributor to a component it depends on roughly half the time, 52% against 32% in a randomized model that preserved how much each developer contributed. The typical low-ownership change is not a tourist. It is somebody crossing a boundary to finish their own work, which is the backend engineer in your Frontend, exactly, and it is going to happen whether or not anybody installs anything. Now read our own claim against that. Everyone in your org ships production Frontend, implemented carelessly, is a programme for manufacturing minor contributors at industrial scale, which is the precise condition that paper says predicts failures, and we are not going to pretend otherwise. What makes it work is that the authors also wrote down what to do about it, and their three recommendations are three of the things a factory installs. Changes by a minor contributor should be reviewed with more scrutiny, by a major contributor where possible: that is unbuildable by hand once everyone ships, because the major contributor becomes the queue we were hired to remove, so the scrutiny attaches to the change rather than to the person and runs before a human is asked, and what survives the guards is routed to the team that owns the surface instead of to whoever is free. A would-be minor contributor should communicate the change to someone experienced with that code rather than making it directly: that is what written acceptance criteria are for, and it is the part non-engineers are usually better at than the diff, since a reviewable specification of what should change is a real contribution and the agent plus the guards are what turn it into code the owning team recognises. And components with low ownership should get priority from quality-control resources, which is the honest answer to what happens to your QA people and it is not that they disappear: ownership becomes an input to where the expensive checks point, so the surfaces with many low-ownership contributors get the characterization tests and the visual baselines rather than spreading the same thin coverage evenly across everything. Then accountability itself, which is an organisational answer and not a tooling one, in three rules. Ownership of a surface does not transfer to whoever merged the last change to it, so the paging path, the error budget and the decision to roll back stay with the owning team, and that lives in the repository as code owners rather than in a rota nobody edits. The owning team’s approval is what the change needs, which is what stops a non-engineer routing around the owner by being faster. And the person who merged is accountable for having followed the path rather than for the incident, because an organisation that answers this question by naming the marketer who shipped the landing page gets exactly one volunteer and then none. Three limits, because this oversells easily. The paper is from 2011 and it is Windows, and the authors say plainly that Microsoft practiced strong ownership and that their results are most likely to hold where similar policies are already in place, so it is the direction of a well-controlled industrial result and not a coefficient for your repository. It measures a world with no coding agents in it, and an agent is a contributor with zero ownership of everything it touches, which is the same variable pushed further rather than a new one. And none of this is a legal or an insurance answer: who carries liability for an outage is a question for your counsel and your contracts, not for us. What we do with it is write the map before anything is installed. The audit stage produces the owner of record for every Frontend surface, the paging path that follows it, and the current distribution of contributors per surface, which is a measurement your repository can already answer and almost nobody has looked at. That is the artifact that cannot be reconstructed during an incident. We install and operate the guards, the routing and the ownership map inside your pipeline. We are not your QA vendor, we do not staff your on-call rotation, and we are not your auditors. ### Is the browser agent standard actually becoming a standard, and what happens to our work if it is not? Not yet, and the document that would settle it has not settled the central question either, so the honest way to price this work is as a capability layer with a replaceable adapter rather than as a bet on a standard. Here is the state of it on 21 October 2026, read from the specification and the charter themselves rather than from the announcements. WebMCP, the API that lets your own pages register callable tools for an agent, is a Community Group draft. Its own metadata says CG-DRAFT in the W3C Web Machine Learning Community Group, it is edited by four people from Microsoft and Google, and the interface it defines is document.modelContext on Document, marked SecureContext so it is HTTPS only, with registerTool, getTools, executeTool and a toolchange event. If you have read that the surface is window.agent or navigator.modelContext, that is an older draft being quoted: the specification repository was last edited on 20 October 2026 and the normative interface in it is on document. A Working Group is proposed and has not been formed. The draft charter for an Agentic Web Working Group was first committed to the W3C charter-drafts repository on 28 September 2026 and last edited on 13 October 2026, and it names WebMCP as its single normative deliverable, to be adopted from the Community Group. Its start date, its end date, its chairs, its team contact and WebMCP’s expected completion are all still unfilled template placeholders, and the charter defines the start date as the date of the Call for Participation when the charter is approved, so the empty field is the status: proposed, not chartered. And the question a buyer actually asks, whether this ends as a W3C Recommendation, is not answered by that document, because the document has not chosen. The sentence about the end state sits inside a to-do marker under a literal “Choose one”, and the clauses for both branches of that decision are still in the file. Anyone telling you the destination is a Recommendation, or confidently that it is not, is reading a template option as a decision. Then the part that decides whether you can actually ship it, which is not the charter at all. Two of the four browser engines have no implementation. Chrome has an origin trial from version 149 and Edge one from version 150. Firefox has a Mozilla standards-positions issue and a Bugzilla entry, Safari has a WebKit standards-positions issue, and neither of those is an implementation. Outside the browsers the picture is real but narrow: ChatGPT Desktop supports it, Brave has it experimentally in Leo, and Meta’s Ray-Ban Display is listed as coming soon, off by default and enabled per device. An origin trial is a temporary, token-gated experiment rather than a shipped feature, and the ordinary bar for a specification to advance is two independent interoperable implementations verified by an open test suite. The specification does declare a Web Platform Tests suite, and watching that is a better signal than any partner list. Now the most useful thing in the charter, which is the half nobody quotes, because it is the half that is filled in. The out-of-scope list is explicit, and it is six things the group says it will not address: model APIs, inference and execution; cryptographic authentication primitives; crawler controls; agent to server communications; content provenance and disclosures; and bot detection. Read that against what teams assume when they hear the web is being standardized for agents. Telling a crawler apart from an agent, deciding which agents may reach you at all, proving what your site actually published, and declaring that a response was machine-generated are not coming from this group. Those stay yours, and in practice they live in your edge configuration, your own policy and your own Frontend. What is in scope is narrower and worth knowing, because it is what you will eventually get: describing site capabilities and relevant context for agents, representing agent identity, delegation and interaction context, transparency about the interaction including status and lifecycle, expressing permissions, policies and constraints on agent actions, and guidance for web authors. One more thing from the specification, because it changes your threat model rather than your roadmap. Its security section, which is explicitly non-normative, states as a baseline assumption that agents inherit user identity and authentication context from the browser, so an agent visiting your site carries your user’s logged-in credentials and session state. It offers three advisory annotations, a read-only hint, a consequential hint and an untrusted-content hint, and then says plainly that a malicious site can omit or misrepresent them, and that preventing an agent from being manipulated is primarily the responsibility of the agent’s own security model rather than something the specification can normatively enforce. So the hints are a courtesy you extend to a well-behaved agent, not a control that protects you, and your authorization has to assume the caller is your signed-in user, because as far as your backend is concerned it is. What all of this means for how we build it is the same layering argument we make about every protocol revision, and it is the reason the uncertainty above is survivable. The tool surface is an adapter and never the implementation. The tool an agent calls runs the same typed function your own button calls, so validation, permissions, telemetry and audit are inherited rather than written a second time, and the registration code that names document.modelContext is a few dozen lines at the edge of your application. If the API is renamed again, if the origin trial lapses, if the Working Group is never chartered, or if something else wins, you replace the adapter and keep the capability layer, which is where the work actually was. Ship it behind capability detection as an additive path rather than the only way to do anything, and keep a human in every irreversible action with the real parameters rendered instead of a summary. Three limits. All of the above is the state of two documents on 21 October 2026, and one of them was edited the day before, so re-read them rather than repeat this. A draft charter is a proposal, and proposals change, including the scope lists quoted here. And we do not speak for the specification or for any Working Group, we are not a browser vendor, we are not your security auditor and we certify nobody. We build the capability layer, the adapter and the gates inside your product. ### We gate on code coverage and it sits in the eighties. Now that people outside the Frontend team are merging, is that still the gate? No, and the reason is mechanical rather than cultural, which matters because the fix is a configuration change and not a culture programme. A coverage number answers exactly one question: while the suite ran, did this line execute. The question your gate exists to answer is a different one, whether anything would have failed if this line were wrong, and no coverage tool computes it. The clearest proof is in the file formats rather than in anybody’s opinion. The mutation testing report schema, the interchange format the JavaScript tools write, carries coveredBy and killedBy as two separate fields on every mutant: the tests that executed the changed code, and the tests that noticed it had changed. Its status enumeration has eight values, and two of them are the ones to read. NoCoverage means nothing ran it. Survived means something ran it, the behaviour was altered, and the whole suite stayed green. A coverage report cannot tell those apart because it only ever computed the first field, and StrykerJS says as much in its own configuration documentation, that per-test coverage analysis does not influence the resulting mutation testing score but does allow Stryker to distinguish between Survived and NoCoverage. Survived is the state that matters once agents write the tests, and it is precisely the state your eighties are silent about. Then the three ways that number rises without the suite improving, all of them documented defaults rather than anybody cheating. Nothing in a coverage report inspects what a test checks, so a test that renders a component, asserts that it did not throw and snapshots whatever came out is indistinguishable from a test that asserts the behaviour. The denominator is editable in the source, because a v8 ignore next or istanbul ignore comment removes code from the measurement and a v8 ignore file removes a file, each of them a legitimate tool and each of them a lever on the number. And the default gate is an aggregate rather than a file: in Vitest, coverage.thresholds.perFile defaults to false, so the thresholds are checked against the project-wide total, which means a repository at 82% absorbs a new file at nothing and stays green. That default is harmless while a dozen people who all know the codebase are committing. It is precisely wrong in the week a PM, a designer and two backend engineers start opening Frontend pull requests, because the aggregate is large and their change is small, and the gate you believe is protecting the change is in fact reporting on the repository. Two neighbouring defaults are worth knowing in the same breath. A glob-pattern threshold does not inherit the top-level perFile, so it has to be set on each glob explicitly or the narrow rule you wrote for a sensitive directory is quietly an aggregate too. And thresholds.autoUpdate rewrites the thresholds upward whenever coverage improves, which is a useful ratchet and also the reason that the number going up is not information. One piece of common advice is now stale: since Vitest 3.2.0 the default v8 provider remaps through the AST and its documentation states it produces reports identical to Istanbul, so switching providers for accuracy buys nothing, and the number you already have is as good as that number gets. Now the measurement that answers the real question, with its price, because this is where most write-ups of the subject stop. Mutation testing changes your code in small specific ways, one at a time, and runs the tests covering each change to see whether any of them fails. A killed mutant means your suite noticed. A survived mutant is a behaviour somebody can break silently today. The mutation score is the share killed, and the part nobody mentions is that installing the tool is not installing a gate: StrykerJS ships thresholds of high 80, low 60 and break null, and its documentation is explicit that break at null, the default, never lets your build fail. Somebody has to choose that number and sign their name to it. On a widening contributor set the number worth choosing is on the files the pull request changed rather than on the repository, because a repository-wide mutation score is both unaffordable and unactionable, and the change is the thing you are deciding about. Budget it honestly, because the cost is real and it is the reason this is usually skipped. Every mutant is a test run, so the wall clock is a multiple of your suite rather than a fraction of it. Concurrency defaults to one less than your core count. Each run is abandoned on a timeout computed as the net time multiplied by 1.5 plus five seconds plus overhead, a formula that exists because deciding whether a mutant loops forever is the halting problem. And incremental mode, which stores the previous result and reuses it, is off by default and is the whole difference between a nightly job and a check a pull request can wait for. Then the limits, which are what keeps this from becoming the next number nobody trusts. A mutation score is not a quality score. Some surviving mutants are not worth killing, because the mutated code is equivalent to the original or the behaviour genuinely does not matter, and a team told to drive the number to a round figure will write tests for those too. Static mutants, the ones that only execute while a file is being loaded, carry a large performance penalty and are sometimes impossible to measure at all, which is why an ignoreStatic switch exists and why using it requires per-test coverage analysis. StrykerJS inserts its mutants by disabling type checking, adding a ts-nocheck and stripping your other TypeScript directives, so what runs under mutation is not type-checked code, and anything your types were already preventing is not what this measures. The weaker number has an error bar of its own: the V8 coverage remapper documents its blind spots, including that it cannot detect an uncovered assignment pattern when the line is otherwise covered, and that code after a throwing call is reported as covered although it never runs. One figure you will meet in nearly every write-up of this subject should not be repeated, by you or by us. The claim that test suites with full coverage caught only 4% of injected bugs circulates with no study attached, and at least one of the places repeating it is presenting it as a worked illustration of the formula rather than as a result. The peer-reviewed literature on how weakly coverage correlates with a suite’s ability to find faults does exist and is worth reading, and it could not be opened from where this answer was researched, so there are no magnitudes here and there should be none in the version you repeat internally either. So the practical shape is a reordering rather than a new tool. Coverage stays, demoted to the job it is genuinely good at, which is finding code that nothing has ever executed. The gate on a change authored by somebody who does not own the surface asserts behaviour instead: mutation score on the changed files against a break value a named human chose, assertion quality on changed lines, and a snapshot never accepted in the same run that changed the component it depicts. That sits inside the test-quality gate we already run rather than beside it, and it is the measurement behind a sentence we have been making for a year, that we gate on whether a test can fail rather than on how many there are. Every default quoted above is the state of these tools on 23 October 2026, read from their own documentation, and defaults move, so read the version you install rather than this paragraph. We build and operate the gate inside your pipeline, we drive the tools you already own rather than replacing them, and we are not your QA vendor and we do not sell test headcount. ### Our architects want to split the Frontend into independently deployable micro-frontends so every team can ship without breaking the others. Is that the boundary we need? Rarely, and almost never for the reason it is usually proposed, because the isolation an independent deployment boundary buys is not the isolation you asked for. What you want is that a change from marketing cannot break checkout. That is a merge-time property and a pipeline can enforce it. A deployment boundary enforces nothing of the kind: it moves the integration out of CI, where a guard can hold a change, and into the browser of whoever loads the page next, where no guard runs. The mechanism is in the tools’ own documentation rather than in anybody’s architecture opinion, and the defaults are the part worth reading. In Module Federation a shared dependency is negotiated at runtime, and singleton is false by default, so two copies of the same library on one page is the documented normal case rather than an error state. Turn singleton on and a version mismatch still does not fail: the documentation says the higher version is loaded and the party with the lower version gets a warning, which means a remote built and tested against one version of your design system runs against a different one in production and the only notice is a console line nobody is reading. requiredVersion defaults to whatever that build’s own package.json declares, and the resolution rule is that a consumer gets the highest version in the scope that satisfies its range, which the documentation presents as the feature that lets two builds needing different majors coexist. Set requiredVersion on one side and singleton on the other and the requiredVersion copy wins regardless of version. Register the same version from two builds and the tie is broken by comparing output.uniqueName, and an already-loaded version is never replaced, so load order decides which copy a user gets. The configuration traps are quieter still. The negotiation key is the property name unless shareKey says otherwise, so a mismatch between the two sides is not an error, it is each side silently bundling its own copy. And a shared entry written as react-dom rather than react-dom with a trailing slash intercepts only the bare import, so react-dom/client is never shared at all; the documentation’s own warning for that one is a second copy of React DOM and hydration errors, and React’s documentation states the rule underneath it, that the react your code imports has to resolve to the same module as the react inside react-dom or hooks break. None of that is a build failure anywhere. Several pipelines go green and the composition fails on a user’s first paint. There is a shape where the split is honest, and it is narrower than the proposal usually is: a genuinely separate product under the same domain, with its own cadence, its own team and often its own framework, where almost nobody crosses between the two inside a session. Then a path-aligned zone is the right tool and you take its cost deliberately, because Next.js documents the seam as a hard navigation that unloads the current page’s resources and loads the new ones, and its own advice is that pages frequently visited together belong in the same zone. One asset prefix per zone, one named owner for the shared layer, and the seam placed where a full page load is already acceptable. Everywhere else the thing that lets people outside the Frontend team ship is the guard set at merge, and that is where the architecture budget goes. Reported: how many copies of each shared dependency a production page actually loads, and the version spread across surfaces, both measured from the built output rather than from a lockfile. Limits: this is a judgement about boundaries rather than a refusal to split anything, an existing federated setup is not something we would remove on principle, and no guard set repairs a shared layer that nobody owns. Every default above is the state of these tools on 24 October 2026, read from their own documentation, and defaults move, so read the versions you install rather than this paragraph. We work inside your architecture, in your repositories and your CI. We do not sell an architecture migration and we do not run your deployments. ### Marketing and our PMs are merging pages now. What stops one of them quietly destroying our organic search traffic? Nothing you run today, and it is a configuration gap rather than a trust problem. Look at what actually carries a page’s discoverability: the URL itself, the internal links pointing at it, one canonical link element, a robots meta tag, a title and a description. Every one of those is a declaration with no consumer inside your repository. Delete the canonical and the page renders. Rename the route and the build passes. Leave a noindex behind from a staging preview and every check is green, because the only reader of that line is a crawler that has not arrived yet, and the consequence lands weeks later in a console nobody in the pull request can open. It is the same shape as broken analytics, and it breaks under exactly the operations a coding agent produces most of: renaming a route, extracting a component, folding two layouts into one, regenerating a template from a newer design. All behaviour-preserving, all green, all shipped by somebody who had no way to know. Then the part most teams get wrong, which is believing they already check this because they run Lighthouse. Its SEO category is worth running, so here is what it decides, read from its own configuration rather than from a blog post. Ten audits carry a score. One of them, is-crawlable, carries a weight of 93 over 23 with a comment in the source explaining why: the weight has to be at least 31% of the category so that failing this one audit fails the category. The other nine weigh one point each. That arithmetic is the whole character of the number. A page blocked from indexing scores about 69, which is loud enough that somebody notices. A page whose canonical points at the wrong URL scores about 92, which is a green dashboard with your canonical broken. And three of the checks cannot fail for the thing teams assume they cover. The canonical audit returns not-applicable when there is no canonical at all, so it fails a wrong one and is silent about a missing one. The robots.txt audit does the same when the file returns a 4xx or comes back empty. Both the canonical and the hreflang audit ignore any link element whose source is the document body, so a canonical injected by a script is invisible to the audit, and invisible for a second reason to every retrieval bot that does not execute JavaScript. The crawlable-anchors audit fails an anchor with an empty href, a javascript:void(0) and a click handler with no href at all, and then skips the element entirely if it carries any role attribute, so role="button" turns that failure green and leaves the link uncrawlable. The meta-description audit fails only when the tag is absent or empty after trimming, never on what it says. And the link-text audit matches a fixed list of phrases: click here, here, learn more, more, more info, read more, see more. Which is to say it fails on the words a coding agent writes by default when nobody told it the destination. So the score is a report, and what you need is a gate. The mechanics are small and they are already in your pipeline if you budget performance. Lighthouse CI asserts any audit by its id in an eslint-shaped config, a level and options, off or warn or error, with defaults of optimistic aggregation and a minimum score of 1. One trap in it matters more than the rest: an audit that does not appear in your assertions object is treated as off. A hand-written block of five SEO assertions therefore switches off everything you did not list, which is why the gate extends a preset instead of starting from an empty object. Per-route rules go in the assertion matrix with a matching URL pattern, because the rules for a checkout flow are not the rules for a blog post. Category assertions exist as well, keyed on the category rather than an audit, and they check only the score, so they never substitute for asserting the audits you actually care about. Now the half no page-level audit can see, which is the half with the revenue attached. Lighthouse runs against the URLs you hand it, so it cannot tell you that a URL stopped existing, that twelve internal links now resolve to nothing, or that the page your campaign points at redirects twice before it answers. Those are repository facts, so they belong in the diff that caused them. The guard is an inventory rather than a crawl. The build enumerates every public route, every canonical and every internal link, and the check compares that inventory against the base branch. A route that disappears or changes shape fails the run unless the same change adds a redirect for the old one. An internal link that resolves to nothing fails. A canonical that does not point at the route it sits on fails, which is the presence check the audit declines to make. A route carrying a noindex while sitting in the sitemap fails, and so does the reverse. The routes that matter commercially get their title, their description and their one-per-page canonical asserted as ordinary tests, so those facts live beside the code that renders them rather than in a spreadsheet somebody maintains. Two things make it stick rather than get switched off in a month. It is ratcheted onto the routes a change touches, so a site carrying years of redirect debt does not go red on day one, it stops getting worse while the debt is worked down deliberately. And the same rules go into the context and the skills the agent reads before it writes, so the common case is that the generated page arrives with its canonical, its description and its redirect already correct and the guard never fires. The limits, plainly, because this is the part that gets oversold. A green gate is not a ranking: it asserts that the declarations are intact and it cannot tell you whether the page deserves to rank. A redirect preserves the address and not the position. The outcome is measured off your pipeline, in Search Console and in your analytics, with weeks of lag, so the gate protects the inputs and the reporting stays where it already is. And the inventory can only see the links inside your repository, so a route reachable only from a campaign tool or a tag manager is outside it by construction, which is an argument for the tag surface having a gate of its own. The second audience gets the same benefit from the same work, and that is the reason this is not purely a marketing concern. An answer engine that cannot fetch a URL cannot cite it, and a 404 sitting behind a citation somebody earned is a lost mention rather than a lost click. This is not an eighth guard. It rides inside the performance budget guard, which is the one already driving Lighthouse on your routes, and the per-route assertions live next to the budgets. Keep it apart from its neighbours: whether your content is in the HTML at all is a rendering question about what your product publishes, the agentic-browsing audit is about whether an agent can operate the page, the third-party script gate is about the tag surface, and the instrumentation gate is about the events your dashboards read. Every default quoted above is the state of these tools on 26 October 2026, read from their own repositories, and defaults move, so read the version you install rather than this paragraph. We build and operate the gate inside your pipeline and we fix the code it stops. We are not an SEO agency: we do not write your content, we do not do keyword research and we do not do link building. ### Marketing wants to A/B test the pages they are now merging. What actually breaks when the experiment ships from the Frontend? It is not the page that breaks, it is the number, and that distinction is the whole reason this is a Frontend problem rather than a marketing one. An experiment does not output a layout, it outputs a decision: ship it, kill it, roll it out to everyone. That decision is computed from events your client code fired, which means a defect here does not make anything look wrong. It makes the business wrong, quietly, with a chart standing behind it, and every check in your pipeline stays green. Four mechanisms produce that outcome and all four of them sit in code somebody now merges without a Frontend reviewer. The first is assignment. A percentage split is not random, it is pseudorandom: the OpenFeature specification calls it fractional evaluation and defines it as resolving a value from a context property, typically a targeting key, against a configured proportion. The specification also makes that key optional, and then says in the same requirement that providers may require it for fractional evaluation and may behave unpredictably if it is not specified at resolution. Unpredictably means the same visitor is not guaranteed the same variant twice, and a visitor who switches arms mid-funnel is counted in both and belongs in neither. In the browser this gets sharper, because a client-side SDK runs in what the specification calls the static-context paradigm, where context is global and the client and invocation must not supply their own. So the key you bucket on is a single global value, changing it re-resolves the flags underneath the user, and the specification adds a provider state called reconciling for exactly that window. The ordinary case that triggers it is a visitor signing in, which is to say the moment in the funnel you care most about. The second is exposure, and this is where most front-end experiments actually die. The arm the user saw has to be recorded before the user leaves, and on a redirect test the leaving is the test. Read the defaults in the SDK rather than the marketing page: GrowthBook delays navigation 100 milliseconds to let the tracking call finish, caps that wait at 1000 milliseconds, and then navigates anyway, and its own documentation says that missed tracking calls are generally the largest contributor to sample ratio mismatch. Sample ratio mismatch is the result arriving as something other than the split you configured, a 46/54 against a 50/50, which GrowthBook surfaces at a p-value below 0.001 by default, meaning it is not chance. The mechanism is asymmetric and that is what makes it poisonous: the control is already on the page, the variant is one navigation away, so the exposures you lose are mostly the variant’s. Your winner looks small and your sample looks clean. The vendor’s own recommended fix is not a tuning parameter, it is to move the assignment off the browser and onto the edge or the server, and the serious intermediate step is a tracking callback that genuinely awaits its network request rather than firing and hoping. The third is flicker, and it is not a cosmetic complaint. A client-side experiment paints the control, then replaces it, so the standard mitigation is to hide the page until the SDK has decided. That mechanism is off by default in the one SDK that has it, it blanks the screen for up to 3500 milliseconds, and the documented manual version is a style rule setting opacity to zero on the html element plus a timer that removes it after three seconds in case the SDK never loads. Now read the Largest Contentful Paint specification against that. An element is reported only at the first paint where it is paintable, which the specification defines as having opacity and visibility, and text with an opacity of zero is skipped outright. So the anti-flicker fix does not delay your LCP measurement, it suppresses the candidate until the class comes off, and your real content is timed from whenever that happens. Worse, the algorithm stops accepting candidates once a scroll or an input event has been dispatched, so a visitor who taps or scrolls during your blank screen never produces a candidate for the content they came for at all. And the flicker you were hiding has its own bias: the vendor’s documentation says it degrades the experience in a way that may skew results toward the control, which means an unfixed Frontend bug systematically votes for doing nothing. The fourth is reconciliation, and it explains the specific complaint that the experiment tool and the analytics dashboard disagree. Two details in the specification do most of it. The context merged into an evaluation runs API, then transaction, then client, then invocation, then before hooks at the highest precedence, so a hook can legitimately change the context that chooses the variant. The context merged into a tracking call runs the same order and stops at invocation. The hooks are not in it. The context that decided the arm is therefore not guaranteed to be the context attached to the conversion, and nothing errors. Then the attribution itself is optional by design. Variant and reason are optional fields, the specification describes resolution metadata as best effort, and it notes that on an unsuccessful evaluation the error fields are set and the variant is not. A provider outage does not fail your page, it returns the default, which is your control, for everybody, and that is indistinguishable from a real result unless you recorded why each value resolved. The reasons that distinguish them exist and are named in the specification: split for a pseudorandom assignment, cached for a value from a cache, stale for one the provider admits may be out of date, default, targeting match, error. The observability convention makes the variant conditionally required on the event and the reason only recommended, so the field that tells you whether the number means anything is the field most integrations drop. One more thing belongs in the same paragraph as the specification, because it is a maturity claim and those get stale: as of 27 October 2026 the OpenFeature specification is at 0.9.0, its flag evaluation and provider sections are marked stable, evaluation context is hardening, and tracking is marked experimental, which in that project’s own words means breaking changes without deprecation notices and a recommendation not to use it in production. The half you evaluate with is stable and the half you measure with is not, and no vendor slide will tell you that. So the guard. The experiment is a declaration in your repository, the same shape as a canonical or an analytics event, and it gets the same treatment: assignment asserted to come from a stable key rather than a value that changes within a session, the exposure asserted to be awaited before any navigation the same change introduces, variant and resolution reason both carried on the exposure event so a defaulted evaluation is visible as an outage rather than averaged into a result, and every experiment carrying an expiry at the moment it is created, because a flag that outlives its decision is a branch nobody owns and a permanent tax on every render path through it. The markup assertions you already have keep applying: one canonical per variant, and no branch that depends on who is asking. Two things make it survive. It rides inside guards you already run, the instrumentation gate for the events and the performance budget for the paint, rather than arriving as a new one. And the same rules go into the context the agent reads before it writes, so the generated variant arrives with a stable key and an awaited exposure and the guard never fires. The limits, plainly. A green gate means the measurement is trustworthy, not that the result is interesting or that the test was worth running. It cannot tell you your sample is large enough, your metric is the right one, or your hypothesis was sound. Every default above is that tool on 27 October 2026, read from its own repository, and defaults move, so read the version you install. Keep it apart from its neighbours: adapting the product per user is a product capability and an outward build, the tag surface is what marketing ships without a pull request at all, the instrumentation gate is whether the events exist and are correct, the discoverability guard is the declarations that carry a page’s organic value, and a render matrix is about themes and viewports rather than arms of a test. We build and operate the gate and we fix the code it stops. We are not a growth agency: we do not design your experiments, choose your metrics, or run your statistics. ### Should we just give marketing a CMS instead of letting them open pull requests? Use a CMS. The part worth arguing about is where the boundary goes, because a content management system looks like it takes risk away from engineering and what it actually does is move the change onto the one delivery path in your company that has no pipeline on it. Everything a factory installs runs at merge: the type check, the tests, the visual regression, the accessibility assertions, the discoverability assertions, the review. A content field runs at publish, and publish has no merge. So the question is not whether editors should edit. It is which fields can reach production with no check on them at all, and in most codebases the answer is more fields than anyone chose. Four mechanisms do the damage and not one of them surfaces as a failure. The first is that a rich text field is markup, which makes the field a code path. React escapes what you interpolate, which is exactly why a plain string field is genuinely safe. The moment the body has to render as authored HTML you reach for dangerouslySetInnerHTML, and React’s own reference is blunt about what that signs you up for: unless the markup comes from a completely trusted source, it says, it is trivial to introduce an XSS vulnerability this way. A CMS is not a completely trusted source. It is a source with editors, roles, API tokens, an import script and at least one integration. The usual answer is a sanitizer, and the sanitizer’s own documentation is more honest than most security vendors: DOMPurify needs a DOM, states plainly that running it on the server requires a DOM to be present, warns that tools like happy-dom exist but are not considered safe at this point, and describes its own behaviour where it cannot run as doing nothing at all and returning exactly the string you fed it. That is a security control that fails open and silently. The detail worth sitting with is that happy-dom is the default test environment in a large share of Vitest projects, so a passing sanitizer test may be passing in the environment the maintainers name as unsafe. Then the defaults, which are generous because they have to be: it permits HTML, SVG and MathML, allows CSS and HTML custom data attributes, and on URL attributes allows only http, https, ftp, ftps, tel, mailto, callto, sms, cid, xmpp and matrix, with the regex that widens that carrying the project’s own comment that the default is false, be careful, XSS risk. And a CMS is a template system, which walks you into the one mode the project tells you to stay out of: the setting that strips template expressions is documented with be careful please, this mode is not recommended for production usage, and with the flat statement that allowing template parsing in user-controlled HTML is not advised at all. The second is that publishing is a cache invalidation, and a cache invalidation is a distributed systems problem the editor does not know they have. Read the framework on its own incremental regeneration rather than a diagram. Invalidating a path invalidates the cache entries, and its own documentation adds that regeneration happens on the next request. The caveats are sharper: on-demand revalidation only invalidates the instance that receives the call, and when you run multiple instances the default file-system cache is per-instance. Your publish webhook arrives at one machine and the others keep serving yesterday. When regeneration throws, the documented behaviour is that the last successfully generated data continues to be served from the cache and the retry happens on the next subsequent request, so an endpoint that fails every time serves the old page indefinitely and raises nothing. Every one of those sentences describes correct behaviour. Together they produce a page that is live, correct in the CMS, wrong in the browser, green in every check you own, and the editor’s screen said published. The third is that a content model is a form rather than a schema, so the validation lives where the form lives. Strapi documents this against itself better than we could: the admin panel takes over a lot of the validation tasks, database-level uniqueness is enforced on published entries only, and then the case that gives the whole shape away, that duplicates therefore remain undetected until publication, at which point the database constraint triggers an error even though the interface had previously displayed the drafts as saved. The editor was told it saved. The constraint fired later, to somebody else. And the lifecycle hooks an engineer wrote to hold the model together are documented as not triggered when the knex library is used directly instead of the framework’s own functions, which is to say the one-off import script bypasses them. The publish is not a single event either: a single action in the admin panel can trigger more than one, publishing sends the update event just before the publish event, and the vendor’s reliability guidance is addressed to your side of the wire, telling you to implement retries for failed webhook requests to handle transient errors. That is the honest way of saying delivery was never guaranteed. The fourth is the one that costs money quietly, and it is the previous wave’s defect class moved onto a path with no pipeline. The fields that carry a page’s organic value are declarations whose only reader is a crawler that has not arrived yet: the title, the description, the canonical, the slug. Behind a merge gate they are asserted. As CMS fields they are text inputs with no validator, and a slug edit is a URL change shipped without its redirect, because a redirect is a repository concern and nobody showed one to the person renaming the page. Nothing 404s in staging either, because in staging the old slug is still the slug. One more that nobody budgets for: a string has no length. A type can say a field is a string and cannot say it fits. Your visual regression suite runs against fixtures committed in the repository, so it asserts the layout for the content that existed when the test was written and never for the headline an editor publishes on a Tuesday. A locale behaves the same way: adding one in the CMS creates the locale, not the translations, and the renderer’s fallback decides what the visitor actually reads. So yes to the CMS, with the boundary drawn by what a field can break rather than by who is editing it. Two classes, and they are easy to tell apart. Content that can only be wrong, which is body text in a slot with asserted bounds, an image with a required alt, one more card in a list, belongs in the CMS and should never need a deploy. Declarations that can break something no reviewer will see, which is anything that becomes markup, anything that becomes a URL or a cache key, a title or a canonical, a new locale, a new field type, an embed or a script, belong in the repository behind the gate, however much the person who wants to change them would prefer a text input. And the gate itself is a publish-time sibling of the ones you already run rather than a new department: the sanitizer asserted to be running by a test that fails when it no-ops instead of passing because the fixture was harmless, every slot asserted against its own longest and shortest permitted content instead of against its fixture, the organic declarations validated at the edit boundary with the same assertions the merge gate already makes, a slug change refused unless its redirect ships beside it, the invalidation treated as delivery with a reconciliation pass behind it rather than a webhook fired into the dark, and the content model committed as code so that a field type change is a reviewed diff and the migration for everything already published is written in the same change. The adoption mechanics are the usual two. It rides inside guards you already run, the security gate for the DOM sink and the discoverability guard for the declarations, rather than arriving as a new one. And the same rules go into the context the agent reads before it writes, so the field arrives bounded and sanitized and the guard never fires. The limits, plainly. A green gate means a published field cannot break the page or the declarations that carry it. It cannot tell you the copy is good, the offer is right, or that the page should exist. Every default above is that tool on 28 October 2026, read from its own repository, and defaults move, so read the version you install. Keep it apart from its neighbours: the tag surface is what marketing ships with no pull request and no content model at all, the discoverability guard is the declarations themselves, the localization guard is translation completeness, the deployment boundary question is about splitting the application rather than the content, and marking AI-generated text is about labelling what you publish rather than how it reaches production. We build and operate the gate and we fix the code it stops. We are not a content-ops vendor: we do not choose your CMS, run your editorial calendar, or staff your content team. ### You recommend A2UI for cross-platform generative UI. Is it actually safe to build on, and what do we own if it changes? Safe to build on if you build the right half of it, and the version you build on is not the highest number you will see quoted. Here is the state of the project on 2 November 2026, read from its own repository and package registries rather than from launch coverage. A2UI describes itself as an early stage public preview. Its current production release is v0.9.1, a patch release inside the stable v0.9 family. The v1.0 specification is a release candidate rather than a release, v0.8 is legacy, and the project says in as many words to expect changes. The gate on v1.0 is written in the specification directory itself: it becomes the stable 1.0 once a sufficient number of renderers have been ported to it and the feedback from that has been incorporated, with a high bar for breaking changes until then. Those ports are moving and the project has not declared the gate met. The Angular renderer’s package root carries the v1.0 basic catalog, the Flutter renderer documents v1.0 and v0.9, the Swift core supports v0.9.1 and v1.0, and the conformance suite has v1.0 adapter cases covering Lit, React, Angular, Flutter and SwiftUI. Against that, the React and Lit renderers still tell you in their own documentation to use v0.9 for new projects, and the project’s own v1.0 page still points production use at v0.9.1. So the honest reading is that v1.0 is where the protocol is going and v0.9.1 is what the project tells you to ship today, and anyone quoting v1.0 as the current version is quoting a candidate. Two more facts worth having before you commit. The name most coverage uses is out of date: the project’s documentation says A2UI was created by Google with contributions from CopilotKit and the open source community, and its home is now the a2ui-project organisation, with the old google path redirecting there. And agent SDKs now exist, young as they are. a2ui-agent-sdk for Python reached 0.10.0 on PyPI on 2 November 2026, @a2ui/agent for TypeScript reached 0.1.0 on npm the same day, and a2ui_agent for Dart is on pub.dev as a work-in-progress 0.0.1 version. The Python changelog records breaking changes between releases, so treat them as dependencies to pin rather than as settled interfaces. Now the part worth adopting whichever version number wins, because it is the architecture rather than the release. A2UI is a declarative data format and not executable code. Your client application keeps a catalog of trusted, pre-approved components, and the agent can only ask for components that are in it. The project’s own phrase for the property is safe like data, but expressive like code. The catalog is not a configuration file. It is your design system expressed as JSON Schema, and defining your own is what the project expects of a real product: most production applications define a catalog that reflects their design system, which restricts the agent to exactly the components and visual language that already exist in your application instead of generic inputs and buttons. On v0.9.1 every surface names its catalog when it is created. The v1.0 candidate makes the rule stricter, so plan for it now. Every component resolves through its own catalog id or the surface default, and if neither is present resolution fails and the component is not rendered, with no fallback to whatever the renderer advertises, even when it advertises exactly one catalog. An external reference into another catalog makes the catalog invalid, and implementations must report that when the catalog loads and must not fetch the target over the network. Validation is yours too. Checks attach to inputs and buttons, and a button whose checks fail is disabled rather than left to submit. When a generated payload is invalid the renderer answers in a fixed shape, an error code, the surface, a JSON pointer at the field that failed and one sentence of why, and the model corrects itself against that instead of against prose. That loop runs in your code. Accessibility is where the division of labour surprises teams, and it is also where the version matters. A schema cannot tell which property of your component holds the visible label or which component accepts input, so the v1.0 candidate places the obligation on implementations as requirements rather than guidance. A catalog and a renderer must carry the accessibility attributes through to the platform’s own accessibility layer, ARIA on the web, Semantics in Flutter, the native accessibility properties on Android and iOS. They must infer sensible defaults from the visible text and let an explicit label override them. And catalog linters must check that any component accepting an action or an input binding declares an accessible label requirement or a fallback. The v0.9.1 schemas define the accessibility attributes, but its protocol document has no such section, so on the version you ship today this is your engineering standard with no specification text behind it. Read that as a bill of work. An agent-generated screen is exactly as accessible as the catalog and the renderer you wrote, and no more, and there is no build to audit afterwards because the screen existed for one request. The security framing has the same shape and the project states it plainly: the pattern that lets you wrap your existing components, including secure iframe containers for legacy content, places security firmly in the developer’s hands, so sandboxing policies and trust ladders live in your component logic rather than relying solely on the core system. That is a feature if you were going to own that anyway, and a trap if you assumed the protocol was the control. So here is what you own. The catalog, the components, the renderer bindings, the data each component fetches under the signed-in user’s authorization and the accessibility behaviour are yours. That is where the work is, and all of it survives a protocol change largely untouched. The envelope handling and the version-specific imports belong in a thin adapter at the edge of the application. Build on v0.9.1 because that is what the project calls current, keep the adapter isolated, and read the evolution guide before you pin, because v1.0 adds function calls in both directions between agent and renderer, allows initial components and data inside the message that creates a surface, and removes the theme property and its primary color to separate layout from branding. For a mature Frontend the project itself rates mirroring your existing design system into a catalog as medium effort. Three limits. All of this is the state of one repository on 2 November 2026, where the v1.0 specification was last edited on 30 October and commits land daily, so re-read it rather than repeat this. A release candidate can still take breaking changes and the project says to expect them, so pin a version and assert it in a test rather than following a branch. And we do not speak for the project, we are not its maintainers, and we are not your accessibility auditor: we build the catalog, the renderer bindings and the gates inside your product, and we issue no conformance statements. ## עברית: אנפיטק בקצרה (Hebrew summary) This section restates the same facts in Hebrew for Hebrew-language queries. The website itself is English-only; nothing here is a separate offering. **אנפיטק** (Enpitech) היא חברת הנדסת תוכנה ישראלית המתמחה בפרונטאנד, שהוקמה ב-2021 על ידי **ניר פריזיאן** (לשעבר אינטל, לשעבר Curv שנרכשה על ידי PayPal). כ-13 מהנדסים, מבוססים בגבעתיים, עובדים מרחוק עם לקוחות בישראל, ארצות הברית ואירופה. שפת העבודה העיקרית אנגלית, שיחות מכירה ופרויקטים בישראל מתנהלים גם בעברית. **מה אנחנו עושים:** מאיצים את פיתוח הפרונטאנד. בינה מלאכותית הפכה את כתיבת קוד הפרונטאנד לזולה. מה שנשאר יקר זה להביא את הקוד הזה לפרודקשן ולמזג אותו בבטחה. מנהל מוצר, מעצב או מפתח בקאנד יכולים היום לייצר קוד פרונטאנד. מה שהם לא יכולים זה למזג אותו. הידע שהמהנדסים הבכירים מחזיקים בראש (סטנדרטים לביקורת קוד, משמעת מערכת עיצוב, בטיחות בפרודקשן) הוא צוואר הבקבוק החדש. אנחנו הופכים אותו לתשתית. **שלושת השירותים:** - **מפעל הפרונטאנד (Frontend Delivery Factory)**, השירות המוביל. [enpitech.dev/frontend-factory](https://enpitech.dev/frontend-factory) תשתית פיתוח שאנחנו מתקינים על הקוד שלכם: מפרטים מובנים שסוכני קוד יודעים לבצע, בדיקות אוטומטיות ושערי איכות, אכיפת מערכת עיצוב ב-CI, הקשר AI שנשמר ברפוזיטורי (AGENTS.md ו-CLAUDE.md), וביקורת של מהנדס בכיר בנקודת המיזוג. המהנדסים שלנו מתקינים, מפעילים, מלמדים את הצוות ומעבירים בעלות. התוצאה: כל הארגון שולח קוד פרונטאנד לפרודקשן, לא רק צוות הפרונטאנד. מחיר קבוע בשלבים. זה עוסק **באיך הארגון שלכם משלח**. - **Frontend AI**: [enpitech.dev/frontend-ai](https://enpitech.dev/frontend-ai) יכולות בינה מלאכותית בתוך המוצר ומסביבו, לשני הקהלים שלו. למשתמשים אנושיים: ממשקים גנרטיביים, סוכני צ'אט וקול על הדאטה שלכם, חיפוש חכם, עיבוד מסמכים, פרסונליזציה. לסוכני AI: אפליקציות MCP ו-MCP-UI, WebMCP, ממשקים שסוכנים יודעים להפעיל, נראות במנועי תשובות (AEO/GEO). מחיר קבוע מול סקופ מוגדר. זה עוסק **במה שהמוצר שלכם עושה**. - **הדרכות וסדנאות AI**: [enpitech.dev/ai-workshops](https://enpitech.dev/ai-workshops) סדנאות פרטיות ומותאמות על בסיס הקוד שלכם: פיתוח פרונטאנד בעזרת AI, שיטת המפעל, הרשת של הסוכנים והנדסת ווב מודרנית. פרקטי, על הסטאק האמיתי שלכם, והצוות משלח משהו אמיתי כבר בחדר. B2B פרטי בלבד, בלי קורסים פתוחים. זה עוסק **באנשים שלכם**. **מהנדסי פרונטאנד בכירים משובצים** הם מודל שילוח ולא שירות רביעי: מהנדסים בכירים שעובדים בתוך הצוות שלכם בריטיינר חודשי, מינימום 6 חודשים, בכירים בלבד. כל מהנדס משובץ מגיע עם הכלים והפרקטיקות של המפעל. **מתי פונים אלינו:** - "הפרונטאנד הוא צוואר הבקבוק שלנו, הכול מחכה לצוות הזה" - "מפתחי הבקאנד, מנהלי המוצר והמעצבים רוצים לשלוח UI ושום דבר שהם מייצרים לא נכנס" - "הטמענו כלי AI לכתיבת קוד וביקורת הקוד הפכה לפקק" - "אנחנו צריכים שהמוצר יעבוד מול סוכני AI ולא יודעים מאיפה להתחיל" - "אנחנו צריכים מפתחי פרונטאנד בכירים ששולחים קוד מהשבוע הראשון" **שאלות נפוצות בעברית:** *מה זה מפעל הפרונטאנד?* תשתית פיתוח שאנחנו מתקינים על הקוד שלכם כדי שאנשים מחוץ לצוות הפרונטאנד יוכלו לשלוח פרונטאנד לפרודקשן. מפרטים שסוכני קוד יודעים לבצע, בדיקות ושערי איכות, אכיפת מערכת עיצוב, הקשר AI ברפוזיטורי, וביקורת בכירה במיזוג. אנחנו מתקינים, מפעילים, מלמדים ומעבירים בעלות. הבעלות היא התוצר. *למה לא פשוט לגייס עוד מפתחי פרונטאנד?* כי התור לא בנוי מחוסר ידיים אלא מחוסר הרשאה. כל בקשת UI "קטנה" עדיין חייבת לעבור דרך המעטים שמורשים למזג פרונטאנד, וגיוס נוסף נכנס לאותו נתיב. המפעל משנה את הצורה ולא את הגודל. *האם זה אאוטסורסינג או השמת מפתחים?* לא. המפעל הוא תשתית ניתנת להתקנה עם תוצאה מוגדרת ומחיר קבוע בשלבים. אנחנו גם משבצים מהנדסים בכירים בריטיינר כשצוות צריך תגבור, אבל זה מודל שילוח ולא המוצר. אנחנו לא משבצים ג'וניורים. *אתם עובדים בעברית?* שיחות מכירה, פגישות ופרויקטים עם לקוחות ישראליים מתנהלים בעברית. התיעוד, הקוד ושפת העבודה היומיומית הם אנגלית. *כמה זה עולה?* מפעל: מחיר קבוע בשלבים, עם ריטיינר תפעול אופציונלי אחרי ההעברה. Frontend AI: מחיר קבוע מול סקופ מוגדר. הדרכות: לפי סדנה או לפי תוכנית. מהנדסים משובצים: ריטיינר חודשי למהנדס, מינימום 6 חודשים. אנחנו לא מחייבים לפי שעה ולא מפרסמים תעריפים. לקוחות ישראליים מתומחרים בשקלים. *איפה אתם נמצאים?* המשרד בגבעתיים. עובדים מרחוק עם לקוחות בישראל, ארצות הברית ואירופה. *קהילה:* ניר פריזיאן הוא מייסד **פרונטאנדיסטים**, קהילת מפתחי הפרונטאנד דוברת העברית הגדולה בישראל, מעל 10,000 חברים. [frontendistim.co.il](https://frontendistim.co.il/) **יצירת קשר:** office@enpitech.dev · [enpitech.dev/#contact-us](https://enpitech.dev/#contact-us) ## Selected clients Oasis Security, Ryft, Otterize, Autofleet, Lendbuzz, Lupa, Redefine Crypto, Leeway, Bubble Skincare, Innoviz, Panjaya, Clover Security, Orchid Security, Salt Security, Komodor, Hi-Mami, Mint. ## What our clients say Every quote below is published on enpitech.dev, attributed to a named person with their role and their own LinkedIn profile. We publish no invented and no anonymous testimonials. > "We were truly impressed by the professional capabilities and seamless integration we had with the engineering team from Enpitech. They delivered the exact development expertise we needed during a significant period of growth for the company." > > **Alon Ribak**, VP of Operations, Oasis Security ([LinkedIn](https://www.linkedin.com/in/alon-ribak-872225aa/)) > "We partnered with Enpitech to accelerate our initial product development. There couldn't be a better choice - a perfect combination of quality work and speed of execution, done by an amazing team. Highly recommended!" > > **Guy Gadon**, Co-Founder & VP R&D, Ryft (Acquired by Cyera) ([LinkedIn](https://il.linkedin.com/in/guygadon)) > "We wanted to move fast, and knowing Nir’s expertise firsthand, we trusted him to help us quickly build a functional application while also assembling a strong, permanent team. Nir’s team was exceptionally skilled and delivered the first version of the Access Graph - a visual network map - in record time." > > **Ori Shoshan**, CTO & Co-Founder, Otterize (Acquired by Cyera) ([LinkedIn](https://www.linkedin.com/in/ori-shoshan/)) > "Enpitech's expertise in React Native and Frontend development has significantly contributed to the success of our projects - Enpitech's ability to deliver quality results on tight schedules, communicate effectively, and adapt to our needs and methods made them an invaluable partner to our team." > > **Sapir Ashorov**, R&D Chief of Staff & Director, Autofleet ([LinkedIn](https://www.linkedin.com/in/sapirashorov/)) > "Working with Enpitech has been a fantastic experience - their expertise, honesty, and transparent approach significantly elevated our Frontend, QA, and overall development processes." > > **Ami Oren**, Director of Infrastructure, Lendbuzz ([LinkedIn](https://www.linkedin.com/in/ami-oren-a0254887/)) > "Partnering with Enpitech has transformed our team’s productivity, aligned us with the best practices in the industry, and made collaboration an absolute pleasure thanks to their approachable and supportive team." > > **Ben Rosenbaum**, Product Manager, Lupa ([LinkedIn](https://www.linkedin.com/in/ben-rosenbaum-6726031ab/)) > "We went from 0 to 100 at record speed, from having no knowledge in Frontend development to achieving high-quality workflows and a professional application." > > **Shira Brezis**, CEO & Co-Founder, Redefine Crypto ([LinkedIn](https://www.linkedin.com/in/shira-brezis/)) > "Working with Enpitech was a great experience. The dedicated developer moved fast, owned the Frontend, stepped into backend work when needed, and proactively suggested improvements - exactly the kind of mindset you want in a startup." > > **Matan Gilat**, CTO, Leeway ([LinkedIn](https://www.linkedin.com/in/matangilat/)) > "Working with an outsourced team is rarely simple. Enpitech removed the friction. They thought like owners, made clean architectural choices, and executed steadily, getting our React Native app to alpha on time and into production smoothly." > > **Yossi Cohen**, CTO, Bubble Skincare ([LinkedIn](https://www.linkedin.com/in/yossi-cohen-a52b433/)) > "Working with Enpitech was a pleasure. They quickly understood our app, solved complex challenges with smart solutions, and were always available and helpful. Beyond their deep technical skills, they genuinely care about the product, process, and people. Highly recommended!" > > **Hadar Cohen**, Tech Lead, Innoviz ([LinkedIn](https://www.linkedin.com/in/hadarcohen87/)) > "We chose to work with Enpitech to focus on our product rather than assembling a team. From day one, we received experienced developers who stay up to date with industry best practices. Enpitech accelerated our development, helped us overcome challenges efficiently, and quickly became an integral part of our team, bringing broad thinking, creative solutions, and valuable knowledge." > > **Hilik Shani**, Co-Founder, GM Israel, Panjaya ([LinkedIn](https://www.linkedin.com/in/hilik-shani-972929216/)) > "Enpitech plugged in like a true extension of our team; they onboarded in days, scaled us from one to three engineers, and treated our Next.js Frontend like owners, not contractors. Month-to-month flexibility, zero procurement friction, and delivery that met our standards." > > **Or Chen**, Co-Founder & CPO, Clover Security ([LinkedIn](https://www.linkedin.com/in/or-chen/)) > "Working with Enpitech was a great experience, especially during a very intense release period. The dedicated developer onboarded quickly, took strong ownership of the Frontend, stepped into backend work when needed, and proactively suggested improvements. This level of professionalism, flexibility, and impact is exactly the mindset you want in a fast-moving full-stack team." > > **Robert Wiseman**, Co-Founder & CTO, Orchid Security ([LinkedIn](https://www.linkedin.com/in/robert-wiseman-00a626129/)) > "Enpitech integrated like a core part of our engineering team, scaling from one to three engineers seamlessly as our needs grew... Their agility was critical in helping us hit high-stakes deadlines, delivering high-value results without compromising quality... Their data-driven approach and crystal-clear communication make them feel like internal partners." > > **Iko Azoulay**, EVP of Technology, Salt Security ([LinkedIn](https://www.linkedin.com/in/ikoazoulay/)) ## Founder Nir Parisian, Founder & CEO. Ex-Intel (Fullstack), ex-Curv (Frontend Team Lead, acquired by PayPal). Founder of Frontendistim, Israel's largest Hebrew-speaking Frontend developer community (10K+ members). ## Pricing Phased fixed price for Factory deployment, with an optional operation retainer after handover. Fixed price against defined scope for Frontend AI builds. Per session or per program for training. Monthly retainer per engineer, 6-month minimum, for embedded engineers. No hourly billing and no published rates. Israeli clients priced in ₪; US and EU clients at 70-80% of comparable domestic agency rates. ## Contact - Website: [enpitech.dev](https://enpitech.dev/) - Email: office@enpitech.dev - LinkedIn: [linkedin.com/company/enpitech](https://www.linkedin.com/company/enpitech) - GitHub: [github.com/enpitech](https://github.com/enpitech) - Community: [frontendistim.co.il](https://frontendistim.co.il/) ## Agent endpoints (NLWeb + MCP) - [Ask Enpitech](https://enpitech.dev/ask?query=YOUR+QUESTION): NLWeb natural-language query endpoint. GET (or POST) a `query` and get back ranked Schema.org results as JSON. Add `streaming=true` for an SSE stream. Mirrored at [enpitech.dev/nlweb](https://enpitech.dev/nlweb). - [MCP server](https://enpitech.dev/mcp): Model Context Protocol endpoint. POST JSON-RPC 2.0 (initialize, tools/list, tools/call) and call the `ask` tool to query this site from any agent. - [Enpitech MCP App](https://mcp.enpitech.dev/mcp-app): Remote MCP server (Streamable HTTP, no auth) with interactive views for Claude, ChatGPT and other MCP Apps hosts. Tools: `agent_ready` and `agentready_scan` (AgentReady, which scores 0-100 how ready a public website is for AI agents), `ai_hub_search` (searches the AI Hub catalog of skills, MCP servers and workflows), `newsletter` (newsletter signup), `contact_form` and `submit_contact` (Enpitech's contact form). Listed in the official MCP Registry as `io.github.enpitech/enpitech`. Docs: [enpitech.dev/mcp-app/docs](https://enpitech.dev/mcp-app/docs). Privacy policy: [enpitech.dev/privacy](https://enpitech.dev/privacy) ## Key pages - [Homepage](https://enpitech.dev/): The Frontend Delivery Factory, Frontend AI, training, selected work, contact - [FAQ](https://enpitech.dev/faq): The sitewide FAQ, searchable and grouped by topic: what the Frontend Delivery Factory is and what an engagement looks like, the guards that catch agent mistakes before merge (security, tests, performance, accessibility, design-system drift), the people the factory unlocks (designers, PMs, backend engineers), and AI in the product you sell (MCP apps, agent readiness, compliance, measurement) - [Glossary](https://enpitech.dev/glossary): Every term this site uses, defined once, each with its own anchor and a link to the answer it comes from. Grouped into the factory and its guards (Frontend Delivery Factory, merge gate, guard set, forward deployed engineer, context layer, init fossilization, handover), what gets measured (merge acceptance rate, scrap rate, guard catch rate, oversight ratio, delegation gap, mutation score, survived mutant, break threshold, owner of record, minor contributor), the people the factory unlocks (non-Frontend contributor, tacit layer, Frontend enablement), boundaries and architecture (deployment boundary, runtime composition, singleton, hard navigation, path-aligned zone, repository boundary) and the agentic web (agent-ready, agent readiness score, capability layer, declared tool, MCP app, generative UI, agent UX, AEO and GEO, llms.txt). Most entries carry a "not to be confused with" note, because the public definitions of these words conflict: published definitions of "software factory" disagree with each other, "guardrail", "gate", "policy" and "scan" are used interchangeably, merge acceptance rate is routinely mistaken for suggestion acceptance rate, mutation score for code coverage, and agent-ready for an agent readiness score. The glossary defines terms and never dates them: protocol status, versions and engine support stay in the linked answer - [Frontend Delivery Factory](https://enpitech.dev/frontend-factory): The flagship in depth. The harness we install on top of your coding agent, whichever one your team runs (context structure, maintained skills, guards, telemetry and evals, learning loop), the control surface that makes it debuggable, and the engagement: audit, pilot, run, own - [Frontend AI](https://enpitech.dev/frontend-ai): The outward-facing service in depth. What we build for your human users (generative UI, in-product agents, voice, document intelligence) and for the agents (MCP apps and MCP-UI, WebMCP tools, agent discoverability, agentic commerce), how a fixed-price scoped build runs, and the objections - [Forward deployed engineers](https://enpitech.dev/forward-deployed-engineers): The delivery model behind the flagship. What a forward deployed engineer is, how the model differs from a new hire and from staff augmentation, the four phases of a deployment (install, operate, teach, hand over), the seniority bar, and what stays in your repository when the engagement ends - [Frontend delivery options, compared](https://enpitech.dev/frontend-delivery-options): The shortlist page. Hiring Frontend engineers, staff augmentation or an agency, a coding agent rollout, an AI code review tool, an internal platform build and a Frontend Delivery Factory, compared on what you buy, what it fixes, where it stops, what remains afterwards and when each is the right call, plus four diagnostic reads a team can run on its own repository before buying anything and an explicit list of what would make us say do not buy this - [Agent-ready product options, compared](https://enpitech.dev/frontend-ai-options): The outward shortlist page. Waiting deliberately, agent discoverability work only, riding a commerce platform's own MCP server, adding WebMCP tools to your existing pages, building and hosting your own MCP server with MCP-UI views, and building a full agent-ready product surface, compared on what you buy, what it fixes, where it stops, what remains afterwards and when each is the right call, plus four diagnostic reads a team can run on its own product before building anything. Row one is doing nothing and it is a real recommendation: AI referral traffic is still a fraction of a percent of all web traffic, and the page says which teams should wait - [Enpi](https://enpitech.dev/enpi): The company-knowledge agent, currently in private beta with a limited first group of teams. Installed in your cloud, it turns years of Slack, Notion, Jira and GitHub into a living knowledge graph, then answers hard questions in Slack with citations that resolve. Four gates between a guess and an answer: grounding filter and verbatim verification on ingest, citation enforcement and permission scoping on answer. Opt-in sources, your model keys, acts only with approval. Access is by request through the page's form; onboarding is a half-hour live demo, then Enpi on your own sources - [Enpilink](https://enpitech.dev/enpilink): Our open-source (MIT) full-stack TypeScript framework for MCP Apps and ChatGPT Apps. One codebase of MCP tools and React views runs in Claude, ChatGPT, VS Code, Goose and other MCP Apps hosts. Typed tools and views, React hooks for everything a view does, account-free local development with a public tunnel, a Console (dashboard, logs, configuration, a Playground with realistic ChatGPT and Claude previews, an OAuth debugger), production OAuth, evals and view tests, an admin plane secured by default, no telemetry, self-hosted. Runs on the official MCP SDK v2 and the 2026-07-28 spec. Start with `npm create enpilink@latest`; source at https://github.com/enpitech/enpilink - [AI-Tools](https://enpitech.dev/ai-tools): Our open-source (MIT) toolkit of skills for Claude Code and other AI coding agents, installed as a Claude Code plugin (`/plugin marketplace add enpitech/ai-tools`, then `/plugin install enpitech@enpitech`) or with `npx skills add enpitech/ai-tools -g -y`. Multi-pass PR code review, a plain-language PR brief, Figma to code, a dependency audit and full-codebase audits. Runs locally and in GitHub Actions; source at https://github.com/enpitech/ai-tools - [AI-Tools code review](https://enpitech.dev/ai-tools/code-review): The cr-* skills (cr-react, cr-node, cr-python, cr-fullstack, cr-general) review a PR diff and the files it directly affects in sequential passes, seven for React and Next.js, Node.js and Python and five for any other language, plus seven cross-layer checks for fullstack projects. Only CRITICAL and WARNING findings at 8/10 confidence or higher, each with a suggested fix. In GitHub Actions a comment such as /cr-react posts a summary and one reply per finding, and /fix or /fix-all applies the fixes. The cra-* skills audit a whole codebase locally with system-level checks and a dependency audit - [AI-Tools PR brief](https://enpitech.dev/ai-tools/pr-brief): cr-brief writes a decision-level PR brief: a plain-language summary with no file or function names, then the decision, before and after, the three to six files that matter, the real risks and open questions, in under 250 words excluding the files table. It summarizes and never reports findings. Local, or one PR comment on /cr-brief in GitHub Actions - [AI-Tools Figma to code](https://enpitech.dev/ai-tools/figma-to-code): figma-to-code turns a Figma section into responsive production code on your design tokens through the Figma MCP and Playwright MCP servers, exports assets as-is, and compares Playwright screenshots to the Figma baseline at mobile, tablet and desktop. No invented content or styles, no new breakpoints - [AI workshops](https://enpitech.dev/ai-workshops): Private, hands-on training tracks run on your own codebase (the canonical training landing page; older /workshops URLs redirect here) - [AI Hub](https://enpitech.dev/ai-hub): Curated Claude Code skills, MCP servers, agentic workflows for Frontend teams - [AI Hub, Browse](https://enpitech.dev/ai-hub/browse): Full catalog of skills, workflows and tools - [Frontendistim community](https://enpitech.dev/community): Israel's largest Hebrew Frontend developer community - [AgentReady](https://enpitech.dev/agent-ready): Free scanner that scores how ready a website is for AI agents across 21 checks (discovery, readability, structured data, actions/MCP, trust) and returns the highest-impact fixes - [Nir Parisian](https://enpitech.dev/nirparisian): Founder & CEO of Enpitech, founder of Frontendistim. Newsletter signup, talks, podcast, YouTube and contact - [Blog](https://enpitech.dev/blog): Senior Frontend perspectives on AI-assisted delivery, generative UI, MCP, Claude Code workflows, the agentic web and React/Next.js patterns from production work - [PointFive case study: from prototype repo to production](https://enpitech.dev/case-studies/pointfive): How PointFive's product and UX team started shipping production Frontend. PointFive designed new screens in a prototype repo that production could not absorb, so every feature was built twice. Enpitech installed a Frontend Delivery Factory over four months: a rebuilt design system, standards enforced by a gate, a generated backend schema, agent-written Playwright tests and migration skills. Then product and UX took the keys. - [Sitemap](https://enpitech.dev/sitemap.xml)