Claude escribe, Gemini revisa, ChatGPT hace de pato de goma

La IA de un solo proveedor se ve más fácil sobre el papel y produce fragilidad en la práctica. RakuAI está construido por un bucle de agentes multi-proveedor, y construido para que el modelo de cualquier proveedor pueda dirigirlo. El proceso de desarrollo refleja la tesis del producto.

Sábado por la mañana, café, y el flujo de trabajo antes de que vuelva a cambiar. Cuando le digo a la gente que estoy construyendo un motor junto a agentes de codificación autónomos, la primera pregunta es “cuál agente.” La respuesta honesta es “varios, en roles distintos, y las divisiones de trabajo importan.” Este post es la respuesta más larga.

En este momento el flujo de trabajo de desarrollo involucra al menos tres proveedores de IA distintos jugando partes distintas del bucle. La razón no es lealtad ni quisquillosidad. Es que cada modelo es genuinamente mejor en una forma de trabajo diferente, y tratar de hacer que un solo modelo lo haga todo produce código medible como peor.

Los roles, hoy

Claude escribe la mayor parte del código del runtime. Razonamiento de contexto largo a través de un código extenso, planificación antes de editar, mantener mucho estado en una sola cabeza. Este es el modelo que uso en la cola de issues para el trabajo sustantivo de subsistemas. Cuando un issue dice “implementa un gestor de capas de composición de OpenXR y espacios de acción,” Claude es el que completa el PR.

Gemini revisa la mayoría de los PRs. Entrenamiento diferente, puntos ciegos diferentes. Cuando Claude completa un PR, Gemini lee el diff y objeta. Los tipos de comentarios que Gemini saca a la luz son diferentes de los tipos que yo sacaría manualmente. Algunos son ruido. Algunos son útiles. La relación señal-ruido es lo bastante buena como para que confíe en Gemini como el primer pase de revisión en cada diff.

ChatGPT es donde hago de pato de goma. Cuando estoy atascado en una decisión arquitectónica y todavía no sé hacia dónde debería ir, pienso en voz alta con ChatGPT. El modelo no escribe código en este rol. Me presiona sobre suposiciones, sugiere tres planteamientos alternativos y me deja discutir con él. Es el rol que jugaría un compañero senior si tuviera uno. Actualmente no tengo uno. ChatGPT es la simulación.

Copilot está en el editor. Este es el rol de autocompletado. Cuando escribo código a mano (que es menos frecuente de lo que la gente piensa, pero pasa), Copilot es el modelo cuyas sugerencias veo en el IDE. Es bueno en el trabajo de contexto local, las próximas cuatro líneas.

Ese es el flujo de trabajo. Cuatro modelos, cuatro roles. Cada uno es mejor en su rol de lo que serían los demás.

Por qué importa lo multi-proveedor

Tres razones.

El techo de capacidad es diferente por proveedor. Si estuviera corriendo un solo modelo para cada rol, cada debilidad de ese modelo aparecería como una debilidad en el proceso de desarrollo. Claude es excelente escribiendo. Menos excelente encontrando errores en su propia escritura. Gemini es excelente encontrando errores pero no es el modelo al que dejaría planificar una refactorización sin supervisión. ChatGPT piensa bien sobre preguntas arquitectónicas abiertas pero su código en subsistemas reales no es lo que quiero lanzar. Cada uno es la mejor herramienta para un espacio.

La independencia en la revisión es estructural. La regla más importante a la que he llegado es que el modelo que escribe un PR no puede ser el modelo que lo revisa. La autorrevisión no es revisión. Hacer que el modelo de un proveedor diferente haga el primer pase de revisión produce independencia de arquitectura, de datos de entrenamiento, de modos de fallo. Los errores que Gemini detecta en el código de Claude son errores reales que de otro modo habrían llegado a producción.

