A squad of eight on a product area usually had one or two people who actually understood the system. The rest were following. They wrote code against decisions someone else had made, and the depth lived in a couple of heads. When someone wasn't pulling their weight, the team absorbed it and nobody could see it clearly.

In the AI age we staff one or two engineers per area.

This isn't a headcount story. It's the opposite: the same engineers now cover far more surface area, and we can sprint on more of the product at once than we ever could with squads.

The work that made large teams necessary moved. Execution capacity comes from the LLM. Most bug work runs in the background. The engineer's job moved up a level: build the system that writes the code, encode enough of the product intent that what comes out is right, and keep the whole thing running as the product underneath it changes. That's a harder job than writing the feature yourself. You're not solving one problem, you're designing the conditions under which a whole class of problems gets solved correctly without you.

One person owning an entire area used to be impossible because bug fixing alone would consume them. Keep up with the bugs and no new features ever get built. Now that volume runs in the background, and what remains is the part that never parallelized well anyway: knowing what should be built, and whether what shipped is right.

The second-order effects matter more than the speed. No handoff between the person who understood the requirement and the person who wrote the code. No context lost across a standup. And output per engineer is finally legible, because there's one name on the area.

This is why we're building an owners-only culture. The job isn't writing code anymore. It's owning a machine that writes code, and owning what it ships.

AI is a limitless supply of engineering capacity. Most teams can't use it. Our agentic software factory let us harness that capacity to rebuild our entire product in a quarter.

The bottleneck for most teams older than a year is the development environment AI has to operate in. A few months ago, AI agents couldn't even reliably start our application. The best any engineer could do was work one local task at a time and manually hand sub-tasks to a model. All that capacity, and no way to plug into it.

So we rebuilt from the ground up. The conceit from day one: the entire app would be built by the software factory. That was the forcing function. Every part of the development environment had to work for agents, because agents were doing all the work. No retrofitting agentic development onto the codebase. We expected a tradeoff, going slow now to go fast later. There wasn't one. It was faster from the start.

The result: zero lines of code to live customers in one quarter. Four years of product rebuilt, plus new features, in that same window. Engineers who used to run one local task now oversee 5+ in parallel. Conservatively, a 5x productivity increase, and we haven't found the ceiling.

The AI world is all about speed. Getting it means working backwards from a single question: how do we harness this capacity? Everything about your engineering system follows from the answer. Get it right and you're running on fusion while everyone else is still running on steam.

Originally posted on LinkedIn.

The hard part of enterprise agents isn't knowledge. It's timing. The model doesn't just need to know the customer's policies, it needs to apply the right one at the right step of an orchestrated workflow. Stuffing all 400K tokens of rules into the prompt gave our agent perfect knowledge and terrible timing: hallucinated contacts, skipped steps, a lost thread.

The industry has an answer for this, sort of. Route the model to the context it needs instead of stuffing the prompt. But the public playbook stops at one hop: classify the intent, load the matching instructions, done. Salesforce topics work this way. Skills and progressive disclosure work this way.

One hop can't fix a timing problem. The decisions are chained, and each link needs its own rules.

Past that first hop, we were on our own. No write-up existed for what we needed, so we built it. A routing tree: 72 nodes, each owning a single decision, each carrying only the documents it needs. The agent traverses one decision at a time and never sees more than 5-15K tokens per turn. Token usage dropped 95%. The hallucinations stopped.

Nikola Upīte and Anna Bicevska developed node-based routing to handle keeping agents on track for navigating the most complicated enterprise policies in chat.

Full writeup: https://lnkd.in/g3258Dpy

Originally posted on LinkedIn.

Given the Claude-deleted-a-production-database story going around, now seems like a good time to advocate for AI managing your infrastructure.

Last week I granted AdministratorAccess to Claude Code for an isolated AWS account. Asked it to set up Grafana. 17 minutes. Then the full LGTM observability stack including supporting infrastructure (ECS, RDS, volumes, networking, etc) and a working hello world app to prove that the stack was working. 22 minutes.

I’d been meaning to properly explore Grafana for years. Infra setup was always one of the hurdles that made it feel like a big undertaking. That blocker is gone now.

No, don’t give Claude access to your production environment. But it is time to identify what environments we can hand off to AI.

A lot of what slows down software innovation is skill cleavages — the handoffs between frontend and backend, between application engineers and DevOps. Every boundary between specializations is a place where one person’s idea has to become someone else’s ticket.

Those boundaries are collapsing. I no longer need to go through a DevOps team to spin up infrastructure. The side app we built to track our token spend just runs. Claude manages the infra. If it deletes the database, we’re back in five minutes.

This means I can run software that previously I simply wouldn’t have. Not because I couldn’t write it, but because owning the full stack was too much overhead for a side project or an experiment.

So yes, be careful with production. But I’ll be disappointed if AI doesn’t delete at least one of our non-prod environments this year. If it doesn’t, it probably means we’re leaving velocity and innovation on the table.

Originally posted on LinkedIn.

Agentic loops change what belongs in CI. Previously you were trading off delivery speed against codebase hygiene.

Block on linting, coverage, pattern enforcement, you slow the team. Don’t block, the codebase rots.

Fast static analysis and formatting checks still belong at the gate. The shift is with the slow, expensive stuff. Running full coverage analysis, enforcing architectural patterns, refactoring for DRY used to be a real tradeoff. Post-merge meant a context switch back to something a developer had already moved on from. That work was an expensive context switch for a developer and usually got skipped.

That cost doesn’t exist when an agent is doing the work. At Levelpath we’ve already moved coverage tracking and developer experience metrics to background agents running post-merge. We’re now looking at what else moves: pattern enforcement, refactoring, architectural consistency.

