Coding-Agent Dependency Checklist: Factory's $5B Jump

You are deciding whether one AI coding agent can sit in every build path. Factory raised $200 million in a round announced Sept. 15, 2026, lifting its valuation to $5 billion. That followed a $150 million raise in April 2026 at a $1.5 billion valuation. The jump turns a tooling choice into a vendor choice.

A valuation jump is a dependency warning

When a core vendor's price rises, you re-evaluate the relationship. Enterprise coding agents are moving into the same category. Factory builds an enterprise platform where AI agents create, test, and maintain software, competing with Cognition and Cursor, both AI coding platforms. By Sept. 16, 2026, enterprise buyers were weighing Factory, Cognition, Cursor, and Poolside as separate options. The market is treating the category as infrastructure, so the dependency decision is now a business decision.

Blackstone, Khosla Ventures, Sequoia Capital, Insight Partners, Evantic Capital, and Sound Ventures participated in the financing. That kind of backing does not guarantee product quality, but it does raise the stakes. If the vendor is a core dependency, its balance sheet is part of your risk model.

As of Sept. 15, 2026, hundreds of thousands of developers use Factory's platform, including people employed by Nvidia, Adobe, and Palo Alto Networks. In January 2026, large language models were described as automatically improving Factory's agents from anonymized signals across thousands of daily sessions. That combination raises the operational question: how much of your build path depends on the tool?

Run the dependency test before standardizing

A dependency is a tool you rely on when the business is under pressure. The test is whether you can model the cost of that reliance before the reliance becomes real. Start with the unit of value. Is the agent priced by seat, by repository, by compute, or by outcome? A pricing unit that mismatches the way your team consumes the tool will drift.

Then map the data path. When the agent improves from usage, you need to know what it learns, what it retains, and what you can revoke. Finally, rehearse the exit. A vendor that cannot describe a migration path is asking you to accept an open-ended commitment.

Pricing power and data feedback decide whether the tool compounds in your favor or against you. Vendor viability, integration lock-in, and exit path decide whether you can leave. Each item below should be answerable in a meeting, not a diligence project.

• Pricing power. Can you predict renewal cost per engineer, per repository, or per agent run? Ask for the unit price, the usage meter, and the renewal assumption. Unclear answers turn the vendor into a bet.
• Data feedback. What usage signals leave your environment, and what do they improve? When the vendor's model improves from your anonymized sessions, you need the limits. Get what is retained, what is aggregated, and what you can disable.
• Vendor viability. Can the vendor survive a price war, a model provider shift, or a funding gap? Check the cap table, the customer base, and the product roadmap. A strong balance sheet helps, but it leaves operational risk.
• Integration lock-in. How much of your build, test, and release path depends on one interface? Map the touchpoints: build pipeline, code review, deployment, and incident response. Removing it should not mean rewriting any of those.
• Exit path. What can you export, and how long does migration take? Request a sample export, a migration estimate, and a support commitment. A promise without a date is not a plan.

Make the checklist produce outputs

Do not standardize on a coding agent until the checklist produces outputs. A cost model, a data boundary, and a migration plan are the minimum. A vendor that cannot answer in writing has answered. Vague answers should be priced into the decision. Missing answers should be treated as higher cost than the vendor's written quote.