AI-native engineering: the bottleneck moved

For more than a year now, Xaventra has been 100% AI-native. Agents write every change we ship: features, fixes, migrations, tests. Engineers still decide what gets built and whether it's right. They've mostly stopped typing it.

The agents also keep getting better. A year ago an agent could handle a well-scoped bug fix. Today it can take an issue all the way to a pull request: it writes the code, runs the suite, reads the CI failure, and pushes the fix.

That changed how we work, though not in the way we expected.

What AI-native means for us

• Agents write the code. Engineers write the plan: the problem, the constraints, what "done" looks like. The plan is now the real artifact, and the diff follows from it.
• Agents review first. Before a human opens a PR, an agent has already checked it for bugs, missing tests and drift from the plan.

The new bottleneck

Writing code got dramatically faster. Deciding what to build didn't.

Take a feature that used to take ten days: two to plan, seven to build, one to review. Now say agents make building 5× faster, and planning and review stay the same.

Building drops from seven days to under a day and a half, so the feature now takes 4.4 days instead of ten. Building got 5× faster, but the feature only got 2.3× faster. Planning and review went from 30% of the time to 68%.

Ownership, not more layers

So how do you organize a team where engineers can build much faster, without decisions and reviews piling up?

The obvious answer is more process: more PMs, more planning meetings, more approvers. But that slows down the part that's already slow.

Our bet goes the other way: give engineers more ownership. One engineer owns the whole loop, from understanding the customer's problem to shipping a fix, checking that it actually worked, and owning any regression it causes in production. Every handoff adds a queue, and the queues are where the time goes.

In practice:

• Plans live in the repo, next to the code, and get reviewed like code. If an agent can execute a plan, another engineer can review it in five minutes.
• Review depends on risk. Every change gets an agent review. A human reviews the changes that could do real damage: data migrations, auth, billing. A copy change doesn't wait for anyone.
• Verification is part of done. Every PR says how we'll know it worked, whether that's a metric, a log line or a dashboard. The engineer who shipped it checks.
• A regression goes back to its author, not to a generic on-call queue.

Engineers have to be product-savvy

When writing code is cheap, deciding what to build matters a lot more.

That changes what we need from our leads. They need to understand customers, have strong product opinions, and be comfortable making product decisions, not just technical ones. They also need to help engineers build the same judgment. We shouldn't need a PM or a designer for every small product decision.

An agent will build exactly what you asked for. Whether you asked for the right thing is now most of the job.

Marketing as code

This isn't only an engineering change. Our brand, our blog and our hiring material now live in the same repo as everything else, as code.

Because it's all code, agents work on it the same way they work on product code. A new cover or a new job ad is a prompt and a pull request.

That changes the job for designers and everyone else too. Designers stop making one-off assets and start designing the system that makes them: the tokens, the layouts, the rules for what a cover can look like. A good decision about the system shows up in every asset an agent generates after it. The same goes for anyone who writes copy, job posts or docs. Their work moves into the repo, gets reviewed in a pull request, and ships the same way code does.

Where this leaves us

We spent the last year making engineers faster. Now we're working out how to make the whole organization move at that speed.

We suspect that will be harder than automating code, tests and reviews. Those were technical problems. This one is about how people make decisions.

We're still early, and there's a lot we haven't figured out. These are the questions we're actively working through right now:

• Does code quality still matter when agents write most of the code?
• What will codebases look like in an AI-first world?
• How much of review can be automated?
• Should AI be allowed to review and merge without a human approving?
• What are the biggest bottlenecks when building with AI, and how do we remove them?
• How should hiring change? And team structure?
• What does seniority mean from here on?
• How should AI credits be allocated across the team?

We'll write about what we learn as our answers take shape. If your team is working through the same questions, we'd love to compare notes.