Usaste una herramienta de programación con IA para crear una función. Aparece la lista, funcionan los filtros y otra petición puede cambiar el resultado. Entonces alguien pregunta por qué desapareció un elemento o si modificar una regla afectará a los otros filtros. Tienes que volver a preguntar a la IA.

Prueba con un pequeño filtro de JavaScript. Anota qué elementos conservará, cambia a mano el umbral de existencias y compara el resultado con tu predicción.

Elige un comportamiento que puedas predecir

«Enséñame toda esta aplicación» es una tarea amplia. Elige un resultado concreto: ¿qué elementos quedan al combinar categoría, texto de búsqueda e interruptor de disponibilidad?

Responde a tres preguntas antes de cambiar nada:

  1. ¿Qué identificadores debe devolver esta entrada?
  2. ¿Qué condición incluye o excluye cada elemento?
  3. Si cambia la regla de disponibilidad, ¿qué resultados deberían permanecer iguales?

Si todavía no entiendes la sintaxis, lee una expresión cada vez. Aquí, filter conserva elementos cuya función devuelve true, && exige que se cumplan todas las condiciones y || permite que cualquiera de los lados satisfaga una condición. La entrada y salida son pequeñas y se pueden calcular en papel.

Descarga el laboratorio de aprendizaje con filtros. El código y los cuatro registros se construyeron para esta lección; no proceden de una respuesta de IA ni del código de una aplicación real. Descomprímelo y abre filter-learning-lab. Necesitas Node.js 22 o posterior, un editor de texto y un terminal. No hay dependencias que instalar, llamadas a modelos ni solicitudes de red.

Escribe tres predicciones antes de ejecutar

Lee catalog.mjs y filter.mjs. El catálogo contiene estos registros:

ID Etiqueta Categoría Existencias
folded-stars Folded stars paper 1
paper-kites Paper kites paper 3
clay-moons Clay moons clay 0
clay-bells Clay bells clay 2

La regla original incluye un elemento si tiene al menos una unidad. La búsqueda usa la etiqueta, ignora mayúsculas y recorta espacios alrededor de la consulta. Deben coincidir categoría, búsqueda y disponibilidad. La categoría all acepta cualquiera; una búsqueda vacía coincide con cualquier etiqueta.

Abre blank-note.md y escribe los identificadores esperados para estas entradas. Consulta la función cuando lo necesites, pero espera antes de ejecutar el observador o pedir la respuesta.

Caso Categoría Búsqueda availableOnly Qué explicar
A paper vacía true Por qué una unidad aún cumple la regla
B all CLAY false Por qué puede aparecer el elemento sin existencias
C clay bells true Cómo se combinan las tres condiciones

Después ejecuta estos comandos desde la carpeta descomprimida:

node observe.mjs
node --test baseline.test.mjs
Compara tus predicciones con los resultados originales
Caso Identificadores originales Motivo
A folded-stars, paper-kites Ambos son de papel y tienen al menos una unidad.
B clay-moons, clay-bells La búsqueda recortada y sin distinción de mayúsculas coincide con ambos. El filtro de disponibilidad está desactivado.
C clay-bells Coincide en categoría y etiqueta, y tiene 2 unidades.

Si tu predicción difiere, señala la primera condición que interpretaste mal. En B, «el elemento tiene existencias» sería incorrecto: clay-moons tiene cero. Permanece porque availableOnly es false y esa condición no lo excluye.

Explica la regla sin copiar una respuesta

Cierra la nota completa si la abriste. Escribe dos o tres frases que expliquen B a alguien que vea el catálogo. Incluye la entrada real y la condición que permite cero existencias.

Separa los pocos archivos y sus funciones:

Archivo Función en este ejercicio
catalog.mjs Proporciona los cuatro registros.
filter.mjs Decide qué registros cumplen las condiciones.
observe.mjs Proporciona tres conjuntos de condiciones e imprime identificadores y existencias seleccionados.
baseline.test.mjs Comprueba el comportamiento original del filtro.

