When a ticket is created on our team, an AI agent picks it up by default. A human only gets pulled in if the agent escalates.

How did we get here? In the beginning, there were engineers. Then engineers got AI assistants, and the assistant sat next to the human: you’d pick up a ticket, figure out what was worth delegating, and hand pieces of it to the model. The human was the one actually working the ticket. AI was optimizing the developer’s throughput.

The key shift that we made 3 weeks ago was that by default AI does the work. Engineers spend their time unblocking them: giving them context, shaping the environment, deciding what should trigger an escalation, fixing the cases where they get stuck. Our biggest bottleneck now is code review.

The job of the engineer stops being “do tickets” and starts being “design the conditions under which tickets get done.”

The results so far: 5 engineers running this system ship roughly as much as the other 50 on our engineering team combined.

And this is V1. It’s the dumbest the system will ever be. V2 is already underway. We are building a machine that turns tokens into product delivery capacity. Now the developer is optimizing the AI’s throughput.

If you’re trying to get more out of AI in engineering, the question probably isn’t “how do I delegate better.” It’s “what would it take for the agent to pick up the work by default.”

“Things feel slow. We need an eng velocity metric.”

This is almost always well-intentioned. We should always want to move faster. And in practice, engineering will almost always feel slower than we want it to be—especially from the CEO’s perspective. That tension is normal and permanent. If it ever goes away, something is wrong.

It’s tempting to respond by looking for a single number that explains the feeling. I’ve read extensively on this topic—’s is a favorite—and the conclusion is consistent: there is no single metric that can definitively tell you whether an engineering organization is “fast.” Velocity matters, but it does not collapse cleanly into one measurement you can manage directly.

While there is not a single metric that exists, based on my research and hard-earned experience, these are the tools that I reach for when building a high velocity culture.

Talk About Velocity. A Lot.

Culture changes because people talk about something repeatedly and without embarrassment.

If you want a high-velocity engineering culture, velocity has to be discussed openly and often. Not as a threat. Not as a performance weapon. As a shared goal. People should hear it in planning meetings, retros, one-on-ones, and hallway conversations.

This starts with stating the obvious: of course we want to be faster. Of course there is room to improve. Saying this out loud regularly matters more than most process changes.

Wins should be loud. Shipping should be celebrated. Progress should be visible. This reinforces that velocity exists to help engineers do their best work, not to pressure them into cutting corners.

This also creates a shared language. Talking about speed should not feel like an accusation or a critique of individual engineers. It should feel normal, neutral, and collective—something the team owns together.

As a side effect, this helps with managing up. When velocity is a consistent topic, CEOs and execs feel that it’s being actively worked on. They stop asking for a single magic metric and start trusting the system.

Identify What’s Slowing You Down

You cannot make a team faster if you don’t know where time is being lost.

Some sources of drag are technical. Builds are slow. Tests are flaky. Deploys are fragile or mysterious. Engineers are usually very aware of these.

Others are organizational, and these are often harder to surface. I had a CTO friend recently realize that one reason teams were reluctant to ship early was that the ops team would yell at engineers any time a change was made without weeks of advance notice for training. From the outside, it looked like a lack of urgency. In reality, it was a rational response to punishment.

A high-velocity culture makes it easy to surface this friction. The cost of reporting drag should be close to zero; otherwise, people simply won’t do it. Engineers should be able to say, “This slowed me down,” without defensiveness or fear of consequences.

One simple mechanism is a lightweight velocity retro at the end of a project. Ten minutes. No slides. Just a central place where engineers can drop a list of everything that made progress slower than it needed to be. We especially want the embarrassing stuff, so we have the opportunity to fix it.

This process must be continuous. If friction is only discussed occasionally, it will compound faster than you can remove it. Teams that feel fast are not the ones without problems—they’re the ones that surface and address them quickly.

Measure What Slows You Down

While measuring velocity directly is close to impossible, measuring the things that slow you down is usually straightforward.1

Start with the inner development loop: edit, build, test. This loop is sacred. If, after each change, an engineer has to wait long enough that their attention drifts, velocity is already gone.

Build time, test time, and deploy time in CI matter more than almost anything else. If this loop feels slow or unreliable, nothing else in the system will feel fast.

