18. Mejora del proyecto mediante nuevas instrucciones

18.1 Introducción

La primera versión de la lista de tareas permitió recorrer el ciclo completo del Vibe Coding: describimos una idea, generamos archivos, revisamos el código y ejecutamos pruebas manuales.

La revisión y las pruebas confirmaron dos problemas: el contador utiliza plural cuando queda una sola tarea y la entrada inválida se rechaza sin explicación. También registramos una limitación conocida: las tareas desaparecen al recargar.

Ahora convertiremos esos hallazgos en nuevas instrucciones. No pediremos “mejorá toda la aplicación”, porque una solicitud abierta mezclaría decisiones y dificultaría comprobar qué produjo cada modificación.

18.2 Construir una lista priorizada

Antes de volver a conversar con la IA, ordenamos los hallazgos según su naturaleza e impacto.

La prioridad no depende de cuán interesante sea una función. Primero corregimos comportamientos confirmados y luego agregamos valor nuevo.

18.3 Anatomía de una instrucción de mejora

Una instrucción para modificar código existente debería incluir:

• Estado actual: qué archivos y comportamiento existen.
• Evidencia: qué caso produjo un resultado incorrecto.
• Resultado esperado: cómo debe comportarse después.
• Alcance: qué puede cambiar y qué debe conservarse.
• Restricciones: tecnologías, dependencias y convenciones.
• Verificación: qué casos deben ejecutarse.

Una solicitud precisa permite revisar la respuesta contra una intención explícita. También ayuda a detectar cuando la IA agrega refactorizaciones o funciones no pedidas.

18.4 Primera instrucción: corregir defectos confirmados

La instrucción combina dos correcciones pequeñas relacionadas con mensajes de interfaz. Define textos exactos y comportamientos que pueden probarse.

No solicita persistencia todavía. Separar esa mejora evita atribuir un posible error de almacenamiento a la corrección del contador.

18.5 Cambio propuesto en index.html

La IA puede asociar el campo con una región de error mediante aria-describedby:

<input
  id="texto-tarea"
  name="tarea"
  type="text"
  placeholder="Ejemplo: estudiar JavaScript"
  autocomplete="off"
  aria-describedby="mensaje-error"
>

<p id="mensaje-error" class="mensaje-error" aria-live="polite" hidden>
  Escribí una tarea antes de agregarla
</p>

El atributo hidden evita mostrar el mensaje en el estado inicial. aria-live="polite" permite anunciar el cambio sin interrumpir de forma brusca.

Durante la revisión confirmamos que el identificador sea único y que aria-describedby apunte exactamente al elemento agregado.

18.6 Cambios propuestos en styles.css y app.js

Agregamos una presentación sencilla para el mensaje:

.mensaje-error {
  margin: 8px 0 0;
  color: #b91c1c;
  font-weight: 700;
}

En JavaScript seleccionamos la región y centralizamos su estado:

const mensajeError = document.querySelector("#mensaje-error");

function mostrarError(mensaje) {
  mensajeError.textContent = mensaje;
  mensajeError.hidden = false;
  campoTexto.setAttribute("aria-invalid", "true");
}

function ocultarError() {
  mensajeError.hidden = true;
  campoTexto.removeAttribute("aria-invalid");
}

La función del contador queda vinculada con la cantidad:

function actualizarContador() {
  const pendientes = tareas.filter(tarea => !tarea.completada).length;
  contador.textContent = pendientes === 1
    ? "1 tarea pendiente"
    : `${pendientes} tareas pendientes`;
}

18.7 Integrar la validación en el envío

Modificamos solamente la parte del evento relacionada con la validación:

const texto = campoTexto.value.trim();

if (!texto) {
  mostrarError("Escribí una tarea antes de agregarla");
  campoTexto.focus();
  return;
}

ocultarError();

tareas.push({
  id: proximoId,
  texto,
  completada: false
});

La posición de ocultarError() es importante: se ejecuta después de confirmar que la nueva entrada es válida y antes de continuar con el alta.

No eliminamos trim(), el foco ni la validación anterior. La mejora agrega comunicación sin debilitar el control existente.

18.8 Verificar la primera iteración

Repetimos pruebas relacionadas y también casos que ya funcionaban.

Solo después de aprobar esta iteración avanzamos hacia persistencia.

18.9 Segunda instrucción: conservar las tareas

La nueva función requiere varias decisiones. Para este proyecto elegimos localStorage, almacenamiento disponible en el navegador para pares de clave y texto.

