Source: Dev.to

El mes pasado me tocó tomar una decisión que probablemente muchos de ustedes han enfrentado

Nuestro equipo quería integrar un LLM en el pipeline de revisión de PRs, y alguien tenía que elegir cuál usar en producción. Ese alguien fui yo.

Así que dediqué dos semanas a probar:

• Claude (Sonnet 4.6 y Opus 4.6)
• GPT‑4o
• Gemini 2.0 (Flash y Pro)

con tareas reales de nuestro flujo de trabajo — revisión de código, generación de tests, análisis de logs de errores y documentación técnica. No benchmarks artificiales, sino tareas que yo o mi equipo hacemos todos los días.

Lo que encontré me sorprendió en algunos casos y confirmó lo que ya sospechaba en otros.

---

Por qué esta prueba era diferente a leer un leaderboard

Trabajamos en un equipo de seis personas construyendo una plataforma SaaS de analytics.

Stack principal: TypeScript, React, Node.js, PostgreSQL.

El proyecto de revisión de PRs consistía en analizar diffs de código y generar comentarios estructurados — identificar posibles bugs, sugerir mejoras de performance, verificar que los tests cubran los casos edge relevantes.

Para cada modelo usé la misma batería de prompts sobre los mismos PRs reales (con nombres de variables y datos sensibles sanitizados, obvio). Medí:

• Calidad de los comentarios
• Tiempo de respuesta
• Consumo de tokens para tareas equivalentes
• Consistencia del output entre llamadas

Gasté alrededor de $40 en total entre las tres APIs. No es una fortuna, pero fue suficiente para tener una muestra decente. También anoté en qué tareas fallaba cada modelo y con qué frecuencia, no solo cuándo brillaba.

---

Generación de código: Claude gana, pero GPT‑4o no se queda atrás

La verdad, para generación de código complejo, Claude Sonnet 4.6 fue mi favorito. No por un margen enorme, pero sí consistente. Cuando le pedía refactorizar funciones asíncronas complicadas o generar lógica de manejo de errores para edge cases específicos, el código que producía necesitaba menos correcciones manuales.

Ejemplo concreto

Teníamos una función que manejaba reintentos de peticiones a una API externa con backoff exponencial, con lógica especial para códigos de error específicos. Le pasé el código original y le pedí a cada modelo que lo refactorizara para hacerlo más testeable.

// Prompt: "Refactoriza esta función para que sea más fácil de testear.
// Necesito poder mockear el delay y controlar qué errores se reintentan."

// Versión original (simplificada):
async function fetchWithRetry(url: string, maxRetries = 3): Promise {
  let lastError: Error;
  for (let attempt = 0; attempt = 500) {
        await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 1000));
        continue;
      }
      return response;
    } catch (err) {
      lastError = err as Error;
      await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 1000));
    }
  }
  throw lastError!;
}

// Claude Sonnet 4.6 propuso inyección de dependencias así:
interface RetryConfig {
  maxRetries?: number;
  delay?: (attempt: number) => Promise;      // mockeable en tests
  shouldRetry?: (response: Response) => boolean;   // lógica separada y testeable
}

async function fetchWithRetry(
  url: string,
  config: RetryConfig = {}
): Promise {
  const {
    maxRetries = 3,
    delay = (attempt) =>
      new Promise(r => setTimeout(r, Math.pow(2, attempt) * 1000)),
    shouldRetry = (res) => res.status === 429 || res.status >= 500,
  } = config;
  // ... resto idéntico pero ahora con las dependencias inyectadas
}

GPT‑4o llegó a una solución similar, aunque con un diseño de interfaz ligeramente diferente. Perfectamente usable.

Gemini 2.0 Pro también lo resolvió, pero — y este es un patrón que noté varias veces — tendía a over‑engineer la solución, añadiendo abstracciones que nadie pidió, como una clase RetryManager completa con métodos estáticos para una función que perfectamente podría quedarse como función.

Gotchas

• En una tarea de análisis de código Python (no nuestro stack principal, pero a veces revisamos contribuciones externas), GPT‑4o sugirió usar async-timeout con una API que ya no existe en las versiones recientes del paquete. El error pequeño me costó 15 minutos descubrir por qué el código no funcionaba.
• Con Claude no tuve ese problema en las mismas tareas — aunque no diría que sea inmune a este tipo de confabulación, simplemente no me pasó en esta muestra.

---

Razonamiento y análisis: donde Claude realmente se distancia

Aquí la diferencia fue más clara. Para tareas que requerían razonamiento sobre código — “¿por qué este query de PostgreSQL está siendo lento dado este execution plan?” o “analiza este stack trace y dime qué puede estar causando el memory leak en Node” — Claude Opus 4.6 era notablemente mejor: más preciso, con más contexto útil y con menos relleno.

Problema: Opus 4.6 cuesta considerablemente más. Para uso intensivo en producción, el costo escala rápido y se siente.

Gemini 2.0 Flash fue una sorpresa positiva para tareas más simples. Muy rápido, barato, y para “¿tiene este código algún bug obvio?” o “genera el JSDoc para esta función” funciona bien. Donde se rompe es cuando la tarea requiere mantener contexto de múltiples archivos o razonar sobre interacciones entre distintos módulos del sistema.