Beyond the core loop, there are other common sources of measurable drag:

• Code review turnaround time

• Time to deploy (if deploying is slow, people do it less, and iteration slows with it)

• Time to first deploy

• Flaky tests and intermittent failures

• Hard-to-read code or missing patterns

For engineering work, having a concrete quantitative metric to ratchet down is powerful. When you’re confident something is slowing you down, measure it and reduce it. You may not be able to measure velocity directly, but you can measure drag.2

Build a Productivity Baseline (Carefully)

You need a productivity baseline.

Not because maximizing output is the goal, but because without baseline data, the right conversations don’t happen. “It feels slow” is not something you can debug. Concrete data gives teams a shared starting point for understanding what changed and why.

Story points (or an equivalent) are sufficient for this. They don’t need to be precise; they need to be consistent. Shipping roughly 20 points one sprint, 22 the next, and then 15 after that is enough to ask useful questions. Without that data, those questions simply don’t happen.

Each team should also be using a productivity tool to collect this data. Tools like DX, LinearB, Jellyfish, and similar systems are best thought of as instrumentation. They surface patterns around PR throughput, cycle time, and deploy frequency that are otherwise hard to see.

The caution is in how these tools are used. The moment a baseline becomes a target, behavior will shift to optimize the number instead of the system. That’s the predictable Goodhart’s Law failure mode.

This is where the earlier, more qualitative cultural work matters. If you actually did the work to build a culture that genuinely cares about velocity, this data becomes empowering. Teams use it to be curious about their own bottlenecks and improve without being told what to do. If you skipped that part and jumped straight to dashboards, the same data will feel like overhead or surveillance—and will be treated accordingly.

Holding Leaders Accountable for a Velocity Culture

Velocity does not sustain itself. It has to be actively propagated.

Leaders are responsible for keeping velocity present in how work is planned, discussed, and reflected on. That means making speed a normal topic of conversation—not a reaction to pressure, not a postmortem after something goes wrong, and not a proxy for performance management.

For any meaningful project, leaders should be pushing on timelines, not to create stress, but to surface assumptions. How long do we think this should take? Is that timeline conservative? What would have to change for us to be more aggressive? Asking what it would take to do the work in half the time is a useful forcing function. Not because it’s realistic, but because it reveals where scope, process, or sequencing can be rethought.

While there’s no clean way to roll velocity up into a single aggregate number, teams that care about velocity develop a strong intuition for it at the project level. “This used to take us a month, now it takes a week.” “Why is it so hard for us to upgrade to the next version of Postgres?” It is much easier to have a quantitative intuition for what fast looks like at a project level. Of course it’s not the magic eng velocity number that the CEO asked for, but sampling how long individual projects take can help build up data to better understand velocity.

That intuition only forms when leaders consistently reinforce it. By creating space for teams to notice when work feels slow, when progress stalls, or when a change meaningfully compresses timelines, leaders turn those observations into shared context. Retros surface what sped things up or slowed them down, and follow-through removes friction.

It’s intentional that this section keeps saying leaders. This work can’t be centralized. A VP of Engineering can’t be everywhere, and shouldn’t try to be. Velocity culture spreads through leaders throughout the organization. While this should be a core responsibility of engineering managers and staff engineers, there are many kinds of leaders in an engineering organization, and all of them should be accountable for nurturing a culture of velocity. In engineering, this looks like engineers jumping into reviews unprompted, fixing flaky tests they didn’t write, improving build scripts they don’t “own,” and noticing when someone is stuck before it becomes a ticket. You see this same pattern in elite sports teams, emergency rooms, trading floors, and flight decks — places where collective tempo matters more than individual heroics.

A Note on AI and Velocity

It would be strange to write about engineering velocity in 2026 without acknowledging that AI is already changing how software gets built.

This piece is intentionally not about AI tactics. That’s a long conversation unto itself, and this post is already much longer than our median article. What matters here is that teams with a strong velocity culture naturally start asking better questions about how AI fits into their work.

They don’t ask, “How do we mandate AI usage?” They ask, “What’s slowing us down, and can AI remove it?” Can mundane work be turned into background tasks that generate PRs while engineers sleep? Can reviews, refactors, or migrations be accelerated without increasing risk? Can development environments be reshaped so that product requirements flow directly into agents that can build or scaffold features themselves?

