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

The conversation around AI tends to collapse into a strangely binary shape.

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.

We used to scale engineering teams based on execution capacity. With AI, we’ll scale them based on cognitive load.

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 vs in-person debates in startups have the energy of a theological schism. Lots of vibes. Very little accounting. Having led engineering at Airbyte through a shift from fully remote to in-person, I think about this less as ideology and more as a set of tradeoffs.

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.