Tools: The Hardest Part of AI Isn't the AI

A Quick Rewind ## The Technology Figured Itself Out ## The Leadership Shift Nobody Talks About ## What "Leading by Example" Means Now ## The Judgment Gap ## What I Got Wrong (And What It Taught My Team) ## AI Beyond Engineering ## The Question That Matters ## What's Next After 6 months of building, shipping, and leading with AI tools every day, I can tell you the technology was the easy part. Last fall, I wrote about AI being the first thing in 20 years that genuinely changed how I work and then the workflow shifts that followed—builder to architect, the "worth doing" threshold dropping, parallel execution changing everything. Then I went quiet. Not because I lost interest. Because I went deep—building infrastructure, integrating tools, navigating the organizational reality of AI adoption. Living it instead of writing about it. Here's what I learned that I didn't expect. Let's get this out of the way: the tools are incredible now. I run a stack that would've sounded fictional two years ago. Cursor for deep coding context. CodeRabbit scanning every PR before I look at it. Claude for the kind of architectural reasoning that used to require a whiteboard and three senior engineers. GitLab Duo woven into the platform workflow. These tools work. They work well. They're getting better every month. But here's what I've realized after months of using them in production: the tools were never the hard part. Getting Cursor set up takes an afternoon. Integrating CodeRabbit takes a few hours. The technology adoption curve is the flattest I've seen in my career. The hard part is everything that happens after the tools are running. When I wrote about moving from builder to architect, I thought I understood the shift. I understood maybe a third of it. The real shift isn't in what you do. It's in what you decide. Every day now, I make judgment calls that didn't exist before: When AI generates a solution that works but doesn't match our patterns, do I accept the velocity or enforce the standards? When a junior engineer ships twice as much code because AI is writing most of it, how do I evaluate their growth? When I can prototype three approaches in the time it used to take to spec one, how do I decide which to invest in? These aren't technology problems. They're leadership problems. And my 20 years of experience matter more for these decisions than they ever did for writing code. That's the part nobody warned me about. AI doesn't reduce the need for experienced judgment. It concentrates it. I've always believed leaders should be hands-on. Build what you ask others to build. Understand the work at the level you're asking people to do it. AI changed what that means. Leading by example used to mean I could sit down and write the code myself. Now it means I can sit down and orchestrate the solution myself—and more importantly, that I can show my team how I think through the orchestration. The valuable demonstration isn't "watch me use Cursor." It's "watch me decide what to point Cursor at, what context to give it, and what to reject from the output." I've started doing something I never did before: I walk through my AI-assisted problem-solving process out loud with my team. Not the tool mechanics. The judgment. Why I gave it this context and not that context. Why I rejected a technically correct solution because it didn't fit our operational reality. Why I chose to do something manually when AI could have done it faster. That's the new version of leading by example. And it might be the most important thing I do now. Here's something uncomfortable I've learned: the gap between "I use AI effectively" and "my organization uses AI effectively" is enormous. And it's not a training gap. Everyone on my team has access to the same tools I do. They can all prompt an LLM. The gap is in knowing what problems to solve. After 20 years, I carry a mental model of what matters—which architectural decisions will haunt us, which shortcuts are fine, which edge cases will wake someone up at 3 AM. AI amplifies that mental model. I point AI at the right problems, give it the right context, and validate the output against real operational experience. Without that kind of judgment, AI is incredibly productive at building the wrong things very fast. This isn't an argument that junior engineers can't use AI. They absolutely can, and they should. It's an observation that AI makes experience more valuable, not less. The people who've been around long enough to know where the landmines are buried? They're the ones who get the most leverage from AI. That's a leadership insight that matters right now, because a lot of organizations are treating AI adoption as a training problem when it's really a mentorship problem. In the spirit of honesty that started this series, here's what I got wrong in my earlier posts—and what we learned from it: I underestimated the security complexity. I wrote about security implications, but I didn't appreciate how much the attack surface changes when AI tools have context about your systems. Context engineering isn't just about making AI more effective—it's about controlling what AI knows. That's a fundamentally different security model than most organizations are built for. We had to rethink our entire approach to data classification—not because of a breach, but because we realized we were one lazy prompt away from one. I overestimated how fast teams adopt new patterns. My personal workflow transformation happened in weeks. Organizational transformation takes months. Not because people resist change—because the coordination cost is real. Everyone needs to learn new judgment patterns, not just new tools. The fix wasn't more training sessions. It was pairing—experienced people working alongside less experienced people, making the invisible judgment visible. I thought the "worth doing" threshold drop was purely positive. It mostly is. But when everything becomes worth doing, prioritization gets harder, not easier. A backlog that grows because you can do more is a different kind of problem than a backlog that grows because you can't. We caught ourselves three months in with too many things in flight. The discipline of saying "not now" is harder when "now" is so cheap. Here's where this gets bigger than dev teams. Everything I've described so far happened inside engineering. But the patterns aren't engineering-specific. The judgment gap, the mentorship problem, the "worth doing" threshold—those exist in every department. I'm now building a plan to take AI adoption org-wide. Operations. Security. Project management. Not by handing everyone a ChatGPT login and calling it transformation. By applying the same approach that worked in engineering: start with the people who have the deepest domain judgment, give them AI tools, let them demonstrate what's possible, and build the infrastructure that lets it scale. The insight from engineering applies everywhere: AI doesn't replace domain expertise. It gives domain experts leverage they've never had. A security engineer with 15 years of experience and AI tools isn't just faster at writing policies—they're solving problems that weren't feasible before. An operations lead who knows where every process bottleneck lives can use AI to finally fix the ones that were never "worth the effort." That's the real unlock. Not AI for engineering. AI for the entire organization, led by the people who know the work best. If you're a leader thinking about AI adoption—or in the middle of it—here's the question I'd push you to answer: Who in your organization has the judgment to direct AI effectively, and how are you scaling that judgment to others? Not: what tools should we buy. Not: how do we train people on prompting. Not: what's the ROI. Who has the mental model, and how does it spread—across teams, across departments, across the org? Because the tools are easy. The technology is the easy part. The leadership challenge of developing AI-ready judgment across an organization—that's the work that separates companies that get real value from companies that just get faster at building the wrong things. I've been building the infrastructure that makes all of this work at scale—context systems, security boundaries, observability for AI-assisted workflows. I'll share the technical details in the next post, including the code. All of it is public at gitlab.com/mikefalk. But I wanted to start here. With the human part. Because after 6 months of living with AI every day, I'm more convinced than ever that the technology will keep getting better on its own. The leadership? That's on us. Let's compare notes. If you're navigating AI adoption in your organization—especially if you're a hands-on leader who refuses to just delegate it—I want to hear what you're learning. The best insights I've had came from conversations, not documentation. Find me: LinkedIn | GitLab | dev.to Mike Falkenberg is a technologist with 20+ years leading development, operations, and security teams. He shares practical insights from building world-class technology organizations. Follow on GitLab for code and dev.to for articles. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse