I see a strange split happening in our industry. In one corner, I have friends in freelance-heavy communities where everyone is using AI tools like Copilot, Claude, or Cursor. They're shipping features at a blistering pace, and for them, it's a non-negotiable part of the stack.
Then I talk to engineers at large, traditional companies. It's a ghost town.
Most aren't using AI tools at all. Many haven't even tried them. Some orgs have actively disabled them. It's not a small difference; it's a chasm.
This isn't just about "Luddites" or "early adopters." This is a fundamental divide in how we're building software, and it's happening right under our noses. The question isn't whether the tools are powerful—they are. The question is, why is there such massive resistance and inertia?
It's not a simple answer. It's a complex mix of trust, corporate friction, and a deep-seated misunderstanding of what these tools are actually for.
1. The Trust Deficit: "I Don't Trust What It Writes"
Let's get this out of the way: this is the biggest barrier for senior engineers. We've spent our careers learning to be skeptical. We build defenses. We write tests. We review code. Our entire job is to not trust things.
Then, a tool comes along that confidently "hallucinates" a solution that looks plausible but is subtly and disastrously wrong.
My first real week with Copilot, I felt like I was spending more time debugging its "clever" suggestions than it would have taken me to just write the code myself. It's great at syntax, but it often has no concept of context or consequence.
- The Review Burden: A junior dev writing bad code is one thing. An AI writing bad code 10x faster is a new kind of technical debt. The cost of reviewing AI-generated code can often feel higher than the cost of writing it clean the first time.
- The Black Box: It gives you a "solution," but it can't explain why. It can't participate in an architecture review. When it's wrong, it's not a "learning moment"—it's just noise.
Until an engineer can build a mental model of when to trust the tool, their default setting will be "off."
2. Enterprise Inertia: The Wall of "No"
For engineers in larger companies, the problem often isn't personal—it's political. The organization itself is a massive bottleneck.
The IP and Security Lockbox
This is the number one blocker. The first question any legal or security team asks is: "Is our proprietary code being sent to OpenAI for training?"
For a long time, the answer was a terrifying "maybe."
Even with "Enterprise" plans from GitHub, Anthropic, and others that promise data privacy, the default stance from security is "no" until proven otherwise. It only takes one engineer pasting a sensitive internal API key or a chunk of proprietary algorithm into a public-facing model to create a multi-million dollar incident.
For many companies, the perceived risk just isn't worth the (still unproven) reward.
The ROI Black Hole
How do you prove the value of a $20/month/dev subscription to a VP who manages a 5,000-engineer budget?
- "It makes us faster."
- "How much faster?"
- "...Faster?"
We don't have good metrics for this. "Lines of code" is a terrible one. "Story points" are subjective. "Tickets closed" is gameable.
Unlike a freelancer, where Productivity = Direct Income, an enterprise engineer's "productivity" is tied up in meetings, code reviews, and cross-team alignment. The C-suite is hesitant to sign a massive check for a tool that just "feels" more productive.
3. The "Craft" vs. The "Grunt Work"
There's a psychological barrier, too. We call ourselves "software craftsmen." We value the hard-won insights from hours of debugging. Does "outsourcing" the thinking to an AI make us... "prompt monkeys"?
This is where the divide is sharpest. I've found AI tools to be terrible at craft (designing new systems, novel algorithms, complex debugging) but absolutely god-tier at grunt work.
- Writing boilerplate for a new React component.
- Generating 10 unit tests for a utility function.
- Refactoring a dense block of code into smaller, cleaner functions.
- Translating a JSON object into a TypeScript interface.
The engineers who are missing out are the ones who try to get the AI to do the craft. The ones winning are using it to automate the grunt work so they can focus only on the craft.
4. How I Actually Use This Stuff (And Build Trust)
I didn't get past my skepticism by asking the AI to "write me a new feature." I got past it by treating it like a very fast, very naive junior dev.
I never use it for things I don't already know how to do. I use it for things I don't want to do.
Example Workflow: The Messy Refactor
Here’s a real-world, practical example. I have a messy function that's grown over time.
My Prompt: "I'm going to give you a JavaScript function. I want you to refactor it into smaller, single-responsibility functions. Do not change the logic. Add JSDoc comments for each new function."
Why this works:
- I'm the "senior." I'm giving specific instructions.
- The scope is small. I'm not asking it to build an app.
- Verification is "easy." I can run the exact same unit tests against the new code to ensure the logic hasn't changed.
Here's the code I'd paste in:
javascript
// BEFORE
function processUserData(data) {
if (data && data.user) {
// 1. Validate user
const user = data.user;
if (!user.id || !user.email) {
console.error("Invalid user data");
return null;
}
// 2. Normalize email
const normalizedEmail = user.email.trim().toLowerCase();
// 3. Create a greeting
let greeting = `Hello, ${user.name || 'guest'}`;
// 4. Check for admin
let isAdmin = false;
if (user.roles && user.roles.includes('admin')) {
isAdmin = true;
greeting += ' (Admin)';
}
// 5. Return processed object
return {
id: user.id,
email: normalizedEmail,
greeting: greeting,
isAdmin: isAdmin
};
}
return null;
}
## Conclusion: It's a Lever, Not a Crutch
The gap between the AI-augmented freelancer and the traditional enterprise dev is real, but it's not permanent. It's a temporary state defined by trust, policy, and habit.
The tools are not magic. They're not "intelligent." They are incredibly powerful text-completion engines that have ingested all of GitHub. They are a lever.
The engineers who are "ignoring" them are either blocked by their orgs or are trying to use the lever as a crutch—asking it to do the thinking for them. The ones who are winning are using it as it's intended: to amplify their own expertise and clear the boring stuff out of the way.
The future isn't about AI replacing developers. It's about developers who use AI replacing those who don't.
So, here's my question for you: What's the single biggest blocker to AI adoption you've seen in your organization? Is it trust, policy, or something else entirely?
Top comments (0)