A Case Study in AI Product Development 🔬
How TRM built a custom internal harness for product and engineering work.
Hey there, Luca here!
When I write about AI coding, you can typically find three types of articles:
Commentary on recent research — as we did several times recently.
My own experiments — these days, mostly about building Tolaria.
Case studies — about how other teams work.
The third type is the hardest to write. There are very few companies that accept to put themselves out there and talk about practices, not just tools or tokens. That is why I was happy when I met Rahul and the team at TRM Labs, and they agreed to share how they are redesigning their product development workflow.
For context, over the last few months, I have argued that AI is changing the cost structure of development. So, since coding is now cheaper, we need to find a way to make everything else cheaper too.
TRM reached the same conclusion and did something interesting: they rebuilt their shipping workflow and encoded it into a custom internal harness called Cortex, which they are now open-sourcing.
Today we’ll explore how they have been thinking about it. So here is the agenda:
🏁 Inner loop vs outer loop — a useful mental model to translate faster coding into actual faster delivery.
🔀 From handoffs to outcomes — how TRM redesigned its product workflow around the work rather than the roles.
🧰 Cortex as a harness — how reviewable artifacts, deterministic gates, and repository context make the workflow reliable.
🧪 Starting small — how TRM moved from a greenfield experiment to a regulated production system.
✅ Healthy code and healthy people — why increasing automation doesn’t mean removing human judgment.
Let’s dive in!
I want to thank Rahul and the team at TRM Labs for partnering on this piece. You can learn more about their work below:
🏁 Inner loop vs Outer loop
Most AI coding tools optimize what we call the inner loop: you describe a feature, watch the agent write the code, and get something working a few minutes later. This is where AI has delivered the most visible improvements, but it’s just a small part of how software gets shipped.
Other than the inner loop, there is an outer loop, that covers the broader cycle: deciding what is worth doing, shaping and reviewing the solution, releasing it, and learning from production.
As of today, it’s been obvious how AI can help with the inner loop, but much less so with the outer loop. And if you don’t do both, constraints move to other parts of the workflow, like:
🔍 Reviews — agents create more PRs than people can reasonably inspect.
📋 Shaping product — the team can build faster than it can decide what good work looks like.
🎯 Customer signal — shipping the wrong thing faster is still waste.
At a small scale, this is the same acceleration whiplash I have experienced with Tolaria. Starting work is cheap, but my ability to review it, decide what is good enough, and create the next piece of work does not scale at the same rate.
To fix this, the TRM team stopped treating engineering speed as the goal and started looking at end-to-end throughput instead 👇
🔀 From handoffs to outcomes
Like most companies, TRM had a product shipping framework. This can be more or less formalized, but chances are your team has a shared language for how an idea moves from customer feedback to production.
At TRM, such a framework had nine stages and was mostly organized around roles. A Product Owner prepared the spec, a Technical Product Manager helped translate it; a Technical Anchor owned the implementation, and various artifacts moved from one person to another.
The process was designed around the assumption that every artifact had to be created by one specialist and handed to the next.
AI weakens that assumption. For example:
A PM can now explore technical feasibility and create a working prototype.
Or, on the other end, an engineer can investigate the customer context and draft a product spec.
Does this mean the intermediate artifacts disappear? I don’t think so. If anything, specs, plans, or decision records can become even more important when agents do the implementation, to trace execution and record history. But it’s likely that individual artifacts no longer need to belong *exclusively* to an individual role.
So, TRM rebuilt the framework around six outcomes, organized into three groups:
🔭 Sense and Decide — collect signals, understand the problem, and decide whether it is worth solving.
✏️ Shape and Make — turn the problem into a reviewable direction, then build it.
📣 Communicate and Learn — release the change, observe its impact, and feed what was learned into the next cycle.
These are broad areas that change the job of the people involved:
🎯 PMs and EMs expand their scope — they can test feasibility and prototype ideas without waiting for engineering capacity.
🧑💻 Engineers get closer to the problem — they can retrieve customer signal, shape solutions, and work across more of the stack.
🎨 Specialists turn judgment into platforms — designers, security engineers, and other experts create rules and constraints that make good decisions easier for everyone else.
I really care about the last point, and I think it’s how specialist work is evolving today. Deep specialists are more and more an overkill for regular production tasks — they have a bigger impact when they bottle their taste into design systems, components, security policies, workflows, and platform in general.
So TRM laid down the process and then created a harness around it 👇