I’m dealing with a divide on my dev team where some senior engineers refuse to use AI coding tools, while others rely on them daily for debugging, documentation, and faster delivery. It’s starting to create tension around productivity, code review standards, and hiring expectations. I need help figuring out whether this resistance is reasonable or if these developers are falling behind industry trends in software development and AI adoption.
This is a management issue, not a tooling issue.
Senior devs who refuse AI are not auto-wrong. Senior devs who lean on AI are not auto-better. What matters is output, code quality, review load, incident rate, and team trust.
Set rules. Measure results.
-
Define where AI is allowed.
Use it for docs, test scaffolds, refactors, log analysis, and boring glue code.
Block it for sensitive code, secrets, regulated flows, and arch decisions without review. -
Set a review standard.
AI code gets reviewed like any other code. No free pass. The dev who submits it owns it. If they cnt explain it, it does not ship. -
Track a few metrics for 6 to 8 weeks.
PR cycle time.
Bug rate after release.
Review comments per PR.
Rework rate.
Time spent on docs.
Then compare teams or people who use AI vs people who do not. -
Stop making it ideological.
This turns dumb fast. AI is a tool. Like linters, Stack Overflow, or debuggers. Some people overuse it. Some people refuse it on principle. Both camps get annoying. -
Train both sides.
AI users need verification habits.
Non-users need exposure to real use cases, not hype.
My take, if a senior dev refuses all AI no matter the task, they risk falling behind on speed. If a senior dev depends on AI for core reasoning, they already fell behind.
You want judgement first, tools second. That is the line.
I’d push back a little on the framing. “Refuse to use AI” and “use AI daily” are both kinda meaningless unless you ask why.
Some seniors avoid it because they’ve seen too many confident wrong answers, license murkiness, and juniors cargo-culting generated code into prod. That’s not stubbornness, that’s scar tissue. On the flip side, if someone won’t even try AI for low-risk stuff like draft docs, regexes, SQL cleanup, or test cases, yeah, that can become a speed problem.
Where I disagree a bit with @hoshikuzu is this is not just management. It’s also culture and identity. Some devs hear “use AI” as “your hard-earned judgement is replacable now.” That tension is real.
What I’d do:
- stop debating “AI yes/no”
- split work into discovery, implementation, and verification
- allow AI more in the first two, demand human ownership in the third
Also, watch for hidden team damage. The AI-heavy folks can start dumping sloppy PRs because “review will catch it.” The anti-AI folks can become bottlenecks out of principle. Both are bad.
Seniority isn’t about typing speed anyway. It’s about making fewer expensive mistakes. If AI helps that, use it. If it hurts that, dont. That’s the actual bar.
This probably needs a policy, not a philosophy fight.
I mostly agree with @hoshikuzu that the “why” matters more than the label. But I’d also push back on one thing: teams sometimes over-romanticize skepticism. A senior who refuses every new tool on principle can hurt throughput just as much as someone rubber-stamping AI output.
What usually works is setting team expectations around artifacts, not process. I do not care if code, docs, tests, or queries start with AI or not. I care that the final result is understandable, reviewable, secure, and maintainable by someone who did not generate it.
A few practical rules:
-
Require attribution in PRs when AI was used in a meaningful way.
Not for punishment. For review calibration. -
Ban opaque copy-paste.
If the author cannot explain it, it does not ship. -
Track defect patterns.
If AI-assisted work creates more regressions, roll usage back in that area. -
Separate speed metrics from quality metrics.
Otherwise the AI users will “win” on velocity while everyone else pays the cleanup tax later. -
Create an approved-use list.
Great for boilerplate, migration drafts, test scaffolds, docs, repetitive refactors.
Higher scrutiny for auth, concurrency, infra, compliance, and anything user-data related.
Pros for the ‘’: can improve readability, lower blank-page friction, and help standardize routine output. Cons for the ‘’: unclear governance, inconsistent quality, and the temptation to replace thinking with generation.
My take: seniors are not left behind for avoiding AI. They are left behind if they cannot evaluate when it helps, when it harms, and how to work with teammates who choose differently. That is the real senior skill now.