Building an AI-Native Organization

Lessons from running product and engineering as an AI-native company.

Most companies I talk to say they’re becoming AI-native. When I ask what that means in practice, the answer is usually a list of tools they bought.

I understand the instinct. Tools are easy to buy and easy to point at in a board deck. We bought them too!

Then we spent a year doing the harder version of this, across product, design, and engineering. Three things turned out to matter. None of them was a tool, and two of them took us an embarrassingly long time to see.

Lesson #1: You can’t empower only one function

Engineering was the loudest voice in the room, so engineering went first. That felt obvious at the time. Our developers were already using AI for everything, agents were writing most of our code within a few months, and the output looked great.

Then the cracks showed. We were shipping more code than ever, but more and more of it came back for rework. Not because the code was bad, but because what we had asked for was unclear.
It took us a while to see that the problem wasn’t in engineering at all.

Our engineers had become very fast at building things, but the tickets they were building from hadn’t changed at all. Same level of detail, same ambiguity, same Tuesday morning rush to get something into the sprint. What we had actually built was one team that was faster than the others.

That was the first lesson, and I think it’s the one a lot of companies are about to learn the expensive way.

You can’t empower only one function.

Give engineering an agentic pipeline and leave the product team where it was, and the queue just moves. Now you have idle capacity sitting behind vague requirements. Do it the other way around, hand product AI and leave engineering alone, and you generate more requests than anyone can absorb. Everybody works harder. Nothing ships faster.

The bottleneck doesn’t disappear when you automate one function. It moves. It usually lands on the team you didn’t invest in, and because everything now waits on them, the whole organization slows to their pace. Their work didn’t become less important. It became the constraint.

So AI-native is not a department. If it is a department, then what you have built is a fast segment inside a chain that still moves at the speed of its slowest link.

Lesson #2: Agents test themselves, or your engineers do it for them

The second lesson was the highest-leverage investment we made, and it’s the one no one wants to talk about (or admit).

It’s not a better model. It’s not a better prompt.

Our agents run inside environments where they can execute against every capability we have. The agent writes code, runs it, watches it fail, fixes it, runs it again. All of that happens before the agent opens the pull request. The agent does not hand us code it believes works. It hands us code it has watched work.

That sounds like a small infrastructure detail, but it changed what our engineers do all day. And it helps us ship code 24/7.

Before, a reviewer’s first job was answering "does this actually work?" That question is mechanical, it is exhausting at volume, and an agent can close it. Now the reviewer answers something harder: is this the right thing, built the right way? That takes judgment, and it is the only question worth a senior engineer's afternoon.

Here is the test I would apply anywhere you want AI doing real work, not just in engineering. Can it see whether it succeeded? If the answer is no, you have not deployed an agent. You have deployed a very fast first draft, with a human QA department attached to it.

Lesson #3: The definition is the constraint

The third thing took the longest to accept.

Models are not the constraint any more. The quality of the definition is.

Give an agent a vague request and it will build something: fast, confident, and probably not what you meant. Someone explains what they actually wanted, the agent tries again, and eventually it ships. We call each of those loops a round trip. Many teams run four or five per task without noticing, because commits keep coming and commits feel like progress.

Once you’re counting, the uncomfortable part gets obvious. A lot of the leverage starts with how the work is defined.

Which is why we ended up investing in how product describes intent before we invested in making engineering execute faster. The definition is the input to everything downstream, and nothing downstream recovers from a bad one.

Where to start

Measure before you change anything. You won’t believe how much you were guessing. We built the measurement after we built the system, so for that first few months, we were running on feel.

1. Give AI somewhere to validate itself. It’s unglamorous infrastructure work and it pays for itself faster than anything else on this list.

2. Find the real bottleneck, not the one you assume. Ours was not where we expected, and we lost a quarter to that.

3. Don’t roll this out one team at a time and expect it to compound. You’ll get a fast segment and a frustrated neighbor.

Becoming AI-native is an organizational project that happens to involve technology. It is not a technology project that happens to involve the organization. That distinction sounds academic right up until the moment you have spent a quarter accelerating the wrong link in your chain.

The companies that get this right won’t be the ones with the best tools.
Everyone has the same tools.