It is 2026. AI has infiltrated the market for the past few years. The so called "vibe-coders" cry out in unison: For what is Software? It is vapour which appeareth for a little while and afterwards shall vanish away. For that you should say: If AI wills it, and, If we shall live, we will do this or that. On the other side, a handful of hardened, disgruntled engineers, unconvinced by the great Evil try to cast away Moloch by any means necessary. This dynamic has been going on for atleast the last two years, and the AI-bros are winning ground day by day. So what now? Do we just accept the inevitable, do we turn the creative spirit of software development into a mere mechanical process?
I have been reading lots of different blogs, articles about how to incorporate AI into my current workflow, from infinitely more experienced developers than me. A lot of them never go beyond an Agents.md file, loop prompts infinitely and at some point write, that AI is basically useless (at best inefficient). Horror stories from newgrads not being able to define what an array is but confidently asserting that they do not write any code anymore. This is not only a problem in SWE, it seems to happen in almost every white-collar industry.
So I ask myself - why see those things exclusionary? Why not just rejoice in the fact that you need to not humble yerself to do some dumb task that took a whole day to complete and focus on the real task of engineering software: making good software.
I really think more people would benefit from viewing todays models as a more sophisticated codegen tool, something akin to a Java annotation processor just for every language and most white collar tasks. Similar to those annotation you cannot just will it and have good software. In many cases, an annotator can be more of a problem and hinder your process more than helping it.
For code is cheap now, yes. Cheaper than it has ever been. But correctness has not become cheap. Taste has not become cheap. Knowing which abstraction will become a tomb for future maintainers has not become cheap. Knowing when not to build, when to delete, when to leave the clever thing unborn... these have not been automated away. If anything, they have become more precious, because the world is now full of entities willing to generate an infinite amount of plausible nonsense at near-zero marginal cost.
This is why the great replacement story feels so hollow to me. It imagines software development as if it were merely the production of syntax, as if the business of engineering were to summon tokens in the right order until the compiler ceases its lamentations. But this was never the hard part. The hard part was always deciding what ought to exist, what must not break, what can be made simple, what can be safely ignored, and what future poor soul must be spared from cursing your name at 3:17 in the morning.
So no, I do not think we should throw away these tools. That would be its own kind of vanity, a monkish pride in toil for toil’s sake. There is no holiness in manually writing the fourteenth CRUD endpoint of the week. There is no virtue in spending an afternoon moving fields from one representation to another while pretending that suffering is craftsmanship. Much of what we called “work” was merely tribute paid to accidental complexity, and if the machine can carry some of that burden, let it carry it.
But neither should we kneel.
The right posture, I think, is neither worship nor exorcism. It is domestication. Treat the model as one treats fire, or SQL, or macros, or reflection, or inheritance after the third level: powerful, treacherous, useful in the hands of the disciplined, ruinous in the hands of the intoxicated. Let it draft. Let it scaffold. Let it search the dark corners of documentation and return with strange little offerings. But do not let it decide the shape of the system. Do not let it become the architect by default merely because it speaks first.