Work story · Software factory insights
Understand the system your team builds with
After our team built its software factory, I conceived and built a tool to help us understand how it operated. We had invested substantial effort in refining the system, and telemetry was essential to seeing what needed improvement.
I wanted to make that visibility available to other development teams.
01
See what’s in the factory
An agent-driven development environment can include skills, hooks, instructions, Markdown files, agent configurations, multiple harnesses, and several models.
The platform helps teams understand what they have, how those pieces are being used, and what they could add or change.
02
Find where time goes
Software delivery includes waiting, retries, repeated checks, and handoffs. The platform helps teams investigate questions such as:
- Where does work spend time waiting?
- Are CI checks running more often than necessary?
- Which parts of the workflow repeatedly stall?
- Where are agents effective?
- Where does the process require repeated human intervention?
03
Understand usage in context
Model and usage telemetry can point to opportunities to improve the workflow itself.
For example
A team may discover that every prompt carries extensive instructions that would work better as targeted skills.
Or
It may find that an engineer regularly reaches Claude limits and switches to Codex, affecting how work continues.
Those observations help teams make decisions about configuration, capacity, and tooling.
04
Connect observation to action
The purpose is to help teams improve how they build software. That could mean reorganizing instructions, removing duplicate checks, improving a harness, changing model usage, or introducing a missing capability.
Teams need to examine delivery speed and quality together as they make those changes.
My contribution
I conceived and built the insights platform, drawing on our experience operating a software factory and the information we needed to improve it.
It combines my interest in hands-on technical work with a founder’s instinct for turning an internal problem into a product other teams could use.