This past week I had the opportunity to do a deep dive in to a completely vibe-coded application. Note that I didn't build it. My main task was to audit it to see if it was production ready or if there were any notable issues with the codebase.
Well. It's been a few days, and I have my thoughts. But first, let me say that this is a great opportunity to see if indeed software developer jobs are about to be wiped out by sentient emotionless agents.
Because that's been the claim for some time now. In 2025, Mark Zuckerberg stated that he believed that AI will be doing the work of mid-level engineers by the end of the year.
And I think he got it right. But the part that the media and news outlets missed, was that this most likely depends on mid-level to senior-level engineers driving the entire thing.
If you put a completely non-technical person in the captains chair, you are no doubt going to get an unfinished product.
Now let's talk about the app for a second.
The app
The application itself is pretty complex, from a human developer perspective. It's intended to be a go-to-market AI agent that users can communicate with through Slack or some other entry-way.
It scans emails, creates files, analyzes metrics and even does automated outreach. At the end of the day, "go to market" essentially boils down to finding the ideal ICP's and doing outreach for your product.
The agent itself is the complicated component here. Each agent is an OpenClaw instance running in its own cloud environment with various configs tailored to a specific client.
Nothing Earth-shattering, but definitely a bit more than just a quick weekend build.
You need to worry about performance, security, agent memory management, and API integrations. Not including the core "web" elements, like authentication, email templates, billing and invoicing, SEO and several other dozen things.
The Build
The original developer in this case, is business-savvy and knows startups. But they aren't technical. They don't know what Postgres is and frankly, they don't want to know.
They just want to talk to their coding agent with in-plain-English specs, and get the desired output.
Which makes total sense, since that's what all the frontier models have been promising for some time now.
So it isn't unlikely that someone would type:
"I need a kick-ass GTM agent that lives in Slack and that can help a company with their GTM strategy."
That makes sense to me.
It's how every demo on the internet essentially works these days. And once the agent spins up a 1000 line file, you might then follow up with:
"And let individual companies sign up to use it."
After that prompt, there's no telling what the implementation will look like.
By the time you get to "and let's charge x,y and z", odds are you don't have a well scaffolded project.
The Deep Dive
The first thing that I noticed, was that the entire project (minus the node modules) sat at only a few hundred kilobytes.
Not unusual in it of itself. Except that my personal client/server templates that I use for nearly every project both sit in the MB's.
And the entire project was essentially one large JS file with 2500 lines of code. This one script handled the Slack OAuth integration, billing, admin, landing pages and Docker orchestration.
The database was essentially just a JSON file. Which to me screams lazy model. Instead of checking whether a relational database exists or can be created on the host, the model takes the easy way out.
There was a database migration script generated, but it didn't seem like anything ran it or even knew that it existed.
Many of the scripts loitering around the project folder were one-time use scripts used to test things or to fetch configuration data. Deciphering which files were actually core to the project took me some time.
Security as a whole was very lax and not something that I would personally consider production ready. And this is, sadly, very expected. When coding with AI agents, a developer has to be highly explicit about how they want their codebase setup.
And a non-technical coder, would have little to no idea on how to even begin that process.
"I need the best password hashing, salted, with x number of rounds" isn't something that the average person is expected to know.
The biggest issue for me though, was that there was little to no tech-stack even considered in this implementation.
The front-end was essentially hard-coded HTML strings served by the express server. There was no actual separation between client, server and/or database.
And worse of all, the entire application (admin included) sits in a single file.
But it works
The application itself "works", meaning that the expected inputs result in the expected outputs. And that's as "AI" as you can get here. Outside of that, there's little to no security, infrastructure, redundancy and compliance.
You'd definitely need vast amounts of more vibe-coding before you'd get to something more production ready.
And that’s the real trap here. If you don't know how software works under the hood, seeing a functional UI and a working Stripe webhook feels like magic.
You feel like you've cracked the code to something previously known only to a rare few.
It looks like a finished product, so you naturally assume the hard part is done. But the architectural debt lurking behind that single file is huge.
The first time two requests hit that flat JSON file at the same millisecond, or an unhandled Promise crashes the entire Node process, the entire house of cards will come down.
Vibe coding is genuinely incredibly useful for validating a raw concept or hacking together a weekend prototype.
But building something reliable that handles real customer data securely and professionally still requires deliberate engineering. AI models are great at giving you exactly what you ask for. But the problem is, they rarely bother to tell you what you forgot to ask.