If I’m using agents to write code, investigate issues, and fix weird bugs, it becomes much harder to commit that work to memory. I can read a final diff and understand what it does, but that’s not always the same thing as understanding why the system works the way it does or having the intuition to know when a proposed change is off.

Even if an agent writes the change, I maintain and own the system (at least for now).

The old way I built context

Before I relied much on agents, I built context through the whole process of solving a problem. I’d investigate an issue, read logs, and figure out what was happening. Then I would write a ticket capturing the problem and relevant context so others (and especially future me) would know what was going on and why we were doing this. When I started working on it, I would need to find where the behavior lived in the codebase, understand the existing implementation, and decide how to change it. Finally, I would test and validate the result.

That process was not always fast, but a useful side effect was that by the end, I had a mental model of that part of the system and pretty deep context about tradeoffs and why changes were made. I knew where that behavior lived, what had caused the issue, what alternatives I had considered, and what other pieces of the system could be affected. Even when I forgot the finer details, I still had higher-level intuition about generally how that part of the system worked.

What agents changed

Agents can now move through that process incredibly quickly. But I have noticed a tradeoff. If the entire workflow happens through agents, I can end up mostly looking at the final answer. I know the bug was fixed. I can see the before and after repro. I can see the diff and the passing tests. But I may not have built the context that I used to get by working through each step myself.

That can slowly take away my intuition about the system, the architecture, and the codebase. The question I keep coming back to is “If I am mostly reading the final answer, when am I building the intuition to challenge it?”

I’m responsible for judgment

If agents can also debug the next problem and implement the next change, why do I still need to understand the system? I do not need to retain every implementation detail the way I did in the before agent times, but I do need a strong enough mental model to direct the work, evaluate the result, and make decisions that shape the system over time.

I am happy to delegate time-consuming work. But delegation does not transfer ownership. I’m still responsible for how the system behaves in production, whether a proposed change fits its architecture, and what tradeoffs we make as it evolves.

That understanding is also what allows me to use agents effectively. Agents can produce answers that are plausible, technically valid, and still wrong for the system as a whole. Without enough context of my own, I cannot reliably challenge those answers or recognize when a local fix may create a larger problem. Choosing between several reasonable approaches also becomes harder if I first have to relearn the system or depend on an agent to surface every relevant constraint.

I want to delegate the work without delegating away my judgment. I still want to be able to explain why we made a change and remember that later when investigating issues or making further changes.

So far, I’ve made a few changes to my personal workflows that help me keep building that intuition.

Stay involved in planning

Agents can create a reasonable plan quickly and it’s tempting to accept it and move on. But planning is also where requirements, priorities, scope, and architectural tradeoffs get decided. Those decisions can disappear into an agent’s implementation if I am not paying close enough attention, especially while multitasking agents across different tasks (more on this later).

My general rule of thumb is that if something needs a decision, I want it to reach me and not be an invisible choice made by the agent that I only notice after the code is written.

One tool I find useful is Compound Engineering’s brainstorm skill. I start by giving it the context of what I want, and it follows up with questions that make me clarify the problem before we settle on a plan. That gets me past a hand-wavy feature outline and makes the decisions behind the work more explicit. For details I have not already specified, it makes me weigh tradeoffs I may not have considered yet and clarify the scope. Some of those boundaries might seem obvious to me, but making them explicit helps both me and the next agent working on the code.

Another tool I’ve been trying out is the grill-with-docs skill. It starts by exploring the relevant code and existing domain documentation and then asks high-leverage questions one at a time about the plan or domain concept. It can challenge vague terminology, point out when my assumptions conflict with the codebase, and help surface edge cases I might otherwise overlook.

The value is not that these tools make design decisions for me. They make it harder for me to handwave a decision that needs to be made before implementation begins. Being more deliberate about this part of the design-to-shipping process has helped me retain context.

Review agent work more pedantically

Agent output can easily land in a place where it technically works, the tests pass, and the overall approach seems reasonable. That does not automatically mean it’s written the way it should be. So I treat review as more than a final correctness check; it’s also the point where I make sure the code reflects the decisions, patterns, and level of care I want to maintain.

This means going deep on things that can look minor at first glance, such as where code lives, whether names make the intent obvious, whether an abstraction is at the right level and provides the intended value, and whether comments are adding useful context or just adding more text to read.

I also use review to make sure I understand why each meaningful change exists. The question is not only “does this work” but also “would I have made these same choices” and “is this how I want the codebase to evolve.” Sometimes that means keeping the approach; sometimes it means changing it to something simpler or easier to read.

Cap multitasking

One place where my workflow is wildly different from when I started using agents in my day-to-day is the amount of multitasking I do. Agents make it easy to kick off a lot of work at once, which is especially powerful when doing initial investigations. But investigation is often only the beginning.

My involvement usually increases as a task moves into planning, implementation, review, and validation. Not every task demands the same amount of attention, either. Fixing a small bug with clear expected behavior in a familiar part of the codebase is very different from building a new feature that requires decisions about scope, architecture, and how the system should behave. Some changes need very little handholding, while others need me closely involved.

My agents can do a lot of work, but I still have only one singular brain. I might be able to ask agents to pick up several unrelated problems at once, but I cannot deeply plan and design five large unrelated features and fixes at once. If I try, I end up with shallow context on all of them.

Because of that, my limit isn’t a fixed number of tasks. I try to judge how much involvement each one will need and how that will change as the work progresses. I may have more tasks running while agents are gathering information, then narrow my focus once those tasks begin requiring decisions and careful review. The question is no longer “How much can I kick off at once?” It is “How much can I reasonably stay engaged with at once?” Being disciplined about that helps me benefit from the amount of parallel work agents can do without creating an information firehose that I cannot meaningfully process.

Staying in the loop does not mean being involved in everything

I don’t want to be personally involved in every little thing my agents do. A small wording change or light refactor does not need the same level of thought as building out a new feature or changing how a system behaves. The goal is to spend more time where the work establishes new patterns, changes existing behavior, or interacts with a complex system.

Agents are making it much faster to produce code. For me, that makes it more important to deliberately maintain context as someone who has to keep owning and maintaining the systems behind that code. I am still figuring out the right balance. But I want to make sure agents help me move through the codebase faster, not leave me behind.

Software engineering has changed

I realize this statement is a lot like saying “water is wet.”

We live in a fundamentally different world for developing software today. Are there familiar things? Definitely. Are there things from the past that we can use in this new world? Absolutely. Code is still code after all. As a mentor used to preach to me, it’s bytes in and bytes out.

The bottlenecks we underinvested in are still around, from source control to CI/CD to code review and even deployments. Only now they are killing the newfound velocity we have.

The pain of these bottlenecks is compounding because everyone can now contribute code. Code has expanded outside of an engineering team and into other teams like sales, support, and marketing. Meaning, a 10-minute build is felt by literally everyone in a company, not just a small subset.

This has profound implications, as it calls into question the assumptions and things we have accepted as normal. It raises questions that I think are still unanswered:

• Who owns the code? Or, put another way, who is responsible for the code that gets deployed?

• How do we trust the code?

• How do we review all of this new code being generated?

• How do we connect code from one place to work with code in another place?

• How do we weigh the costs of token spend with the output of quality features?

Ask these five questions of five different people, and you’ll most likely get five different answers.

This is what I mean when I say that software engineering has changed. It’s not just that LLMs and agents can generate an entire feature off a five-sentence prompt. That’s a tool we are using.

It’s that the entire paradigm around software engineering is now drastically different and moving at a velocity that we simply can’t keep up with. Assumptions we have made are crumbling with each passing release.

I believe we must rethink our paradigm and the tools we are using. We are bending our existing tools and human-centric paradigms into this new world. This is the wrong approach.

Collaboration vs infrastructure

Really, this blog post should be titled something like “GitHub, GitLab, Bitbucket, and others are the wrong shape for this new world.” But that’s a mouthful, so when I say GitHub, read it as all of them.

I think of GitHub as a collaboration tool. Google Docs is a place where I can go to collaborate on this blog post with our technical writing team. GitHub is a place I can go to collaborate with other engineers on the code that makes up Depot.

I grew up with GitHub. In fact, I wanted to work at GitHub when I first became a software engineer. My entire muscle memory is built around the paradigm that GitHub pushed me to use.

• Write code in a branch.

• Open a pull request when I’m ready for my changes to be reviewed.

• Wait for CI and checks to pass to validate that everything works.

• Review comments from my colleagues and go back and forth on ideas in the PR.

• Once everything is green and my colleagues have signed off, merge my changes.

There are derivatives of this workflow. There are wildly differing opinions on the effectiveness of this paradigm. But ask any engineer, and they will know it like the back of their hand.

When LLMs first started to come online, it was natural to bolt them onto our existing paradigm. They could write code in a branch, open a pull request, get a code review from a human (or another agent), use the PR to collaborate via comments, run our tests via our existing CI pipelines, and eventually merge the code.

It was logical. The systems existed, and the agents at that time still largely moved at human speed.

Then everything changed. Agents with the latest generation of models got incredibly good. Freakishly good. We went from models where we often had to nudge the Jenga blocks back into place to get good code out, to models that produce consistently correct code given enough context.

What’s the net result of better models? More code, more branches, more parallel work, and more strain on our existing clunky human-powered paradigm.

Our collaboration pattern, and the underlying systems that back it, are now the primary bottleneck. Every engineering team is feeling bottlenecks in GitHub itself, CI, code review, pull requests, security scanning, and even deployments.

