Claude Code o Codex: el método importa más que la herramienta
Mike Codeur
Anuncié que dejaba Claude Code y Codex por una herramienta desconocida. La frase llama la atención, pero la conclusión es menos cómoda: no abandoné ni Claude Code ni Codex.
Los devolví a su sitio.
Comparar modelos y herramientas es útil. La calidad, el precio, la velocidad, la seguridad y la ergonomía cambian el trabajo. El problema empieza cuando una elección temporal se convierte en identidad profesional. Si cada lanzamiento obliga a reconstruir todo el proceso, hemos aprendido sobre todo una interfaz.
Tres capas que no conviene mezclar
El desarrollo asistido por agentes se entiende mejor al separar tres capas.
| Capa | Función | Ejemplos | Lo que cambia rápido |
|---|---|---|---|
| LLM | Comprender, razonar y generar | Claude, GPT, Gemini | capacidad, precio, contexto |
| Harness o arnés agéntico | Dar al modelo contexto, herramientas, permisos y un bucle de ejecución | Claude Code, Codex CLI, OpenCode | interfaces, integraciones, comportamiento |
| Método | Delimitar el problema, dividir el trabajo y comprobar el resultado | criterios de aceptación, tests, revisión, puertas de validación | mucho más despacio |
El LLM es el motor. El harness organiza la ejecución alrededor del motor. El método decide qué hay que construir, en qué orden y qué pruebas demuestran que está terminado.
Claude Code y Codex CLI no son modelos. Son entornos de ejecución que reúnen el contexto, llaman herramientas, inspeccionan el repositorio, gestionan permisos y repiten una tarea. Dos harnesses pueden usar modelos parecidos y ofrecer condiciones de trabajo muy distintas.
Las herramientas importan sin convertirse en tu identidad
Ser agnóstico no significa que todas las herramientas sean iguales. Un modelo mejor puede resolver un bug que otro no resuelve. Un harness mejor integrado puede eliminar fricción, limitar errores y facilitar las revisiones.
Sigo comparando herramientas y elijo el mejor ejecutor para el problema actual. Lo que evito es guardar todo el método dentro de un producto que quizá reemplace en tres meses.
Es el mismo error de las antiguas guerras entre IntelliJ y Eclipse. El IDE influye en la comodidad y la velocidad. No sustituye la arquitectura, el diagnóstico, los tests ni la capacidad de entregar un cambio seguro.
Lo que conservo por encima de Claude Code y Codex
Un método portátil deja artefactos útiles para la siguiente herramienta:
- Una necesidad delimitada. El objetivo, el alcance y las restricciones se escriben antes de ejecutar.
- Una división visible. Las dependencias y el orden de las tareas no quedan escondidos en un chat.
- Artefactos de decisión. El PRD, la arquitectura, las decisiones y los criterios de aceptación viven en el repositorio.
- Roles separados. El agente que escribe el cambio no lo aprueba en solitario.
- Puertas bloqueantes. Una etapa no pasa si faltan tests, revisión o pruebas.
- Un bucle de retorno. Los fallos observados se convierten en tests, reglas o mejores instrucciones.
Estos elementos sobreviven a un cambio de modelo y también a un cambio de harness porque no dependen de un botón o un comando propietario.
Killer SaaS es un ejemplo, no una receta universal
Aplico esta lógica en Killer SaaS, mi método para sustituir software caro por productos enfocados. El encuadre del producto se realiza una vez. Después, cada funcionalidad pasa por un ciclo repetido de investigación, diseño, planificación, ejecución, revisión y validación.
Claude Code o Codex pueden ejecutar ese ciclo. Su papel importa, pero no contienen por sí solos todo el conocimiento acumulado. El alcance, las decisiones, los tests y los comentarios de revisión siguen disponibles si cambio de ejecutor.
El método no es universal. Un sistema legacy, un prototipo, una migración regulada y un producto greenfield tienen riesgos distintos. La habilidad duradera consiste en construir los controles adecuados para el contexto, no en copiar una carpeta de prompts.
Una prueba sencilla para tu sistema
Pregúntate qué perderías si mañana sustituyes Claude Code por Codex, o Codex por otra herramienta.
- Si pierdes principalmente atajos, tu sistema es portátil.
- Si pierdes el contexto, las decisiones, los criterios y los tests, el proceso depende demasiado de la herramienta.
- Si nadie puede explicar por qué el cambio es correcto, falta un método de validación.
Usa las mejores herramientas disponibles. Conserva necesidades, decisiones, tests y pruebas en formatos que la siguiente herramienta pueda reutilizar.