When Building Is Easy, the Danger Is Building Everything

You had a backlog of fifty things, your team could build three this sprint, so you had to choose. Which three matter most? Which ones move the product forward? Which ones can wait? The constraint forced the conversation, and the conversation forced clarity about where the product was going.

That constraint is gone.

When agents can pick up an issue and ship it in an afternoon, the calculus changes in ways that feel good at first and turn dangerous fast. That feature someone asked for in a support ticket? Build it. The edge case a customer mentioned on a call? Handle it. The thing your sales team has been asking about for months? Done by Thursday.

You clear the backlog. You feel productive. Everyone's happy. And then one day you look at your product and realise it does everything and stands for nothing.

The backlog is not a product strategy

There's a version of agentic development where you become a ticket processor. Issues come in, you triage them, agents build them, PRs land. The backlog shrinks. It feels like progress because things are moving. But moving isn't the same as going somewhere.

Every feature you ship is a decision about what your product is. When those decisions were expensive, you made them carefully. When they're cheap, it's easy to stop making them at all. The backlog becomes the strategy. Whatever's next in the queue is what gets built.

I wrote in The Code Was Never the Job that deciding what not to build might be the most important part of my day. Agents are genuinely terrible at this. An agent will happily build anything you ask it to. It won't tell you that a feature adds complexity without enough value, or that the simpler version is good enough. It doesn't know where the product is going. Only you know that.

Estimation doesn't survive this

Traditional estimation was always about implementation cost. How many days, how many story points, how many sprints. A feature estimated at two weeks got weighed differently than one estimated at two days, even if the two-week feature was more important for the product.

When agents collapse implementation time, that framework stops working. The two-week feature takes an afternoon. The two-day feature also takes an afternoon. Story points lose their meaning. The entire planning ritual that most teams organise their weeks around suddenly has nothing to measure.

So do you replace estimation with something, or do you just stop?

I think you stop estimating effort and start estimating impact. The question isn't "how long will this take to build." It's "how much does this change the system" and "what's the blast radius if it goes wrong." A small feature that touches a critical boundary is a bigger deal than a large feature that's self-contained, regardless of how long either takes to implement. That's always been true, but implementation cost used to dominate the conversation so heavily that nobody thought about it properly.

What you need to know before greenlighting work isn't how many hours it takes. It's what it does to the product, the architecture, and the users. Architectural estimation, not implementation estimation. Another thing agents can't do for you.

If you're not deciding, why are you here?

If you're saying yes to everything on the backlog, if agents are just implementing whatever comes next in the queue, what exactly is your role?

You've turned yourself into a middleman between the ticket queue and the agent. At that point, why not fully automate it? Let the agent triage the issues, plan the work, implement it, review it, and ship it. Take the human out entirely.

That's the logical endpoint of "build everything." Nobody steering. A product that grows in every direction at once, which is the same as growing in no direction at all.

The whole reason a human stays in the loop isn't to approve plans or check code. The agents handle that. It's to say "no, not this, not now, that's not where we're going." Take that away and you don't have a product team. You have a feature factory with nobody at the wheel.

Stay close, stay ahead

The discipline that matters now is knowing your users well enough to understand what they actually need, and having a clear enough vision to be a little ahead of them.

Marty Cagan has been making this argument for years in Inspired. Most teams spend too much time on delivery and not enough on discovery. For a long time that felt aspirational, because delivery was so expensive it dominated everyone's attention. Now delivery is essentially solved. The teams that internalised Cagan's thinking about product discovery are perfectly set up for an agentic world. The ones that were always delivery-focused just lost their differentiator.

A little ahead. Not a lot. Not building the abstraction layer for a use case that might exist next year. Not shipping the enterprise feature because someone on the sales team thinks it might close a deal. Close enough to your users that you understand their real problems, far enough ahead that you're solving the next one before they ask.

Staying close also means being able to adapt instantly when the moment is right. A few days ago, swamp was approaching one million events. One of our team noticed and thought it would be cool for the user who made the millionth event to get a custom badge in the product. They floated it in Discord, someone suggested a name, and thirty minutes later the feature was live. That user now proudly displays the badge. The whole community lit up about it. That kind of moment builds loyalty that no roadmap feature ever will.

