Source: Dev.to

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<Response> {
  let lastError: Error | undefined;

  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      const response = await fetch(url);

      // Si la respuesta es exitosa, la devolvemos.
      if (response.ok) return response;

      // Si el código de estado indica que debemos reintentar, esperamos.
      if (response.status === 429 || response.status >= 500) {
        await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 1000));
        continue;
      }

      // Otros códigos de error se consideran definitivos.
      return response;
    } catch (err) {
      lastError = err as Error;
      // Esperamos antes de volver a intentar.
      await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 1000));
    }
  }

  // Si agotamos los intentos, lanzamos el último error.
  throw lastError!;
}

Propuesta de Claude Sonnet 4.6 (inyección de dependencias)

interface RetryConfig {
  /** Número máximo de reintentos. */
  maxRetries?: number;
  /** Función que devuelve una promesa de delay; mockeable en tests. */
  delay?: (attempt: number) => Promise<unknown>;
  /** Lógica para decidir si se debe reintentar a partir de la respuesta. */
  shouldRetry?: (response: Response) => boolean;
}

/**
 * Refactorización que permite inyectar dependencias para facilitar pruebas.
 */
async function fetchWithRetry(
  url: string,
  config: RetryConfig = {}
): Promise<Response> {
  const {
    maxRetries = 3,
    delay = (attempt) =>
      new Promise((r) => setTimeout(r, Math.pow(2, attempt) * 1000)),
    shouldRetry = (res) => res.status === 429 || res.status >= 500,
  } = config;

  let lastError: Error | undefined;

  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      const response = await fetch(url);

      if (response.ok) return response;
      if (shouldRetry(response)) {
        await delay(attempt);
        continue;
      }

      return response;
    } catch (err) {
      lastError = err as Error;
      await delay(attempt);
    }
  }

  throw lastError!;
}

GPT‑4o llegó a una solución similar, aunque con una interfaz ligeramente distinta; sigue siendo 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

Diferencias observadas

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 resultó notablemente mejor: más preciso, con más contexto útil y con menos relleno.

Problema: Opus 4.6 cuesta considerablemente más. En entornos de producción con uso intensivo, el costo escala rápidamente y se vuelve un factor limitante.

Gemini 2.0 Flash fue una sorpresa positiva para tareas más simples. Es muy rápido y barato, y para preguntas como “¿tiene este código algún bug obvio?” o “genera el JSDoc para esta función” funciona bien. Su punto débil aparece cuando la tarea requiere mantener contexto de múltiples archivos o razonar sobre interacciones entre distintos módulos del sistema.

Una observación sobre Gemini 2.0 Pro (poco mencionada en los reviews) es su ventana de contexto de 2 millones de tokens. En teoría suena increíble, pero en la práctica, al pasarle contextos muy largos (varios archivos de código a la vez), la calidad de las respuestas resulta inconsistente. No siempre aprovecha toda la 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, aunque a veces comete 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) son:

Estrategia que adoptamos: routing por complejidad

def select_model_for_review(diff_size: int, complexity_score: float) -> str:
    """
    Devuelve el modelo a usar según el tamaño del diff y una puntuación de complejidad.

    Parameters
    ----------
    diff_size : int
        Número total de líneas modificadas en el PR.
    complexity_score : float
        Valor entre 0‑1 calculado a partir del número de archivos,
        profundidad de los cambios y si tocan partes críticas del sistema.

    Returns
    -------
    str
        Identificador del modelo a invocar.
    """
    # Cambios grandes o arquitectónicamente complejos: vale la pena Sonnet
    if diff_size > 1000 or complexity_score >= 0.7:
        return "claude-sonnet-4-6"
    # 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:

Observación adicional

Latencia:

• La latencia impacta más de lo que parece al integrar estos modelos en herramientas interactivas.
• Claude es algo más lento en respuestas iniciales para prompts cortos, lo que se nota en un copilot dentro del editor.
• En procesos batch la diferencia es irrelevante, pero en interacciones en tiempo real puede ser decisiva.

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

Modelo por defecto para un nuevo proyecto

Claude Sonnet 4.6

• No es perfecto, pero ofrece el mejor equilibrio entre calidad, consistencia y coste para la mayoría de las tareas de desarrollo de software.
• Los errores que comete son más fáciles de detectar que los de otros modelos, lo que resulta valioso en producción.

Cuando mantener el modelo actual tiene sentido

• Integración profunda con Azure/OpenAI (o casos de uso que dependen de funcionalidades específicas de GPT‑4o).
• No cambies lo que funciona sin una razón clara.

Cuando el coste es el factor limitante

• Gemini 2.0 Flash es una alternativa seria si manejas volúmenes grandes o tienes un presupuesto ajustado.
• En nuestro pipeline cubre ~40 % de las solicitudes sin que la diferencia de calidad sea perceptible en el resultado final.

Mi setup actual

Conclusión

Lo que más importa no es el modelo que elijas hoy, sino que tu arquitectura permita cambiar de modelo fácilmente cuando aparezca una opción mejor. Esa “mejor opción” suele estar a unos dos meses de distancia.