Claude Opus vs GPT-4 para escribir plugins de WordPress: prueba completa
Cara a cara: pedí a Claude Opus y a GPT-4 construir los mismos tres plugins. Ganador por calidad de código, defaults de seguridad y cumplimiento de estándares WP.
Le di a Claude Opus 4.6 y a GPT-4 los mismos tres prompts de plugin de WordPress, con las mismas instrucciones de sistema sobre WordPress Coding Standards. Luego revisé la salida a ciegas (sin saber qué modelo había producido qué) y puntué. Esto es lo que encontré.
Cómo se montó la prueba
Mismos prompts, mismo mensaje de sistema describiendo el contexto WordPress (WP 6.4, PHP 8.1, WooCommerce 8.5 donde aplica), mismos temperature y top_p. Sin código de referencia. Corrí cada modelo tres veces por prompt y elegí el mejor intento. Revisé a ciegas con una rúbrica numerada: estructura (15), defaults de seguridad (25), defaults de rendimiento (15), cumplimiento WP standards (15), legibilidad (15), completitud funcional (15). Total sobre 100.
Prompt 1: Fácil — "Shortcode que muestre la fase lunar actual con un emoji"
Salida esperada corta, ~40 líneas. La parte difícil es usar una fórmula astronómica correcta en vez de una aproximación barata.
Claude Opus 4.6: usó el algoritmo de Conway con la época correcta, cacheó el cálculo en transient de una hora, devolvió string escapado, y añadió una función test-friendly con inyección de dependencias de la fecha actual. 94/100. Perdió puntos porque el algoritmo no es el más preciso, pero era el trade-off correcto para un plugin de este tamaño.
GPT-4: usó una fórmula más simple módulo 29,53 días, sin caché, devolvió HTML directamente sin escapar. Menos defendible en la fórmula (precisión quizá de un día) pero funcionaba. 72/100. Perdió puntos por la salida sin escapar, que es un bug real.
Ganador: Claude.
Prompt 2: Medio — "Resumen semanal por email de productos WooCommerce con poco stock, umbral configurable"
Requiere: cron, página de opciones, templating de email, lookup de stock, soporte multitienda. ~200-300 líneas de código real.
Claude Opus 4.6: arquitectura limpia en cuatro ficheros, usó wp_schedule_event con unschedule en deactivate (correcto), construyó el email desde una plantilla HTML con wp_mail y headers Content-Type correctos, página de opciones con nonce, testeado con caso cero productos. Añadió un botón "Enviar test ahora" en los ajustes que no pedí. 91/100. Perdió puntos por no deduplicar notificaciones si el mismo producto sigue bajo semana tras semana.
GPT-4: implementación en fichero único, usó wp_mail correctamente, pero guardaba la plantilla como un string constante gigante que hacía incómoda la personalización. El cron se programaba en activación pero no se desprogramaba en desactivación: desactivar y reactivar crearía eventos cron duplicados. 78/100.
Ganador: Claude.
Prompt 3: Complejo — "Sincronizar pedidos WooCommerce a HubSpot como deals, bidireccional, con UI de mapeo de campos"
Escala "proyecto de cliente real". ~600-900 líneas esperadas. Varias APIs, lógica con estado, UI admin, cola, reintentos.
Claude Opus 4.6: dividido en siete ficheros, creó cola con tabla propia (correcto para volumen), usó WP Cron con fallback a Action Scheduler si estaba disponible, refresh de token OAuth integrado, UI de mapeo como componente React con WP Scripts. Sync bidireccional con debounce para evitar loops. 89/100. Perdió puntos porque la UI React requería build step y el ZIP no incluía el bundle compilado, así que no funcionaba out-of-the-box sin npm install y npm run build.
GPT-4: cinco ficheros, cliente HubSpot con reintentos manuales, UI de mapeo con jQuery plano (más simple, funcionaba ya). Cola en tabla de opciones: no escala más allá de unos pocos miles de pedidos. No manejaba refresh del token OAuth: el plugin se rompería tras una hora. 69/100.
Ganador: Claude.
Puntuaciones globales
- Media Claude Opus 4.6: 91,3/100
- Media GPT-4: 73,0/100
Claude fue consistentemente mejor en defaults de seguridad (escape, nonces, capability checks) y en pensar en ciclo de vida del plugin (activate, deactivate, uninstall). GPT-4 fue ligeramente mejor produciendo código que "simplemente funcionaba" sin pasos extra de build, lo que importa si pegas en producción con prisa.
Dónde gana cada uno
Claude es el modelo que uso para trabajo de cliente donde voy a revisar el código y me importa que siga convenciones. Sus defaults están más cerca de lo que produciría un dev senior de plugins.
GPT-4 es útil cuando la prioridad es un prototipo desechable. Las arquitecturas más simples que produce a veces son más legibles si no necesitas escalar.
Un matiz importante
Probé el modelo a través de un agente loop con tool use (escritura de ficheros, lectura, bash). Correr Claude Opus 4.6 como completion de chat puro sin el framework de agente produce resultados notablemente peores porque el agente deja que el modelo se corrija tras leer su propia salida. Si comparas modelos, asegúrate de comparar cosas comparables.
Coste
Claude Opus 4.6 al precio actual (5 $/M input, 25 $/M output) produjo el plugin complejo por ~2 $ de coste API. GPT-4 salió similar. La diferencia de calidad es la historia, no el precio.
¿Saltaría de uno a otro?
Usaría Claude Opus 4.6 para cualquier cosa que firme. Usaría GPT-4 cuando el riesgo es bajo y quiero respuesta de un disparo. Para todo lo intermedio, correría los dos y me quedaría con el que acabe leyendo con más atención, que suele ser la salida de Claude.