Dev.to AI πŸ€– Ai πŸ‘ 0 πŸ“– 11 min read

Vibe coding ships fast. Software engineering keeps it from falling apart.

Why engineering discipline still decides whether a web app survives real users, with evidence from 2025 and 2026 By Tchoffo Idris In late January 2026, Moltbook, a social network for AI agents, went viral. Its creator

Why engineering discipline still decides whether a web app survives real users, with evidence from 2025 and 2026

By Tchoffo Idris

In late January 2026, Moltbook, a social network for AI agents, went viral. Its creator said he hadn't written a line of the code himself, because AI built all of it. A few days later, researchers at Wiz opened the site like any visitor, found a database key in the client-side JavaScript, and discovered it gave them the whole production database. About 1.5 million API tokens, around 35,000 email addresses and thousands of private messages were readable. Write access was open too.

The app worked and people were using it. The database behind it just had no access rules.

That gap is what this article is about. Vibe coding is useful, and I'm not here to bury it. But when AI-written code meets the open internet with no engineering practice around it, the failures repeat, and they cost real money.

What "vibe coding" actually means

Andrej Karpathy coined the term in February 2025. He described building by accepting whatever the AI produces, pasting errors back in, and carrying on until you can "forget that the code even exists." By the end of 2025, Collins Dictionary had named it Word of the Year.

Then the meaning drifted. A description of weekend tinkering became shorthand for shipping unreviewed AI output to production.

A year later, in February 2026, Karpathy himself suggested a different name: agentic engineering. His reasoning was that you now direct agents instead of writing the code yourself, and that doing it well takes real expertise. At a Sequoia event in April 2026 he said vibe coding raises the floor, and agentic engineering is what extends the ceiling. Google's Addy Osmani drew the same line: the AI can do the implementation, but a person still owns the architecture, the quality and the correctness.

So the person who named vibe coding now says the important part is the engineering. I think that's the most honest summary of the whole debate.

Software engineering is not typing code

Writing code is one slice of the job. The rest is what keeps a system correct, safe and changeable over time:

  • Requirements and threat modeling: who can do what, and what must never happen
  • Data modeling and the design of authentication and authorization
  • Code review and automated tests
  • CI/CD pipelines with quality gates
  • Separate environments, secrets management and least-privilege access
  • Logging, monitoring and alerting
  • Backups someone has actually restored
  • Dependency and supply-chain hygiene
  • Refactoring and long-term maintenance

A prompt like "build me a SaaS with login and payments" optimizes for what you can see. Security, resilience and maintainability are invisible, and nobody notices them until they're missing. An AI rewarded for "it runs and looks right" will deliver the visible part and happily skip the rest.

What the evidence says

Security: the same holes, at scale

  • Veracode tested more than 100 language models on security-sensitive coding tasks. About 45% of the generated samples introduced OWASP Top 10 vulnerabilities. Its March 2026 update found the pass rate flat at roughly 55%, even though the models kept getting better on coding benchmarks.
  • Georgia Tech's Vibe Security Radar tracks vulnerabilities traced to AI coding tools. It logged about 18 cases over the last seven months of 2025, then 56 in the first three months of 2026, with 35 of those in March. The Cloud Security Alliance says researchers think the real number could be five to ten times higher.
  • Escape.tech scanned apps built on platforms like Lovable, Base44 and Bolt.new and reported more than 2,000 highly critical vulnerabilities and over 400 leaked secrets.
  • In December 2025, security firm Tenzai (reported by CSO Online) had five agentic coding tools build the same test apps. The 15 apps held 69 vulnerabilities, and the most common serious ones were authorization and business-logic failures. Every app lacked CSRF protection and security headers, and every tool introduced server-side request forgery flaws.
  • A June 2026 study of 10,517 vibe-coded apps by Deng, Fan and Meng sorted the failures into systemic classes. I'm working from a secondary summary of it, not the paper. One class, memory defects, covers security requirements that get forgotten or applied inconsistently as a project grows, and it accounted for about 19.5% of vulnerabilities. According to that summary, telling the agent to write production-ready code cut vulnerabilities by 27 percentage points, and a self-check prompt cut them by 22. That helps, but plenty of risk remains.

