Most IT teams already use AI coding assistants, usually one person at a time, each in their own way. Whether that helps depends less on the tool than on how the team introduces it. With my own DevOps team and a client's whole IT department, operations and development included, I tried several approaches, and ran into several pitfalls, before we found a way of working that lasts. This article does not describe that method. It collects lessons that are publicly documented: well-known examples of what goes wrong, and of what works.
What goes wrong
The assistant has more access than it should
In July 2025, an AI agent on the Replit platform deleted a live database during a code freeze (Fortune). Replit's CEO called it "unacceptable and should never be possible" and started separating development and production databases automatically (The Register).
The lesson: a code freeze that exists only in the instructions is not a freeze. What the assistant must not touch has to be out of its reach, through permissions and separate environments, with backups and a tested way back.
The tools themselves become an attack path
Also in July 2025, a release of the Amazon Q Developer extension for VS Code contained malicious code. An attacker had used a GitHub token with too broad permissions to commit it to the extension's repository, and it was included in a release automatically; it failed to run only because of a syntax error (AWS security bulletin). The injected instruction told the agent to clean the system "to a near-factory state and delete file-system and cloud resources" (404 Media).
A second path is the content the assistant reads. In May 2025, Invariant Labs showed how a malicious issue in a public GitHub repository could make an agent leak data from private repositories, and noted that many users approve tool calls with "Always Allow" and stop watching (Invariant Labs).
The lesson: AI tools, their extensions and their MCP servers are part of your software supply chain. Install them like any other dependency, give them the least access that works, and keep a person approving what matters.
Company data in personal tools
In 2023, Samsung restricted the use of generative AI on company devices after staff had uploaded sensitive source code to a public chatbot (TechCrunch). The situation is still common: in the 2026 Stack Overflow survey, AI use is optional and left to the individual for 30% of developers, and only 24% report approved tools and guidance (Stack Overflow Developer Survey 2026).
The lesson: decide which tool, which plan and which data before people find their own way.
Suggestions nobody checks
Assistants produce code that looks right. A study presented at USENIX Security 2025 found that, on average, at least 5.2% of the packages suggested by commercial models and 21.7% of those suggested by open-source models did not exist (Spracklen et al.), which attackers can exploit by publishing packages under those names. In the 2025 Stack Overflow survey, the most common frustration, cited by 66% of developers, was "AI solutions that are almost right, but not quite" (Stack Overflow Developer Survey 2025).
Feeling faster is not the same as being faster
In a controlled study in early 2025, experienced open-source developers took 19% longer with AI tools, although they had expected to be 24% faster and still believed afterwards that they had been 20% faster (METR). METR itself now considers it likely that developers are faster with today's tools (METR, 2026). The point that remains is the gap between impression and measurement: in that study, the developers overestimated the effect of AI on their time by about 40 percentage points, and METR's 2026 survey of self-reported gains still cites this as a reason for caution (METR survey).
What works
Review stays with people
At Google, 75% of all new code is now generated by AI and approved by engineers (Google). The order matters: generated, then reviewed. Passing tests is not enough on its own: METR found that roughly half of the AI-generated changes that passed the tests of a widely used benchmark would not have been merged by the projects' maintainers (METR).
Context that is written down
Anthropic describes how its own teams work with Claude Code: they document workflows, tools and expectations in CLAUDE.md files, commit their work regularly so changes can be rolled back, and the security team has Claude Code explain Terraform plans before an infrastructure change (Anthropic, PDF). A CLAUDE.md file committed to the repository gives the whole team the same project instructions (Claude Code docs).
Rules the tool enforces
Instructions are context, not enforcement. Claude Code has three layers for that, all of which can be committed to the repository:
- Permission rules decide what the assistant may do without asking, what needs a confirmation and what is never allowed; deny rules always win (permissions).
- Hooks run at fixed points, for example a formatter and the linter after every edit, and always run, whatever the model decides (hooks).
- The sandbox restricts the files and network destinations that shell commands can reach at operating-system level (sandboxing).
Well-defined tasks with automatic checks
Airbnb migrated nearly 3,500 test files to a new testing library with the help of AI in six weeks; by hand, it had estimated a year and a half. Each file moved to the next step only after the previous one had passed its checks; the files the automation could not finish were fixed by hand (Airbnb). The success came from the checks around the model as much as from the model.
Training on the team's own work
General courses are forgotten quickly. What sticks is practice on the team's own repositories, pipelines and incidents, with the same rules for data and review that apply afterwards. In the EU, the AI Act also requires organisations that use AI to support their staff's AI literacy (EUR-Lex).
A rollout that lasts
- Choose the tool and the plan, and agree which data may go into it, before the wider rollout.
- Start with a small pilot group, as Anthropic also recommends (Claude Code docs), and one or two repositories.
- Commit the shared instructions, permission rules and hooks to the repositories.
- Give the assistant no more access than a new colleague: no production credentials, separate environments, approvals for what matters.
- Keep the review and the tests as they are, and train each team on its own tasks.
- After a few weeks, measure on your own work instead of relying on impressions.
Where I can help
I introduce Claude Code in IT teams, in development, operations and DevOps: the setup, the rules for access, data and review, and hands-on training on the team's own tasks. I have been through such an introduction in practice, with my own DevOps team and across a client's IT department.