En mayo de 2026, un desarrollador corrió GPT-5.5, GPT-5.4 y Opus 4.7 contra 56 tareas reales de código extraídas de dos repositorios open source. El resultado: GPT-5.5 ganó en “shipping” (patches que pasan tests y sobreviven code review), mientras Opus 4.7 escribió patches notablemente más chicos, aunque en uno de los repos eso significó código incompleto.
En 30 segundos
- GPT-5.5 fue el mejor default para producción: sus patches pasan tests, matchean la intención del cambio humano y sobreviven code review con más frecuencia.
- Opus 4.7 escribió patches 30-40% más pequeños, lo que en el repo Zod fue un trade-off real, pero en el segundo repo fue bajo-implementación.
- La evaluación usó 27 tareas de Zod y 29 de un segundo repo, con cada modelo corriendo en su harness nativo (Claude Code para Anthropic, Codex CLI para OpenAI).
- No hay ganador absoluto: el resultado depende de si tu bottleneck es el costo de review o el footprint del código generado.
- Los benchmarks públicos (SWE-bench, etc.) no predicen este comportamiento. Necesitás correr tu propio eval en tu codebase.
Benchmarks públicos vs evaluaciones en repos reales
Un benchmark público como SWE-bench agrega miles de tareas de cientos de repos y colapsa todo en un número. El problema con eso es que aplana el comportamiento del modelo: dos modelos pueden tener el mismo score agregado y comportarse de forma completamente diferente en tu codebase específica.
Ponele que tu equipo mantiene una librería de validación en TypeScript con tests estrictos y un estilo de patches minimalista. O ponele que tenés un monorepo donde cada PR toca 15 archivos y el reviewer ya está cansado antes de abrir el diff. En esos dos casos, el modelo que te conviene puede ser distinto, aunque en SWE-bench empaten.
Lo que hizo este análisis publicado el 1 de mayo de 2026 fue distinto: tomó 56 tareas de código real de dos repositorios open source concretos, corrió tres modelos en condiciones controladas, y midió qué pasó realmente. Eso es mucho más útil que un número global.
Metodología: 56 tareas de código real
El setup fue directo: 27 tareas del repo Zod (el popular parser/validator de TypeScript) y 29 de un segundo repositorio. Los repos fueron seleccionados de forma arbitraria, y el autor lo aclara explícitamente porque eso importa: los resultados pueden no representar tu experiencia, y esa es exactamente la razón por la que correr tus propios benchmarks vale la pena.
Cada modelo corrió en su harness nativo a configuración default. Anthropic en Claude Code, OpenAI en Codex CLI. Nada de wrappers custom, nada de prompting especial. Lo que dan los modelos cuando los usás como los pensó la empresa que los construyó.
La métrica central: ¿el patch pasa tests? ¿Matchea la intención del cambio humano? ¿Sobrevive code review? Eso es “shipping” en términos prácticos. Ya lo cubrimos antes en herramientas de desarrollo con GPT-5.4.
GPT-5.5 vs Opus 4.7 tareas código: el ganador en “shipping”
GPT-5.5 fue el mejor default para producción. Escribió patches que con más frecuencia pasaban los tests, matcheaban la intención del cambio y sobrevivían review. No ganó todo, pero fue el modelo al que le confiarías el commit si tuvieras que elegir uno.
¿Qué significa “sobrevivir code review”? Que el reviewer no tenga que hacer un segundo round de comentarios sobre qué faltó implementar, que los edge cases estén cubiertos, que el estilo del código sea coherente con el repo. GPT-5.4 también estuvo en la evaluación y quedó por debajo de su sucesor en todas estas dimensiones.
Eso sí: GPT-5.5 no es perfecto. “El mejor en shipping” no significa “hace todo bien”. Significa que de las tres opciones evaluadas, sus patches son los más probables de mergearse sin drama.
Opus 4.7: patches compactos con trade-offs reales
Opus 4.7 escribió patches notablemente más chicos. En el repo Zod, eso fue un trade-off genuino: patches más focalizados, cambios más quirúrgicos. Si tu equipo valora diffs limpios y chicos, hay algo atractivo ahí.
El problema apareció en el segundo repositorio. Ahí los patches chicos de Opus 4.7 no eran disciplina, eran bajo-implementación. El modelo no completaba el trabajo. Casos no cubiertos, lógica faltante, tests que pasaban pero que no testeaban lo que deberían.
¿Alguien verificó si el patrón se repite en otros repos? Todavía no hay evidencia pública de una evaluación más amplia con este mismo setup. Complementá con integración de Copilot y agentes IA.
La diferencia entre “patch chico porque es preciso” y “patch chico porque cortó camino” es algo que el benchmark público no te dice. Necesitás ver el diff y entender el contexto del repo para saberlo.
El dilema real: footprint vs carga de review
No hay ganador absoluto en esta evaluación, y ese es uno de los hallazgos más honestos que podés esperar de un benchmark.
Si el bottleneck de tu equipo es el tiempo de review, GPT-5.5 probablemente te ahorre más rondas de comentarios. Si el problema es deuda técnica de código generado enorme y difícil de entender, Opus 4.7 puede ser la opción (siempre que el repo sea del estilo Zod, no del segundo).
Lo que nunca conviene: patches chicos que no resuelven el problema. Eso es lo peor de los dos mundos. Menos líneas de código con más errores lógicos no es eficiencia, es retrabajo disfrazado.
Tabla comparativa de los tres modelos
| Dimensión | GPT-5.5 | GPT-5.4 | Opus 4.7 |
|---|---|---|---|
| Tasa de shipping (patches mergeables) | La más alta de los tres | Por debajo de GPT-5.5 | Variable por repo |
| Tamaño de patches | Normal/amplio | Normal/amplio | 30-40% más chico |
| Completitud en Zod | Alta | Media-alta | Alta (trade-off real) |
| Completitud en segundo repo | Alta | Media | Bajo-implementación |
| Harness nativo | Codex CLI | Codex CLI | Claude Code |
| Ideal para | Producción general | Fallback de GPT-5.5 | Repos con estilo minimalista |
Cómo ejecutar tu propio benchmark repo-específico
El punto de esta evaluación no es “usá GPT-5.5 y listo”. Es que los resultados del paper de alguien no aplican necesariamente a tu codebase. El comportamiento de un modelo de lenguaje sobre código cambia según el estilo del repo, el tipo de tareas, y los estándares de review de tu equipo.
Un proceso razonable para correr tu propio eval:
- Elegí 15-20 tareas reales de tu codebase: issues cerrados recientemente, bugs de mediana complejidad, features chicas. Que sean representativas de tu trabajo real, no los casos más fáciles.
- Corrí cada modelo en su harness nativo a configuración default. No personalices los prompts todavía, primero medí el baseline.
- Medí lo que importa en tu equipo: tasa de tests pasando, número de rondas de review antes del merge, tiempo desde el primer commit hasta el merge, y si el cambio matcheó la intención del issue original.
- Con esos números, tomá la decisión. Y si cambiás de modelo, volvé a correr el eval en 3 meses.
Esto aplica tanto si tu equipo despliega en infraestructura propia como si usás servicios cloud. El modelo que genere mejor código para tu repo es el que te ahorra plata, no el que tiene el benchmark público más alto. Sobre eso hablamos en capacidades de ChatGPT en desarrollo.
Diferencias en eficiencia y costos
Según análisis comparativos publicados en 2026, GPT-5.5 usa aproximadamente 72% menos tokens de salida que Opus en tareas similares. Eso tiene impacto directo en el costo por tarea si estás pagando por tokens.
Pero el costo real no es solo tokens de salida. Si Opus 4.7 produce patches incompletos que requieren una segunda o tercera pasada, el costo sube aunque los tokens por intento sean menores. El patch chico que no resuelve el problema cuesta el doble: el primer intento más el correctivo.
GPT-5.5 y Opus 4.7 tienen precios diferentes por millón de tokens. Si vas a escalar el uso de estos modelos para automatizar partes del desarrollo, hacé los números con tu tasa de éxito real (patches mergeados al primer intento) y no solo con el costo de lista.
Errores comunes al comparar modelos de código
Usar benchmarks públicos como criterio único
SWE-bench y benchmarks similares dan una orientación inicial, pero agregan comportamientos de cientos de repos con contextos muy distintos. Un modelo puede ser excelente en repos de Python y mediocre en TypeScript con tipos estrictos. Si tomás una decisión de tooling basada solo en SWE-bench, estás volando a ciegas sobre lo que importa para tu equipo. Mirá también comparativa completa con Claude Code.
Cambiar de harness y atribuir el resultado al modelo
Si corrés Opus 4.7 en Codex CLI en vez de Claude Code, los resultados van a ser peores, pero el problema no es el modelo. El harness importa. Esta evaluación fue cuidadosa en ese punto, pero muchas comparativas que circulan en Twitter no lo son. Si ves un benchmark donde todos los modelos corrieron en el mismo wrapper custom, los resultados son sospechosos (el wrapper puede favorecer el estilo de un modelo sobre otro). Cobertura relacionada: capacidades de seguridad de GPT-5.4.
Confundir “patch chico” con “patch bueno”
Tamaño y calidad son dimensiones distintas. Un patch quirúrgico que resuelve exactamente el problema es ideal. Un patch chico que deja el problema a medias es un bug disfrazado de feature. Antes de preferir un modelo porque “escribe menos código”, verificá que ese código menos resuelve el problema completo.
Preguntas Frecuentes
¿GPT-5.5 o Opus 4.7 cuál es mejor para desarrollo?
Según la evaluación de 56 tareas reales publicada en mayo de 2026, GPT-5.5 es el mejor default para producción general. Genera patches que pasan tests y sobreviven code review con más frecuencia. Opus 4.7 puede ser preferible en repos donde el estilo es minimalista y los diffs chicos son prioritarios, pero mostró bajo-implementación en al menos uno de los repos evaluados. Cubrimos ese tema en detalle en características principales de GPT.
¿Qué modelo genera patches que sobreviven code review?
GPT-5.5 tuvo la tasa más alta de patches que pasan tests, matchean la intención del cambio humano y no requieren múltiples rondas de revisión. “Sobrevivir code review” fue la métrica central de esta evaluación, y GPT-5.5 lideró en los dos repositorios analizados.
¿Opus 4.7 escribe código incompleto?
Depende del repositorio. En Zod, los patches más chicos de Opus 4.7 fueron un trade-off genuino con ventajas reales. En el segundo repo evaluado, el tamaño reducido de los patches reflejó bajo-implementación: código que no cubría todos los casos necesarios. El patrón no es universal, pero es un riesgo real que hay que verificar en tu codebase específica.
¿Cómo se comparan en 56 tareas reales de GitHub?
La evaluación usó 27 tareas del parser TypeScript Zod y 29 de un segundo repo open source, con cada modelo corriendo en su harness nativo a configuración default. GPT-5.5 fue el mejor en shipping (mergeabilidad), Opus 4.7 escribió patches más chicos con calidad variable por repo, y GPT-5.4 quedó por debajo de GPT-5.5 en todas las métricas.
¿Cuál modelo elegir para automatizar desarrollo?
Para automatización de desarrollo general, GPT-5.5 es el punto de partida más seguro en 2026. Si tu equipo quiere ir más fino, la recomendación es correr 15-20 tareas reales de tu propio repo con ambos modelos en sus harnesses nativos, medir la tasa de merge al primer intento, y decidir en base a eso. Los benchmarks públicos no son suficientes para tomar esta decisión.
Conclusión
Esta evaluación de mayo de 2026 confirma algo que muchos desarrolladores ya sospechaban: los benchmarks públicos no dicen lo suficiente. Lo que importa es cómo se comporta el modelo en tu repo, con tu estilo de código, frente a tus estándares de review.
GPT-5.5 es el mejor default para shipping en este análisis. Opus 4.7 tiene una propuesta interesante con patches más chicos, pero la historia del segundo repo donde eso derivó en bajo-implementación es una señal de alerta que no podés ignorar. Antes de adoptarlo como tu modelo de desarrollo, corré tu propio benchmark.
La conclusión práctica: si hoy tenés que elegir uno para producción sin más contexto, GPT-5.5. Si tenés tiempo para hacer el trabajo fino de evaluación repo-específica, vale hacerlo, porque la respuesta correcta para tu equipo puede ser diferente. Y si usás donweb.com para alojar tus proyectos, correr evals locales con ambos modelos no requiere infraestructura extra.