There is now an impedance mismatch between our tools and how we want to build. Our existing collaboration paradigm, largely built around GitHub, is now in conflict with how we actually build software today.

We must rethink our paradigm for software delivery. Not through the lens of human-centered collaboration, but through high-throughput infrastructure primitives.

High throughput software delivery

Building a new software delivery paradigm requires taking a step back from the human-centric process that we have used over the last decade. Rethinking software delivery, not as a sequence of human actions, but as a continuous automated process driven by systems.

Once you start imagining that world, the problem of software delivery starts to look less like a collaboration tool and more like infrastructure. Where infrastructure, in this context, means a small number of primitives on which everything else can be built. We can look to how we have adopted cloud-native technologies for inspiration:

• Compute as a primitive gave us VMs

• Storage gave us object stores

• Networking gave us load balancers

We should be thinking about the fundamental infrastructure primitives we need for software delivery:

• Source control: durable, immutable history of how code evolved

• Execution: isolated, performant compute for building, testing, and validating changes

• Artifacts: reproducible outputs that can be moved across systems

• Caching: reuse of deterministic work

• Identity: proving who or what produced code

• Policy: machine-enforceable rules for quality, security, and compliance

These aren’t features of a developer tool. They’re infrastructure primitives. Just as we stopped thinking about provisioning individual servers and started thinking about compute, storage, and networking as composable building blocks, software delivery needs the same shift.

The winners of the next decade won’t build a better pull request. They’ll build the infrastructure that makes software generation, validation, and deployment operate at machine scale.

At the scale of Depot Registry, this is no longer hypothetical. Once you reach a certain request volume, a one-in-a-million interleaving becomes a reality and happens on a schedule you don’t control.

So when we rebuilt the garbage collector for Depot Registry, we model checked it with TLA+. The model checker found a real bug that our tests and reviews had missed. It also forced us to be precise about a design decision that sounds absurd on first read: our registry stores immutable, content-addressed blobs (that by definition never change), and it depends on S3 bucket versioning anyway.

What TLA+ is

TLA+ is a language for describing a system as states and transitions. TLC is a model checker that explores every reachable state and every possible interleaving, then tells you whether your invariants hold in all of them. You don’t write the implementation in TLA+. You write a simplified model of it that’s small enough for the checker to explore in full, but close enough to the real thing that a bug in the model points at a bug in your system.

Here’s a trivial model: two clients withdrawing from a shared wallet, each doing a read-then-write without locking.

---------------- MODULE Wallet ----------------
EXTENDS Integers

VARIABLES balance, read

Init == balance = 10 /\ read = [c \in {"a", "b"} |-> -1]

Check(c) == read[c] = -1
            /\ read' = [read EXCEPT ![c] = balance]
            /\ UNCHANGED balance

Withdraw(c) == read[c] >= 8
               /\ balance' = balance - 8
               /\ read' = [read EXCEPT ![c] = -2]

Next == \E c \in {"a", "b"}: Check(c) \/ Withdraw(c)

NoOverdraft == balance >= 0
================================================

Each definition is a transition: Check(c) reads the balance, Withdraw(c) subtracts 8 if the client sees enough money. /\ means “and,” while \/ means “or.” The primed variable balance' is the value in the next state, and NoOverdraft is the invariant we want to hold everywhere.

TLC breaks it in four steps: client a checks and sees 10, client b checks and sees 10, both withdraw, and the balance is -6. That’s the classic check-then-act race, found mechanically, with a step-by-step trace showing exactly how to reproduce it. No test run was unlucky. The checker simply tried every ordering.

The wallet is a toy example. Here’s the same idea in one of the real invariants from our registry GC model:

ManifestNeedsData ==
    \A p \in PusherIDs: manifestExists[p] => s3Versions /= {}

Read it from left to right:

• ManifestNeedsData is the name, and == means “is defined as.”

• \A means “for all.”

• p \in PusherIDs means p ranges over every pusher in the model.

• manifestExists[p] asks whether pusher p has a committed manifest.

• => means “if the left side is true, the right side must be true.”

• s3Versions /= {} means the set of S3 versions is not empty.

Put together, the invariant is roughly this pseudocode:

for each p in PusherIDs:
    if manifestExists[p]:
        assert s3Versions is not empty

The last clause might look too weak: it says some S3 version exists, not that the right blob exists. That’s intentional. This model has a single blob digest, because the race we care about is whether GC can delete that blob while a manifest still needs it. In a multi-digest model, the invariant would need to be indexed by digest: s3Versions[manifestDigest[p]] /= {}. Reviewing a model means asking whether choices like this preserve the question you wanted to answer.

Model the moving parts (uploads, database transactions, GC workers), state what must always be true, and let the checker do to your design what production traffic eventually will.

Why we can afford TLA+ now

TLA+ has been around for decades, and it has a reputation problem: everyone agrees it’s powerful, but almost nobody budgets the weeks it takes to write and maintain a faithful model next to a moving implementation. That was our position too. Before this year, a spec for our GC would have lost the prioritization fight every single time.

What changed is that we don’t write the model by hand anymore. An agent reads the implementation, the Go transactions and SQL and S3 calls, and translates it into a spec. We review the rest: do the invariants say what we mean, and does the model abstract away the right things? Writing TLA+ was the expensive part. Deciding what must always be true was always the cheap part, and it’s the part that stays human.

The result is a spec of the registry’s three-tier garbage collector that models concurrent pushers, two GC domains, a counter reconciler, and injected counter drift, all interleaved. It’s rooted in the real implementation, transaction by transaction. TLC explores 14,290,224 distinct states in about 21 minutes and proves 10 safety invariants and 2 liveness properties. The most important invariant is the first one: a committed manifest never loses its blob data.

We now use AI to ship faster like everyone else. But we’re also using it to build systems that are more correct than what we had the time to verify before.

The race: why our immutable blobs use S3 versioning

OCI registries are content-addressable. Within Depot Registry, blobs live at blobs/sha256/<digest>, and the digest is the hash of the content. Upload the same blob twice and you get byte-identical data at the same key. Nothing ever changes in place. Under that model, S3 bucket versioning looks pointless: every version of an object would be identical.

But the problem is the deletes.

Garbage collection has to remove blobs that nothing references anymore. The GC worker marks a blob with zero references, waits out a grace period, re-verifies, and deletes. But the references live in MySQL and the bytes live in S3, and there is no transaction that spans both systems. Which opens a gap:

1. GC verifies the blob has zero references and decides to delete it.

2. Concurrently, a client pushes an image containing that exact blob. Same digest, same key. The upload writes to S3 and commits a new reference.

3. GC’s delete lands and removes the object that a just-committed manifest now points to.

Every individual step is correct. Yet the interleaving deletes live data. And “a client re-pushes a blob right as it becomes garbage” is not exotic: it’s what happens when a popular base image cycles out of use and back in.

You could try to fix this with locks or with ever-more-careful re-checking, but you can’t re-check S3 and delete in one atomic step. So instead we made the delete itself precise. The bucket has versioning enabled: a re-upload of the same key becomes a new version instead of overwriting. When GC marks a blob, it records the specific S3 version ID it saw. When it deletes, it deletes only that version:

1. GC marks the blob and captures version v1.

2. The concurrent push writes the same bytes as version v2 and commits its reference.

3. GC deletes v1, and only v1. v2, the version the new manifest was built on, is untouched.

We don’t use versioning to keep history. Every version of a blob is byte-for-byte identical, so there’s no history to keep. We use it as a delete fence: it turns “delete this key” into “delete exactly the bytes I inspected,” which makes a delete safe to race against a write. That’s the answer to the puzzle in the title of this section, and it’s a good pattern for any content-addressable store that garbage collects: versioning, not immutable content, makes deletion safe.

Turning a doubt into a line of TLA+

One concern in the registry design was how its reference counters behave under failure. To reduce contention on hot blobs, we use a lightweight saga: increment a reference counter, do the work, and compensate with a decrement on failure. A reconciler repairs counters when a crash prevents that compensation from completing. The important detail is that a wrong counter is not symmetric. Overcounting delays GC, while undercounting can make GC treat a referenced blob as garbage and delete live data.

That asymmetry was our doubt, so we told the agent to verify exactly that. It came back with an invariant:

ManifestCountNeverUndercounts ==
    blobActive => blobManifestCount >= TrueGlobalManifestCount

Whenever the blob’s row is active, the stored counter must be at least the true count derived from the physical link rows. The >=, rather than =, captures the asymmetry directly: overcounts are tolerated, undercounts are a violation.

For that invariant to tell us anything useful, the model also has to include incorrect counters. We added a dedicated drift process that changes them in the same directions as failed compensations and historical desynchronization:

process DriftInjector = "drift"
begin
    Drift:
        await driftBudget > 0;
        either
            await blobActive /\ blobLinkCount > 0;
            blobLinkCount := blobLinkCount - 1;   \* undercount
        or
            await blobActive /\ blobLinkCount < N + DRIFT;
            blobLinkCount := blobLinkCount + 1;   \* overcount
        end either;
        driftBudget := driftBudget - 1;
        goto Drift;
end process;

This part of the spec is written in PlusCal, a front-end syntax that compiles down to TLA+, which is why it reads like pseudocode. await blocks the step until its condition holds, and either/or is nondeterministic choice: TLC explores both branches wherever this process could run, interleaved with the pushers, GC workers, and reconciler. Rather than representing one specific bug, the process represents the broader condition that a counter may be wrong in either direction when another operation runs. The checker can then verify that destructive steps recount the physical rows instead of relying on a stale counter.

