I stopped telling engineers to 'just try AI' and started giving them a failing test

For the first three months after we rolled out AI coding tools, my advice to engineers who asked how to get started was: "just try it on your next task." That advice was well-intentioned and almost completely useless.

The problem with "just try it"

"Just try it" puts the entire cognitive load on the learner. They have to pick a task, figure out the tool's interface, formulate a useful prompt, evaluate the output, and decide whether it was worth the effort — all at once, while also trying to do their actual job. Most people, reasonably, tried it once on a vague task, got a mediocre result, and moved on.

Our internal survey showed about 30% regular usage after that first quarter. Disappointing, but predictable in hindsight.

The failing test approach

We changed the approach for the next pilot group of 25 engineers. Instead of open-ended exploration, we gave each person a very specific exercise:

1. Clone this repo (a real internal service, not a toy).
2. Check out this branch. There is one failing test.
3. Use Claude Code to make it pass. You have 30 minutes.

That is it. No slides about prompt engineering. No lecture on what LLMs are. No demo of all the features. Just: here is a broken thing, here is a tool, fix it.

Why this works

The failing test removes every source of friction that "just try it" introduces:

• Task selection is done for you. You do not have to decide what to try the tool on.
• Success criteria are clear. The test passes or it does not. No ambiguity about whether the tool "helped."
• Scope is constrained. You are not trying to rewrite a service. You are making one test pass. The cognitive overhead is low enough that you can focus on learning the tool.
• The codebase is real. This is not a contrived example. It is production code in a language and framework the engineer already knows. The patterns they learn transfer directly to their work.

The results

Four weeks after the lab, 80% of that pilot group was using Claude Code at least weekly. That is not a typo — we went from 30% with "just try it" to 80% with a single structured exercise.

The engineers told us what changed. Almost all of them said the same thing: "I did not understand what it was good at until I used it on a real task with a clear goal." One staff engineer put it well: "I thought it was autocomplete. The lab showed me it is more like a junior dev who is really fast at reading docs."

How to build your own version

You do not need to buy our platform to do this. Pick an internal repo with good test coverage. Write a small, self-contained failing test — something that requires reading existing code, understanding a pattern, and writing 20-50 lines. Bring five engineers into a room with their laptops for an hour. Walk them through the first two minutes, then let them work. Have one facilitator who has done it before available for questions.

That single hour will produce more adoption than any number of "lunch and learn" demos or Slack messages saying "Claude Code is available, go try it."

The insight is not complicated: people learn tools by using them on constrained, real problems. Not by being told the tools are good.