Saltar al contenido
Lección 7 de 12

Refinamiento Iterativo — Entrega Rapido, Mejora Mas Rapido

8 min read

V1 en Minutos, No Dias

El enfoque tradicional para la calidad de software es construir algo perfecto la primera vez. Los desarrolladores pasan dias planificando, escribiendo, refactorizando y puliendo antes de que algo se entregue. El enfoque 5.7x invierte esto: obtén una version funcional en minutos, luego itera rapidamente hacia la calidad que necesitas.

Esto no se trata de entregar codigo roto. Se trata de reconocer que una V1 funcional te da algo concreto para evaluar y mejorar, mientras que un diseno perfecto teorico no te da nada. Codigo real que puedes probar supera al codigo imaginario que aun estas planificando.

El ciclo de iteracion se ve asi:

V1 (minutos): Implementacion funcional, funcionalidad basica
V2 (minutos): Refinada basada en tu revision, casos extremos manejados
V3 (minutos): Pulida, optimizada, lista para produccion

Tiempo total: 20-40 minutos para lo que solia tomar un dia

Cada version se construye sobre la anterior. Cada iteracion esta informada por ver realmente el codigo funcionar, no por adivinar lo que podria necesitarse.

El Ciclo de Revision

El mecanismo central del refinamiento iterativo es el ciclo de revision: la IA genera codigo, tu lo revisas, la IA refina basada en tu retroalimentacion. Este ciclo es rapido porque:

  1. La IA genera rapidamente. Un componente o funcionalidad completa en segundos, no horas.
  2. Tu revisas a velocidad de lectura. Revisar codigo es 5-10x mas rapido que escribirlo.
  3. La IA refina con precision. Cambios dirigidos basados en retroalimentacion especifica, no reescrituras.

Aqui esta el ciclo en la practica:

# Paso 1: La IA genera V1
claude "Crea un componente DataTable con ordenamiento, filtrado
       y paginacion. Usa los estilos de tabla existentes."

# Paso 2: Tu revisas
# - Ordenamiento funciona pero solo para strings, necesita soporte numerico
# - Filtro es sensible a mayusculas, deberia ser insensible
# - Paginacion se ve bien
# - Falta estado de carga

# Paso 3: Describes los refinamientos
claude "Tres refinamientos al DataTable:
       1. Soportar ordenamiento numerico (detectar tipo de columna automaticamente)
       2. Hacer el filtrado insensible a mayusculas
       3. Agregar estado de carga skeleton con el mismo layout de columnas"

# Paso 4: La IA refina (V2)
# Revisas de nuevo — mucho mas cerca de calidad de produccion

# Paso 5: Pulido final
claude "Ultima pasada: agrega aria-labels para accesibilidad, memoiza la
       funcion de ordenamiento para rendimiento, y agrega un estado
       vacio de 'sin resultados'"

# V3 esta lista para produccion

Tres iteraciones, quiza 15 minutos en total. El proceso manual equivalente implicaria escribir el componente desde cero, descubrir los mismos problemas durante pruebas y pasar una hora o mas corrigiendolos.

Usando Diffs para Entender Cambios

Cada vez que la IA hace cambios, revisa el diff -- no solo el codigo final. Los diffs te muestran exactamente que cambio y te ayudan a detectar modificaciones no deseadas:

# Ver que cambio en la ultima accion de IA
git diff

# Ver cambios en un archivo especifico
git diff src/components/DataTable.tsx

# Ver un resumen de que archivos cambiaron
git diff --stat

Al revisar diffs, observa:

  • Cambios inesperados de archivos: La IA modifico archivos que no pediste?
  • Adiciones de imports: Las nuevas dependencias son razonables y necesarias?
  • Codigo eliminado: Se borro algo que debio conservarse?
  • Consistencia de patrones: Los cambios siguen los patrones existentes de tu proyecto?

La revision de diffs es la puerta de calidad en el flujo de trabajo 5.7x. Reemplaza el proceso manual de escribir codigo cuidadosamente. En lugar de ser cuidadoso durante la escritura, eres exhaustivo durante la revision.

Checkpoints como Redes de Seguridad

Los checkpoints te permiten experimentar con audacia porque siempre puedes revertir. Antes de iniciar un cambio riesgoso o una iteracion importante, crea un checkpoint:

# Crear un checkpoint antes de un cambio importante
git add -A && git commit -m "checkpoint: antes de refactorizacion del sistema de notificaciones"

# Ahora puedes experimentar libremente
claude "Reescribe completamente el sistema de notificaciones para usar
       WebSockets en lugar de polling. Cambia todo lo que necesite cambiar."

# Si el resultado es bueno, continua
# Si no, revierte instantaneamente
git checkout .

Los checkpoints cambian tu relacion con el riesgo. Sin ellos, cada cambio se siente de alto riesgo porque deshacerlo es doloroso. Con ellos, puedes intentar refactorizaciones agresivas, enfoques experimentales y simplificaciones radicales sabiendo que la red de seguridad esta a un comando de distancia.

Estrategia de checkpoints para una sesion tipica de funcionalidad:

Checkpoint 1: Antes de empezar la funcionalidad
  -> Implementar V1
Checkpoint 2: Despues de que V1 funciona
  -> Iterar a V2 (refinamientos)
