Regresar
001

El checklist de 10 preguntas antes de pedirle a la IA que construya algo

Actualizado: 13/09/2026

Antes de abrir el chat con la IA vale la pena hacerte una pregunta simple: ¿sé qué quiero construir, o voy a dejar que el modelo decida por mí?

Cuando la respuesta está clara, la IA se vuelve una herramienta rápida para ejecutar tu criterio. Cuando no lo está, decide ella, casi siempre con la opción más repetida en internet, que no es necesariamente la correcta para lo que estás construyendo.

Este checklist son diez preguntas que conviene responder antes de escribir el primer prompt. Ninguna es técnica. Todas son decisiones que la IA va a tomar por ti, en silencio, si no se las das resueltas.

Para qué sirve responderlas antes

Una respuesta provisional tuya vale más que una respuesta implícita del modelo. No porque sea mejor, sino porque es revisable: sabes que la tomaste, sabes con qué información, y sabes cuándo volver sobre ella.

Lo que no se puede revisar es lo que nunca se decidió.

Árbol corto que parte de la pregunta de si el error se corrige recargando la página. Si la respuesta es sí, adelante sin más, con ejemplos como cambiar un texto, renombrar una variable o ajustar un estilo. Si es no, conviene responder antes las diez preguntas, con ejemplos como empezar un proyecto, tocar datos de usuarios o dinero, o integrar un servicio externo
La señal es sencilla: si deshacer el error cuesta una recarga, no hace falta el checklist.

Cuándo usarlo y cuándo no

Pasar por las diez preguntas toma unos diez minutos. Ese costo se justifica al empezar un proyecto, al agregar una funcionalidad que toca datos de usuarios o dinero, y al integrar un servicio externo nuevo.

No se justifica para arreglar un estilo, renombrar una variable o cambiar un texto. Aplicarlo a todo lo convierte en burocracia y deja de usarse, que es la peor forma de perderlo.

Hay una señal simple para saber si aplica: pregúntate si el error se corrige recargando la página. Si la respuesta es sí, sáltate el checklist.

El error más común: responder lo que uno quisiera

Hay una forma de fallar el checklist que no tiene que ver con saltárselo. Es responderlo con el proyecto que uno espera tener en vez del que tiene.

A la primera pregunta se responde bueno, si sale bien podrían ser miles. A la del presupuesto, ya conseguiré cómo pagarlo. A la de quién mantiene el código, seguro contrato a alguien. Cada una es una intención razonable, y las tres juntas producen exactamente la arquitectura sobredimensionada que el checklist buscaba evitar.

El criterio útil es responder con lo que es verdad hoy, no con lo que sería verdad en el mejor escenario. Un sistema simple que funciona para veinte usuarios se puede hacer crecer cuando lleguen los mil. Un sistema complejo construido para los mil que nunca llegaron no se puede simplificar: hay que reescribirlo.

La forma honesta de plantearlo es cambiar el tiempo verbal. No cuántos usuarios voy a tener, sino cuántos usuarios tengo esta semana. La segunda pregunta tiene una respuesta verificable; la primera, no.

Cuando las respuestas cambian a mitad del proyecto

Ninguna de las diez respuestas es permanente, y varias van a cambiar justamente en los proyectos que salen bien. Llegan usuarios reales, aparece un cliente que exige un contrato de disponibilidad, o empiezas a guardar un tipo de dato que antes no tocabas.

El problema no es que cambien. Es que casi siempre cambian sin que nadie lo note, porque el cambio ocurre en el negocio y el código se entera meses después.

Tres cambios que conviene tratar como disparadores para revisar la lista completa, no solo la pregunta afectada:

  • Empiezas a cobrar. Cambia la tolerancia a caídas, aparece regulación de medios de pago y el monitoreo deja de ser opcional.
  • Entra otra persona al proyecto. La pregunta de quién va a entender el código deja de ser hipotética, y lo que estaba solo en tu cabeza pasa a ser un problema real.
  • Guardas una categoría de dato nueva. Un campo de fecha de nacimiento o un número de documento puede mover el proyecto entero a un régimen legal distinto.