Consider this a teaser on some of the most interesting ways that AI can accelerate engineering teams.

Engineers Need to Ship

I worry that this focus on velocity can sound crushing at first. That reaction is understandable. Velocity often gets conflated with grinding harder. They are orthogonal. This approach isn’t about grind; it’s about intentional growth and improvement.

Is it intense? Yes. When it’s working, people are locked in and working hard. Great engineers have a deep-seated desire to ship great things. Velocity alone won’t fix poor compensation, bad management, or a weak mission — but without velocity, even those rarely hold great engineers for long.

A healthy velocity culture creates an environment where engineers can work on important problems, move with urgency, and see their work land in the world. Over time, that turns velocity from a management concern into a powerful part of your retention strategy. A high-velocity engineering culture builds a virtuous cycle where it helps grow your business and attract and retain talent.

1

Credit to for introducing me to this idea.

Engineering Enablement

The Case Against Measuring Cycle Time

This is the latest issue of my newsletter. Each week I cover research, opinion, or practice in the field of developer productivity and experience. This week is an article I wrote about cycle time…

Read more

3 years ago · 11 likes · 4 comments · Abi Noda

On one side, there’s a calm, spreadsheet-friendly story: AI is just another productivity tool. It nudges GDP up a couple of points, makes companies more efficient, and otherwise fits neatly into existing economic models.

On the other side, there’s a much louder story: widespread job loss, social upheaval, and a fundamental break from how work has functioned for the last century.

What gets lost is that these two narratives aren’t actually in conflict. They’re describing different points on the same timeline.

In the short run, the disruption-focused view is often right. Technological change hits faster than people can adapt. Skills depreciate. Institutions lag. The impact is uneven and concentrated.

In the long run, the steady-growth view usually wins. Productivity gains compound, new roles emerge, and the next generation adapts by default by growing up inside the new system.

The mistake is pretending that this timeline is smooth.

Technological change doesn’t fail loudly or succeed quietly. It succeeds eventually, after a period where a very specific group absorbs most of the cost.

When massive technological or economic change hits, humanity eventually figures it out. One or two generations later, things mostly work. New jobs appear. Institutions adapt. People point at the GDP chart and declare success.

But the generation caught in the transition? They tend to get wrecked.

The cleanest recent example is the China shock.

US GDP was fine. Consumers benefited. Economists nodded. Meanwhile, a mid-career factory worker with location-bound, asset-specific skills lost their job, their leverage, and often their community. “Just retrain” is great advice if you’re 19. It’s a gamble if you’re 45.

The pattern repeats:

• The Industrial Revolution eventually raised living standards, after decades of brutal work and political conflict

• Agricultural mechanization hollowed out rural labor

• Software quietly ate clerical work and entry-level white-collar roles

Net positive. Locally catastrophic.

Viewed through this lens, the AI trajectory looks fairly predictable. For the work that already exists today, we’re going to need far fewer people to do it. In practice, that shows up as job replacement.

The impact won’t be evenly distributed. Some sectors will absorb the shock first — customer support is the canary. When AI meaningfully pairs with robotics, displacement stops being confined to screens and starts showing up in physical work as well. Software engineering won’t be spared either: teams get much smaller, individual leverage goes up, and output concentrates.

What is clear is that much of what we currently think of as the most valuable and productive work no longer needs humans — or at least, far fewer of them. That severs a link we’ve relied on for a long time: productivity as the primary justification for livelihood. It’s a structural break that societies won’t metabolize quickly.

From there, several equilibria are possible. Maybe abundance enables stronger social systems, and a decent quality of life becomes less tightly coupled to formal employment. Maybe we invent new kinds of work — after all, we already have plenty of post-subsistence jobs. Or maybe some mix of Jevons’ paradox and the effective defeat of Baumol’s cost disease explodes entrepreneurship and cheap consumption in ways we haven’t fully internalized yet.

AI is an enormous unlock for humanity. The question isn’t whether the system benefits in aggregate — it almost certainly will. The question is who bears the transition cost, and when.