El observador es un llamador de terminal, no una captura del navegador. En tu aplicación, un botón o formulario puede proporcionar valores similares; lee ese código antes de suponer qué envía la interfaz.

Puedes usar el lector de código local de Yenpo para mantener abiertos datos, filtro y llamador mientras lees. La búsqueda de archivos y texto no necesita conectar un modelo. Si usas AI Reader con tu proveedor, pregunta por la condición concreta que no entiendes, vuelve al código cercano y escribe tu propia explicación. Ejecuta los comandos en Terminal; el ejercicio no necesita una respuesta del modelo.

Cambia una regla a mano

Cambia ahora el requisito: con el filtro de disponibilidad activo, muestra solo materiales suficientes para dos personas, una unidad por persona. Conserva el filtro de categoría, la normalización de búsqueda y el comportamiento con la disponibilidad desactivada.

La regla original de «al menos una» era correcta para el requisito original. Es una pequeña modificación de funcionalidad, no una corrección de un fallo oculto.

Antes de editar, escribe otra predicción. A debe perder folded-stars. B debe seguir incluyendo el registro sin existencias porque el interruptor está desactivado. C debe conservar clay-bells, con exactamente 2 unidades.

Ejecuta una vez las comprobaciones del nuevo requisito contra el código original:

node --test exercise/pair-policy.check.mjs

Se espera que falle antes de editar: la función descargada aún acepta una unidad. Lee la aserción fallida para saber qué comportamiento solicitado falta. Un error de sintaxis o un archivo ausente serían fallos distintos.

En filter.mjs, cambia solo el umbral de >= 1 a >= 2. Conserva la condición availableOnly que lo rodea. Después ejecuta:

node observe.mjs
node --test exercise/pair-policy.check.mjs
Caso Identificadores tras editar Qué comprueba
A paper-kites Una unidad ya no satisface la regla para dos personas.
B clay-moons, clay-bells Desactivar disponibilidad sigue omitiendo la regla de existencias; la búsqueda sigue recortando e ignorando mayúsculas.
C clay-bells Exactamente dos unidades cumplen; cambiar a > 2 sería incorrecto.

La suite original describe la regla de una unidad. Sus aserciones afectadas fallarán tras este cambio intencional. Usa las comprobaciones separadas para dos personas; no borres una aserción solo para ocultar un fallo. El archivo conserva el código original para repetir desde el principio.

Explica otra vez el cambio, incluido lo que sigue igual

Aparta el ejemplo completo y termina tu nota con tus palabras. Debe identificar:

  • Los umbrales original y nuevo y el lugar exacto editado.
  • Por qué A pierde un elemento y B permanece igual.
  • Por qué exactamente 2 unidades deben seguir cumpliendo en C.
  • Los comandos ejecutados y lo que mostraron sus salidas.
  • Lo que no comprobaste, como entradas de formularios reales, comportamiento del servidor o persistencia.

Una explicación final útil es concreta: «Con disponibilidad activada, todos los filtros deben coincidir y ahora hacen falta al menos dos unidades. Desactivada, las existencias no afectan a la selección. El nuevo umbral elimina folded-stars de A; B y C conservan los mismos identificadores». Cierra la página e intenta explicarlo a partir del código, sin memorizar estas palabras.

Ahora prueba otra entrada. Predice el resultado antes de ejecutarla y explica qué condiciones conservaron o eliminaron cada elemento.

Aplica el mismo ciclo a una función de tu proyecto

Elige un comportamiento pequeño con entradas visibles y una salida reproducible. Anota la versión, haz una copia o usa tu flujo habitual de control de versiones y limita la primera edición. Escribe la predicción antes de ejecutar. Si el resultado difiere, lee la condición y el código que llama antes de pedir otro parche generado.

Si aún no localizas el comportamiento, empieza buscando una entrada en código desconocido. Si necesitas decidir si una explicación de IA es cierta, usa el ejercicio de comprobación de explicaciones. Si revisas un cambio propuesto, el recorrido de la caché de promesas analiza un parche concreto y su caso de fallo.