Tu primer proyecto con IA necesita una restricción, no más funciones

Por /

Cuando empiezas un proyecto con inteligencia artificial lo más tentador es seguir añadiendo funciones: “entiende la intención”, “corrige el texto”, “sugiere mejoras”. Esa expansión abre ambigüedad: cada nueva función crea formas alternativas de resolver el problema, reduce la verificabilidad y facilita que el proyecto sea subjetivo. En cambio, un proyecto principiante se vuelve verificable si eliges una restricción clara que excluya soluciones triviales y defines criterios de aceptación medibles. Añadir funcionalidades sin esa restricción expande el espacio de soluciones y termina por ocultar si la IA está cumpliendo lo prometido.

Esta guía paso a paso explica por qué priorizar una restricción, propone un alcance mínimo viable concreto, lista tareas pequeñas para implementar y transforma la idea vaga en cuatro checkpoints verificables. Las recomendaciones toman como base ideas de desarrollo guiado por especificación para sistemas AI-native (Microsoft: Spec-driven development), la descomposición y el pensamiento computacional para convertir problemas complejos en piezas comprobables (PMC: decomposition & computational thinking) y observaciones sobre cómo la asistencia de IA modifica las habilidades de programación (Anthropic: AI assistance & coding skills).

Por qué una restricción hace verificable un proyecto

Una restricción actúa como una guardrail: limita las soluciones válidas y convierte juicios vagos en condiciones que pueden medirse. Según el enfoque spec-driven, antes de escribir parámetros de IA o pedir prompts, hay que definir la especificación que describe la intención, las restricciones y los criterios de aceptación. Sin eso, los prompts y las salidas se interpretan de múltiples maneras. Limitar el problema evita que la IA “resuelva” por la vía más compleja (o la más automática) y obliga a diseñar pruebas concretas.

La descomposición (dividir para conquistar) ayuda a convertir una restricción en micro-problemas comprobables: cada subproblema tiene entradas, transformaciones y salidas esperadas. Esto facilita pruebas manuales o automáticas y evita que el proyecto se convierta en una colección de supuestos. Además, cuando trabajas con asistencia de IA, es crítico decidir qué decisiones no delegas: la IA puede generar código y sugerencias, pero las decisiones de especificación, criterios de aceptación y límites del alcance deben quedar en humanos.

Alcance mínimo verificable: lista pequeña de tareas

Define un MVP que puedas verificar en minutos y que no dependa de infraestructura. Propongo estas restricciones explícitas:

  • Persistir el estado del usuario en localStorage (sin servidor ni base de datos externa).
  • Cada ítem de la lista tiene exactamente una acción: marcar como completado / alternar estado completado.
  • No hay autenticación ni cuentas de usuario.
  • No hay backend: toda la lógica está en el cliente (HTML/CSS/JS).
  • Mostrar un estado vacío claro cuando la lista no tiene ítems.

Este alcance es deliberadamente pequeño: elimina muchas rutas de solución (auth, backend, sincronización, notificaciones) y te permite centrar la verificación en comportamientos concretos. Si la IA “propone” una mejora, devuélvela al backlog y no la implementes hasta que pases los checkpoints.

Convierte la idea vaga en cuatro checkpoints verificables

Cada proyecto debe pasar estos cuatro checkpoints antes de considerarse válido. Piénsalos como pruebas de aceptación mínimas.

  1. Restricción buena (¿qué se excluye?):

    Define explícitamente lo que no está permitido. En este caso: no backend, no auth, no sincronización remota, no dependencias externas para persistencia. Comprobación: inspecciona el código y verifica que no hay llamadas fetch/xhr ni referencias a servidores. Requisito de aceptación: al recargar la página, los datos persisten usando localStorage.

  2. Alcance (qué incluye exactamente):

    Lista las funcionalidades mínimas. Aquí: crear ítem, mostrar ítem, alternar completado, borrar opcional (si quieres), estado vacío. Comprobación: prueba manual hipotética siguiendo pasos de usuario (añadir 3 ítems, completar 1, recargar, ver que el estado se mantiene).

  3. Criterio de aceptación (qué mide éxito):

    Especifica con ejemplos y pasos. Por ejemplo: “Cuando el usuario añade ‘Comprar pan’ y recarga, la lista contiene exactamente ese ítem en la posición X y su propiedad ‘completed’ es false.” Estos criterios deben ser suficientemente concretos para que dos personas independientes lleguen al mismo veredicto.

  4. Decisión no delegable (qué decide el humano):

    Establece qué decisiones no puede tomar la IA. Por ejemplo: el formato de almacenamiento (clave de localStorage), el esquema de datos (id, texto, completed, timestamp) y los criterios de aceptación. La IA puede sugerir implementaciones, pero la validación de que la restricción se cumple es humana.

Checklist de aceptación ejemplar

  • Al abrir la aplicación por primera vez, se muestra el estado vacío con un mensaje y un campo para añadir ítems.
  • Al añadir “Tarea A”, aparece un elemento en la lista con texto “Tarea A” y un botón/checkbox para marcar como completado.
  • Al marcar “Tarea A” como completada, su propiedad visual cambia (clase completed) y localStorage refleja completed=true.
  • Al recargar la página, la lista sigue conteniendo los ítems y sus estados (persistencia verificada).
  • No hay errores de red ni solicitudes externas en el inspector del navegador (verificación de restricción: no backend).

Paso a paso operativo para implementar (guion rápido)

  1. Crear tres archivos: index.html fragmentario, app.js, styles.css (opcional). No uses frameworks para mantenerlo simple.
  2. Definir el esquema de datos en la parte superior de app.js:
    // Esquema simple
