Un equipo le pregunta a Claude Code si su repo cubre de verdad un dolor real del usuario. La respuesta llega rápida, afilada y justa. Luego le preguntan lo mismo a Brújula y obtienen otra lectura, conectada al mapa de lo que el producto ya es. Las dos tienen razón en parte.
La pregunta interesante no es cuál IA “gana” ese intercambio. Es qué tipo de sistema necesita un equipo para seguir decidiendo bien, durante meses, no en un único chat.
Construir se ha abaratado. Decidir se ha encarecido.
Durante años, una parte grande del coste estaba en convertir una idea en código. Con agentes como Claude Code, Codex, Cursor o Kimi, construir es mucho más barato y rápido. Eso no hace menos importante el trabajo de producto. Lo hace más exigente.
Si cualquiera puede construir más rápido, la ventaja ya no está en producir features. Está en decidir mejor qué construir, con qué evidencia, bajo qué supuestos, y cómo aprender antes de acumular deuda de producto.
Construir barato trae una trampa dentro. Ahora puedes generar más pantallas, más épicas, más experimentos, más código. Y más deuda de producto. Si el equipo no mejora su sistema de decisión al mismo ritmo, toda esa velocidad solo acelera la dispersión.
Ese es el nuevo cuello de botella. No teclear. Decidir, y aprender.
El manual de siempre sigue valiendo. Ha subido el listón.
Esta no es la parte donde alguien anuncia que los clásicos están obsoletos. No lo están.
Valor, viabilidad, usabilidad y factibilidad siguen siendo el trabajo. El descubrimiento continuo sigue ganándole a discutir una única solución que parece inevitable. Una métrica compartida que capture el valor real al usuario sigue evitando que el equipo hable cuatro idiomas distintos. El linaje de Cagan, Teresa Torres y la gente de la North Star no lo ha sustituido la IA. La era IA sube el listón sobre todo ello, porque acelerar el código y el diseño no garantiza mejores outcomes. El trabajo difícil, encontrar soluciones valiosas y viables, necesita más juicio, no menos.
Lo nuevo es dónde tiene que vivir ese juicio. No en un documento estático que envejece al día siguiente de escribirse.
En la era de la IA, el PRD deja de ser el documento que precede al producto. Pasa a ser un sistema vivo que evalúa, recuerda y corrige las decisiones del producto.
Qué cambia de verdad
La forma del trabajo se mueve en seis frentes:
- de explorar una solución a explorar muchas rutas
- de un PRD a un prototipo evaluable
- de la opinión a los evals
- de la búsqueda documental a un grafo de relaciones
- de un roadmap estático a un decision ledger
- de “el PM escribe requisitos” a “el PM diseña el sistema que aprende”
Ninguno de estos quita al humano. Cambian de qué es responsable el humano. En un mundo de agentes, la persona de producto deja de ser quien escribe la spec y pasa a ser quien diseña el bucle de decisión.
Dónde entra Brújula
Brújula es la capa de razonamiento de producto dentro de PaellaDoc. Lee tu repo, tus artefactos, tus decisiones y tus conversaciones, y conecta cinco cosas:
- Mapa as-built: qué existe de verdad en el repo.
- Provenance: de dónde viene cada artefacto.
- Grafo semántico: cómo se relacionan capacidades, riesgos, decisiones y evidencia.
- Apuestas futuras: las direcciones candidatas que se derivan de todo ello.
- Evals de producto: cómo sabes si una recomendación ha sido buena.
Lo importante es lo que se niega a hacer. No te entrega una estrategia y la llama verdad.
Brújula no dice “esta es la estrategia”. Dice: esto es lo que se puede inferir, esto es lo que no se sabe, estas son las apuestas candidatas, y esta es la validación mínima antes de construir más.
El reverse intake muestra qué se ha construido, no por qué importa
Un reverse intake no es discovery. No habla con usuarios, no mide dolor y no reconstruye la intención original del equipo. Su valor es otro: muestra qué producto se ha construido de verdad. Ese mapa as-built, más provenance y relaciones, basta para detectar capacidades, huecos y deuda de decisión. A partir de ahí, el trabajo no es dictar una estrategia. Es formular apuestas candidatas y nombrar qué validar antes de construir más.
Lo que significa que no toda fuente permite el mismo tipo de afirmación. Esta es la parte que casi todos los grafos de producto hacen mal:
| Lo que quieres afirmar | Lo que necesita | Qué puede sostenerlo |
|---|---|---|
| “El usuario siente este dolor” | usuarios reales, uso, validación | evidencia externa, validation runs |
| “Lo decidimos a propósito” | docs y decisiones de humanos | fuentes naturales, escritas por personas |
| “Esta capacidad existe” | el producto construido | reverse intake |
| “Así está implementado” | el código | código en crudo |
La regla que mantiene a Brújula recta consigo misma: un nodo de reverse intake puede sostener esto existe. No puede sostener esto le importa al usuario. Un grafo bonito de nodos no es evidencia. La apuesta ordenada, puntuada por la evidencia que de verdad la respalda, sí.
Claude Code diagnostica. Brújula recuerda.
Esto no es una batalla de modelos, y Brújula no es “la más lista”. Claude Code directo es excelente en lo suyo: leer código en crudo con precisión, detectar dispersión y deuda, contestar una pregunta técnica o local afilada, sin capa intermedia. Para diagnóstico puntual, tíralo de ahí.
Su límite es la continuidad. El contexto se reconstruye en cada chat. No hay provenance estructurada, ni historial de decisiones reutilizable, ni grafo de artefactos persistente, ni comparación entre versiones, ni evals de producto repetibles. La respuesta es buena y luego se evapora.
Brújula es la infraestructura de la parte que tiene que persistir:
| Claude Code directo | Brújula |
|---|---|
pregunta → escaneo del repo → buena respuesta → contexto perdido |
pregunta → grafo + provenance + historial → respuesta → artefacto → eval → decision ledger → mejor respuesta siguiente |
La diferencia no es que Brújula piense mejor que Claude Code en una pregunta aislada. Es que Brújula convierte el razonamiento de producto en un sistema persistente, auditable y mejorable.
Los evals son el nuevo PRD vivo
En productos de IA, la calidad no se controla solo con tests deterministas. Hay que definir qué es una buena respuesta, qué fallos son inaceptables y qué evidencia puede sostener una recomendación. Por eso los evals empiezan a parecerse a PRDs vivos: no describen una feature una vez, evalúan continuamente si el producto se comporta como ha prometido.
Así que cada respuesta de Brújula que recomiende una dirección debería poder evaluarse a sí misma: si ha mantenido recta la provenance, si ha separado evidencia de hipótesis, si ha propuesto una validación siguiente concreta, si ha evitado certeza estratégica sin respaldo. Es la misma apuesta que el resto de lo que construyo, donde lo que hace fiable la salida es la spec, no la intuición del modelo. Lo he medido en el benchmark de verificación: en crudo, el modelo cuela errores; con el contrato escrito, no.
La ventaja que compone
La nueva ventaja de producto no es una IA que responde una vez. Es un sistema que recuerda, conecta, cuestiona y evalúa cada decisión de producto a lo largo del tiempo.
El futuro del product management no es humanos contra agentes. Es diseñar un sistema donde los agentes construyen, el grafo recuerda, los evals corrigen y las personas siguen siendo responsables del juicio. El PM no desaparece. Se convierte en el diseñador del bucle de decisión.
He escrito sobre mantener vivo el contrato de producto mientras los agentes hacen la escritura, en el runtime eres tú. Esta es la otra mitad: generar el contrato correcto desde el principio, y ser claro sobre qué puedes y qué no puedes afirmar todavía. Brújula es esa capa para PaellaDoc. No una IA que pretende tener la verdad. Un sistema que te ayuda a encontrarla más rápido.
Si construir ya es barato, ¿cuál es la decisión más lenta y más cara que tu equipo sigue rehaciendo desde cero? Cuéntame en el foro.