la IA puede ayudarte muchísimo a programar… pero copiar y pegar sin filtro es como cambiar una pieza del coche “porque encaja” sin saber si era la correcta. Puede ir bien. O puede salir caro.
Así que aquí tienes una versión más legible y apta para público no técnico, sin perder lo importante. La idea es que cualquiera (tú, tu cliente, tu compi de producto, tu yo del futuro) pueda entender por qué este checklist existe.
Por qué “vibe coding” mola… y por qué puede ser una trampa
Cuando hablamos de vibe coding nos referimos a esa forma de trabajar donde le pides a la IA un trozo de código, lo pegas y sigues, porque “tiene buena pinta” y te ahorra tiempo.
Y sí: ahorra tiempo al principio.
El problema es que a veces el código:
- no está pensado para tu web o tu app,
- no cumple tus normas internas,
- o trae consecuencias (seguridad, rendimiento, errores raros) que no se ven en el primer minuto.
Resumen: la IA te da velocidad. Pero tú necesitas seguridad y control.
La comparación clave: tiempo de decisión vs. carga mental
Esto es lo más importante del post.
- Tiempo de decisión: lo que tardas hoy en revisar antes de subir algo.
- Carga mental: lo que te obliga a pensar, arreglar y explicar después si algo sale mal.
Pegar código sin revisar suele ahorrar 10 minutos hoy… y costar horas (o días) mañana.
Este checklist existe para que decidas un poquito mejor ahora y no sufras después.
El checklist anti-catástrofes: 12 preguntas (explicadas “para humanos”)
Úsalo como un semáforo: si respondes “no lo sé” a varias, no es drama… pero no lo subas tal cual.
1) ¿Qué hace exactamente este código?
Si no puedes explicarlo en una frase, es que todavía no lo controlas.
Ejemplo: “Esto muestra una lista de artículos y los ordena por fecha.”
Perfecto. Si no sabes qué hace, no lo pegues.
2) ¿Entiendo lo básico de cómo lo hace?
No tienes que saberlo todo, pero sí entender:
- qué datos entran,
- qué cambia,
- y qué sale.
Si es “magia negra” desde el minuto 1, te costará el triple mantenerlo.
3) ¿Encaja con mi proyecto o es una pieza de otro puzzle?
A veces la IA escribe código “genérico” que no sigue:
- tu forma de trabajar,
- tu estilo,
- tu estructura.
Si tu proyecto tiene una manera clara de hacer las cosas, el código debe adaptarse a eso.
4) ¿Trae cosas extra que no pedí?
Esto pasa muchísimo.
Ejemplos típicos:
- añade librerías nuevas,
- mete funciones que no necesitas,
- cambia comportamientos sin avisar.
Si el código trae “regalos”, desconfía. En programación, los regalos suelen venir con letra pequeña.
5) ¿Qué pasa si algo falla?
En el mundo real fallan cosas:
- internet,
- servidores,
- datos que vienen vacíos,
- permisos.
Si el código no contempla fallos, puede romperse justo cuando más lo necesitas.
6) ¿Hay algún riesgo de seguridad?
Pregunta sencilla:
¿Este código toca contraseñas, inicios de sesión, formularios, pagos, datos personales o permisos?
Si la respuesta es sí, necesitas doble revisión.
Ejemplos de riesgo:
- guardar tokens en lugares inseguros,
- mostrar datos sensibles,
- aceptar textos sin validar (puede abrir puertas a ataques).
7) ¿Usa datos personales? ¿Los guarda? ¿Los envía?
Aquí no se trata de ser abogado/a, se trata de sentido común:
- ¿recoge nombre, email, teléfono, ubicación?
- ¿lo guarda sin fecha de caducidad?
- ¿lo manda a servicios externos?
Si no lo tienes claro, hay riesgo.
8) ¿Esto puede volver la web lenta?
A veces el código funciona, pero:
- carga demasiadas cosas,
- repite llamadas a internet,
- hace cálculos pesados,
- obliga a la página a “recolocarse” todo el rato.
Si tu web se vuelve lenta, el usuario se va. Así de simple.
9) ¿La experiencia de usuario es buena?
Aquí entra lo que se siente “bien”:
- ¿hay mensajes claros si algo falla?
- ¿se entiende qué pasa cuando cargas?
- ¿el botón hace lo que promete?
- ¿no hay comportamientos raros?
Lo que parece pequeño puede convertirse en frustración.
10) ¿Es accesible para todo el mundo?
Pregunta práctica:
¿Se puede usar con teclado sin ratón?
También:
- ¿se leen bien los textos?
- ¿hay suficiente contraste?
- ¿las ventanas emergentes (modales) se pueden cerrar bien?
Accesibilidad no es extra. Es parte del producto.
11) Si esto falla en producción, ¿me enteraré?
Esto es clave.
Porque hay fallos que solo se ven cuando ya está en producción.
Entonces necesitas:
- logs útiles (sin datos sensibles),
- avisos,
- señales claras.
Si no hay nada, te enteras por un usuario enfadado. Y eso es lo peor.
12) Si sale mal… ¿Puedo deshacerlo rápido?
Una pregunta que salva proyectos:
¿Hay plan B?
- ¿puedes volver a la versión anterior?
- ¿puedes activar/desactivar la función?
- ¿puedes revertir sin romper datos?
Si no puedes deshacer rápido, el riesgo se multiplica.
Cómo usar este checklist sin volverte lenta
Hazlo “rápido y rutinario”
No es para escribir un ensayo. Es para revisar con cabeza.
Un buen objetivo:
- 5 minutos en cambios pequeños
- 15–30 minutos en cambios críticos (login, pagos, seguridad)
Úsalo donde importa
- en un checklist de revisión antes de subir cambios,
- en una plantilla de PR (si trabajas con Git),
- o en tu propio “antes de publicar”.
Preguntas Frecuentes (FAQs)
1) ¿Entonces está mal usar código generado por IA?
No. Lo que está mal es subirlo sin entenderlo.
La IA es una herramienta. Tú eres quien decide si entra en producción.
2) ¿Qué preguntas son las más importantes?
Si quieres ir a lo mínimo vital:
seguridad (6), fallos (5), lentitud (8), enterarte si falla (11) y poder deshacer (12).
3) ¿Esto no me hará ir más lenta?
Al revés: te hace ir más rápido en el tiempo total.
Porque evita que pierdas horas después arreglando incendios.
El vibe coding tiene algo adictivo
El vibe coding tiene algo adictivo: te da velocidad, sensación de avance y dopamina de “funciona”. Y eso no es malo. Lo que es peligroso es confundir fluidez con fiabilidad.
Este checklist no intenta frenarte. Intenta que tu rapidez no se convierta en deuda invisible. Porque en producción no gana quien escribe más rápido, gana quien escribe código que otras personas pueden entender, operar y mejorar sin miedo.
Si te quedas con una sola idea, que sea esta: invertir un poco de tiempo de decisión hoy reduce muchísimo la carga cognitiva mañana. Y eso, en un proyecto real, es la diferencia entre vivir apagando fuegos… o construir con calma.