The role AI can't fill

Dan Shipper thinks you need two people to ship software in 2026. A pirate and an architect. He's only 2/3 right.

Shipper's framework, which circulated widely enough to become shorthand in engineering circles, is straightforward: one person ships features as fast as possible using AI-assisted vibe coding, discovering what works through speed. A second person follows, turning those discoveries into stable, maintainable systems. Both roles are AI-augmented and necessary. Together, Shipper argues, they cover what used to require a much larger team.

When I shared this with a senior engineer, his response was immediate: the framework covers building fast and building right. But nobody's covering whether the thing actually works for someone who isn't the person who built it.

As his team shrank, he was judge, jury, and executioner — the pirate and the architect rolled into one, shipping up to 100 pull requests in a week, reviewing his own code with AI tools, moving fast in every direction. He even had a word for the side effects from his architectural piratitude: casualties.

‍

What the third role uncovers

‍

I know how that role works because at DevDocs, it's what we train our practitioners to be.

During a recent engagement with a developer infrastructure company, I ran user interviews with developers integrating their MCP, a tool that enables AI assistants to understand their programming language and interface directly with their infrastructure. It was a smart feat of engineering, but as someone coming in cold, I saw what they couldn't.

Hidden in plain sight

Users were arriving at the README and spending 5 to 10 minutes asking Claude to explain what the tool even did before they could think about installing it. The main docs linked to it from the homepage, but neither the stub nor the README ever answered the obvious question: how does this help me?

Across interviews, familiar patterns kept showing up: developers routing around docs they'd decided weren't reliable, or feeding them straight into Cursor or Codex, only for AI to replicate the same oversights as those who skipped them entirely.

It takes an outsider

Our CEO, Justin, volunteered to sit in on a user interview as someone who had never touched their tech stack. He hit real problems immediately. The Node version wasn't documented, the error it threw was a dead end, and even knowing when to invoke the tool took trial and error. He worked through it because he's an elite engineer. Most developers would have given up or wasted hours on setup with a tool designed to save them time.

What makes the third role work is that it stays outside. An agency like ours makes that sustainable, cycling in fresh perspectives rather than letting any one person become the expert they were hired not to be.

‍

Why AI makes this role more critical

‍

The assumption baked into Shipper's framework is that the tools help close the gaps, letting pirates ship faster and architects refine faster. What the framework doesn't account for is that neither role gains an external view from AI tools, widening the insider blind spot. When speed drives the roadmap, less time goes toward empathizing with new users.

There's a second problem specific to documentation. Developers hallucinated good docs long before LLMs, making assumptions, skimming review, and missing holes their readers would eventually fall into. LLMs just do that at scale, and with more assurance than any human would. When documentation contains outdated, incomplete, or misleading information, an AI assistant will confidently reproduce those errors.

Speed in production and deployment doesn't close gaps. Without the third role, it just produces more casualties, discovered long after anyone remembers what caused them.

‍

Why org charts miss it

‍

Pirates and architects have legible outputs: features ship, systems stabilize, and you can point to both on a roadmap. But the third role is proactive. With it, nothing breaks in the ways that are hardest to trace back to a source. The value becomes visible only after it's gone, and by then it's already a support problem, a reputation issue, or an LLM that's been quietly wrong for longer than anyone realized.

This is why it gets cut first, or often misses the org chart. It touches engineering, QA, and technical writing, but doesn't map cleanly to any of them. Ambiguity doesn't survive headcount conversations. And because the failure mode surfaces after the product is on the market, the decision to cut it may seem defensible at the time.

The senior engineer I mentioned earlier had internalized the problem before he could name it. When you're covering an entire team as both pirate and architect, you don't have time to experience your product as a new user would.

We call this role a Documentation Engineer, and it's the core of what DevDocs does.

‍

What it looks like when the role exists

‍

AI cannot replicate the outside view.

The pirate and the architect are good at what they do, but even the head of a genius engineer can't fit the third hat. Neither role knows what it's like to be new to your product. By the time that gap appears in your support queue, your LLM has been wrong longer than anyone realized.

Start with a discovery call.