AI can write code. Building software is another story.

There is no denying it anymore. AI coding assistants have changed the way software is built. Tasks that once took hours can now be completed in minutes. Need a new API endpoint? A database migration? Unit tests? A decent coding assistant will usually get you 80 percent of the way there before you've finished your coffee. That is genuinely impressive. It is also where many teams start getting into trouble.

Because there is a big difference between writing code and building software. One is about producing functionality. The other is about creating systems that remain understandable, secure and maintainable years after the first release. That distinction was the central theme of software engineer Dex Horthy's talk No Vibes Allowed. His message was refreshingly simple. AI is becoming an incredible development tool, but it is still a poor substitute for engineering judgement.

The rise of “vibe coding”

A new term has appeared over the past year: vibe coding. It describes a style of development where developers simply describe what they want, accept the generated code, make a few tweaks and move on. For small projects, prototypes or internal tools, this can work surprisingly well. Modern language models are exceptionally good at recognising patterns and producing code that compiles. The problem starts when that same approach is applied to production software.

Real business applications are rarely greenfield projects. Most organisations are working with systems that have evolved over many years. They contain business rules, security controls, integrations, legacy components and architectural decisions that were made for reasons people may barely remember today. An AI model only sees the code in front of it. It does not understand why a particular pattern exists or what problem it solved five years ago. It sees structure, not history. That difference is often where technical debt begins.

More code does not equal more value

One of the biggest misconceptions around AI-assisted development is that more generated code automatically means higher productivity. In reality, every line of code carries a cost. Someone has to review it. Someone has to test it. Someone will eventually debug it. Six months later, someone will try to understand why it exists in the first place. Without clear guidance, AI has a tendency to optimise for solving the immediate problem rather than preserving the health of the overall system.

You often see the same patterns appear:

• Existing functionality gets duplicated because the model did not know it already existed.
• New helper classes appear instead of reusing existing services.
• Entire sections are rewritten when a small refactor would have been enough.
• Compatibility layers remain in place long after they have stopped providing value.

None of these changes look particularly dangerous in isolation. Collectively, they slowly make a codebase harder to understand and more expensive to maintain. Ironically, many teams eventually spend their time cleaning up yesterday's AI-generated code instead of building tomorrow's features.

Context matters more than prompts

People often ask why AI performs brilliantly on a small demo but struggles inside a large enterprise application. The answer is context. A mature codebase is far more than a collection of files. It represents years of decisions, trade-offs and business knowledge. Some decisions exist for performance reasons. Others satisfy compliance requirements or support long-standing customer integrations. Many make little sense until you understand the wider system. An AI model simply cannot infer all of that from a handful of files. That is why vague prompts such as “implement this feature” often produce disappointing results.

The best teams provide constraints instead of freedom. They tell the AI to follow existing architectural patterns, reuse established services, avoid introducing unnecessary dependencies and keep solutions as simple as possible.

In other words, they provide the engineering judgement that the model lacks.

Think of AI as another developer

Perhaps the healthiest way to view an AI coding assistant is as a very capable junior developer. It works incredibly fast. It remembers syntax better than most humans. It never gets tired of writing boilerplate code or generating unit tests. What it lacks is experience. It does not instinctively recognise when a small refactor is safer than a complete rewrite. It cannot judge whether a complicated abstraction is solving a real business problem or simply adding unnecessary complexity. It does not know when the best decision is to leave well-functioning code alone. Those are decisions that still belong to experienced engineers.

The future is collaborative

None of this means AI is overhyped. Quite the opposite. Used well, it can dramatically increase developer productivity. It is excellent at explaining unfamiliar code, generating repetitive implementations, identifying duplicate logic and helping engineers navigate large repositories faster than ever before. The real opportunity is not replacing software engineers. It is allowing them to spend less time writing routine code and more time making thoughtful technical decisions. The teams that will benefit most from AI are unlikely to be the ones generating the largest amount of code. They will be the ones maintaining the cleanest architectures, establishing clear development standards and treating AI as an accelerator rather than an autopilot.