AI Adoption: The Real Resistance
By Darryl Brown
Getting our team to adopt AI turned out to be more complex than I expected for reasons that were both practical and deeply human.
On the practical side, these tools are difficult to use well. The quality of what you get out is directly tied to the skill and effort you put in. Learning to work effectively with AI requires real investment — in understanding how to frame problems, how to evaluate output critically, and how to redirect when the tool goes off course. That learning curve is real.
But underneath the practical challenge was something deeper: the change asked people to revalue expertise they’d spent years accumulating. Some tasks that used to take a day now take minutes. That’s genuinely exciting — and it’s also genuinely disorienting if your sense of professional value is tied to the expertise that made the day-long task hard. Those are not small things to ask someone to reconcile simultaneously.
Let me explain why this mattered so much to us specifically.
We are a small team. We don’t have the budget to simply add resources whenever demand increases. What we have is a group of skilled people, a set of problems to solve, and a need to do more with the same — or fewer — resources over time. One of our developers put it plainly: we have deadlines to meet and products to build to stay relevant and win new work. If we don’t innovate, we won’t succeed.
AI is not optional for a team in that position. It’s the difference between a team that can punch above its weight and one that can’t.
I began introducing the topic in late 2024 in our weekly team meeting that has evolved well beyond its original purpose into a space where anyone can bring technical challenges, frustrations, new ideas, or demos. It’s not a top-down meeting. I use it occasionally to float ideas, and AI became a frequent topic. The timing felt right. By late 2024, the tools had crossed a threshold — the return on using them had become obvious enough that the conversation had shifted from “Should we?” to “How do we?”
My view, which I shared with the team directly, was that the direction of travel wasn’t really optional, not because I said so, but because the world outside our company was moving this way regardless. What I could offer them was a chance to get ahead of it. I wanted everyone on this team to be employable in five years, whether that was here or somewhere else. Framing it that way perhaps landed differently than “Here is a new tool, please use it.”
How we landed on our specific tools reflects the same principle of trusting the team.
I had a conversation with a CEO at another company who was ahead of us in AI adoption. He generously shared their experience and mentioned they were experimenting with Devin. Some of our engineers had already been trying Cursor on their own. We discovered the two tools had different strengths, so we’ve continued using both for different purposes rather than forcing a single choice. GitHub Copilot was a natural addition given that we already use GitHub for our codebases. Any tool that integrated cleanly with existing infrastructure had a lower barrier to adoption.
Copilot has its annoyances, but it also consistently catches real bugs and gives genuinely useful advice on best practices. On balance, it has proven its usefulness.
Adoption wasn’t uniform or frictionless. The developers who adopted early became internal champions, and social proof did work that no mandate could have done. We started sharing AI experiences in our weekly team meeting — the good, the bad, and the ugly. There were enough genuinely remarkable experiences that the case for AI made itself more effectively than any directive from me.
The shift in how developers work is real. They’re not writing the majority of the code. They plan a solution with AI, direct it toward an implementation, evaluate the output, and validate that it isn’t doing anything unexpected. The role changed. It didn’t disappear.
AI is not a replacement for engineering judgment. Someone still has to evaluate whether the output makes sense, whether it’s introducing subtle problems that look fine on the surface, whether the approach is sound. The developer became the director rather than the implementer — which requires a different and in some ways more demanding set of skills than pure coding. AI is most valuable as a partner throughout the work — helping plan a solution, generating an implementation, reviewing that implementation from multiple angles, and iterating when something isn’t right. The developer directs that partnership at every stage.
We’ve also begun building AI expert reviewers into our code review process. Our code review tool currently reviews every set of proposed changes before any human sees them, catching real bugs and flagging best practice violations. We are actively adding additional automated passes — for security, performance, and other specialized concerns — that will run as part of the same gate. The goal is that issues are caught by an automated expert before a human ever looks at the code, making them cheaper to fix and faster to resolve. That work is in progress and the early results are encouraging.
One thing we’ve been deliberate about is separating how we prompt AI from which tool we’re using — and treating prompting as its own discipline entirely. Within each of our codebases, we maintain a set of context files that describe the codebase for an AI reader: best practices, architectural decisions, coding standards, and baseline instructions. When a developer engages an AI tool on a work item, the first instruction is always to read those files before attempting to solve anything.
The result is that the AI operates with the same foundational knowledge any experienced member of our team would bring to the work. The context travels with the code, not with the person. It’s tool-agnostic by design — when we switch platforms, the accumulated knowledge of how to get useful output from our codebase doesn’t disappear with the old tool. The recipe travels with us.
This matters more than it might seem. The quality of what you get from AI is largely determined by the quality of what you put in. Investing time in how you interact with these tools, not just which tools you use, is where the real leverage is. The context files are our answer to that challenge, and they’ve made a meaningful difference in the consistency and quality of AI-generated output across the team.
The mindset shift we’ve worked toward is this: AI augments the team. It lets us remain small and still meet the demands of a growing business. The developer’s job is to direct that augmentation at every stage: framing the problem clearly, evaluating the output critically, redirecting when the AI goes off course, and applying judgment the tool doesn’t have.
Stepping back from our own experience, I think the AI moment we’re in has surfaced something important about organizational readiness that goes beyond tools and workflows.
Many of the principles that drove our transformation — small batch sizes, eliminating waste, continuous improvement, creating safety to experiment and fail — are core tenets of LEAN manufacturing, applied to software. What I’ve learned is that these principles aren’t just useful for building better software. They are the prerequisite for implementing any significant change at all. Without a culture where people can ask why, experiment, and occasionally fail without consequence, an organization cannot iterate its way toward a better state. It will announce changes rather than grow them. And announced changes, in my experience, rarely stick.
This matters urgently right now. The companies that will successfully adapt to AI are not necessarily the ones with the biggest budgets or the most sophisticated tools. They are the ones with the cultural foundation to absorb change iteratively — to try something, measure it, adjust, and keep going. The technology is, in many ways, the easier part. The culture is the hard part. And it cannot be installed overnight.
There is one broader implication of this shift that the industry hasn’t fully answered yet.
As AI has taken over the tasks that used to define junior engineering work — the straightforward implementations, the repetitive foundational code, the well-defined work items — I’ve found that I no longer need junior engineers in the way I once did. The work that remains requires seniors: people who can architect solutions, evaluate AI output critically, redirect the tools when they go wrong, and write complex code themselves when the problem demands it. Those are not skills a junior engineer walks in the door with. They’re skills developed over years of doing exactly the kind of work AI is now doing.
Which raises a question I don’t think the industry has answered yet: where are tomorrow’s senior engineers going to come from, if we are no longer hiring juniors to develop them? I don’t know. But it’s worth asking — and worth watching carefully as this unfolds.
The tools are changing quickly. The responsibility to think clearly isn’t going anywhere.
The final post in this series is about a shift in how we think about quality, not as something we check at the end, but as something we build in from the start.