The model also has invariants for its own internal bookkeeping:

S3HeadOK ==
    /\ (s3Versions = {}) <=> (s3Current = 0)
    /\ (s3Versions /= {}) =>
        /\ s3Current \in s3Versions
        /\ s3Current = MaxVersion(s3Versions)

S3HeadOK says the “current version” pointer is empty exactly when the version set is empty, and otherwise points at the newest version. It does not express a product guarantee; it checks that the model’s S3 abstraction remains internally consistent. These checks help distinguish a failure in the system being modeled from a mistake in the model itself.

Tests and model checking cover different ground. Tests exercise concrete implementations, while the model explores interleavings that would be difficult to reproduce deliberately.

Tips and tricks on getting started yourself

Formal verification used to be a luxury reserved for teams with time to burn. That constraint is gone. The tedious part, faithfully translating an implementation into a spec, is now something you can delegate to an agent, while you make the judgment calls. Here’s what we wish we knew six months ago.

Pick your battles: Don’t throw TLA+ at everything. Good candidates are competing processes, tricky transactional boundaries, autonomous workers racing on timing, or work spanning multiple systems with no shared transactions. For example, a CRUD endpoint doesn’t need a model checker.

Have a bias for action: While you’re still learning TLA+, the goal is not a correctness proof. That comes later, if ever. When people hear “TLA+,” the first objection is always “but what if the model doesn’t match reality?” That’s not the point: testing and formal verification both exist to increase trust, and a model checker is one more trust dial. So don’t wait until you understand every line of a generated spec. Run it and see what falls out. Worst case you lose an afternoon; best case you’ve found a thread to pull. If the cost of a mistake is high, that’s when you invest real time hunting for flaws in the spec itself.

Steal this workflow: Use cheaper models to generate sequence diagrams of the interleaving procedures, either at design time or from an existing implementation. Review them, simplify, and abstract away steps that don’t matter. I like Codex for this exploration: it renders the diagrams nicely, and side-chats make it easy to pull on a topic without derailing the main thread. Once the diagrams say what you mean, hand them to a frontier model (Fable at extra high effort, in our case) to generate the TLA+ spec. That first spec will be a black box: you can’t read TLA+ yet, so all you can judge is what goes in and what comes out. That’s fine. Start there.

Refine the workflow: Now make the black box transparent, one piece at a time. The entry point is the invariants, because they’re the readable part: short statements about what must always be true. There are usually 1–3 obvious ones. Use agents to propose more; then cut ruthlessly. After a few iterations the rest of the spec stops being opaque too: you start recognizing the transitions, then questioning them. Is this really how our retry behaves? Does the model even allow two workers here? Now you’re reading the spec whitebox, finding problems in the model itself instead of just trusting its output.

Turn doubts into invariants: Describe what you’re not confident about, since that’s exactly the confidence a checker can buy you. For us it was an asymmetry in our GC counters — overcounting is always safe, undercounting never is — and the previous section explained what the agent did with that doubt. Your doubts are the spec’s best requirements.

Treat findings as leads, not verdicts: The model might not match reality, so a violated invariant is a starting point, a thread to keep pulling. Take the counterexample trace, turn it into a sequence diagram, and zoom in until you either fully understand the race and fix it, or find the mismatch between model and implementation. Either outcome is progress: you’ve gone from unknown unknown to something you can point at.

You now have another tool in your toolbox: tests check the interleavings you thought of; TLA+ explores the ones you didn’t.

Engineers are funny about this kind of stuff. In technical work, we tend to care deeply about what things do and why they work. But the second process comes up, everyone suddenly gets very comfortable saying, “Well, this is what we did at my last company.”

Or worse: “This is just how we do things.”

These are terrible answers.

It makes sense why this happens. Computer systems are easy in one specific way: they are mostly deterministic and mostly under our direct control. Human systems are much messier. There is no USB-C port I can plug into a coworker’s brain and upload stop-being-a-dick.exe.

Tragic, honestly.

People systems are stochastic (at best, we have influence, not control). A lot of engineers write them off as the mushy, manager-brained stuff that gets in the way of the “real” work. The irony is that ignoring the people system is a great way to make sure the real work doesn’t get done. Or worse, that the wrong work gets done extremely efficiently.

Process isn’t inherently shitty. Teams need it to move context, make decisions, and notice friction. But process becomes theater when we confuse the format with the principle.

The standup test

The format of a process is the visible part: a daily meeting, a retro, a Slack post every Friday. The principle is the reason the thing exists in the first place.

Take standup. The classic format is: *what did I do yesterday, what am I doing today, any blockers.* If the process stops there people eventually mentally check out.

“Yesterday I worked on making the logs page faster.”

Cool. What does that mean? Is it going well? How is it impacting what others are working on? Is it about to burst into flames?

The shape of standup survived, but the reason for it did not. I’ve seen the exact same format produce completely different outcomes depending on the principle underneath it. If a manager’s principle is control, a standup turns into a daily surveillance ritual to prove everyone is earning their paycheck. The room feels like a tribunal.

If the principle is connection, it becomes the one moment in a distributed day where everyone is actually together. We pick up on the weird little human signals that don’t survive the trip into Slack. We notice when someone is circling the same problem for the third day in a row.

Same format. Different principles. Completely different outcomes.

Scaling process and culture

When the principle is useful and understood, the format can change without losing utility. When the principle is missing, all that’s left is a ritual. And rituals are sticky.

We hit this wall recently with project updates. Our leadership was staying informed through Linear project updates. When there were three projects, that was fine. When it grew to fifteen, it broke. The updates were scattered across different days, with completely different altitudes of context.

A template could only fix so much. The deeper issue was the principle: visibility at the right altitude.

Project-level updates were too granular for leadership and too scattered for the ICs to see how the work fit together. So, we killed the ritual and changed the process. We introduced initiatives: a collection of related projects tied to a larger business objective, managed by one owner in one channel.

Upward communication got better because leadership had one place to look at the right altitude. Lateral communication got better because ICs finally had a forcing function to see how their work connected to the broader system.

The old process wasn’t stupid. It worked until it didn’t.

Keep the why alive

I don’t want process for the sake of process. I want exactly enough of it to make the team work. Not so much that everyone spends their lives feeding status machines, and not so little that context disappears into DMs and engineers become isolated code islands.

That balance changes as a company scales.

If I don’t know why a process exists, I don’t know what to keep, what to change, or what to kill. I am just copying shapes. Process doesn’t suck. Process without principles really does.

Embracing AI and steering it to produce maintainable code at an acceptable cost is the name of the game. There are countless smart people out there working on different harnesses and techniques to crack the problem. The current craze is loops, but aside from being too expensive, the approach just doesn’t click with me.

There’s a difference in effective AI use between working alone and being part of a team on the same project. In the latter case, I have obligations to my employer and my team. Some employment contracts even contain a clause like this: “the Employee shall perform their duties to the best of their ability and skill.” I tend to take that line rather seriously. Ridiculous as it may sound, this is my creed. I take great pride in my work, and I plan to keep it that way. I invest heavily in keeping my code maintainable and reviewable, to make life easy for my peers and my future self. Let me show you the AI assisted development workflow I’m currently happy with.

What works for me

The approach that works today is constraint. Selectively adding guardrails to get more consistent, predictable output. I work with Go the most in my day-to-day, so my examples will use it, but I think these techniques apply to almost any other language. That said, Go has the advantage that different developers tend to produce fairly similar code, thanks to the language’s rigid structure.

Linter

I find that linting is the alpha and omega of steering agents to produce acceptable code. As expected, I’m using the standard golangci-lint as my linter. These are the rules I mostly rely on to influence the shape the code takes:

  settings:
    cyclop:
      max-complexity: 10
    funlen:
      lines: 90
      statements: 50
    revive:
      rules:
        - name: argument-limit
          arguments:
            - 8
        - name: file-length-limit
          severity: error
          arguments:
            - max: 1000
              skipComments: true
              skipBlankLines: true

Your peers will thank you later for the effort you put into constraining the code’s dimensions. Limiting the lines of code in a single file and capping cyclomatic complexity forces the agent to break code down into smaller logical units across multiple files. Function length and the number of allowed function arguments complement these rules, making the code far more readable to humans.

Testing

Agents are useful for generating (unit) tests to save you from the grunt work. Proper test coverage has always been important, but it matters more than ever in the era of full project rewrites. Take the agent by the hand and don’t let go until it can produce sane test cases.

I usually start by writing a few very good test cases manually. I almost always write table-driven tests, so that’s a good starting point. Agents can easily generate mocks, but I usually give them a framework to do so. Invest early in coming up with sane interfaces, and force the agent to use those to generate mock structs with deterministic code generators such as moq. Agents like to solve problems in creative ways. Without guardrails, they usually produce working but hard-to-read assertions. GPT 5.4+ likes to write tests that basically “grep” a line of business logic, checking character by character for the existence of a function and calling it a unit test. Weird.

I usually instruct the agent to use the testify package to keep test cases standardized and easy to read. Once the preparations are done, you can just ask the agent to look at your reference test implementation and write future tests based on it.

Take a look at this simple go project:

package main

import "errors"

type calculator struct{}

func (c calculator) add(a int, b int) (int, error) {
	if a == 0 || b == 0 {
		return 0, errors.New("values cannot be 0")
	}
	return a + b, nil
}

func (c calculator) subtract(a int, b int) (int, error) {
	return a - b, nil
}

func addWrapper(a int, b int, c calculator) (int, error) {
	return c.add(a, b)
}

