Vibe Coding — Is It Bad?

The word "vibecoding" in the IT environment evokes mixed reactions: developers grimace, businesses are interested, and everyone else pretends they have figured it out a long time ago.

Hello everyone, I’m Nazar from the SimpleOne SDLC product team. Let's be honest — neither the camp of haters nor the camp of evangelists provides a complete answer to the question in the headline. So let's figure out why developers react so painfully, why businesses are still heading in this direction, and what to do about it.

Special thanks for help in writing this article go to Yana Panfilova.

First — what is vibecoding

Simply put, vibecoding is when artificial intelligence writes code, and a person manages the process through messaging with a chat. You describe what needs to be done, and the AI generates the implementation. You essentially don’t write the lines of code yourself.

— Why is the feature taking so long?

— I asked Claude to write it, he produced 400 lines, and I'm figuring out what’s there.

— Wait, did you write this yourself or did the AI?

— Well... the AI. But I checked.

— You checked 400 lines?

— ...I checked that it works.

And that's all there is to vibecoding in one scene.

It sounds like the future of development. Or the end of it. Depending on which side you look from…

According to the Stack Overflow Developer Survey 2025, 80% of developers are already using AI tools in their work. GitHub records that 46% of all new code today is generated by artificial intelligence. Gartner predicts that by 2028, 75% of engineers will use AI assistants in their work — compared to less than 10% at the beginning of 2023.

The dark side: why developers are against it

Developers see problems where managers see opportunities. And from the perspective of the engineering craft — their arguments are serious.

First, the quality of code

AI generates working code, but working ≠ good. "Working" code typically contains unnecessary checks, comments in unexpected places, and logic that solves the problem but does so oddly. All of this turns the codebase into something that is hard to work with later: it’s poorly readable, poorly maintainable, and harbors defects that will manifest at the most inconvenient moments.

Here's an example—a simple function to get a discount for a user. The task is trivial, but vibe coding turns it into a puzzle:

# Function to get discount for user

def get_user_discount(user, product):

    # Check if user is not None

    if user is not None:

        # Check if user exists

        if user:

            # Get the user role

            user_role = user.get('role')

            # Check if role is not None

            if user_role is not None:

                # Check if the role equals admin

                if user_role == 'admin':

                    # Admin gets 20% discount

                    discount = 20

                    return discount

                else:

                    # Check if role equals premium

                    if user_role == 'premium':

                        # Premium user discount

                        discount_value = 10

                        return discount_value

                    else:

                        # For all other roles

                        if user_role == 'basic':

                            return 5

                        else:

                            # Default case - no discount

                            discount = 0

                            return discount

            else:

                # If role is None, return 0

                return 0

        else:

            return 0

    else:

        # User is None

        return 0

The code works. But try coming back to it in a month—or passing it on to a new developer. Six levels of nesting for four values. Comments that recount the code verbatim. Two different variables for the same thing (discount and discount_value). The check if user is not None right after if user—that's the same condition twice.

A clean version of the same logic:

DISCOUNTS = {'admin': 20, 'premium': 10, 'basic': 5}

def get_user_discount(user):

    if not user:

        return 0

    return DISCOUNTS.get(user.get('role'), 0)

The result is identical. The difference lies in how easy it is to read, test, and extend.

And here arises the problem with code review. The reviewer is used to reading code written by a human — with clear logic and predictable structure. AI-generated code is formally correct, but reads differently. The reviewer either spends three times more time or simply approves it — because "well, it works." The second option occurs more often. And this is how technical debt quietly accumulates in the codebase — one approved PR at a time.

Secondly, skill degradation

When you offload coding to AI, you stop training your engineering thinking. Over time, the developer loses the ability to design solutions independently — they get used to directing and checking rather than thinking. This has already been discussed on Habr: a person creates projects at an incredible speed, and then comes to an interview and cannot explain what makes their own code work. This may not become a catastrophe right now, but it is a slow drift towards dependence on neural networks.

Thirdly, dependence on external aggregators

Currently, the most powerful models are from Anthropic and OpenAI. Local models that can be deployed on your own servers are noticeably weaker. This means that companies that switch to vibe coding begin to depend on American providers — with risks of codebase leaks, training models on your own code, and potential legal consequences.

