The Developer Productivity Stack for an AI-First Team

A solo developer with a good AI workflow is fast. A team where every developer has their own idiosyncratic AI workflow is chaotic. The delta between the two is team-level convention: shared context files, agreed-on CLIs, predictable review loops, common guardrails.

This is the productivity stack I've seen work for AI-first teams of 3-15 developers. It's not a product pitch; it's a set of conventions that make the team more than the sum of its parts.

The problem with "let people use what they want"

The pro-autonomy instinct is good, usually. For AI tooling in 2026, it produces a specific failure mode: every developer has a slightly different CLI, config, and workflow, which means:

• Code review is harder because the reviewer doesn't have the same agent context.
• Onboarding is slower because there's no reference workflow.
• The best practices never propagate because nobody's doing the same thing.
• Costs vary wildly across developers for reasons nobody can explain.

The solution is not to mandate one tool. It's to standardize the things that benefit from standardization and leave the rest to personal taste.

What to standardize

Three things, in order of importance:

1. Context files. CLAUDE.md, AGENTS.md, skills — these are repo-level and should be consistent across the team.
2. The review loop. Who reviews what, what the acceptance criteria are, how AI-written PRs are flagged and triaged.
3. Guardrails. What the agent is allowed to do, what requires human approval, what's forbidden entirely.

What not to standardize:

• Which editor each developer uses.
• Which CLI each developer prefers for their implementer pane.
• The specific layout of each developer's grid.

The rule of thumb: if it affects the output code or the review process, standardize it. If it's about how a developer gets to the output, leave it alone.

Context files as the team's shared brain

The most underrated team-level investment is a good CLAUDE.md (and equivalents) at the repo root. It should include:

• A one-paragraph stack overview.
• A layout diagram of the main directories.
• Exact build/test/lint commands.
• Coding conventions (naming, error handling, imports).
• Security and privacy rules (what the agent must never touch).
• Pointers to project-specific skills.

This file pays for itself within a week. Every developer's agent reads it at session start. Every new hire's agent is immediately productive. Every AI-written PR is written in the house style because the agent knew the house style.

Update it when conventions change. Review it at sprint boundaries. Treat it like any other important repo-level artifact.

Team CLI conventions

You don't need to mandate one CLI, but you should agree on a shortlist. My recommendation for a small team:

• Primary: Claude Code (Opus for Driver, Sonnet for Implementer).
• Secondary: Codex CLI for implementer work.
• Tertiary: Qwen for backfill/test work.

See Claude vs Codex vs Qwen for the rationale. The 9 best AI coding CLIs covers the broader landscape.

Everyone uses at least the primary. The others are optional. This gives you a shared vocabulary ("I had Claude do this part") without forcing uniformity.

Shared spaces and layouts

If the team uses a grid terminal, having shared space templates is a surprisingly powerful convention. Example template: "backend-feature-work" — a 2x2 with specific CLIs and cwds pre-configured. A new developer joining a sprint clicks the template and is productive in 30 seconds.

SpaceSpider's spaces are exportable via the underlying JSON config, so this is straightforward. See the getting-started docs for the space model, and the grid layouts docs for the presets.

Not mandatory, but a strong default.

The AI-written PR convention

AI-written PRs should be labeled as such. Not to shame them — most PRs have some AI in them now — but so reviewers know to look for AI-specific failure modes.

What I flag in an AI-written PR vs a human one:

• Over-refactoring: did the agent change things it wasn't asked to change?
• Over-commenting: did the agent add comments that restate the code?
• Missing edge cases: did the agent handle the obvious path and skip the weird ones?
• Boilerplate drift: did the agent rewrite error handling in a style slightly different from the rest of the repo?

Reviewers should know which of these to scan for. Human-written PRs have different failure modes. Labeling the source helps reviewers calibrate.

Review loops with multi-model

For high-stakes PRs, running multi-model code review as a team convention is worth it. Three models on a diff catches issues that single reviewers miss, and the cost is modest compared to the cost of shipping bugs.

Convention: any PR touching payment, auth, or data retention gets a three-model review before merge. Any PR touching core infrastructure gets it. The rest is optional.

The multi-model code review use case has the specific setup.

Guardrails as a team contract

A short document in the repo — or in the CLAUDE.md — listing what agents are never allowed to do. Example:

• Never run git push unattended.
• Never modify src/auth/ without an engineer pairing.
• Never access production credentials.
• Never run rm -rf outside the current worktree.
• Never publish to npm/PyPI from an agent session.

These sound obvious. They're obvious until someone's agent does one of them at 3am because the guardrail wasn't written down. Write them down.

Cost visibility

If the team is expensing AI CLIs, cost visibility matters. Two conventions help:

• Monthly cost review, 15 minutes, comparing developer-level spend.
• A shared list of anti-patterns to avoid (e.g., "running Opus in the implementer pane").

Not a ranking, not a blame game — just awareness. Developers who see their own cost compared to the team median self-correct without managerial intervention.

For the optimization techniques, see cutting your AI coding bill in half.

Onboarding template

A specific artifact I recommend every team create: an "AI onboarding doc" for new hires. It covers:

• Install these CLIs, here are the account details.
• Here's the recommended space template.
• Here's the CLAUDE.md and where to find the per-subdir ones.
• Here's the guardrail list.
• Here's the cost expectation (rough monthly).
• Here's who to ask when you're stuck.

This cuts onboarding for AI tooling from "figure it out over two weeks" to "up and running on day one." Worth writing.

Anti-patterns that hurt teams

Patterns I've seen hurt AI-first teams:

• Tool evangelism: one developer insisting everyone else should use their CLI. Not useful.
• Skipping review on "trivial" AI PRs: they're not always trivial.
• Hidden skill hoarding: devs writing private skills/prompts that would help the team. Share them.
• Cost denial: not tracking spend until it's a problem.
• Sprawl of context files: five variants of CLAUDE.md at five paths. Consolidate.

Each is fixable with a convention. None fixes itself.

The productivity stack, summarized

Standardize the boxes marked "yes." Leave the rest alone. The team gets predictability where it helps and autonomy where it doesn't hurt.

Key takeaways

AI-first teams lose productivity not to missing tools but to missing conventions. Standardize the context files, the review loop, and the guardrails. Leave individual workflow choices alone. Share space templates and skills. Make cost visible.

The gains are multiplicative across the team. A senior developer's good habits, encoded in a CLAUDE.md and shared as skills, lifts every other developer on the team. That compound effect is the real productivity story — not any single tool or model. See agentic coding setup for the individual piece, and the parallel AI agents use case for the multi-pane pattern the whole team should be running.