An unfiltered conversation with Matan Grinberg, CEO of Factory AI

Factory is building a platform for agentic software development where developers shift from coding to orchestration roles. The platform features specialized 'droids' for different tasks and requires rethinking the entire development workflow from scratch rather than iterating on existing IDE patterns.

• •Developer behavior must shift from coding to planning, systems thinking, and understanding business constraints
• •Droids handle specific tasks (RCA, incident response, feature building) with varying levels of autonomy
• •Platform designed from ground up rather than adding AI features to existing IDEs
• •Developers can dynamically adjust between collaboration and full delegation modes

Factory is seeing unexpected adoption from technical PMs, engineering managers, and even C-suite executives who haven't coded in years. The platform lowers barriers to entry by removing language fluency requirements while still requiring systems thinking capabilities.

• •Technical PMs and engineering managers are becoming active users alongside traditional developers
• •Skills that matter: systems thinking and constraint understanding, not just coding fluency
• •Solo developers and non-engineers gaining value from the platform
• •Enterprise focus on large organizations with complex engineering systems

Factory launches with three primary droids: CodeDroid for feature building, RCA/Incident Droid for production debugging, and Knowledge Droid for understanding interconnected engineering systems. Each droid integrates with tools like Slack, Jira, Linear, and observability platforms.

• •CodeDroid: Handles zero-to-one applications and feature development with full agentic loops
• •Incident Droid: Pulls from Sentry, Datadog, code, docs, and PRDs for root cause analysis
• •Knowledge Droid: Understands connections between code changes, Slack conversations, and sprint plans
• •Context from entire engineering system (not just code) is critical for human-level performance
• •Enterprise deployments typically start with one high-priority use case like migrations

Factory enables developers to dynamically switch between full delegation and hands-on collaboration. The platform supports both local and cloud execution, with governance controls for enterprise deployments including command whitelisting and ownership tracking.

• •Developers need both pure delegation for routine tasks and collaboration for complex work
• •Planning phase is critical - explicit constraints prevent unwanted assumptions
• •Agents iterate on test failures autonomously until acceptance criteria met
• •Enterprise deployments require governance: command permissions, ownership tracking, blacklists/whitelists
• •Parallel agents can run locally (for hands-on work) and in cloud (for confident delegation)

Factory customizes droids for enterprise workflows using explicit documentation and standard operating procedures rather than expensive fine-tuning. This approach is cheaper, more flexible, and allows organizations to update best practices by editing YAML files or docs.

• •Explicit documentation of best practices works as well as fine-tuning at lower cost
• •Large orgs have codified SOPs that can be directly integrated
• •Organizations can manually update droid behavior by changing config files
• •Internal champions teach teams how to set up droids for new use cases
• •Scalability comes from empowering users, not doing custom work each time

Factory focused on enterprise because that's where sophisticated retrieval and codebase understanding creates the most differentiated value. For zero-to-one vibe coding, model quality dominates, but enterprises have tribal knowledge, dead code, and complex permissions that models alone can't handle.

• •Zero-to-one use cases: alpha comes from models, not product differentiation
• •Enterprise codebases have tribal knowledge across thousands of engineers that models can't access
• •Role-based access control, repository permissions, and organizational complexity require product innovation
• •Better UI can extract implicit constraints from users for more aligned outputs
• •Factory's platform handles the 'less sexy' problems like RBAC and context management

PMs discovered Factory organically and now submit PRs independently without bothering full-stack developers. One organization saw 30 new daily active users when PMs requested access. PMs adopt faster than developers because they lack ingrained workflows and explore features more freely.

• •200-engineer org saw 30 new DAUs when PMs discovered the platform
• •PMs submit PRs for frontend changes without needing developer support
• •PMs have higher feature discoverability - no rigid workflow to unlearn
• •Factory now proactively reaches out to heads of product during deployments
• •Table stakes for PRDs has changed - interactive mocks and customer validation expected upfront

Better models provide free performance boosts but create challenges as users develop familiarity with specific model behaviors. Factory must decide whether to absorb model differences or let users adapt their interaction patterns as models like Sonnet 3.7, Gemini 2.5, and o3 behave differently.

• •Users develop familiarity with specific models (like Sonnet 3.5) and notice when defaults change
• •Different models require slightly different interaction styles for optimal results
• •Factory provides model selector but maintains default for consistency
• •Challenge: should Factory normalize model behaviors or expose differences to users?
• •Tool usage patterns and RL approaches vary significantly across model providers

AI dramatically raises the bar for what's table stakes in product velocity, shifting competitive advantage from engineering capacity to taste and product sense. Similar to how website development evolved, the ability to build is no longer differentiating - great taste and user understanding matter most.

• •What took 1,000 developers two years might take one person six months
• •Table stakes velocity increases, but good taste becomes the differentiator
• •Analogy to early 2000s websites: fancy features don't matter without taste
• •Latent talent with great taste but limited resources can now build products
• •This shift should improve overall software quality as taste-driven builders succeed

Factory pivoted from fully autonomous background droids to an interactive platform after realizing developers wanted more control. A 90-day pilot that nearly churned became a success story when the new platform launched, with developers preferring Factory over any other tool.

• •Original approach: droids worked in background, submitted PRs autonomously
• •Problem: 90% complete PRs were frustrating - developers had to pull down and finish locally
• •Three-month bet to build platform from scratch despite 1.5 years without one
• •Pilot extended from 30 to 90 days, nearly churned before platform launch
• •Turning point: developer said they'd procure even as sole user at their company
• •Key lesson: developers need ability to adjust between collaboration and delegation

Matan discusses Factory's diverse tech stack for testing customer environments and his personal preference for analog tools outside work. For 2025, he hopes people realize developers are becoming more important (not obsolete) and that the US maintains AI leadership through diversified bets rather than herd mentality.

• •Factory uses all models and tools to stay aware and support diverse customer stacks
• •Testing requires Slack, Teams, RingCentral, Google Drive, Notion, OneDrive, etc.
• •Personal preference: paper books and minimal technology outside work for contrast
• •Hope for 2025: dispel notion that developers are disappearing - they're becoming more important
• •Concern: US needs to diversify AI bets beyond trendy approaches, avoid herd mentality from theoretical physics