Una cosa que noté con Gemini 2.0 Pro, y que nadie en los reviews que leí mencionaba con honestidad, es su ventana de contexto de dos millones de tokens. En papel suena increíble, pero en la práctica, cuando le pasaba contextos muy largos — varios archivos de código a la vez — la calidad de las respuestas era inconsistente. No siempre usaba bien toda esa información disponible. Los release notes de febrero mencionan mejoras en este aspecto, pero a la fecha sigue siendo un punto débil.

---

Conclusión breve:

• Claude Sonnet 4.6 → mejor para generación de código limpio y consistente.
• Claude Opus 4.6 → sobresale en razonamiento profundo, pero su costo es alto.
• GPT‑4o → buena alternativa equilibrada, con algunos errores de referencia.
• Gemini Flash → barato y rápido para tareas triviales.
• Gemini Pro → gran contexto teórico, pero calidad variable en la práctica.

Con esta información, puedes decidir cuál modelo se alinea mejor con tus prioridades de costo, velocidad y profundidad de razonamiento.

El factor costo: lo que cambia cuando lo usas en producción real

Aquí está la parte que la mayoría de las comparativas no tocan con suficiente honestidad.

En desarrollo y pruebas, todos los modelos se sienten baratos porque los usas ocasionalmente. Cuando los integras en un pipeline que procesa cientos de solicitudes al día, la matemática cambia. Mis estimaciones para nuestro caso de uso (análisis de PRs medianos, ~2 000 tokens de input y ~800 de output):

Lo que terminamos haciendo fue routing por complejidad:

def select_model_for_review(diff_size: int, complexity_score: float) -> str:
    """
    complexity_score: float 0‑1, calculado en base a número de archivos,
    profundidad de cambios, y si toca partes críticas del sistema.
    """
    if diff_size = 0.7 or diff_size > 1000:
        # Cambios grandes o arquitectónicamente complejos: vale la pena Sonnet
        return "claude-sonnet-4-6"
    else:
        # Zona gris: depende del rate limit actual de cada API
        return "gpt-4o"

No es la arquitectura más elegante del mundo, pero en tres semanas de producción ha funcionado. No estoy 100 % seguro de que este enfoque escale sin fricciones cuando tengamos diez veces más PRs, pero por ahora el ahorro en tokens es real.

---

Lo que cada modelo hace mejor, sin rodeos

Después de dos semanas, esto es lo que realmente pienso:

• Claude Sonnet 4.6

  • Sigue instrucciones complejas con mayor fidelidad que los otros dos.
  • No inventa APIs que no existen con la misma frecuencia.
  • Cuando no sabe algo, tiende a decirlo en lugar de generar algo plausible‑pero‑incorrecto.
  • Para código TypeScript y Python, la calidad es consistentemente alta sin necesitar prompts muy elaborados.

• GPT‑4o

  • Brilla en integración con el ecosistema Azure/OpenAI si ya estás en él.
  • Ideal para generación de texto que no es código puro (documentación, mensajes de commit detallados, resúmenes de changelogs).
  • Soporte multimodal sólido para analizar screenshots de errores junto con código.
  • Acceso a herramientas como web search nativo dentro del mismo contexto, útil para ciertos flujos de trabajo.

• Gemini 2.0 Flash

  • Modelo que más me sorprendió en sentido positivo por el costo.
  • Para tareas de alto volumen donde la precisión no necesita ser perfecta, es difícil justificar pagar más.
  • Gemini 2.0 Pro es más capaz, pero no aprovecha bien su enorme ventana de contexto, que es su característica más impresionante sobre el papel.

Algo que nadie menciona suficiente: la latencia importa más de lo que parece cuando integras estos modelos en herramientas interactivas. Claude tiende a ser algo más lento en respuestas iniciales para prompts cortos comparado con GPT‑4o. Para casos batch no importa, pero para un copilot interactivo dentro de tu editor sí lo notarás.

---

Qué usaría yo y qué le recomiendo a mi equipo

• Modelo por defecto para un nuevo proyecto: Claude Sonnet 4.6.
  No porque sea perfecto en todo — no lo es — sino porque ofrece el mejor balance entre calidad, consistencia y costo para tareas típicas de desarrollo de software. Los errores que comete tienden a ser más detectables que los de los otros modelos, lo cual en producción vale mucho.

• Si tu equipo ya está integrado profundamente con Azure/OpenAI (o tienes casos de uso que dependen de funcionalidades específicas de GPT‑4o), tiene todo el sentido quedarse ahí. No cambies lo que funciona sin una razón real.

• Si el costo es tu limitante principal (volúmenes grandes, presupuesto ajustado), dale una oportunidad seria a Gemini 2.0 Flash antes de descartarlo. En nuestro pipeline cubre alrededor del 40 % de las solicitudes sin que la diferencia de calidad sea perceptible en el output final.

Mi setup actual

Lo que más importa no es el modelo que elijas hoy — es que tu arquitectura haga fácil cambiar de modelo cuando salga algo mejor. Y ese algo mejor siempre está a dos meses de distancia.