“The world is changed. I feel it in the water. I feel it in the earth. I smell it in the air.” — Galadriel
Can you feel it too? If you’ve been around for some time (like I do), it’s now undeniable that software engineering teams are changing.
If you’re a leader, and you’ve been ignoring AI, it’s fair to say that this luxury has officially expired. Your team is looking for your stance; they want to know what’s ok and what’s not. They need your guidance and clarity.
Here, I’ll talk about my experience and how I enabled my team to experiment and succeed with AI (with some caveats), and how can you do the same right now.
Seeing is believing
First things first: try it yourself. I know it sounds obvious, but you’d be surprised how many engineering leaders hold strong opinions about AI tools they’ve never even opened.
As a modern engineering manager, you need to be in the details. Gone are the days when you could lead from a distance without understanding what (and in this case how) your team is actually doing.
So get your hands dirty. Fix a simple bug with Claude Code. Try shipping a small feature using Cursor. Draft a company document with ChatGPT. Your personal experience matters here—without it, it’s all just theories in your head; you’ll be out of touch.
Experimentation culture
Once you’ve experienced it, and now see the value of it, create space for your team to explore. In my experience, there are three main barriers to adoption:
- Money and resources: The easiest one to solve—just give them a budget. Your company doesn’t have an AI budget? Fight for it! The ROI is obvious when their productivity can jump by 50%.
- Time for experiments: Explicitly tell your team that investing time, even if experiments fail, is totally acceptable. Yes, many of these initiatives will be dead-ends. But that’s exactly how breakthroughs works. The key isn’t avoiding failure—it’s sharing what you’ve learned (and trying to fail fast).
- Resistance to change: This is the trickiest one, especially among senior engineers who are accustomed to their tools for many years (well, like I was with my Neovim setup). For this transition to work, you need to know your people individually. If they swear by VSCode, show them how Cursor keeps the familiar interface while adding AI superpowers. Terminal junkies? Introduce them to Claude Code or Warp. Meet them where they are.
Also, nothing drives adoption faster than engineers seeing their peers succeed. You can, for example, create a dedicated Slack channel where your team can share AI wins.
Last month, one of our devs posted a before/after comparison of how they refactored a complex function using AI assistance. It took them 15 minutes instead of 2 hours. By that afternoon, three more engineers were experimenting with it.
The thing we don’t want to talk about
Of course, there’s the elephant in the room: job security. I had an engineer who was clearly holding back from using AI tools despite seeing the benefits. During our 1:1, they finally spoke what their fear was: “If I become twice as productive with AI, won’t the company just need half as many engineers?”
I gave him/her the honest truth: “It’s impossible for me to promise job security for anyone. But think about this logically: we hired you before AI was a thing, and now that you’re significantly more productive with these tools, why would we let you go?”
Companies don’t (usually) fire their most productive people; they invest in them. The real threat isn’t AI—it’s sticking to outdated ways while the industry evolves around you. The engineers who embrace these tools will (well, probably) be just fine; the ones who ignore these tools, I’m not so sure…
Some caveats
As much as I’m advocating for AI adoption, there are some guardrails we need to set.
- Don’t force adoption: If someone only wants to use AI for asking questions but prefers writing code themselves, that’s fine. Forcing tools on resistant engineers often backfires spectacularly.
- Clear accountability: When something breaks in production, “AI wrote it” will never fly as an explanation. If your name is in the PR, it means you have full responsibility for the output.
- Bad vibes: Yes, vibe coding is a thing, but vibe engineering isn’t. I tell my team repeatedly: “If you can’t explain exactly how the code works and why, you aren’t ready to commit it.” Engineering requires rigor and understanding, not vibes.
- Team and long-term; not you and now: That 3-minute AI-generated document might feel efficient today, but if it lacks proper context or clarity, the rest of the team will spend 10x that time trying to understand it later. I make everyone ask themselves: “If I encountered this code or document for the first time, would I understand it?” Proper review isn’t optional—it’s essential.
Your role as a leader isn’t to fight this wave or to blindly surf it. It’s to help your team harness it effectively, to set clear boundaries, and to keep the focus on delivering value—just with more powerful tools.
The shift to AI-assisted engineering isn’t coming—it’s here. The teams that adapt fastest will define the next generation of software development, and the ones that resist will be telling stories about the good old days when people wrote every line of code by hand.
Terrible Software 