Introducción
Hoy en día tenemos una amplia variedad de herramientas de inteligencia artificial que por supuesto nos ayudan a trabajar más rapido más eficientemente ahorrandonos un par de horas. Pero cuando hablamos de equipos que utilizan distintas herramientas, ya sea por preferencias personales, costos o necesidades especificas, comienza a aparecer un problema menos evidente.
El conocimiento del equipo comienza a divagar. Comandos, skills y contextos que funcionaban bien en una herramienta no siempre funcionan en otras, por lo que se convierte en un desafío, que muchas veces se paga con altos costos como por ejemplo: Consumo excesivo de tokens, entre otros.
Al final, poco a poco cada miembro del equipo va terminando de construir su propio entorno de trabajo, generando duplicación de esfuerzo y por su puesto mala experiencia con la inconsistencia dentro del mismo proyecto.
El problema oculto de trabajar con múltiples herramientas de IA
Cada herramienta crea sus propias reglas
Durante el auge de las herramientas de IA, muchos equipos adoptaron una solución principal para asistir en tareas de desarrollo. Pero a medida que aparecían nuevas funcionalidades, modelos más capaces y diferentes formas de trabajar, algunos miembros del equipo comenzaron a experimentar con otras alternativas.
Esto parecía algo genial. Después de todo, cada desarrollador podía elegir la herramienta con la que se sentía más productivo. Pero fue ahí donde apareció un problema que no se había considerado.
Estas herramientas proponen su propia forma de manejar o almacenar contextos, instrucciones o reglas para ayudar a los modelos a entender mejor el proyecto y ofrecer una mejor experiencia al desarrollador.
| Herramienta | Configuración |
|---|---|
| Cursor | .cursor/rules |
| Claude Code | .claude/CLAUDE.md |
| Codex | instrucciones propias |
| Otras herramientas | formatos diferentes |
Duplicación es costosa
Aqui comienza a aparecer un problema que inicialmente puede pasar desapercibido: la duplicación del conocimiento.
La misma información termina replicándose en múltiples lugares:
- Arquitectura del proyecto
- Convenciones de código
- Estándares de testing
- Flujos de Git
- Comandos reutilizables
- Conocimiento del negocio
Y mantener esta información sincronizada no solo requiere tiempo, sino que también aumenta el riesgo de inconsistencias. Un cambio realizado en un lugar puede quedar desactualizado en otro, generando comportamientos distintos entre herramientas y resultados menos predecibles para el equipo.
Solución: Fuente de la verdad
En base a mi experiencia, luego de encontrarme varias veces con escenarios de contextos duplicados, reglas inconsistentes y comandos que solo funcionaban en una herramienta específica, empecé a preguntarme si estaba resolviendo el problema incorrecto.
Al principio intentaba mantener sincronizadas las reglas y configuraciones de Cursor y Claude. Cada vez que agregaba una nueva regla o mejoraba un comando, debía replicar estos cambios en varios lugares. Esto era un proceso muy manual, repetitivo y propenso a errores.
La idea que terminó funcionando fue mucho más simple: dejar de considerar a las herramientas como el lugar donde vive el conocimiento.
En lugar de almacenar contexto, comandos y habilidades dentro de Cursor o Claude, decidí centralizar todo en un directorio dedicado dentro del repositorio:
# root project
ai/
La diferencia es importante:
| Antes | Después |
|---|---|
| El conocimiento vive dentro de cada herramienta. | El conocimiento vive en /ai. |
| Cursor tiene sus reglas. | Cursor consume reglas desde /ai. |
| Claude tiene su contexto. | Claude consume contexto desde /ai. |
| Los cambios deben copiarse entre herramientas. | Un cambio en /ai se refleja para todas. |
El objetivo no es que todo el equipo use la misma IA. El objetivo es que todas las IAs usen el mismo conocimiento.
Arquitectura propuesta
/ai
├─ context
│ ├─ architecture.md
│ ├─ frontend.md
│ └─ business-domain.md
├─ commands
│ ├─ review.md
│ ├─ refactor.md
│ └─ create-component.md
├─ skills
│ ├─ testing.md
│ ├─ performance.md
│ └─ accessibility.md
└─ agents
├─ frontend-agent.md
└─ reviewer-agent.md
¿Cómo se conecta cada herramienta?
Una vez que el conocimiento del proyecto se encuentra centralizado en el directorio /ai, las herramientas dejan de ser el lugar donde se define el contexto y pasan a ser simplemente consumidores de ese conocimiento.
Integración con Claude Code
En lugar de mantener un archivo CLAUDE.md grande y difícil de actualizar, podemos mantenerlo pequeño y enfocado únicamente en referenciar el contenido compartido.
.claude/
└── CLAUDE.md
Ejemplo:
@ai/context/architecture.md
@ai/context/frontend.md
@ai/commands/review.md
De esta forma, Claude Code consume el mismo conocimiento centralizado que utiliza el resto del equipo.
Integración con Cursor
La misma estrategia puede aplicarse en Cursor.
En lugar de duplicar reglas, instrucciones y documentación dentro de .cursor/rules, las reglas pueden mantenerse mínimas y delegar el conocimiento al directorio compartido.
.cursor/
└── rules/
Las reglas pueden referenciar información proveniente de:
/ai/context
/ai/commands
/ai/skills
Esto permite que Cursor trabaje con la misma arquitectura, convenciones, comandos y conocimiento de negocio que otras herramientas.
Aqui un pequeño diagrama de referencia:
┌──────────┐
│ Cursor │
└────┬─────┘
│
┌────▼─────┐
│ Claude │
└────┬─────┘
│
┌────▼─────┐
│ Codex │
└────┬─────┘
│
┌────▼─────┐
│ /ai │
│ Source │
│ of Truth │
└──────────┘
Beneficios
Cuando el conocimiento se encuentra centralizado, agregar una nueva herramienta deja de implicar migrar o reescribir contexto. Los beneficios son inmediatos:
- Menos duplicación de información.
- Menor costo de mantenimiento.
- Una única fuente de verdad.
- Contexto consistente entre herramientas.
- Comandos y habilidades reutilizables.
- Incorporación más sencilla de nuevas herramientas de IA.
Conclusión
La cantidad de herramientas de IA seguirá creciendo. Nuevos modelos aparecerán, algunas plataformas evolucionarán, otras desaparecerán y probablemente dentro de unos años estemos utilizando herramientas que hoy ni siquiera existen. Intentar estandarizar una herramienta específica es una estrategia complicada de mantener. Tarde o temprano surgirán nuevas necesidades, preferencias o restricciones que llevarán al equipo a explorar otras alternativas.
Las herramientas cambiarán, pero el conocimiento del equipo no debería cambiar de lugar cada vez que aparece una nueva IA. Por eso, en lugar de invertir esfuerzos en replicar contexto entre herramientas, resulta más sostenible construir una única fuente de verdad que pueda ser consumida por cualquiera de ellas.
Cuando el conocimiento está centralizado:
- Cambiar de herramienta deja de ser un problema.
- Incorporar nuevas IAs requiere menos esfuerzo.
- El equipo trabaja con reglas y contexto consistentes.
- Se reduce la duplicación y el mantenimiento.
No estandarices una herramienta. Estandariza el conocimiento.
