Claude Code escribió el buscador en 3 días, pero al equipo de Jmix le costó 3 semanas aceptar el código

Los agentes escriben código rápido, pero una persona sigue teniendo que leerlo, entenderlo y asumirlo como propio. El equipo de la plataforma open source Jmix lo ha descrito a partir de su propia experiencia. Escribieron el nuevo buscador y el índice para el asistente de IA en tres días, junto con Claude Code. Para que en el equipo hubiera alguien dispuesto a responder por el resultado hicieron falta casi tres semanas.

Dos cronómetros en lugar de uno

Antes de responder, el propio asistente busca fragmentos de documentación en una base vectorial. El equipo añadió ahí fichas de clases a partir de Javadoc y dividió la documentación en ejemplos breves y completos. La calidad se comprueba con un circuito de evaluación: 74 preguntas de control cuyas respuestas puntúa un modelo juez.

La primera versión del código la escribió Claude Fable 5, y GPT-5.6 Sol revisó de forma independiente algunas partes. El resultado fue un diff de 122 archivos y casi 15 mil líneas. Los autores contaban de antemano con dos o tres días de revisión. Veían cada cambio y podían preguntarle al agente por cualquier decisión. Pero recorrer el diff y entenderlo lo bastante bien como para responder por él sin el agente resultaron ser cosas distintas.

El equipo lo describe como dos cronómetros. El primero corre hasta que existe código funcional, y se detuvo a los tres días. El segundo corre hasta que en el equipo aparece una persona capaz de arreglar el sistema de memoria.

Los autores llaman a ese momento «code adoption»; en esencia, es ownership. Las señales son estas: la persona sigue el recorrido de los datos desde la entrada hasta el resultado, explica los invariantes, predice qué afectará un cambio y modifica un contrato sabiendo qué habrá que volver a comprobar. Un build en verde no garantiza nada de esto, porque solo responde a las preguntas planteadas de antemano.

Por ejemplo: ¿alguien ha comprobado que, si hay un fallo a mitad de una reindexación, los fragmentos antiguos se conservan?

Adónde se fueron las tres semanas

La velocidad de lectura explica solo una parte. Según SmartBear y Cisco, conviene revisar en cada sesión 200–400 líneas en 60–90 minutos. De las 15 mil líneas, unas tres mil son fixtures HTML que no hace falta leer. Quedan unas 12 mil, es decir, 30 sesiones y 30–45 horas de lectura. Eso equivale a una semana laboral, y los tests se leen más rápido. Los autores reconocen que la estimación es aproximada y que el estudio tiene casi veinte años.

Tres cosas se llevaron el resto. Primero, el agente cambiaba código «de paso». Al tercer día de revisión, el código había perdido el soporte de varias versiones de Jmix.

El agente modificó el formato de respuesta de /api/search el primer día, así que hubo que restaurar el contrato antiguo, y el nuevo formato pasó a /api/v2/search. Además, hubo que retirar del repositorio capturas de pantalla, volcados de 3,5 MB y logs de Playwright. Durante casi una semana hubo una serie de commits «Restore …

as in main». Segundo, el agente explica con la misma seguridad cosas correctas e incorrectas, de modo que sus explicaciones había que contrastarlas con el código y confirmarlas con tests. Tercero, llegaron los cambios tardíos: el umbral de aprobación pasó a ser un campo independiente de la ejecución, se endurecieron las reglas del juez y se añadió al conjunto de referencia una forma abreviada de la consulta de DataManager.

Todo lo que el equipo ya había entendido sobre el significado de la puntuación hubo que volver a comprobarlo.

Según el historial de commits: 44 commits en los primeros tres días, luego 53 en la semana y media de análisis y otros 47 en los últimos nueve días.

El contexto de los datos del sector es este. Según DORA 2024, un aumento del 25% en el uso de IA se asocia con mejor documentación y revisiones más rápidas, pero el rendimiento de las entregas cayó aproximadamente un 1,5% y la estabilidad, un 7,2%. Es una correlación basada en una encuesta, no un experimento.

En DORA 2025, la relación con el rendimiento pasó a ser positiva y la relación con la estabilidad siguió siendo negativa. En el experimento de METR, los desarrolladores con experiencia que usaban IA tardaron un 19% más en las tareas, pero creían haber ido un 20% más rápido. Las herramientas eran de principios de 2025, y una nueva medición en febrero de 2026 resultó estadísticamente poco fiable.

Qué hace ahora el equipo

La idea principal es distinguir tres fronteras. La entrega determina qué llega completo a main. La iteración del agente lleva el trabajo a un estado estable que se puede levantar y comprobar. El punto de code adoption indica qué parte mantiene ya una persona por sí misma. Antes, el equipo las combinaba en una sola pull request grande, y el segundo cronómetro solo arrancaba cuando terminaba el primero.

Ahora el trabajo se divide en tres bloques: ciclo de vida del corpus, búsqueda con API y circuito de evaluación. Una persona revisa y acepta cada bloque antes de pasar al siguiente. Los bloques se encadenan en una pila de ramas, y a main llega una sola pull request final en la que solo se revisan las uniones. Por ejemplo, que tras una reindexación fallida la búsqueda siga devolviendo la generación anterior de datos.

Son seis prácticas: describir el contrato de todo el sistema antes de la primera sesión, dividir el trabajo en estados estables y dejar una nota entre sesiones, pedirle al agente una confirmación en lugar de un informe, encargar la revisión a otro agente con contexto limpio, incorporar a una persona después de cada bloque y cerrar con una aceptación integral completa. Ideas parecidas aparecen en los experimentos de Anthropic con tareas largas de agentes y en las recomendaciones de Claude Code para revisar el diff con un subagente.

Limitaciones

Los autores lo advierten con franqueza: esto todavía no es un reglamento, y no tienen mediciones comparables con las tres semanas de aquella rama. Queda abierta la pregunta de si ayudó el revisor independiente con ojos frescos o simplemente que fuera otro modelo. Además, un bloque aceptado tampoco queda congelado: el significado de la puntuación hubo que revisarlo el último día. La conclusión práctica para los equipos es sencilla: no cuenten solo el tiempo de generación del código, sino también el tiempo hasta que aparece alguien dispuesto a responder por él, e incluyan los puntos de aceptación en el plan antes de la primera sesión del agente.