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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Specialized models are now viable for real engineering work. Almost all of our development runs through an autonomous loop, and we'd been on a trajectory where each new frontier model made that loop markedly better. With the latest generation, that's no longer the pattern.

We run that loop on Cursor Cloud Agents. We started there because the harness was easy to stand up, and it's the most ergonomic remote agent environment we've used. We assumed the coding in that loop needed the best general model available.

We tried Composer on a lark. We were blown away: for most of the coding we run through the loop, it was a drop-in replacement. It's faster too. We haven't benchmarked it precisely, but the gap is obvious, and public numbers put it near 50% quicker on coding tasks. It's also 90% cheaper than Opus.

It isn't good at everything. Behind our QA agent it was noticeably worse. That's the point. It's specialized for coding.

For us the tradeoff flipped. A cheaper, faster, good-enough coding model beats a general model that's stronger at things the task never touches. Composer is the good-enough one today. I'd expect that to flip: specialized coding models pulling ahead of general ones at coding outright, and getting cheaper and faster as they do.

QA is the gap for us now, so if you know a model specialized for it, tell me.
I'm surprised I don't hear more about Composer. And it raises a real question for model specialization: who wins there? Maybe it's the major foundation labs that already hold all the leverage. Maybe specialization is the crack where someone else gets in.

There's a lot of handwringing about merging code that has only been reviewed by AI. It's backwards. A process where some code is reviewed only by AI will be more security conscious than what we do today.

Start with the problem. AI writes more code than any team can review, so everything gets the same rushed skim, and the changes that actually matter don't get the attention they deserve. The fix isn't more reviewers or going slower. Teams can’t afford to ship slower in this environment. It's deciding what humans need to see at all.

Humans were always bad at this part anyway. Outside the most egregious cases, we've never been good at spotting a bug or a vulnerability by reading code cold. AI has been better at that for a long time. A half-distracted developer waving through a diff is not your security baseline. An agent making that call catches more.

So route deliberately. Certain file paths and high-risk changes go to humans. That's a mix of deterministic rules and AI classification, and classification is something AI is good at. Everything else is reviewed by AI alone. Now the sensitive code gets real scrutiny instead of competing for attention with everything else.

What was human review ever really verifying? Legibility. Could another person read this and follow it. But the primary reader is shifting from human to AI, so stop optimizing for human legibility and start optimizing for AI legibility. We used to have complexity metrics for how hard code was for a person to parse. I want the equivalent for a model, scoring not just structure but whether the prompts, skills, and agents around the code help it understand what it's looking at. That's the thing worth building.

"Our engineers use Cursor."

"Use Cursor? We moved beyond IDEs entirely. Engineers just describe features to agents."

"Describe features? That's adorable. Our PMs describe features directly to agents."

"PMs? We eliminated PMs. Customers describe features directly to agents."

"Customers? We eliminated customers. Agents analyze user behavior and create the roadmap themselves."

"Roadmap? Our agents rewrite the company strategy every night."

"Strategy? We don't even have executives anymore. The agents found them to be a bottleneck."

"Executives? Luxury. Our board meetings are attended exclusively by agents."

"Board meetings? We haven't had a board meeting in months. The agents acquired three companies while we were asleep."

"Companies? We don't have companies. Just a loose federation of cooperating agents with a Delaware LLC."

-- Inspired by Monty Python's 4 Yorkshiremen sketch: https://lnkd.in/dA9U4b9E

You can't build an AI-native product with a team that isn't AI-native.

Most teams still think about AI the wrong way. They start with a human process and ask: "How can AI help people do this faster?" That's the wrong question.

An AI-native team starts with the outcome and asks: "How do we get the AI to achieve this outcome?" Then they work backwards from there. Maybe the AI needs verification. Maybe it needs an approval threshold. Maybe it needs an audit trail. Maybe there are edge cases that still require human judgment.

The software becomes scaffolding around the AI, not the other way around.

This is a hard mindset shift because for most of business history, outcomes were constrained by people. If you wanted more contract reviews, more supplier research, more invoice matching, or more policy enforcement, you hired more people. The software was there to support the human.

Now, for a growing set of tasks, you can spend tokens instead. That doesn't mean humans disappear. It doesn't mean AI can do everything. But it does mean we should stop assuming humans are the default actor in every business process.

Procurement is full of work that AI can already do as well as, and often better than, people: three-way invoice matching, sending NDAs, supplier research, tracking RFP responses, policy enforcement.

The opportunity isn't to help humans do those tasks faster. The opportunity is to have AI do them, then add the controls, verification, and auditability required to trust the result.

The most important mindset shift in AI is moving from: "How do we use AI in this process?" to "Why does a human need to do this at all?"

The bottleneck to scaling enterprise AI is almost never the model. It's the data underneath it. I've spent most of my career in data infrastructure. That bias shapes how we build at Levelpath.

The customers we work with who are building agents run into the same wall: the agent can't access the right data to make a decision. A supplier record that lives in a system it can't reach. An approval history that was never structured. A risk signal that exists somewhere, just not somewhere the agent can see. When that happens, agents don't tell you they're stuck. They fill in the gap and keep going. That's the failure mode nobody talks about enough.

At Levelpath, we do the integration work upfront. Every relevant data source connected, normalized, accessible. We do this because our approach is agent-first: everything in the product is designed to be done by an agent by default. For that to work, the agent needs to be trustworthy. It escalates when it should and it never makes something up. We build those guarantees in.

Applied AI is usually a data and integration problem. The models are plenty capable. Give them the right data and they'll do the work.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI algorithms deserve the same mindset.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Talk About Velocity. A Lot.

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

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

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

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

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

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

Identify What’s Slowing You Down

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

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

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

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

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

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

Measure What Slows You Down

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

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

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

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

• Code review turnaround time

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

• Time to first deploy

• Flaky tests and intermittent failures

• Hard-to-read code or missing patterns

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

Build a Productivity Baseline (Carefully)

You need a productivity baseline.

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

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

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

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

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

Holding Leaders Accountable for a Velocity Culture

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

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

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

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

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

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

A Note on AI and Velocity

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

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

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

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

Engineers Need to Ship

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

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

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

1

Credit to for introducing me to this idea.

Engineering Enablement

The Case Against Measuring Cycle Time

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

Read more

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

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

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

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

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

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

The mistake is pretending that this timeline is smooth.

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

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

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

The cleanest recent example is the China shock.

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

The pattern repeats:

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

• Agricultural mechanization hollowed out rural labor

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

Net positive. Locally catastrophic.

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

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

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

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

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

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

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

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

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

A few corollaries fall out of this.

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

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

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

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

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

Remote: Talent First, Pay in Process

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

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

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

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

In-Person: Energy First, Optionality Reduced

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

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

That volatility is the price.

The Middle Is the Failure Mode

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

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

Both are fine. Waffling is not.

Conclusion

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

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

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

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

1. Testing unfamiliar systems: documentation by empiricism

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

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

Before, your options were:

• Read the docs (ha).

• Read the source (double ha).

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

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

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

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

2. Testing things you didn’t think of

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

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

That stuck with me.

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

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

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

3. The next frontier: acceptance testing via prompt

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

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

But a prompt like:

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

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

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

Two nice properties fall out of this:

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

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

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

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

The bigger shift: when tests hit zero marginal cost

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

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