Key takeaways
  • Anthropic writes over 90% of its production code with AI; Google is at 75% of new code, up from 25% a year ago. OpenAI engineers who lean fully into their internal agent open 70% more pull requests.
  • A software factory is not engineers using Copilot faster. It is agents writing the code while humans design the line, and it requires three things: infrastructure, process design, and change management.
  • Four questions audit whether you have one: live system access, persistent agent context, defined exception criteria, and agent-built code shipped to production in the last 30 days. A no on any of them means you are still running the craft model.

Anthropic says more than 90% of its production code is AI-written. Google says 75% of new code is AI-generated, up from 25% a year ago. Individual founders are shipping the output of 20-person engineering teams solo. Something changed in how software gets made, and you need to understand what's actually happening.

This is not "developers using AI tools." This is a different model of software production entirely. And most companies are not running it, even the ones that think they are.

The Craft Model vs. the Factory Model

Strip away the jargon. Two models.

The craft model: a human sits down and writes the code by hand. Output scales with how many skilled engineers you can hire and how fast they can type. Context lives in people's heads. Each feature is bespoke. The codebase gets harder to work with over time because each addition injects more complexity.

The factory model: the work is industrialized. There's a repeatable production line: write, review, test, deploy, monitor. Software moves through it with standardized steps, automated quality checks, and minimal manual labor. Humans design the line and handle exceptions. Agents do the reps.

The most important distinction: a factory is not "humans coding faster with AI." It's a system where humans move up a level. From doing the work to directing it.

The craft model still running in most companies

Humans write. Output scales with headcount.

Output model
Engineers write features by hand; output scales with headcount
Review process
Manual: another human reads every line
Context storage
Lives in people's heads; onboarding takes months
Complexity over time
Each new feature adds complexity the next engineer has to navigate
Role of AI
AI tools used as faster autocomplete, not as a production system
The factory model

Agents write. Humans design the line.

Output model
Agents write the code; engineers design the system and review outputs
Review process
Quality checks are automated: tests, linting, type checking run at every step
Context storage
Lives in documented systems the agent can read: CLAUDE.md, skills, memory
Complexity over time
Each new feature teaches the system new capabilities for the next build
Role of AI
AI is the production worker; the human is the factory floor designer

The Proof Points Are Real

Don't let this feel theoretical. The data is already here.

By the numbers
90%+
Anthropic's production code written by AI. Not a pilot. Not a skunkworks team. Their primary engineering output.
75%
Google's new code that is AI-generated, as of early 2026. Up from 25% a year ago.
1,000+ PRs
Shipped by one founder running a code factory. Agents write, review, test, and watch production while he sets guardrails.
70% more
Pull requests opened by engineers at OpenAI who lean fully into their internal agent vs. those who don't.
Share of Code Now AI-Generated
Anthropic
90%+
OpenAI (engineers)
95%
Google (new code)
75%

Source: Alex Barasa (@businessbarista), June 2026, citing Anthropic, Google, and OpenAI internal figures.

Why Most Companies Are Not Running a Factory

The gap between what CEOs think they have and what they actually have is large. Here's what most companies actually have.

Engineers using Copilot or Cursor to write code faster. Individual productivity is up 20–30%. The output model is unchanged: humans design, humans write, humans review, humans deploy.

That is the craft model with a faster pencil. It is not a factory.

A real software factory requires three things most companies haven't built.

Requirement 01
Infrastructure

A git workflow where agents can open branches, run tests, and submit pull requests. A skills system that gives agents reusable context across builds. A memory layer that lets agents learn from previous work. An MCP layer connecting agents to the live internal systems they need to act on.

Requirement 02
Process design

Defined criteria for what agents handle autonomously vs. what gets escalated. Output quality gates before anything merges. Exception handling that surfaces edge cases without stalling the line.

Requirement 03
Change management

Engineers who understand their new role is designing the line and reviewing agent output, not writing every line themselves. The tools can be installed in a day. The mental model takes longer.

Kieran Klaassen at Every.to calls the underlying philosophy compound engineering: the principle that each unit of work should make subsequent units easier. Bug fixes eliminate entire categories of future bugs. Patterns become reusable tools. The system gets easier to extend over time, not harder. Most codebases work in the opposite direction. A software factory is the infrastructure that makes compounding possible.

What Garry Tan Learned Building 540,000 Lines

Garry Tan, gStack author and YC partner, built a 540,000-line Rails application using AI agents. Then he realized he'd built the wrong thing. He'd used AI to do more of what he'd been doing in 2013: more code, more tests, more complexity. He'd upgraded the engine and kept the 2013 mental model.

"The 2013 engineer believes one thing in his bones: capability equals lines of code. That belief was correct for decades, until now." — Garry Tan

The shift is from code-as-capability to instructions-as-capability. The behavior lives in markdown and system prompts you can edit in plain language, not logic frozen in code the day you wrote it.

The factory is not about writing more code. It's about writing less, and making the code that does exist easier to understand, extend, and replace.

What a Factory Actually Needs an Operator For

A software factory is not a product you buy. It's a system you build. The tools are accessible: Claude Code, Codex, Cursor, MCP servers. The infrastructure pieces are standard. But assembling them into a working production line inside a specific company's existing systems, data architecture, and engineering workflow takes an operator.

What the operator builds in the First Build, 2 weeks:

The First Build is the first production run. The Install is the full factory.

How to Audit Where Your Company Is

Four questions. Answer them honestly.

If the answer to any of these is no, you are running the craft model with AI tools. That's a reasonable place to start. But it's not a factory.

Ready to build the line?

Book a free Diagnostic: 30–45 minutes, no deck, no pitch. We map which function in your factory to close first, what the MCP layer and orchestration look like, and what it takes to have the first loop running in production.

Book the Diagnostic →
Sources
1Garry Tan, GStack, AI agent harness, GitHub, 2026.
2Tom Blomfield (YC General Partner), How to Build a Self-Improving Company with AI, YC Root Access, May 2026.
3Garry Tan, "Stop Building Foxconn Factories for Your Agents", X, June 2026. On just-in-time software and the shift from code-as-capability to instruction-as-capability.
4Alex Barasa (@businessbarista), "What the hell is a Software Factory?", X, June 2026. Non-technical breakdown of the software factory model; cites Anthropic, Google, and OpenAI internal figures.
5Kieran Klaassen & Every.to, "Compound Engineering", Every.to, Jan 2026. The AI-native engineering philosophy behind the factory model.
John Tan
John Tan

Fractional AI & Product Founder at nativefirst.ai. Ex-CEO, Depict (Y Combinator). Embeds on-site with scaling founders and CEOs to ship Level-3 agents and AI workflows in production.