El miércoles 14 de octubre, en la inauguración del hackatón AWS Breaking Barriers Chile 2026, alguien de AWS dijo la frase que cambió el experimento: acceso ilimitado a Kiro, a su SDK, y tokens ilimitados para prácticamente todos los modelos del catálogo — OpenAI, Anthropic, los de frontera. Sin cuota. Sin tarjeta. Sin contar tokens.
En la sala había más de veinticinco equipos. Y durante los siguientes tres días, la mayoría hizo lo previsible: abrió los modelos más caros que existen. GPT-6. Claude Opus 5.5. Lo mejor de lo mejor, porque era gratis. Incluso mis propios compañeros de equipo optaron por esos modelos.
Yo abrí mi laptop y seguí usando Shiva, mi propio harness, con DeepSeek. Una versión que ni siquiera era la última. Un modelo que, en el mercado, cuesta una fracción de lo que cuesta el tope de gama.
Tres días después, ese sistema quedó segundo entre más de veinticinco equipos.
Este artículo no es la crónica de ese podio —eso ya lo contamos en las tres crónicas del hackatón—. Es el análisis de lo que ese resultado significa, porque creo que es el dato más importante que hemos producido en el año: cuando el acceso al modelo se vuelve ilimitado para todos, el modelo deja de explicar nada. Y lo único que queda en pie es la arquitectura que lo rodea.
1. El recurso escaso se mudó. Durante años la ventaja fue tener acceso al modelo de frontera. En ese hackatón el acceso fue regalado e ilimitado. Cuando el recurso escaseaba, la excusa era el presupuesto; cuando se regaló, la excusa desapareció.
2. El default es el más caro. La mayoría de los equipos —y mis propios compañeros— eligieron GPT-6 y Claude Opus 5.5. No porque hubieran medido que eran necesarios, sino porque estaban disponibles y eran "lo mejor". Lo caro es el default emocional.
3. Un modelo barato + un harness propio compitió de tú a tú. No ganamos por el motor. Ganamos porque el sistema sabía el problema, recordaba el contexto y verificaba el resultado.
4. Y la implicación incómoda: si el modelo es gratis para tu competencia también, entonces el modelo no es tu ventaja ni tu excusa. Es el terreno, no el jugador.
El aviso de rigor, que en este artículo es más importante que nunca: esto no fue un experimento controlado. No audité el código de los otros equipos ni sus resultados internos. Lo que sí sé con certeza es (a) qué modelos eligieron —se veía en las pantallas—, (b) que el acceso era ilimitado para todos, y (c) el ranking final. Todo lo que voy a afirmar se sostiene en eso. Donde interpreto, lo digo. Donde no sé, también.
1. Lo que AWS puso sobre la mesa (y por qué cambió el experimento)
Un hackatón normalmente tiene un sesgo escondido: el que puede pagar, prueba más. El acceso al modelo de frontera ha sido, durante dos años, la ventaja competitiva más aburrida y más real del mercado: el que tiene presupuesto para Opus no compite con el que tiene que usar un modelo chico.
AWS eliminó esa variable de un plumazo. Kiro, su SDK y tokens ilimitados sobre prácticamente todo el catálogo frontier. Nadie en esa sala podía decir "no tuve acceso". Nadie podía decir "me faltó cuota". El techo técnico era el mismo para todos, y estaba muy alto.
Cuando igualas el acceso al modelo entre todos los competidores, lo que queda no es una competencia de inteligencia: es una competencia de criterio. ¿Qué construyes con el mismo motor que todos? ¿Cuánto contexto útil le das? ¿Cómo verificas que no alucina? ¿Cuánto tarda, cuánto cuesta y qué pasa cuando falla?
Esas preguntas no las contesta el modelo. Las contesta el harness.
2. La decisión: no cambiar de cerebro a mitad de carrera
Cuando cayó la noticia del acceso ilimitado, hubo un momento de duda razonable: "¿y si me cambio a Opus? Total, es gratis, es mejor". Es la decisión que tomó casi todo el mundo. Yo no la tomé, y quiero explicar por qué, porque no fue por romanticismo ni por terquedad.
Porque el trabajo no era el modelo. A esa altura, mi harness ya tenía cosas que ningún modelo te da al conectarte:
• Memoria del problema: notas de sesión, un grafo de conocimiento y el contexto del desafío, acumulados durante semanas.
• Procedimientos: skills reutilizables —cómo escribimos, cómo validamos, cómo desplegamos— que no había que reexplicar.
• Verificación: pruebas, criterios de aceptación y un humano en el loop que aprueba o rechaza.
• Portabilidad: el sistema estaba construido para que el modelo fuera una pieza reemplazable, no el fundamento.
Cambiar de motor a mitad de la carrera no te hace ganar: te hace entrar a boxes. Y en un hackatón de 72 horas, entrar a boxes es la forma más elegante de perder tiempo que existe.
No usé "el modelo barato" como limitación ni como excusa. Lo usé como condición de diseño: si el sistema funciona con un motor de una generación anterior, entonces el sistema es robusto. Y si mañana me dan Opus, el harness no cambia — solo mejora. Esa es la diferencia entre tener una arquitectura y tener una dependencia.
3. Lo que eligió la sala: el default es el más caro
Vale la pena detenerse en esto porque es un patrón de mercado, no una anécdota de hackatón. En esa sala, con acceso ilimitado a todo, la mayoría eligió los modelos más caros del catálogo: GPT-6, Claude Opus 5.5. Incluidos mis compañeros de equipo.
| Dimensión | La elección mayoritaria | Nuestra elección |
|---|---|---|
| Modelo | GPT-6 · Claude Opus 5.5 (tope de gama) | DeepSeek, una versión anterior a la última |
| Costo por token | El más alto del catálogo | Una fracción del anterior |
| Razón de la elección | "Es lo mejor y es gratis" | "Es el motor de un sistema que ya sé que funciona" |
| Qué aportaba la ventaja | El modelo | El harness: memoria, procedimientos, verificación |
| Resultado | — | 2° lugar entre +25 equipos |
¿Por qué el default es el más caro? Por tres razones que no tienen nada de técnicas: miedo (no quiero que me falte capacidad), marketing (el nombre del modelo es la señal de status) y pereza (elegir el más caro no requiere pensar). Y funciona, en el sentido de que nadie te va a criticar por elegir Opus. Nadie te va a criticar por sobre-ingeniería cuando el token es gratis.
No sé qué resultados internos obtuvieron los otros equipos, ni si su código era mejor o peor que el nuestro. No comparamos benchmarks entre equipos ni medimos tokens ajenos. Lo único que comparo aquí es una elección de modelo muy distinta y un resultado final medible: el ranking. Cualquier conclusión más fina que eso sería invento.
4. Qué demuestra el resultado (y qué no)
Voy a ser quirúrgico, porque este es exactamente el tipo de dato que se suele vender de más.
Lo que SÍ demuestra: que un modelo de una generación anterior, montado sobre un harness con memoria y verificación, puede competir de tú a tú contra equipos que usan el estado del arte del catálogo — y llegar al podio. Es decir: la capacidad efectiva de un sistema no es la capacidad bruta de su modelo.
Lo que NO demuestra: que el modelo no importe, ni que DeepSeek sea superior a Opus o a GPT-6. En tareas de razonamiento puro, matemática dura o generación de código complejo desde cero, el modelo de frontera gana, y negarlo es mentir. Lo que este resultado demuestra es más específico y más útil: en problemas reales —con datos sucios, reglas de negocio, memoria y verificación— la arquitectura domina sobre el motor.
| Concepto | Qué mide | Quién lo determina |
|---|---|---|
| Capacidad bruta | Lo que el modelo puede hacer en el vacío | El proveedor del modelo. No la controlas |
| Capacidad efectiva | Lo que tu sistema resuelve con contexto, herramientas y verificación | Tu arquitectura. Es tuya |
En un hackatón —y en producción— no compites con capacidad bruta. Compites con capacidad efectiva. Y esa se construye.
5. La trampa de los tokens ilimitados
Hay una consecuencia de tener tokens infinitos que casi nadie menciona en voz alta: lo ilimitado esconde la ineficiencia. Si tu arquitectura reenvía 40.000 tokens de contexto en cada turno, el fin de semana no te importa. Pero en producción, ese mismo diseño es la diferencia entre un proyecto rentable y uno que no se puede sostener.
El eje real deja de ser "cuántos tokens gasto" y pasa a ser costo, latencia y confiabilidad por resultado entregado. En un post anterior documentamos cómo nuestro harness sostiene turnos de 142.000 tokens con 98,99% servidos desde caché: la palanca no fue un modelo más barato, fue no reenviar lo mismo cada vez. Eso es diseño, no presupuesto.
Nunca diseñes como si el token fuera gratis. Aunque te lo regalen. Porque el día que te lo cobren —y te lo van a cobrar— la arquitectura que sobrevive es la que ya estaba optimizada cuando no hacía falta.
6. Por qué esto no es RLHF ni fine-tuning (aunque parezca)
Cuando digo "la ventaja está en el harness y la memoria", la respuesta automática es: "entonces hay que afinar el modelo". No. Son cosas distintas, con costos distintos y riesgos opuestos — y en este hackatón lo comprobamos con datos propios.
| Dimensión | Fine-tuning / RLHF | Harness + memoria |
|---|---|---|
| Qué cambia | Los pesos del modelo | El contexto, las herramientas y las reglas |
| Qué aprende | Estilo, formato, sesgos de tarea | Hechos, relaciones, historia, decisiones |
| Costo | GPU, datos etiquetados, ciclos de evaluación | Almacenamiento + recuperación |
| Reversibilidad | Difícil: el "olvido catastrófico" borra lo anterior | Total: borras el registro y listo |
| Auditabilidad | Baja: ¿por qué respondió así? Nadie lo sabe | Alta: la evidencia está guardada y es citable |
| Sirve si cambias de modelo | No: el trabajo se pierde | Sí: el harness es agnóstico al motor |
Y el dato incómodo del día 1: quisimos afinar "el modelo de moda" para nuestra tarea y lo empeoramos. En nuestro benchmark interno sobre 300 notas sintéticas, el modelo afinado rindió 0,137 frente al 0,507 del base. El ensamble con memoria y reglas, sin tocar un solo peso, llegó a 0,940.
Esas cifras son de nuestro benchmark interno sobre 300 notas sintéticas. No son un paper ni un estándar de industria. Lo robusto es la dirección: en nuestra tarea, el ajuste fino degradó y la arquitectura de contexto compuso. Si alguien te vende lo contrario como ley universal, pídele su benchmark.
7. Cómo se audita un harness (seis métricas, no una)
Si el harness es lo que diferencia, entonces necesitas métricas que no sean "el modelo respondió bien". Estas son las seis que usamos para auditar la capa que de verdad decide:
| Métrica | Qué mide | Por qué importa |
|---|---|---|
| Procedencia | % de registros con fuente, autor y fecha | Sin esto no hay auditoría posible |
| Tasa de contradicción | Registros que se contradicen sin regla de precedencia | Principal generador de respuestas seguras y falsas |
| Cobertura | % de casos con evidencia asociada | Mide si el sistema puede citar o solo opinar |
| Latencia de recuperación | Tiempo hasta traer el contexto correcto | Una memoria lenta es una memoria que se apaga |
| Ratio humano/agente | % de memoria escrita por humano vs por agente | Es tu control de calidad real |
| Exportabilidad | ¿Puedes llevarte todo, en abierto? | La métrica de soberanía. La más ignorada |
Ninguna de estas seis se resuelve eligiendo un modelo más caro. Todas se resuelven diseñando.
8. La pregunta que queda: ¿y cuando el modelo sea gratis para tu competencia también?
Ese hackatón fue un adelanto de lo que viene. Hoy pasa en una sala de la Universidad de Chile con 200 personas; mañana pasa en tu industria, cuando el proveedor de turno baje los precios, incluya el modelo en la suscripción o lo regale para ganar cuota. El acceso se está democratizando rápido, y con él desaparece la última excusa cómoda.
Cuando eso pase, la pregunta que te van a hacer no va a ser "¿qué modelo usas?". Va a ser "¿qué puedes hacer tú que tu competencia —con el mismo modelo— no pueda?". Y la respuesta va a estar, completa, en la arquitectura: qué recuerdas, qué verificas, qué automatizas, qué puedes auditar y qué puedes llevarte.
Por eso la última pregunta, la que nos importa como empresa, sigue siendo la misma de siempre: ¿de quién es lo que tu sistema recuerda? Si tu memoria vive en el SaaS del proveedor, tu ventaja es alquilada — y el día que te suban el precio, descubrirás que nunca fue tuya. Es el mismo argumento que hicimos sobre los productos de memoria que no te devuelven el control de tu conocimiento.
Nosotros quedamos segundos con un motor de una generación anterior y un harness propio. No lo cuento para presumir de un trofeo: lo cuento porque es la prueba más limpia que tenemos de que el modelo es el terreno, no el jugador. Y de que si mañana el modelo es gratis para todos, el juego que queda es el que ya estábamos jugando.
El valor no está en el modelo: está en el problema resuelto.
Si estás llevando IA a un proceso donde el error se paga —niños, salud, beneficios, dinero— y necesitas que el sistema recuerde con evidencia y no solo que responda con fluidez, conversemos 30 minutos. Te decimos qué capas necesitas, cuáles puedes omitir y cómo se audita.
Hablemos 30 minutos →