func subtractWrapper(a int, b int, c calculator) (int, error) {
	return c.subtract(a, b)
}

func main() {
	addWrapper(10, 10, calculator{})
}

I prompted Claude 4.8 (1M context) High-thinking with the following text:

Please take a look at blogpost/main.go. I would like you to write unit tests for addWrapper function. The test should have at least 3 different inputs. Write idiomatic go.

The agent actually produced table-driver tests without being asked, and the tests themselves are fine, but we could make them more readable. I’m not happy with how the table-driven tests look, and those assertions could be much easier on the eyes. I’m also not happy with the direct use of calculator, which could change at any time, for example by introducing dependencies.

See the agent’s first attempt

  package main

  import (
  	"testing"
  )

  func TestAddWrapper(t *testing.T) {
  	tests := []struct {
  		name    string
  		a       int
  		b       int
  		want    int
  		wantErr bool
  	}{
  		{
  			name: "two positive values",
  			a:    10,
  			b:    10,
  			want: 20,
  		},
  		{
  			name: "positive and negative values",
  			a:    5,
  			b:    -3,
  			want: 2,
  		},
  		{
  			name:    "zero operand returns error",
  			a:       0,
  			b:       7,
  			wantErr: true,
  		},
  	}

  	for _, tt := range tests {
  		t.Run(tt.name, func(t *testing.T) {
  			got, err := addWrapper(tt.a, tt.b, calculator{})

  			if tt.wantErr && err == nil {
  				t.Fatalf("addWrapper(%d, %d) error = %v, want %v", tt.a, tt.b, err, tt.wantErr)
  			}
  			if got != tt.want {
  				t.Errorf("addWrapper(%d, %d) = %d, want %d", tt.a, tt.b, got, tt.want)
  			}
  		})
  	}
  }

Lets make some changes to the main file, and create a reference unit test implementation:

package main

import "errors"

var errZeroValues = errors.New("values cannot be 0")

//go:generate moq -stub -out calculator_mocks.go . Calculator
type Calculator interface {
	add(a int, b int) (int, error)
	subtract(a int, b int) (int, error)
}

type calculator struct{}

func (c calculator) add(a int, b int) (int, error) {
	if a == 0 || b == 0 {
		return 0, errZeroValues
	}
	return a + b, nil
}

func (c calculator) subtract(a int, b int) (int, error) {
	return a - b, nil
}

func addWrapper(a int, b int, c Calculator) (int, error) {
	return c.add(a, b)
}

func subtractWrapper(a int, b int, c Calculator) (int, error) {
	return c.subtract(a, b)
}

I introduced a sentinel error called errZeroValues. I also added a Calculator interface, along with a generator that writes a mock to calculator_mocks.go. Now let’s write our reference test implementation:

package main

import (
	"testing"

	"github.com/stretchr/testify/require"
)

var mockCalculator = &CalculatorMock{
	subtractFunc: func(a, b int) (int, error) {
		return a - b, nil
	},
}

func TestSubtractWrapper(t *testing.T) {
	tcs := map[string]struct {
		a       int
		b       int
		want    int
		wantErr error
	}{
		"positive and positive values": {
			a:    10,
			b:    10,
			want: 0,
		},
		"positive and negative values": {
			a:    10,
			b:    -10,
			want: 20,
		},
		"negative and negative values": {
			a:    -10,
			b:    -10,
			want: 0,
		},
		"zero operands": {
			a:    0,
			b:    0,
			want: 0,
		},
	}

	for name, tc := range tcs {
		t.Run(name, func(t *testing.T) {
			got, err := subtractWrapper(tc.a, tc.b, mockCalculator)
			require.NoError(t, err)
			require.Equal(t, tc.want, got)
		})
	}
}

Lets see what the next prompt produces:

Please re-read blogpost/main.go, and the reference test implementation in blogpost/main_test.go. I would like you to follow the practices seen in the TestSubtractWrapper reference unit test, and write TestAddtWrapper.

The agent extended the mock and used require, just as asked. (Please ignore the fact that the mock and the real implementation are the same; this is just a small example.) This shows that agents are capable of producing sane unit tests, given some investment in crafting good examples.

See the agent’s revised attempt

  package main

  import (
  	"testing"

  	"github.com/stretchr/testify/require"
  )

  var mockCalculator = &CalculatorMock{
  	addFunc: func(a, b int) (int, error) {
  		if a == 0 || b == 0 {
  			return 0, errZeroValues
  		}
  		return a + b, nil
  	},
  	subtractFunc: func(a, b int) (int, error) {
  		return a - b, nil
  	},
  }

  func TestSubtractWrapper(t *testing.T) {
  	tcs := map[string]struct {
  		a       int
  		b       int
  		want    int
  		wantErr error
  	}{
  		"positive and positive values": {
  			a:    10,
  			b:    10,
  			want: 0,
  		},
  		"positive and negative values": {
  			a:    10,
  			b:    -10,
  			want: 20,
  		},
  		"negative and negative values": {
  			a:    -10,
  			b:    -10,
  			want: 0,
  		},
  		"zero operands": {
  			a:    0,
  			b:    0,
  			want: 0,
  		},
  	}

  	for name, tc := range tcs {
  		t.Run(name, func(t *testing.T) {
  			got, err := subtractWrapper(tc.a, tc.b, mockCalculator)
  			require.NoError(t, err)
  			require.Equal(t, tc.want, got)
  		})
  	}
  }

  func TestAddWrapper(t *testing.T) {
  	tcs := map[string]struct {
  		a       int
  		b       int
  		want    int
  		wantErr error
  	}{
  		"positive and positive values": {
  			a:    10,
  			b:    10,
  			want: 20,
  		},
  		"positive and negative values": {
  			a:    10,
  			b:    -10,
  			want: 0,
  		},
  		"negative and negative values": {
  			a:    -10,
  			b:    -10,
  			want: -20,
  		},
  		"zero operands": {
  			a:       0,
  			b:       0,
  			want:    0,
  			wantErr: errZeroValues,
  		},
  	}

  	for name, tc := range tcs {
  		t.Run(name, func(t *testing.T) {
  			got, err := addWrapper(tc.a, tc.b, mockCalculator)
  			if tc.wantErr != nil {
  				require.ErrorIs(t, err, tc.wantErr)
  				return
  			}
  			require.NoError(t, err)
  			require.Equal(t, tc.want, got)
  		})
  	}
  }

Agents.md and Claude.md

I often think my Markdown files might look naive to agentic power users, but I like to keep things simple, and it seems to work for me. This is the basic structure I usually start with:

# AGENTS

<Short description what the project is about>

# Main components
<A list of the main components and their path within the project with a very short description>

# Most important go packages
<A list of important go packages and what they should be used for>

# Development

`make build` cross compiles to linux
`make generate` generates the gRPC files
`make test` executes the unit-tests
`make lint` executes the linter check (needs docker)
`make lint-proto` lints the proto files

## Coding style
- The code should be idiomatic go
- You should listen to the linter all the time
- Code should be self-explanatory. prefer code readability over comments
- Comments should be short, to the point
- Comments shouldn't include ticket numbers
- Comments shouldn't include made up worlds and phrases not in the english dictionary
- New files shouldn't extend over 1000 lines of code (excluding comments and whitespaces)
- Think twice before adding code to files where the number of lines in a file already surpass 700
- Unit tests are nice, but don't write tests just for the sake of writing tests
- When adding new unit-tests, keep the style from the existing tests
- PRs should be small, encapsulating a single feature or fix.
- If you need to stuff multiple features or related changes into a PR, oranize them into separate commits

# Deployment
<How to deploy to STAGING>. # deploying to production should follow process

That’s all. It overlaps somewhat with what we covered earlier on linter rules and unit tests, but I find that the more we surround the agent with walls, the more deterministic and higher-quality its output becomes.

The remarks about comments are probably the interesting part. I’ve found that Opus 4.7+ and GPT 5.4+ models produce complete garbage in their comments when not regulated. Let’s take a look at the following comment:

exitCode, exitErr := command.GetExitState()
if exitErr != nil {
	// Synthetic "exit status N" goes on the legacy line rail only; it
	// would corrupt callers that concatenate StderrRaw to reconstruct
	// the process stderr (DEP-5505).
	if err := stream.Send(&somepackage.ExecuteResponse{
		ExitCode: exitCode,
		Stderr:   exitErr.Error(),
	}); err != nil {
		return fmt.Errorf("send exit error to stream: %w", err)
	}
}

1. It includes a ticket number for no good reason.

2. It contains a made-up expression like legacy line rail.

3. It refers to code it just changed as “legacy.”

4. It takes real mental effort just to understand what the comment is even about. What does “synthetic” even mean in the context of exit codes?

Furthermore, I’ve observed that after slightly changing a function, GPT 5.4+ likes to write something like: “Previously myfunction was working like this … (and then it details how the function worked before the change), but since TICKET-NUMBER, the function now does this … .” I’m not sure why the models write comments like this, but I’m pretty sure this is what Git is for. To add to that, in Rust code GPT 5.4+ will happily write comments 50 to 100 lines long. It would be insane to burden my peers and my future self with that much noise, so I like to guide the agent on how to write sane comments, and I think you probably should too. As a bonus, you might want to set up Cursor Bugbot or another reviewer agent to check comments against a rubric on open PRs.

Processes

So far, we’ve worked to produce sane agentic code that resembles something the team would expect from other engineers. To pass the ceremony of validating and merging code into the codebase, we need to take a few extra steps.

PR descriptions

