The Velocity Trap Portfolio Construction in the Agent Era
Intro
A couple of weeks ago I was in a 1:1 with one of our senior engineers – the kind of 1:1 that starts on the agenda and ends on a whiteboard. She had pulled up our current project list on her laptop and asked:
"Do you feel like we're actually building toward anything, or are we just shipping?"
I made some hand-wavy noise about velocity and positive feedback. She let me finish. Then: "Because I think we've shipped more than twenty things since the last sprint, and I can only tell you what a handful of them were for."
I went back to my desk, poured the last of a lukewarm KLLR from Ethiopia, and pulled the same list into a spreadsheet.
She wasn't pointing at the wrong things. She was pointing at a single backlog that had quietly become different kinds of work fighting over the same attention and the same calendar. Last week I was discussing the same thing with our Head of Engineering; after we wrapped up, I saw a tweet that made things a bit clearer.
Brooker's Ratio
Marc Brooker stated in that post that "The fixed cost of building software collapsed; the cost-complexity curve flattened." I couldn't agree more. You see this clearly in the number of PRs and issues that are shipped.
If you think about it as a formula, it looks like this:
Historically, the cost of writing, testing, and deploying code scaled linearly or exponentially with the complexity of the feature. That is the Cost of Execution.
AI agents are driving that cost toward zero. They can produce reasonable code in a fraction of the time it would traditionally take. But as execution compresses, everything around it stays the same: alignment, meetings, specs, architectural reviews, etc.
The fixed overhead of your development process does not change. This means the process is now your primary bottleneck.
In other words:
Then he goes on and talks about three distinct side effects of that change: the cheapened middle market (work that was already viable got cheaper to create and develop), the sprawl (cheap low-value software became newly viable; the "vibe-coded" surge), and the frontier (expensive high-value software became attemptable, with long lead times). His own caveat on the last one sticks with me: "because costs and complexity here are rather high, the effects of this change aren't as visible yet."
Three effects. Three kinds of projects. Different economics, different failure modes, different staffing shapes.
Our job as lead engineers is portfolio construction: Deciding what kinds of bets the team is making, in what proportions, against what time horizons. The three buckets are how you see the portfolio clearly. And by default – if you don't actively manage it – is that one bucket quietly starves while your attention is on the others. Ask me how I know.
The three buckets in your portfolio.
1. Mid-Market Core
The roadmap. The known-good SaaS work.
These are the projects that already have specs. Your PM can talk about them from memory. The shape is clear, the requirements are stable, the question is execution quality. Using Brooker's framing, this is Product work, not Craft work.
What it feels like to work in this bucket right now: the typing is fast enough to feel like cheating. An agent will scaffold the UI in an afternoon. The hard part isn't the code anymore – it's noticing that the agent quietly used three different color schemes across two versions of the same feature because the existing code had inconsistencies, and it averaged across them.
Misalignment is now the most expensive part of the lifecycle. You can ship a big refactor in a day; validating that it matches the intent across a dozen endpoints takes three days in code review. Reviewer's Burnout is the lived experience of this inversion – you spend more time saying "no, that's not exactly what we meant" than you do approving.
What it feels like to work in this bucket right now: the typing is fast enough to feel like cheating. An agent will scaffold the UI in an afternoon. The hard part isn't the code anymore. It's noticing that the agent quietly used three different color schemes across two versions of the same feature because the existing code had inconsistencies, and it averaged across them.
This is the bucket that screams loudest in leadership reviews. The Linear burndown is here. The flashy demo is here. High velocity is expected. It's extremely easy to let it grow to eighty percent of the backlog while you're not looking… which is exactly how it overtakes the space of the other two buckets of projects.
Misalignment is now the most expensive part of the Software Delivery Lifecycle (SDLC). You can ship a big refactor in a day; validating that it matches the intent across a dozen endpoints takes three days in code reviews. Reviewer's Burnout is the lived experience of this inversion: you spend more time saying "no, that's not exactly what we meant" than you do approving.
2. The Sprawl
Small utilities. Internal tools. Niche experiments.
Brooker points at @CNC_Kitchen as an example: A hobbyist building a tool "that many people have wanted for a long time" and he built it alone, in a weekend. In the old cost structure it never penciled out. He's explicit that this class of software is good for consumers, even if it looks like slop to craftspeople.
Our version of this materializes quietly. A customer-success manager has been hand-copying numbers into a spreadsheet every Monday for months to spot unusual movement. Not a roadmap item. Not anyone's roadmap item. Someone hears about it, spins up a small agent-assisted task in an afternoon, and now the CSM shares an auto-refreshing view with a customer every week. Two hours of engineering time. Several hours a week of CSM time recovered.
That's the bucket. Useful-to-someone, low-value-at-scale, near-zero-cost. Work that wouldn't have been built a year ago.
The failure mode is Sprawling tech debt: the new tool works beautifully. Three months later, an engineer updates the schema in the database and it breaks silently. A report goes out with stale numbers, and the post-mortem starts with the sentence "we didn't even know about this dependency." The Shadow AI risk sneaks in the same way: think a personal agent-powered script to do some work that's never committed to source control, runs from their laptop only with no audit trail. Your compliance and security tooling has zero visibility into what it touches.
You have to cap bucket two work, and audit it every quarter. Underinvest in it, and you miss real wins; overinvest, and you spend Fridays reading Slack threads about mystery CLIs and shadow workflows.
3. Foundational Frontier
Load-bearing platform bets.
These are foundational investments that used to be multi-year projects: A live-scoring evaluation framework several downstream improvements depend on or that infrastructure migration that no customer will ever notice, but every future feature depends on. They would have been staffing-suicide at a lean startup two years ago. They're possible now because the cost curve flattened enough that a small team with agents can credibly attempt them. This is the biggest benefit of this shift, and it's the one most teams might miss.
What it feels like: slow, quiet, full of architecture documents and technical decisions. You spend eight weeks finalizing that new framework, and you can't point at a shipped feature.
A Bucket 3 project can die in a single planning session. Someone points at it and asks: "What's the customer impact if we delay this a quarter?" The honest planning answer might be: none. The true answer: every downstream thing we want to ship sits on top of this platform, and if we don't rebuild it now, we're shipping all of it onto a substrate that breaks at the next traffic inflection point. The first answer is what the roadmap sees. The second is what the system actually needs. Your leadership skills are key for this bucket.
There's a second, slower consequence worth naming: Junior Talent Starvation. When platform bets are staffed with senior engineers and an army of agents, the work gets done fast – but the judgment behind the work becomes invisible. Why DynamoDB over Postgres for ephemeral state? Why these retry semantics? Why that new orchestration boundary fits better? Someone with experience makes those calls intuitively; an agent builds the solution without asking. Engineers early in their career are not learning the whys anymore. A year from now, when you need to staff the next platform bet, the pipeline of engineers who can lead it might have dried up, unless you consciously make sure that it’s happening.
Visibility Asymmetry
Here's the part I keep coming back to. The three buckets are not equally visible to other people when making planning and staffing decisions — and the ordering is inverted from the signal.
The sprawl is loud. Bucket 2 dominates the twitter feed. Every "look what I shipped in an afternoon" post lives here. Every "AI slop" complaint lives here. Brooker's own line is that the flood is the most visible effect — which is precisely why it drives the narrative.
The mid-market core is invisible by design. Bucket 1 looks, from the outside, like the same roadmap work teams have always shipped. The economics changed underneath — margins compressed, velocity expectations climbed. A feature ships. The roadmap stays green. The PR Count per feature has exploded, but nobody outside the team can tell that the ratio of alignment-to-execution quietly inverted.
Now we need to track Decision Velocity — how fast a decision moves from idea to shipped.
The last one hasn't happened yet. Brooker's observation — that Bucket 3 effects aren't visible because lead times are long — is the one that matters most for planning. The Bucket 3 projects I should be funding now will not ship this quarter. They might not ship next quarter. You won't get quick rewards for starting these projects.
Volume across buckets is anti-signal The loudest bucket carries the least information about where the moat is. Out-executing inside Bucket 1 isn't a moat anymore. Bucket 3 is where you build the new moats.
Portfolio Review
Now that our job is portfolio construction, take time to review your own portfolio.
Answer these three honest audit questions to help manage it:
- Is my team too focused on shipping "commodity" features from Bucket #1?
- Is my Bucket #2 work capped, or is it just that I'm not seeing it?
- Is my Bucket #3 investment where it needs to be? What's the story if the answer is no?
You can also ask Claude for help. Here's an example.
Let me know if you’re seeing something similar. Thanks for reading!
Now, coffee time. Enjoy!
Coffee Time: The 4:6 portfolio planning method
Block 90 minutes. Brew a perfect pour-over using the 4:6 method:
- Use 20g coffee (coarsest setting, similar to a French press) and 300ml water.
- Divide your water into five equal 60ml pours, leaving about 45 seconds between each.
- At three and a half minutes, remove the dripper.
This method yields a brilliant cup, giving you exactly the focus you need because this exercise takes a while.
Pull your current quarter's project list onto a single page. For each project, write one letter: C for Core, S for Sprawl, F for Frontier. Don't let yourself write two letters for a project.
Count them up. Convert to percentages. Think if your portfolio is balanced.
For every F on the list, write one sentence describing the argument you'd make in a meeting when someone asks what the customer impact is if you delay it a quarter. If you can't, the project is probably going to die in the next quarterly planning.
Bring the sheet to your next skip-level and discuss it. The most useful hour of the quarter is usually the one where the two of you disagree about a letter.