What Makes Software Vibe+?

If Vibe+ is going to be useful, it has to mean something more specific than software built with AI.

In my first article on Vibe+, The Case for Vibe+: When Vibe Coding Meets the Real World, I argued that vibe coding has done something important: it has made the distance between an idea and working software much shorter. You describe what you want, AI helps build it, you try it, and you keep refining it until it works.

I also argued that “it works” is where a different set of problems begins. Once software meets real users and real production environments, we have to understand whether it’s secure, maintainable, scalable, usable, and actually accomplishing what we intended. I used Vibe+ as a name for extending the AI relationship into that part of the software’s life.

That definition needs boundaries. If any application that uses AI somewhere in its development process qualifies as Vibe+, then the term isn’t particularly useful. We already have good language for AI-assisted development and for an AI-native software development lifecycle.

So what would actually make software Vibe+? I think there are five characteristics that matter.

AI Stays Involved After the Software Works

The most basic requirement is that the AI relationship doesn’t end when the application runs successfully.

Vibe coding is centered on creation. You describe what you want, AI produces an implementation, you try it, and the conversation continues until you’re satisfied with the result. There may be testing and debugging along the way, but the goal is still to get from an idea to working software.

Vibe+ carries that relationship forward. Once the software exists, AI continues to help understand it. Depending on the application, that might mean examining architecture, security, maintainability, technical debt, usability, production readiness, dependencies, performance, or other areas that matter.

This isn’t about prescribing a standard list of assessments. A consumer mobile application, an internal accounting system, and a public API don’t have identical concerns. The important point is that evaluation becomes part of the continuing relationship with the software rather than a separate activity that happens occasionally, if at all. As the software changes, our understanding of it should change too.

The Real World Becomes Part of the Evidence

There are limits to what we can learn from source code, specifications, automated tests, and pre-release analysis. Some questions can’t be answered until people actually use the software.

We can test whether a signup flow works, but that doesn’t tell us whether people abandon it halfway through. We can verify that a feature behaves according to its specification without knowing whether anyone finds it useful. We can model expected load, but production tells us what the load actually looks like.

A Vibe+ approach therefore needs a way for real-world evidence to find its way back into the development process. That evidence could include usage, performance, failures, user behavior, support patterns, business outcomes, or other information relevant to the purpose of the software.

This doesn’t mean collecting every available metric and handing it to an AI. More data isn’t automatically more understanding. The useful evidence is the evidence that helps answer questions about how the software is behaving and whether it is doing what we expected.

That distinction matters. Without real-world evidence, we’re still primarily asking AI to reason about what we built. Once production becomes part of the picture, we can begin asking what happened because we built it.

Intent Has to Survive Implementation

Software development has traditionally been very good at losing intent.

Someone decides why a feature should exist. Requirements get written, designs are produced, tickets are created, and code gets written. Months later, the code is still there, but much of the reasoning behind it has disappeared into old documents, issue trackers, meeting notes, chat threads, and people’s memories.

AI gives us an opportunity to do better.

Suppose the original intent behind a feature was simple: make it easier for new users to create their first project. That intent shouldn’t stop being relevant once the feature has been implemented.

When the feature reaches production, we should be able to return to the original question. Did we actually make it easier? Are more people completing the process? Are they completing it faster? Where are they getting stuck? Did we solve the problem we set out to solve, or merely implement the feature we described?

That requires maintaining a connection between intent, implementation, and evidence. I think this is an important part of Vibe+ because it separates the idea from simply applying AI to software monitoring. The goal isn’t only to know that something happened. It’s to understand what happened in the context of what we were trying to accomplish.

The original intent should remain part of the conversation.

Understanding Has to Lead Somewhere

Modern software already produces an extraordinary amount of information. We have logs, dashboards, vulnerability scanners, code-quality reports, analytics systems, observability platforms, issue trackers, user feedback, test results, and plenty more.

Adding an AI-generated summary to those systems doesn’t necessarily change much. The more interesting opportunity is to shorten the distance between understanding something and deciding what to do about it.

If an architectural assessment identifies a problem, there should be a path toward deciding whether it matters and what should change. If users consistently struggle with a workflow, that evidence should be able to inform a product change. If a security review finds a meaningful vulnerability, the finding shouldn’t end its life in a report that someone has to manually translate into development work.

This doesn’t require AI to make those decisions on its own. It means the context shouldn’t be lost as we move from evidence to action.

A finding can become a recommendation. A recommendation can become planned work. Approved work can become another implementation. That implementation can then be evaluated again, both technically and in the real world. At that point, we no longer have a collection of AI features scattered around the software lifecycle. We have a feedback loop.

People Still Make the Consequential Decisions

It would be easy to interpret Vibe+ as an argument for autonomous, self-modifying software. That’s not what I mean by it.

