La IA escribe más rápido pero tu equipo no entrega más rápido

Dese hace algunos meses decidí escribir todos mis pitches con IA (y pido a mi equipo que haga lo mismo). Si los estudios tienen razón, deberíamos documentar cerca de 40% más rápido.

Sinceramente, no es lo que veo. Mis documentos son mejores, pero no los termino antes. Busqué datos para entender por qué y la primera pista no apareció en la documentación de producto, sino en el código.

Más código no es más software

En octubre de 2024, Google informó que más del 25% de su código nuevo lo escribía una IA. En abril de 2026, la cifra llegó al 75%.

Cada vez menos código se escribe a mano. Eso ya no se discute. La pregunta importante es otra: ¿Ese código llega más rápido a producción?

Los estudios coinciden en que programar con IA es más rápido, pero no en cuánto:

• GitHub: Los desarrolladores con Copilot terminaron una tarea controlada 55,8% más rápido.
• Google: En una tarea empresarial compleja, 96 de sus ingenieros fueron cerca de 21% más rápidos.
• Microsoft y otras empresas: En un experimento de campo, Copilot aumentó en 26% las tareas completadas.

Los investigadores de Harvard Fiona Chen y James Stratton fueron más allá del laboratorio. Analizaron datos de más de 700 empresas y encontraron que, con agentes de IA, se produce 30% más código, 20% más commits y 23% más pull requests.

Sin embargo, las tareas terminadas (lo que realmente pasa a producción) no cambiaron de forma significativa.

El motivo es la revisión. El tiempo para aprobar cambios de código subió 49%. Los pull requests que necesitan correcciones se duplicaron y cada uno recibe más comentarios.

Escribir más código no significa crear más software.

Además, escribir y revisar código es solo una parte de construir un producto. Antes de la primera línea hay pitches, funcionales y mockups. Esa documentación también demanda tiempo, pero casi no hay datos sobre cómo la IA cambia esa etapa.

¿Acelera la IA a los product managers?

No hay muchos estudios para responder esta pregunta. Sin embargo, estos 3 sirven para tener una primera visión:

En resumen: Documentar con IA es cerca de 40% más rápido. Pero esa velocidad casi no mueve la entrega final (la salida al mercado mejoró solo un 5%), y la calidad depende de la experiencia de quien usa el harnés.

Mi percepción es distinta. Mi documentación está mejor escrita y mejor estructurada, y sé que mi experiencia pesa en el resultado. Pero no me siento más rápido.

Si creas documentación de producto, compara cuánto te tomó tu último pitch (PRD, historias de usuario, etc.) con uno que escribiste hace dos años. Estoy seguro que no es lo bastante más rápido como indican los estudios.

Encontré dos problemas que frenan mi velocidad (y ninguno es técnico):

Falta de políticas en el uso de IA en la documentación de producto

En mi equipo, todos usamos IA para escribir pitches y funcionales. Sin embargo, nadie definió cómo hacerlo cuando comenzamos.

Cada persona trabajaba con sus propios prompts, su propio criterio de revisión y su propia idea de cuándo un documento estaba terminado. El resultado eran documentos que salían totalmente distintos unos de otros.

Esto es porque la IA llena vacíos a su manera. Inventa, agrega relleno y se contradice. Y releer el documento no basta para detectarlo.

Esto tiene un costo alto. En producto, nuestro entregable es el documento. Si se contradice, deja casos sin resolver o no coincide con los mockups, el error llega al desarrollo. Ahí se paga en retrabajo, hotfixes y credibilidad.

Mi primer paso para encontrar una solución fue escribir una guía sobre cómo usar IA en la creación de pitches. Estos son sus pilares:

1. Una definición de "listo"

"Listo" significa listo para desarrollar, no listo para revisar. Cada tipo de entregable (pitch, funcional y mockup) tiene su lista de condiciones. Si falta un punto, no se entrega.

Algunas condiciones aplican a todos:

• Hay una sola versión vigente y todo el equipo sabe cuál es.
• Cada scope tiene nombre, explicación y su tabla de criterios de aceptación. La idea es que se pueda desarrollar y probar por sí solo.
• No tiene texto de relleno generado por IA.
• Los textos de pantalla viven en los mockups, no en el documento. Así el mockup se puede ajustar sin tocar el documento.

2. Reglas para trabajar con la IA

• Nunca de memoria: La IA escribe en base a la documentación que se le entregó, no con lo que recuerda de la conversación. Principalmente en conversaciones largas, olvida y mezcla cosas. Por eso, cada 10 minutos de trabajo se lo recordamos con un prompt fijo.
• Primero las decisiones, después el texto: Antes de escribir, se acuerda con la IA qué entra, qué no entra y cómo se resuelve cada caso. La IA trabaja en modo de planeación y hace todas sus preguntas antes de redactar.
• La IA no decide el formato: Si agrega una sección, una nota o un resumen que nadie pidió, se borra o se justifica.
• Un cambio a la vez: Se pide una corrección, se valida y recién ahí se pasa a la siguiente.

