What's new in Vibe Coding: A Conversation with the Father of Low-Code, John Rymer from Forrester

I sat down with John Rymer for The Low-Down by Analysis.Tech. If you have not heard the name, John is one of the people who defined what low-code means as a category. He co-authored the original Forrester research that gave the movement its name. He is now doing the same close reading of vibe coding, which is what happens when the human describes what they want and AI writes the code.

We spent an hour talking about what breaks. He summarized the conversation in four points, and they are the tightest articulation of the problem I have been trying to explain:

1. Apps work only on the happy path.
2. LLMs generate lots of duplication and bloat, sometimes in files too large to debug efficiently.
3. Architecture is implicit, without consideration of updates and expansions.
4. Ungoverned "shadow AI" overwhelms IT governance.

I want to expand each one, because they are not gripes. They are the roadmap for what any serious vibe coding governance layer has to cover.

1. Apps work only on the happy path

If you demo a vibe-coded app in a room, it will almost always look great. One person clicks through the intended flow. The AI-generated screens do exactly what they were designed to do. Everyone nods.

Then you put real users in front of it. Someone pastes 50,000 characters into a field built for 200. Someone refreshes mid-payment. Someone opens the same form in three tabs. The app was never asked to handle those cases, so it does not handle them.

This is what production readiness actually means. It is not about security holes. It is about whether the app survives a bad Tuesday. The AI does not flag the missing error handling, the missing timeouts, the missing retries, because none of those were in the visible spec. The demo never triggered them.

We wrote about this at length in Will Your App Survive 1,000 Real Users?. If you build with these tools, read it. This is the failure mode that quietly kills launches.

2. LLMs generate duplication and bloat

Every senior engineer who has read AI-generated code has said some version of the same thing. The code works, it just does not know how to reuse itself. The same helper gets redefined in four places. The same import is duplicated. Files sprawl to thousands of lines because the model has no natural incentive to consolidate.

What this actually costs you is future speed. The first version of your app ships fast. The second version, the one where you add a feature or fix a bug, is where the bloat starts to bite. You cannot find the right place to make the change because there are three of them. You cannot debug efficiently because the file is too large to hold in your head or your context window.

This is the maintainability problem. It shows up months after launch, not on launch day. And nobody flags it in the moment.

3. Architecture is implicit

This is my favorite of John's four, because it names something most vibe coders do not know they are missing.

When you describe an app to an AI, you are describing the user-facing behavior. The AI generates code that produces that behavior. But the architecture, meaning how components fit together, how data flows, how the parts will grow when the app grows, is a set of decisions the AI makes silently.

You do not see the decisions. You do not review them. You do not know what tradeoffs were made. And when you try to expand the app six months in, you discover the shape it was given, because it fights you.

The fix is to make architecture explicit. Draw the diagram. Read the flow. Understand what shape the AI gave you before you build on top of it. Every NEKOD 360° review now includes a plain-language architecture diagram for exactly this reason. You cannot govern what you cannot see.

4. Ungoverned "shadow AI" overwhelms IT governance

This is the enterprise version of the problem. Employees at your company are already shipping AI-built apps. They are not asking permission. They are not writing them into your architecture review. They are copy-pasting the URL into Slack and calling it done.

Your IT team, if they are paying attention, is in one of two states. Either they have banned the tools (which does not work, people find them anyway) or they are trying to keep up manually (which does not scale past a handful of apps).

Neither is a strategy. What you actually need is a governance layer that is platform-agnostic, that can assess any AI-built app across data, security, compliance, and readiness, and that does not require every employee to become a compliance officer. This is the layer NEKOD builds for the enterprises we work with.

The Santander AI open source release is another version of the same signal, from a different direction. Governance is moving out of internal binders and into public frameworks. If you are running IT at a regulated company, this is on your agenda whether you put it there or not.

Where NEKOD sits in the picture

The four problems John named map cleanly to the five areas of our 360° review.

• Happy path failures → Reliability
• Duplication and bloat → Maintainability
• Implicit architecture → Reliability + Maintainability, plus the plain-language architecture diagram
• Shadow AI at enterprise → Compliance + Commercial, plus platform-agnostic assessment across the portfolio

We did not build the 360° review because we wanted to compete with the AI tools. We built it because the tools are producing real value at real speed, and the layer that sits between "the AI shipped it" and "real users use it" is either present or it is not. When it is not, all four of the problems John named show up on the same Tuesday.

Watch the conversation

The full podcast is on YouTube: Antigoni Kourou: Governance in the Age of AI, on The Low-Down by Analysis.Tech.

Thank you to John Rymer for having me on. The whole conversation is worth an hour of your time if you build, buy, or govern AI-generated apps.

Key takeaways

• John Rymer, one of the analysts who defined the low-code category, named four problems with vibe-coded apps in our conversation
• Happy-path fragility, duplication and bloat, implicit architecture, and ungoverned shadow AI are the four
• They map cleanly to NEKOD's five-area assessment: Security, Compliance, Reliability, Maintainability, Commercial
• Every NEKOD 360° review now includes a plain-language architecture diagram, because architecture that is implicit is architecture that is ungoverned
• If you are running IT at a regulated company, "shadow AI" is on your Q3 agenda whether you put it there or not

What to do next

If you are a builder or founder shipping a vibe-coded app, get your free scan at nekod.co and see which of the four problems live in your app.

If you are running IT or innovation at a company with employees already shipping AI-built tools, a consultation walks through how the 360° review works at portfolio scale.