How AI-Native Companies Ship Faster Than Everyone Else

Everyone keeps asking the wrong question about Anthropic's shipping velocity.

The common assumption is that companies like Anthropic and OpenAI move fast because they have access to better AI. They built the models, after all. Surely that's the edge. Nate B Jones, who runs the AI News & Strategy Daily channel, thinks this framing is almost entirely wrong—and his argument is more structurally interesting than the typical "adopt AI tools" content that's flooding the internet right now.

"Hint, it's not AI," Jones says at the top of his recent video laying out what he calls 15 commandments for becoming an AI-native organization. "The answer is relatively simple."

His actual diagnosis: the companies shipping weekly have moved their repeatable human coordination into code. The ones stuck shipping quarterly haven't. The AI is the same. The organizational substrate underneath it is not.

What "moving into code" actually means

This isn't programmer evangelism dressed up as management theory. Jones is making a specific claim about how decisions flow through an organization.

In a traditional company, a decision gets made in a meeting, sometimes gets written down, and then has to be re-explained by a human the next time it's needed. That re-explanation loop is the rate limiter. Every time a decision has to travel through a person, that person becomes a bottleneck—especially when agents and automated systems are now waiting on the other end.

"If every decision has to be reexplained by a person," Jones argues, "the humans become the rate limit on the business."

The shift he's describing is: take what used to require a person to repeat and make it durable. Meeting decisions become documents that agents can reference. Repeated reminders become automated systems. Product managers stop directing engineers through ticket queues and start working directly in the codebase alongside them. Design stops being a screen-only discipline and starts showing up in the SDK, the error messages, the permission boundaries that agents hit.

The photography analogy Jones uses lands well here. When film cost money, scarcity imposed discipline—you took 24 pictures on vacation because each frame had a cost. Digital photography removed that cost, which is why most people now have 40,000 photos and can't find their kid's birthday in the pile. AI has done the same thing to software: the cost of another prototype, another draft, another analysis is collapsing toward zero. But the decisions about what to build, why it matters, and whether anyone will care—those didn't get cheaper. They just got easier to avoid.

That's the crux of Jones's argument. The AI era doesn't remove the need for judgment. It removes the artificial scarcity that used to force judgment. AI-native companies have built systems that preserve judgment while eliminating the coordination overhead around it. Everyone else is just drowning in cheaper drafts.

The cluster that will make product managers nervous

The most pointed section of Jones's framework targets the sacred document of modern product development: the roadmap.

Commandment three says product does not make roadmaps. Commandment five says product does not control or direct engineering time. Read those two in isolation and yes, you've got a good recipe for organizational chaos. But Jones pairs them immediately with commandments four and six: product managers should be in the terminal daily, sitting with engineering and making decisions while the thing is being built, not before.

The logic is clean. With current tooling, a team can get a working prototype in front of a customer faster than a roadmap meeting can find a free slot on everyone's calendar. Jones specifically names tools like Claude 3.5 Sonnet and multi-agent systems as the reason the build-to-feedback loop has compressed this dramatically. The question isn't whether to build before getting full alignment—it's whether product judgment is present in the room while building happens, rather than happening upstream in documents that are stale by the time the engineers touch them.

Jones is careful to note the job descriptions don't actually collapse: "Engineering still has to answer: does this code work and will it keep working? Product still has to answer: should this exist and does anybody care enough to use it? Same terminal, maybe you're in the codebase together. Different questions."

What changes is proximity. And timing. The AI coding arms race that's currently consuming the major labs is making this shift increasingly non-optional—faster models mean the build loop compresses further, which means the upstream planning process falls even further out of sync if it's not co-located with building.

The documentation problem that nobody wants to talk about

Jones devotes serious time to writing—which might seem like an odd priority in a video about AI-native speed. But it's the part of his argument I find most structurally sound, even if it's the hardest sell.

The reasoning: agents need clear documents to act on. Ambiguous documents don't just fail to help agents—they actively propagate confusion downstream at machine speed. "If you have ambiguous documents, you are just spreading chaos through that system," Jones says. "You need to obsess over your documents so that they are clear. Otherwise, you're just pushing that chaos downstream."

This reframes documentation from administrative overhead into load-bearing infrastructure. The quality problem Jones flags—AI slop, vague instructions, documents that technically exist but don't carry decisions—isn't just an aesthetics issue anymore. It's an ops issue. An agent running on a poorly written spec is an agent confidently doing the wrong thing faster.

Jones invokes his experience at Amazon to make the point about writing discipline, emphasizing the culture of rigorous multiple drafts and peer review of documents—not as nostalgia, but as the model for what agent-era documentation should require from humans. The principle holds regardless of the specific numbers: writing that agents must act on demands a different standard of clarity than writing that merely informs humans. That gap is where AI productivity gains tend to evaporate for organizations that haven't figured it out.

The failure mode everyone picks

Jones's most useful contribution might be his diagnosis of partial adoption. He's seen it enough to name it as one of two primary ways organizations ruin this whole system.

The pattern: a leadership team watches a video or reads an article, identifies the one commandment that sounds easiest or least threatening—say, the no-roadmap rule—and adopts it without the surrounding system. Now they have no roadmap, no PM in the code, no documentation discipline, and no daily PM-engineering collaboration. They don't have a lean AI-native org. They have a confused one.

"If you only take the no roadmap rule, but you don't get your PMs into the code, all you're doing is producing chaos," Jones says.

This is where I'd push back slightly on the framing. Jones presents this as an all-or-nothing system that organizations must adopt whole—and there's genuine logic to that, since the commandments do function interdependently. But the organizational change literature is pretty consistent that all-at-once transformations have a rough success rate, and Jones is essentially describing a full cultural overhaul. The Anthropic Slack integration story is instructive here: even inside a company explicitly built for AI-native speed, the cultural adoption has been uneven, with engineering moving faster than the rest of the organization. If Anthropic has this problem internally, the prescription of "do all 15 or fail" probably needs some nuance for the legacy enterprise trying to adapt.

Jones acknowledges the culture point directly: Anthropic's advantage isn't just that they've adopted these practices—it's that they've been hiring for them from the start. Every new hire arrives expecting this pace. That's a compounding advantage that a traditional organization can't simply acquire by running a change management process, however good the companion guide.

The one thing that actually stays human

Jones insists repeatedly that not everything moves into code. Trust stays human. Taste stays human. The courage to say something isn't working stays human.

"One person and one agent can produce an enormous amount of material," he says, "but they still need all of us working together to get to taste and domain knowledge and customer connection and brand and willingness to say that this doesn't work."

That framing—AI handles the volume, humans handle the discernment—is where his argument is most honest about what it's asking of organizations. It's not asking people to work less, or to let AI make decisions. It's asking them to stop using coordination overhead as a substitute for clarity, and to show up with better judgment, faster, with less scaffolding to hide behind.

Whether most organizations can actually do that is an open question Jones doesn't fully resolve. But the framing of the problem—humans as the rate limit, coordination overhead as the real drag, documentation as ops infrastructure—is clear enough to be useful even if you only act on pieces of it.

Just don't tell Jones you're only implementing one commandment.

---

Alex Volkov covers startups, venture capital, and the tech business ecosystem for Buzzrag.