Vibecoding responsable: velocidad con fundamentos, pruebas y seguridad

La IA acelera la escritura de código, pero arquitectura, pruebas, seguridad y capacidad de explicar el resultado siguen siendo responsabilidad humana.

Este artículo también está disponible en inglés.
Vibecoding responsable: velocidad con fundamentos, pruebas y seguridad

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

Generar código no equivale a poder operarlo

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 →