Buying AI coding licenses is the easy part. Getting a thousand engineers to use them well is where most rollouts stall. Docusign’s engineering team has been unusually open about this, and in its own account of the rollout the company says 100% of its 1,000+ engineers now use AI coding tools, with a human reviewing every line before it ships. The interesting part is how it got there: AI coding adoption stalled at 49% until the company stopped relying on access and started relying on people.
If you manage engineering teams, in-house or extended, the sequence is worth studying. A caveat first: every number below is self-reported by Docusign, and the company does not say how it measures them beyond what is quoted here.
The plateau: licenses are not adoption
Docusign ran a GitHub Copilot pilot from December 2023 to June 2024 for roughly 20% of engineering, then rolled the tool out company-wide. According to the company, adoption reached 49% and productivity rose 18%, and then both flattened. The post names the friction: no dedicated time to experiment, no guidance tailored to the codebase, and no one to learn alongside.
That is a familiar pattern. The tool works, the early adopters are happy, and the rest of the organization quietly decides it is somebody else’s project. Nobody refuses. They just keep working the way they always have.
What moved the number: champions, then multipliers
In mid-2025 Docusign set up an Eng AI Champions program, a six-person central team that wrote guardrails, collected best practices and ran workshops. Adoption climbed to 65% by October 2025. The bigger jump came from AI Multipliers: engineers embedded inside individual development teams as peer mentors. Within two months of launching them, the active user rate reached 93%, and lines of code updated per developer were up roughly 52% from the starting point, per the Docusign engineering blog.
IT Brew reported in August that there are about 75 multipliers, roughly one per team, which makes the design easy to picture. The mentor is someone your team already trusts, sitting in the same standup, working on the same code.
The company’s own conclusion is blunt: peer-led enablement worked better than top-down mandates, and access alone stalled adoption.
Guardrails came before autonomy
Docusign did not trade control for speed. The guardrails it describes are concrete:
- Human review is required on every pull request, including those opened by agents, as described in the post on its autonomous coding agent.
- AI-generated code is labeled, and quality gates apply before anything merges.
- Per IT Brew, guardrails also include proof that code was tested before review and mutation testing.
- Its internal agent platform, Krew, runs more than 400 agents, none of which can merge a pull request or take an irreversible action without a person approving, according to the Krew write-up.
CTO Sagnik Nandy put the accountability point this way to IT Brew: “A human still is responsible for the chainsaw.” For a delivery manager, that sentence settles who owns a defect, whoever or whatever typed the code.
Automation arrived only after trust
Docusign describes a four-stage maturity model: Try, Use, Trust, Rely. Only in the third phase, starting December 2025, did it push into workflow automation. Its internal coding agent took a task from Slack or Jira, wrote the change, ran the tests and opened a pull request. The share of PRs generated by the agent rose from under 1% to over 7% in two months, and an infrastructure configuration job that normally took about a week was done in about 15 minutes, with 10 of 12 files correct on the first pass, according to the agent write-up.
Notice the order. Mentors and guardrails came first. Agents that open pull requests came after the review habits were in place.
What to copy if you run distributed or nearshore teams
None of this is specific to a company with 1,000 engineers. The following is my reading, not a Docusign claim. If part of your delivery runs through a nearshore partner or an extended team, the same structure applies:
- Name one multiplier per squad, including partner squads, and give that person real time for it.
- Agree on the review rules up front: who reviews AI-assisted code, how it is labeled, what tests must exist before review.
- Track delivery measures such as review latency and rework, not just the share of engineers with an active seat.
- Add agents that open pull requests only after the review habits hold across every team, partners included.
Adoption is a management problem
Docusign’s 49% plateau is the useful data point. It shows that a tool rollout can look finished while the real work has not started. The fix was people, not procurement.
If you are planning how to bring AI-assisted development into an extended engineering team, talk to the Luby team about how we structure enablement alongside delivery. And a question for your next planning meeting: who, exactly, is the multiplier on each of your teams?