Software factories aren't a research demo. At Tessl we run one that merges over 1,000 PRs a week, as well as maintenance agents that raise their own issues on the factory itself, and creates changes that merge without us ever knowing they exist.
In this session I'll present a full, honest account of the building an autonomous issue-to-PR factory for an open-source learning platform which we built for our users on our site. I'll show why a factory is never built in one go, but rather an iterative system that earns maturity layer by layer, and I'll give you a concrete path to grow that maturity safely rather than trusting too much too soon. I'll share the decisions that paid off (versioned review lenses, deterministic gates), and the ones that cost us. I'll show where autonomy earned trust and where a human still has to step in, and how the developer's job quietly shifted from writing code to architecting changes the pipeline can execute via issues. The goal is to give you a realistic build plan, with potholes marked, so you can follow the same route with fewer scars.
These learnings are drawn both from building an open source factory fit for production and from Tessl's own dark factory that is used at scale. You'll leave with a real build plan, the potholes marked, and enough to go build your own.
Key Takeaways:
- The components of a software factory, and how to assemble them.
- Why a factory is iterative, and how to mature it safely. You don't build trust in one shot, you earn it layer by layer. I'll give a practical path for growing a factory's maturity without over-trusting it too early.
- What are loops and why they are the key to a factory you can trust. What inner, middle, and outer loops are, and how loop engineering lets a factory measure, self-improve, and reach the reliability needed to merge autonomously.
