The right to tools and experimentation.
Adoption does not come from locking developers down. It comes from giving people the right to try tools and run experiments inside guardrails that produce evidence.
Every company putting AI into its software work hits the same fork. One path restricts: approve a short list of blessed tools, block the rest, treat experimentation as a liability to contain. The other governs: let people try things, measure what happens, keep what works. The first path feels safer. It is the one that fails.
Restriction kills adoption
Tell capable people they may not use a tool and you do not stop them from using it. You stop them from telling you. Restriction breeds shadow tooling. The work moves to personal accounts, unmanaged endpoints, and laptops outside any policy, where there is no logging, no provenance, no chance of governance. The exact behavior you were scared of is the one you just drove underground.
It also breeds resentment. A hard block reads as: we do not trust you to pick your own tools. That costs goodwill you do not get back cheap. Pilots stall the same way. A program that runs every tool through a committee before anyone can touch it moves at the speed of the committee, which is to say it does not. Then the org decides AI is slow and risky, when the slow, risky thing was the restriction.
Governed experimentation drives it
The alternative is not a free-for-all. It is a loop: try, measure, keep what works. People bring tools and run experiments, but inside guardrails that capture what happened, so every experiment leaves a trail instead of a gap. Freedom and governance are not at odds. The guardrails are what make the freedom safe to hand out.
This is also what lets security say yes. A blanket no is the natural answer when the only other option is ungoverned risk, but nobody wants to be the person who says it. When the guardrails produce evidence on their own, when every tool use carries provenance, policy checks, and an audit trail, security is no longer choosing between blocking and flying blind. They can permit the experiment and still see all of it, govern all of it, revoke any of it. The default flips from no to a conditional, watchable yes.
One guardrail to set before anything else: cap spend before the call, not after the invoice. Agentic tools loop, retry, and burn tokens nobody budgeted for. We learned that one the hard way, with a real product, in front of 130+ real users. Set the cap up front and you can let people experiment without betting the month on it.
The field will not hold still
There is a sharper reason the right to experiment matters now. The inference landscape moves fast. New models, new providers, new price and capability tradeoffs land constantly, and the best tool for a job this quarter may not be next quarter. Lock yourself to a fixed, slowly-approved list and you have locked yourself out of that progress. The right to experiment is not just how individuals stay sharp. It is how the org keeps pace with a field that will not wait for it.
A culture change, not a control
The real shift is cultural: from tool restriction to governed experimentation, from treating curiosity as exposure to treating it as the engine. That is the one that decides whether adoption happens at all.
What is unusual is that both sides win. The developer keeps the right to reach for the best tool and learn by doing, which is the work they came to do. Security gets visibility, accountability, and the ability to govern at the level of evidence instead of blocking at the level of fear. Neither has to lose for the other to gain, because the guardrails serve them both. That is the adoption story, and it is the one we are building toward.