That's speed paired with taste. The team didn't build it because it was on a roadmap. They built it because they were close enough to the users to recognise a moment worth celebrating, and the agents made it possible to act before it passed.

But the temptation to just build things is enormous when every feature is an afternoon's work. "It's only an afternoon, what's the harm?" The harm is that you said that about the last twelve features too, and now your product is twelve features heavier with no clearer sense of what it's for. Every feature ships forever. It gets maintained, tested, documented. The implementation was cheap. The complexity is permanent.

Saying no is everyone's job now

In the old world, the hard skill was implementation. In an agentic world, it's taste. Knowing what belongs and what doesn't. Having the discipline to keep your product focused even when building the wrong thing would only take an afternoon.

I've caught myself skipping that discipline. An issue comes in, it's clear, the agent could knock it out in an hour. Then I stop and ask: does this make the product better, or just bigger?

This goes beyond engineering. Think about the traditional PM day. Prioritise the backlog. Estimate with engineers. Plan the sprint. Negotiate scope because the team can only build three things this cycle. Most of that work existed because building was expensive and someone needed to manage the scarcity. The scarcity is gone. Sprint planning becomes ceremony. Negotiating timelines feels absurd when the honest answer is "we could probably ship it tomorrow."

PMs who were primarily backlog managers are in real trouble. But PMs who were always about product vision and the courage to say no? They just became the most important people in the room.

Every role that touches product is going through this. Engineers, PMs, designers, QA. The mechanical parts evaporate. The judgment parts become everything. When the bottleneck isn't implementation, what's your actual contribution?

The moat is gone

It's not just features. The same thing happens with refactors, framework migrations, infrastructure changes. When rewriting a subsystem takes an afternoon instead of a quarter, every "we should switch to X" conversation becomes dangerously actionable.

Someone reads a blog post about a new framework. Six months ago that conversation dies in a planning meeting because nobody can justify the migration cost. Now an agent can do the rewrite by end of day. So you do it. Then someone else reads a different blog post. Then you're swapping your database layer because the new one benchmarks better on a workload you don't actually have.

The moat that used to protect your architecture from churn was the cost of change. That moat is gone. The implementation cost dropped but the real costs didn't. Your team still has to understand the new patterns. Your users still feel the instability. You've burned a week and your product didn't move an inch forward.

When a migration is the right call, the speed is transformative. We just moved our entire infrastructure from Railway to DigitalOcean. Without agents, that's a couple of weeks of careful work. It took a day. The difference is we did it for a clear reason, not because someone read a blog post.

Refactoring is the same trap. When extraction and reorganisation are cheap, it's tempting to refactor constantly. But refactoring without a reason is just rearranging furniture. The question isn't whether the code could be better. It's whether the current structure is actually preventing something you need to do next.

I refactor a lot. But every session starts with a reason: this structure is going to make the next set of changes harder than they need to be. Not "this isn't how I'd write it today." Not "this module is too big." Those aren't reasons to restructure something that's working.

The right approach is architecture designed to evolve. Keep boundaries clean so subsystems can change independently. When you do need to migrate or rearchitect, the blast radius is contained and the path is clear. Agents are incredible at executing evolutionary change, fast, thorough, across dozens of files in a single session. But evolution is different from revolution. Push too far too fast and you're not evolving, you're destabilising. The system needs time to settle. Your team needs time to absorb new patterns. Your tests need to prove the new structure holds under real usage, not just in CI.

Build less, but build what matters

For swamp, we could build an enormous amount of features every week if we wanted to. We deliberately don't.

We stay close to our users. We watch how they use the product. We read their bug reports, their feature requests, the things they struggle with. And then we decide what belongs next. Not what's easiest to build. Not what someone asked for loudest. What moves the product toward where it needs to go.

A disciplined team with agents can move through meaningful work at a pace that would take a traditional team years. Not by building everything on the backlog, but by finally getting to the important things that never survived prioritisation. The features that sat at the bottom for years because the expensive ones above them always won. The architectural improvements that never justified a quarter of engineering time. The quality of life changes users kept asking for and kept getting told "maybe next sprint."

That's the reward for saying no to the wrong things. You get to say yes to the right ones, faster than was ever possible before.

That's the job now. Not building fast. Building right. Knowing your users, having a direction, and saying no to everything that doesn't serve it.