If you prefer watching a video version of this article, check out:

Here, we are going to look into a phenomenon that is happening across social media. “Vibe coding” is all the rage—for good reasons, and also for some bad ones.

We will examine this phenomenon, look at its strengths and weaknesses, and discuss my position on it as the author of git-lrc and as someone working in this space of tools that help build things quickly—AI-assisted coding and so on. I am interested not just in the technology, but in what it means for software engineering, its users, customers, the public at large, and civilization.

Why Does Vibe Coding Sound So Inevitable?

I have a screenshot here. The person doesn’t matter, but it captures a general opinion many people have: if you are not vibe coding, you are essentially writing today’s version of COBOL—it works, but it’s no longer how things are meant to be built.

That is a strong and very clear claim about the present and the future.

I don’t like absolute statements. I prefer to assess things in more detail.

What Changes When You Translate Intent Instead of Code?

Previously, we had assembly programming. Then came B at Bell Labs with Ken Thompson, then C, and later languages like Python and Java. These transitions are related. Moving from C to assembly is a conversion from one formal language to another.

What is a formal language? The meaning is precise. A print statement in C has a corresponding, predictable meaning in assembly. There is no uncertainty. A for loop in C becomes a loop structure in assembly. The mapping is clear and deterministic.

But when you prompt an AI agent and it produces Python or C, that is a different kind of process. It is a conversion from a natural language to a formal language.

Your prompt might be two lines or ten lines. It might be structured. But the output can vary widely. Even the same model can produce different outputs across runs. We don’t know exactly what it will produce.

Also consider the reverse direction. Given code, can you reconstruct the original problem? Not reliably. This is not a one-to-one mapping. It is one-to-many.

In contrast, C to assembly is close to one-to-one. From assembly, you can reconstruct C-like code. You might lose variable names, but the structure remains intact.

So with vibe coding, we must remain vigilant. The system is producing meaning on the fly. It adds, removes, and modifies intent. It generates its interpretation of your input.

This is a key differentiator when dealing with natural language input.

Why Abstractions Stop Protecting You at the Worst Time

There is also the concept of leaky abstractions. Even with traditional abstractions, you need to understand layers beneath them to produce good results.

Consider why Elon Musk needs to understand how rockets work. He could hire people and delegate everything, but he still engages deeply with engineering details.

When you build something serious, you need understanding across multiple abstraction layers. Depth matters.

Similarly, we teach computer architecture concepts—memory, CPU, etc.—even if students later write Java. Why? Because abstractions break. They work most of the time, but not always. You need to understand what is happening underneath.

What Breaks When Software Gets Trusted Too Easily?

Now consider a few questions about vibe coding.

You might think this is exaggerated. Let’s look at history—examples of software failures.

• The Therac-25 accidents led to six deaths due to software malfunction.
• Toyota had unintended acceleration issues—89 deaths and thousands of complaints.
• The Patriot missile failure caused 28 deaths due to a numerical error.
• The Mariner 2 failure involved costly software-related issues.
• Another spacecraft failure was caused by an integer overflow.
• The Mars Climate Orbiter was lost due to a unit mismatch.
• Boeing crashes caused hundreds of deaths due to sensor-related software issues.
• Financial systems like Capital One and Citibank experienced major erroneous transactions.
• The Fujitsu Horizon scandal led to wrongful prosecutions due to software errors.
• The CrowdStrike outage affected millions of systems, disrupting flights, healthcare, and payments.

These are failures in professionally engineered systems.

So the question is: am I exaggerating?

In serious contexts—from personal tools to critical infrastructure—you cannot blindly trust software.

The problem with vibe coding is that its advocates promote it, but would they trust systems built using it?

At a deeper level, trust is the bedrock of civilization. Engineering exists to build reliable and secure systems that others can depend on.

An engineer’s responsibility is not personal convenience, but public safety and reliability. Bridges must stand. Planes must land safely. Medical systems must work when needed.

So What Should Replace Vibe Coding?

Vibe coding, by itself, cannot support this level of responsibility. It may be useful for prototyping, exploration, or internal tools. But it cannot be the foundation for serious systems without additional rigor.

That is why I discourage the term “vibe coding” and instead advocate “agentic engineering.”

Agentic engineering emphasizes respect for reality, feedback loops, testing, criticism, and verification. Not blind trust—verification.

We must not rely solely on intuition or “it seems to work.” Systems can fail in critical ways.

We have a responsibility to promote methods that uphold engineering values.

Interestingly, Andrej Karpathy popularized the term “vibe coding,” and by 2026 he is also advocating a shift toward agentic engineering.

We want to preserve engineering values: reliability, correctness, efficiency, performance, and security. These are what build civilizations.

Agentic engineering aligns with that.

As part of this, I built a tool called git-lrc. It provides micro AI code reviews on commit. Every time you commit, it encourages you to review what was generated, identify issues early, and maintain quality.

We should not pass problems downstream to customers. We should take responsibility upfront.

That is the core message: promote agentic engineering over vibe coding.

---

Want a Practical Way to Apply This?

Now, a quick introduction to git-lrc.

git-lrc is a free micro AI code review tool that runs on Git commits as you develop software with AI agents.

AI can generate large amounts of code, but your team still owns the outcome. You cannot delegate responsibility—only execution.

git-lrc provides lightweight code reviews at commit time. It improves stability, security, and performance while reducing bugs and costs.

You run Git as usual. When you commit, a review is triggered. You receive a summary of changes and categorized issues—warnings, critical issues, performance problems, and security concerns.

The tool includes a web UI for reviewing results.

It is open source and available at github.com/HexmosTech/git-lrc.

For teams, pricing starts at $32 per month. It supports unlimited users and includes integrations with GitHub, GitLab, and Bitbucket, along with AI credits.

You can learn more at hexmos.com/git-lrc