Cuando se habla de IA para programar, casi todo el mundo piensa en "que te escriba la función". A mí donde más me ayuda no es generando código, sino pensando y organizando antes de tocar nada. Esto es cómo la uso de verdad en mi trabajo.
1. Estructurar el problema antes de codear
Antes de escribir una línea, le explico el problema y le pido que me ayude a descomponerlo: qué piezas hay, qué orden tiene sentido, qué casos límite se me escapan. No para que decida por mí, sino para tener un primer mapa que luego yo critico y ajusto. Salgo con un plan, no con un folio en blanco.
2. Partir el trabajo en tareas reales
De una funcionalidad grande y difusa a una lista de tareas concretas y ordenadas. La IA es muy buena convirtiendo "hay que hacer el módulo de notificaciones" en pasos accionables. Eso me ahorra la parte más pesada de planificar sprints y backlog.
3. Sparring de arquitectura
Para decisiones de diseño la uso como alguien con quien discutir: le planteo dos enfoques y le pido trade-offs. No me creo la respuesta a ciegas —muchas veces está incompleta— pero me obliga a argumentar mi decisión, que es justo lo que quiero.
4. Documentación y revisión
Primeros borradores de documentación, READMEs, mensajes de commit con sentido, y una primera pasada de revisión que detecta despistes antes de pedir review a un compañero.
Lo que NO hago
- No me fío a ciegas. Verifico todo lo que toca código o datos; la IA se equivoca con seguridad aparente.
- No delego el criterio. La decisión y la responsabilidad son mías; la IA acelera, no decide.
- No genero código que no entienda. Si no sé explicarlo, no entra.
Conclusión
Para mí la IA es sobre todo una herramienta de orden y estructura: me ayuda a pensar mejor y más rápido, a no perder el hilo y a llegar al código con un plan claro. El valor no está en que escriba por ti, sino en que te ayude a pensar antes de escribir.