Vibecoding sin base técnica es como automedicarse con IA

Tecnología 🌐 ES · EN

Vibecoding sin base técnica es como automedicarse con IA

All articles include both versions in their content: Spanish first, then English.
Vibecoding Without Technical Foundation Is Like Self-Medicating with AI

🧠 Vibecoding sin base técnica es como automedicarse con IA

Hay una idea suelta en muchos círculos técnicos que dice que con las herramientas de IA correctas cualquiera puede construir software hoy. La idea no es falsa del todo, pero tampoco es la historia completa, y la diferencia entre esas dos versiones puede costarle caro a quien la confunda.

El vibecoding es la práctica de generar código mediante prompts en lenguaje natural, dejando que el modelo de lenguaje produzca la lógica sin que el usuario necesariamente entienda lo que se genera. Andrej Karpathy, uno de los investigadores que contribuyó al entrenamiento de modelos fundacionales en OpenAI, describió en febrero de 2025 que él mismo lo practicaba para prototipos rápidos, "olvidando que el código existe". Esa descripción honesta de un experto se convirtió en justificación para muchos que no tienen su contexto, y ahí empieza el problema.

El criterio no lo escribe el prompt.

Cuando un médico recibe a un paciente con dolor de cabeza, tiene dos caminos. Uno es leer los síntomas en voz alta y esperar que el sistema diga qué pastilla recetar. Otro es interpretar los síntomas dentro del historial, descartar causas graves y decidir con criterio clínico. Ambos pueden llegar a la misma recomendación un porcentaje del tiempo, pero solo uno sabe cuándo el otro falla. Con el vibecoding ocurre algo equivalente.

El vibecoding, entendido con precisión, es una interfaz entre lenguaje humano y código máquina. Lo que produce el modelo depende de qué tan bien entrenado está, de la calidad del prompt y, sobre todo, de si quien revisa el resultado puede distinguir una solución funcional de una que funciona solo bajo condiciones específicas. Un desarrollador con base reconoce cuando el código generado ignora casos borde, cuando introduce una vulnerabilidad de inyección SQL, o cuando el modelo "alucinó" una librería que no existe. Un usuario sin base acepta el resultado porque se ejecuta sin error inmediato.

El siguiente ejemplo muestra la diferencia en un endpoint de consulta de usuario. El primer bloque es típico de un prompt sin revisión técnica. El segundo refleja lo que hace alguien que lee lo que el modelo produjo y lo corrige.

# Versión sin revisión técnica (salida directa de prompt novato)
@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())

# Versión con revisión experta
@app.route("/user")
def get_user():
    user_id = request.args.get("id", type=int)
    if user_id is None:
        return jsonify({"error": "id requerido"}), 400
    result = db.execute(
        "SELECT id, nombre, email FROM users WHERE id = ?", (user_id,)
    )
    row = result.fetchone()
    if row is None:
        return jsonify({"error": "usuario no encontrado"}), 404
    return jsonify(dict(row))

La primera versión concatena directamente el parámetro de URL en la consulta SQL, lo que permite la inyección SQL, una de las vulnerabilidades más documentadas desde hace décadas. Además, devuelve todos los campos del usuario incluidos los que no deberían exponerse. La segunda valida el tipo de entrada, usa consultas parametrizadas, limita los campos devueltos y maneja los errores con códigos HTTP correctos. El modelo puede producir ambas versiones dependiendo del prompt. El criterio no lo escribe el prompt.

La calculadora llegó a las oficinas contables en los años cincuenta y sesenta. La predicción de la época era que los contadores desaparecerían porque la máquina hacía los cálculos. Lo que ocurrió fue distinto: la demanda de contadores creció porque la capacidad de procesar más datos creó más necesidad de interpretar esos datos, proyectarlos y auditarlos. La herramienta amplificó el trabajo del que tenía criterio y redujo el valor del que solo sabía operar la máquina manualmente.

Recursos recomendados

YouTube — AI Systems Engineering: From Architecture Principles to Deployment

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

El Foro Económico Mundial proyecta en su reporte de enero de 2025 que se crearán unos 170 millones de empleos nuevos en esta década mientras cerca de 92 millones serán desplazados, con un saldo neto positivo de 78 millones. Dentro de los cinco roles con mayor crecimiento absoluto aparecen los desarrolladores de software. No como víctimas del cambio tecnológico sino como parte de quienes lo construyen.

La encuesta de Stack Overflow a más de 65,000 desarrolladores en 2024 encontró que el 70% de los profesionales no percibe la IA como una amenaza a su empleo, mientras que el 45% de esos mismos profesionales considera que las herramientas de IA son malas o muy malas para manejar tareas complejas. El dato no es una contradicción: es una descripción de por qué el criterio no lo escribe el prompt.

En Colombia la comunidad creció un 25% interanual hasta superar un millón de desarrolladores activos en GitHub según Octoverse 2024. Ese crecimiento está pasando mientras las herramientas de IA se expanden, no a pesar de ello. El riesgo no está en que la profesión desaparezca sino en que quienes no desarrollen criterio técnico queden atrapados en producir código que nadie puede auditar, mantener ni mejorar, porque quien lo generó tampoco entiende cómo funciona.

La automatización no elimina la necesidad de saber; desplaza las tareas mecánicas y concentra el valor en la interpretación, el diagnóstico y la decisión. Un desarrollador sin base puede generar un endpoint con un prompt, pero no puede leer la alerta de seguridad que ese endpoint dispara tres meses después en producción. Quien sabe leer esa alerta es quien tiene trabajo.

Primero entiende qué produce el modelo antes de desplegarlo, luego practica revisar código generado por IA usando los criterios del OWASP Top 10, después compara los dos bloques de código de este artículo en tu propio entorno y analiza por qué uno falla, por último consulta el reporte de Octoverse para leer los datos de tu región antes de apoyar cualquier narrativa sobre desaparición de profesiones.

Si en tu equipo alguien ha usado vibecoding en producción, ¿cómo resolvieron la revisión técnica del código generado? 🔍

→ Explora el hub de IA en Producción →

Versión en inglés

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

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

[YouTube embeds with updated titles translated to English]

The World Economic Forum projects in its January 2025 report that some 170 million new jobs will be created this decade while about 92 million will be displaced, with a net positive balance of 78 million. Among the five roles with greatest absolute growth are software developers. Not as victims of technological change but as part of those building it.

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? 🔍