From individual coding tools to development platforms

Who do you trust to merge the code?

I ask engineering leaders a version of this question all the time: if an agent writes the code, who do you let merge it? The answers are all over the place. I've seen teams where an agent ships to production and a human barely glances at the diff. I've seen teams that won't let an agent near a branch without two reviewers signing off. Same tools, very different comfort levels.

What interests me is why, because it usually has little to do with how good the models are or how much the company spent on tooling. It mostly comes down to one thing that's harder to talk about than any feature list: how much you actually trust the thing.

For about three years now I've watched organizations try to go from "my editor finishes my line for me" to "my team runs something closer to a software factory." The messy part is the middle, and that's what I'll try to talk about.

Where I'm coming from

I'm a Senior Principal PM at AWS, I spent years on containers and serverless, and now I build and ship Kiro, Amazon's agentic coding tool. That gives me a couple of angles on this: I talk to AWS customers across a lot of industries, and I watch teams inside Amazon put themselves through it. So take all of this as one person's read from those seats.

What shifted recently is the size of the help. A year or so ago, "AI coding" mostly meant inline suggestions, a smarter autocomplete in your editor. Now an agent will plan a change, edit across a bunch of files, run the tests, and open a pull request. And the newest step is the one that unsettles people most: the agent can decide what to work on in the first place, picking the next task off a backlog or a failing build without a human prompting it. We went from help at the level of a line, to help at the level of a task, to the thing choosing its own tasks, and a lot of what people assumed in the autocomplete days stops holding once that happens.

I've come to suspect this is less a tooling purchase than it looks. From what I've seen, going from individual assistance to a team platform tends to be an organizational change that happens to involve tools. Fair warning before I go on: this is more stories than spreadsheets, partly because the good data is still thin and partly because the stories are where I actually learned things.

Trust gets earned at the speed of checking, not the speed of models

You'd think teams hand agents more work as the models get smarter. That's not really what I see. They hand agents more work as they get better at checking the work. A benchmark going up doesn't move anyone. What moves people is being able to verify an agent's output cheaply, and watching those checks come back clean over and over.

It helps to stop thinking of trust as a yes-or-no call. It's a spectrum, and every team sits somewhere different on it. A code review is just one point on that spectrum, from a human reading every line, to a quick skim, to a bot that gates the merge, to nobody looking at all. Where you land depends on how much risk you can stomach, on the context around the change (no pun intended) like how critical and how reversible it is, and on smaller things like who wrote it and whether the tests are any good. The same team will sit in different spots for a config tweak and a change to the billing path, and that's exactly as it should be.

So the teams that got somewhere didn't chase the most capable agent. They made the output easy to read, easy to test, and easy to undo, and then the agent earned more room the way a new hire does, by getting the small stuff right until you'll hand it something bigger. The ones that struggled pointed a high-autonomy agent straight at their most important service and hoped. The ones that did well started it on the boring work, test coverage, migrations, dependency bumps, where a bad answer is cheap and obvious.

The bill scales with how hard the agent works

And all of this costs a lot of money. More than most people have clocked yet.

A customer once pushed back on me because one agent seat ran about $19 and the equivalent Kiro SKU was $20. A whole dollar. I had to smile, because that dollar is not the conversation anyone will be having for long. These folks have no idea what's waiting for them.

In the autocomplete era, cost was a flat per-seat line, and the bill didn't move no matter how much the developer used it. Agents broke that. When the unit of work is a whole task, and the agent is reading files, running tests, retrying, and reasoning its way through a change, you pay for all of that activity. The more you let it do, the more it runs and the more it costs, and the seat price becomes the last thing you worry about.

That's a feedback loop most budgets weren't built for, because the autonomy you earn through trust is the same autonomy that drives the bill up. A pilot that looks fantastic on a handful of developers looks very different once the whole org is running agents against every ticket, every day.

Here's the pattern that genuinely surprised me, because I watched customer after customer land on the same shape without comparing notes. Spend is wildly lopsided. Roughly 80% of your developers use maybe 20% of the budget, dipping in for the occasional task, while the 20% who really rewire how they work around agents burn through the rest. There is no average developer to price against, and your bill is mostly that second group.

So the question isn't "what does a seat cost," it's "what does a unit of useful work cost, and is it worth it." Sometimes it clearly is: a change that would have taken a person half a day, for a few dollars of tokens, is an easy trade. But a lot of agent activity is retries, dead ends, and spelunking through context to rebuild what a cheaper setup would have just known. The teams watching this treat tokens like any cloud bill, with visibility per team and per workflow, so they can tell the valuable spend from the spinning.

Why this points at a factory

The organizers asked us to place our topic inside the emerging idea of a software factory, where agents, developers, teams, tooling, and context all work together to build and evolve software. The more I sit with trust and cost, the more they look like two links in a chain: trust is what gets you a factory, and the factory is what lets you control the cost.

Trust comes first because a factory only runs if the agent can make real progress toward a goal on its own, instead of stopping every few minutes to check in, or worse, finishing and leaving a human to review code it never bothered to prove was correct. Until you trust it to run unattended, you don't have a factory, you have a very expensive assistant that still needs a babysitter. So trust is the thing that unlocks the factory in the first place.

And the factory is what finally lets you get the cost under control. Left to individuals, frugality is a thousand private judgment calls about when an agent is worth running. Once the work flows through a shared system, you can bake the discipline in, with budgets, limits, and routing the cheap jobs to a cheaper model, so spending restraint is a property of the line rather than a habit you hope everyone picks up. You can't do that at the level of one developer and their editor. You need the factory to even have the knobs. That's the piece I think is still unsolved, and the piece I most want to kick around with the room.

The short version

Going from individual coding assistants to team platforms is more of an organizational shift than a tooling purchase, and it runs in that order: you earn enough trust to let agents work unattended, that trust is what lets you build a real factory around them, and the factory is the only place you can actually get the costs under control.

If you remember one thing: trust comes first. It's what unlocks everything downstream, including the bill. Build for it, and the rest becomes a problem you can actually manage.

Come to the session for the stories, and we'll have some fun with it. One caveat: I reserve the right to change what I talk about between now and the conference. A year in gen AI is about three dog years, and a few weeks can rewrite the whole conversation, so if the ground shifts, the talk shifts with it.