{"schemaVersion":"1.0","revision":"f19aa4da224581732283326dfc7569678839b68f12285a78b479d792fdcd673d","canonicalUrl":"https://f200.ai/content/editorial.json","entries":[{"id":"editorial.news.cd14spi6ib58foxfr282x0ex","documentId":"cd14spi6ib58foxfr282x0ex","kind":"news","slug":"explore-f200-with-your-ai-assistant","title":"Explore F200.ai with your AI assistant","summary":"F200.ai’s public MCP endpoint and agent-readable website let AI assistants explore our offerings and read published articles from the same sources as website visitors.","body":"Source: https://f200.ai/news/explore-f200-with-your-ai-assistant\n\nYou can explore F200.ai through your AI assistant as well as your browser. Our public website provides a structured offering catalog, Markdown pages and a remote Model Context Protocol (MCP) endpoint.\n\n## Start with the published facts\n\nVisit our [guide for AI agents](https://f200.ai/agents) for connection details and supported interactions. Assistants can read company information, explore services and products, and find published articles through the public endpoint at https://f200.ai/mcp.\n\nThe [offering catalog](https://f200.ai/content/catalog.json) and [machine reading index](https://f200.ai/llms.txt) are also available directly. These give assistants access to the same approved information that visitors read on the website.\n\n## Read our engineering insights\n\nPublished articles cover software factories and governed coding-agent workflows. Explore the [blog](https://f200.ai/blog) in your browser, or use the editorial tools described in the agent guide to find and read articles through MCP.\n\n## Prepare a conversation\n\nAn assistant can help you explore relevant offerings and prepare an inquiry. You review and submit it through the website’s [contact form](https://f200.ai/#contact). The public MCP endpoint does not submit inquiries or administer the CMS.\n\nStart with the [agent guide](https://f200.ai/agents), or browse our [services](https://f200.ai/services) directly.\n","publishedAt":"2026-10-07T21:46:48.799Z","url":"https://f200.ai/news/explore-f200-with-your-ai-assistant"},{"id":"editorial.vacancies.t2ew3jk1mielqmolasp15ycn","documentId":"t2ew3jk1mielqmolasp15ycn","kind":"vacancies","slug":"devops-engineer","title":"DevOps Engineer","summary":"Help build and operate the cloud foundation behind F200.ai’s AI workforce and software factory work. We’re looking for a DevOps engineer who values automation, reliable delivery and clear operational practices.","body":"Source: https://f200.ai/careers/devops-engineer\n\nF200.ai is looking for a DevOps Engineer to help build dependable cloud infrastructure and delivery workflows for AI and software engineering projects.\n\n## What you’ll work on\n\n- Build and improve infrastructure as code and repeatable environment setup.\n\n- Automate CI/CD pipelines, deployments and rollback procedures.\n\n- Operate cloud infrastructure and containerized services with a focus on reliability.\n\n- Improve monitoring, alerting, incident response and operational documentation.\n\n- Work with engineers to strengthen security, access controls and cloud cost visibility.\n\n## What we’re looking for\n\n- Practical experience with cloud infrastructure, Linux and networking.\n\n- Experience with infrastructure as code, CI/CD and containers.\n\n- Confidence troubleshooting production systems and explaining what you find.\n\n- A habit of automating repetitive work and documenting decisions.\n\n- Interest in the infrastructure needs of AI systems and software factories.\n\nExperience with Kubernetes, Terraform, observability or platform engineering is welcome. Tell us about the tools you’ve used and the systems you’ve helped improve.\n\n## Apply\n\nUse our [contact form](https://f200.ai/#contact) and start your message with “DevOps Engineer application”. Include a link to your CV or professional profile, a short example of relevant work, your location and your availability. We’ll discuss role scope and working arrangements directly.\n","publishedAt":"2026-10-07T21:44:20.060Z","url":"https://f200.ai/careers/devops-engineer","location":"","employmentType":""},{"id":"editorial.posts.tfo015hsv6ke3adcn54ghutw","documentId":"tfo015hsv6ke3adcn54ghutw","kind":"posts","slug":"inside-shiftyard-governed-software-factory-for-coding-agents","title":"Inside Shiftyard: a governed software factory for coding agents on your own machines","summary":"A deep technical tour of Shiftyard, f200's pre-release, Apache-2.0 daemon that runs unmodified coding-agent CLIs under a queue, leases with fences, a deterministic policy gate, verified turns and a merge train: architecture, the gate's decision ladder, memory and model-selection gates, tests, measurements, and what is built versus planned.","body":"Source: https://f200.ai/blog/inside-shiftyard-governed-software-factory-for-coding-agents\n\n![Overhead harbour chart titled Shiftyard, with a dock building, four terminal-equipped berths, and a magenta route from work cards through a gatehouse to a harbour-mouth junction.](https://f200.ai/media/editorial/35301e25e24a7c5855daa9b9319ec19c145d56859aac0d501b21c750f9ebfcad.webp)Work follows a shared course through the Shiftyard harbour.\n\nCoding agents are good enough now that the hard part is no longer getting one to write a change. The hard part is running ten of them at once, on your own subscriptions, against real repositories, without one of them force-pushing to main, leaking a credential into a prompt, or quietly merging a pull request nobody reviewed.\n\nShiftyard is the software we built to do that for ourselves. It is a daemon that runs unmodified coding-agent CLIs (Claude Code and Codex today) on machines you own, and wraps every one of them in a queue, leases, a policy gate, budgets, verification and a merge train. Since 5 October 2026 our own engineering work, including most of Shiftyard's own commits, has run on it.\n\nThis post is a long, technical tour: the architecture, how a command gets allowed or refused, how two agents are kept from writing over each other, how a change travels from a queue item to a merged pull request, how the memory subsystem and its models are being selected, what we test and what we have measured. It also says plainly what is built, what is still in review, and what is only planned.\n\nStatus. Shiftyard is pre-release: there is nothing to install yet. The code is licensed Apache-2.0 and the public repository is coming soon. Everything below describes the code as of early October 2026 on macOS hosts.\n\n## 1. Why we built it\n\nA single coding agent in a terminal is a solved workflow. A team of them is not. Once you run more than a handful in parallel you meet the same failures over and over:\n\n- Shared state. Two agents claim the same ticket, or both rebase the same branch, or one writes after its claim has expired.\n\n- Unbounded actions. An agent that can run git push --force, terraform destroy or gh pr merge will, eventually, run it at the wrong moment.\n\n- Credentials. Vendor logins, cloud keys and tokens drift into prompts, logs and model context.\n\n- Verification theatre. An agent says the tests pass. Whether they ran, on which commit and with which files changed is another question.\n\n- Capacity. Subscriptions have usage windows, laptops have RAM and thermal limits, and a resumed session costs less than a fresh one.\n\n- Memory. Every new session re-derives what the last one already worked out.\n\nWe had been running an earlier internal orchestration platform for this. Shiftyard is its rewrite: one Rust daemon per host, with every backend service native inside it, built around the lessons from operating the first one.\n\n## 2. Principles\n\nFour principles are written into the project's README, and most design decisions trace back to them:\n\n- Your credentials stay on your machine. You sign in to each agent through its vendor's own login flow. Shiftyard never reads, stores or forwards those credentials.\n\n- One agent by default. A builder plus QA pair is an opt-in verification step, not the baseline.\n\n- Deterministic enforcement. Policy gates, sandboxing and budgets run on the host. They do not depend on the agent's cooperation.\n\n- Works offline. Local work never depends on the cloud.\n\nTwo engineering rules follow from the third principle and shape the whole codebase:\n\n- Pure domain cores. The gate, leases, the work state machine, flows, budgets, capacity, the balancer and the model router are pure crates: no async runtime, no I/O and no clock. Time is passed in. That makes every rule property-testable and replayable.\n\n- One writer. A single SQLite writer thread owns every SQL statement; async code never writes to the database directly. Concurrency is three sanctioned patterns only: actor tasks with channels, the writer thread, and cancellation tokens for shutdown.\n\n## 3. One host, end to end\n\n![Host enclosure containing a daemon with API, scheduler, gate, store, land, and egress modules above three sandboxed terminal seats with lock icons and arrows to the gate, plus one egress exit.](https://f200.ai/media/editorial/ca14a224bf320507d903ddea4ead4183dad51fa5dfabee9a6ea535bc9af4f6e8.webp)One host contains the daemon, sandboxed seats, and a single egress path.\n\nA yard is one Shiftyard install: the daemon on one host and everything it runs. A crew is a named group of pods working toward one purpose. Pods organise related seats, and a seat is a durable position with a role and an address; the agent session in it can change.\n\n![A macOS host contains a single daemon with eight modules and isolated seats. Operator traffic enters the API over loopback, hooks wait on the policy gate, bare-mirror objects feed each clone, and only redacted text exits through the egress sanitizer.](https://f200.ai/media/editorial/81025b7dd1082cd358addfe966a11cb82fd7e0ddec80dfb2707585e76a422ebd.webp)One host contains the daemon, isolated seats, and a single sanitized path out.\n\nThe daemon exposes two listeners and nothing else: an operator listener on loopback (admin token or session cookie, browser defences, the embedded web UI, server-sent event streams) and a Unix socket for seats (per-seat tokens, daemon user only). There is deliberately no non-loopback listener, no TLS termination and no CORS. The local API is a typed RPC service of 94 methods, served as JSON or binary, with every schema change gated by a breaking-change check.\n\n## 4. Seats: running unmodified agent CLIs\n\nShiftyard does not fork or patch the agents. It runs the vendor's own CLI and controls it from the outside, through the same surfaces a careful human would use: the terminal, the CLI's hook system and its configuration.\n\nThe launch plan. Every launch, resume and wake recomputes a launch plan as a pure function of the crew spec, the policy and the seat's state. It is never stored as truth; it is written to disk at mode 0600 just before launch, for the record.\n\nThe PTY holder. The agent runs inside a small holder process that owns its pseudo-terminal. The daemon talks to the holder over an authenticated socket with a length-prefixed protocol that supports the current and previous version, so the daemon can be upgraded while seats keep running. Input is typed only as named keys or bracketed paste.\n\nReading the screen. Detection reads the rendered screen, not the byte stream. We chose the terminal model with a spike that replayed real recorded sessions against a reference emulator (section 14): coding-agent TUIs draw spaces with cursor moves and put non-breaking spaces after their prompt glyph, so pattern-matching raw output is not reliable.\n\nFenced stops. Every stop is fenced to a launch id and a generation. Settlement proves that the agent's process id, start time and process group are gone before a seat is considered stopped, so a late signal can never hit a newer launch.\n\nClaude Code. Each seat gets its own settings file with hooks and a status line, its own account directory and a private MCP configuration loaded in strict mode, so account-level MCP servers never leak into a seat. Hooks call back into the daemon over a private socket, bound to the launch nonce. PreToolUse waits for the gate's answer and fails closed. Until a session-start event proves which session is running, every tool call is denied. A usage-limit menu is only ever answered \"stop and wait\". A resume never silently becomes a fresh start; only the recycler starts fresh, deliberately, with a recovery packet.\n\nCodex. Each seat gets its own CODEX_HOME and a per-seat profile with hooks that route session start, prompt submit and tool calls to the gate. A deny or ask returns exit code 2. The account's own configuration is checked against an allowlist of keys pinned to one CLI version; account-level hooks, rules or skills refuse the launch rather than being silently stripped. Dangerous bypass flags are banned outright, and a resume first checks that the rollout exists and that no other writer holds it.\n\nCredentials. The account registry only probes identity: which email a Claude account belongs to, and whether a keychain item exists. The Codex driver is not allowed to open the credentials file at all.\n\nOther agents. An OpenCode driver exists (two sandboxed processes: a pinned server and an attached TUI, every permission request routed to the gate, and the daemon re-reading the agent's own store every second to detect rules it did not set). It is in review, not yet composed into the running daemon. Support for further CLIs exists only as offline interface probes.\n\n## 5. The policy gate\n\n![Terminal commands pass through parse and classify stages into a rule ladder that branches to a large navy DENY bin, a medium slate ASK bin, and a small magenta ALLOW bin.](https://f200.ai/media/editorial/a4b148d0dbe69acac439837a953157f3a83638584e0aac8ef7afac9068bd3ad8.webp)The policy gate lets the most restrictive rule determine the outcome.\n\nEvery shell command an agent wants to run goes through the gate before it runs. The gate is a pure function: no clock, no store, no network and no model.\n\n![Five policy stages parse command text, classify typed action kinds, apply eight first-match rules, combine outcomes as DENY over ASK over ALLOW, and atomically record authority and consume a grant in the hash-chained audit.](https://f200.ai/media/editorial/2c9f940fe5385723438932f0a5d3eb59733d290448137291a16b38bea2d43644.webp)The policy gate fails closed and records decisions with their authority.\n\nA few details matter more than they look:\n\n- Obfuscation fails closed. Command substitution the parser cannot resolve, continuation tricks and a handful of grammar edge cases are marked opaque on purpose. Only a person can allow an opaque action.\n\n- Protected refs. main and master are always protected, in any spelling and case. Writes into .git/ or hook directories need a person's approval of the exact command.\n\n- A model may only tighten. If a model is consulted at all, it can turn an Allow into an Ask. Nothing ever becomes an Allow because a model said so.\n\n- Pinned policy. Policies are YAML with tightening overlays, canonicalised to JSON and identified by their SHA-256. Each launch is pinned to one policy hash. An invalid document fails closed; there is never a fallback policy.\n\n- Panics are denials. A classifier panic is caught and becomes Deny.\n\n- The daemon being down is a denial. If the hook cannot reach the daemon, every tool call is refused, reads included. Approvals are never auto-answered.\n\nThe code states the gate's limits in its own documentation, and so do we: the gate is defence in depth against mistakes and runaway agents, not a security boundary. The controls that hold against a hostile agent are server-side (scoped credentials, branch protection) and the OS sandbox. The gate exists so that the common failure, an honest agent doing the wrong thing at the wrong time, is stopped deterministically and recorded.\n\n## 6. Leases and fences\n\n![Two seat lanes cross a timeline fence marked 7 to 8; Seat A's token 7 write bounces back, while Seat B's token 8 write passes through.](https://f200.ai/media/editorial/03e068067a6ce4d553787e6fe437d3c74a4acdc4669be392305569d3c2a0d239.webp)Fence tokens reject stale writes and admit the current lease holder.\n\nAnything two seats could fight over is a leased resource: a work item, a slot in a heavy-job pool, a branch, a step in a flow, the merge train of a repository, the single writer of an issue-tracker project, or a claimed path in a repository.\n\nA lease alone is unsafe. A holder can stall past its expiry, wake up and write anyway. So every resource also carries a fence: a number that only grows. Each grant and each revoke moves it on, and every guarded write checks the writer's fence inside the same transaction as the write.\n\n![Seat A receives fence 7 and stalls; its lease expires, Seat B receives fence 8, and the store refuses A’s stale write while accepting B’s current write. External writers use HMAC tokens and retain each resource’s highest fence.](https://f200.ai/media/editorial/e572a344ebe02a1396c8cc8f826effe59e6034b3e73fea2347a230b3c3d44b23.webp)A newer fence prevents an expired holder from writing stale work.\n\nThe rules are one pure function, decide(view, command, now), over six commands: grant, renew, release, validate, expire and revoke. The store applies the resulting changes inside the caller's write transaction. A few constants keep it honest: no lease lives longer than 24 hours, a holder may have at most 8 live leases, and a grant is refused if the clock reads more than 5 seconds earlier than the newest grant, so a clock that jumps backwards can neither mint grants nor shorten a lease.\n\nHolders are typed (seat, job, flow, host), and cleanup for one type never touches another type's leases. That rule exists because the earlier platform once let a seat's leak guard free a background job's lease.\n\nFor writers outside the database transaction, the daemon issues a signed, expiring fence token keyed by a host secret that never appears in an agent's environment or logs. The receiver checks the signature in constant time first, then refuses any fence lower than the highest it has accepted for that resource.\n\nEvery lease implementation, the local engine today and any future broker, must pass the same shared conformance fixtures: stale renew and release, revoking a stale write, idempotent regrant, double expiry sweeps, conflicting grants and validation after expiry.\n\n## 7. The work queue\n\nWork items move through an explicit state matrix. There are four live states and five terminal ones, and terminal states refuse every command.\n\n|  From |  Command |  To | \n| --- | --- | --- |  \n|  Pending |  Claim |  Claimed |  \n|  Pending |  Block / Handoff / Deny / Cancel |  as named |  \n|  Claimed |  Start |  Running |  \n|  Claimed |  Complete / Fail |  Done / Failed |  \n|  Claimed |  Block / Handoff / Deny / Cancel |  as named |  \n|  Running |  Complete / Fail |  Done / Failed |  \n|  Running |  Block / Handoff / Cancel |  as named |  \n|  Blocked |  Unblock |  Pending, or Claimed if the prior claimant can take it back |  \n|  Blocked |  Claim / Block / Handoff / Deny / Cancel |  as named |  \n\nAn exhaustive test walks every state against every command. Claims are leases with fences, so a seat transitions its own item by presenting its fence. When an item closes, items blocked directly on it are released in the same transaction.\n\nWaiting without polling. Agents are bad at waiting. Shiftyard bans polling outright: a seat that needs CI to finish blocks its item on a canonical external reference (a commit's checks, a pull request, a CI run) with a wake-after between 5 minutes and 24 hours, and ends its turn. The daemon wakes it when the reference changes, with a slow fallback wake if nothing arrives. A wake is not a result: the seat re-reads the evidence when it wakes.\n\nIdle dispatch. An idle seat is offered its next pending item addressed to it, most urgent first and then oldest, once per idle window. The seat claims it itself. Finishing work comes before starting work.\n\nWork-in-progress limits. New build claims wait while a repository already has 15 open pull requests from the factory.\n\n## 8. Verification and the land train\n\n![Pull request cards on train wheels follow a magenta track through verify, review, approve, and merge signals to a main station, with queued cars stopped at the red verify signal.](https://f200.ai/media/editorial/b608d6e7a866fbe2a30c3e847099c516849495c56c9f1ecb3c6aed1cb6df12bc.webp)The land train carries pull requests through checks toward main.\n\nTwo mechanisms stand between an agent saying \"done\" and a change reaching main.\n\nStop-hook verification. A seat may finish its turn only once the repository's declared checks pass. The check declaration is read from the daemon's own mirror at a base commit the daemon resolved, never from the seat's working copy. The checks run in a fresh checkout built from the work's tree, with protected paths (tests, fixtures, CI configuration) taken from the base, and with a cleared environment. So an agent cannot make its turn pass by editing the tests or the check declaration. A pass lets the turn end; a failure blocks it and hands back the redacted output tail; after repeated refusals a person decides. Verdicts currently record isolation = weak, because the separate verify user does not exist yet.\n\nThe land train.\n\n![A two-row pipeline follows a queue item through a fenced claim, seat edits, stop-hook verification, PR creation, risk-tier reviews, SHA-bound checks, landability, person-approved LAND NOW, a pinned-head merge driver, and main; failed verification blocks the turn and a failed release verdict freezes the train.](https://f200.ai/media/editorial/638814d923e990ca406eb735fbb3ec434996a06833b843bfcefe58c4ce15d342.webp)Every merge passes verification, reviews, current-head checks, and a person-approved land batch.\n\nDetails that came from real incidents:\n\n- Verdicts are bound to the exact head commit. A verdict on an older head does not count.\n\n- Rebases. A verdict is carried across a rebase only when the base, the patch-id and the set of changed files are all the same. Otherwise it is superseded and the PR gets one re-review per kind. CI results never carry.\n\n- Risk tiers. Tiers come from path rules. An unclassified PR is normal; unknown files are read as infrastructure. An infrastructure batch is always size one.\n\n- Only the head the verify gate admitted can land. The merge driver only touches pull requests the engine opened, pins the head SHA on the merge and never uses an admin bypass. It runs every ten minutes and shortly after any verdict, approval or green check.\n\n## 9. Scheduling, capacity, routing and budgets\n\nLiveness from evidence. The wake core never stores \"alive\" as a flag. Liveness is computed from evidence: the holder, the process, the screen, the hooks. Every launch is a resume; there is no fresh launch except through the recycler. A permanent-failure breaker stops a seat that keeps failing to launch.\n\nHousekeeping that is on by default.\n\n|  Behaviour |  What it does | \n| --- | --- |  \n|  limit holds |  a seat that hits a usage limit has its wakes held until the reset; two agreeing seats open an account-wide limit episode |  \n|  stuck alarms |  a busy seat with no progress raises an item to its coordinator |  \n|  orphan adoption |  after a daemon restart, adopt a live agent whose holder survived, after proving identity (fenced token, kernel peer uid, holder executable, pid and start time, plan hash) |  \n|  reaper |  sleep idle seats (10 minutes for unit seats, 30 for core seats) after saving their work-in-progress to a ref and snapshotting the screen |  \n|  recycler |  start a fresh session for an implementer at 60% context or after a finished item, seeded with a recovery packet; others are compacted |  \n|  idle dispatch |  offer an idle seat its next item |  \n\nCapacity. The working seat target is floor(min(ram_seat_cap, cpu_seat_budget) × thermal_factor). The daemon samples the host every 15 seconds, keeps a 2 GiB memory reserve plus 1 GiB per new seat and a disk reserve, and gates queued resumes on CPU below 85%. Heavy jobs (builds, test suites) take a slot from a leased pool through a governor command that runs the job in its own process group, renews the slot at a third of its remaining time and releases it when the job ends. A heat guard that renices builds, caps concurrent build trees and backs off on thermal pressure is designed and in review.\n\nRouting tiers and floors. Models are grouped into three tiers. A crew may lower a tier; only the policy may raise one. Each stage of work has a floor:\n\n|  Stage |  Minimum tier |  Effort | \n| --- | --- | --- |  \n|  implement / fix (small, medium) |  2 |  medium |  \n|  implement / fix (large or unknown) |  3 |  medium |  \n|  QA and code review |  2 |  medium |  \n|  security review |  3 |  high |  \n|  security delta review |  2 |  high |  \n|  coordination |  3 |  medium |  \n|  design |  3 |  high |  \n\nTier 3 never runs at low effort.\n\nBudgets and usage. Budget admission is pure fixed-point arithmetic. Token use and list price are read from each CLI's own local records into a usage ledger, and metrics can arrive over a loopback OpenTelemetry receiver.\n\nThe balancer. A pure engine decides where seats should run across accounts: hard filters that fail closed, then ranking by headroom before the next reset, the cheapest suitable role chain and slack; failover at a cold boundary and fail-back after reset; and caps learned for windows a vendor does not publish. Today the balancer records its moves; applying them is in review.\n\nModel gateway. For components that call models directly, the daemon serves a loopback gateway that speaks the OpenAI Responses, OpenAI chat-completions and Anthropic messages protocols, walks a fallback chain with per-entry cooldowns, classifies errors, meters usage into the ledger and redacts on the way out.\n\n## 10. Isolation and egress\n\nSandbox. On macOS every seat runs under a per-seat, deny-by-default Seatbelt profile (derived from the Apache-2.0 Codex sandbox profiles). It hides other seats' state, allows only the seat's own terminal, restricts loopback by address family and denies terminal input injection. Applying the profile fails closed, and an escape test suite runs against it. Two limits are documented rather than hidden: Seatbelt does not stop one process from reading another's arguments through the kernel, and there is no Linux sandbox yet.\n\nAgent OS identity. A small root-installed helper can run agents under their own OS user, with unsafe code confined to one module. The running daemon still launches seats as the same user today.\n\nWorkspaces. Each seat has its own clone of each repository, borrowing objects from a daemon-owned bare mirror. Work in progress is saved to a per-seat ref, retired clones are parked and pruned after 30 days, and build directories are warmed with copy-on-write.\n\nEgress. There is exactly one way text leaves a host. A redacted-text type can only be constructed by the sanitizer, and every transport accepts nothing else. Deny terms are matched in a folded form, the egress log keeps only hashes and counts, never content, and a missing or empty deny list means nothing leaves at all. An operator can preview exactly what would leave before it does.\n\n## 11. Storage and audit\n\n- One writer thread plus a pool of read-only connections.\n\n- Two databases. The engine database, and an attached, append-only, hash-chained audit database. An audit command recomputes the chain end to end.\n\n- Migrations are forward-only and checksummed, with a backup before every run.\n\n- The outbox. Side effects (GitHub calls, issue updates, notifications) are written as outbox rows in the same transaction as the state change and executed by an effect runner, so a crash cannot produce a merged PR without a record or a record without its effect.\n\n- Redaction before storage. Credential shapes are replaced before any text is stored.\n\n- Secrets. Daemon-held secrets are sealed with XChaCha20-Poly1305 bound to the secret's name, with the data key in the OS keyring. The secret type cannot be formatted and is wiped on drop.\n\n- Authority records can only be written through a sealed key type, and a dependency policy check bans every other crate from depending on it.\n\n## 12. Memory: index, embeddings and governance\n\n![Dashed source icons for git, PRs, issues, and sessions connect to solid chunker and embed components, vector dots, a chained ledger book, and a dashed search magnifier.](https://f200.ai/media/editorial/c78f4ed9d23fbe979a09858be6c4bf31e20070098f03180706cd2376dd2630c1.webp)The memory pipeline connects chunking, embeddings, and a hash-chained ledger with planned sources and search.\n\nAgents forget. Our team has been running a separate memory service for months: it indexes our repositories, git history, every agent session and a ledger of remembered decisions, and serves all of it over MCP. At its last backup it held 179,037 indexed chunks. It is written in Go and uses a local embedding model through a separate model server.\n\nOn 6 October we decided that memory should not be a separate product. It becomes native code inside the Shiftyard daemon. The building blocks are in the repository; composing them into the daemon and cutting over is the work of the coming days. This section separates the two.\n\n![Solid built memory blocks include chunking, embedding, the index store, and a governed append-only ledger; dashed planned blocks include sources, hybrid search, and MCP tools. A model-selection gate lists throughput, cosine, ranking, and licence criteria.](https://f200.ai/media/editorial/ef1245392f374b5374148c7ad274ba15e6d4ceb5da026044b78f1f33ea9ca7ab.webp)Memory processing and governance are built while ingestion and retrieval remain planned.\n\nChunking. We ported the per-language regex rules of the existing service rather than switching to tree-sitter. Pure Rust, the same languages and output that can be diffed against the reference. Code is split at top-level definitions together with their leading comments and attributes; prose is split at headings outside code fences; small spans are merged and large ones split on line or paragraph boundaries; cuts move back to a UTF-8 boundary; every piece of an oversized code span is capped at 4,000 bytes. A parity test checks spans, symbols and imports against the reference implementation's output; on a 32-file test corpus the outputs match except for two documented deviations. A tree-sitter chunker is a later decision, gated on beating the regex baseline on code-scope retrieval.\n\nEmbeddings. The model layer defines Embedder, Reranker and Classifier interfaces and one shared post-processing pipeline: an 800-character input cap, the model card's query and document prefixes, Matryoshka truncation, L2 normalisation and an int8 form with sign bits. A model id names a vector space (name, precision, dimensions and a hash prefix), and vectors from different ids are never mixed.\n\nModels are open-weight GGUF files only, run in process through llama.cpp: Metal on macOS, CPU elsewhere, GPU by default with an automatic CPU fallback whose reason is recorded. One thread owns a loaded model. User text is tokenised with special-token parsing switched off, so a document cannot inject control tokens. We chose not to use ONNX Runtime.\n\nModel supply chain. A model manifest pins a 40-character commit and a SHA-256, accepts only Apache-2.0 or MIT licences with no override, and accepts GGUF only, never pickle. Provisioning asks for consent with the size and licence shown, downloads with a size cap and resume, verifies the file before every load, works offline once cached and uses file locks for fetch and use. One candidate embedding model was dropped from consideration purely on its licence terms.\n\nGoverned memory. Remembered facts and decisions live in an append-only, hash-chained lifecycle ledger: approve, hold, supersede, retract, quarantine and restore, each atomic with its ledger event. Imports are idempotent and keep provenance. A write to a shared scope stays pending until an owner approves it.\n\nCutover plan. Backup (done 6 October), a four-model quality and speed evaluation, a parity proof, composition into the daemon, a 48-hour shadow run, then the switch, one seat first and then all, and finally the old service read-only and retired. The target window is 8 to 15 October. The rule written into the plan: if no model meets both the quality and the speed bar, we report the measured results; we never lower either bar.\n\n## 13. Models and training\n\nShiftyard trains no model weights. That is an explicit non-goal, not an omission. Training models, or using another model's outputs as labels, is out of scope for the memory work. Hosted judgment results are never used as training data. What we do instead is select open models against fixed gates, and optimise text (guidance and skills) against held-out evaluations.\n\nSelecting the embedding model. The candidates are open-weight embedders in the 0.1 to 0.6 B parameter range: Qwen3-Embedding-0.6B, nomic-embed-text-v1.5, the BGE family (bge-m3, bge-small-en-v1.5) and IBM Granite embeddings. A candidate passes only if all of these hold:\n\n|  Gate |  Bar | \n| --- | --- |  \n|  throughput |  median warm chunks/s at 800 characters above the current baseline, and above 15 |  \n|  numerical agreement |  mean cosine against the same model under the reference runtime ≥ 0.99, minimum ≥ 0.97 |  \n|  retrieval quality |  file-level MRR@10 ≥ baseline − 0.01 |  \n|  licence |  Apache-2.0 or MIT |  \n\nCutover itself has a stricter, statistical gate: a paired bootstrap with 10,000 resamples on at least 150 queries, whose 95% confidence interval lower bound must be ≥ −0.02 on both MRR@10 and weighted recall@10, with search p95 at or under 293 ms and a daemon footprint at or under 78 MB excluding the model, at 15 seats. Quantisation has its own gate (cosine ≥ 0.99, ΔMRR ≤ 0.01, classifier ΔF1 ≤ 1 point). A reranker is optional and must earn its place on nDCG@10.\n\nWhat we have measured so far.\n\n|  Measurement |  Result |  Status | \n| --- | --- | --- |  \n|  reference service, M2, 3,000-char inputs |  6.1 chunks/s |  measured |  \n|  reference service, M2, 1,500-char inputs |  14.3 chunks/s |  measured |  \n|  reference service, M2, 800-char inputs |  15–28 chunks/s |  measured |  \n|  reference service, pooled file-level MRR@10 at 800 chars |  0.529 |  measured |  \n|  native, Qwen3-Embedding-0.6B Q8_0 (1024-d), batch 32, M2 + Metal |  11.3 chunks/s |  preliminary: laptop under load, not a clean run |  \n|  reranking in the reference service |  hit@1 −0.085 |  measured: it hurt, so it is off by default |  \n\nThe native number is below the baseline range, and we are publishing it anyway: it was taken on a loaded laptop and is not a gate result. Performance claims in the codebase must be measured in a fresh process, on fixed inputs, after a warm-up, as the median of several runs. The negative reranking result is the reason the reranker is opt-in and gated.\n\nExperimental: automatic guidance and skill learning. On an unmerged branch we are testing a loop that improves the text agents run on (their guidance files and skills) without training anything:\n\n- A local Qwen2.5-1.5B-Instruct model (Q4_K_M GGUF, about 1.1 GB) runs in a daemon-managed llama.cpp child process. API spend is zero, each run has a 10-minute budget and makes at most three changes.\n\n- Runs happen daily (guidance in the morning, skills an hour later) and after outcome events.\n\n- A candidate must strictly improve on the training set, then pass one sealed, paired, held-out evaluation, then a person reviews it before it is activated.\n\n- Retrieval inside the loop uses BGE-small-en-v1.5 (Q8, 384-d) for a shortlist of 8, a Jina turbo reranker, and BM25 plus dense retrieval fused with reciprocal rank fusion (k = 60).\n\nThe measurements so far are deliberately small and do not establish production quality. On 10 English and 10 Ukrainian queries, top-1 retrieval was 80% and 90% with query translation, 20% for Ukrainian without translation, and 70% for English before fusion. On 20 fresh English queries it moved from 65% to 70%. In screening, four smaller models (Qwen2.5-0.5B, Qwen3-0.6B, Qwen3.5-0.8B and SmolLM2-360M) each failed at least one of five guidance checks. No change has yet earned promotion.\n\nAdvisory judgments. Four typed judgments help the operator: queue priority, duplicate ticket, a seat stuck in a loop, and pull-request scope drift. Each has a firm probability band (for example p ≥ 0.9 for a duplicate). They are advisory only. A judgment may add a note, a badge or a display order; it may never grant, block, merge or reorder a queue, and \"no answer\" must behave exactly like \"off\". The backend is hosted or off today, and a local decider that shadows the hosted one is planned.\n\n## 14. Testing and measurements\n\nThe codebase on main at the time of writing:\n\n|  Metric |  Value | \n| --- | --- |  \n|  Rust workspace |  49 crates, about 397,000 lines (261,000 source, 136,000 tests) |  \n|  Web UI |  about 65,000 lines of TypeScript (React, Vite, Playwright) |  \n|  Test functions |  4,613 (static count) |  \n|  Gate classification corpus |  483 cases |  \n|  Gate bypass corpus |  987 cases (must-gate bypasses plus read-only negative controls) |  \n|  Conformance fixtures |  14 (leases, fleet reads, handshake, claims) |  \n|  Known-failure baseline |  empty |  \n\nHow we test.\n\n- Property tests on the gate, the lease rules and secret sealing.\n\n- Fuzzing of the gate classifier, the usage parsers, and the agent-identity helper's arguments (a million iterations by default). A fuzz crash becomes a regression test before it is fixed.\n\n- New review findings become failing corpus cases first.\n\n- Exhaustive matrices, such as every work state against every command.\n\n- No wall clock in tests. Tests use a fake clock, and a guard test enforces it. Test retries are set to zero in every profile.\n\n- Conformance as a contract. Fixtures are protobuf JSON; a run that skips a required fixture fails.\n\n- CI runs on self-hosted Linux arm64 runners only, the main suite runs in about a minute, and a hung test is killed at 300 seconds. macOS coverage runs on maintainers' machines. A public-text guard runs on every pull request.\n\nChoosing the terminal model, measured. Before writing the screen reader we replayed five real recorded Claude Code sessions plus synthetic Codex and stress recordings through three Rust terminal emulators, comparing each against a headless reference emulator. Two identical runs on an M-series Mac:\n\n|  Terminal crate |  Text mismatches |  Unexplained modes |  Failed checkpoints |  Throughput (MB/s CPU) |  Memory per 200×50 screen + 10k scrollback |  Result | \n| --- | --- | --- | --- | --- | --- | --- |  \n|  alacritty_terminal 0.26 |  0 |  0 |  0 |  162.8 |  49,922 KiB |  chosen |  \n|  avt 0.18 |  0 |  20 |  4 |  81.9 |  32,194 KiB |  rejected: no bracketed paste |  \n|  vt100 0.16.2 |  144 |  0 |  0 |  85.4 |  63,328 KiB |  rejected: unmaintained |  \n\nThe same spike showed that 30 seats with 10,000 lines of scrollback each would cost about 1.5 GB, which is why the default scrollback is 2,000 lines.\n\nWhat we have not measured yet. Gate decision latency, daemon RPC latency (the histograms exist; we have not published numbers), throughput or merged pull requests per day attributable to the factory, and cost per merged pull request. The last one is the outcome metric we care most about, and the usage ledger exists to feed it.\n\n## 15. Running our own work on it\n\nOn 5 October 2026 we moved our own engineering team off the earlier platform and onto Shiftyard in one hard switch, with no parallel run. The import moved the open work across and checked that no authority records (grants, approvals) travelled with it. The go/no-go list had six blockers (per-seat accounts, MCP for seats, guardrail parity, Codex wake registration, disk and session resume), and some were repaired in flight.\n\nSince then Shiftyard has largely been built by agent seats running on Shiftyard: the repository has 366 merged pull requests, and the busiest day after the switch had 356 commits. The same mechanisms described above (the gate, the land train, verdicts bound to head commits) govern the agents that are writing the code.\n\n## 16. Roadmap and YardBridge\n\n![A magenta voyage route joins filled buoys dated Sep 25, Oct 5, and Oct 6, hollow buoys dated Oct 12 and Oct 15, and a dashed continuation to an island labelled YardBridge.](https://f200.ai/media/editorial/8b37ecf545e51d36da2c8d65f873a4376dd06bf0ab927c9ddad3c41d1201de2a.webp)Completed and planned milestones chart the voyage toward YardBridge.\n\n![A 2026 milestone timeline marks completed work from September 25 through October 6, planned October memory migration and retirement, next items in review, and later multi-host, Linux sandbox, and public release work, with a separate indicative YardBridge lane.](https://f200.ai/media/editorial/775d737fafeff8bc32ca61d018bb24303867b6797b467bd3d1184ad85a911347.webp)The roadmap separates delivered foundations, reviewed next steps, and planned horizons.\n\nMulti-host. A host-to-host link protocol, a fleet read service and conformance fixtures exist; the coordinator that implements them does not. One host acting as the coordinator for a person's other hosts is planned.\n\nYardBridge is the planned organisation layer on top of Shiftyard. The design installs it in the customer's own AWS account, with yards always dialling out and the control plane never connecting into a yard. The first release is scoped to enrolment, fleet visibility, customer-signed policy (Ed25519 signatures over canonical documents, a host-pinned trust root, effective permissions as the intersection of org and host policy, with the built-in floor always preserved) and exact outcome evidence. Shared claims across hosts, strict fleet budgets, a visual flow builder and organisation-wide memory come later. The indicative path to a first partner pilot is 10 to 12 weeks; it is a plan, not a delivery date, and none of YardBridge is available today.\n\n## 17. What we do not claim yet\n\nEngineering posts about agents tend to round up. Here is the list of things Shiftyard does not do today:\n\n- It is not installable, and the public repository is not open yet.\n\n- Memory, the code index, embeddings and reranking are not running inside the daemon; the building blocks exist and the cutover is planned.\n\n- No embedding model has been selected, and we have no retrieval-quality number for Shiftyard's own memory yet.\n\n- Shiftyard trains no models.\n\n- OpenCode seats, the heat guard and applying the balancer's moves are in review, not running.\n\n- There is no Linux sandbox and no multi-host coordination.\n\n- The gate is not a security boundary, and the verify step's isolation is recorded as weak.\n\n- We have measured no productivity, cost or quality improvement, and we are not implying one.\n\n## Get involved\n\nShiftyard is licensed Apache-2.0, and the names f200, Shiftyard and YardBridge are trademarks of f200: forks are welcome under a different name. The public repository is coming soon, with a Developer Certificate of Origin sign-off for contributions. If you run coding agents in parallel and recognise the failures in section 1, or you want to be an early YardBridge design partner, book a 30-minute call with the founders.\n","publishedAt":"2026-10-07T20:17:09.826Z","url":"https://f200.ai/blog/inside-shiftyard-governed-software-factory-for-coding-agents"},{"id":"editorial.posts.dwzxv0o4gdfi7iweu0s9x2g0","documentId":"dwzxv0o4gdfi7iweu0s9x2g0","kind":"posts","slug":"software-factories-why-every-company-needs-one","title":"Software factories: why every company, from enterprise to solo founder, needs one","summary":"AI agents can now do day-long engineering tasks, and almost every developer uses AI. Yet company-level gains are elusive. The research shows why: value comes from the system around the agents. A business guide for CEOs, product founders and solo builders, with data from 40+ studies, case studies and a 90-day plan.","body":"Source: https://f200.ai/blog/software-factories-why-every-company-needs-one\n\n![An overhead shipyard with four crane-equipped slipways feeding identical vessels along a magenta route through an inspection gate into open water.](https://f200.ai/media/editorial/64f9fa8ae54093da9ec2890c6ea5061e44bba2b879e232587e5c4c72d28875e1.webp)A software factory builds agent work in parallel and sends it through inspection before release.\n\nEvery founder we talk to asks a version of the same question. \"My engineers already use AI. Why isn't the company shipping twice as fast?\"\n\nThe short answer: an AI coding assistant makes a person faster at writing code. A software factory makes a company faster at shipping working software. Those are different things. The research from the last two years explains the difference, and it makes the business case for building the second one.\n\nThis post is for CEOs, CTOs, product founders and solo builders. It covers what a software factory is, what the data says about the value, where the value leaks away, and how to start at your stage. Every number is sourced at the end. Where the evidence cuts against the story, we show that too.\n\nThe one-paragraph version. AI agents can now do multi-hour engineering tasks, and that capability is doubling roughly every four months. Adoption is close to universal. But the gains show up in company results only when the work around the code is redesigned: queues, verification, review, merge, budgets and memory. Without that, AI produces more code, more review load and more defects, and the business barely moves. A software factory is the system that turns agent capability into shipped, trustworthy product.\n\n## 1. What a software factory is\n\nA software factory is a governed production line for software, where AI coding agents do much of the building and people decide what gets built and what ships.\n\n![Eight steps connect goals and ideas to production, with policy gates, verification and risk-based review. Shared memory supports every step; measured outcomes feed back to goals.](https://f200.ai/media/editorial/ba340ec5eb52091dd43b8d99b29ba6ed60fa544acfe86d20e7d5c58cc67b1140.webp)What a software factory is\n\nIt has six parts, and each one exists because agents fail in a specific way without it:\n\n|  Part |  What it does |  The failure it prevents | \n| --- | --- | --- |  \n|  Intake and queue |  Turns goals into small, well-defined work items with owners and priority |  Agents working on the wrong thing, or two agents on the same thing |  \n|  Agents |  Claude Code, Codex and similar tools doing the implementation, each in its own sandboxed workspace |  One agent's mess spilling into another's work |  \n|  Policy gates and budgets |  Deterministic rules on what an agent may run and spend |  Force-pushes, deleted databases, surprise cloud bills |  \n|  Verification |  Tests and checks that must pass before an agent may say \"done\" |  \"The tests pass\" when they never ran |  \n|  Review and merge |  Risk-based human review and an exact, auditable merge pipeline |  Unreviewed code reaching production |  \n|  Memory |  What was decided, tried and learned, searchable by every agent |  Every session re-deriving yesterday's work |  \n\nThe key idea: the agent is not the product. The system around the agent is.\n\n![Comparison of human-only, copilot and software factory operating models across code authorship, work units, bottlenecks, governance, scaling and measured gains.](https://f200.ai/media/editorial/057d14f1637075a80a37f7c17ad78a7f1db34fbf88a63e21e8e3e079e78d6edf.webp)Three ways to build software with AI\n\n## 2. The capability curve: why this is a now problem\n\nIn 2023 the best AI model could reliably finish a software task that takes a human expert about 4 minutes. By February 2026, the best models could finish tasks that take an expert about 12 hours, half the time. That is a ~180× increase in three years.\n\n![Linear-scale task horizons by model release date: GPT-2 0.05 min; GPT-3.5-instruct 0.6 min; GPT-4 4.0 min; GPT-4o 7.0 min; Claude 3.5 Sonnet 20.5 min; o1 38.8 min; Claude 3.7 Sonnet 60.4 min; o3 119.7 min; GPT-5 203 min; Gemini 3 Pro 224.3 min; Claude Opus 4.5 293 min; GPT-5.2 352.2 min; Claude Opus 4.6 718.8 min. Illustrative least-squares exponential fit to the shown 2023–2026 observations on a linear hours axis; observations remain unchanged.](https://f200.ai/media/editorial/963ff14727317e810ce71e5e82fdb6d39b456456ad33e3ea7706413c259b8331.webp)The 50% success horizon rose from GPT-4’s 4 minutes to Claude Opus 4.6’s 718.8 minutes (~12 hours). Linear hours reveal the exponential shape; the curve is an illustrative least-squares exponential fit to the displayed 2023–2026 observations, not a forecast. METR reports ~129-day doubling for its broader trend..\")\n\nMETR, an independent research organisation, measures this \"time horizon\": the length of task, in expert-human time, that an AI agent completes with 50% success. Since 2023 it has doubled about every 129 days. Over the full history since 2019, the doubling time is about 188 days.\n\nWhat this means for a business:\n\n- A 4-minute task is autocomplete. A person stays in the loop for every line.\n\n- A 1-hour task is a delegated ticket. Someone reviews the result.\n\n- A 12-hour task is a day of engineering. You need a queue, a budget, checkpoints and a way to verify the outcome without redoing it.\n\nThe tools crossed from the first category to the third in about 30 months. Most companies' processes did not.\n\nA note on benchmarks: public coding benchmarks like SWE-bench Verified went from about 50% to over 90% in under two years, and OpenAI stopped reporting the benchmark in February 2026 after an audit found many of its tasks flawed. Treat any single leaderboard number with caution. The direction is not in doubt; the exact score is.\n\n## 3. Adoption is near-universal. Trust is not.\n\n![Use or plan to use AI: 76% in 2024 to 84% in 2025; distrust of AI accuracy: 31% to 46%; AI agent use: 31% in 2025 to 59% in the April 2026 pulse.](https://f200.ai/media/editorial/75f9887f2232bf3b2dcb8576fc8720492acc75e2d29c54fb19376d1718fab396.webp)AI adoption and distrust both increased, while reported agent use rose to 59% in the April 2026 pulse.\n\n- 90% of software professionals now use AI at work, a median of two hours a day (Google DORA 2025, about 5,000 respondents).\n\n- 84% of developers use or plan to use AI tools, up from 76% the year before (Stack Overflow 2025, 49,000+ responses).\n\n- Use of AI agents, not just chat or autocomplete, rose from 31% in 2025 to 59% in April 2026 (Stack Overflow pulse survey).\n\n- Google says 75% of its new code is now AI-generated and approved by engineers, up from about 25% in late 2024.\n\n![Google 75% (Apr 2026); Robinhood ~50% (Jul 2025); Coinbase ~40% (2025); Microsoft 20–30% (Apr 2025); Uber ~10% by autonomous agents (May 2026). Google trend: 25% Oct 2024, 50% fall 2025, 75% Apr 2026. Executive statements; definitions differ.](https://f200.ai/media/editorial/70b22af31bbe0acd46b47deec61ab880d222b1c6c0ee8a910a6e45214f9a3005.webp)Reported AI-generated code shares range from ~10% by autonomous agents at Uber to 75% at Google; definitions differ.\n\nThe open-source world shows the same shift. GitHub's 2025 Octoverse counts 180 million developers, 1.1 million public repositories using an LLM SDK (up 178% in a year) and 518.7 million merged pull requests (up 29%). The most-starred open-source coding agents were almost all created in 2025: four of them passed 100,000 stars each within about eighteen months.\n\n![GitHub stars by repo creation date: opencode: 212,182, Apr 2025; Claude Code: 149,734, Feb 2025; OpenAI Codex CLI: 128,169, Apr 2025; Gemini CLI: 107,245, Apr 2025; OpenHands: 90,185, Mar 2024; MetaGPT: 70,766, Jun 2023; Cline: 69,981, Jul 2024; Goose: 55,037, Aug 2024; Aider: 49,409, May 2023; Continue: 36,148, May 2023; ChatDev: 34,458, Aug 2023; Kilo Code: 27,520, Mar 2025; Roo Code: 24,284, Oct 2024; SWE-agent: 20,497, Apr 2024. Four projects created in 2025 have 597K+ stars combined.](https://f200.ai/media/editorial/acf72ae876afa1446a3e2168911a51162b98cb639486c630d048d529242384d9.webp)Four coding-agent projects created in 2025 passed 100,000 GitHub stars each, reaching 597K+ combined.\n\nAt the same time, trust is falling:\n\n- Only 24% of DORA respondents trust AI output \"a lot\" or \"a great deal\".\n\n- 46% of Stack Overflow respondents distrust the accuracy of AI tools, up from 31%.\n\n- 66% say the biggest frustration is code that is \"almost right, but not quite\".\n\n![Trust in AI output: 24% a lot / a great deal, 46% somewhat, 30% a little / not at all. 90% use AI; median usage is 2 hours per day.](https://f200.ai/media/editorial/c34024646bb4c552501304f225b08f030d59f0085fd231fe9e1490457b08b50a.webp)Only 24% of DORA respondents expressed high trust in AI output, despite 90% using AI.\n\nThis gap, near-universal use with low trust, is the whole business problem in one picture. People are generating more code than ever and believe less of it. Somebody has to check it, and that somebody is your most expensive engineers.\n\n## 4. What the evidence says about productivity\n\nHere are the controlled studies and large field measurements, side by side.\n\n![Effects: Copilot +55.8% faster; Google +21% faster (~96 vs 114 min); Microsoft/Accenture +26.1% tasks ±10.3; Microsoft CLI +24.0% merged PRs, CI +14.5 to +33.7, daily users +50.1%; Faros +21% tasks; METR −19% slower. METR 2026 follow-up faster on average but inconclusive due to selection bias. METR experts predicted +24%, measured −19%, believed +20% afterwards.](https://f200.ai/media/editorial/42ad7149cb6e8f1531c3c1eff61cd628fcf7ebe9a5883fbb0c71b094d77027a4.webp)Reported effects vary across settings, with METR’s 2025 study finding a 19% slowdown among experienced developers.\n\n|  Study |  Setting |  Result | \n| --- | --- | --- |  \n|  GitHub Copilot RCT (2023) |  One scoped task: build an HTTP server |  55.8% faster |  \n|  Google internal RCT (2024) |  96 Google engineers, enterprise task |  ~21% less time |  \n|  Microsoft, Accenture, Fortune-100 field experiments (2025) |  4,867 developers, real work |  +26% completed tasks; juniors gained most |  \n|  Microsoft agentic CLI rollout (2026) |  Command-line coding agents, 4 months |  +24% merged PRs, no decay; daily users +50% |  \n|  Faros telemetry (2025) |  10,000+ developers, 1,255 teams |  +21% tasks, +98% PRs, but flat company-level metrics |  \n|  METR RCT (2025) |  16 expert open-source maintainers on their own repos |  19% slower, while believing they were 20% faster |  \n|  METR follow-up (2026) |  57 developers, 800+ tasks |  Faster on average, but too biased by selection to be conclusive |  \n\nThree things stand out for a business owner.\n\nFirst, the gains are real and they repeat. Well-defined work, measured inside a real organisation, consistently shows 20–30% more output, and agentic tools in 2026 show similar or better, sustained over months.\n\nSecond, people misjudge their own speed. In METR's 2025 study, experienced developers predicted AI would make them 24% faster, were actually 19% slower, and still believed afterwards they had been 20% faster. Self-reported productivity is not a metric. If you don't measure, you don't know.\n\nThird, individual output and company output are different numbers. Faros saw teams merge almost twice as many pull requests, and saw no improvement at the company level. McKinsey's 2026 Technology Trends Outlook reports the same pattern across companies: AI tools raised coding activity by 180%, but shipped releases rose by only 30%; only a quarter of companies achieved meaningful acceleration, and nearly 30% saw productivity fall after adopting agentic tools. The next section explains why.\n\n## 5. What it looks like when it works\n\nThe companies getting real results did not just hand out licences. They built pipelines.\n\n![Airbnb: 1.5 years estimated to 6 weeks, 97% automated, ~3.5K files. Amazon: ~50 developer-days per app to hours, 30,000 apps, ~4,500 developer-years and ~$260M/yr saved. Google: 6× faster migrations. Stripe: 1,300+ fully agent-written PRs merged weekly, all human-reviewed. Uber: background agent opens 11% of PRs; AI review covers 90%+ of ~65K weekly diffs.](https://f200.ai/media/editorial/bd8cd19732330288d63dc3d52b34c934b0ccbfeefa0c0af57268c3809a51c572.webp)Company reports describe faster migrations and substantial agent output, alongside review practices.\n\n- Stripe merges more than 1,300 pull requests a week written end-to-end by its internal agents, every one reviewed by a person. Work starts as a request in Slack and ends as a PR that has already passed CI, built on isolated environments and hundreds of internal tools.\n\n- Airbnb migrated about 3,500 test files to a new framework in 6 weeks, against an original estimate of 1.5 years, with 97% of the work automated.\n\n- Amazon used its coding agent to upgrade 30,000 applications to a new Java version, cutting each upgrade from about 50 developer-days to hours, and estimates 4,500 developer-years and $260 million a year saved.\n\n- Google reports a large code migration done by agents and engineers together six times faster than a comparable one done by people alone.\n\n- Uber's background agent opens 11% of all its pull requests, and its AI reviewer covers more than 90% of about 65,000 changes a week.\n\nThe flip side is at Uber too: the company spent its entire 2026 AI-coding budget in about four months, and its COO said publicly that the link between agent usage and shipped features \"is not there yet\". Same tools, same company: where there is a pipeline, there are results; where there is only usage, there is a bill.\n\n## 6. Where the value leaks: the review bottleneck\n\nWhen agents write more code, every downstream step gets more work: review, testing, merging, deploying, fixing.\n\n![High-AI teams vs baseline: tasks completed +21%, PRs merged +98%, PR size +154%, review time +91%, bugs per developer +9%. Company-level delivery metrics: flat.](https://f200.ai/media/editorial/3c6ebf1a3bc6c660663a8669bf9abcad2f25e427d1d578bef9afa61349ffccbc.webp)High-AI teams produced larger PRs and spent more time on review while company-level delivery metrics stayed flat.\n\nIn Faros's data, high-AI teams merged 98% more PRs, but their PRs were 154% larger, review time went up 91%, and bugs per developer rose 9%. The constraint moved from writing code to verifying it, and verification capacity didn't grow.\n\nIt gets worse over time. A 2026 study of 400 reviewers and 11,429 reviews found that reviewers approve agent-written PRs more and more easily: approval rose from 27.9% to 42.4% across reviewers' own history, while their inline comments fell 22%. Over the same period they became stricter with human PRs.\n\n![Agent PR approval rates by reviewer experience decile 1–10: 27.9%, 27.1%, 30.0%, 28.1%, 33.3%, 35.6%, 32.6%, 34.2%, 38.6%, 42.4%. Approvals +14.5 points; inline comments −22%.](https://f200.ai/media/editorial/9ffeee26d36d2d933ec94c2513e6c8239807db4c4b31d4c180fc7be9e4ed424e.webp)Approval rates rose from 27.9% to 42.4% across reviewer experience deciles as inline commenting declined.\n\n![Dozens of small boats converge across a wide bay toward a narrow harbour mouth guarded by one inspection tower, with only a few boats beyond it.](https://f200.ai/media/editorial/230f4fd460e509a98dcd00cd854949ad58c86c3d00dbb304216bc15c64c348a6.webp)Output grew; verification capacity did not.\n\nOn public GitHub, the review gap is measurable. Coding agents opened millions of pull requests in the past year (Codex about 5.1 million, Claude Code about 4.2 million, Copilot about 1.9 million). Most of them merge, but for two of the three biggest agents fewer than a third of merged PRs got a human review. And merging isn't the end of the job: merged agent PRs need follow-up fixes at 1.62× the odds of human PRs, and a Stanford study of 6,000 real agent sessions found that only 44% of agent-written code survives into commits.\n\n![PRs opened: Codex 5.1M; Claude Code 4.2M; Copilot 1.9M; Jules 1.2M; Cursor 614K; Devin 161K. Merge rate / human review among merged PRs: Claude Code 91.5% / 30.5%; Codex 87.5% / 28.6%; Copilot 68.1% / 80.5%. Merged agent PRs need follow-up fixes at 1.62× the odds of human PRs.](https://f200.ai/media/editorial/16ea10b270a85b5f988cc7997bb7f58daa3109f25afab8234f7638c02195aa0d.webp)Most merged agent PRs were never reviewed by a person; merged agent PRs had 1.62× the odds of follow-up fixes.\n\nDevelopers feel both sides of this. Atlassian's 2025 developer experience survey found 68% of developers save more than 10 hours a week with AI, while 50% lose more than 10 hours a week to organisational friction. The time AI gives back is easily eaten by the system around it.\n\nAnd the quality signals are mixed:\n\n- Veracode found security flaws in 45% of AI-generated code tasks (over 70% in Java).\n\n- Apiiro saw 3–4× more code produce 10× more security findings.\n\n- GitClear measured an 8× rise in duplicated code blocks and a 40% drop in refactoring.\n\n- On the other hand, a study of 37,623 public agent PRs found security-smell rates lower than humans' when pooled, with large differences between agent vendors.\n\n![Veracode: 45% of AI code tasks introduced a vulnerability, Java >70%. Apiiro: 10× more security findings for 3–4× more code. GitClear: 8× more duplicated code blocks, −40% refactoring. A 37,623-PR study behind good gates found agent security-smell rates below humans.](https://f200.ai/media/editorial/cc4ff2dee260cd3d9dd9e69a674fcf945a64617d0a9eae4889bfee1b9e29db17.webp)Studies report security and maintainability risks, while a gated PR study found lower agent security-smell rates than humans.\n\nThe lesson isn't \"AI code is bad\". It is: the outcome depends on the system the code goes through. The same agents, behind good gates, produce good results. Behind no gates, they produce volume.\n\n## 7. AI is an amplifier\n\nGoogle's DORA research summarises two years of data in one sentence:\n\n\"AI's primary role is that of an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones.\"\n\nTeams with clear policies, small batches, solid version control, good internal platforms and accessible data get the gains. Teams without them get more instability. DORA reports that throughput is up across the industry while delivery instability keeps rising.\n\nMcKinsey reaches the same conclusion from the other side: top performers see 16–30% improvements in team productivity, customer experience and time to market, and 31–45% in software quality. What separates them is how they work, not which tools they bought.\n\n![AI coding agents amplify strong foundations into faster, safer delivery, and weak foundations into more code and more instability.](https://f200.ai/media/editorial/50a7878c0e0b73f0cf06fdbef02ca59065eb00949d9e479483223b4485bff0cd.webp)AI is an amplifier\n\nThis is why a software factory is a management decision, not a tooling decision. The factory is how you make your organisation the kind that AI amplifies upward.\n\n## 8. Where the business value comes from\n\n![Five branches of business value: throughput, lead time, quality and risk, cost control, and talent leverage, with the figures supplied in the brief.](https://f200.ai/media/editorial/1c3a11f40873106cec6666690dd42db61b59c33c4d9d5261287e4b3d0087139c.webp)Where the business value comes from\n\nFor a CEO, the value of a software factory shows up in five places:\n\n- Throughput. More finished, merged work per engineer: +20–30% in controlled studies, +24% for agentic tools at Microsoft, with Gartner expecting agent-based workflows to reach 30–50% team gains versus 0–20% for assistants alone.\n\n- Lead time. Shorter time from idea to production, because the queue, verification and merge steps are automated and run around the clock. Google reports a large migration running \"six times faster\" with AI.\n\n- Quality and risk. Verification that can't be skipped, deterministic policy on dangerous actions, and an audit trail. This is what keeps the 45%-flawed-code statistic out of your production systems.\n\n- Cost control. Agent spend is real, and it is growing even as models get cheaper (see the next section). Budgets, model routing and avoiding wasted agent work are part of the factory. One 2026 study found simple developer-written \"skills\" cut agent cost by 8–42% in most settings.\n\n- Leverage of scarce talent. Your senior engineers stop typing and start specifying, reviewing and designing. The factory multiplies the people you can't hire more of.\n\n![Cursor annualised revenue run-rate: $2B February 2026, $3B late April 2026, $4B+ June 2026; Claude Code >$2.5B early 2026. Gartner enterprise AI coding agent market ≈ $10–11B/year in 2026; 90% of enterprise engineers to use AI code assistants by 2028, from <14% early 2024.](https://f200.ai/media/editorial/7a586ddca2e9e5c1c7e5e10089682a02043227134be8e8b2fe49a6e0fbb8bdcc.webp)Reported coding-agent run-rates reached billions of dollars as Gartner forecast widespread enterprise adoption.\n\nThe market is moving accordingly. Gartner published its first Magic Quadrant for Enterprise AI Coding Agents in May 2026 and sizes the market at roughly $10–11 billion a year. Claude Code alone passed a $2.5 billion run-rate in early 2026, and Cursor reported growth from $2 billion to over $4 billion run-rate between February and June 2026. Enterprises are paying for this, at scale.\n\n## 9. The economics: cheaper tokens, bigger bills\n\nFirst, a paradox every CFO will meet: tokens get cheaper, bills get bigger. The price of a fixed level of AI capability falls roughly 10× a year (a16z) and by a median of 50× a year on Epoch AI's measures. Yet spend per developer is rising: Anthropic's own estimate of a typical Claude Code day went from about $6 to about $13 in a year, a quarter of technology leaders already spend $200–500 per developer per month (Gartner), and Gartner expects AI coding cost per engineer to exceed the average developer's salary by 2028. Cheaper intelligence means agents do longer, more autonomous work, and that work costs money. Gartner's warning is blunt: without a governed engineering operating model, costs can escalate faster than the productivity gains.\n\n![Constant-capability cost per million tokens: $60 in 2021 to $0.06 in 2024, ~10× cheaper yearly (a16z); Epoch AI median 50× yearly. Claude Code typical cost per developer per active day: $6 in 2025 to $13 in 2026. A quarter of tech leaders spend $200–500 per developer per month. Uber exhausted its 2026 AI-coding budget in ~4 months. Gartner forecasts AI coding cost per engineer exceeding average developer salary by 2028.](https://f200.ai/media/editorial/1565a0b208829438335be163ee15ccf580a8483afe371f4adc147ff6e8113f8b.webp)Lower token prices coexist with rising bills. Budgets belong inside the factory.\n\nWe won't give you a made-up ROI number. Here is the model we use with clients instead, so you can plug in your own figures.\n\n![Engineer cost times measured throughput gain yields extra-output value. Subtract agent spend, review time and factory operation, then adjust for quality to find net quarterly team value.](https://f200.ai/media/editorial/0f8072cb79b17daa9e7636562a36709a06f610433ecd32454d8fa602861e3442.webp)A simple economic model (use your own numbers)\n\n- Start from the fully loaded cost of an engineer. The US median software developer wage alone is about $133,000 (BLS, 2024), before benefits and overhead.\n\n- Apply a measured, conservative throughput gain. 20–25% is what the controlled studies support for well-run teams.\n\n- Subtract the new costs. Agent and model spend, more review time, and the time to build and run the factory itself.\n\n- Adjust for quality. Escaped defects and security incidents cost far more than the code that caused them, so verification is worth paying for.\n\nRun the numbers per team, measure for a quarter, and decide with data. The METR study is the reason: if you rely on how productive people feel, you can be off by 40 points.\n\n## 10. What this means at your stage\n\nThe software factory looks different for a solo founder and for an enterprise. The principles are the same.\n\n![Four growth stages compare constraints, initial factory capabilities and payoffs, with governance increasing from solo founder to enterprise.](https://f200.ai/media/editorial/a49a1a4acab16d10596d71da4e9644da4fe0ea19348b40d27063a874d862822c.webp)The software factory at every stage\n\n### Solo founders and indie builders\n\nSolo founding is rising fast: the share of new startups with a single founder went from 23.7% in 2019 to 36.3% in the first half of 2025 (Carta). In Y Combinator's Winter 2025 batch, a quarter of companies had codebases that were about 95% AI-written.\n\n![Solo founders accounted for 23.7% of new startups in 2019 and 36.3% in H1 2025. 25% of YC Winter 2025 had codebases ~95% AI-generated. Solo founders received 14.7% of priced-round cash in 2024.](https://f200.ai/media/editorial/87d0c9a15ca2808ac307f48d91d550f4db2217bf5278076d9a6359782414fd38.webp)The solo-founder share of new startups rose to 36.3% in H1 2025, while YC reported extensive AI-generated code in a quarter of its winter batch.\n\nThe economics of small teams have changed. Base44, a bootstrapped company with one founder, was sold to Wix for $80 million in cash six months after launch. Lovable reported about $2.7 million of revenue per employee in early 2026, against a median of about $141,000 for private SaaS companies. Gartner expects 60% of organisations to run \"tiny\" software teams of two to five people by 2029, up from 15% in 2026, and warns that cutting junior roles weakens the talent pipeline.\n\n![Revenue per employee: Lovable ~$2.7M (Feb 2026, company statement) versus median private SaaS $141K (2026, SaaS Capital). Base44: solo-founded, sold to Wix for $80M cash after 6 months (Jun 2025). Gartner forecast: organizations running tiny 2–5 person software teams rise from 15% in 2026 to 60% in 2029.](https://f200.ai/media/editorial/d71b7b565dff570a08eb38da6f26600d1c87ff0ba503e3ee2155b81e5940e4b9.webp)Lovable reports ~$2.7M revenue per employee; Base44 sold for $80M after six months; Gartner forecasts more tiny software teams.\n\n![A single faceless founder at a helm beside a lighthouse directs identical boats along coordinated magenta courses across a nautical chart.](https://f200.ai/media/editorial/a25d3ae6722479ba1b3ec1ee65496c1eef53cff2c98ba34688a8f0a3cdc2f4e3.webp)One founder sets the course for a fleet of agents.\n\nFor a solo founder, the factory is a force multiplier: you are the product owner, the reviewer and the release manager, and the agents are your team. What you need most:\n\n- A queue and small tasks, so agents work on the right thing in the right order.\n\n- Automatic verification, because you can't review everything by hand.\n\n- Budgets, because a runaway agent loop is your burn rate.\n\n- Memory, so you don't re-explain your product to every new session.\n\n### Startups and scale-ups\n\nYour constraint is senior engineering time. The factory turns your best engineers into specifiers and reviewers and lets agents absorb implementation, migrations, tests and maintenance. Watch the review bottleneck most closely: if PRs pile up, add risk tiers (low-risk changes need one review, infrastructure needs more) rather than more reviewers.\n\n### Enterprises\n\nYour constraint is risk and governance. You need policy as code, audit trails, approvals routed to the right people, spend caps per team, and evidence that controls work. The Gartner Magic Quadrant exists because this buyer exists. The factory is how you let hundreds of agents work without losing control of what reaches production.\n\n## 11. How to start: a 90-day plan\n\n![A three-phase roadmap: measure and pilot in days 1–30, add factory parts in days 31–60, and scale what the data supports in days 61–90, with data-driven checkpoints.](https://f200.ai/media/editorial/3a745ee9435964759d2cbec2b46c395ab196666a54a6f19c67ec81da901d3f27.webp)Your first 90 days\n\nDays 1–30: measure and pilot. Pick one team and one workflow, such as test writing, dependency upgrades or internal tools. Baseline the metrics you care about: lead time, merged work, escaped defects, review time and spend. Give agents sandboxed workspaces and a short list of things they may never do.\n\nDays 31–60: add the factory parts. Put work into a queue with small, well-defined items. Make verification mandatory: an agent's turn isn't finished until the declared checks pass. Introduce risk-tiered review and a merge pipeline that only merges the exact commit that was verified and reviewed. Set budgets.\n\nDays 61–90: scale what the data supports. Compare against the baseline. Expand to more teams only where the measured numbers moved. Add memory so agents stop repeating work. Report value in business terms: lead time, quality, cost per change.\n\n![Boats follow two orderly magenta lanes between navy buoys through a harbour gatehouse with a green signal and an open logbook on the pier.](https://f200.ai/media/editorial/ffe18f4a102adc6d62855e3e614a2b25e3cb626d13c8f8ab9d911a821f0c83c0.webp)Governance provides clear lanes, permission signals, and a record of passage without slowing traffic.\n\n## 12. The honest risks\n\nA software factory is not magic, and the research is clear about what can go wrong:\n\n- Perception is unreliable. Measure outcomes, not sentiment.\n\n- Review quality decays. Reviewers get used to approving agent work. Make verification automatic and keep human review focused where risk is high.\n\n- Security and maintainability. AI code can multiply vulnerabilities and duplication without the right gates.\n\n- Understanding. Developers who let agents do everything understand their code less. Keep people in the design and review loop.\n\n- Cost. Without budgets and routing, agent spend can grow faster than the value.\n\nEvery one of these risks is a reason to build the factory, not a reason to avoid AI. The companies that will lose are the ones that adopt agents without the system around them.\n\n## 13. How f200 approaches this\n\nWe build and run AI software factories, for ourselves and for clients. Our own engineering has run on Shiftyard, our factory for coding agents, since October 2026. It is pre-release and will be open source under Apache-2.0; you can read the [technical deep-dive](https://f200.ai/blog/inside-shiftyard-governed-software-factory-for-coding-agents). For clients, our Software Factory Integration service designs and installs the queue, gates, verification, review and memory around the agents your teams already use.\n\nIf you want to know what a software factory would mean for your company, at your stage, book a 30-minute call with the founders. We'll start with your workflow and your numbers, not with a tool.\n\n## Sources\n\n- Peng et al., The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv 2302.06590, Feb 2023. [https://arxiv.org/abs/2302.06590](https://arxiv.org/abs/2302.06590)\n\n- Paradis et al., How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv 2410.12944, Oct 2024. [https://arxiv.org/abs/2410.12944](https://arxiv.org/abs/2410.12944)\n\n- Cui, Demirer, Jaffe, Musolff, Peng, Salz, The Effects of Generative AI on High-Skilled Work, Management Science, 2025. [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566)\n\n- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, Jul 2025; and uplift update, Feb 2026. [https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf](https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf) · [https://metr.org/blog/2026-02-24-uplift-update/](https://metr.org/blog/2026-02-24-uplift-update/)\n\n- Murphy-Hill, Butler, Savelieva (Microsoft), Adoption and Impact of Command-Line AI Coding Agents, arXiv 2607.01418, Jul 2026. [https://arxiv.org/abs/2607.01418](https://arxiv.org/abs/2607.01418)\n\n- Faros AI, Lab vs. Reality: AI productivity study findings, Jul 2025. [https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings](https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings)\n\n- Google DORA, State of AI-assisted Software Development 2025, Sep 2025. [https://dora.dev/research/2025/dora-report/](https://dora.dev/research/2025/dora-report/)\n\n- Stack Overflow, 2025 Developer Survey (Jul 2025) and survey look-back (Sep 2026). [https://survey.stackoverflow.co/2025/](https://survey.stackoverflow.co/2025/) · [https://stackoverflow.blog/2026/09/30/getting-ready-for-2026-results-a-look-back-on-developer-survey-findings/](https://stackoverflow.blog/2026/09/30/getting-ready-for-2026-results-a-look-back-on-developer-survey-findings/)\n\n- JetBrains, State of Developer Ecosystem 2025, Oct 2025. [https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/](https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/)\n\n- GitClear, AI code quality report, Feb 2025. [https://gitclear-public.s3.us-west-2.amazonaws.com/GitClear-AI-Copilot-Code-Quality-2025.pdf](https://gitclear-public.s3.us-west-2.amazonaws.com/GitClear-AI-Copilot-Code-Quality-2025.pdf)\n\n- Veracode, 2025 GenAI Code Security Report, Jul 2025. [https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/](https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/)\n\n- Apiiro, 4x Velocity, 10x Vulnerabilities, Sep 2025. [https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/](https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/)\n\n- METR, time-horizon benchmark results v1.1 (accessed Oct 2026). [https://metr.org/time-horizons/](https://metr.org/time-horizons/)\n\n- OpenAI, Why we no longer evaluate SWE-bench Verified, Feb 2026. [https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/)\n\n- Stanford HAI, 2026 AI Index Report. [https://hai.stanford.edu/ai-index/2026-ai-index-report](https://hai.stanford.edu/ai-index/2026-ai-index-report)\n\n- Gartner, software engineering trends press release, Jul 2025; Magic Quadrant for Enterprise AI Coding Agents, May 2026 (as reported by Virtualization Review). [https://www.gartner.com/en/newsroom/press-releases/2025-07-01-gartner-identifies-the-top-strategic-trends-in-software-engineering-for-2025-and-beyond](https://www.gartner.com/en/newsroom/press-releases/2025-07-01-gartner-identifies-the-top-strategic-trends-in-software-engineering-for-2025-and-beyond) · [https://virtualizationreview.com/articles/2026/06/05/ai-firms-push-cloud-giants-from-leaders-quadrant-in-gartner-ai-coding-report.aspx](https://virtualizationreview.com/articles/2026/06/05/ai-firms-push-cloud-giants-from-leaders-quadrant-in-gartner-ai-coding-report.aspx)\n\n- McKinsey, Unlocking the value of AI in software development. [https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/unlocking-the-value-of-ai-in-software-development](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/unlocking-the-value-of-ai-in-software-development)\n\n- Google, Cloud Next 2026 keynote remarks on AI-generated code (as reported by The Decoder). [https://the-decoder.com/google-says-75-percent-of-its-new-code-is-now-written-by-ai/](https://the-decoder.com/google-says-75-percent-of-its-new-code-is-now-written-by-ai/)\n\n- Anthropic, Series G announcement, Feb 2026. [https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation](https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation)\n\n- Cursor revenue run-rate, Dealroom, Jun 2026. [https://dealroom.co/news/134107-cursor-tops-4b-annualized-revenue/](https://dealroom.co/news/134107-cursor-tops-4b-annualized-revenue/)\n\n- TechCrunch, Y Combinator W25 AI-generated codebases, Mar 2025. [https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/](https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/)\n\n- Carta, Solo Founders Report 2025, Dec 2025. [https://carta.com/data/solo-founders-report/](https://carta.com/data/solo-founders-report/)\n\n- US Bureau of Labor Statistics, Occupational Outlook Handbook: Software Developers. [https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm)\n\n- Habituation at the Gate, arXiv 2606.22721, 2026. [https://arxiv.org/abs/2606.22721](https://arxiv.org/abs/2606.22721)\n\n- Kraishan, agent PR security and maintenance study, arXiv 2609.17598, 2026. [https://arxiv.org/abs/2609.17598](https://arxiv.org/abs/2609.17598)\n\n- Purdue agent cost study, arXiv 2609.30725, 2026. [https://arxiv.org/abs/2609.30725](https://arxiv.org/abs/2609.30725)\n\n- GitHub, Octoverse 2025, Oct 2025. [https://octoverse.github.com/](https://octoverse.github.com/)\n\n- GitHub API, star counts for open-source coding-agent repositories, 8 Oct 2026. [https://api.github.com/repos/anomalyco/opencode](https://api.github.com/repos/anomalyco/opencode) · [https://api.github.com/repos/anthropics/claude-code](https://api.github.com/repos/anthropics/claude-code) · [https://api.github.com/repos/openai/codex](https://api.github.com/repos/openai/codex) · [https://api.github.com/repos/google-gemini/gemini-cli](https://api.github.com/repos/google-gemini/gemini-cli) · [https://api.github.com/repos/OpenHands/OpenHands](https://api.github.com/repos/OpenHands/OpenHands) · [https://api.github.com/repos/FoundationAgents/MetaGPT](https://api.github.com/repos/FoundationAgents/MetaGPT) · [https://api.github.com/repos/cline/cline](https://api.github.com/repos/cline/cline) · [https://api.github.com/repos/block/goose](https://api.github.com/repos/block/goose) · [https://api.github.com/repos/Aider-AI/aider](https://api.github.com/repos/Aider-AI/aider) · [https://api.github.com/repos/continuedev/continue](https://api.github.com/repos/continuedev/continue) · [https://api.github.com/repos/OpenBMB/ChatDev](https://api.github.com/repos/OpenBMB/ChatDev) · [https://api.github.com/repos/Kilo-Org/kilocode](https://api.github.com/repos/Kilo-Org/kilocode) · [https://api.github.com/repos/RooCodeInc/Roo-Code](https://api.github.com/repos/RooCodeInc/Roo-Code) · [https://api.github.com/repos/SWE-agent/SWE-agent](https://api.github.com/repos/SWE-agent/SWE-agent) · [https://docs.github.com/en/rest/repos/repos#get-a-repository](https://docs.github.com/en/rest/repos/repos#get-a-repository)\n\n- McKinsey, Technology Trends Outlook 2026, Sep 2026 (as reported by CIO Dive). [https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-top-trends-in-tech](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-top-trends-in-tech)\n\n- Stripe Engineering, Minions: Stripe's one-shot, end-to-end coding agents, Feb 2026. [https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2)\n\n- Airbnb Tech Blog, test migration case study, Mar 2025. [https://medium.com/airbnb-engineering/accelerating-large-scale-test-migration-with-llms-9565c208023b](https://medium.com/airbnb-engineering/accelerating-large-scale-test-migration-with-llms-9565c208023b)\n\n- AWS DevOps Blog, Amazon Q Developer just reached a $260 million dollar milestone, Aug 2024. [https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/](https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/)\n\n- Uber Engineering, uReview, Aug 2025; The Pragmatic Engineer, How Uber uses AI for development, Mar 2026; Fortune, May 2026. [https://www.uber.com/gb/en/blog/ureview/](https://www.uber.com/gb/en/blog/ureview/) · [https://newsletter.pragmaticengineer.com/p/how-uber-uses-ai-for-development](https://newsletter.pragmaticengineer.com/p/how-uber-uses-ai-for-development) · [https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/](https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/)\n\n- Amplifying, State of the Coding Agent Market, Oct 2026. [https://amplifying.ai/research/state-of-coding-agents](https://amplifying.ai/research/state-of-coding-agents)\n\n- Takerngsaksiri et al., follow-up fixes after agent merges, arXiv 2609.26847, Sep 2026. [https://arxiv.org/abs/2609.26847](https://arxiv.org/abs/2609.26847)\n\n- SWE-chat, Stanford, arXiv 2604.20779, Apr 2026. [https://arxiv.org/abs/2604.20779](https://arxiv.org/abs/2604.20779)\n\n- Atlassian, State of Developer Experience 2025. [https://www.atlassian.com/teams/software-development/state-of-developer-experience-2025](https://www.atlassian.com/teams/software-development/state-of-developer-experience-2025)\n\n- a16z, LLMflation, Nov 2024; Epoch AI, LLM inference price trends. [https://a16z.com/llmflation-llm-inference-cost/](https://a16z.com/llmflation-llm-inference-cost/) · [https://epoch.ai/data-insights/llm-inference-price-trends](https://epoch.ai/data-insights/llm-inference-price-trends)\n\n- Anthropic, Claude Code cost documentation. [https://code.claude.com/docs/en/costs](https://code.claude.com/docs/en/costs)\n\n- Gartner press releases on AI coding costs (Jun 2026) and tiny software teams (Jul 2026). [https://www.gartner.com/en/newsroom/press-releases/2026-06-24-gartner-predicts-ai-coding-costs-will-surpass-average-developer-salary-by-2028-as-token-consumption-surges](https://www.gartner.com/en/newsroom/press-releases/2026-06-24-gartner-predicts-ai-coding-costs-will-surpass-average-developer-salary-by-2028-as-token-consumption-surges) · [https://www.gartner.com/en/newsroom/press-releases/2026-07-07-gartner-predicts-60-percent-of-organizations-will-adopt-smaller-software-engineering-teams-by-2029](https://www.gartner.com/en/newsroom/press-releases/2026-07-07-gartner-predicts-60-percent-of-organizations-will-adopt-smaller-software-engineering-teams-by-2029)\n\n- SaaS Capital, revenue-per-employee benchmarks for private SaaS companies. [https://www.saas-capital.com/blog-posts/revenue-per-employee-benchmarks-for-private-saas-companies/](https://www.saas-capital.com/blog-posts/revenue-per-employee-benchmarks-for-private-saas-companies/)\n\n- TechCrunch, Wix acquires Base44, Jun 2025. [https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/)\n\n- Company statements on AI-generated code share, as reported: Google (Apr 2026), Robinhood (Jul 2025), Coinbase (2025), Microsoft (Apr 2025), Uber (May 2026). [https://the-decoder.com/google-says-75-percent-of-its-new-code-is-now-written-by-ai/](https://the-decoder.com/google-says-75-percent-of-its-new-code-is-now-written-by-ai/) · [https://www.aol.com/robinhood-ceo-says-majority-companys-094801868.html](https://www.aol.com/robinhood-ceo-says-majority-companys-094801868.html) · [https://www.theblock.co/news/business/2025-09-04-brian-armstrong-coinbase-ai-369460](https://www.theblock.co/news/business/2025-09-04-brian-armstrong-coinbase-ai-369460) · [https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-30-of-the-companys-code-was-written-by-ai/](https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-30-of-the-companys-code-was-written-by-ai/) · [https://fortune.com/company/uber-technologies/earnings/q1-2026/](https://fortune.com/company/uber-technologies/earnings/q1-2026/)\n","publishedAt":"2026-10-07T19:59:45.685Z","url":"https://f200.ai/blog/software-factories-why-every-company-needs-one"}],"sequence":1126}