🧱 Fundamentos

Un agente de programación es un LLM que ejecuta un ciclo autónomo: lee código, planifica, edita archivos, ejecuta comandos y revisa su propio resultado, a diferencia del autocompletado, que solo sugiere la siguiente línea.

Sin este modelo mental, usas Claude Code/Codex como si fuera Copilot y pierdes el 90% del valor. El agente realiza la tarea de principio a fin, no solo un fragmento de código.

Bucle ReAct (razonamiento + acción), uso de herramientas, permisos, contexto persistente de la sesión, hooks de eventos.

Archivo Markdown en la raíz del proyecto que el agente lee automáticamente al inicio de cada sesión. Claude Code busca CLAUDE.md; Codex busca en AGENTS.md. La misma función, con otro nombre.

Es el "manual del proyecto" que el agente siempre tiene presente. Bien escrito, evita que tengas que repetir el contexto en cada sesión. Mal escrito, se convierte en ruido que se ignora.

Jerarquía global (~/.claude/CLAUDE.md) frente al proyecto, instrucciones directas, convenciones de código, comandos de compilación y pruebas, enlaces a documentación interna.

Carpeta oculta del proyecto donde reside todo lo específico del agente: settings, skills, sub-agents, hooks. Claude usa .claude/; Codex usa .codex/ para config y .agents/ para skills.

Es donde personalizas el comportamiento del agente por proyecto. Sin entender esta carpeta, te quedas solo con los defaults — y los defaults nunca son lo ideal para tu flujo de trabajo.

Global vs. proyecto (tilde-dot vs. dot), carpetas semánticas (skills/, agents/, commands/), settings.json y config.toml, gitignore parcial (commitear skills, ignorar credenciales).

Skill es una «competencia empaquetada»: un archivo SKILL.md con frontmatter YAML (nombre, descripción) + cuerpo en markdown que explica cómo ejecutar una tarea; se activa automáticamente cuando aparece el desencadenante en el contexto.

Las Skills son la forma moderna de enseñar comportamiento al agente sin inflar el CLAUDE.md/AGENTS.md. Ambos entornos de ejecución implementan el estándar Agent Skills (agentskills.io); solo tienen algunas diferencias.

Frontmatter YAML, activación por descripción (coincidencia semántica), directorios scripts//references//assets/, invocación con barra (/skill) frente a la invocación con dólar ($skill).

Un subagente es una «persona especializada» a la que el agente principal puede delegar tareas. Claude Code descubre e invoca subagentes automáticamente; Codex exige que los llames por nombre.

Este es el mayor choque entre los dos. Quien migra lo olvida y se frustra pensando que Codex «no tiene sub-agents». Sí los tiene, solo que no los invoca automáticamente.

Formato Markdown (Claude) vs TOML (Codex), descripción como disparador de autoselección, aislamiento del contexto, dispatch de agentes en paralelo, costo de tokens.

Model Context Protocol es un estándar abierto para conectar LLMs con herramientas externas (Slack, Gmail, bases de datos, etc.). Claude Code y Codex consumen servidores MCP de la misma manera.

MCP es la parte de la pila que NO cambia entre runtimes. Si configuras un servidor MCP, sirve para ambos. Solo cambia la forma de declarar la dependencia.

Servidor stdio vs. HTTP, declaración en .mcp.json, herramienta expuesta como mcp__server__tool, permisos/lista permitida por servidor.

Cada agente tiene perfiles distintos: Claude tiende a ser más detallista en refactors largos y depuración profunda; Codex suele ser más rápido en tareas pequeñas y seguir los prompts estrictos al pie de la letra.

Saber qué herramienta elegir para cada tarea ahorra horas. No es «cuál es mejor», sino «cuál es mejor para esto ahora mismo».

Estilo de razonamiento (más orientado a la planificación vs. más orientado a la ejecución), tolerancia a la ambigüedad, comportamiento al editar archivos grandes, costo por token.

Estándar observado por quienes usan ambos: cuando un agente entra en un bucle, repite el mismo error o pierde el hilo, pasar el contexto al otro suele resolverlo en segundos.

Es la justificación #1 para tener ambos instalados. No necesitas esperar soporte ni seguir luchando: abre el segundo agente, pega el resumen y sigue adelante.

Session handoff (cf. T6.1), volcado del contexto en markdown, «efecto de ojos nuevos», costo de cambio casi nulo cuando el proyecto está bien documentado.

Los proveedores fallan. Se alcanzan los límites. Si tu productividad depende 100% de Anthropic O de OpenAI, cualquier inestabilidad te deja fuera de servicio. Tener ambos garantiza la continuidad.

Si cobras por hora o tienes una fecha límite, el costo de quedarte parado es mayor que el de las dos suscripciones. Haz el cálculo.

Páginas de estado (status.anthropic.com, status.openai.com), límite de solicitudes por ventana, alternativa manual, «tool-agnostic» como principio.

Todo lo que NO es configuración del agente (código fuente, docs, scripts, READMEs, wikis) lo leen ambos por igual. No duplicas nada de eso.

Este es el punto que desbloquea la coexistencia: el 95% del proyecto se comparte. Solo el 5% de la configuración necesita traducción, y polyskill resuelve esa traducción para las skills.

Código fuente, documentación, ADR, scripts de shell, datos de ejemplo: todo se comparte. Solo se duplican las Skills, los sub-agents y los settings.

Actitud de no casarse con una herramienta. El ecosistema de coding agents cambia rápido: Gemini CLI, Cursor, Copilot, JetBrains y la próxima herramienta. Tu skill debe sobrevivir al cambio de herramienta.

Quien se queda atrapado en un runtime sufre cada vez que aparece algo mejor. Quien escribe contenido portable migra en horas. polyskill es la manifestación técnica de esa mentalidad.

Especificación abierta (agentskills.io), formato canónico frente a formato de entorno de ejecución, adaptadores conectables, política de divergencia, «rewrite-once, deploy-many».

Sí, son dos planes que pagar. Pero ¿cuánto vale una hora tuya bloqueada por un agente atascado? ¿Cuánto vale aprender el ecosistema dominante cuando cambie la marea?

Para defender la elección ante ti (y ante el equipo o cliente) con números, no con sensaciones. Hay escenarios en los que basta con una sola, y otros en los que dos son el mínimo.

Plan según el uso vs. suscripción, costo de oportunidad, depreciación del conocimiento, valor de la redundancia en flujos críticos.