When I’m not working across a lot of parallel lanes, I still like to write PR descriptions. I aim to keep them short and to the point, and I occasionally include screenshots of the product changes, which help peers understand them. When I have the agent write them, I hold it to the same rules I described earlier for comments.

Making PRs reviewable

As a rule of thumb, I try to keep changes small, say under 200 changed lines overall. Of course, sometimes that isn’t possible: there are large refactors and new features. When the changeset is sufficiently large, I try to decompose the changes into separately reviewable commits. You can split the changes into commits by logical boundaries, modules, packages, and so on. Whatever works best for your team. Agents are insanely good at this; you can just tell them to break your change into small commits right before opening a PR. Another promising approach is GitHub stacked PRs. The feature is in preview, but it makes reviewing code so much easier.

The missing cherries on top

I’m quite happy with my current workflow, since these simple tricks can greatly improve the quality of the code produced, but there’s always room for improvement. There are a few things on my wishlist that would make life easier:

Organization level Agents.md

It would be so nice if GitHub (and other forges) supported defining organization-level AGENTS.md directives that would merge with repo-level Markdown files. This way, I could define global defaults (comment styling), and the repo-specific directives (deploy, build, etc.) would stay in the repositories.

Closing the feedback loop

Since Opus 4.7 and GPT 5.4, agents have started using some REALLY weird tools. For example, I often see them run Perl scripts. Other times, instead of editing a file, they make a copy, then move the new file in to replace the original. Sometimes they offer to run a shell script so exotic that I’d rather ask them to do something else. An obvious solution is to run the agents in (I’m not super happy with the local isolation levels agents provide). Running them in a remote sandbox solves the isolation problem, but takes away the instant feedback I get locally. I’d like to run my integration suite after each remote modification to my codebase, so it mirrors my local workflow. It’s absolutely doable, but involved, and as far as I know no provider supports it natively.

Haven’t you heard that coding is solved?

You might be thinking, “But Peter, so many words wasted on code quality, when coding is already solved. Nobody needs to read code anymore!”

I respectfully beg to differ. LLMs make a lot of mistakes even today, and the quality of the code they produce is far from deterministic or uniform. Furthermore, I’m responsible for the work I release, or that goes out under my supervision. After all, I’m the one on call, not Claude. There are many cases where I don’t care about code quality at all, such as quick experiments, small scripts, visualizations, and so on. But until the day LLMs stop making mistakes (that day might come soon), and you can’t tell human code from agent code, expect me to show up and read all the code. To the best of my ability and skill, as the contract says.

There’s a certain attitude people have toward the extremes of hardening. Disable Hyper-Threading? Sure, if performance doesn’t matter! Lock kernel module loading after boot? Cool, until it breaks. I’ve had that attitude myself, and for the longest time, it was the right one.

The kernel had earned a lot of trust. Bugs got reported, embargoes held (mostly...), and the really nasty bugs usually got patched before exploitation in the wild. So I never even really thought about obscure kernel features - if it has a CVE against it right now, it’s usually already fixed. Many hardening steps felt like a mix between an insurance policy that won’t ever pay out and security theater with performative hardening as the main star.

Then, this spring, something genuinely changed. AI increased productivity for all - even attackers, who could look for vulnerabilities faster and in more places than ever before. And once such a bombardment of vulnerabilities starts, you stop asking “is this feature vulnerable today” and start asking “isn’t it reckless to let the kernel auto-load whatever”. Unused kernel surface is no longer just debt.

The wave

Five Linux local privilege escalation (LPE) vulnerabilities got disclosed and immediately abused in a couple of weeks. Copy Fail started the party. It was the result of an hour-long AI scan of the kernel’s crypto/ subsystem. The published exploit for it was a short Python script that worked on almost everybody’s favorite Linux distributions. The vulnerability had been sitting in algif_aead, introduced by an optimization that everybody had in their kernel, and nobody really needed.

Here’s the run:

CVE references from the table above:

• Apr 29 — Copy Fail: CVE-2026-31431 — page-cache write → root (AF_ALG + splice(), algif_aead module)

• May 7 — Dirty Frag: CVE-2026-43284 + CVE-2026-43500 — page-cache write → root (IPsec ESP, esp4/esp6, rxrpc modules)

• May 13 — Fragnesia: CVE-2026-46300 — page-cache write → root (XFRM ESP-in-TCP coalescing, esp4/esp6, rxrpc modules)

• May 20 — ssh-keysign-pwn: CVE-2026-46333 — FD theft → secrets/root (ptrace exit race + pidfd_getfd)

• May 21 — PinTheft: CVE-2026-43494 — page-cache write → root (io_uring + RDS zerocopy double-free, rds_tcp, rds modules)

Four of the five are almost the same bug: some optimized crypto or zerocopy path writes into a buffer the kernel doesn’t actually own, and you end up with a controlled write into the page cache of a Set User ID (SUID) binary you’re allowed to read. They don’t actually use the network, and none of them are extremely privileged. (I’m not a kernel hacker, so I rely on the write-ups, reading the patches and a bit of guesswork, but the pattern is real.)

These kinds of things have happened before. We had embargoes violated or not-quite-responsible disclosures regarding vulnerabilities. We always had some people looking at recent Linux patches, trying to reverse engineer vulnerabilities from patches - we also had hasty fixes introducing new bugs. But we never had this scale or speed.

Patches are still a must - but that’s reactive. The patching is now a race against something that can read 100x more code than you, even the boring bits. But we can give them less attack surface and a harder time.

Paranoia keeps becoming the default

Just to preface this: nothing listed here is really new. These hardenings started their lifetime as paranoid measures, then moved into normalcy, best practice or even defaults.

For example, OpenBSD has always been quick and an early adopter of these ideas and has often been called paranoid due to its choices. When OpenBSD devs separated the privileges in OpenSSH, to separate the unprivileged process talking on the network (risky), it felt like over-engineering, but today it’s common. Their W^X (memory is writeable or executable, not both) and a stack-smashing protector (ProPolice) were adopted in OpenBSD system-wide in 2003, but it took Linuxes one more year for NX and multiple years to turn stack protector on (Ubuntu and RHEL ~2006, Debian ~2013).

I have to also tip my hat to PaX and grsecurity. They have maintained a huge set of out-of-tree patches to harden the Linux kernel, with innovative and early adoption of hardening ideas. Just listing what they had patches for early on would often sound like an advertisement for their paid products.

Sadly, these paranoid hardenings often came with a cost (performance, ease of use, etc.) up front, but very abstract protection against a bug (or bug class) that might not exist yet, so they were usually adopted after the fact.

Sorting hardening by cost

Hardening is often a balancing game, and it’s not just one thing or one idea. Each choice can have wildly different trade-offs, and they all depend on what you are trying to achieve. Some of them are trivial choices, some of them may make a service 30% more expensive to run. To make choices easier, I feel it’s easier to think about categories:

• A - Free. Simple housekeeping, won’t harm anything.

• B - Nearly free. Turning off genuinely useful things, but not things we use.

• C - Costs you visibility. Makes operations harder (debug, monitor), but closes doors.

• D - Costs you some performance. Can have a negative effect on performance, but very tiny. Might hurt on high node count.

• E - Costs you real money. You lose throughput, you have to run more nodes or more expensive hardware. Danger zone.

This is neither a definitive guide for hardening, nor a todo list! The scope here is mostly about the Linux kernel, but these ideas can be applied to other pieces of software and infrastructure. If you don’t “check all the boxes” and apply all hardening, you are not necessarily reckless. If you are conscious about your trade-offs, then you will be able to decide what is worth it and what is not. Also, do note that in this list, only the cost of running servers and services is considered - things like spending engineering hours for security, maintaining customizations, and making decisions, are not part of it.

It’s important to note that I’m writing about generic advice and I’m not defining a concrete threat model here - you will need to consider your own requirements and threat model to weigh any advice in this post. I also want to highlight that the goal of the hardening measures and ideas I’m talking about is to minimize the chance an attack is successful or useful for information extraction, denial of service or similar malicious goals. Exploitation often involves multiple vulnerabilities, where attackers might have to orient themselves and might have to pivot from lesser to privileged access.

A - Free: the housekeeping

The Linux kernel’s support for protocols, hardware and others is extensive, but this also means a bigger attack surface. While maintaining your own custom kernel build per use-case might be good, the kernel distributed with common distributions can also be locked down. For example, you may blocklist rarely used kernel modules, which Ubuntu already does for you. This meant that PinTheft (CVE-2026-43494) didn’t affect stock Ubuntu installations. The good thing about this is that you may also blocklist and unload kernel modules on running machines, like the workarounds for these vulnerabilities, which reduces the chance of being affected by faulty hotfixes, such as Fragnesia (CVE-2026-46300).

Some hardening can also just make attackers’ lives harder, like reducing information leaks on the system. For example, don’t let any user read dmesg (sysctl: kernel.dmesg_restrict=1), which can contain sensitive information that regular users really shouldn’t read. Another example is to not let setuid / setgid programs coredump (sysctl: fs.suid_dumpable=0), which will hold sensitive information in case of, say, sudo. Two more concrete hardenings catching real bugs are making NULL pointer dereference exploitation much harder by making low memory unmappable (sysctl: vm.mmap_min_addr=65536), and enforcing stricter symlink/hardlink checks (sysctl: fs.protected_symlinks=1, fs.protected_hardlinks=1), so TOCTOU (time of check, time of use) symlink attacks are much harder.

Another one to consider is to reduce setuid binaries to a minimum, and make them unreadable by anybody outside of root - which could block attacks relying on poisoning the page cache of these setuid files. Be careful with persistence here, though.