The bar for codebase hygiene stops being what’s worth slowing people down and starts being what standard you actually want to hold.

Originally posted on LinkedIn.

For decades, good algorithms were shaped by the silicon running them. Cache lines, branch prediction, pipeline stalls — the hardware’s characteristics shaped the code.

AI algorithms deserve the same mindset.

LLMs have performance characteristics too. Fast and tireless on some things, unreliable on others. Better at generation than verification, or sometimes the reverse. Context has a sweet spot. Token costs and latency stack fast. The algorithms we build on top of models should be shaped by all of this.

When I think about an AI system at Levelpath, it mostly comes down to two decisions: how to decompose a problem, and how to structure the creator/evaluator loop around each piece. Decompose too coarsely, the model drowns. Too finely, orchestration overhead eats the gains. Strong creator, weak evaluator: you ship garbage confidently. Flip it: you burn tokens forever.

To make it more challenging, these characteristics keep moving. Context windows grow. Reasoning gets cheaper. What was a 10-step decomposition last year is one prompt today. We design for current models, knowing that we can pull away constraints as the substrate evolves.

The software engineer’s job is changing, and the shape of the new job is this: designing algorithms for the AI substrate.

Originally posted on LinkedIn.

We track DX metrics via a GitHub Action — code coverage, CI build time, app start time, hot reload time.

We’re mid-replatform, so the app and how it runs are changing constantly. What we want to measure isn’t. Result: the action breaks every other morning. A path moves, a script is renamed, a dependency shifts.

For a week I just fixed it: open the failure, paste it into Claude Code, patch the workflow, merge. I was a courier between the CI log and the model.

So I built a second Action: headless Claude Code, with read access to the failing run’s logs and permission to open a PR against the workflow. When the DX metrics action fails, it reads why, proposes the fix, opens the PR. I review and merge.

Most AI energy right now goes into building new agentic workflows. The quieter move is pointing agents at the workflows you already have — to keep them doing the right thing as everything underneath shifts.

When the what is stable (measure these four DX metrics) and only the how keeps changing, an LLM is enough to hold it together. Self-healing is a declarative way of describing what you want. The model handles the imperative.

Originally posted on LinkedIn.

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.”

I am not a Writer. I am a tech exec, a dad, a software engineer, and a human with ideas I want to share. AI has been a huge unlock for me in doing this. Pre-AI, I struggled to publish anything. While I had plenty of ideas that were baked enough to share, the actual process of translating them from my head into written text was very slow. This struggle is evidenced by this early post on this Substack, where all I managed to do was write about how I wasn’t writing anything.

My process for writing articles is straightforward: I start with a topic I want to discuss. I then build a fairly dense outline, complete with examples and a point-by-point breakdown of what I’m trying to say. I know what I want to say. I use AI to help augment my research along the way. When it’s time to write, I pass the outline to a personal GPT, which has been trained on my past, pre-AI content to capture something of my voice. It then generates the text. There is an iteration process there where we work together to refine it. I also ask other LLMs to challenge the work to pressure test both the ideas and the writing.

Does this diminish the content of this blog? I don’t think so.

My brother texted me the other day, saying, “Some of your blog sounds like it was written by AI.” I responded, “Of course it does, because it is!” I understand his reaction, because I do it too: when I consume something and begin to suspect it was AI-written, my hackles go up, and I immediately become more skeptical of its quality. I believe we need to move past that reaction. This is related to an earlier piece where I built a mental model for how to grapple with the use of AI in media content.

Similar to that article, I think we can build a truth table. One axis is whether the ideas being described are AI-Generated or Human-Generated. For where AI is now, none of the ideas it generates are interesting to read. It truly feels like slop. Now, of course, a lot of human-generated ideas are not that interesting either. But for the sake of our mental model, we’re going to assume a decent hit rate on humans sharing interesting thoughts and wrestling with hard problems.

The second axis is how the idea gets presented. As a software engineer, I think of the presentation as merely a “display layer.” In engineering, we’d consider whether functionality was being exposed via an API, a GUI, a mobile app, a chatbot, etc. These are different display layers. Genuinely useful products can become useless because of a bad interface. However, a fundamentally unuseful product cannot be saved by a nice display layer.

Given the time I am willing to put in, I cannot create a high enough quality display layer for my work. Yes, I could probably spend years learning the craft, but that opportunity cost is too high. AI lowers the barrier, enabling me to produce readable content quickly. The other axis on our truth table, therefore, is whether the “display layer,” or the text itself, is generated. We should be totally okay with the quadrant where the idea is human-generated, but the text is AI-written. That certainly doesn’t diminish the fully human-generated and written content. We can safely ignore all AI-generated ideas (at least for now).

My commitment in writing this blog is that I will never publish AI-generated ideas. I will not say, “Hey Claude, write an article in my voice about unit tests.” I will continue to take a human-generated thesis or outline and ask Claude to turn it into text. We are going to live in the top-right corner of that truth table.

I am not a Writer. My differentiation is not in the craft or style of my prose; the prose is simply a means of providing a display layer for the conversations and theses I want to share. With AI, I can take an idea that I’ve already baked and produce a full article in 15 minutes at a higher level of polish than if I put in hours. For people who are Writers, I understand why relying on AI to write the final text generally would not make sense; the prose itself is part of their differentiator. Naturally, the barrier to entry for people writing using AI like I do makes that field more competitive. I can imagine that is frustrating because it was already a brutal field.

My hope is that as consumers we can learn to identify the AI text generation that is helping share interesting ideas from that which does not, instead of immediately disregarding it. I look forward to continuing this experiment here in sharing ideas and takes that I think are genuinely interesting and challenging.

At some point, a CEO will come to you and say:

“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—Abi Noda’s Engineering Enablement 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.¹

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.²

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 Engineering Enablement 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