In summary

The code is unclear, engineers are dulling, data is leaking. On one hand — everything is bad.

The bright side: why business is still transitioning

Business does not make technical decisions in a vacuum (if you thought so) — it makes decisions based on the market situation.

Every year, tens of thousands of tech startups emerge in the American and Chinese markets. If you haven't quickly secured a position— the market has closed for you. According to LexisNexis PatentSight, in 2024, 73% of all global patent publications were from China—compared to 6% from the USA. In the IT sector alone, Chinese patent applications exceed the combined annual total of patents from all other countries.

Vibe coding allows for faster development—that's a fact. This means you get to market faster, receive feedback faster, and iterate faster.

And here arises an uncomfortable question that is not often asked: how important is initially good architecture if it is cheaper to rewrite from "working"? The basic value of good code lies in its maintainability. But if the speed of rewriting with AI is sufficiently high, it is cheaper to generate "not perfect" code, release it quickly, make money, and then—if necessary—quickly redo it. The logic is not indisputable, but it does make sense.

But there is another argument in favor of vibe coding—and it is the most uncomfortable for developers. It’s not about the code at all.

The market will get used to everything breaking

Here, perhaps, is the most interesting observation—and the most debatable.

Look at Claude Code. Incidents regularly appear on its status page, even though it’s an important system used by hundreds of companies, and it regularly goes down. So what? No one leaves. Everyone continues to use it—because the value it creates outweighs the inconvenience of occasional failures.

Jira lags with a large number of simultaneous users. Telegram periodically crashed in different countries. None of this stopped people from using these products — because they fulfill an important need.

Important caveat:

This works for B2C products and internal tools. If your product is a payment gateway or a medical system, “getting used to it crashing” is not a valid argument. The regulator won’t get used to it.

This is the market direction: users gradually get used to the fact that applications sometimes glitch, sometimes crash, and sometimes are not perfectly made. And they tolerate this if the product still delivers value. It’s not a fact that because of vibe coding people will abandon applications if they solve their problems.

The goal of vibe coding is not good code

And if people tolerate glitchy applications for the sake of convenience — it means the market has silently answered the question: what is more important, code quality or product value? Here it’s important to separate the concepts that we habitually mix up.

Well-written code is a professional value of a developer. It is the beauty of architecture, readability, maintainability. This is what hundreds of books are written about. And, by the way, this is something that people themselves do not always achieve, otherwise there wouldn’t be those books.

Vibe coding does not set this goal.

The goal of vibe coding is to quickly deliver a cheap working product to the user that is in demand. This is a different optimization function.

Imagine the housing market. Economy-class housing is built from cheaper materials, with less attention to detail, faster. Buyers know this. And they still buy — because they need a roof over their heads, and an economy apartment solves that problem. The same thing happens in development: if a product addresses a real need at an acceptable price, it will be used regardless of how beautiful the code is under the hood.

So is vibe coding good?

Not quite. Rather, it is a tool for specific tasks.

Critical systems — banks, government services, infrastructure — will still be written by people with high reliability requirements because the cost of failure is too high.

But a huge layer of applied products — corporate interfaces, internal tools, prototypes, auxiliary services — can very well transition to vibe coding. It's like with illustrations: artists won't disappear, but a significant part of the tasks for generating images has already gone to AI, and this process won't reverse.

As long as AI does it faster, more, and cheaper, it will win where it matters.

Condemning this is like condemning people for driving cars instead of walking. The question is not whether it's good or bad. The question is where you are going and whether you remembered to check the brakes.

Summary

Vibe coding is neither a threat to development nor its salvation. It is a tool with a different purpose: not to write beautiful code, but to quickly deliver a working product. Developers are right to worry about quality. The business is right to rush. The market, apparently, will tolerate imperfection — if the product solves a real problem.

How to try it without risk?

Start with internal tools and prototypes. Measure the speed and number of bugs after a month. If the time to the first working prototype has decreased, and production isn’t on fire — scale up. If bugs start appearing — you've found the limit.

***

Are you using AI when writing code — and if so, how does your team cope with it?