3. Contexto justo y en base a documentos oficiales

La IA recibe solo fuentes oficiales, como La plantilla del pitch correspondiente, el glosario de términos aprobados, los mockups (a través del MCP de Figma) y las transcripciones de las reuniones donde se tomaron decisiones.

También recibe una lista de decisiones vigentes que crece durante el trabajo. Esa lista manda sobre cualquier versión anterior del documento.

4. Prompts de arranque

Cada pitch tiene su prompt de inicio y todos fijan las mismas reglas: Trabajar solo con las fuentes oficiales, respetar el formato, separar las dudas del documento y no escribir nada hasta que se confirmen las decisiones.

El prompt no garantiza un buen documento. Garantiza que todos los documentos arranquen desde el mismo punto.

5. Una lista de calidad que se responde con sí o no

Cerré la guía con una checklist. Cada punto se puede comprobar y se responde con sí o no. Si uno queda en no, el documento no está listo.

Esto eliminó una discusión frecuente: "¿Este documento está bien?".

El loop infinito en QA

Tengo una técnica para escribir pitches con IA.

Genero el documento título por título. Cuando la IA me entrega uno, activo el micrófono y lo leo en voz alta. Mientras leo, doy feedback y, al cerrar el micrófono, le envío la transcripción y ajustamos. Solo paso al siguiente título cuando ya no queda feedback.

Con el documento completo, le pido una revisión (QA). Si encuentra errores; los corregimos. Entonces, le pido otra revisión. Y siempre vuelve a encontrar nuevos errores, así que los corregimos también. Y, después, otra revisión con más errores.

Ese loop nunca termina.

En mi experiencia, cada revisión es una lectura nueva del mismo texto. La IA no "recuerda" qué ya validó, así que siempre encuentra algo. Algunas veces es un problema real. Muchas otras, es una frase que podría estar mejor escrita o una decisión que ya tomamos y vuelve a cuestionar.

Es el mismo cuello de botella que encontraron Chen y Stratton en el código: Producir es rápido. Revisar es lo que frena.

Para ordenar ese ciclo, la revisión la encargo a tres agentes de QA por separado y sin ver el trabajo de los otros:

1. Coherencia: Busca contradicciones entre secciones y entre scopes. Revisa que se respeten las decisiones, el formato, la terminología, etc.
2. Lógica: Busca cabos sueltos, callejones sin salida y estados de los que no se puede salir. Revisa qué pasa cuando un servicio no responde, cuando algo vence y cuando la persona repite o abandona una acción.
3. Mockups: Revisa que cada pantalla, caso y error del documento exista en los mockups, y al revés. Y valida que todos los componentes estén conectados con el design system correspondiente.

Cada hallazgo debe citar el texto exacto y explicar por qué es un error. Cada corrección que implica una decisión entra a la lista de decisiones vigentes. Así, en la siguiente ronda, los agentes no vuelven a marcar lo que ya se resolvió.

Y una regla más: Si un hallazgo necesita una decisión de negocio o técnica, la IA pregunta. Nunca toma una decisión por su cuenta.

Pero ni con todo esto el loop se detiene solo. Necesita un criterio de cierre.

Identifica problemas de fondo; no de forma

La solución es clasificar cada hallazgo por su riesgo al producto. Para nosotros, estos son problemas de fondo (de alto riesgo):

• Contradicciones y casos sin salida: Reglas que chocan, casos borde nuevos, callejones donde la persona no puede actuar y tiempos que no cuadran.
• Proveedores, APIs y acuerdos: El funcional no coincide con las guías de proveedores, las APIs o los acuerdos documentados.
• Funcional contra mockups: Contradicciones entre ambos.
• Mockups entre sí: Contradicciones, pantallas sin salida o notas inentendibles.
• Mockups en lo visual: Márgenes inconsistentes, elementos encimados o componentes que no salen del design system.

Todo lo demás (redacción, tildes, repeticiones) es de forma. Se corrige, pero no detiene la entrega.

Con esa división, el criterio de cierre queda claro: Cuando una ronda completa sale con cero errores de fondo y solo reporta correcciones menores, el loop termina.

Además, encontré que no esperar al final para revisar ahorra horas de trabajo posterior. Cuando la IA entrega cada título, le pido una revisión rápida con los tres agentes, así los errores de fondo aparecen antes y cuestan menos.

Conclusión

La IA no me hizo más rápido escribiendo pitches, ya que la velocidad se pierde en el mismo lugar que en el código: La revisión. Lo que sí logró es que escriba mejores documentos.

Por eso, antes de pedirle velocidad a la IA, conviene resolver dos cosas:

1. Escribe políticas para tu equipo: Qué contexto recibe la IA, qué prompts se usan, qué significa "listo" y cómo se comprueba.
2. Define cuándo termina el QA: Separa los problemas de fondo de los de forma, y detente cuando una ronda completa salga sin errores de fondo.

Sin esas dos reglas, cada persona del equipo produce más texto. No más producto.