Responsible Vibecoding: Speed With Fundamentals, Testing, and Security

Published: Updated: Technology 🌐 ES · EN

AI accelerates code writing, but architecture, testing, security, and the ability to explain the result remain human responsibilities.

This article is also available in Spanish.
Responsible Vibecoding: Speed With Fundamentals, Testing, and Security

🧠 Vibecoding Without Technical Foundation Is Like Self-Medicating with AI

Generating Code Is Not the Same as Being Able to Operate It

There's a loose idea in many technical circles saying that with the right AI tools anyone can build software today. The idea isn't entirely false, but it's not the complete story either, and the difference between those two versions can be expensive for whoever confuses them.

Vibecoding is the practice of generating code through natural language prompts, letting the language model produce the logic without the user necessarily understanding what's generated. Andrej Karpathy, one of the researchers who contributed to training foundational models at OpenAI, described in February 2025 that he himself practiced it for quick prototypes, "forgetting that the code exists." That honest description from an expert became justification for many who don't have his context, and that's where the problem starts.

Judgment is not written by the prompt.

When a doctor receives a patient with a headache, there are two paths. One is reading the symptoms aloud and waiting for the system to say what pill to prescribe. Another is interpreting the symptoms within the history, ruling out serious causes, and deciding with clinical judgment. Both can reach the same recommendation a percentage of the time, but only one knows when the other fails. With vibecoding something equivalent happens.

Vibecoding, understood with precision, is an interface between human language and machine code. What the model produces depends on how well it's trained, on prompt quality, and above all on whether whoever reviews the result can distinguish a functional solution from one that works only under specific conditions. A developer with foundation recognizes when generated code ignores edge cases, when it introduces a SQL injection vulnerability, or when the model "hallucinated" a library that doesn't exist. A user without foundation accepts the result because it executes without immediate error.

The next example shows the difference in a user query endpoint. The first block is typical of a prompt without technical review. The second reflects what someone does who reads what the model produced and corrects it.

# Version without technical review (direct output from novice prompt)
@app.route("/user")
def get_user():
    user_id = request.args.get("id")
    query = f"SELECT * FROM users WHERE id = {user_id}"
    result = db.execute(query)
    return jsonify(result.fetchone())

# Version with expert review
@app.route("/user")
def get_user():
    user_id = request.args.get("id", type=int)
    if user_id is None:
        return jsonify({"error": "id required"}), 400
    result = db.execute(
        "SELECT id, name, email FROM users WHERE id = ?", (user_id,)
    )
    row = result.fetchone()
    if row is None:
        return jsonify({"error": "user not found"}), 404
    return jsonify(dict(row))

The first version concatenates the URL parameter directly into the SQL query, which allows SQL injection, one of the most documented vulnerabilities for decades. Plus it returns all user fields including those shouldn't be exposed. The second validates input type, uses parameterized queries, limits returned fields, and handles errors with correct HTTP codes. The model can produce both versions depending on the prompt. Judgment is not written by the prompt.

The calculator arrived in accounting offices in the fifties and sixties. The prediction of the time was that accountants would disappear because the machine did calculations. What happened was different: demand for accountants grew because the capacity to process more data created more need to interpret that data, project it, and audit it. The tool amplified the work of those with judgment and reduced the value of those who only knew how to manually operate the machine.

Recommended Resources

Stack Overflow's survey of more than 65,000 developers in 2024 found that 70% of professionals don't see AI as a threat to their employment, while 45% of those same professionals think AI tools are bad or very bad at handling complex tasks. The data isn't a contradiction: it's a description of why judgment isn't written by the prompt.

In Colombia the community grew 25% year-over-year until surpassing one million active developers on GitHub according to Octoverse 2024. That growth is happening while AI tools expand, not despite it. The risk is not that the profession disappears but that those who don't develop technical judgment get trapped producing code that no one can audit, maintain, or improve, because whoever generated it doesn't understand how it works either.

Automation doesn't eliminate the need to know; it displaces mechanical tasks and concentrates value in interpretation, diagnosis, and decision. A developer without foundation can generate an endpoint with a prompt, but can't read the security alert that endpoint triggers three months later in production. Whoever can read that alert is whoever has work.

First understand what the model produces before deploying it, then practice reviewing AI-generated code using OWASP Top 10 criteria, then compare the two code blocks from this article in your own environment and analyze why one fails, finally consult the Octoverse report to read data from your region before supporting any narrative about disappearance of professions.

If someone on your team has used vibecoding in production, how did you resolve technical review of the generated code? 🔍

Media

YouTube — AI Systems Engineering: From Architecture Principles to Deployment

YouTube — SQL Injection y OWASP Top 10 para reforzar revisión técnica