Rolling Junie out to a team without the chaos

Junie on one laptop is a productivity story. Junie across a team is a change to how your codebase gets written, and pretending otherwise is how the chaos starts. The failure mode is always the same: everyone gets a license, nobody agrees on conventions, and six weeks later the review queue is full of large, confident, subtly inconsistent diffs that nobody quite owns. None of that is the model's fault. It is a rollout problem, and rollout problems have playbooks.

The guidelines file is the team contract

The single most important artifact in the rollout is .junie/guidelines.md, checked into the repository. On a team it stops being personal configuration and becomes a shared contract for how the agent behaves in your codebase: same file, same behavior, every seat. Build and test commands, architectural conventions, directories the agent must not touch, what done means: that is what belongs in it. The team-level rule is simpler and non-negotiable: changes to the guidelines file go through pull-request review like any other code, because one line in that file now shapes every diff the agent produces for everyone.

Decide the autonomy policy centrally while you are at it. Whether Brave mode is acceptable, and for which commands, is a team decision, not a per-developer mood.

One review bar, no asterisks

Set the second norm before the first agent diff lands: an agent-assisted PR meets exactly the same bar as a hand-written one, and the human who opened it owns every line. The moment Junie wrote that part becomes an acceptable answer in review, you have created a class of code nobody is responsible for. Reviewing AI-heavy changes has its own mechanics, but the cultural rule outweighs any tooling. It cuts both ways, too. Reviewers do not get to wave agent diffs through because they look plausible, which is precisely the trap plausible output is built to spring.

• Cap the diff, not the tool. Review fatigue arrives with large diffs, so keep agent tasks scoped small enough that the output fits inside one reviewer's attention span.
• Disclose by convention, not surveillance. A PR label for agent-heavy changes helps reviewers calibrate. Policing authorship line by line is wasted effort when the bar is identical anyway.

Skipping shared conventions does not save their cost — it moves the cost into code review, with interest.

Start narrow, measure like you mean it

Do not launch with use it for everything. Pick task types where the agent is strong and verification is cheap: test backfills for existing code, mechanical refactors, boilerplate endpoints, dependency bumps. Keep architecture, auth, and anything security-sensitive human-first for the first quarter. The team builds a shared sense of where the tool is trustworthy before anyone stretches it.

Then measure something beyond vibes, because vibes after a tool rollout are reliably positive and reliably useless. You will not get a clean experiment. Attribution is genuinely hard here, and anyone promising a precise productivity percentage is selling something. But you can watch numbers you already track: cycle time on the chosen task types, revert and rework rates on agent-assisted PRs, review turnaround, drift in PR size. Re-survey the team after a month, and pay attention to one question above all: which tasks have people stopped doing by hand?

Rolled out this way, Junie turns into boring infrastructure within a couple of months. That's the goal. The judgement I will defend: invest in the guidelines file and the review norm before you buy a single additional seat. A team with shared conventions gets a fleet of agents pulling in one direction. A team without them gets ten talented strangers pushing code into the same repository.