The feature works. But does it belong?

retained text

TRM Labs’ Rahul Raina and CodeRabbit’s Harjot Gill on choosing, validating, and shipping work as agents take on more development.
In the first episode of CodeRabbit’s Founder to Founder, moderator Erik Thorelli brought together TRM Labs co-founder and CTO Rahul Raina and CodeRabbit co-founder and CEO Harjot Gill to discuss how AI is changing the way their teams build software. They discussed how their teams decide what to build, validate agent-generated code, and deliver new features to customers.
TRM Labs builds software that helps investigators trace illicit financial activity and combat fraud, ransomware, terrorism financing, and other threats.
At TRM, agents give the team more ways to respond to customer requests. Rahul describes an agent building a feature and delivering a screen recording of it in action. But the example also points to a familiar product dilemma. Suppose the solution adds another button to a page. The feature works, but solving every request this way eventually leaves you with a page full of buttons.
That leaves the team to ask whether the agent’s solution is the one they would have chosen. As Rahul puts it, “Is this how I want to solve this problem?”
Decide what is worth building
At CodeRabbit, background agents can investigate support tickets and alerts and propose code changes.
“Now it’s so easy to go from an idea to a pull request,” Harjot says.
When ideas can become PRs this quickly, teams need to make decisions sooner. A support ticket identifies the problem, but the team still has to decide whether to pursue it and how to solve it. At CodeRabbit, Harjot is exploring whether the team can introduce a planning and approval step before background agents open pull requests. The agent would describe the change it intends to make and ask whether it should proceed.
Harjot is also considering senior review of the prompts junior developers plan to give coding agents, so architectural decisions can shape the work before implementation begins.
TRM has been developing its own way to guide work before implementation through an internal collection of tools and skills Rahul calls the “product cortex.” Customer calls and feedback provide ideas for possible work. Product managers review the ideas and decide what to pursue, then develop requirements and iterate on prototypes before implementation.
The early version of the product cortex mostly surfaced things the team already knew. The suggestions improved after TRM added its design system and strategic priorities. PMs can also give agents a particular objective, helping the agents find signals that match those priorities rather than simply reacting to everything coming in.
Rahul estimated that about 10% of those signals became something the team would eventually build. The documents and prototypes from that process stay in the repository as the feature moves into implementation.
Bring evidence to the review
Choosing what to build is only the first decision. Once an agent implements the work, the team still needs evidence that the change behaves as intended and a clear rule for when a person must review it.
At the time of the conversation, TRM still required human approval for customer-facing pull requests and deployments. The team was also investing heavily in automated validation, with the goal of generating test evidence as part of each PR instead of asking a person to assemble it.
At TRM, implementation and validation are treated as one development step.
“We call it make-validate, because make without validation is kind of slop,” Rahul says.
TRM is working toward controls that detect changes to security-sensitive areas such as authentication and authorization. Those changes would receive human review, while other work could move faster.
Harjot makes a similar point about the responsibility developers retain at CodeRabbit. He expects developers to validate their work and meet the quality bar before asking a colleague to examine an AI-assisted change.
The increase in output has also put pressure on CodeRabbit’s delivery infrastructure. As development accelerated, the company had to improve caching, build systems, deployment pipelines, and merge queues.
Bring more people into the work
Agents are also changing how product managers and designers contribute to software development.
Rahul says TRM hires builders and expects every product manager to ship a feature. The exercise showed PMs how much they could investigate on their own before involving an engineer. Agents with access to the codebase and previous PRs help them identify dependencies and edge cases while shaping a specification.
That gives engineers a more developed proposal to discuss.
At CodeRabbit, Harjot describes reorganizing teams into pods that bring product, design, and engineering together, with plans to add marketers to those pods. PMs can submit copy changes directly, while designers can implement improvements themselves.
“Everyone’s allowed to touch the code,” he says. “It’s not a sacred thing anymore.”
Engineers still make decisions about scale and API design, while designers keep the interface consistent. Agents let each discipline apply that expertise directly to working software.
The context created while a feature takes shape can also support its launch. Harjot says CodeRabbit is exploring a newsroom-style approach that brings marketing closer to development. At TRM, the product cortex automatically generates materials for sales and marketing from the context gathered throughout the process.
Rahul’s advice to future founders returns to the product decision at the center of the conversation: stay close to customers and keep looking for problems worth solving.
“There’s still a desperate need for great products,” he says.
Watch the full episode of Founder to Founder for the complete conversation on product judgment, validation, and how agents are changing work across engineering, product, design, and marketing.

document fetched 2026-10-24 10:04