These are pretty easy to implement, free in terms of performance, not too intrusive and won’t reduce observability for operators. Many of these hardenings became baseline for some popular Linux distributions.

B - Nearly free: purge unused modules

The basic hygiene step could be to enforce signature checking on kernel modules (set /sys/module/module/parameters/sig_enforce to 1), to block loading unsigned modules. While lockdown=integrity (/sys/kernel/security/lockdown set to integrity) also allows this, that value also blocks other functionality, such as kexec and some debugging opportunities - more on that later. This might be enabled based on your distribution (Ubuntu enabled it by default in 20.04 LTS) and your UEFI secure boot setting.

A standard Debian or Ubuntu image for example ships multiple thousands of kernel modules. What used to be paranoid but I think is a good practice now is to prune your kernel modules and block kernel module loading after boot (via /proc/sys/kernel/modules_disabled), which also prevents an attacker from loading or unloading any kernel modules. (While kernel module signing exists, vulnerable kernel modules are also signed.) Doing this on fixed-purpose nodes can be pretty easy (like hypervisors, simple nginx web servers), but it can be really painful for generic hosts (like kubernetes nodes) or generic images.

C - Costs visibility: ptrace, eBPF

I think hardening measures impacting observability are pretty divisive: observability helps you, but it can also help attackers. I remember calling someone paranoid for disabling eBPF altogether, but I do now agree that limiting it at least is a minimum (sysctl: kernel.unprivileged_bpf_disabled=1 - 1 is disabled until reboot, 2 is disabled, but reversible), so only root can load BPF programs.

There is also Yama, which can help harden certain parts of the kernel. For example, you can enforce that only CAP_SYS_PTRACE privileged processes can do ptrace (sysctl: kernel.yama.ptrace_scope=2), but it’s also sensible to turn this off completely (sysctl: kernel.yama.ptrace_scope=3) until a reboot. The ssh-keysign-pwn (CVE-2026-46333) vulnerability could’ve been prevented with this. However, completely disabling ptrace means no gdb -p or strace -p - so don’t do this on your dev machine, but it’s fine on a server.

You can also reduce visibility into the kernel by hiding kernel pointers from userspace (sysctl: kernel.kptr_restrict=2), which helps prevent information leaks.

D - Costs performance: pinning, libc

In this category, there are a couple of hardening options, which will likely reduce performance, but can be worth it. One example is if you run workloads for multiple tenants, and want to provide better isolation on your hypervisor node. In this case, it will be necessary to do CPU core pinning at least, so no two tenants are on the same CPU core at the same time, so fewer resources are shared - more on this in the last point. Depending on your business, you might even have to separate tenants between NUMA nodes, and might have to consult your CPU documentation.

One thing that is pretty divisive is using glibc or musl libc. On one hand, musl libc’s code is incredibly easy to understand, and small enough to reason about its correctness, giving a “safer feeling” codebase. On the other hand, glibc has had more eyeballs on it for years, and the performance is also on its side.

The math here is pretty interesting: 3% performance may not seem like much, but these loses stack up, and a couple of percentages can silently bleed a lot of money.

E - Costs real money: turn off SMT

Let’s get back to OpenBSD and paranoia a bit. 20 years ago, CPUs were considered reliable, then came the hardware bugs (Spectre and its siblings), which were fixable by microcode updates to some degree, but might require compiler patches, kernel support, and it can cause performance loss. The choice is clear: be vulnerable, or be slower by some percentages.

However, there is also the case of SMT (Simultaneous multithreading, or Hyper-Threading in the case of Intel), which essentially lets 2 threads independently execute on a single CPU core, albeit slower. The upside is that instead of 1 physical CPU core’s performance you get 2 times roughly 65% performance, resulting in up to 30% overall performance increase, depending on workload. The problem is that this means that 2 threads are executing in the same CPU, and they share a physical, classically indivisible unit of computing. Good performance, potential problems.

As a reaction to CPU hardware bugs, OpenBSD disabled SMT altogether in June 2018 (sysctl hw.smt default off), calling everyone else to follow suit. Then, still in 2018 and later in 2019, multiple SMT hardware bugs were disclosed, such as L1TF (e.g. CVE-2018-3615, CVE-2018-3620, CVE-2018-3646), MDS (e.g. CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091) and TAA (CVE-2019-11135), where these vulnerabilities were either caused by SMT or were amplified by SMT.

So, OpenBSD was right. But Linux wasn’t wrong either, because 30% of performance loss is extreme - leaving that on the table means you have to pay for much more resources, and the business is hurt. So, while OpenBSD disabled it by default, Linux decided to keep it enabled by default, because in a plethora of server use-cases the potential vulnerabilities don’t matter (big data clusters, storages, etc.) or can be mitigated (core isolation between tenants, hardened databases, etc.), and if you keep your personal machine up-to-date, keeping up to 30% of performance gain is not that reckless.

There is also io_uring, which for example Google decided to get rid of on production servers and ChromeOS and blocked for Android, because in the kCTF program (where Google pays for kernel vulnerability reports) 60% of their successful vulnerability submissions were io_uring, meaning it has a poor track record as a Linux feature, amassing more vulnerability reports in this program that year, than the rest of the Linux kernel. So, it is straightforward to disable it (sysctl: kernel.io_uring_disabled=2). However, io_uring can provide dramatic performance increases in certain IO-heavy workloads - some PostgreSQL synthetic benchmarks claim even 2-3x increases, but real-world numbers can easily be in the 10-30% range, depending on many factors. I would argue that in a number of use-cases (e.g. big data clusters, etc.), it makes a lot of sense to enable io_uring if it makes your workload faster or more efficient, so you can reduce the required number of hosts. The PinTheft (CVE-2026-43494) vulnerability also required io_uring.

Doing this without overdoing it

The hardest part of hardening is finding balance in everything - performance, ease of use, and also, very importantly, the culture. It can easily become a Paranoiafest, because there is always something that can be locked down further. This can fatigue people, to the point that they just start ignoring the warnings after the hundredth “this is extremely important” unimportant tunable that catches nothing.

I recommend documenting hardening steps, especially:

• why you do it (threat model, historical bug count, or if it’s an immediate fix for a vulnerability)

• what are the costs (resources, operational, complexity)

• operational notes (why it was made, or how it changes operations), if necessary

This documentation makes it easier for everyone to digest decisions and review them later.

While paranoia in hardening used to be optional, in a race with AI-assisted bug hunting it is reckless to leave unnecessary attack surface. It is also very important to remind ourselves that hardening is supposed to help ensure things are working safely - a turned-off computer buried in the forest is extremely secure, but won’t serve customers.

Just in the past three months we went from having to be intimately in the loop with our agents to now throwing them all kinds of things and letting them cook. We’re all collectively moving at a velocity never before seen.

But, we’re all hamstrung by the elephant in the room: existing CI platforms and paradigms simply can’t keep up.

CI was designed for humans.

The impedance mismatch

The CI systems we have today are built around specific assumptions: a developer writes some code, pushes it to a branch, opens a pull request, and waits. Most engineers context switch to something else while waiting for CI to finish. The traditional processes measure feedback loops in minutes or tens of minutes. It wasn’t great but it was fine enough.

With agents writing code, that assumption collapses. An agent can write code in seconds, commit it, monitor CI, read the results, watch for regressions in the logs, detect issues, fix them, and push again – in a loop – much faster than any CI system was designed to support. The agent isn’t doing something else while CI runs. It’s blocked.

Today CI systems force humans back into the loop. To help the agent context switch to something else while waiting for CI. To paste errors from CI back into the agent and say “fix it”. To help the agent get logs about what regressed.

Every time an agent has to push code and wait for CI or have a human help it understand its results, you’ve added friction to a process that’s supposed to be autonomous.

CI is now in the critical path in a way it never quite was before.

What CI needs to be for agents

If you think about what makes CI painful specifically for agentic workflows, although engineers often talk about wanting these capabilities as well, a few things stand out:

Targeted reruns, not full pipeline reruns

Nothing is more annoying than trying to debug one step inside of a fifteen step CI workflow. That drives engineers nuts. But it actively blocks agents from finishing their work. When an agent is finishing a feature, waiting for a 15-minute pipeline to finish while validating a 3-line fix inside of a fifteen step workflow is genuinely wasteful in terms of time and tokens. Agents need to be able to rerun a single job inside of a workflow – not restart from scratch every time.

Run real CI on local patches

Agents and engineers today have to commit and pray to learn if their debugging hypothesis is correct. That’s the worst possible inner loop: write a change, commit it, push it up, wait 5 minutes, get a result, shit it’s broken, revert, try again. CI should be able to be invoked with local file changes from the agent writing the code.

All context behind an API

Most CI systems were designed for humans clicking through dashboards. Their API is a bolted on concept, not something designed to be the primary interface. Agents don’t click through dashboards. They need to trigger runs, poll status, retrieve logs, and make decisions programmatically. If the API isn’t there to give agents context, you’re forcing them into hacky workarounds.

Speed and orchestration at scale

A single engineer can be operating tens of agents simultaneously. Several agents, several branches, all needing CI at the same time. The latency, queueing, and run time of your CI pipelines and their backing providers matter a lot more when you have 20 agents all trying to validate changes at once. Not to mention that you need pricing that is clear without any hidden gotchas like one minute minimums.

What this looks like with Depot CI

We built Depot CI and simultaneously used it as the CI system for our own agentic engineering workflows. We made design decisions that make Depot CI a fundamentally different system that engineers and agents can use.

