Think Before You Vibe: Don't Vibe Drunk

Vercel, of course, is a deployment and hosting platform. It is not an answer to the question. He did not know which framework his applications used, which libraries they depended on, how authentication worked, where user data was stored, whether that data was encrypted, or whether secrets and sensitive credentials might be exposed. He could not explain who had access to the database or what would happen if an unauthorized user modified a request before sending it to the server. Yet there he stood, presenting himself as a technology entrepreneur and selling what appeared to be vibed snake oil. More troublingly, people were taking him seriously.

Four numbers worth sitting with before the rest of this piece:

A designer can turn an idea into a working interface. A small-business owner can explore a potential workflow. A student can see how software components interact. An experienced engineer can automate repetitive implementation work and move more quickly through a familiar architecture.

A screen that loads is not necessarily a functioning application. A login form does not prove that authentication is secure. A database connection does not establish that authorization rules are correct. A polished dashboard tells us nothing about data isolation, dependency vulnerabilities, error handling, backups, auditability, or regulatory compliance.

Traditional software failures were often visible: the program crashed, the compiler complained, or the feature did not work. AI-generated software can fail more convincingly. It may appear to work during a demonstration while quietly exposing customer records, accepting unauthorized requests, or trusting values that should have been verified on the server. The interface creates confidence that the underlying engineering has not earned.

These are not obscure questions reserved for elite cybersecurity specialists. They are part of the basic responsibility of operating software. OWASP's secure-coding guidance covers input validation, authentication, session management, access control, cryptography, error handling, database security, and protection of sensitive data — and its secure-by-design framework emphasizes that security must be incorporated into architecture before code is written, not attached after the product is already assembled.

A person does not have to memorize every implementation detail. Experienced architects consult documentation, collaborate with specialists, and use automated tools. The essential difference is that they know which questions must be asked, which assumptions must be challenged, and which risks require expert review.

Giving everyone access to power tools does not make everyone a structural engineer. Making automobile components easier to manufacture does not mean anyone can safely design a braking system. The democratization of construction does not repeal the laws of engineering. The most irresponsible message, therefore, does not always appear in a formal technical document — it emerges from the total atmosphere surrounding the products: build anything, build it instantly, do it without coding, replace a team with a prompt, and worry about the details later. But in software, the details are the product.

That would be survivable if the juniors who do get hired were still learning to code. The evidence suggests many are not. An Anthropic randomized controlled trial found that developers who delegated coding tasks to AI scored meaningfully worse on subsequent comprehension tests than developers who used AI conversationally — about 17 percent lower, while those who used AI to ask conceptual questions scored well above baseline.

Senior engineers are not spontaneously generated. They are junior engineers who spent years being wrong in front of a compiler, tracing bugs by hand, and building the instinct that only comes from having personally broken something and fixed it. If that apprenticeship is skipped, the industry is not saving five years of training cost — it is deferring the bill to a moment, five or ten years from now, when it discovers it has no one left who actually knows how the systems work.

Developers describing this experience keep reaching for the same metaphor: muscle memory, replaced by the act of waiting for a suggestion. A widely shared comparison is GPS navigation — it makes you better at arriving, and worse at understanding the geography you passed through, with the erosion becoming visible only when the tool is unavailable or wrong.

Here is what makes this genuinely dangerous rather than merely nostalgic: AI does not evenly distribute its help. It tends to speed up exactly the routine work senior engineers had already automated in their own heads, while offering little help on the novel architectural problems and subtle bugs where their judgment actually matters. That same judgment — the instinct that recognizes a timing-attack vulnerability in a clean-looking authentication function, or knows that mapping over a million-row array will page someone at 3 a.m. — is precisely the thing that atrophies when it goes unexercised for long enough.

I have described this broader condition elsewhere as the Blinded Mind Problem: a system crosses a comprehension threshold when its complexity and output exceed the ability of the responsible human or institution to understand, audit, and control it. A system that cannot be understood cannot be reliably secured or governed.

An automated reviewer can be valuable — it can identify patterns, flag suspicious changes, and supplement human analysis. NIST's Secure Software Development Framework explicitly describes tool-based review as something that complements rather than replaces review by people. OWASP likewise defines secure code review as manual examination intended to identify vulnerabilities that automated tools may miss, particularly those involving business logic and contextual understanding. The problem is not AI review. The problem is circular automation without accountable comprehension.

The security differences included greater rates of cross-site scripting, insecure object references, improper password handling, and insecure deserialization — weaknesses that can expose accounts and data or allow attackers to manipulate an application. AppSec Santa reported confirmed vulnerabilities in 25.7 percent of 522 AI-generated code samples tested across six models using five static-analysis tools, with server-side request forgery and path-traversal weaknesses among the most common findings.

A separate compilation of recent studies describes audits of thousands of publicly accessible vibe-coded applications that found exposed secrets, credentials, and personally identifiable information in production systems. AI-generated code can be useful, elegant, and correct. It can also be insecure in ways that remain invisible to someone who lacks the knowledge to inspect it. That is precisely why confidence is not evidence.

None of the underlying research was measuring AI-generated code specifically — most of it predates the current wave of AI-assisted development. That's exactly the point. Technical debt at this scale was already accumulating when humans were writing every line by hand, deliberately and mostly with an understanding of what they were building. Someone always pays eventually — the company, in slower delivery and rising maintenance costs; the next engineer, in hours spent reverse-engineering a system nobody documented; or the customer, in a breach, an outage, or a compliance failure that traces back to a decision nobody remembers making, let alone understood at the time.

What did the AI actually build? What assumptions did it make? Which packages did it install? Which permissions did it grant? What data does it collect, and who can retrieve it? How will the system fail, and who will recognize that failure? Who will be accountable when someone is harmed? And, eventually: who is going to pay to fix it, and will there be anyone left on the team who still remembers how?

That danger grows dramatically in medicine, finance, healthcare, law, transportation, and other fields in which software decisions affect rights, safety, property, and human lives. Poorly engineered systems do not remain charming prototypes forever. They accumulate users, integrations, dependencies, and data. By the time an organization discovers it cannot explain the system it now depends upon, the cost of understanding it may exceed the cost that proper engineering would have required in the first place.

AI should help engineers move faster without asking them to stop being engineers. It should assist with implementation without eliminating architecture. It should strengthen code review without creating the illusion that review no longer requires a qualified human. And it should never be allowed to quietly replace the apprenticeship that turns juniors into seniors, or the practice that keeps seniors sharp.

A responsible AI-assisted development process should still include documented architecture, explicit data classification, threat modeling, dependency inventories, secrets management, access-control testing, automated security scanning, human review, logging, incident planning, clear ownership of every production system — and, deliberately, time spent coding without the assistant on, so the skill underneath the tool doesn't quietly disappear.