Operator Insights

Reported by others3

1. 

   Dr. Łukasz BolikowskiChief AI OfficerComarch

   IT services company of about 5,000 specialists, with Factory in the hands of hundreds of its engineers.

   Factory, published Jul 29, 2026Read the case study (opens Factory in a new tab)

   Observation

   Comarch put Factory in the hands of hundreds of engineers and let Missions run overnight.

   Takeaway

   Long-running Missions pay off on bounded migrations and re-platforming when engineers set direction during the day and review the overnight output each morning.

   What happened

   Comarch's leadership set a goal that all newly generated code would be developed with AI by the end of 2026. It chose Factory after comparing coding tools on speed, accuracy, rework, and coverage of the whole lifecycle. Engineers start Missions that run overnight and at weekends, then review the output in the morning. Factory reports a scoped XSLT modernization estimated at 10,000 man-days finished in 45 days.

   • Vendor case study
   • Organization metrics reported by Factory
   • No model named

   Deployment details

   IT services company of about 5,000 specialists, with Factory in the hands of hundreds of its engineers.

   • Vendor case study
   • Organization metrics reported by Factory
   • No model named

   Team

   Hundreds of Comarch engineers

   Workload

   Bounded migrations, re-platforming, and net-new builds, including an XSLT modernization and a database migration

   Product version

   Factory with Missions running in the background

   Measurement

   Comarch's own analysis of project speed; Factory reports a 40% efficiency gain and 30 to 34% higher team velocity

1. You.comJun 16, 2026FactoryYou.com made Droid its default pull request reviewer and moved repetitive growth work onto Missions.

   

   Edward IrbySenior Software EngineerYou.com

   You.com engineering, with Droid working across the company's repositories.

   Factory, published Jun 16, 2026Read the case study (opens Factory in a new tab)

   Observation

   You.com made Droid its default pull request reviewer and moved repetitive growth work onto Missions.

   Takeaway

   Commit shared, tool-agnostic skills to the repository so team standards travel with the code, and send rote work to cheaper models.

   What happened

   You.com consolidated several coding tools onto Factory after its evaluations showed Droid used the skills, tools, and MCP servers it was pointed to more reliably than its built-ins. Automated review is rolling out as the default across repositories. Droid reproduced an MCP timeout in a Docker environment and found the cause in an afternoon, and daily Missions now open integration pull requests for new open source projects.

   • Vendor case study
   • Engineer's account, no team metrics
   • No model named

   Deployment details

   You.com engineering, with Droid working across the company's repositories.

   • Vendor case study
   • Engineer's account, no team metrics
   • No model named

   Workload

   Automated pull request review, debugging and investigation, and recurring open source integration work

   Product version

   Droid in the terminal, IDEs, and the desktop app, plus Missions

   Measurement

   One debugging case described as days of work finished in an afternoon

2. ChainguardJan 30, 2026FactoryA Chainguard staff engineer kept single Droid sessions running for two weeks across repositories.

   

   Josh WolfStaff EngineerChainguard

   Chainguard engineering. Internal codebases and upstream open source packages. Sessions of about two weeks.

   Factory, published Jan 30, 2026Read the case study (opens Factory in a new tab)

   Observation

   A Chainguard staff engineer kept single Droid sessions running for two weeks across repositories.

   Takeaway

   Long sessions help most on a task that repeats, with review at each step. Give each parallel session its own git worktree.

   What happened

   Josh Wolf had tried memory MCPs, memory tools, and custom SDKs without result. With Droid he runs several long sessions on different parts of one project, each in its own git worktree, and kept one going for two weeks without losing context. He teaches Droid a packaging task once or twice, then lets it repeat the pattern with little intervention.

   • Vendor case study
   • Engineer's account, no metrics
   • No model named

   Deployment details

   Chainguard engineering. Internal codebases and upstream open source packages. Sessions of about two weeks.

   • Vendor case study
   • Engineer's account, no metrics
   • No model named

   Team

   One staff engineer's own workflow

   Duration

   Sessions running about two weeks

   Workload

   Design documents, reviews, and package builds across internal repositories and upstream open source

   Product version

   Droid sessions with context compaction, one git worktree per session