The Missing Engineering Discipline in AI-Assisted Software Development

I have identified what I believe is a major gap in AI-assisted software engineering, and I would like to explain it.

Let me start with an analogy.

Suppose I tell a civil engineer, “I want a building with these specifications.” The engineer does not simply say, “Okay, let me start building it for you.”

First, they create a complete architectural and engineering plan. Then they show it to me and ask: “Is this the building you actually want?”

Only after the plan has been reviewed and validated do they begin construction.

A professional engineer does not create a series of small, temporary plans at every stage of construction and discover fundamental design problems while the building is already being built.

I believe AI-assisted software development has a similar problem.

An AI coding agent often starts the implementation process from an initial idea and moves directly into writing code. I think this reflects a fundamental misunderstanding of what “vibe coding” should be.

Perhaps we think of vibe coding as a casual or recreational activity for ordinary people—something like saying that after the invention of the sewing machine, everyone can simply become a tailor.

I see it differently.

I believe vibe coding is becoming a serious engineering discipline.

To make it reliable, we need strong documentation before implementation begins. This documentation should play a role similar to a building blueprint: it should describe the system comprehensively enough that implementation becomes the execution of an already validated design, rather than a process of discovering the design while coding.

However, producing such a blueprint requires two things:

  1. The AI must develop the blueprint through an iterative conversation with the user, gradually transforming the user’s initial idea into a complete and precise specification.

  2. The user must have sufficient skill to communicate effectively with the AI agent, challenge its assumptions, answer its questions, and clarify requirements.

There are also two critical requirements for this blueprint.

First, it must be consistent.

We should not discover contradictions in the specification only after implementation has begun. Fundamental inconsistencies should be detected and resolved during the design phase.

Second, it must be complete.

The blueprint should not leave critical parts of the system undefined and rely on the implementation phase to fill in the gaps.

This leads to an important principle:

When an AI agent creates the blueprint, it should evaluate the blueprint against explicit engineering standards, such as consistency, completeness, and sufficient coverage of the required process.

Simply asking the user, “Does this look good?” is not enough.

User approval should be a secondary factor, not the primary measure of whether the blueprint is valid.

The agent should be responsible for verifying that the specification satisfies the required engineering standards before coding begins.

In other words, the fundamental workflow should not be:

Idea → Code → Discover Problems

It should be:

Idea → Conversational Analysis → Complete, Consistent, Validated Blueprint → Implementation

I believe this shift could be one of the important missing disciplines in AI-assisted software engineering.