Ningún bloqueo con un solo proveedor. El motor se está construyendo para recibir dirección de cualquier LLM en la nube (cubierto el mes pasado en el trabajo del XRAssistantService). El flujo de trabajo de desarrollo que construye el motor debería coincidir con esa postura. No quiero que la ingeniería de este runtime dependa de que un proveedor se mantenga competitivo durante los próximos cinco años. Ninguno de ellos lo hará. Los que son buenos ahora serán buenos de maneras diferentes después. Correr un flujo de trabajo multi-proveedor en la capa de desarrollo mantiene la ingeniería portable.

Los costos honestos

Unos cuantos.

La sobrecarga de coordinación es real. Cambiar de proveedor a mitad de tarea conlleva sobrecarga cognitiva. La solución es mantener cada tarea dentro del carril de un solo proveedor y dejar que el traspaso ocurra entre tareas, no dentro de ellas.

Las facturas se acumulan. Correr cuatro suscripciones de modelos no es gratis. El costo es significativo, y por ahora lo estoy pagando personalmente. El retorno es medible en subsistemas lanzados, así que las cuentas cuadran en esta etapa. No siempre será así.

La deriva de calidad entre proveedores es un problema real. Cuando Gemini mejora en un tipo de tarea que Claude ha estado haciendo, la respuesta correcta es mover esa tarea a Gemini. La respuesta incorrecta es seguir haciéndolo a la manera antigua porque la manera antigua es lo que dice el documento del flujo de trabajo. El documento del flujo de trabajo tiene que revisarse cada pocas semanas porque el panorama de modelos se mueve por debajo del flujo de trabajo.

Los proveedores no saben unos de otros. Cuando Claude escribe una pieza de código que va a ser revisada por Gemini, Claude no lo sabe. Cuando ChatGPT discute una decisión arquitectónica conmigo, la implementación eventual de Claude no ve esa discusión. La integración entre los proveedores está en mi cabeza. Ese es un lugar frágil para que viva la integración, y es una de las cosas que querría arreglar si estuviera construyendo infraestructura para ayudar a otros a correr este flujo de trabajo.

¿Qué hay del lado del runtime?

Esta es la parte donde la historia del flujo de trabajo de desarrollo y la historia del motor convergen.

El XRAssistantService que se completó hace dos semanas en el runtime es agnóstico al modelo por diseño. La razón es exactamente la misma razón por la que este flujo de trabajo de desarrollo es multi-proveedor. La interfaz está construida para que el modelo de cualquiera de estos laboratorios pueda dirigir una experiencia de RA a través del runtime. El laboratorio cuyo modelo es el mejor en una tarea determinada obtiene el derecho de proporcionar la intención de esa tarea en cualquier experiencia dada.

Esta es la apuesta más amplia: la era de “este producto está construido sobre este modelo de este proveedor” es breve. La era en la que estamos entrando es “este producto está construido alrededor de capacidades con forma de modelo, y qué modelo específico llena qué espacio de capacidad en un momento dado es una elección de configuración.” El motor tiene que estar listo para eso. El flujo de trabajo de desarrollo que construye el motor debería reflejarlo.

Lo que quiero que los constructores y laboratorios se lleven de esto

Si eres un proveedor de agentes de codificación y estás leyendo esto, la métrica que optimizaría es “con qué frecuencia el PR de este agente sobrevive a la revisión de un agente de un proveedor competidor.” La autoconsistencia no es la vara de medir. La supervivencia a la revisión entre proveedores es la vara de medir. Los agentes que rindan bien en esa métrica serán los que se usen para trabajo serio.

Si eres un desarrollador pensando en adoptar un flujo de trabajo asistido por IA para un código serio, no elijas un modelo y te detengas ahí. Elige uno para escribir. Elige uno diferente para revisar. Usa un tercero para hacer de pato de goma en las decisiones arquitectónicas abiertas. La prima de costo es real y la diferencia de calidad es mayor.

Si eres un líder empresarial pensando en la IA en tu organización de desarrollo, el patrón multi-proveedor es el que va a escalar. La adopción de un solo proveedor se ve más fácil sobre el papel. En la práctica produce fragilidad, tanto técnica como estratégica.

Sábado tranquilo. El motor tuvo un fin de semana de treinta y cinco commits. La mayoría de esos commits serán invisibles dentro de seis meses. El flujo de trabajo que los produjo no lo será.