Buenas y malas practicas

Buenas y malas prácticas

Una lista práctica para revisar tu forma de trabajar. La regla general: tú diriges, la IA ejecuta —y todo deja rastro.

Malas prácticas (evítalas)

• Vibe coding. Prompts vagos y aceptar lo que salga sin entenderlo. Genera deuda y código frágil.
• Pegar sin leer. Si no entiendes lo que la IA escribió, no lo subas.
• Repetir el proyecto en cada sesión. Volver a explicar el contexto una y otra vez quema tokens y dinero. Usa documentación viva y memoria.
• Dar todo el repositorio como contexto. Más tokens, peor atención (context rot). Carga lo justo.
• Sesiones eternas sin compactar. El contexto se degrada; resume y guarda el estado fuera.
• No fijar versiones. Dejar que la IA “adivine” APIs lleva a errores. Verifica con context7.
• Saltarte la seguridad “para que funcione”. Validación, auth y escape no se negocian.
• Secretos en el chat o en prompts. Quedan registrados. Nunca.
• Aceptar cambios sin revisar el diff. El propose-and-review solo funciona si revisas.

Buenas prácticas (adóptalas)

• Método según el tamaño. Cambio relevante → SDD (explore → … → archive). Cambio pequeño → directo + actualizar la documentación viva.
• Deja que la IA configure el proyecto (/aiws-configure) en vez de partir de cero.
• Ingeniería de contexto. Carga bajo demanda, datos al vuelo (context7), memoria sobre recuerdo.
• Intención antes que código. Una spec con escenarios verificables (Dado/Cuando/Entonces).
• Verifica con evidencia. Build y tests reales, no “parece que funciona”.
• Respeta el safety gate. Ante upgrades, migraciones o acciones irreversibles: parar, proponer, esperar tu decisión.
• El efecto ratchet. Añade una regla al harness solo tras un fallo real; no acumules texto.
• Commits limpios y revisables. Convencionales, un cambio lógico por commit.

En una frase

El objetivo no es escribir código más rápido, sino mantener el control mientras la IA hace el trabajo pesado —gastando los tokens justos y dejando un rastro que tú (y tu equipo) podáis entender mañana.