Is Alignment all you need in AI-native Team?

TL;DR: The bottleneck in an AI-native team is alignment: between people, between people and their agents, and between the agents themselves. The models had more capability than we could use, and keeping those three layers in sync ate most of the gain. The fix is to write down the rules, rubrics, and boundaries that everyone, human or agent, works against, starting on day one.

I learned this over the past year, leading a few AI-native teams that build products. The largest had 10 people, each working with their own agent. The hardest part of the year was organizing people, agents, and the system into one team that kept getting faster.

Here's what I'd tell anyone starting an AI-native team, in the order this post covers it:

1. Align on three layers. Person to person, person to agent, and agent to agent. The two new layers cost the most.
2. Organize around three roles. Contextualists direct agents, Judges define what good means, and an Architect runs the team's agents as one system.
3. Run the AI before the meeting. Most stalls come from missing information, and AI fills that gap faster than a discussion.
4. Set up four things on day one. A model per task, evals, prompt tuning, and staging.
5. Write every doc twice. One version for people, one for agents.
6. Fix three failure modes with rules. Prompt bloat, unreviewable PRs, and compounding debt each have a rule that prevents them.
7. Next: let agents work while people sleep. Remote, throwaway environments turn people into reviewers.

Align on three layers

An AI-native team has to align on three layers, and the two new ones are where the cost hides. A traditional team only has the first:

• Person ↔ person. Goals, priorities, who decides, what "done" means, who's waiting on whom. When this fails, everyone works alone and PRs get redone.
• Person ↔ agent. The rules in your head go on the page as specs, boundaries, formats, and rubrics, concrete enough to execute and to measure. It's the PM–engineer relationship with an engineer who forgets yesterday's meeting. When this fails, the agent's output looks right and turns out unusable.
• Agent ↔ agent. Every agent works against the same interfaces and the same definition of quality: shared schemas, shared rubrics. When this fails, each piece optimizes for itself and the system drifts apart. Unit tests pass while the whole thing doesn't run, eval scores rise while the experience gets worse, and the repo becomes hard for a person to maintain.

The fix is to write the agent layer down on day one. Put the project's rules into the repo's CLAUDE.md and AGENTS.md: behavior norms, naming conventions, a commit template, a cap on PR size. Those files are the agents' team onboarding doc.

At the start of my last project I wrote a collaboration guideline for the team, and most of what was in it, like how to name branches, was really meant for the agents. I never wrote the agent version. So every person trained their own agent with its own habits, style drifted from PR to PR, and tech debt piled up far faster than it had on the project before.

Half of your team guideline is an agent guideline. Write that half where the agents will read it.

Organize around three roles

Split an AI-native team into three roles: Contextualists, Judges, and an Architect. Splitting by module is slow, because modules overlap and depend on each other, and lining them up and stitching them together is exactly the work agents do best. People can hand that layer to the agents.

The Architect is the role most teams are missing. Even if every person runs just one agent, the team as a whole is a multi-agent system. Someone has to keep tuning its habits and writing the rules that slow down tech debt.

The mix is uneven. Judges are always scarce, because the job takes deep domain knowledge. One senior Architect per team is enough, and a team without one slowly bogs down. Contextualists grow with the size of the project.

Judges and Contextualists work like a red team and a blue team: one builds, the other attacks, and both make the system stronger.

My last team split by module: retrieval, then evals, then citations. Retrieval and citation kept running into each other, and by the end the team still felt slow.

Run the AI before the meeting

When the team is stuck, have the AI lay out the options before anyone meets. Most decisions stall because nobody has enough information yet, and AI widens the options faster than people can.

The loop is simple: the AI expands the set of options, people look, repeat. It ends on one of four signals:

1. Taste threshold. Someone says, "OK, now I have a strong preference." The signal comes from a person.
2. Information saturation. The options the AI comes back with all look alike. No new tradeoffs show up.
3. Cost ceiling. One more round is worth less than the time it takes. An economic signal.
4. Time pressure. An outside deadline forces the call. A structural signal.

