Un ingeniero de producto describe un flujo de trabajo para construir software con ayuda de IA en el que se invierte el orden tradicional de planificación. Frente al esquema clásico de escribir un RFC, dividirlo en issues y desarrollar cada bloque secuencialmente, propone construir primero la solución completa en una sola rama y descomponerla después en PRs pequeños y revisables.
El artículo identifica qué se abarató con los asistentes de IA y qué no. La generación de código, la iteración sobre un plan y, sobre todo, la división de una rama acabada en una secuencia de PRs pequeños —antes la parte más tediosa— ya no son cuellos de botella. En cambio, siguen siendo costosas la parte sustantiva de la revisión de código (corrección sutil, ubicación de un cambio, efectos a seis meses) y la validación de producto: decidir si lo construido es lo que hay que construir.
El flujo que describe es: interrogar el plan hasta tener decisiones reales, comprometer la especificación antes del código cuando el diseño es nuevo, construir de forma amplia en una sola rama con commits como puntos de guardado, demostrar el resultado a futuros usuarios antes de cualquier code review, y solo entonces cortar la rama en PRs estrechos. Un prompt específico le pide a la IA que divida el trabajo en el conjunto mínimo de PRs revisables de forma independiente, apilándolos solo cuando hay una dependencia real, y dejando la limpieza del código antiguo para un PR final de pura eliminación.
El autor aplica reglas derivadas de la práctica: apilar ramas solo ante dependencias reales y enviar la limpieza en último lugar. Termina con un balance: los PRs que llevan el riesgo arquitectónico real siguen siendo grandes, los que los consumen se leen en minutos, y revisar el trabajo propio PR a PR es lo que distingue haber enviado código escrito por IA de entenderlo.