27 hallazgos de una revisión de consultoría, resueltos
La relación del estudio con el cliente
La consultora es una parte independiente que evaluó el lienzo de planificación de Changemkr, una plataforma de la que Torn Studio posee una parte y en la que tuvo el rol de producto. El estudio recibió su material e hizo el trabajo posterior.
Sobre el nombre
La consultora no ha aceptado ser nombrada, así que la página la describe y deja fuera el nombre de la empresa. La descripción es cierta y basta para situar de dónde vino el material.
Respuesta breve
Una consultora nórdica probó un lienzo de planificación con IA y lo calificó de poco fiable. Torn Studio convirtió el informe en 27 tickets rastreables, halló las causas raíz antes de la primera línea de código, corrigió y verificó contra una pila viva. En la verificación del 25 de junio de 2026 había 22 resueltos, 3 parciales y 2 aplazados.
El encargo
Un consultor de la firma había probado el lienzo de planificación y su asistente de IA en uso real y había resumido el resultado en una presentación. El encargo era convertir ese relato en algo que se pudiera trabajar, y poder mostrar qué se corrigió de verdad.
Lo que lo hizo difícil
- El material era el relato de una sesión en el orden en que las cosas fallaron, con 27 quejas que podían ser menos fallos o más — cuál de las dos cosas era, no se leía en la lista.
- El hallazgo más grave era que el asistente escribía haber hecho cambios que nunca ocurrieron, lo que deja inservible el resto de la herramienta por muchos fallos de maquetación que se arreglen.
- Varios tickets dependían de salidas del modelo que varían entre ejecuciones, así que no podían verificarse con una prueba corriente que espera la misma salida cada vez.
Cifras que se pueden contar
- 27tickets de un solo documento de prueba
- TP-01 a TP-27 en el plan de corrección del repositorio, cada uno con la formulación propia del probador y una causa raíz asociada.
- 22 / 3 / 2resueltos, parciales, aplazados
- Contable en la tabla de estado del plan de corrección, fechada el 25 de junio de 2026. Dos filas cubren varios tickets cada una, por eso 24 filas llevan 27 tickets.
- 11 / 1pruebas pasadas y omitidas
- El informe de verificación del repositorio nombra los siete archivos de especificación que se ejecutaron contra la pila y el comando que los vuelve a ejecutar.
- 4tickets que eran decisiones de producto
- Apartados de la lista y resueltos como decisiones en el plan, con la elección y su consecuencia escritas. No tienen corrección de código alguna.
Cómo se hizo
El relato se volvió tickets rastreables
Las quejas de la presentación se tradujeron a 27 tickets numerados, TP-01 a TP-27. Cada uno lleva la formulación que usó el probador, de modo que cualquiera puede volver y leer lo que esa persona vio realmente. Esa parte decide si una ronda de pruebas lleva a alguna parte.
Análisis antes de la primera línea de código
Una pasada completa transcurrió con el código intacto. Cada ticket se asoció a una causa raíz confirmada o supuesta, los que compartían causa se agruparon, y cuatro que resultaron ser decisiones de producto se apartaron y se resolvieron como decisiones. Agrupar primero es lo que permite que una corrección cierre varios síntomas.
Primero el ticket más peligroso
La afirmación de cambios ejecutados se abordó antes que nada, porque un usuario engañado una vez deja de fiarse de la siguiente respuesta. El prompt prohíbe ahora esa formulación, y la interfaz muestra la propuesta como no aplicada hasta que una persona pulsa el botón.
Verificación contra una pila viva
Las correcciones se ejecutaron contra toda la pila en contenedores, con Playwright manejando a la vez la aplicación web, la API de negocio y el servicio de IA. Once pruebas pasaron y una se omitió, la última por un gesto que ningún navegador sin pantalla puede ejecutar. El informe dice cuál y por qué.
Tecnología
- Next.js
- React Flow
- FastAPI
- LangGraph
- Playwright
- Podman
- PostgreSQL
Hasta dónde llega esta prueba
Esto muestra que un material de prueba disperso puede convertirse en un plan que se sigue fila a fila. No muestra nada sobre el éxito del producto: dos tickets se aplazaron con motivo, tres están parcialmente resueltos con el caso límite en pie, y los tres grandes recorridos de creación nunca se ejecutaron de principio a fin porque dependen de salidas del modelo que varían.
Evidencia
En qué se apoya este artículo — una medición nuestra, una fuente fechada o una decisión y lo que costó.
- Medición
Cuántos de los 27 tickets estaban resueltos en la verificación
Objeto medido: La tabla de estado del plan de corrección del planificador con IA
Método: Contar las marcas de estado de la tabla y desglosar las filas que cubren varios tickets.
Resultado: 22 resueltos, 3 parciales, 2 aplazados
- Decisión
Hacer una pasada de análisis sobre toda la lista antes de tocar código, agrupando los tickets por causa raíz.
Lo que costó: La pasada costó tiempo antes de que algo pareciera corregido, lo que es difícil de defender ante un cliente que espera arreglos.
- Decisión
Hacer que el asistente presente las propuestas como no aplicadas hasta que una persona pulse el botón.
Lo que costó: Cada cambio exige ahora un clic más, y el objeto debe estar seleccionado primero, lo que hace el flujo más lento que dejar al modelo escribir de una vez.
Preguntas frecuentes
- ¿Por qué no se nombra a la consultora?
- La empresa no ha aceptado ser nombrada, y entonces el nombre no aparece aquí. La descripción — una consultora nórdica de transformación digital — es cierta y basta para que entiendas de dónde vino el material. El día que una empresa acepte, el nombre estará ahí.
- ¿Por qué se analizó sin tocar el código?
- Porque 27 síntomas rara vez son 27 fallos. Agrupar por causa raíz muestra dónde una misma causa produce varios síntomas, de modo que una corrección cierra varias filas. La pasada también apartó cuatro tickets que resultaron ser decisiones de producto, y esos no tienen corrección de código alguna.
- ¿Cuál fue el hallazgo más grave?
- Que el asistente escribía haber hecho cambios que nunca ocurrieron. Un fallo de maquetación se ve y se puede sortear, mientras que un acuse falso hace que el usuario deje de fiarse de toda la herramienta. Ese ticket se abordó primero, y la solución es una regla en el prompt y una marca visible en la interfaz.
- ¿Qué significa parcialmente resuelto en el informe?
- Que el caso que el probador comunicó funciona, mientras queda en pie un caso límite contiguo. El informe describe ese límite en la fila. La marca existe porque una ronda comunicada como completamente verde deja sin valor la siguiente: quien lee el informe debe ver dónde está la frontera.
- ¿Cuánto duró la ronda?
- Recepción, análisis, corrección y verificación cupieron en junio de 2026, con el informe de verificación fechado el día 25. Es el ritmo que sostiene una persona con herramientas de IA sobre un material acotado donde los tickets ya están descritos por alguien que usó el producto.
Cuéntanos qué quieres construir
Treinta minutos, sin coste, y una respuesta directa sobre si somos el estudio adecuado.
Respuesta en menos de un día, una propuesta escrita con precio cerrado en tres días, y decides con calma.
Garantía de satisfacción