Flujo de Trabajo Diario con IA¶
Proposito¶
Como integrar la IA en tu rutina diaria de ingenieria. No es teoria: es un flujo concreto que puedes seguir desde manana.
Cuando usarlo¶
- Como checklist diario.
- Para entrenar a nuevos miembros del equipo en el uso de IA.
1. Manana: Planificacion (30 min)¶
Sin IA¶
- Revisa tu backlog y elige la tarea del dia.
- Lee la spec de la feature (si no existe, escribela primero).
- Identifica las dependencias (APIs, servicios, datos).
Con IA¶
- Validacion de spec: Pega la spec a la IA y pregunta:
- "Hay ambiguedades en esta spec?"
- "Que edge cases faltan?"
-
"Las reglas de negocio son completas y consistentes?"
-
Planificacion tecnica: Pregunta a la IA:
- "Dado esta spec, que componentes necesito crear/modificar?"
- "En que orden deberia implementar?"
- "Que dependencias necesito resolver primero?"
Output esperado: Spec validada + plan de implementacion claro.
2. Desarrollo: Implementacion (core del dia)¶
Ciclo de desarrollo con IA¶
Por cada componente/feature:
1. ESPECIFICAR
- Preparar el contexto: spec + domain model + API contract
- Definir que quieres que la IA genere
2. GENERAR
- Enviar prompt con contexto a la IA
- Obtener codigo generado
3. REVISAR
- Leer TODO el codigo generado (no copiar sin leer)
- Verificar contra las reglas de negocio
- Identificar errores, simplificaciones, o mejoras
4. INTEGRAR
- Adaptar el codigo al proyecto (importaciones, convenciones)
- Correr los tests existentes
- Verificar que no rompe nada
5. TESTEAR
- Generar tests con IA (usando BDD scenarios como input)
- Agregar edge cases que la IA no cubrio
- Asegurar que los tests fallan cuando la logica es incorrecta
Repetir para el siguiente componente.
Cuando usar IA vs cuando NO¶
| Usar IA | NO usar IA |
|---|---|
| Boilerplate repetitivo | Decisiones arquitectonicas (tu decides, la IA informa) |
| Implementar logica de negocio desde spec | Debugging sin entender el problema |
| Generar tests desde BDD scenarios | Copiar codigo sin entenderlo |
| Escribir queries SQL complejas | Deploy a produccion |
| Refactorizar codigo existente | Code review final (un humano debe validar) |
| Generar documentacion desde codigo | Estimaciones de tiempo |
3. Tarde: Revision y Cierre (30 min)¶
Con IA¶
- Code review asistido: Pasa el diff del dia a la IA:
- "Revisa estos cambios enfocandote en seguridad y performance"
-
"Hay algun edge case que no estoy cubriendo?"
-
Documentacion: Si tomaste decisiones tecnicas:
- "Dado esta decision [X], ayudame a escribir un ADR"
- Actualiza el domain model si el dominio evoluciono
Sin IA¶
- Haz commit con mensaje descriptivo.
- Actualiza el estado de la tarea.
- Si hay algo que te trabo, documenta el bloqueo para manana.
4. Patrones de Uso Efectivo¶
Patron "Contexto Progresivo"¶
No pongas todo el contexto de una vez. Ve de lo general a lo especifico:
Sesion 1: "Estoy trabajando en un sistema de turnos medicos con NestJS"
Sesion 2: "Dentro de ese sistema, estoy implementando la cancelacion de turnos"
Sesion 3: "Especificamente, necesito la logica de penalizaciones"
Patron "IA como Pair Programmer"¶
En vez de pedir la solucion completa, trabaja iterativamente:
Tu: "Necesito calcular la disponibilidad. Empecemos por el algoritmo."
IA: [genera algoritmo]
Tu: "Ok, ahora agreguemos el filtro de dias bloqueados."
IA: [modifica]
Tu: "Hay un bug: no esta considerando la zona horaria de la clinica."
IA: [corrige]
Patron "Rubber Duck con Superpoderes"¶
Explica el problema a la IA como si le explicaras a un companero:
"Estoy tratando de resolver un problema de concurrencia. Cuando dos
pacientes intentan reservar el mismo slot al mismo tiempo, ambos pasan
la validacion de disponibilidad porque la leen antes de que el otro
haga el INSERT. Estoy pensando en usar SELECT FOR UPDATE. Tiene sentido?
Hay una mejor alternativa?"
5. Metricas de Productividad¶
Trackea estas metricas durante 2 semanas para ver si el flujo funciona:
| Metrica | Sin IA | Con IA (target) |
|---|---|---|
| Features completadas por semana | X | 1.5X - 2X |
| Bugs encontrados en code review | Y | < Y (menos bugs) |
| Tiempo en boilerplate | Z horas | < 0.5Z |
| Tiempo en debugging | W horas | Similar (la IA no elimina debugging) |
| Tiempo en documentacion | V horas | < 0.3V |
6. Errores Comunes al Empezar¶
- Confiar ciegamente en la IA. Siempre revisa. La IA no conoce tu sistema como tu.
- Usar IA para todo. Algunas cosas son mas rapidas de hacer a mano (ej: renombrar una variable).
- No dar suficiente contexto. Si la IA genera algo raro, probablemente le falta contexto.
- Saltarse las specs. La IA amplifica tu productividad, pero amplifica lo bueno Y lo malo. Si tu spec es mala, el codigo generado sera malo.
- No iterar. El primer output rara vez es perfecto. Refina con feedback especifico.
Checklist de Completitud¶
- Flujo matutino de planificacion documentado
- Ciclo de desarrollo con IA definido
- Cuando usar vs no usar IA
- Patrones de uso efectivo
- Metricas de productividad
- Errores comunes
- Revisada por otro ingeniero
Archivos relacionados¶
- prompt-engineering-guide.md - Como escribir prompts
- context-window-strategy.md - Gestionar contexto
- spec-to-code-workflow.md - De spec a codigo