Nobody Ever Got Argued Into Trusting a Tool

A few years back, a suit told me I was going to use Terraform. No training, no ramp-up, no “here’s why this will make your life better.” Just: the devops team isn’t going to help you anymore, here’s the tool, figure it out.

I still have negative feelings about Terraform. Not because the tool is bad. It’s fine. The introduction was bad. Someone decided I needed to adopt a technology and their entire change management strategy was a mandate. No space to evaluate it on my own terms. No acknowledgment that I might have reasonable questions. Just “you’re using it.” You can take the engineer out of the punk band, but you can’t take the punk out of the engineer. Tell me I have to do something without giving me a good reason and watch how fast I decide I don’t want to.

Every engineering leader trying to get their team to adopt AI coding tools is at risk of being the Terraform suits. And most of them don’t realize it.

I’ve been writing software since the 90s, starting with Visual Basic. Thirty-plus years of repetitive coding patterns, boilerplate, and the kind of tedious structural work that makes you wonder why you got into this profession. I’ve written plenty of code generators over the years to deal with it. The kind that spit out scaffolding from database schemas. They work great until you need to modify the generated code by hand. Then the generator is useless going forward. There’s always outliers, and the outliers are where the real work lives.

So when Copilot showed up and started autocompleting Go’s err != nil checks, my reaction was not skepticism. It was: this is a smarter code generator. One that can handle the outliers because it actually understands context, not just templates.

That was the “neat trick” phase. Copilot was a really good autocomplete. I could see the potential, but I wasn’t restructuring my life around it.

Then I started noticing it was tracking across larger codebases. Multi-repo Java projects where the context problem is genuinely hard. Where knowing what to write next requires understanding code spread across multiple services. That was when “neat trick” became “ok, this is actually real.”

But even then, I wasn’t handing over the keys. I was letting it help with the parts I didn’t want to do. The relationship was simple: I think, it types.

The progression from “useful autocomplete” to “this is how I work now” didn’t happen because someone argued me into it. It happened because each step earned enough trust to make the next one feel reasonable.

Tests were the first real unlock. After the autocomplete phase, I started using it to write tests. This is the step I’d recommend to anyone trying to get developers on board, because it reframes the entire relationship. When you’re reviewing AI-generated tests, you’re exercising your expertise. Evaluating whether the test cases are right, whether the edge cases are covered, whether the assertions actually prove anything. You’re not surrendering judgment. You’re applying it. That distinction matters more than people think.

Debugging was the next surprise. I hit a multithreading bug. The kind where you’ve been staring at the code so long you can’t see the problem anymore. I figured, what the hell, I’ll throw it at Claude Code and see what happens. After a bunch of cycles, it found the issue. Not because it was smarter than me. Because it was a second set of eyes that wasn’t carrying the same assumptions I’d been staring at for hours. That’s when the mental model shifted from “AI as code generator” to “AI as a thinking partner who isn’t stuck in the same rut I am.”

Low-stakes personal projects came next. Porting websites to Astro, building helper utilities for myself. Real work, but nothing that blows up if it goes sideways. This is where I let the agent handle entire tasks start to finish and got a feel for what it could and couldn’t do on its own.

Then came the investor POC. In the startup world, you regularly get “it would be really cool if we could show this feature to potential investors.” I gave Claude Code a shot at one of these. I didn’t do the “vibe coding” thing. I didn’t say “magically make me an app.” I gave it a feature at a time, but I let it make the programming language and library decisions to see how it would do. In a week we had a functional prototype. That same work would have been a week of just research if I’d done it myself. It was a great POC to see if the idea was worth fleshing out into our existing infrastructure.

Structured production work was the real shift. Similar flow to the POC but with real constraints. I gave it detailed limits on our existing architecture. I built out skills for different types of agents, defining what each one could and couldn’t do. Before touching a feature, I’d spend time going back and forth until we had a solid plan, then let the agent code within those boundaries. My job became less about writing code and more about designing the constraints the code needed to live within.

That’s where I am today. Architecting and designing, not directly coding. The agents show me the code they’re planning so I can catch missteps before they happen. And it’s become a two-way street. When you’re juggling five projects simultaneously, you’re going to miss things you didn’t think of ahead of time. The AI has caught me on YAGNI violations. Called me out for over-engineering something that didn’t need the complexity. Having another brain asking “do you actually need that?” has probably saved a few cycles.

Here’s the part where I’m supposed to give you a framework. I don’t have one. What I have is an observation: every step in my progression happened because someone gave me the tool and the space to figure it out on my own terms. Nobody mandated it. Nobody scheduled a demo I didn’t ask for. Nobody forwarded me an article about how AI was going to replace developers.

The opposite approach, the Terraform approach, would have killed it. If someone had told me in the Copilot autocomplete phase “you’re now required to use AI for all new code,” I’d have resented it. Not because the tool was bad, but because the mandate would have prevented me from building my own trust at my own pace.

So if you’re an engineering leader trying to move your team toward AI tools, here’s what I’d actually suggest:

Start low. Give everyone access to Copilot in VS Code or Junie in IntelliJ. Don’t make an announcement about it. Don’t have a meeting. Just make the tools available and let people discover them.

If nobody bites, suggest tests. Not mandate. Suggest. “Hey, try letting it generate the test scaffolding for that module and see if it’s any good.” Tests are the perfect entry point because reviewing AI-generated tests is an exercise of expertise, not a surrender of it. The developer is still in charge. They’re just evaluating instead of typing.

Then get out of the way. This is the hard part for leaders. You want to see adoption metrics. You want to know who’s using what. You want a standardized workflow. Resist all of that. Everyone is going to use these tools differently. Your flow with LLMs is as personal as your IDE’s color theme. Some people will use it for boilerplate and never go further. Some will be pair-programming with agents within a month. Both are fine. The worst thing you can do is force a specific workflow on people who are still building trust with the tool.

Don’t measure adoption. Measure output. If a developer’s code quality and velocity are good, it doesn’t matter whether they’re using AI, writing everything by hand, or dictating code to a trained parrot. The tool is a means, not an end. The moment you start tracking “AI adoption rates” you become the Terraform suits.

The surprise in this story isn’t that AI got good enough to write production code. If you’d told me five years ago that would happen, I’d have been skeptical but not shocked. Technology gets better. That’s what it does.

The surprise is what happened to me.

Somewhere on that ladder, and I couldn’t tell you exactly when, my relationship with code changed. I went from “AI handles the parts I don’t want to do” to realizing I was operating at a different altitude. More time on architecture, system design, and the decisions that actually matter. Less time on implementation mechanics. The AI didn’t replace my judgment. It freed me up to use it on the things that needed it most.

And the skepticism I had early on wasn’t really about code quality. It was about identity. I’d spent thirty years as someone who writes software. Letting a machine do that part felt like it was taking something away. It took actual experience, not arguments, not demos, not articles, to understand that it was giving something back. The thinking didn’t go away. It just moved up a level.

That’s the thing leaders need to understand about the skeptics on their team. The resistance isn’t irrational. It’s not about being a luddite or afraid of change. For experienced developers, writing code is tied up with professional identity in a way that’s hard to articulate and easy to underestimate. You don’t overcome that with a mandate or a demo. You overcome it by creating the conditions for someone to have their own experience, at their own pace, and arrive at their own conclusion.

You can’t argue someone into trusting a tool. But you can make it easy enough to try that they argue themselves into it.

Andy Barilla is Director of Language Engineering at Talos Title, where he builds multi-LLM orchestration systems for legal document processing. He has been writing software for over 30 years.