The situation
Since April 2026 I've been the AI Adoption Leader for Claude Code at Intarget: I decide who gets access, I train people and I answer for costs and benefits. If it were up to me, I'd give Claude Code to everyone. Switching it on, though, solves nothing by itself. The real risk is scaling the mistakes, doing the same wrong things twice as many times a day.
What I did
I turned access into a path. Every interview ends with a real task, its inputs, what success means, who can judge it and when we'll talk again. In the follow-ups I ask about the last thing shipped, how the quality looks and where they need a hand. I put the working rules in a shared repository, written for people and above all for the agent, so Claude Code finds them every time it starts.
Every week there's the Generative AI Lab. Andrea Zennaro prepares and runs it, I handle the technical side, give the demos and collect what doesn't work so I can fix it. At the lab, people who don't write code turn their own repetitive work into skills.
What changed
Adoption is in progress and grows one team at a time, around a reference person who has already completed a representative task. Autonomy widens as people show judgement. People who don't code now build skills for reports and checks, and they spend the time they get back on deeper analysis. One colleague calls it time earned.
What I learned
I use Claude Code for everything and no longer write code by hand. Even so, on large codebases it has made a mess for me, and that's when I started writing tests before code. If that happens to someone who uses it all day, an intro course doesn't hand the design over to the agent, even though finishing one feels like being qualified to supervise any work. That's why access goes through an interview that ends with a real task and someone able to judge it, and for every change that matters I ask whoever launches it to explain the design and verify the behaviour.
What it can't replace is systems design
A colleague saved the prompt from every attempt and improved it each time. Once the method settled, she had it generalised into three parts: the method, the client brief and the list of files to use. The same method moved from one client to the next by changing only the brief and the files. A spec written from scratch, at a desk, looks like the tidier starting point, and it loses the tacit corrections that make a method work. The conversation that worked keeps them. Since then, at the lab, I suggest starting there: first a piece of work that succeeded, then the skill extracted from that conversation.
During a demo at the lab, the same colleague called the skill and added a long list of instructions on how to do the job, and the chat got confused. She opened a new one with the files already loaded and hit enter by mistake, with almost no text. The output was close to perfect. The method was already in the skill, and rewriting it in chat set it against itself. Since then we give a proven skill its inputs and its exceptions, and when someone feels the need to repeat the method in chat, we take it as the sign that the skill needs fixing.
A colleague who doesn't write code built many small skills, one per operation, instead of one that does all the work for a client. At the lab she showed the output: it cross-checked the data and also pointed her straight to where to look, like an order that was only partly returned. People expect automation for non-coders to mean fewer clicks and faster reports. The value she described was in the anomaly flagged and the decision that followed. Today it's the first question I ask when someone wants to turn a check into a skill: which exception deserves their attention, and for which decision.