Factory's Matan Grinberg: The Coming ‘Dark Factory’ Where Software Builds Itself
In a Nutshell
Factory builds autonomous software agents ("Droids") that aim to create fully autonomous "dark factories" where software builds itself. The company learned that enterprises demand model independence to avoid lock-in, and that success requires meeting developers where they are rather than forcing premature behavioral change. Their router dynamically allocates tasks across models based on cost and capability, moving from token-maxing toward intelligence allocation where frontier models handle high-stakes work and open models handle the rest.
These notes were generated by AI and may contain inaccuracies.
Bezos at Amazon focuses on customer obsession, but Factory views this as an input metric rather than an output. The distinction matters because a company can be customer obsessed while customers file restraining orders because they dislike the approach. The actual job is to build something so good that customers themselves become obsessed with the product. The basketball coach analogy illustrates this: telling players to sweat before a game is backwards because the goal is to score points, and sweating happens as a byproduct. Similarly, creating obsessed customers requires internal obsession with customers, but the output is what matters.
Matan Grinberg is co-founder and CEO of Factory, which builds droids—autonomous agents for software development. Factory started three and a half years ago in April 2023, when the enterprise was barely ready for GitHub Copilot, let alone fully autonomous agents. The first two years represented a "journey in the desert" because engineers and enterprise procurement teams were not ready for agents. During this period, the team honed its craft and learned how to build for developers in the enterprise.
Enterprises do not want any single provider to become a single point of failure or control their fate. Model independence emerged as a critical requirement after learning from cloud experiences where AWS or Azure would offer subsidized three-year contracts, then raise prices 10x at renewal. Enterprises now recognize that tools like Claude Code and Codex are excellent but cannot put their fate in any single model provider's hands. Model labs carry higher risk profiles than cloud providers due to internal drama, government conflicts, and other chaos. Developers want modularity so they can customize systems and hot-swap new models that are faster, cheaper, or more performant. This model independence is why large enterprises are moving momentum from Codex or Claude Code into Factory.
When enterprises question whether adopting Factory simply shifts lock-in from model labs to Factory itself, the answer is that all modularity ensures customer work stays in their codebase. Automations built and the skills registry created remain with the customer. Artifacts live in the customer's codebase rather than being held as tribal knowledge on Factory's side. Cost optimizations from arbitraging between models are passed to customers. This approach builds trust with enterprises.
Being two to three years early in vision is effectively the same as being wrong because there is no consolation prize for being early. The market either delivers or it does not. Enterprise sales does not come naturally to a physicist who had never held a job before dropping out of a PhD program. The team convinced 20 of the smartest people they knew to join, many with families and kids dedicating years to the mission, only to face customers who were not ready and models that were not yet performant enough.
Developers vote with their feet and are very clear about what they like and dislike. Giving developers an NPS survey is counterproductive because they inherently dislike whatever is being surveyed. The team became good at enterprise sales and reached nearly two million in revenue, but the product was not good enough. This created a ticking time bomb because developers would eventually turn against a product they did not like. The company made the difficult decision to proactively return all customer money because the product was not creating obsessed customers and did not align with their operating principle of building something customers would become obsessed with.
The product was not creating obsessed customers despite internal progress toward becoming more agent-native. The team wanted to maintain trust so they could return to customers later with a product that would "knock their socks off." Some customers reacted positively because they were not yet obsessed with the product. Others were confused. Enterprises are not used to receiving money back once budget is spent, and some did not even know if mechanisms existed to return funds. Investors received the news that revenue was about to drop to zero after being told it was increasing.
The team stayed together because of ruthless early hiring focused on people genuinely obsessed with the mission of bringing autonomy to software engineering. Everyone understood that the fate of the company was in their hands and each person had a part to play. Embracing how difficult the situation was proved valuable. Being honest that competitors' revenue was growing rapidly while Factory had returned all its revenue created shared understanding of the difficult position. These rock-bottom moments created the deepest bonds. The company's initial valuation was five million dollars, and unlike competitors who started as unicorns, Factory experienced being at the bottom. No one left during this period, creating resilience in the company's DNA.
The models getting better was not the most important change. The interaction pattern was too ambitious—fully autonomous agents required complete behavioral change from developers who were not yet using tools like Copilot. The Droid CLI launched on September 26, 2025, met developers where they were. By late 2025, most engineers were using autocomplete tools and many were starting to use chat interfaces for agentic changes. Developers had established workflows over 30 years and were initially resistant to AI tools replacing their craft. The shift came from developers lowering their guard, trying the tools, and developing intuition about necessary guardrails. Andre Karpathy tweeting about agents changed minds among engineers who trust his judgment. Both model improvements reducing required guardrails and developer willingness to experiment drove the change.
Frontier performance on benchmarks has a very short half-life because good benchmarks get benchmaxed within three to six months. Terminal Bench became the key benchmark at Droid CLI launch because it tested terminal settings and general software development tasks like scheduling runs rather than just Python scripting or individual file changes. SWEBench was too focused on Python and single-file changes. Terminal Bench is now heavily benchmaxed with newer models reaching 90% performance.
What keeps a harness at the frontier includes token caching rates since cached tokens cost roughly one-tenth as much. Performance during compression or compaction when sessions exceed context limits is critical—the harness must preserve important information through summarization, tested via "needle in the haystack" evaluations. Tool use quality and how the harness uses the environment to validate work also matter. Internal benchmarks compare out-of-the-box agents versus Factory's performance.
The initial assumption that training a model and building a harness together would make them better proved false. A harness supporting different models performs better because exposing a harness to more models avoids overfitting to any single model's nuances. This is analogous to training a personal AI on the whole internet rather than just personal data—the broader exposure produces better results. When new Opus or GPT models launched, they performed better in Droid than in Claude Code or Codex. Labs prefer co-design because it creates dependency on their harness, but multimodel exposure produces frontier performance across models.
Opus behaves like a super friendly colleague who might identify that some requested tasks are unnecessary and suggest alternatives while being personable. GPT 5.6 behaves like an agent that will complete every single task without stopping until finished.
Different harnesses have different strengths depending on how they are built. One harness might be very OCD and meticulous while another might realize that a list of 20 tasks could be done better with 5 or 6 more methodical steps. The Claude code harness was earlier really strict about sticking to the to-do list because the model itself would typically wander. Other models like Codex wouldn't do that because the model itself was really OCD about maintaining the list.
Users want the same experience regardless of which model they switch to. They need to ensure they don't suddenly lose track of what they are working on. Robust tool use is required for to-do lists so that users always see their to-do list. Cases where the to-do list would just not appear create problems during long sessions with compaction that might get lost in summarization.
The world moved through phases of AI adoption. Phase zero was when no one believed in AI. Phase one was when everyone believed in AI and boards asked CEOs about their AI strategy. Phase two involved CTOs putting AI usage in performance reviews and creating public rankings of who was using tokens the most because people were stubborn and skeptical.
Phase three became token maxing where people used Opus for literally everything including asking what the weather in SF was or telling me about Python. Banks were spending hundreds of thousands of dollars a month on people asking trivial questions that could be Googled. This happened because companies were so worried about adoption that they overcorrected with an adoption by any means necessary approach.
The factory router allows dynamic routing to different models based on the task. Asking about the weather doesn't require the frontier of human intelligence. For enterprises, not everyone needs the same tokens. Having a blanket token cap for every individual in a large bank makes no sense.
Every CIO will need to answer for every incremental token where to allocate it. Currently PMs doing vibe coding dashboards get the same token limits as engineers building critical infrastructure. Cobalt codebases might benefit from a fine-tuned model rather than Opus. The router can accommodate these constraints by routing vibe coding work to Gemini Flash, routing Cobalt work to a fine-tuned model, and routing critical reliability work through OpenAI for generation, Anthropic for testing, and Gemini for review.
Routing procedure instructions can be taken in natural language. Examples include giving specific people Flash because their work doesn't require frontier models, or avoiding open models for certain reasons. Internal benchmarking determines which models are better at which tasks.
GLM 5.2 is incredible. Internally Factory has no token limits for engineers and half of their tokens go to open models because they are faster, cheaper, and just as performant. The mistake people make is comparing GLM 5.2 to the latest frontier models like Opus 4.8 or GPT 5.6. Open models should be compared to Opus 4.7 or GPT 5.5 because they come a generation behind.
The frontier models will remain frontier. The question is whether open models are getting as good as frontier minus one, and the answer is unequivocally yes. This creates a garden of intelligence rather than a monopoly, allowing businesses to pick and choose models.
For a tutor in algebra for a daughter, a cheaper tutor than Albert Einstein would work fine. If she becomes a leading physicist, then Einstein-level intelligence might be needed, but most likely a high school student is sufficient and more cost-effective. The router enables this kind of intelligence allocation.
At the beginning of the year, less than 1% of tokens went to open models. In the first quarter it became single digit percent. It has now crossed into double digit percent of tokens. The forecast is that usage will asymptote toward the vast majority being open models because they provide more optionality and are cheaper.
There will never be 100% open model usage. The frontier of intelligence will always be valuable for every business because stakes are getting higher and intricate thinking is more important. Certain tasks will be offloaded to cheaper models.
This is analogous to how orgs are structured where engineering leaders are more tenured and have higher leverage brain power. A human engineer uses low brain power for much of their day but has moments of deep concentration on systems design problems. All low-leverage moments should be automated so high-leverage eureka moments can become hours at a time rather than brief moments.
Writing docs is a low-leverage use of expert engineers' time. Stripe had incredible docs that provided alpha, but those engineers could have done other things if they weren't writing documentation. The goal is a world where everyone can have docs as good as Stripe without requiring expert engineers to write them.
Usage-based pricing is currently the way to go because it aligns with what customers are doing. Seat-based pricing doesn't make sense. Eventually the model will shift to outcome-based pricing, though enterprises are not ready for that yet. This will likely happen in the 2030s.
Factory points a token cannon at model providers including OpenAI, Anthropic, AWS, and GCP. This functions as a marketplace where the buy side is an engineer wanting a task done and model providers compete on benchmarks for cost and performance.
A future world could have tokens bidding on tasks with providers saying they will get the task done at a certain cost. Validation loops determine if the task was successful. No one uses these tools to just write code anymore. They write code with validation criteria for how success is measured.
Model labs given a task and validation criteria would bid on how much they are willing to pay for tokens while maintaining margin. This shifts from usage-based to outcome-based pricing. Questions remain about how to subdivide tasks, though better tools will make this easier.
Users have incentive to be thorough in validation criteria because agents could technically hit all validation criteria while doing something wrong, like deleting code to fix code.
Everyone has a software factory whether they know it or not. It is just very inefficient. Large organizations with more than 10,000 people have processes for deciding and releasing features that involve hundreds or thousands of people, and most couldn't even draw the process. This is not because they think it is right but because it is the nature of building large software today.
With these systems, tribal knowledge can be codified. Processes that require asking gurus with 30 years of wisdom, getting multiple approvals, and following checklist docs that rely on human behavior and redundancy can be automated. The focus shifts to what actually moves the needle for the business.
Software factories require figuring out the actual inputs that determine what features to build, including inputs from customers, the market, and product leaders. Then the assembly lines of how software is built must be mapped. This enables closing the loop to determine if decisions actually delivered business outcomes.
Two years from now, CIOs will face questions about where to put every incremental dollar rather than every incremental token. They will need to decide between headcount or tokens and where in the org to allocate them. This requires feedback loops showing which decisions based on data created retention, usage, or other metrics the business optimizes for.
Ten years from now, the previous era of software will feel like ancient times when businesses didn't do accounting, similar to marketing in the Mad Men era where everything was creative with no measurement of what worked. Jack Dorsey's blog post about every company being like an AGI means companies need to optimize their weights, figure out which nodes are loadbearing, which need more tokens, and where more nodes are needed.
Models are not trained by vibes for backpropagation. Companies currently determine token budgets and lay off 20,000 people by shooting from the hip. Software factories enable mathematical approaches where parts of the business that matter more get more tokens if that improves outcomes, while other parts might benefit more from humans for building customer relationships.
Salespeople who are good at their jobs probably don't need many tokens because their alpha comes from face-to-face customer conversations. Adding tokens to sales teams probably won't change output, but adding humans probably will. Engineering teams are different because engineers can produce a lot more when given more tokens while owning outcomes end to end.
Operations, finance, and marketing are somewhere in between. Every business needs to ask what their core competency is. Many companies tried building their own software development agents but realized after six months it was not their core competency. A logistics company should focus on logistics rather than hiring AI engineers.
This is an opportunity for businesses to double down on core competencies and procure externally what is not core. In the early internet, pizza shops would have needed engineers to build websites, but that was never a core competency. Companies emerged to help build websites without technical expertise, which is why most pizza shops don't have engineering departments today.
Most pizza shops do not have an engineering department, which is likely a positive development. Many businesses have historically brought in specialized roles when pursuing new initiatives, but this was often necessary rather than a core competency. Allowing businesses to focus and double down on what they do best will benefit consumers through more efficient operations. This shift will lead to ruthless refocusing on what actually matters for each organization.
Every company must go through a process of reinvention. Ten or twenty years ago, organizations discussed digital transformation. Today, the equivalent conversation centers on AI transformation. A couple of years ago, many organizations were not ready to work with autonomous agents. As customers progress along the maturity curve and reinvent themselves, successful organizations demonstrate specific approaches to adaptation.
Companies that conduct company-wide hackathons tend to perform well with AI adoption. Setting aside a single day where the entire workforce builds with AI establishes the right tone and pace for organizational change. Even when these experiments fail, the process itself provides value. Organizations that accept failure as part of the learning process outperform those that demand perfect execution from the first attempt.
EY serves as an example of successful AI integration. Despite not being known for operating at the absolute frontier of AI, EY made a deliberate decision that this transformation matters. The company committed to moving forward, accepting that mistakes would occur while respecting regulatory constraints such as SEC requirements. They encouraged engineers to experiment, build, and identify what works and what does not. This approach of learning through hands-on engagement has proven effective.
Organizations succeeding with AI are willing to question established processes without sacred cows. The approach involves setting aside existing methods, testing new approaches, and reverting if the new method fails. This willingness to experiment distinguishes successful organizations from those that remain rigid.
AI transformation initiatives succeed when driven from within the organization, particularly from the tech team, individual contributors, or leadership. Initiatives originating from the board level tend to struggle. Internal champions who understand the technical and operational realities drive better outcomes.
AI consumption continues to increase rapidly. Current usage patterns are predominantly synchronous, meaning that if users stopped actively prompting systems like cloud code, codeex, or droid, token consumption would drop to zero. Within twelve to twenty-four months, approximately 90% of tokens will be asynchronous. These tokens will power autonomous agents that independently identify signals, such as customer issues, and initiate fixes or first-pass solutions without human initiation.
Current AI systems operate primarily in co-pilot mode, where users initiate tasks even when working with agentic systems. The future involves truly autonomous operation where agents function without constant human direction. Tesla factories provide an analogy, with robotic arms operating throughout the facility without direct human intervention at each step. The concept of a dark factory, where operations continue without human presence, represents the direction of software development.
The name Factory draws inspiration from Elon Musk's statement that the factory is the machine that builds the machine. This principle guided the company's vision for autonomous software development. The company also incorporates the idea that organizations become the opposite of their name, with Factory evolving toward more artisanal outcomes.
The short-term outlook includes significant turbulence as companies correct misallocated resources and reduce bloat. This correction will be painful for many individuals. AI CEOs should bear greater responsibility for addressing and mitigating these impacts. The industry needs to begin addressing workforce displacement immediately rather than delaying action.
Despite short-term displacement, the long-term outlook is positive because numerous problems exist that software can solve but currently does not address. Engineers represent some of the best systems thinkers and problem solvers. The reallocation of engineering talent will direct these capabilities toward previously unsolved problems rather than maintaining overstaffing on existing challenges. This shift represents a net benefit for society.
Current software in many domains, including government services such as DMV and IRS systems, provides poor user experiences. The vision is that all software can become high quality. Pharmaceutical research also stands to benefit, as solving diseases involves not only biology but also sophisticated software engineering. Previously, these domains have not allocated sufficient resources to attract top engineering talent. The current transformation will better align engineering resources with the most significant problems.
The industry has a responsibility to complete the reallocation of engineering talent as quickly as possible, targeting a timeline of six months to one year rather than ten years. This acceleration will minimize the duration of workforce disruption while maximizing the speed at which critical problems receive proper engineering attention.
Keep Sequoia Capital in your library
Save the videos and channels worth coming back to, and find them again in one place.
