Product Managing the System Around Your Agents

By Jake Moses

The biggest thing AI changed about building software is cycle time. A feature that used to take a sprint can now take an afternoon. A brand-new project can go from idea to running code in a day.

That speed is a genuine gift. It is also the source of a quieter problem.

When the cost of producing code drops, the temptation is to skip the practices that used to make code trustworthy. Everyone is excited to build their feature, and everyone assumes they'll clean up later. A developer or an end user sits down, tries the new thing, and finds the rough edges that never got sanded down. The shorter the cycle time, the easier it becomes to drift away from the fundamentals—design, testing, review—that traditional software engineering spent decades getting right.

My response has not been to slow the agents down. It has been to build discipline around them.

An Old Habit, Applied to New Tools

I've cared about this since the beginning of my career. At Amazon, I was an early advocate for the internal issue-tracking tools like SIM, because keeping everyone on the same page about what needed to be done had obvious payoffs. It kept engineering aligned. It made it easy to bubble work needed up to management. And it enforced practices that predate any of this: running sprints, writing tests alongside code rather than after it, and avoiding the waterfall trap of shipping a large batch of changes and only then discovering what broke.

None of those ideas are new. What's new is how well they pair with agents.

Start With the Design, Not the Code

Today I use Linear and the same fundamental agile practices to manage both myself and my agents.

The work starts before any code is written. We lean on Claude to draft design documents and RFCs (Requests For Comments) with us. The goal of that stage isn't the document, rather it's alignment on where we're going, what we're actually building, and how we intend to test it.

Once we have that alignment, we use skills we've built into our own interfaces to break the work down: first into milestones, then into individual tasks. Each task carries its own exit criteria, its own code references, and its own testing standards—the same rigor you'd expect in any traditional engineering shop. Some of that validation is native to pull-request checks. But a lot of it is simply making sure the agent understands the intent: we are adding this behavior, and here is how we expect it to be verified.

Why This Is the Foundation, Not the Overhead

A belief I hold strongly: these agents will keep getting more capable, and we do not want them operating in silos. We want them aware of each other's work. The way you earn that future is by exercising the muscles now—planning clearly, tracking explicitly, and breaking work into well-scoped pieces.

Doing so pays off immediately, in two ways.

First, when work is decomposed into units of bounded complexity, you can hand much of the implementation to cheaper models that also don’t need as many tokens to complete the task. Each task is small and specific enough that it doesn't need the most powerful model in the lineup.

Second, traceability improves dramatically. Every piece of completed work ties back to the project, the milestone, and the exit criteria it was meant to satisfy—rather than living as an opaque record of what an agent happened to be doing at the time.

And honestly, this is far easier than it was at Amazon. Back then I hand-wrote every task from templates I filled out myself. Now we have skills that already know how to format a task, where supplementary detail belongs, and what a good task looks like.

The Point

More capable models will keep arriving. The teams that benefit most won't be the ones that simply let agents run fastest. They'll be the ones that built the system around their agents—the planning, the tracking, the shared awareness—so that all that new capability lands on a solid foundation.

This is one of the things I've been excited to work on at Pedestal, and it has already made our team more organized and more productive across the board.

A system that produces software continuously needs a process for organizing it continuously.