The First 90 Days: Introducing AI-Assisted Dev to a New Team

A lot of "AI adoption" posts are written as if the hard part is choosing a tool. In my experience, the tool is close to the cheapest decision you'll make. The hard part is introducing a practice onto a team that already has a way of working, under deadline pressure, with people whose opinions about AI range from "this is the future" to "this is how I lose my job."

This is the short version of how I would approach it if I were joining a new team tomorrow.

It is not a playbook — the AI-Assisted Dev Adoption Loop is the playbook. This is the narrative version. What I would actually try to accomplish in week one, month one, and quarter one, and what I would be careful not to touch until I had earned the right.

TL;DR

• Do not try to change the team in week one. Change the repo. Start with an AGENTS.md (or CLAUDE.md) that reflects how the team actually works today, and let the tooling catch up to that — not the other way around.
• The first month is about making the loop visible. Gates in CI, hooks pre-commit, session memory, and a single opinionated set of skills. Visibility before optimization.
• By the end of the quarter, the conversation should shift from "which assistant" to "which classes of work are we routing to assistants, and are we getting sharper or duller at the rest." That is the real metric.
• Three things will try to kill the rollout: leadership demanding metrics that do not measure the right thing, senior engineers quietly opting out, and the silent erosion of judgment on the juniors. Plan for each.

Week one: do not touch the code

The first week is about one thing: understanding how the team already works. Not what the process diagram says. What actually happens.

I'd spend the first week doing the work a new engineer would do: pick up a real ticket, ship it, review someone else's PR, sit through a standup, watch a deploy, read an incident postmortem. Then I'd write down what I observed about:

• How the team makes decisions. Slack threads? Design docs? "Ask Jamie"? Every team is different, and AI assistants amplify whichever one you already have.
• What the team's tests actually prove. Not what they claim to prove. There is always a gap, and it is always load-bearing.
• Where the institutional knowledge lives. In senior engineers' heads, in a wiki, in the code itself, in a specific Slack channel. AI assistants are merciless about surfacing this gap.
• What the team's biggest source of churn is. Dependency upgrades? Flaky tests? Manual release steps? PR review latency? This is probably the first thing you'll want AI to help with.

No changes in week one. Listen, read, ship one small thing. Do not announce an "AI initiative." Do not schedule a workshop. Do not write a policy document.

The deliverable from week one is a two-page memo, for yourself, titled something like "How this team actually works." Nobody else has to read it. You have to write it.

Weeks two and three: write AGENTS.md

Now the first real change, and it is deliberately unglamorous.

Write an AGENTS.md (or CLAUDE.md, or the equivalent for your primary assistant) at the root of the main repo. It does one thing: it tells any assistant that opens this repo what the team already does.

Not what you want the team to do. What the team already does.

Concretely:

• The build commands that actually work on this repo. make test, not "run the tests."
• The branch naming and PR title conventions the team uses, even if they are not written down.
• The services and directories, with one sentence each.
• Hard rules the team has learned. "Never edit the generated GraphQL schema by hand." "Do not touch the payment routing tests without pairing with Alex."
• Where to find the docs that do exist, in order of trustworthiness.

This is a boring artifact, and it is the highest-leverage thing you will do in your first month.

Two reasons.

First, every engineer on the team now has a consistent experience when their assistant opens the repo. The lived knowledge that used to be "ask Alex" becomes visible. Nobody had to sit through a meeting.

Second, and more importantly, writing this file is a forcing function for the conversation nobody was having. You will discover that three engineers have three different stories about how testing works. You will discover that two services have been deprecated but still have CI jobs running. You will discover something embarrassing. Every time.

That discovery is the real product. The file is the artifact that causes the conversation.

Through this period, do not roll out anything new. Do not buy tools. Do not push for a new assistant. You are just writing down what is already true.

Weeks four through eight: make the loop visible

Now you can add machinery. And the machinery has one job: making the loop visible.

The loop is always the same shape:

1. An engineer describes a change, usually in a ticket or a PR.
2. An assistant helps draft, investigate, or scaffold.
3. The engineer reviews, adjusts, and ships.
4. CI verifies.
5. Production proves out over time.

Most rollouts fail at step 3. The engineer trusts the output, ships, and the loop never closed.

The machinery that closes it is the unglamorous stuff:

• Pre-commit hooks that format and lint. The assistant should never be the reason the diff looks weird.
• CI gates on typecheck and tests that cannot be skipped. If an engineer has to ask whether the PR passes CI, CI is not doing its job.
• A small set of named skills (commit, review, investigate, refactor) that encode how this team ships. Not a generic set imported from the internet.
• Persistent memory so that sessions do not start from scratch every time. A decision recorded yesterday should show up today.
• A rule that every PR description says what changed, why, and how it was verified. Assistants are excellent at generating these. Make the quality of the description a gate.