La instrucción define cuándo guardar, qué hacer ante datos dañados y cómo continuar la secuencia de identificadores. Sin esas condiciones, la IA tendría que decidirlas.

18.10 Diseñar el almacenamiento

localStorage conserva texto. Para almacenar el arreglo utilizamos JSON:

El almacenamiento es local al navegador y al origen de la página. No sincroniza dispositivos, no reemplaza una base de datos y puede ser eliminado por la persona.

18.11 Funciones para cargar y guardar

Una propuesta posible concentra el acceso al almacenamiento:

const CLAVE_TAREAS = "lista-tareas";

function cargarTareas() {
  try {
    const datos = localStorage.getItem(CLAVE_TAREAS);

    if (!datos) {
      return [];
    }

    const resultado = JSON.parse(datos);
    return Array.isArray(resultado) ? resultado : [];
  } catch (error) {
    console.warn("No se pudieron recuperar las tareas", error);
    return [];
  }
}

function guardarTareas() {
  localStorage.setItem(CLAVE_TAREAS, JSON.stringify(tareas));
}

El bloque try...catch evita que un JSON inválido impida iniciar la aplicación. La validación todavía es básica: confirma la colección, pero no cada propiedad interna. Para el alcance didáctico la registramos como una limitación conocida.

18.12 Inicializar y guardar después de cada cambio

Reemplazamos el estado inicial vacío:

let tareas = cargarTareas();
let proximoId = tareas.reduce(
  (mayor, tarea) => Math.max(mayor, Number(tarea.id) || 0),
  0
) + 1;

Después de cada modificación del arreglo o de una propiedad agregamos guardarTareas() antes de volver a representar:

casilla.addEventListener("change", () => {
  tarea.completada = casilla.checked;
  guardarTareas();
  renderizarTareas();
});

botonEliminar.addEventListener("click", () => {
  tareas = tareas.filter(item => item.id !== tarea.id);
  guardarTareas();
  renderizarTareas();
});

El alta requiere la misma llamada después de tareas.push(...). Si olvidamos uno de los caminos, la interfaz parecerá correcta hasta recargar.

18.13 Tercera instrucción: estado vacío

Una vez estable la persistencia, agregamos una mejora visual pequeña:

En HTML incorporamos:

<p id="estado-vacio" class="estado-vacio">
  Todavía no hay tareas
</p>

Y actualizamos su visibilidad durante el renderizado:

const estadoVacio = document.querySelector("#estado-vacio");

function renderizarTareas() {
  lista.replaceChildren();

  tareas.forEach(tarea => {
    lista.append(crearElementoTarea(tarea));
  });

  estadoVacio.hidden = tareas.length > 0;
  actualizarContador();
}

18.14 Pruebas de regresión de la versión mejorada

Las funciones nuevas amplían el conjunto de casos. También repetimos los anteriores.

Si una prueba falla, detenemos la incorporación de nuevas funciones. Primero reducimos el problema, corregimos y repetimos el grupo relacionado.

18.15 Lecciones del ciclo completo

El proyecto muestra que el Vibe Coding es un proceso iterativo y no una única generación:

1. Definimos una necesidad pequeña.
2. Escribimos criterios antes de pedir código.
3. Generamos una primera versión limitada.
4. Relacionamos requisitos con implementación.
5. Revisamos estructura, lógica, accesibilidad y seguridad.
6. Ejecutamos casos manuales y registramos evidencia.
7. Priorizamos defectos y mejoras por separado.
8. Formulamos instrucciones específicas.
9. Revisamos diferencias y repetimos pruebas.

La IA aceleró la producción y propuso implementaciones. La calidad surgió de combinar esa capacidad con decisiones humanas, límites, lectura y verificación.

18.16 Actividad final

Aplicá un ciclo completo de mejora sobre la versión de tu proyecto.

1. Elegí un defecto confirmado en tus pruebas y una mejora fuera del alcance inicial.
2. Priorizá el defecto y escribí su resultado esperado.
3. Redactá una instrucción que incluya contexto, alcance, restricciones y verificación.
4. Revisá todos los cambios propuestos antes de ejecutarlos.
5. Probá la corrección y repetí los casos relacionados.
6. Guardá esa versión antes de solicitar la mejora funcional.
7. Repetí generación, revisión y prueba para la segunda iteración.
8. Prepará un informe final con funciones, limitaciones conocidas y posibles pasos futuros.

Para cerrar, explicá con tus palabras qué decisiones tomó la IA, cuáles tomaste vos y qué evidencia permite afirmar que la versión mejorada cumple su objetivo.