First, it’s intended to support arbitrary syntaxes or code that represent a CI pipeline. GitHub Actions is the first syntax we’re supporting, but we’re working on our own SDK if you want to use code. We’re also planning to make the syntax system open source so that you can define your own.

You or your agent can convert your GitHub Actions workflows to Depot CI with a single command:

depot ci migrate

The depot ci migrate command discovers your existing workflows, applies compatibility fixes, and copies the result to your .depot directory. Your .github folder stays intact — you can run GitHub Actions and Depot CI in parallel while you validate, then cut over when you’re ready.

Targeted reruns

Agents can now kick off a CI workflow without having to trigger any other kind of event or push code to your repository. You can do that with:

depot ci run --workflow .depot/workflows/ci.yml

Or if you only want to run a specific job, you can do that with:

depot ci run --workflow .depot/workflows/ci.yml --job smoke_container

Or if you want to have your agent debug a specific step in a job, you can do that with:

depot ci run --workflow .depot/workflows/ci.yml --job smoke_container --ssh-after-step 3

Run real CI on local patches

What if your agent has local changes it hasn’t committed yet? It can run CI against them directly — no push required. Every depot ci run command picks up local file changes automatically. The agent writes a change, validates it, and only commits once it knows it works. No more pushing broken commits just to find out they’re broken.

All context behind an API

Depot CI provides a full API for agents to interact with. Today, you or your agents can access the API through the Depot CLI. You can trigger workflows as described above. But you can also poll status, retrieve logs, and make decisions programmatically.

Check what workflows are queued or running:

depot ci run list

Check the status of a specific workflow run:

depot ci status <run-id>

Retrieve logs for a specific job attempt:

depot ci logs <job-attempt-id>

Speed and orchestration at scale

The previous three are all about helping agents rapidly iterate and validate their changes with real CI.

But for that to work, the speed and reliability of the CI system must be able to scale to the needs of the agentic workflows. The volume at which agents can validate and test their changes is going to be massive.

A single engineer today might be running five, ten, or twenty agents simultaneously — each on its own branch, each needing CI to validate its work. That’s not a hypothetical, that’s just how people are working right now. The queueing behavior, cold start latency, and per-job runtime of your CI system matter a lot more in that world than they did when a team of ten humans was pushing thirty commits a day.

Depot CI is a completely new category of CI system built with performance at every step. Plumbing that moves a commit to a running job with minimal queue time. Runners optimized for speed and security with our single-tenant architecture. Flexibility to make CI workflows as fast as you need them to be.

It’s all there from the start. Not an afterthought. Not a bolt on. Not a checkbox.

We charge for Depot CI by the second. No one minute minimums. Your agent can validate its changes in seconds instead of minutes, and you only pay for the seconds it takes to run.

The bigger picture

Targeted reruns, local patch execution, programmatic API access for logs/triggering jobs/checking status, observability into what’s happening in your job, fast orchestration, low queue times, and reliable execution. Engineers have been asking for these things for years. But no CI system was built around them from the start.

We built a programmable CI system from the ground up with all of these concepts baked in. Depot CI is built for engineers and agents. It’s the system engineers have been asking for. And it’s also the system we need to support the velocity of agentic engineering.

I bet you’ve heard the term microVM recently—it goes hand in hand with CI and sandboxes, both hot topics™ of 2026. Say you want to build a cool CI project with super fast-booting VMs. How do you choose from the myriad of available technologies? We’re not here to tell you which one to choose, but we can at least try to explain some differences between QEMU microvm and cloud-hypervisor. As the fundamentals and goals are quite similar, we’ll concentrate on the most notable differences that might be interesting from the perspective of building a platform.

What is a microVM?

(If you’re already familiar with microVMs, feel free to skip to the next section.)

microVMs are lightweight virtual machines with strong isolation guarantees, a reduced attack surface, and usually pretty fast boot times. In Linux-land, the most notable players are all KVM-based. The VMs are typically managed by a VMM (Virtual Machine Monitor) such as Firecracker or cloud-hypervisor. There are a few performance tricks that make microVMs snappier compared to full virtualization:

• Paravirtualization, where the guest OS is aware of being virtualized and communicates with the hypervisor via optimized API calls instead of emulation.

• Minimalist kernels, compiled only with the necessary components so they don’t need to load extra modules at boot.

• Lightweight init, employing a specialized, low-footprint init script instead of something like systemd.

Due to the lower resource overhead, you can achieve higher density by packing more microVMs on a single host compared to traditional VMs, especially with CPU overcommit. These properties make microVMs a good fit for short-lived, ephemeral workloads.

Comparison

Background

cloud-hypervisor is a modern VMM written in Rust. It’s inspired by Firecracker and even shares some of its components. As a relatively new project focused on cloud workloads, it has no business supporting legacy CPU architectures and devices. cloud-hypervisor runs on KVM (Linux) and Microsoft Hypervisor, but has no macOS support.

The QEMU microvm machine type is also relatively new and also inspired by Firecracker. It’s powered by KVM and runs exclusively on Linux. Notably, it doesn’t support PCI-only devices, preferring virtio-mmio as its transport instead. More on the drawbacks later.

API support

cloud-hypervisor has a rich, user-facing REST HTTP API. In fact, this is the primary way to manage VMs and interact with the VMM. When a cloud-hypervisor instance is started, the API is made available via either a UNIX socket or a file descriptor. As you may have noticed, there isn’t a higher-level abstraction or control plane that lets you list running VMs, observe their statuses, etc. Each invoked binary corresponds to a single cloud-hypervisor process.

See the cloud-hypervisor API docs for the full endpoint list.

The QEMU microvm machine type doesn’t expose a REST API, but it does offer several other ways to interact with the VMM. One notable mention is QMP, a JSON-based protocol over a UNIX socket. As an alternative, you might use libvirt, an open-source VM management tool and API that supports various hypervisors, including QEMU. The bad news is that microvm compatibility varies greatly depending on the Linux distribution you’re using, so you’ll probably end up compiling your own libvirt version. Unfortunately, libvirt uses its own RPC-based binary format instead of REST and relies heavily on XML for configuration, which might discourage some.

For more information, see the API reference for libvirt.

GPU passthrough

GPU passthrough is a way to make a physical GPU attached to the host available inside the VM. The VM should see the device as if it were native.

cloud-hypervisor uses the VFIO (Virtual Function I/O) framework, implementing the vfio-pci device to allow attaching compatible devices to the VM. (It doesn’t have to be a GPU: it could be an SD card or a network card as well.) TL;DR: cloud-hypervisor supports GPU passthrough.

2026 is all about GPUs so all VMMs must support GPU passthrough, right? Well, not quite. As mentioned earlier, QEMU microvm doesn’t support PCI devices, which means direct GPU passthrough isn’t possible out of the box. (However, since QEMU 5.2, PCIe is configurable for microVMs as well.)

Snapshotting

The essence of snapshotting is capturing a VM’s state and dumping it to disk for later use. The saved data typically includes CPU register state, disk contents, device states, and dirty (in-use) memory pages. This state can then be restored at a later point.

cloud-hypervisor supports snapshotting via its API. First, the VM needs to be paused, then the snapshot can be taken. When restoring a VM from a snapshot, it needs to be explicitly resumed. The only caveat is that VFIO device states are not included in the snapshot. cloud-hypervisor allows snapshots to be taken regardless of the disk format, including raw disks. Watch out though, snapshotting isn’t guaranteed to work across different versions.

Snapshotting should work with QEMU microvms as well, using the savevm and loadvm commands. These are exposed to the user via the QEMU monitor or QMP. At least one writable qcow2 disk is needed, as the entire VM state is dumped into the disk image. Alternatively, QEMU’s migrate command can dump the full VM state (CPU, RAM, devices) to an external file, which works regardless of disk format, though the disk image must be managed separately in that case.

Live migration

Live migration is the act of moving a running VM from one process to another on the same host, or from one host to another entirely. All processes and connections within the VM should remain intact, and the source VM should gracefully stop once the migration completes. For this to work, both environments need to be identical. The migration is typically performed by iteratively copying dirty memory pages to the destination and switching over once the delta is small enough. Live migration is useful when a host needs to be decommissioned but the workloads must keep running (like for mission-critical services).

cloud-hypervisor supports live migration. As usual, the functionality is exposed via its API.

Nothing in the documentation explicitly says that QEMU microvm doesn’t support live migration, so there’s reason to believe it does. However, live migration with ongoing external IO isn’t supported for the microvm machine type.

For both cloud-hypervisor and QEMU, live migration isn’t guaranteed to work across different versions, which is a small price to pay for such a useful feature.

Hotplug

Hotplugging is the act of adding, removing, or modifying VM resources and devices without requiring the VM to be stopped or rebooted. Just as plugging in a USB device makes it instantly appear on your machine, VMs should be no different, right?

Well, cloud-hypervisor supports hotplugging x86 vCPUs, PCI devices, and memory resizing. When adding extra vCPUs to a running VM, they need to be “onlined” on the guest side. Multiple memory hotplugging methods are supported, some of them semi-manual (see the documentation for details). Adding or removing PCI devices (including GPUs) is handled by the guest with no manual work required.

Unfortunately, QEMU microvm doesn’t support hotplugging at all.

Conclusion

To make everything we’ve covered more digestible, let me summarize it in a table.

There’s no intention to declare a winner here. You might have a very good reason to choose either of these amazing technologies. For example, if you run virtualization across multiple platforms and guest OSes, and you don’t need GPU passthrough or hotplugging, it might make sense to go with QEMU, which has the same API and shenanigans as the rest of your stack. As with everything in life, collect information, capture your requirements, and make an educated decision.

