¿Importa que cada desarrollador use un copilot o un modelo distinto si el equipo comparte el mismo harness?
Los copilots y modelos de primer nivel ya rinden de forma parecida en código. Lo que marca la diferencia es el harness compartido: reglas, specs y sensores que hacen que cualquiera obtenga el mismo resultado.
La pregunta real
En muchos equipos cada desarrollador trabaja con lo que le resulta más cómodo: uno usa un copilot integrado en el IDE con el selector de modelo en auto, otro alterna entre modelos de distintos proveedores según la tarea y otro prefiere una CLI. La duda aparece cuando el equipo decide adoptar Spec-Driven Development: ¿hay que unificar la herramienta, o basta con compartir la metodología?
La respuesta corta: el copilot ya no es lo que decide el resultado, pero la dispersión sí es un riesgo si no hay un harness común que la neutralice.
El modelo ya no es el cuello de botella
Los modelos de primer nivel de los grandes proveedores están, en los benchmarks de programación, en un nivel muy parecido y muy alto. La diferencia real entre dos desarrolladores que usan IA ya no está en qué modelo eligen, sino en qué rodea al modelo: el harness. Conviene separar las capas para ver cuál está realmente bajo control del equipo:
| Capa | Qué aporta | Quién la controla |
|---|---|---|
| Modelo | La capacidad de razonamiento y generación | El proveedor |
| Copilot / interfaz | El bucle de ejecución, las tools y los permisos | El proveedor (con configuración) |
| Framework SDD | El flujo de trabajo: planificar, ejecutar, validar | La comunidad del framework |
| Harness del equipo | Contexto técnico, reglas, contratos, entornos y sensores propios | El equipo |
Las tres primeras capas son intercambiables. La cuarta es la única exclusiva del producto, y es la que hace que el resultado sea reproducible.
El código es efímero; el resultado tiene que ser el mismo
Una verdad incómoda para cualquier desarrollador: el código generado es efímero, y el "toque personal" que antes marcaba la diferencia pesa cada vez menos. El objetivo de un harness es que, ejecute quien ejecute la tarea, el resultado sea lo más parecido posible. Si la mitad del equipo trabaja con reglas en un sitio y la otra mitad con otras reglas en otro, el código acaba dependiendo de quién lo pidió, y eso es justo lo que la metodología intenta eliminar.
Cambiar de copilot, en la práctica, se reduce a mover los mismos ficheros Markdown de una carpeta de configuración a otra. Estándares como AGENTS.md van más allá y permiten que varios copilots lean el mismo fichero sin duplicarlo.
Implicaciones prácticas
Adoptar SDD no es una decisión individual: tiene que ser de equipo o, mejor, de empresa, de arriba abajo. Si solo una o dos personas aplican la metodología, el código seguirá sin ser fiable porque dependerá de quién lo haya generado. Lo razonable es acordar un copilot de referencia para simplificar el soporte interno, pero sobre todo acordar dónde vive la fuente de verdad: reglas, specs, contratos y sensores de validación.
Dejar el selector de modelo en auto tampoco es neutro: el comportamiento puede variar entre tareas sin que nadie lo decida. Cuanto más fuerte sea el harness, menos importa esa variación, pero conviene tenerla medida.
Resumen rápido
- Los modelos de primer nivel rinden de forma parecida en código: el diferenciador es el harness del equipo.
- Usar copilots distintos es tolerable; tener fuentes de verdad distintas no lo es.
- SDD es una decisión de equipo o de empresa: si solo la aplican algunos, el resultado vuelve a depender de la persona.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.