The AI revolution has sent shockwaves through almost every industry, and software is no exception. We have entered a new phase of software development: vibe coding. With powerful frameworks, layers of abstraction and now generative AI, it has never been easier to produce working software with very little understanding of the systems underneath.
At face value, this looks like progress, and in many ways it is. Faster iteration, lower barriers to entry and higher productivity are real achievements. Social media is full of posts like "How I vibe coded a million-dollar app in an afternoon!" But the shift raises an important question: if software can be produced this easily, does software engineering still matter?
The short answer is yes.
The longer answer means going back to why software engineering exists as a discipline in the first place, and why the current AI moment may make it more important than ever.
The software crisis and the birth of software engineering#
The Systems and Software Engineering Vocabulary (SEVOCAB), maintained under ISO/IEC/IEEE 24765, defines software engineering as:
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
The term was not a branding exercise. It emerged in the late 1960s, during what became known as the software crisis. In 1968, a NATO conference in Garmisch, Germany, chose "Software Engineering" as its deliberately provocative title: the argument was that building software should be held to the same discipline as building bridges.
Software systems at the time were growing larger and more complex, but the way they were built was informal and improvised. Projects ran over budget, missed deadlines and often failed entirely. The code that did ship was hard to maintain, hard to reason about and brittle in the face of change.
Software engineering was the response. Its definition has blurred over the decades, but its purpose has not. It introduced ideas that feel obvious today and were revolutionary then:
- Systematic design instead of improvisation.
- Clear requirements and specifications.
- Modularity and abstraction.
- Verification, testing and maintenance as first-class concerns.
In other words, software engineering was never about writing code faster. It was about building software that survives complexity, scale and time.
The Software Engineering Body of Knowledge (SWEBOK) places the discipline between the mathematical and physical foundations of computer science on one side, and the practice of solving problems in a particular domain on the other. Science discovers; engineering applies that knowledge to real-world problems, with limited resources and at a sensible cost. That is why software engineering is as much about engineering economics (weighing the possible solutions and choosing the most cost-effective one), project management, systems engineering and quality management as it is about code.
When software engineering became a label#
Over the decades the industry changed. Tooling improved dramatically. Frameworks abstracted away large parts of the stack. Cloud platforms removed the need to manage physical infrastructure as we moved to IaaS, PaaS and SaaS.
Many of the practices that software engineering introduced became invisible as a result. They were built into our tools, enforced by our frameworks or handled quietly by our platforms. At the same time, the title software engineer stretched to cover a huge range of roles, until in many places it simply meant someone who writes code.
That blurring created a subtle but important shift:
- Software engineering became a title, not always a discipline.
- Understanding systems deeply became optional, until it wasn't.
Vibe coding and the illusion of simplicity#
I have built with Google AI Studio, Claude, Vercel's v0 and Figma Imagine, and there are moments when these tools write code faster, and sometimes better, than I would. That experience is exactly what fuels the claims that coding is now easy and software engineers are obsolete. With these tools, developers and non-developers alike can:
- Generate entire apps from a prompt.
- Scaffold APIs without really understanding networking or HTTP.
- Use databases without reasoning about transactions or isolation.
- Deploy systems without understanding how they fail.
This is powerful. It can also feel like handing someone a grenade as a toy.
The danger is not that AI writes our code. The danger is that working software is mistaken for correct, reliable or maintainable software.
I saw this first-hand while evaluating AI-generated code for model training. The output usually compiled, the happy path worked, and it looked professional. The problems sat underneath: edge cases nobody handled, logic that quietly broke on unusual input, errors swallowed instead of surfaced. These are precisely the bugs a demo never exercises and production always does.
Vibe coding works remarkably well for:
- Prototypes.
- Demos.
- Small, short-lived projects.
- And, time will tell, perhaps much more.
But software engineering was never about demos and prototypes, or even about writing code. It is about systems that:
- Handle failure gracefully.
- Scale under load.
- Protect the integrity of their data.
- Remain understandable months or years later.
Those properties don't emerge automatically from generated code. They come from engineering judgment.
Why AI increases the need for software engineering#
Paradoxically, the AI boom does not reduce the need for software engineering. It increases it.
As code generation becomes cheap and available to everyone:
- The cost of bad architectural decisions rises. A poor boundary between services now takes minutes to create and still takes months to undo.
- The surface area for subtle bugs expands. More code, produced faster, means more code that nobody has read closely.
- Systems grow faster than our understanding of them.
AI can generate code quickly, but it does not own the system. People still do.
Someone must:
- Decide where the boundaries between services belong.
- Understand the trade-offs between consistency, availability and latency.
- Design APIs that stay stable as requirements change.
- Judge whether a solution is merely functional or actually correct.
These are not coding tasks. They are software engineering tasks.
The encouraging part is that the same discipline works on AI itself. When I built Okione, a multi-agent pipeline that turns application source code into hardened Kubernetes manifests, the model was the easy part. Most of the engineering went into not trusting it: validating inputs, forcing every output into a strict schema, running deterministic security scanners over what it produced, grounding each finding in a cited benchmark, and having an independent evaluator check the result before anything reached a user. That is the 1968 playbook, applied to a new kind of component.
Software engineering as a differentiator again#
History appears to be repeating itself.
The original software crisis exposed the limits of unstructured programming. This one is exposing the limits of unstructured generation. Everything works, until suddenly it doesn't, and in that moment the value of disciplined engineering becomes obvious again.
In this environment:
- Software engineering is no longer about prestige or titles.
- It is about responsibility for systems that people depend on in the real world.
The engineers who understand the fundamentals, including algorithms, concurrency, networking, databases, cryptography and security, and distributed systems, will be the ones who can reason about AI-generated systems rather than just assemble them.
Looking forward#
AI will almost certainly be a core part of how software is built from now on. Ignoring that would be short-sighted. Treating AI as a replacement for software engineering would be just as misguided.
The more powerful our tools become, the more important it is to understand why systems behave the way they do.
Software engineering began as a response to complexity. The AI era is bringing that complexity back, faster than ever.
That is not the end of software engineering.
It may be its next defining moment.