Cuando alguno de los tres ocurra, el checklist vuelve a valer sus diez minutos. Y esta vez las respuestas se escriben encima de las anteriores, no en limpio: ver qué cambió respecto de lo que habías decidido es más útil que la respuesta nueva por sí sola.

Qué hacer con las respuestas

Responderlas mentalmente y seguir adelante sirve de poco: a la tercera sesión ya no vas a recordar qué decidiste ni por qué. Lo que funciona es dejarlas escritas donde la IA pueda leerlas al inicio de cada conversación.

# Contexto del proyecto

- Escala: menos de 200 usuarios, sin crecimiento previsto este año
- Caída tolerable: hasta 2 horas, sin penalización
- Secretos: variables de entorno del hosting, nunca en el repositorio
- Presupuesto: 15 USD al mes, sin servicios gestionados
- Datos regulados: ninguno, no se guardan datos de salud ni pagos
- Mantenimiento: una sola persona, sin experiencia en el framework

Seis líneas. Pegadas al inicio de una sesión, eliminan la mayoría de las propuestas sobredimensionadas antes de que aparezcan, porque le quitan al modelo justamente los huecos que rellenaba solo.

  1. ¿Cuánta gente va a usar esto de verdad?

    No es lo mismo programar para veinte personas que conoces por su nombre que para un producto que esperas que crezca solo. La diferencia no está en la calidad del código, está en qué problemas vale la pena resolver hoy.

    La respuesta honesta casi siempre es un número más chico del que uno quisiera admitir. Y ese número chico es una buena noticia: descarta de entrada la caché, las colas, los microservicios y la mitad de las capas que la IA propone por defecto.

    Si todavía no lo sabes, arranca por lo más simple que funcione. Escalar un sistema simple es un problema conocido y acotado. Simplificar un sistema complejo que nadie entiende, no.

  2. Si esto se cae diez minutos, ¿a quién le importa?

    A veces la respuesta sincera es a nadie. Un panel interno que usan tres personas en horario de oficina puede estar caído una tarde entera sin consecuencias reales.

    Cuando ese es el caso, la alta disponibilidad, los reintentos automáticos y los despliegues sin interrupción no son prudencia: son tiempo invertido en un problema que no tienes.

    Si en cambio una caída de diez minutos significa pedidos perdidos o un cliente que incumple un contrato, ahí sí se justifica gastar en redundancia. Lo que no se justifica nunca es no haberlo decidido.

  3. Las contraseñas y los tokens, ¿dónde van a vivir?

    Esta se decide antes, no después, porque el momento en que la IA escribe el código es el momento en que la clave termina donde quede más cómodo. Y lo más cómodo es escribirla directo en el archivo.

    El mínimo razonable son variables de entorno fuera del repositorio, con el archivo que las contiene ignorado por el control de versiones. De ahí para arriba hay gestores de secretos dedicados, que valen la pena cuando hay más de una persona o más de un entorno.

    Hay una pregunta que conviene hacerse en voz alta: si el repositorio se volviera público mañana por error, ¿qué habría que rotar? Si la lista no es vacía y no sabes cómo rotarlo, esa es la primera tarea.

  4. ¿Tengo presupuesto para lo que le acabo de pedir?

    Pedir hazlo escalable sin más contexto es una de las formas más caras de hablar con una IA. Es común terminar con una arquitectura distribuida para una aplicación que usan diez personas.

    El presupuesto es un requisito de arquitectura tan legítimo como el rendimiento. Decir tengo quince dólares al mes y un hosting compartido cambia por completo el conjunto de respuestas posibles, y las cambia para mejor.

    Conviene incluir el costo que no aparece en la factura: cada servicio gestionado que agregas es una consola más que aprender, una cuenta más que administrar y un proveedor más del que dependes.

  5. Esta decisión, ¿qué tan fácil es revertirla en seis meses?

    Es la pregunta que mejor ordena el resto. Las decisiones se dividen en dos grupos y merecen niveles de análisis muy distintos.

    Cambiar una librería de fechas, reemplazar un componente visual o mover un archivo de lugar es barato: se hace en una tarde y nadie se entera. Ahí conviene decidir rápido y seguir.

    Cambiar el modelo de datos con usuarios reales dentro, migrar de proveedor de autenticación o alterar cómo se identifican las cuentas es caro, lento y riesgoso. Esas merecen que te detengas aunque la IA ya te haya dado una respuesta que se ve bien.

  6. ¿Hay alguna ley de por medio?

    Protección de datos personales, información de menores, datos de salud, datos financieros. Cada categoría trae obligaciones concretas sobre qué puedes guardar, por cuánto tiempo y qué tienes que poder borrar si alguien lo pide.

    La IA no sabe en qué país operas ni qué regulación te aplica, y no va a preguntarlo. Va a proponer un esquema de datos técnicamente correcto que puede ser ilegal en tu jurisdicción.

    No hace falta ser abogado para la parte que te toca: basta con saber qué tipo de dato vas a guardar y decirlo explícitamente antes de que se diseñe la tabla que lo contiene.

  7. ¿Quién más va a tener que entender este código?

    Si la respuesta es solo yo, preguntándole otra vez a la IA dentro de unos meses, conviene pedir explícitamente que evite patrones que requieran conocimiento especializado para leerse.

    Un patrón puede ser técnicamente superior y aun así ser la decisión equivocada, si te deja con código que no puedes explicar ni modificar sin ayuda. La elegancia que no entiendes es deuda, no calidad.

    Vale la pena incluirte a ti mismo dentro de seis meses en la lista de personas que van a tener que entenderlo. Es, con diferencia, el lector más frecuente.

  8. ¿Cómo me voy a enterar si algo se rompe?

    Si la respuesta es cuando un usuario se queje, falta lo mínimo antes de lanzar. No hace falta una plataforma de observabilidad: hace falta saber que algo falló antes que quien lo sufre.

    El piso razonable son tres cosas: que los errores queden registrados en algún lado que puedas consultar, que ese registro incluya suficiente contexto para ubicar el problema, y que algo te avise cuando el sitio deje de responder.

    Sin eso, cada incidente empieza con la peor pregunta posible, que es desde cuándo está pasando esto.

  9. ¿Qué integré sin entender bien cómo funciona?

    Cada librería y cada servicio externo que aceptaste sin leer es algo que no vas a poder arreglar el día que falle. Y va a fallar en el peor momento, porque los servicios externos no fallan cuando uno tiene tiempo.

    La prueba concreta es intentar explicar, en una frase, qué hace cada dependencia del proyecto y qué pasaría si la quitas. Las que no puedas explicar son las que conviene revisar o reemplazar.

    Esto pesa el doble cuando la integración toca autenticación, permisos o pagos. Ahí el beneficio de la duda no aplica.

  10. Lo que le pedí a la IA, ¿fue una opinión o fue que decidiera por mí?

    Es la pregunta que cierra el checklist porque resume todas las anteriores. Pedir una opinión es traer información a una decisión que sigue siendo tuya. Delegar es aceptar el resultado sin haber definido el criterio.

    Las dos cosas son legítimas. El problema aparece cuando uno cree estar haciendo la primera y en realidad está haciendo la segunda, que es lo que pasa cuando el prompt no dice nada sobre escala, presupuesto ni restricciones.

    Si al terminar no tienes claro en cuál de los dos casos estás, vuelve a las nueve preguntas anteriores antes de aceptar lo que te devolvió.

Después del checklist

Estas diez preguntas no buscan que tengas una respuesta perfecta para cada una antes de empezar. Buscan que la respuesta sea tuya, aunque sea provisional, en lugar de heredarla por defecto de lo que la IA asumió sin que se lo pidieras.

Las respuestas cambian según el proyecto, y lo que fue correcto para uno puede no serlo para el siguiente. Por eso conviene volver a la lista cada vez que empieces algo nuevo, no solo la primera vez que la leas.

Si alguna te quedó sin responder, no es un fallo del checklist: es información. Una pregunta sin respuesta marca exactamente dónde el modelo va a decidir por ti, y ahí es donde conviene mirar primero cuando algo salga distinto a lo que esperabas.


Checklist práctico principiante