Vibe coding for business value

What vibe coding is

Vibe coding is software development where AI writes most or all of the code from a described outcome or an intent. The person directing it says what the software should do and leaves the how to the AI agents or platform. This allows subject-matter experts who own the process to create what they always dreamed about.

Depending on what this application is built for and for whom, you may need to take different approaches.

1. 1
   Build without review when the cost of being wrong is low

   A prototype. A tool five people use. A page that comes down after the conference. If it breaks, someone loses an afternoon.

   The question is who gets hurt when it is wrong, not whether it looks finished.

2. 2
   Require review when the cost of failure is high

   Personal data. Payments. Anything running at scale. And anything that ends up being the place a number lives, which is most things that survive. Here the review costs a day and buys the right to put the application in front of someone.

The four categories

1. 1
   Rapid prototyping

   A working thing in front of real users inside a week, built to settle an argument and then deleted. A team that can do this stops writing specifications about what users might want.

2. 2
   Data synthesis

   One question, asked in plain language, across systems that each hold a piece of the answer. The records and the documents beside them, with every answer showing the evidence underneath it.

3. 3
   Internal tools

   The applications a function needs to run its own process, built by the people who run it.

   One intake form for a central shared-service team had sat unchanged on SharePoint for five years. The person who maintained it had left, nobody was funded to replace it, and it sat in the IT backlog behind everything with a revenue number attached. A subject-matter expert in that team rebuilt it in three days, and added AI features the original never had.

4. 4
   Client-facing AI applications

   Applications the people you serve use directly: the assessment someone fills in before they ever speak to you, and the portal they live in after they sign.

How do these application types connect to the AI Value paths

Each category serves a different one of the three AI value paths, and you should consider which type to use depending on what you’re trying to achieve.

What rapid building does not solve

Rapid building removes the bottleneck of development, so the actual value depends on how you do other things.

1. 1
   Deciding what deserves to exist

   Scarcity used to make this decision. When ten things can be built in the time one used to take, choosing between them becomes the scarce thing, and sometimes the right answer is that none of the ten should exist.

2. 2
   Modeling the data

   Fast builds break here, and they break late enough that nobody connects the break to the build. The intake form above survived because the person building it already knew what a request contains.

3. 3
   Getting people to adopt it

   An application nobody opens cost less than it used to and returns the same nothing. Rapid building multiplies the applications competing for the same unchanged attention.

How to get this right

The people building are subject-matter experts, not engineers. Make sure you set guardrails and clear principles and guidelines before anyone builds. By the tenth application, the same decision has become a migration.

• Decide who can see what before you populate the app with any data.
• Read data from the system that owns it instead of copying it in.
• Name the point at which a prototype becomes something people depend on, and review it as one when it gets there.