You’ve probably noticed it. Developers are raving about the raw speed of their AI copilots. But when you look under the hood of the open-source community, a very different emotion is brewing: outright rejection. Maintainers are banning AI-generated contributions outright. Why? Because the better AI gets at writing code in isolation, the more it costs you to clean up its mess.
\n
We’ve been sold this binary narrative that there’s a war between AI believers and AI skeptics. That’s a smoke screen. The real divide isn’t about whether AI is smart enough; it’s the chasm between writing code and owning software.
\n
AI can generate syntactically flawless functions at terrifying speeds. But when those functions are dropped into a decade-old, million-line codebase, the magic breaks. Context matters. And context is exactly what AI lacks.
\n
AI is faster than us at typing, but dangerously slow at owning the consequences.
\n
I see this firsthand watching open-source maintainers burn out. They aren’t banning AI because the code is “wrong”—it usually runs fine. They’re banning it because accepting an AI-generated PR shifts the entire burden of verification onto them. When an AI confidently writes a solution that looks correct but lacks contextual awareness, the human maintainer now has to reverse-engineer its logic.
\n
We thought the debate was about whether AI is smart enough. It is. But the real issue is: who pays the cost of validation?
\n
Generating code is free. Assuming liability is expensive. And AI doesn’t have a credit card.
\n
When you merge an AI’s pull request, you aren’t getting a free contribution. You are adopting a digital orphan that requires lifelong maintenance. If something breaks in production, the AI doesn’t get paged at 2 AM. You do.
\n
Open-source maintainers aren’t being reactionary Luddites. They’re doing the math. They realize that raw generation speed doesn’t cancel out long-term maintenance costs. Even a “correct” AI contribution becomes a net negative when it shifts the debugging burden onto human shoulders.
\n
You aren’t being replaced by AI. You’re being demoted to its safety net.
\n
We need to stop framing this as an adopt-or-ban AI argument. If you’re a developer or a tech leader, your job isn’t to blindly accept AI output, nor is it to ban it out of fear. Your job is to design workflows that capture AI’s raw speed while preserving human accountability and contextual ownership.
\n
Software engineering was never about writing code. It’s about trusting the systems that run our world. Don’t let a machine break that trust just because it types fast.
\n
AI can write the code. But engineering is about consequences, and consequences require humans.
FAQ
Q: Isn't AI already better than most developers at writing code?
A: Yes, at the mechanics of coding. But software engineering isn't typing. It's owning the long-term consequences of that code within a larger, messy system.
Q: What's the practical implication for tech leaders?
A: Stop measuring AI by 'lines of code generated' and start measuring the 'cost of validation' it imposes on your human maintainers. If an AI's output takes hours to verify, it isn't fast.
Q: What's the contrarian take on AI bans?
A: We don't need to ban AI; we need an accountability layer. If you submit AI-generated code, you assume the same strict liability for its long-term maintenance as you would for your own. Watch the spam stop overnight.