In the old model, if an inventory feature needed six engineers’ worth of work and you only had three, you hired three more (four, if you’d been burned by attrition before). More work meant more humans because humans were the execution layer.

In the AI model, agents handle most of the execution. You still need a small number of engineers who deeply understand the feature—at least two, to avoid bus factor—but if you need more execution throughput, you buy it as tokens, not headcount.

By cognitive load, I mean something very specific: deep ownership of a system. Understanding how it works technically, how it serves the customer, where it can fail, and which invariants actually matter. This has to live with an engineer. If secrets leak or data is corrupted, you can’t reasonably hold a PM—or today’s app-builder tools—responsible. It’s possible those tools eventually get good enough to own this kind of accountability, but they’re not there yet. You still need a throat to choke, and it needs to belong to someone who actually understands the system.

That’s the real limit. Not how much code can be written, but how many systems an engineer can accurately hold in their head and be accountable for at once.

A few corollaries fall out of this.

First, the more AI reduces cognitive load, the smaller engineering teams can be without breaking. Execution is cheap; understanding is not.

Second, for agents to act like real execution engineers, we need to be far better at sharing context with them. They need to know the codebase, the invariants, and the “why,” not just generate plausible diffs. That implies documentation living with the code. Engineers won’t reliably do this, but agents can—if we make auto-updating docs part of the workflow.

Third, engineers are going to write far less code. Possibly none. Their primary job becomes reviewing generated code submitted by PMs or other non-engineers, or handing designs to agents and letting them implement. Even when engineers make major changes, they’ll often do it by directing an agent rather than typing everything themselves.

The underlying AI is probably good enough already. What’s missing are the tools: context management, infra automation, and guardrails that reduce supervision overhead instead of adding to it.

In the AI era, teams won’t scale with how much work needs to get done. They’ll scale with how much responsibility a human can realistically carry.

Remote: Talent First, Pay in Process

Great companies are built on great talent. Remote’s core advantage is simple: it massively expands the talent pool. Even with time zone constraints, you can hire people you’d never reach otherwise.

The cost is that context, trust, and momentum don’t emerge naturally. They have to be artificially manufactured. Meetings replace osmosis. Docs replace hallway conversations. Slack replaces tone. Team bonding follows the same pattern: in person you eat lunch together and build relationships by default; remotely you schedule offsites and Zoom “bonding.” None of this is fatal—but all of it is work. And it shows up most clearly in ideation: good ideas come from people talking to each other, and almost no one wants to casually brainstorm on Zoom the way they will at a whiteboard.

Remote is also meaningfully worse at training junior people. We are still waiting for someone to publish the seminal blogpost on how they solved growing new grads in a remote environment.

In a startup, time is the scarcest resource. Remote teams pay a small coordination tax per person relative to in-person teams, and that tax compounds nonlinearly as the team grows.

In-Person: Energy First, Optionality Reduced

In-person optimizes for speed, energy, and tight feedback loops. Alignment is cheaper. Intent survives the trip from one brain to another.

The tradeoff is talent optionality. You’re bound to a local labor market, which in places like SF is extremely cyclical. In the last five years alone, roughly half the time it’s been nearly impossible to hire (crypto, AI booms), and the other half merely difficult.

That volatility is the price.

The Middle Is the Failure Mode

Most problems come from unclear optimization. That’s how you get the worst-of-all-worlds setup: nominally in-person, functionally remote, culturally confused.

If you choose in-person, it has to actually be in-person. That means accepting reduced access to parts of the talent pool. That’s the trade. In-person maximizes energy and commitment. Remote maximizes access to exceptional talent.

Both are fine. Waffling is not.

Conclusion

This isn’t about ideology. It’s about systems design. Every model has costs, and pretending otherwise just pushes those costs into places you’re not watching. My intuition is that AI-driven smaller teams push the needle toward remote, but not decisively. Smaller teams blunt coordination costs, yet also make co-location feasible. In the meantime, the best thing you can do is be explicit about what you’re optimizing for, honest about the costs, and willing to commit. Ambiguity is the only option that reliably makes everyone worse off.

In Part 1, we talked about using LLMs to generate ephemeral tests that unfreeze legacy code — basically treating your AI as a bored-but-willing intern who will brute-force the emergent contract you’re too scared to guess at.

