Blog / Español
Tu modelo de IA para coding no es el sistema. El harness sí.
Tu equipo cambia de modelo. Las demostraciones son más rápidas. Los fallos siguen siendo extrañamente parecidos.
El agente continúa recibiendo el contexto equivocado. Sigue intentando utilizar una herramienta que no debería. Sigue declarando que ha terminado sin demostrar que el resultado funciona. Y, cuando comienza la siguiente tarea, las decisiones más importantes del producto han desaparecido dentro de la conversación de ayer.
El problema no siempre es el modelo.
El modelo escribe código. El harness decide si ese código pertenece a tu producto.
¿Qué es el harness de un agente?
El harness es la arquitectura que rodea al modelo. Decide:
- qué contexto entra en la tarea;
- qué herramientas puede utilizar el agente;
- qué puede hacer cada herramienta;
- qué memoria permanece entre sesiones;
- cómo se comprueba el resultado;
- cuándo puede volver a intentarlo;
- cuándo debe detenerse y recurrir a una persona.
El modelo puede ser el componente más visible. El harness define las condiciones de funcionamiento.
Esta diferencia es crucial porque dos equipos pueden utilizar el mismo modelo y obtener resultados radicalmente distintos.
El mismo modelo. Dos sistemas completamente distintos.
Entrega al primer agente un repositorio, un prompt enorme y permisos amplios. Permite que inspeccione, edite, instale dependencias y decida cuándo ha terminado la tarea.
Puede producir algo impresionante. También puede cambiar el alcance en silencio, repetir suposiciones, crear una dependencia que nadie ha aprobado o declarar que todo funciona porque la interfaz parece correcta.
Ahora coloca el mismo modelo dentro de un harness gobernado:
- el discovery y los requisitos son explícitos;
- los límites de arquitectura están disponibles como contexto;
- las herramientas exponen contratos restringidos;
- los permisos siguen el principio de mínimo privilegio;
- las decisiones importantes permanecen fuera del chat;
- la finalización depende de comprobaciones ejecutables;
- las preguntas abiertas impiden conclusiones infundadas.
El segundo agente no es necesariamente más inteligente. Está funcionando dentro de un sistema mejor.
Un prompt es una instrucción. Un harness es un modelo operativo.
Muchos equipos intentan resolver la fiabilidad escribiendo un prompt más grande. El prompt crece hasta acumular reglas del producto, notas de arquitectura, estándares de código, excepciones, recordatorios de seguridad y fragmentos copiados de sesiones anteriores.
Después, el equipo cambia de herramienta y vuelve a reconstruir el contexto.
Esto resulta caro de tres formas:
- Consumo de tokens: la IA de coding vuelve a consumir un contexto que debería recuperar con precisión.
- Deriva de decisiones: prompts ligeramente distintos generan interpretaciones distintas del mismo producto.
- Pérdida institucional: las definiciones críticas viven dentro de una herramienta de IA, en lugar de una fuente de verdad propiedad de la empresa.
Un harness útil no pide al modelo que memorice la empresa. Le proporciona el contexto gobernado adecuado para la tarea actual.
Las siete capas de control alrededor de un agente de coding
1. Selección de contexto
Más contexto no significa mejor contexto. El agente necesita los requisitos, decisiones, interfaces y restricciones relevantes para la tarea, sin arrastrar toda la empresa a cada prompt.
2. Contratos de herramientas
Cada herramienta necesita una entrada, una salida y un modo de fallo definidos. “Acceso a la base de datos” no es un contrato. “Leer este esquema aprobado en este entorno” sí lo es.
3. Límites de permisos
Leer código, editar localmente, abrir un pull request y acceder a producción son niveles de autoridad diferentes. El harness debe tratarlos de forma distinta.
4. Memoria duradera
La intención del producto no puede depender del historial del chat. Las decisiones de arquitectura, las especificaciones y las preguntas abiertas deben sobrevivir a los cambios de modelo, herramienta y equipo.
5. Verificación ejecutable
La explicación del agente no es una prueba. Los tests, las políticas, las reglas de arquitectura y otros sensores deben definir qué significa “terminado” antes de empezar el trabajo.
6. Reglas para reintentar y detenerse
Los reintentos ilimitados pueden convertir una suposición equivocada en decenas de cambios convincentes. El harness debe saber cuándo merece la pena intentarlo de nuevo y cuándo es necesario escalar la tarea.
7. Escalado humano
Hay incertidumbres que no desaparecen generando más texto. La falta de intención de negocio, los requisitos contradictorios y las excepciones de alto impacto exigen una decisión humana responsable.
Dónde encaja ArchGenerator.com
ArchGenerator.com no sustituye a la IA de coding que tu equipo ya utiliza.
Los desarrolladores pueden seguir trabajando con Claude Code, Cursor, Codex, Windsurf, Replit, Lovable o la próxima herramienta que se gane su confianza.
ArchGenerator.com proporciona la capa gobernada que no debería pertenecer a las herramientas de coding:
- discovery;
- especificaciones de producto y técnicas;
- definiciones y decisiones de arquitectura;
- trazabilidad entre intención, trabajo y evidencias;
- contexto empresarial reutilizable;
- gobernanza del software generado con IA.
Esta separación es esencial. La especificación y el coding son responsabilidades relacionadas, pero no son la misma responsabilidad.
Cuando la IA de coding no tiene que redescubrir el producto en cada sesión, el equipo reduce el contexto repetido, el consumo de tokens y el retrabajo. Cuando cambia la herramienta, las decisiones siguen perteneciendo a la empresa.
El modelo se vuelve intercambiable. La memoria del producto, no.
Una prueba del harness en 10 minutos
Antes de entregar otra tarea al agente, pregunta:
- ¿Podemos identificar el origen de cada requisito importante?
- ¿Recibe el agente únicamente el contexto necesario para esta tarea?
- ¿Son explícitos y verificables los límites de arquitectura?
- ¿Son los permisos de las herramientas más restringidos que las acciones posibles del agente?
- ¿Se define “terminado” mediante comprobaciones y no mediante la narrativa del agente?
- ¿Seguirán existiendo mañana las decisiones de hoy fuera de esta herramienta de IA?
- ¿Existe una condición clara para el escalado humano?
Si la mayoría de las respuestas es no, cambiar de modelo puede mejorar la demostración. No arreglará el sistema.
Mantén tu IA de coding. Dale una arquitectura a la altura.
La próxima ventaja competitiva no procederá de encontrar un único modelo perfecto. Los modelos seguirán mejorando, convergiendo y cambiando.
La ventaja procederá de construir un entorno gobernado en el que cualquier modelo competente pueda actuar con el contexto adecuado, una autoridad limitada y resultados verificables.
Mantén la IA que tus desarrolladores ya adoran. Añade el sistema que faltaba a su alrededor.