If you’re interested in which VMM we chose, stay tuned! Join our Discord Community to get all the latest.

John Henry is an American folk legend. He’s a steel-driving man. Driving rail spikes through plains and mountain tunnels alike. He raced a steam-powered drill to prove a human could outwork a machine. He won. Then he dropped dead, hammer still in his hand.

I keep thinking about what that must have felt like. Standing there, watching the machine drive spikes into the earth with speed, consistency, and precision. Wondering if the skills you’ve spent your life getting good at were about to stop mattering.

Because so many of my intuitions as an engineer—intuitions I’ve honed over a decade about readability, maintainability, and “doing it right”—feel wrong now. Part of how I judged myself as an engineer was based on the empathy I showed in my code. How much easier I made it for the next engineer to read and maintain. But I’m barreling into a world where that “next engineer” is just a bundle of statistics finding the next token.

I don’t know what to do with that. Let me show you what I mean.

The moment I noticed

I recently found myself staring at a 1500-line file in our codebase. It was a dumping ground. It had no structure, terrible naming conventions, and logic that meandered like me when I’m with my wife at Target: seemingly aimless, just hoping I could get the heck out of there.

My engineer instincts kicked in. I felt that familiar itch, the urge to refactor. I fired up an LLM and told it to clean the file up. It did a beautiful job. It organized the logic, extracted duplications into helper functions, and turned that dumping ground into something I could more easily parse with my eyeballs.

But then I stopped and looked at the pristine new file. It was better. It was cleaner. But did it actually matter?

We write clean code so that other humans can read it. It’s empathy and insurance for the next human that has to touch it. Over the following months, most every change to that file was made by an agent. Not once did I need to open it and squint at the logic. The agent never cared that I’d organized it into neat little sections. It would have been just as happy chewing through the dumping ground. I was refactoring for me, and I used “empathy for my fellow engineers” as justification.

40 years of empathy for the human brain

Look at these two loops.

Example A:

MOV CX, 10
L1:
ADD AX, 1
DEC CX
JNZ L1

Example B:

for i in range(10):
    count += 1

Which one is easier to understand? For 99.999% of us it’s B. If you picked A, congratulations, I award you one thousand nerd points.

Why do we prefer B? It’s not because Python is faster. It’s way slower. We prefer it because it’s faster for our brains to parse what the heck is going on.

For the last 40 years, many of the advances in software have been about empathy for the human brain. We built abstractions, invented high-level languages, and wrote books like “Clean Code” because human cognitive capacity is limited. Descriptive variable names and small functions are useful because, unlike computers, I forget what I read a few lines ago.

Code became optimized for the reader, not the compiler.

But what happens when the reader is no longer human?

Code as artifact

Here’s the thing I can’t unthink: the code is not the point. It’s an instructional artifact to produce something useful for a user. No user downloads an app and says “Man, I hope they preferred composition over inheritance.”

I tried to talk myself out of this. “Sure, the AI can write it, but can you fix it when it breaks at 3 AM?”

Being on-call used to mean a customer messaged me with some obscure error, and I’d spend the next thirty minutes manually traversing Cloudwatch and Axiom logs. Hoping to find a needle in a haystack. Now, I copy-paste the error, hit the Cloudwatch and Axiom MCPs, and boom: 9 out of 10 times I find the issue. What used to be a log safari is now ninety seconds and a few tool calls. Multiply that across a team, across a week, and I can’t really tell myself that clean code is what’s saving time.

Then I told myself it was about structure. Fine, variable names don’t matter, but structure matters. And maybe it does. But when I’m honest with myself, I can’t point to evidence that an LLM writes worse code in a messy repo. And that bothers me. I’ve watched agents make correct changes in files I’d be afraid to touch. The machine doesn’t need the guardrails that I need.

The last thing I clung to was depth. AI sucks at fixing deep architectural rot that rapidly fills the context window. And that’s true.

For how much longer?

Where the tunnel needs to go

It was never about the hammer though. It’s knowing where the tunnel needed to go. The judgement, the systems thinking, the ability to communicate and tease the real product requirements. That’s the real work. It always was.

And this is where John Henry’s story diverges from ours. Or so I like to tell myself. He was pure strength and execution. We’re the ones who decide where the tunnel goes and why it’s being built at all. The machine could match his hammer but it can’t match our judgement. Right?

Because what really worries me is that the same pattern that is making clean code less relevant is climbing the ladder we’re all standing on. Each rung AI climbs, I tell myself this is the one that requires human judgement. And each time, the horizon gets a little closer.

So, what happens when the machine catches up? When it knows where the tunnel should go?

I don’t have an answer. But I think the honest version of this essay isn’t “relax, the important stuff is safe.” It’s that the boundary between where humans excel and machines excel is blurrier than I’d like to admit. And it’s still moving.

And you know what? I still pick up the hammer some days. I miss how it feels in my hands.

What’s fueling this? It’s AI and LLMs. We’re experiencing a fundamental shift in software development.

For decades, the biggest bottleneck to innovation was writing code. But today, that’s no longer true. Code and ideas can now iterate as fast as you can articulate them to an AI agent with a powerful model like Opus 4.5 or GPT-5.2 Codex.

Iteration can be done in seconds instead of hours. And a new generation of tools, services, and products are being imagined faster than ever.

The bottleneck has shifted from writing code to integrating it.

How did we get here?

When LLMs first became available to the public, the developer ecosystem was quick to experiment with them. We saw folks generate code from prompts. It kind of worked and it was neat. But it was also a bit of a mess. The code was often buggy and the quality was often questionable. But it was a start.

We started seeing their potential, but we didn’t really trust them.

So we figured out ways to integrate them into our existing workflows. The idea of spinning up agents via things like GitHub Actions or CircleCI became a thing. We quickly started seeing AI agents being “bolted on” to our existing workflows for code reviews, test generation, and more.

In essence, we took this new experimental capability and bolted it on to our existing human-centric workflows.

Then things changed. It felt like overnight, but it was steady improvements in model capabilities every couple of weeks. Models like Opus 4.5 and GPT-5.2 Codex are better at understanding code, better at generating code, better at understanding context, better at understanding codebases.

We shifted from a world where the agents and models were experimental and hard to trust to one where they are reliable, productive, and better than humans at many tasks.

The new traffic jam that has been created

With that shift, a new traffic jam formed in our human-centric workflows.

Engineering teams operating with agents are now seeing the downstream effects of their newfound productivity. Pull requests pile up faster than humans can review them. CI queues grow because builds and tests are taking too long to run. Merge conflicts multiply as more changes flow simultaneously.

Repurposing our existing workflow that focused on engineers in the middle of everything is now at the root of the bottleneck. Bolting AI into our existing workflows worked okay initially. This worked when writing code was the slow part. When a developer spent days on a feature, 20 minutes of CI wasn’t the constraint. When you can generate a feature in 20 minutes, a 20-minute CI pipeline is unacceptable.

I’m seeing this with Depot customers right now. They’re coming to us with more and more requests to hyper-optimize very specific parts of their CI workflows.

Can you help make our tests faster? Could you support caching this thing as well? Could you get us a runner in milliseconds for these CI checks that take 30 seconds to complete?

All these questions stem from teams that want to move faster, and they’re seeing the bottlenecks that have always been there but now are more pronounced.

We’re producing exponentially more code and iterating faster than ever before. But we can’t keep the momentum of this newfound power if we can’t move it through review, integration, testing, and deployment faster.

What got us here won’t get us there

The human-centric workflows we built assume developers work at a measured, deliberate pace. Code review happens asynchronously. CI runs are expensive. Integration happens infrequently because changes are large and risky.

None of these hold anymore. AI agents produce working code in minutes, attempt dozens of approaches simultaneously, and generate code 24/7. But they’re forced into collaboration patterns designed for humans working business hours on carefully crafted changes.

The real-time feedback loop is the key

Here’s what I believe: real-time feedback loops are what empower software engineering at scale.

We need to rethink our workflows to support this new reality. We need tests to run on every commit, merge conflicts to self-resolve automatically, context about how the code was developed should live right next to the code, and builds should be near instant. All of this should be seamless for both humans and agents.

It’s not about a human in the loop anymore. It’s about humans orchestrating work being done at scale, with engineers deciding what good vs. bad is, what to iterate on, what ideas to explore, and what to ship next.

We’ve seen this at Depot with build performance. Teams with 60-second builds make fundamentally different decisions than teams with 40-minute builds. They try more things. They validate assumptions faster. They catch issues earlier. Speed doesn’t trade off with quality. Speed enables quality.

We need a new paradigm

The solution isn’t faster pull requests or cheaper CI pipelines. Those are incremental improvements to a fundamentally outdated model.

We need workflows that integrate continuously, validate automatically, provide real-time context, and work for both humans and agents.

Think about Google Docs. Multiple people work on the same document simultaneously. Changes sync in real-time. Comments live in the document. Spelling and grammar checks run automatically as you type. Software engineering collaboration should work the same way.

Every team adopting AI coding tools will hit this bottleneck. Some already have. But we are likely only at 1-2% adoption of AI coding tools. As adoption increases, this bottleneck becomes the most pronounced barrier to break down. Teams that figure out how to bust through it will have a massive competitive advantage. They’ll operate with a new paradigm, where agents have everything they need to go from engineers’ ideas to running in production as quickly and autonomously as possible. They will run circles around their competitors who don’t have this new paradigm. They’ll operate above their weight class.