There are many things AI can increasingly do well. It can analyze large codebases, correlate information from different sources, identify patterns, explain technical issues, suggest alternatives, generate implementation plans, and perform much of the implementation itself.

But software development also involves decisions that aren’t simply optimization problems. Should we accept a particular security risk? Is an architectural change worth the cost? Is a feature important enough to build? Does a recommendation fit the direction of the product? Is the behavior we’re seeing from users actually something we want to encourage?

AI can provide evidence and recommendations for those decisions. People still establish the goals, decide which tradeoffs are acceptable, and determine what matters.

As implementation becomes easier, those decisions may become more important rather than less important. The scarce skill is increasingly not typing the code. It is understanding what should be built, whether what exists is good enough, and what deserves attention next.

Vibe+ should make those decisions better informed. It shouldn’t make them disappear.

A Practical Way to Think About It

Taken together, these characteristics create a fairly simple loop.

Software begins with intent. AI helps turn that intent into an implementation. Once the software exists, AI helps evaluate what was built. Production provides evidence about what actually happens. That evidence is considered in the context of the original intent. The result is a better understanding of what should change, which leads to another iteration.

In shorthand:

Intent → Build → Assess → Observe → Understand → Improve => Repeat

I don’t think the exact labels are especially important. Different products and organizations will break the work into different stages. What matters is continuity.

The intent that led to the software shouldn’t disappear when coding begins. The knowledge created during implementation shouldn’t disappear when the software is deployed. Production evidence shouldn’t live in a separate universe from the decisions that created the product. Recommendations shouldn’t have to be manually reconstructed as new requirements before anyone can act on them.

The loop becomes valuable when those things remain connected.

What Isn’t Vibe+?

Defining what doesn’t qualify is probably just as important.

An AI code generator isn’t Vibe+ simply because it can create an entire application. An AI code-review system isn’t Vibe+ because it can identify problems. An observability platform isn’t Vibe+ because AI can explain an incident. A product analytics system isn’t Vibe+ because AI can summarize user behavior.

Even a development platform that uses AI at several points in the software lifecycle isn’t necessarily Vibe+.

Any of those capabilities could be part of a Vibe+ approach. None of them, by itself, is the idea.

The difference is the connection between them: intent remains available after implementation; evaluation continues after creation; real-world evidence comes back into the process; and what we learn can influence what gets built next.

Without those connections, we have useful AI tools. With them, we begin to have a continuous relationship between the software, the people responsible for it, and the AI helping them understand and improve it.

This Shouldn’t Become a Certification

I don’t think Vibe+ needs a checklist that produces a yes-or-no answer, and I wouldn’t want the term to become another way of declaring one development approach modern and another obsolete.

There will be degrees of this.

A team might begin by using AI to evaluate software after it has been generated. Later, it might bring production evidence into that evaluation. Eventually, it might preserve the original intent and use real-world evidence to determine whether the software actually accomplished what it was supposed to accomplish.

Those are different levels of the same progression.

A more useful question than “Are we Vibe+?” might be: How much of the loop between intent, creation, evidence, and improvement have we connected?

That question can apply to software created almost entirely through vibe coding, software developed by a traditional engineering organization, or something in between. Vibe+ isn’t dependent on who wrote the code. It’s about what happens after the code exists.

Why Give This a Name?

New terminology is useful only when it helps us recognize something that wasn’t easy to describe before.

Vibe coding did that. The term gave people a simple way to describe a new relationship with software creation: instead of translating an idea into code yourself, you can increasingly describe what you want and work with AI to make it real.

As that becomes normal, another relationship starts to matter.

We need to understand the software we’re creating at roughly the same pace that we’re creating it. We need ways to establish confidence in it without making every person who creates software an expert in every discipline required to operate it responsibly. We need the information generated in production to make its way back to the decisions that shape the product. And we need to preserve why something was built long enough to determine whether it actually worked.

That’s the part I think Vibe+ can describe.

It isn’t a replacement for vibe coding, and it isn’t another name for an AI-native SDLC. It is an extension of the relationship that made vibe coding important in the first place.

Vibe coding lets us work with AI to turn intent into software. Vibe+ keeps that relationship going as the software encounters the real world.

The + is the loop that brings what we learn back to what we build next.

Proposed Vibe+ Characteristics

A Vibe+ approach:

• Keeps AI involved after software is working.
• Continuously evaluates the software as it changes.
• Incorporates relevant evidence from real-world use.
• Preserves the intent behind what was built.
• Connects findings and outcomes to future improvements.
• Uses AI to inform and execute work while keeping people responsible for goals, priorities, and consequential decisions.

Together, those characteristics create a continuing relationship between intent, software, evidence, and improvement.