Coding agent adoption beyond the first few teams

Choices made at the start of a rollout are hard to change later. They include which repositories and types of work come first, how agents work with your tools and your CI, and the rules for their use. They also cover who has access and which budget carries the cost. We agree on each one with the leads of your engineering teams before the first agent is enabled.

Agents also need a setup inside every repository they work in. We build it as part of harness engineering.

The pilot runs in a single team or a small group of teams, on tasks that look like their normal work. Human review and your automated checks remain exactly as before. More autonomy for agents follows only where the pilot's results support it.

If tools or models need to be compared during the pilot, we run an evaluation on work your teams have merged.

We check every repository against the points below before agents start work in it. Where some are missing, engineers work with agents interactively. Unattended work begins only when all of them are met.

• One command builds and tests a fresh checkout
• Tests need no manual preparation and fail only when something is actually broken
• The conventions that reviewers insist on are documented
• The repository's agent configuration has an owner
• Neither the repository nor the agent's environment contains secrets
• Reviewers can take on more pull requests

Training takes place in your engineers' everyday repositories, using the tools you selected. Most of the time is spent on scoping a task, deciding what context the agent needs and reviewing what it returns.

From then on, your platform team runs the rollout without us. On request, we meet once a month to go through recent changes to the tools and models.

Devin's cloud agent takes on a task in a remote environment of its own and delivers the result as a pull request. The first thing to settle is what work can be described in writing and checked once it is done. Typical candidates are test coverage, migrations, maintenance updates and backlog items with a clear description. For each of them, a reviewer needs completion criteria that can be verified without retracing the session.

Ahead of a pilot, we make sure the repository comes up the same way every time in Devin's environment. That covers its dependencies, test data and services, and the commands that build it and run its tests. Playbooks store reusable task prompts and keep a history of their versions. Project conventions go into Skills and the repository instructions, and we keep them out of the Playbooks. Devin Desktop, formerly Windsurf, is an editor that runs locally as a separate execution context. If handoff is part of your plan, you can pass a local session on to the cloud, and we test what comes across before any team depends on it.

Tasks reach Devin through your usual issue intake, and its pull requests follow your existing process. They face the same branch protection as anyone else's, and a person reviews every one of them. With security profiles, you can restrict access to git, MCP and the network. Your plan determines which of these controls you have, so we check that before we rely on any of them. In the pilot, each type of task runs more than once. Across those runs, we count how many reviewed pull requests were accepted and track operating cost, review time and rework. The report covers only what your own pilot measured. Productivity figures from the vendor are left out.

• Task types and their completion criteria, decided before anything is delegated
• A named owner for each Playbook and for the repository instructions
• Reviewers and merge owners assigned by name, plus a way to escalate when a run is blocked

Harness setup for delegated environments · Evaluating a change to your workflow · Devin's documentation on local-to-cloud handoff

Some tools, Kilo among them, leave the choice of provider and model to each engineer. Decisions that other tools take on your behalf then become part of your rollout. Someone needs to own the list of approved providers and models, and the keys or the gateway accounts. There also has to be an owner for the decision when a model nobody has tested yet appears in the picker. We agree on these owners and a route for exceptions during the pilot. Teams are enabled with the shared configuration rather than personal setups. Harness engineering covers the configuration itself.

Setting up Kilo

Coding tools move fast, and now and then a change means you have to migrate. Google has moved Gemini CLI over to Antigravity CLI. Since 18 June 2026, its consumer plans no longer include Gemini CLI, but licences for Gemini Code Assist Standard and Enterprise have kept their access. On 30 April 2027, AWS will stop supporting the IDE plugins for Amazon Q Developer, and it directs users to Kiro. Windsurf has become Devin Desktop.

We handle a migration like a small rollout. Wherever both tools read AGENTS.md, the shared instructions move there. We map model access and permissions onto the new tool and rerun the pilot's acceptance tasks. We also check how the switch changes your bill, and only then is the old tool turned off.

Testing a new tool before you switch · Google's announcement about Gemini CLI and Antigravity CLI · The AWS end-of-support notice for Amazon Q Developer IDE plugins

• Which teams give agents real work, and what kind of work that is
• Review effort and rework on pull requests from agents, set against the level before the rollout
• The cost of the rollout for each accepted change