Checkpoint 3: Despues de que V2 es solida
  -> Pulir a V3 (lista para produccion)
Commit final: V3 completa

Tres redes de seguridad a lo largo de la sesion. Sobrecarga total: unos 30 segundos para los comandos git. Valor: la confianza para moverse rapido sin miedo a romper cosas.

El Umbral de "Suficientemente Bueno"

Una de las habilidades mas dificiles en el desarrollo iterativo es saber cuando parar. La perfeccion es enemiga de la productividad. Aqui hay un marco practico:

Entrega en V2 si:

  • La funcionalidad trabaja correctamente para todos los casos de uso principales
  • Los casos extremos estan manejados (aunque no elegantemente)
  • El codigo sigue las convenciones de tu proyecto
  • Los tests pasan y cubren las rutas criticas

Itera a V3 si:

  • La funcionalidad es de cara al usuario y la estetica importa
  • El rendimiento esta por debajo de umbrales aceptables
  • Los requisitos de accesibilidad no se cumplen
  • El codigo sera la base para funcionalidades futuras

Deja de iterar cuando:

  • Estas haciendo cambios que no afectan la experiencia del usuario
  • Las mejoras son preferencias estilisticas, no mejoras funcionales
  • Has pasado mas tiempo refinando que lo que tomo la generacion inicial
  • La siguiente iteracion requeriria mas contexto que el beneficio que justifica

El desarrollador 5.7x entrega en V2 para herramientas internas e itera a V3 para funcionalidades de cara al usuario. Nunca itera a V4 a menos que haya un problema especifico y medible.

Evitando la Sobre-Ingenieria

La IA es capaz de generar soluciones sofisticadas y sobre-ingenierizadas. Cuando pides "un sistema robusto de manejo de errores," podria construir una jerarquia elaborada de errores con clases de excepcion personalizadas, error boundaries, logica de reintento y circuit breakers -- cuando todo lo que necesitabas era un try-catch con un mensaje amigable para el usuario.

Protegete contra la sobre-ingenieria:

Siendo especifico sobre el alcance:

# Prompt sobre-ingenierizado
claude "Construye un sistema robusto y escalable de manejo de errores"

# Prompt del tamano correcto
claude "Agrega try-catch a la ruta de API. Registra errores en consola.
       Devuelve {error: message, status: code} al cliente.
       Eso es todo lo que necesitamos ahora."

Aceptando el primer intento de la IA cuando funciona: Si la primera version maneja tus casos de uso y pasa los tests, resiste el impulso de "mejorarla." El instinto de refactorizar es fuerte en desarrolladores experimentados, pero en el flujo de trabajo 5.7x, el refinamiento innecesario es desperdicio.

Preguntando "necesitamos esto?": Al revisar el output de la IA, cuestiona cada abstraccion, cada funcion utilitaria, cada capa extra. Si no puedes senalar un caso de uso concreto que lo requiera, eliminalo.

Ejemplo Real: Construyendo y Refinando un Componente

Aqui hay una secuencia de iteracion completa para un componente real:

# V1: Obtener algo funcionando
claude "Crea un componente SearchBar con input con debounce que
       filtre una lista de items. Usa el prop items para los datos."

# Revisar V1:
# + Busqueda basica funciona
# + Debounce esta implementado
# - Sin indicador de carga durante la busqueda
# - Limpia resultados cuando el input esta vacio (deberia mostrar todos)
# - Falta navegacion por teclado

# V2: Refinamientos dirigidos
claude "Refina SearchBar:
       1. Muestra un spinner sutil durante la espera del debounce
       2. Muestra todos los items cuando el input de busqueda esta vacio
       3. Agrega navegacion por teclado: flechas para moverse por
          resultados, Enter para seleccionar, Escape para limpiar"

# Revisar V2:
# + Los tres problemas corregidos
# + Navegacion por teclado funciona bien
# - El spinner es demasiado prominente, deberia ser mas sutil
# - Podria usar resaltado de coincidencias en resultados

# V3: Pulido final
claude "Pulido final en SearchBar:
       1. Haz el spinner mas pequeno, usa un pulso sutil de opacidad
          en lugar de un icono spinner
       2. Resalta el texto coincidente en los resultados de busqueda
          con font-medium y un color de fondo sutil"

# V3 esta lista para entregar.
# Tiempo total: ~12 minutos
# Total de iteraciones: 3
# Equivalente manual: 45-60 minutos

El Efecto Compuesto

Las iteraciones individuales son mejoras pequenas. Pero se acumulan. En el transcurso de una funcionalidad, podrias hacer 4-5 iteraciones, cada una tomando 3-5 minutos. El resultado es una funcionalidad que ha sido revisada y refinada 4-5 veces -- mas ciclos de revision que la mayoria del codigo escrito manualmente recibe en una semana de discusiones de pull requests.

Esta es la idea contraintuitiva del metodo 5.7x: el codigo generado por IA que pasa por iteracion rapida a menudo termina con mayor calidad que el codigo escrito manualmente, porque el revisor humano esta enfocado completamente en evaluacion y mejora en lugar de dividir la atencion entre escribir y revisar simultaneamente.

El ciclo de iteracion -- generar, revisar, refinar -- es el motor que convierte la velocidad de la IA en calidad de produccion. Dominalo, y entregas mas rapido mientras mantienes los estandares que tus usuarios y equipo esperan.