Daniel Stenberg Argues Humans Must Stay in Control of curl, AI or Not
#Dev

Daniel Stenberg Argues Humans Must Stay in Control of curl, AI or Not

Tech Essays Reporter
7 min read

The curl maintainer stakes out a middle position in the AI coding debate: use the tools, including AI-powered ones, but never surrender the human judgment that decides what gets merged. His argument is less about resisting automation than about defining what software stewardship actually requires.

Daniel Stenberg, the developer behind curl, has spent more than two and a half decades maintaining one of the most widely deployed pieces of software on the planet. It ships in cars, phones, game consoles, television sets, and roughly every operating system that matters. So when he writes about how artificial intelligence fits into a project of that scale and longevity, the argument carries the weight of someone who has actually lived with the consequences of every line of code he has accepted. His recent post stakes out a position that refuses both of the loud extremes currently shouting at each other across the industry.

The thesis: control, not abstinence

Stenberg frames the present moment as a field with two poles. On one end stand the "vibe coders," developers who let agents write and merge code with no human ever reading the source. On the other stand the absolutists who reject anything touched by AI on principle. His own stance sits deliberately between them, and the precise shape of that middle ground is what makes the piece worth reading. He is not arguing for moderation as a comfortable compromise. He is arguing that a specific human responsibility, the act of standing behind merged code as a person, cannot be delegated to a machine without changing what the project fundamentally is.

The distinction he draws is sharp. Tools that help humans make better decisions are welcome, including AI tools. What is not welcome is the transfer of accountability. "We stand for every bit of code we merge, as humans," he writes, and that sentence does most of the philosophical work in the essay. The question is never whether AI participated in producing a change. The question is whether a human determined that change to be correct, fitting, and worth defending over the decades the code will live.

Featured image

The arguments: where AI helps and where it cannot

Stenberg builds his case by separating software development into activities that have very different relationships to automation. The first observation is almost disarmingly even-handed: AI makes mistakes, and so do humans. He notes that some data suggests AI-generated code may carry a higher error density than human-written code, but he refuses to treat this as a knockout argument, because human code is hardly pristine either. The entire apparatus of test cases and code review was invented precisely because people are fallible. The method by which code was written, he argues, does not subtract from the value of reviewing it. A good review catches omissions and slip-ups regardless of provenance, and it does something subtler as well: it reinforces the architecture and the established design choices that hold a long-lived project together.

This is where his thinking gets interesting, because he then turns the same skepticism on AI review bots. Automated reviewers, in his experience, have not yet replaced human reviewers. They are not good enough. Human reviews catch different things and keep proposed changes aligned with the project's direction. Yet he immediately complicates his own position rather than resting on it. In a sufficiently complicated change, he observes, the AI PR review bots often surface a legitimate issue after the human reviewers have exhausted their findings. Sometimes the bot is wrong and the comment is dismissed in seconds. More often than he might have expected, the finding is real and worth addressing before merge. Human review is better, and also the inverse is true in particular cases. Both statements coexist because they describe different kinds of error and different kinds of attention.

The deeper argument concerns knowledge itself. Stenberg wants to understand how curl works. He does not claim intimate command of every corner, but he knows most of it, and that knowledge is not a vanity. It lets him make better decisions, debug more effectively, help users, and keep the architecture coherent. Writing the initial code, he insists, is not the hard part. The real task is maintaining and polishing landed code across decades. A model that produces a plausible function in seconds does nothing to discharge the multi-year obligation that begins the moment the function is merged. This reframing matters because so much of the current enthusiasm measures AI by its speed at the cheapest stage of the work while ignoring the expensive stage that follows.

The implications: communication is a human channel

The most pointed section of the essay concerns communication rather than code. Open source, Stenberg reminds readers, is a development model conducted in the open, and the communication part is the key to the whole arrangement. People share ideas, describe problems, express what they want, and the team responds and works together. This depends on human-to-human interaction. Dropping a large AI-generated, tone-deaf wall of text into that flow can technically work, in roughly the same way that people can learn to work with difficult individuals, but it introduces friction into a process that runs on goodwill and clarity. He calls it sand in the machine, and he calls it rude. The judgment is blunt and it is aimed at a behavior that has become common in projects flooded with low-effort AI-assisted contributions and bug reports.

The implication for maintainers is that the social layer of open source has its own integrity that automation can degrade even when the underlying code is fine. A contribution is not just a diff. It is a conversation, a claim about intent, and a request for trust. When that conversation is generated rather than meant, the cost lands on the humans who must still read it, evaluate it, and respond to it as if it were sincere. curl has been on the receiving end of this dynamic publicly, particularly in the context of AI-generated security reports that consumed maintainer time without producing real findings, which gives this section a grounding in lived frustration rather than abstract worry.

Counter-perspectives and the limits of the position

The vibe-coding camp would reply that Stenberg is describing a transitional inconvenience rather than a permanent boundary. If AI review bots already catch issues that experienced humans miss, the trajectory points toward systems that will eventually review better than people, at which point insisting on human sign-off becomes ceremony rather than safeguard. Stenberg does not directly refute this, and to his credit he does not pretend the tools are static. His answer is implicit in his emphasis on accountability: even a hypothetically superior reviewer does not resolve the question of who stands behind the product when it fails in the field. Responsibility is not a capability that scales with model quality. It is a relationship between a person and the people who depend on their work.

There is also a tension the essay leaves productively unresolved. If the best mistake-detecting tools today already use AI, and if those tools genuinely make the code better, then AI is woven into curl's quality process at a level deeper than mere assistance. Stenberg's framing holds because he locates the human not at every step but at the decision point, the merge. The machines can write, suggest, scan, and flag. The human decides. Whether that decision point can hold its current position as tools improve is the open question the industry will answer over the next several years, project by project, rather than through any single pronouncement.

What Stenberg offers is not a prediction but a commitment, and a clear account of the values behind it. curl is developed and driven by humans, assisted by tools, and it will remain that way as long as he and the core team run it. The essay's quiet confidence comes from the fact that this is not a theoretical stance for him. It is a description of how a critical piece of global infrastructure has actually been kept alive and trustworthy, and a refusal to outsource the part of that work that gives it meaning. For developers wrestling with where to draw their own lines, the curl model offers a concrete reference point: embrace the tools, interrogate their output, communicate as humans, and never let the convenience of generation erode the obligation of stewardship.

Comments

Loading comments...