The pros and cons of vibe coding
A construction company can get away with a lot in the field if the work is done safely and the results hold up. Software is less forgiving. When a system has to support people, data, handoffs and daily operations, a tool that seems to make sense to one person can become a burden for everyone else.
That is what makes this story useful. A CEO, curious about AI and frustrated with the limits of existing tools, starts building a platform with vibe coding. At first, it feels efficient. The ideas are flowing, the interface looks plausible, and the system seems to match the way the business works in his head.
Then the company tries to use it.
The problems appear quickly. Employees avoid the platform because it is too complicated. No one has tested it properly, so small issues become daily friction. The CEO understands the logic because he built it around his own mental model, but that does not mean the rest of the company can use it easily. Meanwhile, the old systems stay in place because moving live operational data is hard, and the business ends up running two ways at once.
That is not just a technology problem. It is a systems problem.
What Went Wrong
The first issue was adoption. A tool that looks efficient on a screen can still fail if it does not match how people actually work. If employees need extra steps, have to remember the CEO’s logic, or cannot quickly tell what to do next, they will keep using the old process whenever they can. Software succeeds when it reduces confusion. If it adds it, people route around it.
The second issue was testing, or more precisely, the absence of it. A system can look fine in a one-person demo and still break under real use. Testing is where hidden assumptions show up: missing validation, unclear permissions, broken workflows, inconsistent data, edge cases, and simple mistakes that are easy to miss when you are building fast. Without testing, the first real users become the testers whether you intended that or not.
The third issue was the gap between what made sense to the builder and what worked for the organization. That gap is where UX matters. Good user experience is not decoration. It is how software communicates, guides decisions, prevents errors and helps people complete work without needing a manual. If you do not understand those principles, you can build something that feels logical in your own head and still create serious adoption issues.
The fourth issue was data migration. This is where many new platform efforts get stuck. Even if the new software is technically usable, the business still has to decide how to move records, preserve accuracy, handle exceptions and avoid disrupting operations. That work is rarely glamorous, and it is rarely as simple as copying data from one place to another. If migration is hard, parallel systems often linger longer than expected, which means duplicated work, confusion and inconsistent truth across the business.
Why AI Can Make the Problem Worse Before It Makes It Better
AI can be genuinely useful in software development, but it can also be dangerously reassuring. It will often continue the thread you started. It will help you fill in blanks, write code, suggest screens and explain your own idea back to you in a polished way. That can feel like confirmation that you are on the right path, even when you are missing foundational pieces.
That is the trap. AI can make a concept feel finished before it has been tested against reality.
If you already understand software architecture, product design, security, data models, operations and user behavior, AI can speed up the work. If you do not understand those principles, it can help you create something faster that is still wrong. The result may look impressive in a demo and still fail where it matters most: in actual use by a team that has to rely on it every day.
This is why it works for me is not the same as it works for the business.
Software Is Not Just a Tool, It Is a System
People sometimes think software is just an app with a few features. In a business environment, it is usually much more than that. It touches process design, role clarity, permissions, reporting, data quality, onboarding, support and change management. Every one of those areas introduces decisions.
That is why building business software is closer to engineering a production system than assembling a simple gadget. The work is not only about making screens appear. It is about making the whole operation reliable, understandable and maintainable.
In construction, the team would not assume that someone who knows how to pour concrete can design the whole building. The work demands different expertise. The same idea applies here. Knowing the business well does not automatically mean you can design the software that should run it.
Major Software Decisions and Variables
The table below shows some of the core decisions that shape whether a system is useful, usable and sustainable.
| Variables | Why It Matters | Vibed | Engineered |
|---|---|---|---|
| Workflow | Can people finish the job? | Founder flow | All roles and edge cases |
| UX | Drives adoption | Looks intuitive to builder | Clear for real users |
| Testing | Finds failures early | Light checking | Structured QA |
| Data Model | Shapes the system | Basic fields | Relationships and integrity |
| Migration | Moves records safely | Copy the data over | Map, clean, validate |
| Permissions | Protects access | Simple roles | Role-based controls |
| Reporting | Supports decisions | What the founder wants | What each team needs |
| Integrations | Connects systems | Often skipped | Planned dependencies |
| Scale | Works as the company grows | Not always considered | Load and maintainability |
| Maintenance | Keeps it usable | Assumed to be easy | Ownership and support |
| Change Management | Helps people adopt it | They will figure it out | Training and rollout |
| Security | Reduces risk | Checked late | Built in from the start |
| Continuity | Supports downtime recovery | Hope it stays up | Backups and fallback plans |
The Practical Lesson
The lesson is not that business leaders should avoid experimenting with AI. They should. AI can be a powerful aid for prototyping, drafting ideas and exploring possibilities. The lesson is that a prototype is not a production system, and a useful demo is not the same thing as a tool the whole company can depend on.
Before replacing an operational system, ask a few hard questions:
- Who will actually use this every day?
- What will happen when the workflow is more complex than the demo?
- How will testing catch errors before rollout?
- What is the migration plan for existing data?
- What happens when the builder is not in the room to explain the logic?
If those questions do not have clear answers, the business is not ready for a full switch, no matter how promising the build looks.
AI can help a person move faster, but it does not remove the need for judgment. In software, judgment is what keeps a well-intentioned idea from becoming an operational mess.
If you were looking at your own business systems today, which part would be easiest to overestimate: the interface, the data migration, or the number of decisions hidden behind the scenes? A good place to start is by mapping the current workflow, identifying one point of friction, and testing a small change before you assume the whole system is ready. If the project is already underway, it can also help to bring in experienced product and engineering thinking before the team builds any further on top of a shaky foundation.