Value Pairs, one year on

Just over a year ago I wrote Value Pairs, an experiment in reshaping product teams around AI. Instead of a PM, a designer and five or six engineers working through a backlog, I proposed a small core of engineers working in pairs, with product and design available to them, moving through short concentrated cycles of discovery, delivery and validation. It ended with a short list of “foundations” you would need for any of it to work: a design system, golden path modules, a consistent stack, continuous deployment, clear patterns.

Note: This is very much a draft, I’d appreciate any comments or feedback!

A year is a long time at the moment. Since then I have left Infinitas and built a lot of things, mostly on my own with agents: Last Light, Rocketflare, GuideMode, drizzle-cube, Fling and a long tail of smaller ones. I have also written more than I expected to about harness engineering, and spent a lot of time with teams trying to make AI-native delivery work inside real product organisations. This follow-up covers what held, what I got wrong, and what I would now put at the top of the post.

The short version is that the foundations list was the most important part of the original post, and I buried it.

What happened with the experiment

Two examples I have seen first hand stick with me more than any benchmark.

The first was a pair: one product person and one engineer. Between them they rewrote a legacy system that, scoped the traditional way, would have been 18 months or more of work for a full product team. It took them three months, and a lot of that time was spent waiting for the rest of the organisation to keep up and stay connected.

The second was a single forward deployed engineer with no engineering background, a former product manager. Starting from the Rocketflare starter kit, they replaced an existing manual lead management process with a full agentic business application. Two weeks from start to production, and it is creating value in place of the manual process it replaced.

Neither of those is a prototype or a demo. Both teams were smaller than the one I proposed a year ago, and both owned a far bigger unit of work than a ticket: a whole system, a whole business process. That second point turns out to matter as much as the first.

What shouldn’t have surprised me was how hard the move to smaller teams is to manage. The technology is the easy part. Most organisations carry a coordination layer that was built, quite sensibly, for teams of eight or ten: engineering managers, delivery leads, product owners, architects, QA leads, programme managers. Shrink the team doing the work to one or two people and that layer does not shrink with it. You very easily end up with lots of managers and others watching one person do everything.

The refresh: roles merged faster than I expected

The core idea has held up, and if anything it has gone further than I was willing to write down at the time.

Roles are merging. In the original post I was careful to keep the PM / designer / engineer distinction and talk about who leads which phase. To be honest, that was deliberate. I was in part writing for the leadership of my own team, where the lines between product, design and engineering were organisational. They were tied to role and career definitions that people felt very deeply, so I chose to tread carefully. A year on, and with a bit more distance, I can say it more plainly: in practice the boundaries are much softer than that now. An engineer with a coding agent can build three working variants of a flow in a day, and a PM with the same agent can get a working prototype in front of a customer without waiting for a sprint. Addy Osmani describes the result well in The Next Two Years of Software Engineering: the job becomes “part software engineer, part system architect, part product strategist.”

Teams are smaller, and a team of one is a real thing. I was nervous about saying this a year ago. I am not now, because I have been doing it: every project in the list above is, give or take a contributor or two, a team of one. When I wrote The harness is the product in April, 195 of Last Light’s 270 commits had been authored by Last Light itself. Rocketflare is a little over 500 commits, and 458 of them are mine. I am not alone: Kieran Klaassen writes that “Every runs all five of its products with single-person engineering teams”, and Gergely Orosz’s six predictions piece opens one of them with “Smaller engineering teams are a certainty.”

The same piece carries a counterpoint I think is right too. Atlassian’s CTO says their “teams are not necessarily getting smaller, but they’re producing a lot more.” Both can be true, and I think which one you get depends on the environment around the team and how the work is shaped.

The loop still holds. Discovery, delivery, validation. What changed is the weight. Delivery is now the cheap part, and validation and data collection are where the time goes. If you can build three options in a week and it takes you six weeks to find out which one customers want, you have just moved the queue. I flagged this risk in the original post (“if we move from slow Discovery to slow Validation we have a different problem”) and it is exactly what I have watched happen. The teams that do well instrument everything from the first deploy, so the answer is waiting when they need it.

The bit I underplayed: the environment

Most of the AI-native guidance I read is written at the level of a single item of work. A ticket arrives, someone writes a better spec, the agent builds it, it gets reviewed, it ships. Make each step a bit better and you get a bit faster.