Whether you need the loop at all depends on two questions: how well does the team understand the problem, and how costly is the decision to undo?

On my last team, roughly 80% of our stalls happened in one box: decisions that were cheap to reverse, facing people who felt they didn't understand the problem yet. Those decisions only needed the AI to draft a few versions for someone to pick from. We held meetings about them and treated them like expensive, permanent calls.

The rule I'd add to every team's meeting norms: if you're stuck for more than five minutes, run it through the AI first.

How far the loop can take you comes down to taste: knowing what good looks like.

Set up four things on day one

Four things belong in place on day one. On my last team many of them only arrived in month three, and that delay is my biggest regret from the project.

1. A model per task. Each task trades off speed, cost, and quality differently, so pick the model to match. We only started doing this in the second half of the project, and we burned a lot of inference budget before that.
2. Observability and evals. Optimizing without evals is gambling. We put a lot of work into tuning retrieval and got little for it, because we had no eval baseline we trusted, so every "looks better" was anecdotal. Next time I'd pick an existing tool: Braintrust for a mature commercial product with good CI/CD integration, or DeepEval for open source (think pytest for LLMs).
3. Prompt tuning. It's still the highest-ROI optimization there is, well ahead of tuning retrieval parameters. Set up an auto-research loop that iterates on the prompt for you.
4. Staging and production. Once the team is bigger than two people, you need both. Staging is where features get tested together and evals have to pass, or the change rolls back. Production gets one release per one-week cycle. Adding this late is painful, because by then the code assumes a single environment.

Write every doc twice

Every feature needs two docs, one for people and one for agents, because each reader needs different things:

Agents need every piece of context spelled out. An agent can't follow "this continues the decision we made last time," because it has no last time. Context that stays unwritten gets explained again at the next meeting.

All of this depends on writing things down in the first place, since AI can only use what's been put into words. Granola for meeting notes and Linear for issues did a lot of that work for us.

Fix three failure modes with rules

Three failure modes kept coming back, and each one has a simple rule that prevents it.

• Prompt bloat. CLAUDE.md and the system prompt keep growing. Every rule has a good reason to be there, and the whole thing works worse. The fix: refactor the prompt on a schedule, and make deleting rules part of the exercise. Less is more.
• Unreviewable PRs. A 1,000-line AI-generated PR is close to impossible for a person to review well. The fix: a hard cap on diff size, around 400 lines per PR, and anything bigger gets split. The Architect enforces it with a hook in CI.
• Compounding debt. AI writes code fast, so every PR becomes "merge it now, clean it up later." Three months in, nobody can explain why a module looks the way it does. The fix: reserve 20% of every sprint for cutting AI code. Have the agents merge duplicate modules and delete what nobody uses.

Next: let agents work while people sleep

On the next project I want agents to keep working after people log off. Today the bottleneck on iteration speed is a person watching an agent, and the goal is to make "the person sleeps, the agent works" the default. I haven't tested this yet.

The plan is remote development, something like GitHub Codespaces: one remote repo, many worktrees and branches, and many agents running in the cloud.

• Environments are throwaway. Every task gets a clean sandbox, so a messy local setup stops mattering. We never found a clean way to share environments.
• People become reviewers. Your job is to open a preview link or a PR and judge what the agent built.
• Async all the way. Send the instruction and walk away. The agent runs the integration tests in the cloud, and you check the results the next morning. One person can run many agents at once.

Write it down first

Everything that slowed my team down traces back to something we could have written down on day one: a rubric, a schema, a boundary, a rule for the agents.

Agents make building cheap, so the cost moves to agreeing on what to build and what good means. I made the same argument about trials in From n to p: once trials are free, the edge goes to the taste that makes each one land. A team works the same way. Any team can spin up ten agents now, and the ones that move fast are the ones whose agents all read the same written-down picture of good.

So write it down first. Then let the agents run.