A proposed ext4 filesystem driver for OpenBSD has become a useful test case for a problem open-source projects are likely to face more often: what happens when code appears to work, but its development history depends heavily on AI tools? The driver, posted by developer Thomas de Grivel to the openbsd-tech mailing list in March, was described as providing read and write access and passing the e2fsck filesystem checker, while still lacking journaling support. That alone would have made it an interesting technical contribution. The controversy came from how the code was produced and how it could be reviewed.
According to discussion summarized by LWN and mirrored on public mailing-list archives, de Grivel later said the implementation was built with ChatGPT and Claude Code, alongside his own review, builds and tests. He also argued that he had not read Linux source files to create the driver. That claim did not settle the matter for OpenBSD developers. If anything, it sharpened the debate: an AI-generated implementation of a filesystem closely associated with Linux raises questions about copyright provenance, licensing contamination and long-term maintainability.
Working code is not the same as acceptable code
Filesystems sit in one of the least forgiving parts of an operating system. A subtle bug can corrupt user data, expose security issues or create maintenance debt that lasts for years. OpenBSD has a long culture of conservative review, small interfaces and readable code. A driver that passes a checker is therefore not automatically ready for inclusion, especially when it adds complex ext4 behavior such as extents and checksums without journaling.
The AI angle makes the review harder rather than easier. If a human developer writes code from documentation and can explain every design choice, reviewers can challenge those choices directly. If large parts of the implementation were generated from prompts, reviewers must also ask whether the output resembles GPL-licensed Linux code, whether the author understands enough to maintain it, and whether the project can accept the legal risk. Those questions remain even if the driver appears functional in limited testing.
The licensing concern is not theoretical
The central issue is not simply whether AI tools are allowed in software development. The issue is provenance. ext4 is implemented in the Linux kernel under the GPL, while OpenBSD uses a permissive licensing culture and avoids importing GPL code into the base system. If an AI system was trained on Linux code and then generates a similar filesystem implementation, contributors and reviewers have to decide whether that output is independent enough to accept. Current law and project policy do not provide a simple automatic answer.
OpenBSD developers and outside observers also focused on documentation. Even if no Linux source file was opened during the work, ext4 documentation, examples and existing code discussions often lead back to GPL-covered material. For a project that treats licensing as a core engineering constraint, uncertainty can be enough to reject or delay a change.
Why this matters beyond OpenBSD
The OpenBSD ext4 episode is bigger than one driver. AI-assisted coding tools are now capable of producing large patches quickly, including code that compiles, passes tests and looks plausible. That speed is attractive, but infrastructure projects cannot judge contributions only by first-run behavior. They need maintainers, test coverage, design rationale, license clarity and a path for future fixes.
For commercial teams, the lesson is similar. A generated driver, parser or security-sensitive component may reduce development time, but it can also create obligations that are difficult to audit later. The safest workflow is not “AI wrote it, ship it.” It is documented prompting, human design review, source provenance checks, test evidence and clear responsibility for maintenance.
A useful warning, not a simple rejection of AI
The episode does not prove that AI tools have no place in systems programming. They can help explore approaches, write tests, explain unfamiliar APIs and accelerate routine work. The OpenBSD debate shows where the boundary becomes stricter: low-level code that touches data integrity, security or licensing boundaries must meet a higher standard than “the model produced something that boots.”
In that sense, the ext4 driver is a valuable warning. AI-assisted development is moving faster than the policies that judge it. Open-source projects will need clearer contribution rules, and developers using AI will need to be much more explicit about what the tool generated, what sources were consulted and who is prepared to maintain the result. Until then, a working patch can still fail the most important review: whether the project can safely own it.