Most of the gain sits outside that loop. The 2025 DORA report put it more bluntly than I would have: “AI doesn’t fix a team; it amplifies what’s already there”, and “there is a direct correlation between a high quality internal platform and an organization’s ability to unlock the value of AI.” Ramp’s background agent, Inspect, is built on the same idea. Their launch post describes it turning a request into “a visually validated and fully reviewed pull request using your team’s development environment.”

By the environment I mean three things, and together they decide whether a pair can do the work of a team:

• The operating model. How the team is shaped, what the roles are, and how big a unit of work is.
• The assets. The patterns, kits, design systems and golden paths people and their agents can build from.
• The platform. Where code is managed, deployed and operated, including the CI gates, harnesses and factories that run on it.

The operating model

The path I described in Value Pairs still holds. Discovery, delivery and validation, in short concentrated cycles, with the people best placed to reduce each risk leading that part of the work. What needs rethinking is the team that walks it.

The shape that works is a small, self-contained team that owns a larger problem end to end. Owning it means the team holds every skill the problem needs, so it does not have to queue for anyone else to start, ship or learn. It sits close to the customer, close enough to put working software in front of them in days. And it is informed directly by data, with the instrumentation built into what it ships from the first deploy, so the team can read the result itself without asking an analytics function and waiting for a report.

A team like that has very few handoffs, and handoffs were what most of our process was built to manage. Both examples at the top of this post were small teams that owned the whole problem. A lot of the first one’s three months went on waiting for the rest of the organisation to keep up, which is the cost of a handoff in its plainest form.

Tokens cost money, so use code wherever code will do

A year ago the default was to throw the agent at everything. It was novel and mostly subsidised. That has changed. Agentic runs are expensive in a way chat never was, and the cost scales with how much open-ended work you give them. Anthropic’s own harness design post is a good illustration: their full multi-agent harness ran for six hours and cost $200, against twenty minutes and $9 for a single agent. The harness produced a much better result, and they explain why, but you only want to pay that where it earns its keep.

The bigger point is that every deterministic job you hand to an agent costs you twice: once in tokens, and again in the chance that it does it slightly differently this time. Evil Martians have a good post titled Stop writing rules in AGENTS.md that makes the same case from the repo side: “every rule you can encode as a tool is a rule the LLM can’t forget and a token you don’t have to spend reminding it.”

The obvious: verification should be mostly deterministic

Most people already accept this one, at least in principle. Linting, types, tests, secret scanning, dependency checks, migration safety, coverage thresholds. None of these need a model. They are cheap to run and give the same answer twice.

I changed my view on review because I measured it. In the PR review series I found that a single big review prompt caught one finding in twenty five on a golden dataset. What worked was a pipeline: deterministic stages that gather context and route, with model calls only at the specific points where judgement is needed, and evals around each of them.

The less obvious: are your agents copying, or creating?

When an agent starts a new service, a new page or a new integration, where does it start from? In most of the teams I talk to, the answer is the model’s training data plus whatever is in AGENTS.md. It writes auth from scratch, it writes logging from scratch, it invents a folder structure. Every one of those is tokens spent on something you already solved, and every one is a chance to solve it slightly differently from the last time. Then a human has to review it.

The alternative is to give the agent something to copy. A reference service that already has auth, config, logging, tracing and the deploy pipeline wired up. A design system with components the agent is told to use and a lint rule that fails when it does not. A worked example of every type of thing you build often, with the context and skills sitting beside it. An agent that starts from a working copy and changes it is faster, cheaper and far easier to review than one that starts from a blank file, because the reviewer only has to look at what changed.

I said a version of this in Guide Coding last year: “Is it only using existing golden path modules?” was the first question I asked before shipping anything. I now think it is the most important investment a product engineering organisation can make.

AX is the DX team of the future

Mathias Biilmann at Netlify coined the term agent experience, AX, at the start of 2025. He meant it from the point of view of platforms being used by agents, but it applies just as well inside an organisation.

The developer experience and platform teams most of us built over the last decade made it easy for humans to do the right thing. Paved roads, service templates, internal docs, Backstage. The same team now needs to make it easy for agents to do the right thing, which means every golden path comes packaged with the context, skills and scripts an agent needs to follow it without being told. Datadog wrote a good piece on exactly this, Golden Paths for AI Agents: “Golden Paths do not disappear when platform users become agents.”

Thorsten Ball at Amp describes his own setup in similar terms. He talks about “optimizing a specific part of our codebase to be more agent-friendly”, and he leans on the team’s shared skills rather than his own personal ones. I would want every team to have the same habit. If something makes the agent better, it goes into the shared environment, where every engineer and every agent picks it up.