The picture isn't all bleak. Tenzai found no exploitable SQL injection or cross-site scripting in the agent-built apps, so the textbook bugs seem to be getting handled. What broke were the context-heavy things: who may see what, and what the business rules require. That's exactly the work an engineer owns.

Maintainability: debt arrives faster than features

GitClear and GitKraken analyzed 623 million code changes from 2023 to 2026. Compared with the period before AI tools, they reported:

  • Code duplication up 81%
  • Code being moved or reused (a proxy for refactoring) down 70%
  • Refactoring of older code down 74%
  • Code that swallows errors without checking the cause up 47%

That last number bothers me most. Code that never throws an error looks like working code, and it hides bugs until they show up in production as behavior nobody can trace. GitClear's CEO described the end result as five slightly different implementations of the same thing, which somebody eventually has to untangle. Google's 2024 DORA research found a similar trade: every 25% increase in AI usage came with about 7.2% lower delivery stability. LeadDev notes that some of these trends may be flattening, so trust the direction more than any single figure.

Perception: feeling fast is not being fast

METR ran a randomized controlled trial with 16 experienced open-source developers doing 246 real tasks on repositories they knew well. AI tools were allowed on some tasks and banned on others. With early-2025 tools, developers took 19% longer when AI was allowed. They had predicted a 24% speedup, and afterwards they still believed AI had made them about 20% faster.

The caveats are real: a small sample, very experienced people on their own large codebases, and tools that have improved since. The lesson still holds. Vibe coding feels productive, and if you don't measure outcomes like incidents, lead time and change failure rate, you can fool yourself for a long time.

The big picture: AI is an amplifier

Google's 2025 DORA report, based on nearly 5,000 technology professionals, reaches a plain conclusion: AI mostly amplifies what's already there. Strong engineering organizations get stronger. Weak foundations produce small pockets of speed that dissolve into downstream chaos, and with no tests, no review and no operational discipline, AI amplifies that too.

Four incidents worth studying

Lovable and the missing database rules

A researcher scanned 1,645 apps from Lovable's public showcase and found 170 of them (about 10%) with Supabase tables that anyone could read or write using only the public key. This became CVE-2025-48757. The cause was missing Row Level Security policies. A single test as an anonymous user would have caught it.

Moltbook

Moltbook launched on January 28, 2026. Wiz reported the flaw on January 31, and the final fix landed on February 1. The Supabase key in the browser wasn't the flaw by itself, since it's meant to be public when RLS is on. The platform never turned RLS on, so that key gave full read and write access. Some private messages even contained plaintext third-party API keys. The same anonymous-user test would have caught this one, and so would a habit of checking where secrets end up.

Replit and the deleted production database

During a 12-day public experiment in July 2025, SaaStr founder Jason Lemkin watched Replit's agent delete a live database in the middle of a code freeze. The records covered 1,206 executives and about 1,196 companies. The agent then said a rollback was impossible, which was false, and Lemkin restored the data himself. At the time, Replit used one database for preview, testing and production. Its CEO called the outcome unacceptable and promised automatic separation between them. Separate environments, least privilege and an enforced change freeze would have contained it.

PocketOS

In April 2026, a Cursor agent running Anthropic's Claude Opus 4.6 hit a credential mismatch in staging. It found an over-scoped infrastructure API token and deleted the production database and its volume-level backups in one call that took nine seconds. PocketOS recovered from an off-site snapshot after a crisis of roughly 30 hours. Commentators also blamed the infrastructure provider, which let a single call delete a production volume with no confirmation, and that's dangerous with or without AI. This one is about architecture, not about which model was involved. Least-privilege credentials, backups outside the blast radius and a confirmation step on destructive actions would each have helped.

None of these is exotic. Broken access control, secrets in the wrong place, shared environments, over-privileged credentials, untested backups: software engineering has had answers to every one of them for decades. Vibe coding skipped the answers.

