It Works. But Does Anyone Know What’s Inside?

Vibe CodingArtificial intelligence is changing software development at an extraordinary pace.

Today, someone with little or no programming experience can describe an application in plain English and watch an AI generate hundreds or even thousands of lines of code.

A few prompts later, the application runs.

The interface looks good. The buttons work. The database stores information. Perhaps even the automated tests pass.

Success?

Not necessarily.

With AI we are making it easier to create software without making it equally easy to understand software.

And that may become one of the biggest problems facing the software industry.

When Writing Code Was Part of Learning

I have spent decades developing software and have worked with more than twenty programming languages, from Assembly and COBOL to Swift and modern programming environments.

During that time, tools have changed dramatically. But one principle has remained important to me:

I need to understand what my software is doing.

When I write a program, I mentally follow its execution. I consider how data moves through it, which functions depend on others, and what happens when something goes wrong.

I don’t necessarily remember every parameter of every function. After working with so many languages, syntax sometimes gets mixed up in my head.

That’s what documentation, reference manuals, and increasingly AI assistants are for.

But remembering syntax and understanding software are two very different things.

I may ask AI to suggest an implementation, review a function, or remind me of an API.

That doesn’t mean I automatically accept the result.

Sometimes my response is simply:

“This is redundant.”

“That’s unnecessarily complicated.”

“This is too slow.”

Or: “We already have a function that does exactly that.”

The important part isn’t who writes the code.

It’s who understands it.

The Missing Mental Model

Experienced developers often carry a mental model of their applications.

They know the architecture, the dependencies, the data flows, and the reasons behind earlier design decisions.

When something changes, they can anticipate consequences elsewhere in the system.

This knowledge isn’t acquired by memorizing programming languages.

It develops through years of designing, implementing, debugging, optimizing, and occasionally making mistakes.

Now consider someone whose introduction to programming is entirely based on AI-generated code.

They describe what they want. The AI produces a solution. They run it and check whether the result looks correct.

If it doesn’t, they ask the AI to fix it.

Eventually, it works.

But have they learned how the application works?

Perhaps. AI can be an excellent teacher when used that way.

But nothing in this workflow requires them to understand the implementation.

They can successfully produce software without developing the knowledge needed to evaluate it.

That’s a fundamental change.

Unit Tests Are Not a Guarantee

A common response to concerns about AI-generated code is that automated tests will catch the problems.

Tests are valuable. They are an essential part of professional software development.

But they have a fundamental limitation.

A successful test demonstrates that the software behaved as expected under the conditions tested. It does not prove that the software will behave correctly under every possible condition.

Who decides which conditions should be tested?

Who identifies unusual combinations of inputs, unexpected interactions between components, or failures that nobody anticipated?

Who notices that a function is unnecessarily expensive even though it returns the correct result?

Consider a simple example.

An AI generates a function that searches a database. It produces correct results, and all the unit tests pass.

Unfortunately, the implementation performs hundreds of database queries where one would have been sufficient.

The tests are green.

The application works.

And the implementation is still poor.

Now imagine similar decisions repeated across an entire application.

One inefficient function becomes ten. Then a hundred.

Redundant abstractions accumulate. Dependencies multiply. Performance deteriorates.

Nothing necessarily breaks immediately.

But the software becomes increasingly difficult to understand, maintain, and improve.

Tests can detect many of these problems if they are specifically designed to do so.

The question remains: Who knows what needs to be tested?

The Dependency Problem

Modern software development encourages extensive use of libraries, frameworks, and package managers.

There are excellent reasons for this. Reusing established components can save enormous amounts of time and avoid reinventing complicated functionality.

But every dependency also introduces code that the developer may not fully understand or control.

Personally, I prefer keeping my own software relatively small and its dependencies limited.

For example, I generally avoid Composer in my WordPress plugins.

Not because Composer is a bad tool.

But because I value knowing exactly what is included in my software and how its components interact.

That is a deliberate trade-off, not a universal recommendation.

In a large enterprise application, extensive dependency management may be entirely appropriate.

The important point is that someone should understand the architectural consequences of those decisions.

