DOP 346: Fighting AI in Your Project Is a Terrible Mistake

Episode 346

Show Notes

#346: Drive-by PRs, AI slop, maintainers burning out – the open source world is having a meltdown and everyone wants to blame the robots. Viktor isn’t buying it.

The real problem started long before AI. Contributing to most open source projects has always depended on tribal knowledge and obscure docs nobody reads. AI didn’t break that. It exposed it. When contributions were trickling in, you could get away with onboarding people via vibes. Now that contributions are a firehose, you can’t.

Viktor’s take cuts in a direction that will annoy a lot of maintainers: your primary job is empowering contributors, not gatekeeping. And if a 20,000-line PR is drowning you, the answer isn’t to block everybody. The answer is to change the whole review cycle – because yesterday you were complaining about not enough contributions and today you’re complaining about too many. That’s a great problem to have. Solve it.

Here’s the part that will upset people. Viktor reframes what a developer’s job actually is. If you think your role is typing on a keyboard, you’re going to be disappointed. Your role is becoming a product manager. Asking the agent did you look at this, are you sure, what about that. Your job is no more. You just didn’t receive the memo.

There’s also a thread running through the episode about auditing. Can you actually assess the health of an open source dependency you depend on? Viktor dares Darin to audit Kubernetes. Or curl. Or anything. Humans can’t do it at all. AI can – imperfectly, but better than nothing. Which means the old enterprise model (pay Red Hat, they’ll handle it) starts to wobble when the value of someone else handling it drops because the tools can handle it for you.

And there’s a prediction. Right now when you ask AI to build something, it picks libraries based on training data. But what happens when the agent actually goes shopping – analyzing projects, reading docs, deciding which dependencies to pull in? That changes the open source landscape in a way nobody is ready for.

The episode ends somewhere quieter. Contributors, human or AI, should be cherished and trained over time. The hostility toward AI contributions is coming from maintainers who forgot that investing in new contributors is the job. The tools will make a mess. Then they will make less of a mess. Eventually we will be arguing about whether the feature should exist at all – not whether the code compiles.

Frequently Asked Questions

Should an open source project ban AI-generated contributions?

Viktor Farcic calls that a terrible mistake on DevOps Paradox episode 346. His position is that a maintainer’s primary role is empowering people to contribute, and that the barrier to entry has never been lower than it is now. Rather than fighting it, he argues for putting the guidance into the repository itself through an agents.md, skills and rule sets, replacing the tribal knowledge contributing has always depended on.

Can you tell whether a pull request was written by AI?

Viktor Farcic’s answer on DevOps Paradox episode 346 is that you cannot. The only available signal is noticing that no human would have been willing to do it, which he rejects as a criterion. He redirects the question toward instructions instead: how good generated code turns out depends heavily on the guidance it was given, so a project supplying none has largely chosen its own results.

Is zero tolerance for bad AI contributions a sensible policy?

Viktor Farcic reframes it on DevOps Paradox episode 346 by removing one word: zero tolerance for bad contributions. Whether a person, an agent, or his mother wrote it does not change whether it is bad. His harder question is what counts as bad, because a project that has not written that down is judging contributions on the maintainer’s taste and asking contributors to guess it.

How should you audit the health of an open source dependency?

Viktor Farcic argues on DevOps Paradox episode 346 that no human can do it honestly, daring Darin Pope to assess Kubernetes, or even curl, on his own. He narrows the question to context: what matters is the portion of a library your application actually uses and how it uses it, rather than the whole library. He adds that conventional audits cost so much they get treated as permanent once passed.

Is a 2,000 dollar a year sponsorship worth a maintainer's time?

Darin Pope runs the numbers on DevOps Paradox episode 346 and reaches roughly 40 dollars a week, or 8 dollars a day, which he says does not justify the work. Viktor Farcic agrees it cannot be anyone’s income, but values it as recognition on a project someone already works on out of passion. His reasoning is that money is real recognition, where a virtual sticker costs nothing.

What happens to companies selling enterprise versions of open source?

Viktor Farcic lays out the squeeze on DevOps Paradox episode 346. That business rests on customers being able to do the work themselves at far greater cost than the license. As AI lowers the cost of doing it yourself, he sees three possible outcomes: prices fall to stay competitive, the products go away, or the vendor drastically increases what it adds on top, which hiring more people cannot pay for.

What is the DevOps Paradox podcast?

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 346, “Fighting AI in Your Project Is a Terrible Mistake,” works through how curl and Ghostty responded to AI-assisted pull requests, what a dependency audit can honestly cover, and how funding models for maintainers hold up. Every episode page carries the audio, the video, and a full transcript.

Episode Transcript

Read the Full Transcript

Topics

Share and Download

Hosts

Darin Pope

Darin Pope

Viktor Farcic

Viktor Farcic

Viktor Farcic is a member of the Google Developer Experts and Docker Captains groups, and published author.

His big passions are DevOps, Containers, Kubernetes, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).

He often speaks at community gatherings and conferences.

He has published DevOps Paradox and Test-Driven Java Development.

His random thoughts and tutorials can be found in his blog The DevOps Toolkit.