Recently, while serving as a technical advisor and consulting with executives, I’ve increasingly encountered people with a slightly different type of strength than before.
They’re not the so-called “tech-savvy executives.” They have no prior programming experience, but when you teach them tools like Cursor or Claude Code, they absorb them at surprising speed and continuously create products and business tools on their own.
Internal BPO tools, business improvement tools—because they understand the business best, they can shape exactly what they need themselves. This strength, when observed in the field, was quite impressive.
Non-Engineer Executives’ Vibe Coding Is Stronger Than Expected
I myself have mostly adopted relatively orthodox configurations in LLM-powered development: React Router, FastAPI, PostgreSQL, Redis, and DynamoDB when needed.
While I had touched Supabase, I lacked experience taking it from PoC to production-scale sites, so I had somewhat put it on the back burner.
Meanwhile, one executive was using Vercel and Replit to continuously build sites and features via LLM. Moreover, these weren’t just prototypes—they were advancing quite close to their company’s business operations and customer value.
What I felt while observing this was the strength of having the person who deeply understands the business essence do their own Vibe Coding.
Creating screens, changing user flows, adding desired features—these iterations run at a speed almost directly connected to business decisions. This speed is, frankly speaking, quite powerful.
The Problem Came with Production Operation
However, problems arise afterward.
What’s created through GUI-based Vibe Coding is often React-centric with display data based on mocks. When trying to make it actually production-ready, engineers end up taking it over and redesigning it.
- Making data handling secure
- Solidifying authentication and authorization
- Organizing APIs
- Connecting to databases
- Making it operationally ready
I often found myself wrapping it back into the familiar React Router + FastAPI configuration.
This decision itself was quite rational for a divided engineering organization. Separating front-end and API, dividing responsibilities, creating a maintainable configuration. In the traditional context, this was the right choice.
However, I encountered one problem here.
The moment engineers cleanly took it over, the speed at which executives could touch and evolve it themselves dropped.
”I Want to Change This a Bit” Becomes Difficult to Implement
When we’ve organized things to withstand production and are about to release, these kinds of requests naturally come from the executive side:
- I want to change this screen a bit
- I want to add this user flow
- I want to put AI Chat here
- I just want to try this part quickly
During the Vibe Coding phase, they could do these things immediately. However, once engineers wrapped it into a data-safe, solid configuration, small evolutions became difficult to implement.
As a result, service evolution speed drops during the most crucial period of PoC and initial growth.
This felt quite wasteful.
Teaching Docker and CLI Wasn’t Simple Either
“Then let’s teach executives Docker and CLI too, and develop together”—I naturally considered this direction and actually consulted about it.
However, there was a clear barrier here. For non-engineers, the hurdle of introducing command-line tools is indeed high.
Even with Docker alone, it’s difficult to develop an intuitive understanding of what’s running where, what’s in containers versus local, what to start and what to stop.
While UI and Look & Feel can now be created quite well with LLMs, the world of CLI and containers hasn’t yet become a natural working space for non-engineer executives. I feel this is more about compatibility as a working environment rather than tool superiority.
So I’m Starting to Try Next.js + Supabase
When thinking about this, what currently looks promising is the Next.js + Supabase combination.
The reason is simple: when observing non-engineer executives’ Vibe Coding, they progress through development quite naturally while consulting with LLMs.
- Deploying to Vercel via LLM
- Creating master data
- Adding login functionality with role controls
- Building light CRUD operations
They handle these flows with surprising naturalness.
In other words, in that world, an LLM-fully-supported development experience is already being established.
Given this premise, a configuration that separates front-end and API into different frameworks, dockerizes them, and develops across multiple services might be suitable for divided engineering organizations, but feels a bit heavy for collaborative work between LLMs and non-engineer executives.
What I want to say here isn’t that “previous configurations were bad.” It’s more like the evaluation criteria have expanded when considering who builds and who continues to nurture.
Configurations That Are Easier for LLMs to Grasp Might Be Better
My current hypothesis is this:
- Contain both front-end and API layers within Next.js
- Lean toward PaaS like Supabase for databases
- Reduce infrastructure complexity as much as possible
- Make it easier for LLMs to understand “this entire system”
This way, even after engineers adjust it somewhat for production, executives should find it easier to make changes themselves again or modify it together with LLMs.
This is still in the experimental phase, in the middle of trial and error. However, at least currently, I feel considerable potential.
What’s important here is not positioning this as the “ultimate configuration.” What I’m seeing is a promising hypothesis for configurations that don’t easily stop evolution speed—not a universal solution.
The Premises of Framework Selection Are Changing
To reiterate, I don’t want to say “Next.js + Supabase is the ultimate solution.”
What I mean is that entering the LLM Vibe Coding era might be changing the very premises of framework selection.
Previous framework selection was mainly evaluated on whether it facilitated division of labor, responsibility separation, and maintainability for engineering organizations.
But going forward, in addition to those criteria, I feel these axes will become realistically important:
- Can non-engineer executives continue to work with it?
- Can LLMs easily grasp the overall picture?
- Can it absorb small change requests without stopping them?
- Can it maintain evolution speed even after PoC?
Production Quality Assurance Is a Separate Matter
Of course, what I’m discussing here is about “development speed” and “evolution speed”—production quality assurance after release is a separate matter. Testing, vulnerability scanning, monitoring, incident response, security reviews—these processes are naturally necessary.
However, if we stop even the initial evolution speed for these reasons, we reduce the number of at-bats for the business itself. How to balance this is what I think will be the design philosophy going forward.
Summary
I’ve witnessed and felt the strength of executives advancing services and business tools through their own Vibe Coding.
At the same time, I’ve encountered the problem where small evolutions become difficult to implement once engineers take over with traditional safe configurations.
From this experience, what I currently feel is that in the LLM Vibe Coding era, the very axis of framework selection is beginning to change.
While still in the trial and error phase, I believe that “enabling non-engineer executives to continue nurturing with LLMs” will become a quite important condition in future product design.