Marco Mark’s My AI Engineering Journey is a good account of how people arrive here. He walks through eleven stages, from autocomplete to autonomous pipelines, and describes them as “a sequence of bottlenecks” rather than a sequence of tools. By the end his setup works, but “it all runs on my MacBook and is bespoke to my repo”, and the next step he describes is “making it available for all our repos and all teams, with reusable agent configurations, prompts and automations.” That step is AX. The organisations that get ahead will be the ones that take setups like his off individual laptops and turn them into something every team can use.

What this looks like in practice

The asset I know best is Rocketflare, a multi-tenant SaaS starter kit for Cloudflare Workers with tenancy, auth, roles, jobs, storage, an AI layer, analytics and a CLI. You clone it, rename it and start on your first real feature. The code is the less interesting half. The other half is everything that lets an agent work in it without me in the room:

• A root CLAUDE.md (with AGENTS.md symlinked to it) that is mostly a map. It points at the docs, and it says which of the kit’s skills the agent may run on its own, which only when asked (the security audit spends somewhere between $35 and $200+ of agent calls, so it agrees a budget first), and which only a human runs (provisioning, because it creates paid resources).
• A guide in each significant directory. Seven of them: the UI, the database, permissions, plugins, the CLI, the shared contracts and the test driver. Each one explains the local patterns where the agent will be when it needs them.
• Path-scoped rules. Seven rule files that only load when the agent touches matching paths. The database rules load for the schema and migrations, and stay out of the context the rest of the time.
• A concepts document with one section per subsystem, its numbered design decisions, and a Known gaps list. The gaps matter as much as the rest, because an agent that does not know something is missing will happily assume it exists.
• Thirteen skills for the things people do repeatedly: set up, adapt a fresh copy, “how do I”, preflight before deploy, read traces, run evals, upgrade.
• A reference feature built to be read and then deleted. A small notes plugin that touches every slot a feature can fill, with its own guide mapping what each part demonstrates. When an agent builds a new feature, it has a working one to copy from.
• Tests that enforce the conventions, so the ones that matter fail loudly when they are ignored, and nobody has to rely on the agent remembering them.

Copies can also pull in later releases of the kit if you want them to, because each release ships a porting note and an upgrade skill walks the agent through applying it. You could delete all of that and the kit would still do its main job, which is giving an agent that starts a new product working code that already explains itself.

It does not need to be this elaborate to be useful. A single repo of well-documented patterns (how we build an API endpoint, how we do a background job, how we structure a page) with a CLAUDE.md that says when to use each one is already an AX asset. So is a design system with usage notes written for an agent to read. Start with whatever your teams build most often, and make the agent copy it.

You do not need to use Rocketflare (though it would be great if you did!). You do need to think about how you would build something similar within your own team, starting with an agentic pattern agents can copy for each type of service in your architecture. You can start from an existing service you think is right, and Claude will very quickly generalise it into a pattern, with the guides, rules, skills and tests around it. For the right engineer this is days of work, if not hours, and the impact compounds on every new service you build from then on. I would put the capacity that AI frees up here first.

Factories for keeping the lights on

In the teams I have run, up to 40% of engineering time goes on work that keeps the product running rather than moving it forward. Dependency upgrades, flaky tests, small bugs, triage, security patches, migrations nobody wants to own. Harnesses and factories are absurdly effective on this kind of work, and they get much better when they sit on top of golden paths, because the factory is working in code that already looks the way it expects.

This is what Last Light does, for my own repos and now for projects within Nearform. Triage, review, dependency health and small fixes all run as deterministic workflows, and the same instance maintains drizzle-cube and drizby alongside itself. Over the last 30 days it ran 22,879 executions and used 2.1 billion tokens, for a total model cost of $145.68.

Warp’s Zach Lloyd wrote in August that they are “currently automating about 30% of our tasks through our factories.” I expect that number to go up, and I expect most of it to be the work nobody wanted to do anyway.

Factories for all the work

Keeping the lights on is where factories start. The same loop that picks up a dependency upgrade will, before long, pick up a feature, and I think that is coming whether we plan for it or not. At Ramp, Inspect “now accounts for 74% of merged PRs”, and Karim Atiyeh writes that their builders “now ship 6x as much code per person as they did a year ago.” Warp’s factories already handle about 30% of its tasks, and Ramp shows how far that share can go.

