For years we have been told that speed is everything. That shipping faster is the only metric that matters. We are being told that the backlog is dead, that human bandwidth is a bottleneck, and that the future belongs to whoever presses the AI’s generate button hardest.

We reject this.

Not because we fear change, but because we have used these tools, and we have seen what happens when people stop caring about the output. We have seen skills abandoned, standards dropped, and products shipped that no one can explain, maintain, or bring themselves to care about. We have been told this is progress.

It is not.

We are tired of the hype

In 2001, the Agile Manifesto reminded us that individuals and interactions matter more than processes and tools. That working software matters more than comprehensive documentation. That responding to change matters more than following a plan.

In 2009, the Software Craftsmanship Manifesto went further: not just working software, but well-crafted software. Not just responding to change, but steadily adding value. Not just individuals and interactions, but a community of professionals. Not just customer collaboration, but productive partnerships.

Now in 2026, the age of generative AI, we need go further still. Not just well-crafted software, but software we understand. Not just a community of professionals, but engineers who own what they ship. Not just productive partnerships, but human responsibility is required as well.

Because somewhere along the way, we confused generating code with building software. They are not the same thing. Writing the code was never the problem. And the stakes have never been higher: software is no longer a convenience, it is a matter of life and death.

What we value

Less code over more code, because every line is a liability. The best solution is the smallest one that works. AI can generate a thousand lines in seconds, and that is exactly the problem. Good engineering removes code. Great engineering never writes it in the first place.

Tested code over generated code, because if it is not tested, it does not work. It just appears to work, which is worse. And a passing test suite is not proof either, a thousand green checks that test nothing are just decoration. Valuable tests prove behavior that matters. They catch the bug before the user does. They are the only honest documentation your code will ever have.

Quality over speed, always, because sloppy work is not a tradeoff, it is a failure. There is no deadline, no sprint, no business case that justifies shipping something you know is sloppy designed. Quality is not a phase you add later. It is the way you work, or it is absent.

Value delivered over lines produced, because software exists to solve problems for real people. Not to impress a metrics dashboard. Not to fill a pull request. One function that saves a user ten minutes a day is worth more than ten thousand lines of generated scaffolding nobody asked for.

Good abstractions over fast implementations, because the cost of software is not writing it. It is reading it, changing it, debugging it, and explaining it to the next person. Code that is easy to change is more valuable than code that was fast to produce. If you cannot draw the boundaries, you do not understand the problem yet.

Responsibility over delegation, because production is not a playground. When the system fails at 3 AM, a human answers the call. Not a tool, not a prompt, not a process. You. If you shipped it, you own it. “The AI wrote it” is not an incident response. It never was. It never will be.

Understanding over output, because code you cannot explain is code you cannot fix. It does not matter how the code was produced. If you do not understand it, you cannot maintain it, evolve it, or take responsibility for it. The standard is the same regardless of the tool.

Craft over convenience, because we have seen what happens when people optimize purely for speed and stop holding themselves accountable for the result. You get software no one can maintain, teams that cannot onboard, systems that cannot evolve, and engineers that cannot feel proud of what they made because they do not understand it. We refuse to call that progress.

We use tools

We have always used tools. Compilers, frameworks, linters, CI pipelines, autocomplete, we are not afraid of leverage. AI is one more tool. A powerful one. We embrace it. Used well, it amplifies human creativity and frees us to spend less time on repetitive tasks and more time solving meaningful problems. But like every powerful tool, it demands more skill from the person using it, not less.

A calculator makes a mathematician faster. It does not make someone who has never studied mathematics into one. And when the result looks wrong, only the mathematician knows. The tool did not lower the bar. The tool never does. People do, when they stop paying attention.

The question was never whether to use AI. The question is whether we maintain the highest standards of quality and ethics while doing so. We are tired of the false binary: “adopt AI completely or get left behind.” As if the only options are full surrender or irrelevance. As if using your brain is now a competitive disadvantage.

We have seen what happens when people stop holding themselves to a standard: software no one understands and products no one is proud of.

We can do better.

What we commit to

  1. If we cannot explain it, we do not ship it. No exceptions. No tool changes this. Every line that goes to production, we can defend.
  2. We add as little code as possible. Less code, fewer problems, better software. The best solution is the simplest one.
  3. We test what matters and we prove it works. Not test counts. Not coverage percentages. Proof. If the tests do not catch the bug before the user does, we failed.
  4. We never compromise on quality. Not for deadlines, not for demos, not for “we will fix it later.” There is no shortcut that does not come back to haunt you. We do it right or we do not do it.
  5. We own what runs. Production is ours. When it breaks, we fix it. A tool cannot be paged at 3 AM. We can. That is the job.
  6. We keep learning. We practice our craft. We sharpen our skills. We do not let any tool make us lazy, dependent, or dull. The day we stop growing is the day we stop being engineers.

It was always about the people

The Agile Manifesto said it first: individuals and interactions over processes and tools. Somehow, twenty-five years later, we need to say it again, louder this time, because the narrative has shifted to one where the tool matters more than the person using it.

You are not a bottleneck. You are not a token budget. You are not a “human in the loop” rubberstamping machine output.

You are a maker, a thinker, and a professional. You decide what ships. You decide what is good enough. You bear the responsibility. That has not changed. No tool changes that.

The code we write is ours. The quality we demand is ours. The responsibility we carry is ours. Tools do not change that. Nothing does.

We built this profession with our hands and our minds. No tool changes the essence of the craft, or what it demands of those who practice it.

Inspired by the Agile Manifesto (2001), the Manifesto for Software Craftsmanship (2009), and the growing unease of every developer who is told that AI tools are a silver bullet.