You are not trying to get engineers to use the assistant more. You are trying to make sure that when they do, the work shows up in a legible, inspectable form.

At the end of this period, you should be able to open any recent PR and tell, without asking, whether an assistant was involved and whether the engineer reviewed the output carefully. If you cannot, the loop is still open.

Weeks nine through twelve: the real conversation

Now you have earned the right to have the conversation that everyone wanted to have on day one: which tool, which model, how do we measure adoption, what is the policy.

The reason you waited is simple. Those conversations, held on day one, are vibes-based. Held at week ten, they are grounded in what you actually observed.

At this point you can say, specifically:

• Here are the three classes of work we have routed to assistants by default: scaffolding new services, writing tests for existing code, updating dependencies. Here is the acceptance rate for each.
• Here are the two classes we have explicitly kept human: anything touching the patient-matching rules, anything changing payment routing. Here is why.
• Here is the assistant we've standardized on, and here is the one we're piloting in the data team because they have a legitimate reason to be different.
• Here is what we've spent, and here is the slice of work it has absorbed.

None of that is a slideware pitch. It is a short written report with numbers. Leadership will disagree with some of it, and the disagreement will be productive because there is something concrete to disagree with.

This is also the point where I would push to publish a short AI usage policy — not as a legal document, but as the team's own statement of how it works with assistants. It should fit on one page. It should be boring. It should say things like "we always write a description of what changed, human-owned," and "we do not paste production data into prompts," and "we review every change the same way whether an assistant drafted it or not."

The purpose of the policy is to make the invisible explicit. If it is controversial, you had a different problem than you thought.

What almost always goes wrong

Three failure modes, in rough order of how often I see them.

Leadership demands the wrong metrics. "How many tokens are we using?" "How many PRs did AI help with?" These are easy to count and meaningless. The durable metrics are softer: which classes of work are shifting, are we finding more or fewer bugs in review, is engineer judgment compounding or eroding. The ask, respectfully, is to wait eight weeks before committing to metrics. If leadership insists sooner, give them the numbers they asked for and also the numbers that matter, with a footnote explaining why the second set is the one to trust.

Senior engineers quietly opt out. This is the most dangerous failure, because it is invisible. A senior engineer who has decided the assistant is not for them will continue shipping excellent work. But the team loses the feedback — the only person who could have told you "this output is subtly wrong" is not looking at it. The fix is cultural and personal: find the senior engineers' specific objections (usually reasonable) and build the rollout around them. Not against them, around them. If they say "I do not trust the output on architecture decisions," that is a useful constraint — agree, write it into the policy.

Silent erosion of judgment on juniors. The juniors are delighted with the assistant. They are shipping faster. They look great. And they cannot tell, increasingly, when the assistant is wrong. This is the failure mode I worry about most, and it has the least satisfying fix. The fix is that seniors have to review junior PRs more carefully during the rollout, not less, and the review has to sometimes be "walk me through this as if you had written it yourself, because next time you might have to." Some people will find this paternalistic. It is still the fix.

What this looks like at the end of a quarter

If it goes well, you will have:

• An AGENTS.md that reflects the team as it is, updated when things change.
• Gates, hooks, and skills that are boring and reliable.
• A short written report on which classes of work have moved, with numbers.
• A one-page team policy on assistant use, written by the team.
• Three to five stories of "the assistant saved us a day" and two to three stories of "the assistant would have shipped a bug if we had not caught it." You want both kinds.
• A practice that survives the next quarter's platform migration, model swap, or reorg, because it was never about the tool.

This is the part nobody puts in slides, because it is unexciting. That's the point. A reliable practice is always unexciting.

Where to go next

If you want the structured version with phases, gates, and evidence, the AI-Assisted Dev Adoption Loop is the playbook this post is a narrative summary of.

If you want the broader perspective that informs the whole approach, the six principles are the durable ideas the playbook operationalizes. The short version: explicit loops beat vibes, evidence beats preference, warnings beat errors, one config generates many surfaces, contracts turn plausibility into correctness, and GitOps is the boring substrate you want.

And if you're reading this because you are specifically trying to figure out how to make this case inside a team that has not bought in yet — the honest answer is that you cannot argue your way into buy-in on day one. You can earn it by week four, and by week twelve you will be having a much better version of the conversation you wanted to have on day one. The work of the first ninety days is building the ground to stand on.