Getting Buy-In from the Skeptics

You don't persuade experienced developers to use AI.

You let them test it, reject what doesn't meet the bar, and keep what does.

That's what happened in a recent engagement with a large educational technology organization and their lead developer. This person is deeply experienced and legitimately smart—but pessimistic about AI in the way veteran builders often are: not reflexively negative, just unwilling to be sold.

They weren't a "true believer." They were willing to try.

The cadence mattered: small bets, repeated over time

We didn't run a big kickoff. We worked together one day a week—sometimes just an hour at a time.

That structure is underrated. It keeps the cost of experimentation low, but it allows evidence to accumulate. And for skeptical leaders, accumulated evidence is the only thing that changes decisions.

Phase 1: a fair comparison beats an argument

The developer started with simple comparisons between Claude Code and GitHub Copilot.

That alone produced a clear conclusion: for their workflow, Copilot wasn't strong enough to justify the overhead. Not a subtle difference. Enough of a difference that they moved on.

This is how credibility gets built inside technical organizations:

• test something in real conditions
• accept what works
• discard what doesn't
• don't romanticize any of it

Phase 2: the surprise win wasn't code—it was voice

Next came a different use case: writing.

The developer wanted to use Claude for blog posts and possibly a white paper, but had a real concern: "I have a style. I'm not sure AI can do it."

That concern is correct. Generic writing is cheap; credible writing is not. For a technical leader, the writing is part of the reputation.

So we approached it like engineering:

• use real data (their existing posts)
• infer the pattern (tone, structure, vocabulary, depth)
• test the system on a real deliverable

They fed existing hand-written posts into Claude, had it infer their writing style, then gave it a large prompt for a conference white paper.

This wasn't lightweight content. It was a technically detailed paper, over 20 pages long.

They were shocked by the result—mostly because it wasn't "good for AI." It was simply good. A few minor edits and it was effectively ready.

Phase 3: the tipping point arrived through the team

Here's the part most AI adoption stories skip:

The lead developer started hearing from direct reports about the work you'd done with them—and the results they were getting.

That matters because it changes the risk profile. It's no longer "this works for one person." It's "multiple competent engineers are independently saying this is useful."

Skeptical leaders don't become optimistic. They become convinced there's enough signal to invest.

Phase 4: from "tool" to "workflow"

Once the developer had enough evidence, the experiments moved from content into delivery workflow:

• GitHub Actions
• Reading Jira tickets
• Writing Jira tickets
• Sending Claude Code to read those tickets and implement fixes or changes

That's the real direction: toward an automated workflow.

Not "fully autonomous engineering." Not "replace the team."

A pipeline where the slow, repetitive parts of software delivery—triage, interpretation, first-pass implementation, and handoffs—get compressed.

You're not all the way there yet. But you're close.

The executive implication: capacity is being re-priced

By the end of 2 months into this engagement, the lead developer's position wasn't "AI is interesting."

It was more concrete:

Next year, a five-person internal team can plausibly do what they previously expected to need an external contractor team of around 20 to deliver. It took 2 months to come to this realization, but we are there.

That's not a motivational statement. It's a throughput statement.

And it only becomes true when three things happen at the same time:

The tradeoff (because it's real)

This capacity shift isn't free.

• The team has to raise the bar on ticket clarity and acceptance criteria.
• Test coverage and CI discipline become non-negotiable.
• Human review stays in the loop—especially for ambiguous work and architectural decisions.

But if those conditions are met, the economics change: you can concentrate output in a smaller, higher-skill internal team instead of scaling with contractors.

And this is just engineering. The same pattern is showing up in learning systems, support, and marketing—places where the "work" is documentation, diagnosis, routing, and content. The takeaway isn't that AI makes people faster. It's that AI changes how much output you can get from a small, high-skill team when the workflow is instrumented and the standards are clear.

What surprised me is that engineering may end up being the least dramatic part of the story.