// key: 'miListaV1'
// item: { id: string, text: string, completed: boolean, createdAt: number }
  3. Implementar funciones puras para manipular el array en memoria: addItem, toggleItem, saveToLocalStorage, loadFromLocalStorage. Separar la lógica de UI para facilitar pruebas.
  4. UI mínima: campo de texto + botón “Añadir”; lista
      ; cada

    • con checkbox y texto; elemento que muestra el estado vacío cuando la lista está vacía.
    • Verificación manual: seguir el checklist de aceptación. Registra fallos y ajusta la especificación si descubres ambigüedades.

Ejemplo mínimo de función de persistencia (concepto, no bloque completo):

const STORAGE_KEY = 'miListaV1';

function save(items) {
  localStorage.setItem(STORAGE_KEY, JSON.stringify(items));
}

function load() {
  const raw = localStorage.getItem(STORAGE_KEY);
  return raw ? JSON.parse(raw) : [];
}

function addItem(items, text) {
  const item = { id: Date.now().toString(), text, completed: false, createdAt: Date.now() };
  const next = [...items, item];
  save(next);
  return next;
}

function toggleItem(items, id) {
  const next = items.map(it => it.id === id ? { ...it, completed: !it.completed } : it);
  save(next);
  return next;
}

Con esas funciones puedes construir la UI y, más importante, puedes probar las funciones de forma aislada para cumplir la especificación antes de interactuar con la IA para optimizaciones.

Cómo escribir criterios de aceptación que eviten soluciones triviales

Un criterio de aceptación útil es específico en entradas y salidas, y obliga a pruebas reproductibles. Evita frases como “la app debe guardar bien” y prefiere “al introducir el texto ‘X’ y pulsar Añadir, la lista debe contener un ítem con text=’X’ y completed=false; tras recargar, el mismo ítem debe existir y mantener completed=false”. Eso elimina soluciones que, por ejemplo, muestran los ítems solo en memoria temporal.

La descomposición ayuda: divide la historia de usuario en pasos de entrada/salida y verifica cada paso. Microsoft recomienda formular la intención, las restricciones y aceptación antes de implementar, lo que reduce la improvisación. Si usas IA para generar código, pídele fragmentos para cada función pura (addItem, toggleItem, save/load) y valida que las funciones cumplen los criterios sin añadir lógica de sincronización o llamadas de red.

La revisión que haces antes de pedir otra función

Cuando el MVP ya guarda tareas y resiste una recarga, la IA suele ofrecer una lista de mejoras atractivas: filtros, etiquetas, tema oscuro, recordatorios o cuentas de usuario. La pregunta correcta no es si puede generarlas rápido, sino si cada una conserva el contrato que acabas de verificar. Un filtro, por ejemplo, parece una mejora visual, pero introduce estado nuevo: debes decidir si se guarda, qué ocurre al añadir una tarea mientras el filtro está activo y cómo explicar una lista vacía que puede significar dos cosas distintas.

Convierte esta revisión en una regla sencilla: una mejora conserva la restricción y reduce fricción; una expansión cambia los datos, las pruebas o las decisiones que el usuario debe entender. Antes de aceptar código nuevo, escribe dos líneas: “la restricción que permanece es…” y “la condición de aceptación adicional será…”. Si no puedes terminar la segunda frase, la función pertenece al backlog, no al prompt actual. Esta pausa evita que un proyecto pequeño termine siendo una demostración llena de piezas que nadie sabe validar.

También ayuda a cerrar cada sesión con una nota breve: qué criterio pasó, qué supuesto no se comprobó y cuál es la próxima decisión humana. Esa memoria permite retomar el proyecto sin pedir a la IA que reconstruya todo el contexto. La herramienta puede acelerar la siguiente implementación; la dirección permanece tuya porque el alcance, las restricciones y las preguntas abiertas siguen visibles.

Qué decisiones no delegar a la IA

  • El conjunto de restricciones (no backend, no auth, persistencia local).
  • El formato del dato y el contrato de la API interna (esquema de item en localStorage).
  • Los pasos concretos del checklist de aceptación.
  • Si una propuesta de IA añade una nueva interfaz o función que cambia el scope, esa decisión es humana.

La asistencia de IA es útil para acelerar la implementación (sugerir código, refactorizar), pero no para decidir los límites del experimento inicial. Anthropic y otros estudios muestran que la IA modifica cómo los programadores resuelven problemas; eso es una ventaja, siempre y cuando la especificación siga siendo humana y verificable.

Evita añadir funciones hasta pasar los checkpoints

Añadir funciones antes de validar el MVP reabre ambigüedad sobre qué significa “funciona”. Si permites una función como “sugerencias automáticas” o “sincronización futura”, necesitas criterios y pruebas nuevas. Mantén la lista de tareas pequeña y pasea nuevas ideas al backlog con una etiqueta “no verificada”. Si una iteración requiere añadir algo para validar otro requisito, trata ese cambio como una nueva historia con su propia restricción y criterios.

Si quieres leer más sobre cómo prompts y expectativas pueden contradecir el código generado o cómo la IA puede guiar (o confundir) el proceso de corrección, revisa estos artículos de apoyo en el sitio:

Estos recursos te ayudarán a identificar cuándo la IA está ampliando el alcance sin control y cómo volver a la especificación.

Por último: documenta la especificación y los criterios de aceptación en un archivo README o en la descripción de la tarea. Antes de pedirle a la IA cualquier cambio, pregúntate: ¿esto rompe alguna restricción? Si la respuesta es sí, trata el cambio como una historia separada y aplica los cuatro checkpoints otra vez.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Scroll al inicio