In April 2023, Matan Grinberg left a PhD program in theoretical physics to found Factory, which builds software development agents called Droids for enterprise environments. In a conversation with McKinsey Senior Partner Martin Harrysson, he reflected on what it takes to move from AI pilots to scaled adoption, how agent-native development changes engineers’ daily workflows, and why the hardest part of a transformation is often behavioral, not technical.
This interview has been edited for length and clarity.
Martin Harrysson: You started your career in theoretical physics. How did that lead to founding Factory?
Matan Grinberg: I spent about a decade as a theoretical physicist, working on quantum field theory, general relativity, and string theory. It was while I was at UC Berkeley for my PhD that I realized physics was not what I wanted to do for the rest of my life.
I started taking AI courses and became interested in what was then called program synthesis, now called code generation. The idea that AI systems—built in code—could actually write code themselves got me obsessed.
After about a year and a half exploring that, it became clear to me that the best way to pursue it wasn’t through academia but by starting a company. I cold-emailed a former physicist who is now at Sequoia [a venture capital firm in Silicon Valley]. We went on a long walk, and he challenged me to take the leap. I left my PhD program shortly after—and that’s how Factory began in April 2023.
Martin Harrysson: Many enterprises have experimented with AI in software development, but not all have seen a step change in impact. What differentiates those that are scaling?
Matan Grinberg: Since day one, our mission has been to bring autonomy to software engineering. We build software development agents—which we call Droids—designed specifically for enterprises. But they’re not just for vibe coding or building a website from scratch. We’ve focused on legacy migrations and code bases that are sometimes older than the people working on them.
That’s where enterprises actually get stuck and where a lot of potential is locked up.
We like to use an analogy: Software development agents are like Ferraris. But if you drop a Ferrari into San Francisco in 1850 with dirt roads and horses, it’s not going to perform well. You might crash it into a ditch and conclude that cars don’t work. Before organizations can really benefit from agents, they need to “pave the roads.”
In practice, that means documentation, test coverage, CI/CD [continuous integration and continuous delivery], observability, linters, integrations with internal tools, and access to the kind of tacit knowledge human engineers rely on. If those things aren’t in place, agents struggle. If they are, performance improves. And as a side effect, paving those roads makes life easier for human engineers, too.
Martin Harrysson: What convinces organizations to make that investment in paving the roads?
Matan Grinberg: In every organization, there are AI enthusiasts—the people who are willing to take a bet on their reputation and have their team try this out. They’ll go and pave a small stretch of road and use AI agents there to show it works.
If you’re working with the right people, they know which engineers to bring over and say, “Look at this.” And especially when the work involves something like a legacy migration where no one wants to spend more time than necessary, engineers are very open to something that makes the job easier.
Once that small area shows real results, others in the organization are much more willing to pave more roads and try it themselves. But it typically starts with a few people who are willing to go first.
Martin Harrysson: You’ve described paving the roads as an enterprise challenge. How have you approached it at Factory, and what has changed in how your engineers work?
Matan Grinberg: The enemy of AI agents is tacit knowledge—things discussed but not written down. If I know something that an AI agent doesn’t, I have to remember to tell it. That creates friction.
Internally, we record every meeting. Our Droids generate notes and store them in a repository. If a prompt from an engineer is incomplete, a Droid can look at how Factory typically makes decisions and use that context to go ahead.
We also have Droids that automatically start working on tickets the moment they’re created. If a customer reports a bug, a Droid tries to reproduce it, fix it, and test the fix in a virtual environment. A meaningful portion of bug fixes now happen this way.
The mindset shift is that the new directive isn’t to write a line of code. It’s to delegate to an agent. Before a meeting or before going to bed, engineers think about what they can offload. You can ask an agent to try five different approaches overnight, and then you can review the results in the morning. That’s a very different way of structuring your day.
Martin Harrysson: If the focus in the product development life cycle shifts from writing code to delegating work to agents, traditional role boundaries begin to blur. How does that change responsibilities inside an organization?
Matan Grinberg: I think it clarifies ownership.
Before, someone could say, “I don’t write code, so that’s not my fault.” Now code is more of a tool across roles. In our sales organization, for example, people ship code for automations across their software.
The distinction shifts away from who produces which input and toward outcomes. Who owns the customer outcome? Who owns a feature’s adoption? If something goes wrong, who is accountable?
That focus on scope and ownership becomes more important than traditional role boundaries.
Martin Harrysson: You’ve described a shift away from inputs and toward outcomes. In a world where agents can generate large volumes of output, how should organizations think about measuring success?
Matan Grinberg: I think it’s phase by phase.
In phase one, the goal is adoption. You want as many developers as possible to become agent-native. Adoption percentage and daily usage matter. You shouldn’t be overly focused on efficiency or token costs at that stage.
Once adoption is high, you can shift toward efficiency and business-aligned metrics—story points delivered, features shipped, or other measures.
But ultimately, the right metric depends on the business bottleneck. For some companies, more features directly drive growth. For others, the constraint might be relationships, quality, or latency. Measuring success purely by engineering output might not make sense.
It forces organizations to focus on what actually matters for their business, not just what looks like good software productivity.
Martin Harrysson: As organizations pave the roads and shift toward outcome-based ownership, what do you expect will determine how quickly this change takes hold?
Matan Grinberg: A lot of what we discussed will take time to permeate large enterprises. Behavior change is hard.
I think people underestimate what it means to change how thousands of engineers work. If you have 10,000 engineers and their behavior shifts meaningfully, the speed at which that organization can deliver on its mission will change.
The pace of this shift depends less on whether the technology exists and more on how quickly organizations can change the way their engineers operate.
