AI coding has officially become big business.
This week, Factory, a startup building AI coding agents for enterprise engineering teams, raised $200 million at a $5 billion valuation.
That valuation reportedly more than tripled from its previous round.
And Factory is only one company in a rapidly growing market around tools such as Claude Code, GitHub Copilot, Cursor, Codex, and other coding agents.
But this made me wonder:
If many of these products can access the same or similar foundation models, what are developers and companies actually paying for?
I don't think the answer is simply:
"Better code generation."
The real product is becoming much bigger than the model.
We Already Know AI Can Generate Code
A few years ago, generating a useful function from a prompt felt impressive.
Today, that's almost expected.
You can ask an AI model to:
- create a React component
- write an API endpoint
- generate SQL
- explain unfamiliar code
- write unit tests
- refactor a function
- fix a TypeScript error
Useful?
Absolutely.
But increasingly, that alone isn't enough to justify an entire coding platform.
The more interesting question is:
Can the AI understand my project and actually complete the work?
And that requires much more than an LLM.
The Model Is Only One Layer
A basic AI coding tool might look like this:
Developer
↓
Prompt
↓
LLM
↓
Generated Code
A modern coding agent looks more like this:
Developer Goal
↓
Agent
↓
Planning
↓
Repository Context
↓
Search / Tools
↓
Terminal
↓
Code Changes
↓
Tests
↓
Browser
↓
Git Diff
↓
Human Review
The LLM is still extremely important.
But look at everything surrounding it.
That surrounding system is becoming the product.
1. Developers Are Paying for Context
Imagine asking an AI:
"Fix the authentication bug."
To solve that correctly, it may need to understand:
- your routes
- authentication middleware
- database schema
- environment configuration
- coding conventions
- related tests
- previous implementations
Sending your entire repository to a model every time is neither practical nor necessarily useful.
A good coding agent needs to decide:
Which context matters for this particular task?
That is a very different engineering problem from simply calling an LLM API.
Anthropic's own research into roughly 400,000 Claude Code sessions found that human users typically made most of the planning decisions while Claude made more of the execution decisions.
Interestingly, Anthropic also found that users with greater domain expertise tended to get more work from Claude per instruction.
In other words:
Better models matter, but good context and good direction still matter too.
2. Developers Are Paying for Tools
Consider this request:
"Fix the checkout bug and verify it works."
Generating code is only part of that task.
A useful agent may need to:
Search repository
↓
Read relevant files
↓
Edit code
↓
Run tests
↓
Start application
↓
Open browser
↓
Reproduce checkout flow
↓
Inspect error
↓
Modify code again
↓
Run tests again
↓
Show developer the diff
This is why coding products are increasingly integrating more tools.
GitHub, for example, now gives Copilot agents browser capabilities alongside the editor and terminal. Its recent Copilot workflow specifically emphasizes reviewing the diff, running terminal commands, and checking the application in a browser.
The value isn't simply:
AI writes code.
It's becoming:
AI can participate in the engineering workflow.
3. Developers Are Paying for the Agent Loop
One of the biggest differences between autocomplete and an agent is the ability to continue working.
Autocomplete:
Prompt → Generate
Agent:
Understand
↓
Plan
↓
Act
↓
Observe
↓
Evaluate
↓
Correct
↓
Repeat
This loop is powerful.
Suppose the agent changes a function and a test fails.
A basic generator gives you the code and stops.
An agent can potentially:
- read the failure
- inspect the relevant code
- determine why the test failed
- modify the implementation
- rerun the test
- continue until the task succeeds or needs human input
That's much closer to how engineers actually work.
4. Developers Are Paying for Model Choice
There's another interesting shift happening.
The future may not be:
Claude vs GPT vs Gemini — pick one forever.
It may look more like:
Coding Platform
/ | \
/ | \
Claude GPT Gemini
| | |
└───────┼────────┘
↓
Agent Harness
↓
Repo → Tools → Tests → Browser → Git
GitHub has already been expanding model choice in Copilot, including support for additional providers and bring-your-own-key workflows.
Factory describes its system as spanning planning, implementation, testing, security and other parts of the software development lifecycle.
Factory also recently became available through Anthropic's Claude Marketplace.
That tells us something important.
The model and the coding product don't necessarily have to be the same thing.
A coding platform can potentially choose different models for different tasks.
For example:
Powerful model → architecture and planning
Fast model → simple edits
Cheap model → repetitive tasks
Specialized model → code review
This could make the orchestration layer increasingly valuable.
5. Companies Are Paying for Control
For an individual developer experimenting on a side project, giving an AI terminal access may feel harmless.
Inside a large company?
Very different story.
A coding agent might interact with:
- private source code
- internal APIs
- CI/CD
- production infrastructure
- customer data
- cloud credentials
- security systems
Now the questions become much more serious.
What can the agent access?
Which commands can it execute?
What requires human approval?
What gets logged?
Can it access production?
Can administrators restrict certain tools?
Anthropic itself notes that agent autonomy introduces additional risks because agents operate with less human supervision and can also be targets of attacks such as prompt injection.
So enterprise buyers aren't only paying for intelligence.
They're paying for:
Permissions + Security + Auditability + Governance
These aren't glamorous features.
But inside real companies, they matter enormously.
So What Are Developers Actually Paying For?
I think we can summarize it like this:
AI Coding Product
Model
+
Context
+
Planning
+
Repository Understanding
+
Tools
+
Terminal
+
Browser
+
Testing
+
Git Integration
+
Permissions
+
Security
+
Human Review
+
Agent Loop
The model provides intelligence.
The rest turns that intelligence into a usable engineering system.
Why Factory's $5B Valuation Is Interesting
Factory's valuation doesn't prove that coding agents will deliver on every expectation surrounding them.
Valuations reflect investor expectations, not guaranteed future outcomes.
But the investment does show how valuable the market currently believes this layer could become.
Reuters reported on September 15 that Factory raised $200 million at a $5 billion valuation, highlighting strong investor interest in AI tools designed to improve software engineering productivity.
Factory itself says the funding will help scale what it describes as self-improving software development in the enterprise.
The important part for developers isn't the $5 billion number.
It's what investors and companies appear to believe sits behind that number:
AI may become part of the entire software-development lifecycle—not merely a smarter autocomplete box.
The AI Coding War Is Changing
For the last few years, we kept asking:
"Which model writes the best code?"
Claude?
GPT?
Gemini?
Another model?
That question still matters.
But I think another question is becoming just as important:
Which product can turn a good model into the best software engineering workflow?
The winning coding platform may not necessarily own the smartest model.
It may be the platform that best understands:
your repository
your tools
your tests
your engineering rules
your infrastructure
your permissions
your team
That is a much bigger product.
My Take as a Software Engineer
I'm becoming less interested in whether an AI can generate another React component.
Most leading models can already generate decent code.
What matters more to me is:
Can it understand the system?
Can it find the right files?
Can it make the smallest correct change?
Can it test its own work?
Can it recognize when it is uncertain?
Can I review exactly what it changed?
Can I control what it is allowed to touch?
That is where coding agents become genuinely useful.
And it's probably where much of the next competition in AI coding will happen.
Final Thought
AI coding started with:
"Write this function for me."
Then it became:
"Build this feature for me."
Now we're moving toward:
"Take this engineering task, work through the repository, use the necessary tools, test your solution, and bring me the result."
That's a fundamentally different product.
So when an AI coding-agent company reaches a multi-billion-dollar valuation, developers shouldn't only ask:
"Which model does it use?"
The better question may be:
"What has it built around the model that makes the model useful?"
Because increasingly, the model isn't the whole product.
The engineering system around it is.
Sources
Reuters — September 15, 2026
Factory raises $200M at a $5B valuation.
Factory — September 15, 2026
Factory raises $200M at $5B valuation to scale enterprise software-development automation.
Anthropic Research — June 2026
Analysis of approximately 400,000 Claude Code sessions and how developers use agentic coding in practice.
GitHub — September 2026
GitHub Copilot workflows combining code diff, terminal execution, and browser-based validation.
Anthropic — Trustworthy Agents in Practice
Research and guidance on autonomy, permissions, security, and agent risks.
Top comments (2)
I agree. The model matters, but context, tools, permissions, verification, and human review are what make it useful in real engineering work.
The question is increasingly not just which model to use, but how to build a workflow around it that gives the model the right context and produces work we can actually verify and trust. Great post.
What I think is much harder is making agents for the general population. As a dev, you find a way around the tech- LLMs; you loop them, make sense of the Context, persist memory, skills.. But for the suburban mom, how can you create a use case that gives her real benefit from this tech?