An AI can recommend installing another library in seconds.

Understanding why that dependency is necessary, what it introduces, and whether an existing component could already solve the problem requires a broader perspective.

Without that perspective, convenience can gradually become complexity.

Who Will Review the Code?

This brings us to the question that concerns me most.

For decades, software developers generally learned by writing software.

They had to understand at least enough of their programs to make them run.

They encountered compiler errors, memory problems, unexpected behavior, inefficient algorithms, and countless debugging sessions.

Those experiences gradually developed the ability to recognize problems before they became visible.

AI changes that learning process.

A beginner can now create sophisticated applications without going through many of those experiences.

That is an extraordinary opportunity.

But it also creates a risk.

If increasing numbers of new developers learn primarily to generate code rather than understand it, where will the next generation of experienced code reviewers come from?

Who will recognize a poor architectural decision?

Who will identify a subtle security vulnerability?

Who will know when a complicated implementation should have been a simple function?

And who will question an AI-generated solution that appears perfectly reasonable but is fundamentally wrong?

The danger is not simply that AI makes mistakes. The danger is that the people using it may not know how to recognize those mistakes.

More Software Doesn’t Necessarily Mean Better Software

We should be careful not to romanticize the past.

Human developers have always written terrible code.

Experienced programmers make mistakes. Large software projects become unnecessarily complicated. Security vulnerabilities appear in professionally developed products.

AI did not invent these problems.

And AI can also help solve them.

It can review code, identify vulnerabilities, suggest optimizations, generate tests, and explain complex implementations.

In principle, these capabilities could improve software quality enormously.

But only if they are used with appropriate judgment.

Having one AI generate code and another AI approve it does not automatically provide independent, reliable quality control.

Both systems may overlook the same assumptions.

And a human reviewer who doesn’t understand the application may be unable to recognize those omissions.

There is another economic dimension.

AI makes producing code cheaper and faster.

But careful review, system design, testing, and maintenance still require time and expertise.

When organizations prioritize rapid delivery, the temptation to skip those activities becomes stronger.

The result could be an enormous increase in the amount of software being produced without a corresponding increase in the capacity to evaluate it.

We may end up with more applications than ever before.

But not necessarily better ones.

The Real Value of Experience

I use AI regularly in my own development work.

It saves time. It helps me find documentation, compare approaches, investigate unfamiliar problems, and review implementations.

Sometimes it notices something I missed.

Sometimes I notice something it missed.

That is exactly how I want the it to work.

AI is a powerful tool, but it doesn’t eliminate the need for technical judgment.

In fact, the more code AI produces, the more valuable that judgment may become.

Understanding algorithms, data structures, operating systems, network protocols, and software architecture isn’t obsolete knowledge.

It is the foundation that allows developers to evaluate what AI generates.

And that foundation cannot be replaced merely by becoming better at writing prompts.

The Generation That Can Build but Cannot Understand

There is nothing inherently wrong with starting to learn programming using AI.

AI may become one of the most effective educational tools ever created.

It can explain concepts, demonstrate alternatives, and help beginners experiment with ideas that would previously have been beyond their reach.

But learning with AI and delegating all understanding to AI are not the same thing.

We should encourage new developers to ask not only whether their software works, but also why it works.

They should learn to read code, trace execution, understand dependencies, measure performance, and investigate failures.

They should occasionally implement something themselves, even when AI could generate it instantly.

Not because manually writing code is inherently superior.

But because developing the ability to reason about software requires practice.

The next generation doesn’t necessarily need to learn twenty programming languages.

But it does need to learn how computers work.

Otherwise, we risk creating a generation that can build almost anything but cannot reliably explain, maintain, or evaluate what it has built.

And that would leave the industry with an uncomfortable problem.

We will have automated the production of software while gradually weakening the human expertise needed to control its quality.

The future of software development should not be a choice between human programmers and artificial intelligence.

It should be about combining the strengths of both.

AI can generate the code.

But someone still needs to understand the system.

Because ultimately, the most important question isn’t:

Does it work?

It’s:

Does anyone know why it works — and what happens when it doesn’t?