I am confident the patterns that help a small team move fast with quality are the same ones that will let a factory do it: copy, don’t create, put deterministic gates around every change, and give it assets that explain themselves. A factory starting from a blank file has all the problems an engineer starting from a blank file has, only faster and at a larger scale, and a factory starting from a good pattern inherits everything that pattern already knows.

I would focus on this later, though. Get the operating model, the assets and the platform in place for your teams first, because a factory multiplies whatever it is built on.

What an agent-first organisation moving at real speed looks like

Speed the business can see. The reason to do any of this is what a small team on a big problem does for the business. The legacy rewrite at the top of this post took a fraction of the people and a sixth of the time, which freed the money and attention tied up in the old system more than a year sooner. The lead management application was creating value two weeks after the work began, without a programme being funded and staffed first. And when building is this cheap, you can put more ideas in front of real customers and stop the ones that do not work much sooner. Those are the results I would take to a board.

Deep investment in AX and assets, done largely with AI. Reference services, kits, a design system with enforcement, golden path modules, skills and scripts. Owned by a team and versioned like any other product. Every improvement applies to every team and every agent from then on, so the investment compounds.

Small teams, pairs or individuals, on much bigger units of work. The unit of work has to change as much as the team does, and organisations resist it. We have spent years learning to break work into small tickets and tightly specified tasks, because that is what a team of humans passing work between each other needed, and because the first coding agents could only be trusted with something small. Neither is true any more. Today’s agents can take on a whole feature or a whole service, and when they start from a pattern they can copy they do it well.

That combination is where the highest value is. Copy, don’t create, applied to a large chunk of work, gives you a big piece of working software that already looks the way your team builds things. Slice the same work into twenty small specs and you pay for twenty rounds of specifying, reviewing and handing over, and the agent never sees enough of the problem to do its best work. A pair should own an outcome end to end, from problem statement to validated release. With a good environment underneath them, that is a few days to a couple of weeks of work.

Big teams on small tasks get the worst of both. If you keep six engineers and a PM working through a backlog of small tickets, each of them gets faster and the system does not. The bottleneck from before comes straight back as coordination and review. The Faros Speed Trap research from September is sobering here: average PR size up 71.8%, time in QA up 300.6%, and the share of PRs merged without review up to 76.3%. Brendan O’Leary at Kilo put it in four words in 1-Pizza Teams: “Coordination costs eat you alive.”

To be fair, not everyone agrees review stays the bottleneck. Thorsten Ball asks a better question: “are reviews the same thing they were three years ago?” I think he is right that review will change, and I think the way it changes is the environment. Deterministic gates, golden paths and good assets to copy from are what let a human review the decision and trust the gates with the individual lines.

Coming back to the original list of foundations, here is how I would rewrite it now:

• An AX team, funded and owned, building the assets agents copy from. This can just as well be internal open source: if your culture allows it, the assets are shared and every team contributes back.
• Golden path core modules for the things that must be the same everywhere.
• Kits and reference repos for everything else, copied and owned by the team that uses them.
• A design system the agent cannot ignore, enforced by lint and tests.
• Deterministic gates and harnesses for verification and KTLO, with models used only where judgement is needed.
• Instrumentation from day one, so validation does not become the new queue.

A year ago this was the footnote. It is now the post.

You cannot do this in place

My view on this has changed more than on anything else in the post. A year ago I described Value Pairs as an experiment you could run inside an existing product organisation. My current view is that it cannot be done in place, unless you are small enough to get everyone around a table at once and simply make it happen.

You cannot train everyone in AI-native engineering and expect the benefit to arrive by itself. The existing process and organisation will actively fight the change, and the hardest resistance comes from the layers of management that were added over time to coordinate the handoffs larger teams need. That is not bad faith. Those roles exist because the handoffs existed, and a model with far fewer handoffs threatens them directly. Put a pair inside that structure and the structure will pull them back into it: the same ceremonies, the same approvals, the same status updates, now aimed at two people instead of eight.

What I have seen work is doing it alongside the existing organisation. Find parts of your product or platform you can eject: a legacy system due a rewrite, a manual business process nobody loves, a new product line that has no existing team. Both of the examples at the top of this post were exactly that. Run that work in the new way, loosely coupled to the existing organisation and its process, on the assets your AX team is building. Then you eat the elephant one piece at a time, migrating more and more of the work towards the new model as it proves itself.

What do you think? If you have been running something similar, or tried and found it did not work, I would genuinely love to hear about it. You can find me on LinkedIn, or take a look at Rocketflare and Last Light and tell me what you would do differently.