Cómo decidir si SWE-2 merece la pena antes de comprometerte

El mes gratuito es el período de prueba, no el veredicto. SWE-2, el agente de código de Cognition, la empresa creadora de Devin, solo merece la pena si tu trabajo es mayoritariamente programación por cola de tickets. Si tu día son largas sesiones de terminal hostil, el modelo de frontera sigue dominando la fila decisiva.

Cognition lanzó SWE-2 el 10 de septiembre de 2026. Las puntuaciones reportadas son 50,0% en FrontierCode 1.1 Main, 73,0% en DeepSWE 1.1, 92,8% en Terminal-Bench 2.1 y 27,3% en Terminal-Bench 4, la fila de terminal posterior. La afirmación de coste de Cognition sobre SWE-2 es un 64% más barato que Fable 5.1, un modelo rival, en el punto de comparación de FrontierCode 1.1 Main. La primera edición real de código reportada (mediana) llegó tras 18 pasos en la configuración media de SWE-2, frente a 48 pasos en SWE-1.7. No se había publicado ninguna API independiente, ficha de modelo ni ventana de contexto en el lanzamiento.

La tabla de benchmarks es un mapa, no un recibo

Lee las filas como tipos de trabajo, no como un único ranking. FrontierCode 1.1 Main y DeepSWE 1.1 son las filas que importan cuando tu trabajo son tickets acotados, pull requests y pequeñas correcciones. Las filas de terminal se dividen: la anterior parece fuerte sobre el papel, pero la posterior castiga a los agentes cuando la shell se vuelve hostil. La última fila es el número que debe pesar si pasas el día en migraciones, sistemas de build rotos y trabajos de larga duración.

La afirmación de coste es útil, pero está ligada a un punto de comparación. Un agente de código barato puede ganar en un ticket acotado y aun así perder en una sesión larga de terminal. El número de pasos de la primera edición (mediana) te dice qué tan rápido se pone a trabajar el agente, pero no te dice si el trabajo sobrevive a la revisión.

Antes de confiar en cualquier fila, pregúntate qué mide. Un benchmark de tickets acotados premia ediciones rápidas y limpias. Un benchmark de terminal premia la persistencia, la recuperación de errores y la capacidad de mantener viva una sesión larga. Usa tu cola para decidir qué fila tiene más peso.

El período de prueba es donde se valida el cambio

No dejes que la prueba se diluya en un uso general. Plantéate una pregunta concreta antes de empezar: ¿qué tipo de trabajo debería asumir este agente? Luego ejecuta el mismo tipo de trabajo que ya haces, no una demo pulida. La línea base debe ser aburrida. Mantén el mismo repo, la misma forma de ticket y el mismo nivel de revisión. Si el conjunto de pruebas es demasiado limpio, el agente parecerá mejor de lo que será en producción.

1. Registra la mezcla actual de tickets durante un período de línea base. Hecho significa un recuento simple: tickets acotados, sesiones largas de terminal y tareas que necesitan revisión humana.
2. Registra la línea base antes de cambiar. Estás hecho cuando tienes una hoja con nombre de tarea, pasos de primera edición (mediana), carga de revisión y coste por tarea completada.
3. Compara las filas de benchmark con tu mezcla real. Termina con un veredicto breve. Para tickets acotados, las filas de FrontierCode y DeepSWE tienen el peso. Para trabajo de terminal hostil, la fila de Terminal-Bench 4 tiene el peso.
4. Calcula el precio de una tarea real, no de una demo. Hecho significa un número que puedas defender: coste por tarea real tras reintentos, ejecuciones fallidas y limpieza humana.
5. Decide antes de que termine la prueba. Estás hecho cuando tienes una nota escrita: mantener, descartar o mantener solo para un tipo de trabajo concreto.

La trampa es dejar que una sola fila de benchmark tome la decisión. Una fila fuerte puede ocultar un tipo de trabajo débil. Si tu cola son mayoritariamente tickets pequeños, el agente puede sentirse rápido y barato. Si tu cola son mayoritariamente sesiones largas de terminal, el mismo agente puede sentirse lento, frágil y caro tras la limpieza.

El cambio debería sobrevivir a tu cola real

Mantén el modelo de frontera para la fila que importa si tu trabajo son sesiones de terminal hostil. Usa SWE-2 para el tipo de trabajo donde la velocidad y el coste reportados se alinean con tus tareas reales. La documentación ausente significa que no deberías planificar un pipeline a medida a su alrededor hasta que existan esos detalles.

Escribe la decisión en lenguaje llano. Si lo mantienes, nombra el tipo de trabajo. Si lo descartas, guarda la hoja de línea base. Si el resultado es mixto, fija una fecha de revisión y un techo de coste. Haz que la prueba exija una decisión escrita antes de que termine.