Running an AI-Native Engineering Org: What Changes When Coding Isn't the Bottleneck

1. What served you prior may no longer

Fiona Fung opens with a provocation: many engineering processes that feel normal are artifacts of a past constraint. They were designed to protect expensive engineering bandwidth, and now that constraint has shifted.

The pattern recurs through history. In the early 2000s at Microsoft, building Visual Studio meant a single server room with a queue — only six PRs could merge at a time. Every process was built around that bottleneck. Then cloud and CI eliminated the constraint, and the processes had to change.

“When coding is no longer the slow part, everything upstream and downstream of coding has to change too.”

2. The processes that quietly stopped working

Fiona identifies several norms that “quietly stopped working” — they weren’t abolished, they just became subtly wrong:

Deep planning docs. When coding was expensive, you planned exhaustively to avoid building the wrong thing. Now most planning happens in PRs and prototypes. A prototype is cheap. A four-hour planning meeting is not.

Test-driven development as obligation. TDD felt like eating broccoli — virtuous but unpleasant. With Claude, Fiona found it actually enjoyable for the first time: write the failing test, verify it fails, fix the bug, done. “The tax got taken out of test-driven development.” But TDD-as-discipline for its own sake stopped mattering; what matters is that tests exist.

“Who wrote this?” When nearly every commit is co-authored by Claude, asking who wrote something is the wrong question. The right question is: what were you trying to achieve, and can Claude help you get the context you need now?

Serial code review. High-throughput codebases need different review strategies. The answer isn’t fewer reviews — it’s smarter routing. Claude Code’s code review handles style, obvious bugs, and spec-drift checks automatically. Human review focuses on risk tolerance, legal implications, and product taste.

3. Technical debates: code wins

“In technical debate, code wins. Building is cheap, arguing is expensive.”

When Fiona was onboarding and wanted to refactor the codebase, she and Boris had different approaches. Old instinct: book a meeting room and whiteboard. New approach: generate three different versions of the PR with Claude and use the actual implementations to have the debate.

The PR comparison serves two purposes: you see how each approach actually works, and you see how it affects colleagues — who needs to change their code, what API surface changes, what breaks.

Prototyping is now viable for things it wasn’t before. “With Claude, we can actually iterate and learn quickly, and then scale a prototype to production faster than we ever could.” The old concern — that prototype code becomes production code prematurely — is addressed by the model’s ability to clean up and scale what works.

4. Verification as the new bottleneck

“Throughput is up. That means we have to pay even more attention to: is it correct?”

When one engineer can produce what a team of five used to produce, the review and verification infrastructure has to scale proportionally. On the Claude Code team this shows up as:

• Shift-left automation: catching bugs closer to the source, not when users report them
• Claude Code code review: handles the routine review work automatically, surfaces only the genuinely risky decisions to humans
• Routines for feedback: Fiona has a morning routine that aggregates feedback from all channels, categorizes by theme, and surfaces potential regressions

5. Two engineer profiles that matter most

As roles blur, Fiona has narrowed what she looks for to two profiles:

Creative builders with product sense. People who have ideas, can prototype them, dog-food ruthlessly, and talk to customers. Product taste — knowing what’s right when you see it — is a judgment call that Claude can’t make for you. You build this muscle through dog-fooding and being close to users. “Feel it in your bones.”

Deep systems expertise. Understanding the platform at depth — performance characteristics, security properties, failure modes — remains valuable and hard to substitute. These engineers catch what others miss because they understand why the system behaves the way it does.

The note for managers: “This is a great time to get some maker hours back.” With Claude doing more of the day-to-day implementation, managers can stay close to the codebase without burdening their team with questions. Every manager on the Claude Code team starts as an IC first.

6. Knowledge sharing: code as source of truth

“When I onboarded to Claude Code, I did my first tech deep dive just with Claude. Claude is really good at answering all these questions I have.”

The shift: documentation is increasingly a lagging indicator. The code is the source of truth. If you have a spec, check it into the codebase as a skill file — that way it stays in the update loop when code changes. Docs that live outside the repo go stale.

Practical rule from the team: whatever you’d otherwise maintain as a wiki or Notion doc, ask first whether it can live as a skill or CLAUDE.md entry instead. Code-adjacent artifacts get updated when code changes; external docs don’t.

7. Proving it’s working

Fiona’s preferred metrics for whether AI-native practices are actually helping:

• Onboarding ramp-up time going down — time to first PR, questions needed from colleagues
• PR cycle time by stage — not just end-to-end, but broken out into queue time, review time, CI time. If overall cycle time isn’t improving, which stage is the new bottleneck?
• Claude-assisted commits going up — a directional indicator that the team is actually using the tools

For each workflow:
1. What bottleneck was this designed to address?
2. Does that bottleneck still exist?
3. Could Claude handle 80%+ of the work here?

Here is a list of our team's recurring processes:
[paste your list]

For each one:
- Identify what bottleneck it was designed to protect against
- Assess whether that bottleneck still exists given AI-assisted coding
- Rate whether Claude could handle 80%+ of the work (yes / partial / no)
- Suggest how to restructure it if yes or partial

Be specific. Name the bottleneck. Don't generalize.

Where to go next

• A Year of Claude Code — Boris and Cat on verification, auto mode, and routines from the product builders’ perspective
• Claude Code Best Practices — CLAUDE.md, skills, and hooks: the technical setup that makes these practices work
• Vibe Coding in Prod — how to responsibly ship AI-generated code to production with the right verification gates