Why “It Works” Is Not a Quality Criteria

**The phrase “it works” means that the code is not broken right now. It doesn't say anything about what's going to happen in an hour, tomorrow or after the first change. Quality begins where you understand why it works and what happens if conditions change.

## Where does this feeling come from

It almost always starts the same way. You asked for something from the AI, got the code, ran it, and saw the result. The screen showed what you expected. At this point, there is internal relief. So it worked out. Then we can move on.

It's a very human reaction. The brain likes to close tasks. If the result coincides with the expectation, it seems that the work is completed. Especially if you don’t know how to code and don’t fully understand what’s going on inside.

## Why “working” seems to be enough

When there is no experience, quality is easily confused with the fact of running. If the program does not fall and gives the desired result, it seems that it is “right”. Everything else is perceived as complication or complication.

AI amplifies that feeling. He writes confident code, often immediately working, and creates the illusion that if something goes wrong, he will just “fix” it. As a result, the quality criterion is imperceptibly compressed to one point - started or not.

## What is really hidden behind “it works”

The problem is that working code can be very different. It can be stable or fragile. Understandable or completely opaque. Ready for change or falling apart from any movement.

The phrase “it works” does not answer any important question. Why does it work that way? What happens if other data comes in? What happens if you go back to that code in a month? Can you change anything without breaking everything else.

As long as these questions aren’t asked, “working” is just a coincidence with current conditions.

## When that mistake really gets in the way

Everything looks harmless at first. Then comes the first edit. You add a new feature or the AI changes a piece of code. Suddenly, the result becomes strange. Somewhere something stops working, but you don’t know where or why.

At this point, it turns out that the code was working, but not clear. You don't know what to pull for and what not to pull for. Any change becomes risky because you’re not sure you understand the system at all.

## Why AI doesn’t save us from this

It seems logical to think that AI will fix everything at any moment. But the AI doesn't remember how you're going to live with that code. It responds to current query, not project history.

If you don’t understand what should be preserved and what is important not to break, the AI doesn’t know either. He can make it work again, but the problem will repeat itself because the quality criterion never came up.

## What can actually be considered quality

Quality doesn’t start where code starts, but where it’s predictable. When you understand what will happen when you change the input data. When you can explain what this piece is responsible for and what will happen if it is removed or changed.

This does not require deep technical knowledge. This requires clarity. If you can ask questions to the code and get clear answers to them, then the quality has already appeared.

## Why this is especially important in Vibcoding

In vibcoding, it is easy to get used to quick results. AI gives you a sense of speed and progress. But without an intrinsic quality criterion, this speed turns into an accumulation of fragile solutions.

At some point, the project stops moving forward because any change becomes scary. And this is almost always a consequence of the fact that in the past too many decisions were made on the principle of “the main thing that works”.