martes, 27 de octubre de 2026
PortadaModelosNoticia y análisis

SWE-2 promete programar por menos: cómo leer sus cifras sin llevarte una sorpresa

SWE-2 promete reducir costes al programar. Explicamos cómo leer sus pruebas y contar también revisión, reintentos y tareas reales.

Ilustración conceptual de un puente modular azul bajo una luz de inspección, con fichas que simbolizan el presupuesto.
Ilustración editorial de Texploto, generada con IA.

La idea clave: compara el coste de resolver una tarea aceptable, incluida la revisión. El precio de un intento no cuenta toda la historia.

Cognition anunció SWE-2 el 10 de septiembre, con disponibilidad inicial en Devin Desktop y CLI y despliegue anunciado en Devin Web y Fusion. El modelo parte de Kimi K3 y añade entrenamiento especializado en programación. Su argumento comercial combina capacidad y coste. La fuente original incluye las tablas y la metodología de Cognition.

Una cifra prometedora tiene un contexto

En FrontierCode 1.1 Main, Cognition comunica un 50,0 % para SWE-2 frente al 50,9 % de Fable 5.1 y anuncia un coste un 64 % menor en esa comparación. En otra fila de su propia tabla, Terminal-Bench 4, SWE-2 obtiene 27,3 % frente al 55,8 % de Fable 5.1. Son resultados del proveedor; Texploto no los ha reproducido.

Esa diferencia entre pruebas impide resumir el lanzamiento como una victoria en todas las tareas. El porcentaje de ahorro tampoco es una tarifa universal por token ni una reducción garantizada de tu factura.

Cuenta los intentos y la revisión

Imagina dos herramientas ante el mismo fallo. Una entrega un parche rápidamente, pero necesita varias correcciones. La otra tarda más y produce un cambio que puedes aceptar tras una revisión breve. Para comparar, anota el gasto de cada intento, el tiempo de espera y el trabajo humano hasta llegar a un resultado válido.

Conviene mantener esas columnas separadas. Convertir el tiempo humano en dinero exige una hipótesis explícita; esconderla dentro de un porcentaje hace que la comparación parezca más exacta de lo que es.

Un ensayo pequeño para tu repositorio

Protocolo propuesto · no ejecutado por Texploto

Selecciona un fallo que puedas reproducir, una modificación de interfaz acotada y una tarea de mantenimiento. Usa copias aisladas del mismo estado del proyecto y el mismo encargo. Conserva la salida, los comandos, el gasto disponible y los cambios para revisarlos.

Define antes qué significa aprobar: comportamiento esperado, pruebas relevantes y archivos que se pueden tocar. Si cambias el criterio tras ver el resultado, acabarás premiando la respuesta más convincente en lugar de la solución más útil.

  • Comprueba si el parche arregla el caso original.
  • Revisa efectos en funciones relacionadas y dependencias.
  • Anota cuándo necesitó ayuda y cuántos intentos descartaste.
  • Repite tareas comparables antes de generalizar desde una sola experiencia.

Empieza por una clase de trabajo

La decisión puede ser parcial: usar un agente para mantenimiento conocido y reservar otro flujo para cambios que exigen más contexto. Documentar dónde funciona una herramienta resulta más útil que declarar un ganador para todo el desarrollo.

Si todavía estás organizando cómo dar contexto a tus agentes, nuestra guía de proyectos persistentes en Cursor plantea esa parte del trabajo. Un modelo nuevo no elimina la necesidad de explicar qué debe conservarse, quién revisa y cuándo se puede publicar un cambio.

Una ficha para comparar tus intentos

Utiliza una ficha por tarea y herramienta. Copia el mismo encargo y conserva la misma versión inicial del proyecto para que las diferencias puedan revisarse.

Plantilla de evaluación · sin resultados medidos

  • Tarea y punto de partida: fallo reproducible, versión del proyecto y resultado esperado.
  • Herramienta: modelo, configuración y fecha.
  • Intentos: cuántos se ejecutaron y cuáles necesitaban correcciones.
  • Gasto registrado: suma de los intentos; indica «no disponible» si no puedes obtenerlo.
  • Tiempo: espera de la herramienta y minutos de revisión humana, en columnas separadas.
  • Resultado: aceptado, rechazado o pendiente, con la comprobación que lo justifica.

Ejemplo ficticio: si tres intentos cuestan 0,20 €, 0,30 € y 0,50 € y solo el último entrega una solución aceptable, resolver esa tarea ha costado 1 € en esos intentos. Los veinte minutos de revisión que pudieras dedicar se registrarían aparte. Estas cantidades ilustran el cálculo; no son precios ni resultados de SWE-2.

Si ningún intento funciona, conserva el gasto y marca la tarea como no resuelta. Excluir esos casos haría que la comparación pareciese mejor de lo que fue.

Para concretar el encargo, utiliza la plantilla de continuidad del proyecto. Si el problema es seleccionar la documentación correcta, prueba el ejercicio de contexto y versiones.