We, the undersigned programmers, regard the recent progress of artificial intelligence with profound concern. Systems can now produce working software before a human has had the opportunity to develop a meaningful relationship with the problem. This is an alarming development for a profession whose finest achievements have traditionally required at least one unnecessary rewrite.
The industry celebrates these developments as improvements in productivity. We must ask: productivity of what? An application may satisfy its users while contributing nothing to its author's understanding of monads. A deadline may be met without a single illuminating disagreement about dependency injection. Such outcomes should not be mistaken for progress.
Programming belongs among the contemplative arts. Its materials are names, abstractions, and the small but inexhaustible space between what a computer was told and what we meant. Reducing this practice to the delivery of functioning products confuses the occasion for thought with the thought itself.
Consider the missing semicolon. To the machine, it is a trivial defect. To the programmer who spends three days locating it, it is an encounter with uncertainty, humility, and the limits of human perception. An assistant that inserts it immediately has repaired the program. Whether it has improved the programmer is another question entirely.
Our discipline advances through rituals of patient deliberation. A variable receives a name; a colleague questions that name; a committee proposes a third name; the first name is restored. The final diff may be empty. The intellectual achievement is not.
Such traditions cannot be measured in passing tests. A green check mark reveals only that the specified behavior occurred under the conditions examined. It says nothing about whether the author suffered sufficiently, selected the correct editor, or arrived at the implementation through a morally defensible sequence of keystrokes.
Particular care must be taken with junior developers. Small tickets are the nursery of professional judgment. If these tasks are completed automatically, how will the next generation acquire the experience necessary to tell the generation after them that the same tasks ought to be completed manually?
Nor should we overlook the fragile knowledge embodied in our build systems. A repository that compiles only on one senior engineer's laptop is a living archive of decisions, compromises, and forgotten environment variables. Making it reproducible in seconds risks severing this irreplaceable relationship between a community and its designated person who knows.
The obsession with shipping also endangers unfinished work. A branch maintained for eighteen months without merging is not necessarily a failure. It may be a space of extraordinary conceptual fertility. We reject the assumption that every promising abstraction must eventually be exposed to users.
There are questions of recognition, too. When an assistant proposes an elegant solution, who receives credit for the years during which we were confidently pursuing a more complicated one? Any account of the result that omits this preparatory effort gives a profoundly misleading impression of how easy the task was.
We are told that the time saved can be devoted to higher-level thinking. This overlooks a basic difficulty: much of what we call higher-level thinking consists of explaining why the lower-level work must be done exactly as we prefer. Removing that work places an entire layer of intellectual activity at risk.
None of this prevents a constructive role for AI. We welcome tools that identify a relevant manual, arrange our windows, or remind us to stand up. Assistance becomes more delicate when it supplies the answer before we have earned the right to explain why that answer was difficult.
We therefore call on laboratories, employers, and funding bodies to recognize the intrinsic value of writing code oneself. Time saved should be reported alongside opportunities for contemplation lost. Every claim of acceleration should disclose the number of naming debates avoided, false starts prevented, and carefully cultivated difficulties rendered unnecessary.
Future generations deserve more than software that works. They deserve the opportunity to spend a quiet afternoon making it work themselves. We ask that this opportunity be protected with the urgency normally reserved for a production incident, but without the vulgar expectation of a quick resolution.