En este artículo
Un stack de desarrollo con agentes de IA en 2026, a prueba con un fallo de frontend
Una clienta selecciona Open en la lista de pedidos. Aparecen dos pedidos abiertos. El equipo hace una captura y da por resuelta la incidencia. Basta con que la clienta avance una página para encontrarse con dos pedidos cerrados. ¿En qué momento del desarrollo se tendría que haber detectado el fallo?
Ofri Wolfus, creador de ChunkHound, explica en su guía de ingeniería cómo utiliza cuatro herramientas. Pi dirige la sesión de programación, ChunkHound investiga el código, pi-schematic reparte el trabajo y agent-browser inspecciona la interfaz en ejecución. Wolfus lo ilustra con un juego multijugador. Trasladamos ese reparto a una decisión habitual en mantenimiento: ¿qué tiene que comprobar el equipo antes de integrar un arreglo en una aplicación existente? Trayectoria de Wolfus · Ejercicio original con las cuatro herramientas
Comprobado el 14 de noviembre de 2026. Instalamos los cuatro paquetes, cargamos la extensión de Pi, indexamos el ejemplo con ChunkHound y probamos la pantalla de pedidos en Chromium. Usamos Playwright para manejar el navegador porque el entorno bloqueaba el socket local que necesita agent-browser. Los pasos en los que un modelo investigaría o editaría el código forman parte del procedimiento propuesto. La prueba se hizo sin llamadas de pago a modelos.
¿Qué aporta cada herramienta al desarrollo con agentes?
Pi abre una sesión de trabajo para el modelo. ChunkHound localiza las partes del repositorio que permiten explicar un comportamiento. Dentro de Pi, pi-schematic separa las tareas de investigación, implementación y revisión. agent-browser permite recorrer la interfaz ya renderizada. Para quien supervisa el cambio, importa qué entrega cada paso al siguiente.
| Componente | Función en la incidencia | Qué conservar | Licencia del código |
|---|---|---|---|
| Pi 1.5.2 | Ejecutar la sesión con el modelo elegido, las herramientas del repositorio y sus instrucciones. | Un diff acotado y los comandos usados para comprobarlo. | MIT |
| ChunkHound 6.1.0 | Encontrar dónde se lee el filtro y dónde se construyen las URL de navegación. | Archivo, símbolo y líneas que respaldan cada afirmación. | MIT |
| pi-schematic 0.7.1 | Dar a cada agente una tarea delimitada de investigación, edición o revisión. | Una nota breve con los requisitos acordados y las comprobaciones pendientes. | MIT |
| agent-browser 0.43.0 | Reproducir en un navegador la secuencia de la clienta. | URL, identificadores y estados de los pedidos, también después de recargar. | Apache-2.0 |
El código de los cuatro proyectos es libre y gratuito. Las llamadas a una API de modelos, un servicio de embeddings, un navegador alojado o una GPU pueden generar gastos. La búsqueda por expresión regular y la prueba local de navegador de este artículo se pueden ejecutar sin una cuenta de modelos. Licencia de Pi · Repositorio y licencia de ChunkHound · Licencia de pi-schematic · Repositorio y licencia de agent-browser
¿Cómo se conectan Pi, pi-schematic y ChunkHound?
Instala la CLI de Pi, añade la extensión pi-schematic y registra ChunkHound como servidor del protocolo de contexto de modelos (MCP) para el proyecto. Pi ya incorpora MCP para descubrir y llamar a las herramientas del repositorio. Puedes ejecutar agent-browser por separado desde la terminal. Entorno de Pi y soporte nativo de MCP
Estos comandos fijan las versiones que examinamos. Usamos Node 24 y Python 3.12. Instala el navegador en la máquina que vaya a manejar la interfaz y comprueba que el PATH del proceso de Pi incluya los ejecutables que deba lanzar. Instalación de la CLI de Pi y autenticación · Instalación de agent-browser
npm install -g --ignore-scripts @earendil-works/[email protected]
pi install npm:@chunkhound/[email protected]
uv tool install chunkhound==6.1.0
npm install -g [email protected]
agent-browser install
# Ejecuta estos dos comandos en el repositorio que usará Pi.
pi mcp add -l chunkhound -- chunkhound mcp --no-daemon
pi mcp listLa opción -l guarda la definición del servidor en .pi/mcp.json dentro del proyecto. Revisa ese archivo antes de marcar el proyecto como de confianza en Pi. Aunque figure en la configuración, el servidor puede no arrancar si Pi no encuentra el ejecutable o aún no confía en el proyecto. Comprueba qué herramientas detecta y lanza una búsqueda cuyo resultado conozcas. Alcance, confianza y comandos MCP de Pi
Nuestro entorno restringía el socket local del proceso compartido. Usamos --no-daemon de ChunkHound para atender a un solo cliente. En el proyecto de prueba, marcado como de confianza, Pi mostró el servidor como conectado y expuso search y daemon_status. Después, un cliente MCP independiente buscó PAGE_SIZE por expresión regular y obtuvo su definición en el ejemplo. Así verificamos el transporte y la consulta sin pedirle a un modelo que eligiera una herramienta. CLI de ChunkHound y modo de cliente único
También cargamos pi-schematic en un proceso RPC nuevo de Pi, sin conexión. Pi enumeró los comandos de la extensión model-groups, notebook, handoff y readonly. Esa prueba confirma que estas versiones se cargan juntas. Para evaluar la calidad del parche que redactaría un modelo concreto hay que darle una tarea y revisar el resultado.
¿Cómo se rastrea una regresión con ChunkHound?
Formula una pregunta que puedas resolver leyendo el código. Para este fallo hay dos extremos que localizar: ¿qué función incorpora el estado seleccionado a la URL de la página siguiente y qué hace el servidor si falta ese parámetro? Una respuesta verificable señala las líneas de ambos extremos y explica dónde cambia el comportamiento.
Descarga el ejemplo local del filtro de pedidos en un directorio vacío. Contiene seis pedidos ficticios, dos por página. Los dos modos usan los mismos registros. Desde ese directorio puedes crear un índice y consultarlo sin un servicio de embeddings. Elegimos el nombre next_status para que la búsqueda sea fácil de reproducir. Indexación, expresiones regulares, búsqueda semántica e investigación en ChunkHound
chunkhound index --no-embeddings .
chunkhound search --regex 'next_status'ChunkHound indexó un archivo en 20 fragmentos, sin generar embeddings. La consulta devolvió tres coincidencias que se solapaban. En el modo defectuoso, una línea asigna a next_status el valor «todos los pedidos». La siguiente construye el enlace con page_url. Al recibir una consulta sin status, el servidor devuelve por defecto todos los pedidos. Las tres coincidencias apuntan al mismo fallo.
Si ya conoces el símbolo, basta con una búsqueda de texto. En una aplicación mayor, el enlace, el análisis de la ruta, el filtro de la API y las pruebas pueden estar en paquetes diferentes. Ahí probaría la búsqueda semántica o pediría a ChunkHound que siguiera el recorrido y citara cada paso. Abre las líneas en la revisión de Git que vas a aprobar. Tras editarlas, actualiza el índice o comprueba que ya refleja los cambios.
Guardar el índice en el equipo y elegir dónde se ejecuta el modelo son dos decisiones independientes. Las expresiones regulares funcionan sin proveedor de modelos. La búsqueda semántica necesita embeddings. La investigación en profundidad añade un modelo y una configuración compatible para reordenar los resultados. Si eliges proveedores remotos, averigua qué código, fragmentos y consultas recibe cada uno. Cuando un repositorio deba permanecer en la máquina, prueba los servicios seleccionados y registra el destino de las peticiones. Configuración del índice y los proveedores de ChunkHound
¿Cómo conviene repartir un cambio entre Pi y pi-schematic?
Asigna una pregunta a quien investiga, un cambio pequeño a quien programa y un resultado observable a quien revisa. Con spawn, pi-schematic abre una conversación limpia para un agente hijo. Con handoff, pasa las decisiones a una fase nueva. El agente hijo hereda el directorio de trabajo y conserva acceso a los mismos archivos. Funciones, grupos de modelos, cuaderno y directorio compartido en pi-schematic
| Responsable | Encargo | Condición para avanzar |
|---|---|---|
| Investigación | Sigue el estado seleccionado desde la primera página hasta la construcción del enlace y el procesamiento de la petición. Cita las líneas correspondientes. | Se puede señalar exactamente dónde se pierde el filtro y qué valor se aplica por defecto. |
| Implementación | Conserva el estado seleccionado al construir el enlace siguiente. Respeta la ruta existente y el comportamiento sin resultados. | Un diff pequeño con una sola persona o agente a cargo de los archivos afectados. |
| Revisión | Usa los datos iniciales para predecir la segunda página antes de abrirla. Comprueba URL, filas, recarga, vuelta atrás y resultado vacío. | Los valores esperados y observados quedan registrados. Una captura correcta de la primera página aún deja abierta la incidencia. |
Escribe los identificadores esperados y el alcance en la incidencia o en una prueba de regresión versionada. El cuaderno de la extensión sirve para conservar decisiones al pasar de una fase a otra. Está vinculado al flujo en curso y se vacía al iniciar otro. En el siguiente lanzamiento, el equipo podrá recuperar la decisión en Git, en la prueba y en la incidencia. Si varios agentes deben editar a la vez, asígnales worktrees distintos o separa sus cambios de otro modo. Cómo gestiona un harness las herramientas, el estado y la verificación.
¿Cómo se comprueba en el navegador que el arreglo resiste el siguiente clic?
Anota el resultado previsto antes de navegar. Al seleccionar Open, deben aparecer primero ORD-101 y ORD-102. Al avanzar, deben salir ORD-105 y ORD-106, los dos abiertos. La URL debe incluir el estado y el número de página para que una recarga pueda reconstruir el mismo resultado.
Arranca el servidor de ejemplo en modo defectuoso. En otra terminal, ejecuta los siguientes comandos en una máquina que permita iniciar el proceso local de agent-browser. Los controles se buscan por su nombre accesible en inglés, tal como aparecen en el ejemplo. Así seguirá funcionando la secuencia aunque cambien los identificadores de la captura de accesibilidad. Navegación, localizadores e inspección con agent-browser
# Terminal 1
python3 order_filter_lab.py --mode broken --port 8765
# Terminal 2
agent-browser open http://127.0.0.1:8765/orders
agent-browser snapshot -i
agent-browser find role link click --name "Open" --exact
agent-browser find role link click --name "Next page" --exact
agent-browser get url
agent-browser snapshot
agent-browser reload
agent-browser snapshot
agent-browser back
agent-browser snapshot
agent-browser find role link click --name "Cancelled" --exact
agent-browser snapshot
agent-browser closeUna captura interactiva (-i) sirve para localizar controles. La completa también recoge el contenido de la tabla. Si haces clic con referencias como @e3, vuelve a obtener la captura después de navegar y usa la referencia nueva. Añade una imagen cuando debas comprobar la alineación o si algún elemento queda cortado. En este fallo cuentan los identificadores de las filas, su estado y la URL. Tipos de captura y referencias a elementos
| Paso | Modo defectuoso | Modo corregido |
|---|---|---|
| Seleccionar Open | ORD-101 y ORD-102, ambos Open. | La primera página es idéntica. |
| Pulsar Next page | /orders?page=2. ORD-103 y ORD-104, ambos Closed. | /orders?status=open&page=2. ORD-105 y ORD-106, ambos Open. |
| Recargar la segunda página | La URL sin filtro vuelve a mostrar los dos pedidos cerrados. | La URL con filtro vuelve a mostrar los dos pedidos abiertos. |
| Volver atrás | Primera página de Open, con ORD-101 y ORD-102. | Se recuperan la URL y las filas anteriores al avance. |
| Seleccionar Cancelled | Cero filas y el mensaje «No matching orders.» | El mismo estado vacío, con el estado Cancelled reflejado en la URL. |
Detén el servidor con Ctrl-C y vuelve a arrancarlo con --mode fixed para repetir el recorrido. Las dos versiones superan la comprobación superficial de la primera página. Al comparar los identificadores y la ruta se ve por qué fallan el avance y la recarga. La vuelta atrás y la lista vacía permiten comprobar que el arreglo respeta esos comportamientos.
Para repetir la prueba, descarga el test de regresión en Playwright junto al servidor. El test exige el mismo comportamiento a las dos versiones. Quien revise el parche podrá rechazar la defectuosa con independencia de la sesión exploratoria. En el modo defectuoso, el test terminó con el código 1 al avanzar. En el corregido, superó las cinco comprobaciones y devolvió 0.
python3 -m pip install playwright
python3 -m playwright install chromium
python3 test_order_filter.py http://127.0.0.1:8765/ordersPara los demás aspectos de una puesta en producción, consulta la lista de comprobaciones de QA antes del lanzamiento.
¿Cuándo merece la pena adoptar las cuatro herramientas?
Empieza por el problema que ya has observado. Si el equipo localiza enseguida la función responsable, generar embeddings aporta poco a un cambio de seis líneas. Si en cambio la revisión aprueba funciones que se rompen al siguiente clic, empieza con una comprobación repetible en el navegador. Es poco frecuente que un proyecto necesite las cuatro herramientas desde el primer día.
- Si cuesta localizar el código, compara cuánto tarda una persona con la búsqueda habitual y con ChunkHound en incidencias equivalentes. Registra el tiempo hasta encontrar el archivo correcto y cuántas referencias respaldan el diagnóstico.
- Si las tareas se desvían de su alcance, prueba un procedimiento guardado en pi-schematic con un responsable de edición y otro de revisión. Cuenta investigaciones repetidas, cambios en conflicto y hallazgos reproducibles. Abrir tres sesiones de pago para un cambio sencillo puede aumentar el gasto sin mejorar el resultado.
- Si se cuelan fallos de interfaz, reproduce cada fallo en el navegador, conserva el valor esperado por separado y verifica el resultado después del parche. Incorpora una prueba de regresión determinista a la integración continua si el equipo debe proteger ese comportamiento en cada versión.
En un piloto, cuenta como arreglos aceptados únicamente los que cumplen los criterios acordados. Supongamos que ocho arreglos aceptados consumen 12 € en llamadas a modelos y tres horas de revisión a 80 € por hora. Son 252 € en total, o 31,50 € por arreglo aceptado, antes de infraestructura. Incluye en el coste el tiempo de los intentos rechazados. Contrasta la cifra con el procedimiento habitual del equipo en incidencias comparables. La guía de compra de un stack de programación con varios modelos trata la elección de proveedores y el reparto de tareas entre modelos.
El caso de Twinsoft AI describe el trabajo de entrega al pasar de prototipo a piloto. El servicio de ingeniería de harness de Wavect integra las herramientas del repositorio, los procedimientos de los agentes y los controles previos a producción. Define un piloto a partir de una incidencia real.