AI Writes Code Now. So What Changes?

Forty-five years of pattern recognition on the latest thing that changes everything.

In the early 1990s, I was on the beta program for Microsoft Visual Basic – one of a very small number of developers in Australia with early access. I was contracting alone for an experienced engineering project manager, building a tool that post-processed Microsoft Project files: advanced calculations, reporting across sets of files. I remember the quality of the enthusiasm I felt. VB let me drag a button onto a form, double-click it, and write the code that would run when a user clicked it. I could see the interface taking shape in real time. I could iterate on the layout in minutes rather than hours.

Before that, building a graphical application for Windows meant managing an event loop in code – a constant cycle in which your program checked what was happening in the operating system, decided which events it cared about, handled them, asked for a screen redraw, did the redrawing, and carefully released enough processing resources to let other programs continue running. To say it was complex is an understatement. Iterative interface design – trying something, seeing how it felt, adjusting – was genuinely difficult. VB changed all of that. It made GUI development accessible in a way that nothing had before.

I evangelised it to every developer I knew. Most of them couldn’t see it yet. They came around.

But it wasn’t all good. VB’s accessibility attracted less expert programmers and non-programmers who had dabbled in Basic on a home PC. Much of what followed was a mess. Business logic became deeply entangled with visual components. Software was shipped without adequate testing – automated testing of GUI applications was poorly understood, and the people building in VB often weren’t experienced enough to know what they didn’t know. An old industry adage proved itself, repeatedly: you can write COBOL in any language. The tool changes. The thinking required to use it well does not.

I have been watching the current conversation about AI and software development with a strong sense of familiarity.

The phenomenon has acquired a name vibe coding – which captures it well: using an AI assistant to generate code through conversation, iterating on the output, shipping the result. The parallels with the VB moment are not subtle. A technology arrives that makes programming accessible to people who couldn’t previously do it, and dramatically accelerates the work of people who could. The coverage is enthusiastic. The evangelists are out in force. The consequences that nobody is quite ready to discuss are already accumulating.

Let me be honest about both sides.

What genuinely changes is real. The speed at which an experienced developer can implement well-understood functionality has increased substantially. Boilerplate, routine integrations, the first draft of a feature – AI handles these faster than any human. For personal projects and small-scale tools, vibe coding works: if something goes wrong, the person who built it is close enough to notice and fix it. The barrier to building software has lowered again, and some of what gets built at that lower barrier is genuinely useful.

What doesn’t change is more important.

The else clause doesn’t care how the code was generated. I wrote recently about the moment a developer implementing a payment feature types the word “else” and stops – confronted by the cascade of questions that only become visible at the point of implementation. What happens when the payment gateway times out? When the card is declined for one of several distinct reasons? When the payment succeeds but the confirmation email fails? None of those questions are in the AI prompt. They are only visible from close range, and answering them requires judgment that the AI does not have and the vibe coder may not have either. For a personal project, an unhandled edge case is an inconvenience. For a system handling real transactions for real customers, it is something else entirely.

The belief that design is now optional is gaining traction in places that should know better. The idea that you can describe what you want in conversation with an AI and deploy the result – without thinking through requirements, failure modes, or any of the work that precedes responsible implementation – does not work for software of any significance. The AI will generate something. It will often look plausible. What it will not do is tell you what you forgot to ask for.

The consequences for professional developers are serious and largely absent from the coverage. Senior developers – whose job has always included reviewing and correcting the work of more junior colleagues – are now contending with code being generated at a pace no review process was designed to handle. The volume is extraordinary. The quality varies enormously. Seniors are increasingly seen as the bottleneck in the “construction” of software, are being pushed to review faster, and are burning out. This is not a hypothetical. It is happening now, in organisations that have adopted AI coding tools without thinking through what happens to the humans in the loop.

And then there is the question I find most troubling.

Junior developers learn to become senior developers by encountering problems. The obtuse error message that takes two days to diagnose and turns out to be a network configuration issue on one specific server. The unexpected interaction between two libraries that produces behaviour nobody anticipated. The edge case that only surfaces under load, at 2am, in production. These encounters are not inefficiencies to be optimised away. They are the education. A junior developer who generates code through an AI assistant and ships it without deeply understanding what it does is not building the judgment that the industry will need from them in ten years.

So. What changes?

The speed at which you can build the wrong thing increases dramatically. The thinking required to build the right thing does not. And the people the industry will need to do that thinking – experienced enough to know what questions the AI isn’t asking – are burning out at the senior end and failing to develop at the junior end.

Nobody seems to be treating that as the emergency it is.