But there’s an adjacent point I keep circling back to: if the marginal cost of writing a test is now effectively zero, we’ve been massively underusing tests everywhere, not just in fossilized code.

Most of us only write tests when we “need to.” Translation: right before we touch a landmine. But writing tests as part of the exploratory process? Understanding new tools? Probing edge cases you didn’t think of? Historically that’s been too slow, too expensive, and too annoying. Now it’s just a cheap prompt away.

1. Testing unfamiliar systems: documentation by empiricism

This is basically the same move as Part 1 but for greenfield work.

You pick up a new library, framework, or middleware — say, the thing at my job that magically turns incoming JSON into Kotlin objects, plus some undocumented set of delightful quirks that everyone politely ignores.

Before, your options were:

• Read the docs (ha).

• Read the source (double ha).

• Ship something, hit prod, and learn what actually happens (the traditional method).

Now you can just have an LLM carpet-bomb the thing with tests and infer the behavioral terrain map. Ask it for dozens of permutations: missing fields, extra fields, weird nesting, bad types, whitespace crimes — all the delightful real-world entropy the docs never mention.

Most of these tests you’ll delete. A few you might keep, because they reveal a “fun” subtlety that Future Developer (which is also Present Developer + six months of memory decay) is going to trip over.

It’s like doing reconnaissance on a foreign API. Except now the recon is both free and tireless.

2. Testing things you didn’t think of

At a recent conference, George Fraser from Fivetran said something to the effect of:

“I get an LLM’s opinion on everything I do, because sometimes it notices something I don’t.”

That stuck with me.

Not because I need more opinions in my life (I write software; opinions are my primary export), but because it’s the exact same philosophy as ephemeral testing:

Ask the model to test your code for cases you never considered.
Worst case: the tests are useless and you don’t commit them.
Best case: it surfaces a weird edge case that would have cost you a day of debugging and a grumpy Slack thread.

Treat your LLM like an extremely pedantic coworker who specializes in pointing out the one thing you forgot. The key difference is that you don’t owe the LLM coffee or emotional labor.

3. The next frontier: acceptance testing via prompt

This last bit is more speculative, but I’m increasingly convinced that some tests shouldn’t be written in code at all.

Long-lived automated tests age poorly. They embed outdated assumptions in a thousand helper functions and silently pass even after they stop exercising the actual code path.

But a prompt like:

“When I update the number of records moved in a replication job, the job summary returns the updated count.”

…is short, human-readable, and tightly scoped to intent, not implementation.

Imagine a small suite of English prompts that represent the product’s core acceptance criteria. As part of CI, you ask an LLM to execute those prompts against your system and confirm that reality matches the story.

Two nice properties fall out of this:

1. It detects mismatches between the code and the canonical user-facing behavior. Maybe the old tests still hit the v1 endpoint, while your docs point to v2. A human might miss that; an LLM poking at the surface won’t.

2. Anyone can write prompts. We needed QA teams because the tools for encoding and checking product level behavior required a lot of technical expertise. If PMs, designers, and support can maintain their own prompts to describe what workflows they care about, that unlocks entirely new ways of approaching QA.

Of course, there’s an obvious landmine: LLMs are nondeterministic, and flaky tests are how engineering teams slowly lose their will to live.

So I’m not claiming victory here. This idea needs more experimenting — guardrails, temperature controls, scenario anchoring, maybe multiple-run consensus. But the shape of the opportunity is interesting: acceptance tests that read like requirements, not code.

The bigger shift: when tests hit zero marginal cost

This whole series boils down to a simple economic shift: writing tests just dropped from “painful but virtuous” to basically zero marginal cost. And any time something useful collapses to zero marginal cost (think Ben Thompson and Aggregation Theory), the right question isn’t “How do we do the old thing cheaper?” It’s “What new behaviors does this unlock?”

That’s the invitation here. Once tests are cheap, they stop being artifacts you carefully curate and start becoming probes — disposable instruments for exploring unfamiliar code, mapping legacy behavior, surfacing missed edges, or even expressing acceptance criteria in plain English. The examples in these posts are just early sketches. The real point is: we should get weird and creative again. When tests cost nothing, the space of things worth testing suddenly gets a lot bigger.

Subscribe now