Unless you’ve been living under an old woodpile in your backyard, you have certainly seen how agentic coding is rocking the software development world. Things are happening fast and furious, and keeping up is practically a full-time job. 

The latest area that is catching the attention of developers is how agentic coding is affecting the open source community. The open source movement has been defending the rights of folks to use, change, and contribute to software for many years. And of course, agentic coding is starting to become part of that process.

On the one hand, maintainers of open source projects rightfully are frustrated as they become overwhelmed with pull requests of dubious quality and usefulness being submitted by coding agents. On the other hand, as David Heinemeier Hansson notes, maintainers are starting to get a little snooty about accepting AI-written code, viewing it as somehow not worthy of being included. Some organizations have explicitly banned AI-generated submissions.

I get that they don’t want AI slop overwhelming their input queues. But I think it is a huge mistake to ban AI-written code outright.

Whose code?

Before I dig deeper into that notion, it’s important to look at another issue that arises from all of this: Who actually owns the code that AI writes? 

Copyright requires that a human produce the thing being copyrighted. If you prompt Claude Code with “Write me a CMS system” and then Claude writes you a CMS system that you check into a public GitHub repository unchanged, it’s not quite clear if that code is protected by copyright. However, if you prompt Claude Code with a specification and guidelines and then you work with Claude to refine the initial result, reviewing the code and making changes as part of an iterative process, then it could be argued that a human did produce that code. But it is not at all clear-cut legally. (Please note that I am not a lawyer.)

The current thinking is that the result of accepting verbatim the output of a simple prompt is not copyrightable, and that no one actually owns the code — an interesting notion in and of itself. 

But then the ethical question comes into play. If I find a bug in an open source project, I ask GitHub Copilot to fix it, and Copilot writes a clever and effective fix, then who cares who owns the code? Should a maintainer of the project reject such a pull request just because it was AI-generated? That seems silly to me, yet it is happening today. 

Our code

There is, too, the issue of license compliance for AI-generated code. As a general rule, LLMs generate code rather than copying it. They don’t copy and paste code directly from repositories. However, there have been cases where AI-produced code has resembled open source code so closely that the claim could be made that it is a copy. If this happens with GPL code, it could be a violation of the license to use it without the receiving code base being “infected.” Open source maintainers naturally should be concerned about this happening.

In the end, an open source maintainer should care about the quality and license compliance of submissions, not how those submissions were derived. Gatekeeping based on the source of code doesn’t seem like a good path towards project success. Good code is good code, no matter where it comes from.

Agentic coding is here, and the open source community needs to realize — and embrace — that inevitability.

OpenAI has launched a program with cybersecurity firm Trail of Bits to use AI to find and fix vulnerabilities in widely used open-source software, as enterprises face growing risks from flaws buried deep in their software supply chains.

The initiative, called Patch the Planet, uses AI-assisted vulnerability research alongside human review to help turn security findings into tested fixes that can be disclosed through existing project channels.

Initial participants include Python, Go, cURL, Sigstore, NATS Server, aiohttp, freenginx, pyca/cryptography, and python.org. These projects support software development, networking, cryptography, and supply chain infrastructure used across a wide range of enterprise applications and services.

OpenAI said each engagement will begin with consultation with maintainers to identify where security support is most needed. Researchers will then investigate potential vulnerabilities, validate meaningful issues, develop or refine patches, support testing, and coordinate disclosure through the project’s existing channels.

Participating security researchers will use the company’s models and Codex Security to analyze code and help move fixes toward release. Trail of Bits engineers will review findings before they are sent to maintainers, a step meant to filter out false positives and duplicate reports before they add to the workload of open-source projects.

The company is also working with HackerOne and Calif to support vulnerability triage, coordinated disclosure, and additional discovery work as the program expands.

OpenAI said work under the program has already identified “hundreds of security issues and merged dozens of patches, with many more still undergoing coordinated disclosure.”

The work has also produced tools for fuzzing, historical CVE analysis, and differential testing, along with systems to filter inaccurate findings before patches are generated, OpenAI added.

The focus on open-source security follows incidents such as Log4Shell and the XZ Utils backdoor, which showed how quickly a flaw in a shared component can move through enterprise software.

Analysts said Patch the Planet changes the risk equation only if enterprises treat AI-assisted vulnerability research as an input to a broader software supply chain risk program, not as a substitute for one.

“The key shift is speed: AI-assisted research can help find, validate, patch, test, and document issues faster, while human reviewers reduce false positives before maintainers are burdened,” said Biswajeet Mahapatra, principal analyst at Forrester. “But the dependency on scarce expertise does not go away; it moves to triage, exploitability judgment, patch safety, disclosure timing, and production rollout.”

Guardrails before deployment

CISOs should put governance controls in place before using AI-assisted vulnerability research in enterprise security pipelines, to ensure unverified findings do not overwhelm engineering teams, said Devashri Datta, an open-source cybersecurity architect.

“CISOs should demand a Safety Relevance Layer in their risk modeling, a structured framework that requires every AI-generated finding to pass automated verification, including dynamic proof-of-concept validation and strong false-positive filtering, before it reaches a human analyst,” Datta said.

Those controls should also cover disclosure, particularly when AI tools identify flaws in third-party open-source components that the enterprise does not control, Datta said. Organizations need predefined escalation paths, notification timelines, and role assignments that take effect once a confirmed issue is found in an external dependency.

“Ad hoc disclosure in an AI-accelerated environment isn’t just a process gap; it’s a liability,” Datta said. “Trusting AI in the production pipeline requires verifiable auditability: organizations must be able to trace why the AI flagged a line of code, how it validated the exploit, and how it determined that the patch would not break downstream production systems.”

Continuous exposure reduction

AI-assisted vulnerability research could force enterprises to move away from periodic patching cycles and toward more continuous risk assessment, analysts said. If variant analysis and differential testing can be compressed from weeks to days, security teams may need faster ways to decide which findings matter most in their own environments.

That shift also means enterprises can no longer rely only on generic CVSS scores to prioritize remediation, Datta said. Findings will need to be assessed against the affected system, its business role, runtime exposure and the likelihood that a flaw can be exploited.

“We have to move toward context-aware, safety-critical prioritization,” Datta said. “Enterprise SBOM and VEX programs must evolve from passive compliance spreadsheets into live, machine-readable data feeds. For AI-assisted pipelines specifically, that means extending the VEX model to cover AI-introduced risk surfaces.”

Mahapatra said vulnerability management programs will also need to become more closely tied to software ownership, supplier response, and business impact.

“Security teams should move from periodic vulnerability handling to continuous exposure reduction,” Mahapatra said.

That means SBOMs should be treated as live inventories tied to runtime exposure and supplier response, rather than static compliance documents. Patch decisions should also account for asset criticality, exploitability, compensating controls, and business impact.

The article originally appeared on CSO.