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: learn the existing process

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. Compare the documented coverage with the checks that execute and the failures they can catch.
• 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.

Use week one to listen, read, and ship one small change through the existing process. Confirm approved tools, data-handling rules, and action permissions before using an assistant. Broader workflow changes can wait until you understand the team.

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 file gives assistants and new engineers the same starting point: commands, constraints, and links the team has checked.

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.

Writing the file can also expose conflicting assumptions. If engineers disagree about which tests run or which service is retired, resolve that discrepancy before encoding either answer as an instruction.

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.

Step 3 is the failure mode I watch most closely: accepting output without tracing its assumptions or reviewing its tests.

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, a recent PR should show what changed, what the reviewer checked, and what CI verified. Record assistant involvement where team policy requires it; the evidence standard applies to every change.

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.

By this stage, I would revise the team’s AI usage policy using the pilot evidence. Keep it short: approved tools and data, who owns a change, which actions need review, and how to report a mistake. The initial data and permission rules belong at the start of the pilot.

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

Failure modes I watch for

Three patterns deserve attention during the pilot.

Leadership asks for activity counts. Token use and assistant-assisted PR counts describe spend and adoption, but they do not establish value. Track review defects, rework, cycle time, and accepted outcomes by task type alongside cost. Choose a baseline before the pilot and report the limits of a small sample.

Experienced engineers do not participate in the pilot. Ask about their specific objections and invite them to review a small, relevant task. Their expertise can expose subtle errors, but participation should address a real need rather than become a loyalty test.

Authors cannot explain the changes they submit. This can happen at any experience level. Use review to trace a failure path, explain a test, or debug a case without generating another patch. Keep the conversation about understanding the system and supporting the author.

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.

The useful result is a practice the team can inspect and adjust when its tools or workload change.

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.