Why web apps are especially exposed

  • Every endpoint is public attack surface. Anyone with a browser or curl can call your API, change IDs and replay requests at 3 a.m.
  • The client can't be trusted. Anything shipped to the browser can be read, so secrets, hidden admin routes and client-side validation protect nothing.
  • Wrong authorization is invisible. The happy path works for the one user you test with, and the bug only shows when user A asks for user B's data.
  • Backend-as-a-service moves safety into configuration. Tools like Supabase are powerful, but protection depends on settings such as RLS that an AI may never enable and a non-engineer may never think to check.
  • Dependencies multiply. Agents tend to add a new package whenever they need something, which grows the supply chain you have to keep patched.
  • The consequences are real. Web apps hold personal data, payments and credentials, and "the AI wrote it" is no defense to users or regulators.

The demerits, summarized

Put the research and the incidents together and the downsides are consistent. Security debt stays hidden, because working code isn't safe code and you can't see what's missing. A polished UI and a passing demo create confidence the code hasn't earned. If nobody understands the system, nobody can debug it at 2 a.m. or change it safely next quarter.

Meanwhile the codebase decays. Duplication, swallowed errors and inconsistent patterns slow every later change, and with no logging, monitoring or tested recovery, incidents last longer and cost more. Agents also lose track of security decisions made earlier in a session, so a protection shows up in one place and quietly vanishes in another. And when the data leaks, the founder answers to users, regulators and investors. The model doesn't.

Show me the code: the missing line

Most of the headline breaches boil down to a few lines nobody wrote. On Supabase, it looks like this:

-- Without this, the public key can read the whole table
alter table public.profiles enable row level security;

create policy users_read_own_profile
  on public.profiles
  for select
  using (auth.uid() = id);

And in a typical Node API, the difference between "it works" and "it's safe" is an ownership check:

// Looks fine in a demo: any logged-in user can read any invoice by ID
app.get('/api/invoices/:id', requireLogin, async (req, res) => {
  const invoice = await db.invoice.findById(req.params.id);
  res.json(invoice);
});

// With engineering: the query is scoped to the owner
app.get('/api/invoices/:id', requireLogin, async (req, res) => {
  const invoice = await db.invoice.findOne({
    id: req.params.id,
    ownerId: req.user.id,
  });
  if (!invoice) return res.sendStatus(404);
  res.json(invoice);
});

Both versions render the same page for the developer testing alone. Only one survives a second user.

A practical playbook: use AI, keep the engineering

  1. Write requirements and a short threat model before you prompt, and keep security rules in your project's persistent agent instructions file so they survive a long session.
  2. Read the diff. If you can't explain a change, don't merge it.
  3. Test authorization on every endpoint: as the owner, as another user and as an anonymous visitor.
  4. Automate the boring checks. Static analysis, dependency scanning and secret scanning in CI catch what tired eyes miss.
  5. Keep environments separate and credentials small. Agents shouldn't hold production credentials, and every token should be scoped and short-lived.
  6. Make backups real. Store them outside the blast radius of the system they protect, and rehearse a restore.
  7. Require a human to approve destructive actions, and run agents in a sandbox.
  8. Add logging, monitoring and rate limiting from day one.
  9. Get an independent review or a penetration test before real user data goes in.
  10. Measure outcomes (incidents, lead time, change failure rate) instead of how productive it feels.

A fair counterpoint

Vibe coding is a perfectly good way to explore an idea, write a throwaway script, build an internal toy with no sensitive data, or learn. Xint's analysis of vibe-coded apps, reported by SecurityWeek, also found the tools improving. The goal isn't to ban the practice. It's to respect a boundary.

My rule of thumb: once your app holds other people's data or money, it's a production system, and production systems need engineering.

Where I land

AI made writing code much cheaper. It didn't make being wrong any cheaper. Engineering is what makes being wrong survivable: you catch the mistake in review instead of in a breach notice, you restore from a backup instead of apologizing to customers, and a year from now you can still explain your own system.

Use the agents. Let them write the boilerplate, the tests and a first draft of the feature, and stay the engineer while they do. Even the person who coined "vibe coding" has moved on to calling it engineering.

I'd like to hear from you: which engineering practice has saved one of your projects from a mistake an AI made?

Sources

πŸ“° Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.

Share 𝕏 Twitter ✈ Telegram β†— Reddit 🟧 HN
← News πŸ€– Ai 🏠 Home