The Code Was Never the Hard Part
Why planning, not prompting, decides what lasts
For many years, the most expensive part of software was writing it. Requirements took weeks, design took weeks, and a working screen usually appeared somewhere in the second or third month. Every planning method we built, from waterfall to agile, assumed code was slow and costly to produce.
That assumption no longer holds. With AI-assisted development, what the industry now calls vibe coding, a person can describe an application in plain language and see it working the same afternoon. Business analysts, product managers and architects who have not written production code in years are building real tools again.
Having spent a career on IT architecture and delivery, I approached this with scepticism. After working this way for some months, I think it is genuinely transformative. I also think most people are using it in a way that will not last.
The first week is misleading
The early experience is remarkable. You ask for a login page, a dashboard, a form with validation, and they appear. The application looks finished and behaves as if it is.
This is exactly where the risk begins. A screen that looks complete tells you nothing about whether the system underneath is sound. Demos have always been good at hiding that gap. Vibe coding makes the demo arrive faster, which makes the gap easier to miss.
The second week tells the truth
The problems rarely appear on day one. They appear around the tenth change.
A small fix triggers a rewrite of something that was working. A new field breaks three screens that assumed it did not exist. After a break, the assistant has no memory of why a decision was made. Components get duplicated across folders. Code looks correct and is quietly wrong, delivered with complete confidence.
None of these failures are new. Anyone who has run large programmes has seen every one of them: scope drift, lost decisions, undocumented assumptions, no clear ownership of the data model. Vibe coding did not create these problems. It compressed them. What used to go wrong over a quarter now goes wrong within a week.
Old discipline still decides the outcome
What separates a vibe-coded prototype from a vibe-coded system is not the prompt. It is the thinking done before the prompt.
When the problem is clearly defined, the data model agreed and the business rules written down, the AI fills in a structure and does it well. When those things are missing, the AI invents a structure, and every subsequent request negotiates with that invention. The first approach gets faster over time. The second gets slower and more fragile with every change.
Context also has to be managed deliberately. An AI assistant starts every session as a capable new team member with no memory. Treating it that way, with a short, maintained briefing of current decisions, conventions and priorities, is the same discipline as a good handover note. It is simply written for a machine.
A guideline for sustainable vibe coding
For anything expected to still be running in six months, these practices matter more than the choice of tool.
Write the problem statement before the first prompt. One page covering who the user is, what task or decision is being supported, what success looks like and what is out of scope. If this cannot be written, the build is premature, and the AI will build the wrong thing very efficiently.
Design the data before the interface. Screens are cheap to regenerate. A poor data model is expensive to unwind once real records live in it. Agree the entities, relationships and rules first, and have someone who understands the business review them.
Keep decisions outside the conversation. The chat history is not documentation. Maintain a decision log in a file you control, recording what was decided and why. When the tool forgets, the log is the source of truth.
Work in small, reviewable steps. One change, tested and committed. Large requests produce large changes that nobody reviews properly. Version control matters more, not less, when you did not type the code yourself.
Understand what you ship. Not every line needs to be hand-written, but every line touching money, identity, personal data or security needs to be understood. "The AI wrote it" will not survive an incident review or an audit.
Set conventions early and enforce them. Decide folder structure, naming and approved patterns, and give them to the assistant every session. Without this, the codebase fragments quickly.
Build for the next maintainer. Someone will support this system, possibly its author a year later with no recollection of how it was built. If it only makes sense inside the conversation that produced it, it is not an asset. It is a liability with a good interface.
What is really being shipped
The conclusion is less about AI than it first appears.
The product is not what we are shipping. Code has become the cheapest part of software, and almost anyone can now generate an application that looks complete. What cannot be generated is a clear understanding of the problem, a sound model of the data, and a set of decisions that stay coherent as requirements change.
That is planning. In vibe coding, planning is the master brain. The AI is an extraordinarily fast pair of hands, and fast hands without direction simply produce mistakes at scale.
Think of a builder who can lay bricks ten times faster than anyone before. It is an impressive capability. But if nobody has drawn the plans, surveyed the ground or decided how many floors the building must eventually carry, that speed only means you reach the cracks sooner. The quality of the building was decided before the first brick was laid.
Software is no different. For those who understand the problem before they begin, vibe coding is the most productive approach to building software in a generation. For those who do not, it is the fastest route to something that will have to be rebuilt.
The code was never the hard part. It still isn't.