How AI Teams Ship Fast and Break Ground
In Speed is the Last Moat, I argued that velocity is no longer optional. In the AI era, teams that ship faster compound learning, capture markets, and outlast competitors.
That argument stands.
But speed alone is not enough.
AI-native teams are not just building features. They are discovering how to use models, prompts, embeddings, and retrieval systems in ways that did not exist before. That discovery work looks like research — even when you are not training new foundation models.
The mistake leaders make is treating this as a binary choice:
- Either you ship fast
- Or you do research
That framing is wrong.
High-performing AI teams do both, deliberately, inside the same organization — inside the same team! The boundary between dev and R&D teams might not need to exist anymore.
AI Work Has Two Modes — Not Two Teams
Rule: AI teams operate in execution mode and discovery mode, often in the same week.
Most AI work today sits in a hybrid space:
- Prompt engineering that changes model behavior
- Embedding strategies that alter retrieval quality
- Chunking, indexing, scoring, re-ranking experiments
- Evaluation frameworks that redefine “quality”
- Discovering many other possibilities for input and output formatting, optimizing, and guard-railing.
These are not pure engineering tasks.
They are not academic research either.
They are applied discovery — and they require a different operating rhythm without abandoning speed.
The 75/25 Reality
Rule: Most AI teams are ~75% development, ~25% discovery.
75% of the time, you are:
- Shipping endpoints
- Improving latency
- Wiring pipelines
- Integrating models
- Hardening systems
25% of the time, you are:
- Testing new prompt structures
- Exploring retrieval strategies
- Stress-testing embeddings
- Discovering failure modes
- Reframing the problem
Trying to force that 25% into the same delivery mechanics as the 75% is where teams break.
One Team, Two Operating Modes
Rule: Do not split teams — split modes.
The same engineers should be capable of both shipping and discovery. The difference is how the work is framed and measured.
Execution Mode
- Goal: predictable progress
- Unit of value: shipped capability
- Rhythm: short cycles
- Metrics: lead time, failure rate, MTTR
- Artifacts: code, tests, deploys
Discovery Mode
- Goal: reduce uncertainty
- Unit of value: insight
- Rhythm: focused exploration blocks
- Metrics: hypotheses tested, uncertainty reduced
- Artifacts: findings, comparisons, evaluations
Switch modes intentionally. Do not blur them accidentally.
Discovery Without Derailing Velocity
Rule: Discovery must be time-boxed, not output-boxed.
In AI teams, discovery often looks like:
- “Why does this prompt fail on edge cases?”
- “Why does retrieval collapse for long-tail queries?”
- “Why does accuracy improve offline but regress online?”
These are not bugs. They are system-level questions.
Run discovery in short, explicit windows:
- 3–15 days
- Clear hypothesis at the start
- Clear learnings at the end
The output is not a feature.
The output is clarity.
Ship the Learning, Not Just the Code
Rule: In AI systems, learning is a first-class deliverable.
A discovery that proves what does not work is valuable if it:
- Prevents repeated mistakes
- Narrows the search space
- Informs future designs
Require every discovery window to produce:
- A short written summary
- A comparison table
- An evaluation result
- A recommendation
This turns research into organizational memory, not tribal knowledge.
Prompting and Retrieval Are Research
Rule: Treat prompting, embeddings, and retrieval as research surfaces.
When you are:
- Designing multi-step prompts
- Balancing recall vs precision in vector search
- Choosing chunking strategies
- Combining lexical + semantic retrieval
- Defining relevance metrics
You are doing research — even if no paper is written.
The mistake is pretending this is “just engineering” and demanding deterministic estimates for inherently exploratory work.
Protect the System While Exploring It
Rule: Never experiment directly on the production path.
AI discovery must run behind:
- Feature flags
- Shadow traffic
- Offline evals
- Controlled A/B tests
This is how you explore aggressively without slowing delivery.
Speed and safety are not opposites — they are coupled.
Leadership’s Real Job
The biggest failure mode is not technical.
It is leadership forcing one mental model onto all work.
Leaders must:
- Know when the team is exploring vs executing
- Ask different questions in each mode
- Reward learning, not just shipping
- Resist the urge to demand certainty too early
If every conversation starts with “When will this be done?”, discovery dies quietly.
The AI-Team Operating Heuristic
Here is the rule that keeps both engines running:
If a team can ship weekly and explain what they learned this week, it is operating correctly.
If it can only ship — it will plateau.
If it can only learn — it will drift.
The AI era rewards teams that do both, deliberately.
What the Right AI Team Actually Looks Like
Speed and breakthroughs don’t come from roles on paper.
They come from how cognitive load and risk are distributed across people.
A high-performing AI team is not homogeneous. It is deliberately asymmetric.
The Practical Split
For most AI-native teams doing real work (not publishing papers, not training foundation models), the optimal shape looks like this:
- 50–60% Execution Engineers
- 20–30% Hybrid Engineer-Researchers
- 10–20% Deep Researchers / Explorers
Trying to flatten this into “everyone does everything” is a mistake.
Trying to isolate researchers into a separate ivory tower is also a mistake.
1. Execution Engineers (≈ 50–60%)
These are the throughput engine.
What They Are Good At
- Turning ideas into production systems
- Wiring models into pipelines
- Building APIs, infra, observability, eval harnesses
- Making systems reliable, fast, and operable
They thrive in Execution Mode.
What They Are Not Optimized For
- Open-ended hypothesis exploration
- Long stretches without visible output
- Ambiguous success criteria
And that’s fine.
Why They Matter
Breakthroughs are worthless if they can’t be shipped.
Execution engineers turn fragile insights into durable capability.
2. Hybrid Engineer-Researchers (≈ 20–30%)
These are the keystone role in AI teams.
If you only remember one thing from this section, remember this:
Hybrid engineers are the difference between AI demos and AI systems.
What They Are Good At
- Moving fluidly between discovery and execution
- Translating vague insights into testable designs
- Debugging model behavior and system behavior
- Designing prompts, retrieval logic, evals, and then shipping them
They are comfortable saying:
- “We don’t know yet”
- “This failed, but here’s why”
- “This insight is ready to harden”
Why They Are Rare
They require:
- Strong engineering fundamentals
- Curiosity and patience for ambiguity
- Taste — knowing when to stop exploring and start shipping
These people carry disproportionate leverage.
How to Use Them
- Let them lead Discovery Mode
- Pair them with execution engineers during integration
- Never drown them in ticket churn
They are the bridge, not the bottleneck.
3. Deep Researchers / Explorers (≈ 10–20%)
These are uncertainty reducers.
Not academics chasing publications — but people who:
- Sit with hard problems longer than most
- Explore unconventional angles
- Are okay being wrong repeatedly
- Generate conceptual breakthroughs that others wouldn’t reach
What They Are Good At
- Reframing the problem itself
- Discovering non-obvious failure modes
- Questioning assumptions embedded in the system
- Thinking several steps ahead of the current architecture
What They Should Not Be Asked to Do
- Ship weekly features
- Commit to sprint estimates
- Optimize for short-term velocity
That pressure collapses their value.
How They Add Value
They expand the solution space so the rest of the team doesn’t optimize inside a local maximum.
Why This Mix Works
- Execution engineers keep velocity high
- Researchers push the frontier outward
- Hybrid engineers prevent drift and prevent chaos
Remove any one group and the system degrades:
- No execution → insights rot
- No research → stagnation
- No hybrids → constant translation friction
This balance is not about titles.
It’s about cognitive load allocation.
A Hiring Rule That Actually Works
Instead of asking:
“Is this person an engineer or a researcher?”
Ask:
“Where do they add the most signal under uncertainty?”
Then staff accordingly.
The Team-Level Litmus Test
A correctly composed AI team can answer both questions every week:
- What did we ship?
- What did we learn?
If one of those answers is consistently empty, the team shape — not the people — is wrong.
Closing Thought
Speed is still the moat and will remain so for the foreseeable future.
But learning is the compounding engine underneath it.
Teams that ship fast and learn faster will not just outpace competitors — they will redefine the problem space itself.
That is what AI-native excellence looks like.
Originally published on Medium.