Key Takeaways

  • Monaco tested multiple automated code review tools before settling on Devin, keeping the vendor because real pull-request reviews yielded high utility and low noise.
  • For internal agent sandboxes and on-call debugging bots like Hal, Monaco bypassed commercial suites to build Monicoder on top of Coder.
  • Swyx points out that all infrastructure work is just “making God boxes and then taking them apart” (play from 1:37:39) when third-party bundles stop fitting internal systems.
  • Eric directs Monaco's engineering decisions using The Buy to Learn, Build to Keep Principle.

The Buy to Learn, Build to Keep Principle

  • Buy to Learn: Adopt third-party commercial vendors and tools in emerging spaces early to quickly explore capabilities, gather empirical team data, and understand system requirements without upfront engineering costs.
  • Build to Keep: Once the domain reaches product-market maturity or demands specific internal cloud infrastructure integrations that commercial vendors fail to provide, develop proprietary in-house solutions (e.g., custom background agent sandboxes) to retain deep operational control.

Most young engineering teams get this backwards. They spend three months writing a custom code review bot or an LLM gateway on day one, before anyone on the team knows what good agent reviews look like. They waste precious seed runway rebuilding commodity plumbing.

Eric flipped that instinct at Monaco. Instead of building their own reviewer, the team tested external systems and kept Devin on pull requests. “We spent a lot of time looking at different code review platforms,” (play from 1:02:14) Eric said. “It turns out today we still use Devin because we've actually still find a lot of value in how the system's been built.” (play from 1:02:16) Buying gave them immediate data on developer feedback cycles without writing a line of scaffolding.

Building happened only where vendor platforms broke against Monaco's internal stack. To let background coding agents run safely across private repos, Monaco created Monicoder by extending Coder, and built Hal, a dedicated Slackbot for internal debugging. Commercial tools simply could not isolate their multi-agent execution environments.

This cycle reflects an old pattern in devops. As swyx put it: “Congratulations, you now have a job in infrastructure. You need to understand that your entire job is making God boxes and then taking them apart. So your problem is either you don't have a good God box, or your problem is someone else's God box you don't like, so now you have to take it apart and make your own.” (play from 1:37:31)

Eric agreed: “It is absolutely correct that the underlying architecture is the God box where one thing goes in and there's a bunch of other stuff that is some third party, some internal, some first party that all exists on the other side of the God box.” (play from 1:37:02)

When This Works (and When It Doesn't)

This rule works when software categories are in active churn, such as code generation, context routing, and agent sandboxing. Buying commercial software lets you discover what your engineers actually complain about before you freeze requirements into code.

It fails when regulatory requirements or strict air-gapped data policies forbid sending code to third parties. If vendor terms risk client data, buying to learn is not an option; you must build from the start.

What to Do With This

Take your company's AI PR review or agent routing project scheduled for this sprint. Stop writing custom middleware. Buy an off-the-shelf seat on a commercial agent platform tomorrow morning. Give it to three engineers for two weeks, log every bad suggestion and failed merge, and measure real noise ratios. Only write in-house code when an internal VPC or unique database requirement blocks you from using that vendor.