00:00:00Ningún modelo de Claude es suficiente por sí solo. Opus tiene el razonamiento, pero agota tus
00:00:04límites. Sonnet es rápido, pero se bloquea ante decisiones difíciles. Y la respuesta no es elegir uno sobre
00:00:10el otro. Es usarlos todos juntos. Ahora, Claude Code ya hace esto hasta cierto punto.
00:00:14Orquestra entre modelos por su cuenta. Pero Anthropic acaba de lanzar algo que
00:00:18no solo ahorra tokens, sino que hace que los modelos pequeños sean casi tan capaces como los grandes.
00:00:23Ahora, al construir con Claude, puede que hayas notado esto. Siempre que le das una tarea a Opus
00:00:28y este determina que no requiere tanto esfuerzo, se la pasa a Sonnet o Haiku y
00:00:32delega tareas a los modelos más pequeños para gestionar el uso de tokens correctamente. Pero hay un problema
00:00:37con este enfoque. Como mencionamos en nuestro video anterior, Anthropic ha estado bajando los límites de uso,
00:00:42así que durante las horas pico tu ventana de 5 horas se llena más rápido. Y además, Opus consume muchos
00:00:47tokens incluso en tareas simples, lo que significa que usar Opus hace que tu límite de contexto se llene antes.
00:00:52Anthropic decidió cambiar las reglas del juego y lanzaron algo llamado la
00:00:55estrategia de Asesor. La forma en que funciona esta estrategia es que le das el rol de ejecutor al modelo
00:01:00Sonnet y usas a Opus puramente como un asesor al que solo se consulta cuando el ejecutor realmente lo
00:01:05necesita. Hay dos agentes involucrados. El ejecutor es tu agente principal que corre en Sonnet y maneja
00:01:10todas las llamadas a herramientas, cambios de código y resultados para el usuario. El asesor corre en Opus y su único
00:01:15trabajo es guiar al ejecutor cuando se queda atascado. El asesor nunca escribe código ni hace cambios.
00:01:20Cuando Anthropic experimentó con este enfoque, descubrieron que superaba a Sonnet solo en el
00:01:25SWE-bench. Vieron que esta combinación superaba a Sonnet solo tanto en rendimiento como en costo.
00:01:31Y cuesta significativamente menos que usar a Opus como agente principal porque Opus solo se invoca
00:01:36cuando realmente importa, no en cada iteración. Ahora, podrías pensar que ya
00:01:40tenemos muchos frameworks para crear apps que son mejores y están listos para usar, ¿así que por qué molestarse?
00:01:45La razón es que la mayoría de los frameworks existentes no están construidos pensando en el costo y la eficiencia.
00:01:50Aunque cumplen su función, se quedan cortos a la hora de hacer que Claude funcione por más tiempo
00:01:54y de forma más eficiente, porque se centran principalmente en crear la app en lugar de optimizar
00:01:59el uso de tokens. Con esta configuración, puedes crear una app funcional usando un modelo más débil, haciendo
00:02:04que todo el proceso sea mucho más eficiente en tokens. Y eso conecta con el problema de los límites que mencionamos
00:02:09antes. Ya hicimos un video sobre los límites de Claude y te dijimos que cambiaras a un modelo más pequeño
00:02:13para que durara más. Así es como se conecta. Sonnet consume muchos menos tokens y requiere menos esfuerzo
00:02:19que Opus para realizar la misma tarea. Opus es un modelo muy grande y potente, por lo que consume muchos
00:02:24tokens incluso para tareas sencillas. Sonnet puede manejar muchas de esas tareas de manera más eficiente. Así que
00:02:30usar a Opus solo para cerrar la brecha de rendimiento en decisiones difíciles es donde reside el verdadero impacto.
00:02:35Solo invocas esa potencia cuando realmente la necesitas, no para cada tarea. Esto hace que el
00:02:40uso general sea más eficiente en tokens y te permite hacer más dentro de los mismos límites. Compartimos
00:02:45todo lo que encontramos sobre la creación de productos con IA en este canal, así que si quieres más videos sobre eso,
00:02:50suscríbete y mantente atento a futuros videos. Quisimos probar cómo funciona esto en una
00:02:55app que ya estaba construida usando Sonnet. Para usar la estrategia dentro de Claude Code, configuramos el
00:03:00comando de asesor con Opus 4.6 como el modelo asesor. Nuestro agente principal era el ejecutor, que ya había
00:03:05establecido como Sonnet ya que construí la app usándolo. La app debía tener sincronización en tiempo real y mientras
00:03:10el movimiento y cambio de tamaño de elementos se sincronizaba perfectamente, el borrado no funcionaba. Intentamos
00:03:16depurar esto varias veces con Sonnet solo, pero el problema persistía sin importar cuánto
00:03:20intentara solucionar los fallos. Así que tras activar a Opus como asesor, le dimos a Claude el prompt
00:03:25describiendo el problema y, como Sonnet ya había fallado varias veces, en lugar de intentarlo
00:03:30de nuevo por su cuenta, decidió invocar al asesor esta vez. El asesor revisó la
00:03:34conversación hasta ese punto para evaluar la situación. Proporcionó los cambios exactos que debían hacerse,
00:03:40señalando dónde fallaba la lógica de sincronización y qué debía reestructurarse específicamente. El modelo ejecutor
00:03:45tomó ese consejo y aplicó los arreglos directamente sin más idas y venidas. Lo probamos
00:03:50en varios dispositivos para verificar la sincronización y vimos que el problema se resolvió. Ambos lados
00:03:55reflejaban los borrados correctamente, incluso si el usuario había seleccionado el ítem en un extremo y el
00:04:00otro se borraba, algo que no ocurría antes. Si hubiéramos intentado arreglar esto usando solo Sonnet,
00:04:05habría tomado más rondas de prompts porque Sonnet es intrínsecamente un
00:04:09modelo más débil y no es capaz de manejar lógica compleja por sí solo. Por otro lado, usar solo Opus
00:04:15habría consumido muchos más tokens y probablemente no habría sido tan rápido. Usar Sonnet con Opus
00:04:20como asesor hizo el proceso mucho más eficiente. En general, esta estrategia ayudó a depurar problemas de sincronización
00:04:25mucho más rápido que antes. Pero antes de seguir adelante, unas palabras de nuestro patrocinador Juni, de JetBrains.
00:04:30Si eres desarrollador, conoces la lucha de cambiar de contexto entre la terminal, el IDE y los pipelines de CI
00:04:36solo para terminar tareas. La mayoría de los agentes de programación te encierran en un entorno o un LLM específico.
00:04:41Juni CLI es diferente. Es un agente agnóstico al LLM que funciona en todas partes. Tu
00:04:47terminal, tu IDE, GitHub, pipelines de CI/CD, incluso tu gestor de tareas. Un agente en todas partes. Delégale
00:04:54trabajo real: escribir tests, construir backends, refactorizar o automatizar revisiones de código en cada commit.
00:04:59Ahora JetBrains ofrece un programa de acceso anticipado gratuito que incluye $50 en créditos de Gemini para probar el
00:05:04agente, además de soporte BYOK para que uses el modelo que prefieras. Acceso total a todas las funciones,
00:05:10acceso previo a novedades y soporte directo del equipo de desarrollo. Es simplemente mejor con Juni.
00:05:15Haz clic en el enlace del comentario fijado para unirte gratis. Ahora queríamos probar si Sonnet realmente
00:05:20consulta al asesor para cambios importantes en la interfaz. Teníamos una aplicación ya construida y queríamos
00:05:25transformar su interfaz a una librería diferente. Además, queríamos hacer múltiples cambios de UI de una
00:05:31sola vez, lo cual no se recomienda, pero queríamos ver cómo rinde el modelo pequeño coordinado
00:05:36con el grande en una tarea mayor. Primero accedió a la UI actual usando Playwright MCP.
00:05:41Una vez entendida la estructura, en lugar de ir directo al código, consultó al asesor
00:05:46para determinar el mejor enfoque porque era un cambio crítico y mayor que podría romper la app si
00:05:50se manejaba mal. El asesor reportó que la librería que elegimos y la que
00:05:55ya se usaba en el proyecto tenían problemas de versiones. Así que antes de empezar con la UI, Claude debía
00:06:00resolver esto primero. Sonnet lo manejó primero, ejecutó varios comandos para asegurar que las dependencias
00:06:04se aplicaran bien y luego revisó el estado de la UI mediante Playwright para confirmar que la app
00:06:09seguía funcionando correctamente sin errores del lado del cliente. Una vez resueltas las dependencias, empezó a hacer
00:06:14los cambios sugeridos por el asesor, trabajando componente por componente y rediseñando la
00:06:18app por completo de forma efectiva. La interfaz que creó era mucho más interactiva y se veía significativamente
00:06:23más pulida que antes. Aún tenía algunos problemas, pero la mejora general era clara. Pero aquí
00:06:27es donde aparecieron las limitaciones. Todo el proceso tomó unos 31 minutos. Opus por su cuenta lo habría
00:06:32hecho mucho más rápido porque es mejor orquestando tareas al identificar qué puede ejecutarse
00:06:37en paralelo y haciéndolo al mismo tiempo. Sonnet, al ser un modelo más pequeño, manejó todo de forma secuencial
00:06:43sin dividir el trabajo en sub-agentes paralelos. Para una app que ni siquiera era tan compleja,
00:06:4831 minutos es más de lo que debería. También maneja cambios pequeños por su cuenta sin
00:06:53involucrar al asesor, lo cual es el comportamiento correcto para ajustes menores. Pero para cambios a gran escala
00:06:58en toda una app como esta, es mejor usar Opus directamente porque eso te ahorrará significativamente
00:07:03más tiempo y esfuerzo. Ahora queríamos probar si implementaba una característica totalmente nueva en una
00:07:08base de código existente de forma adecuada. Teníamos una app ya construida y queríamos añadir otra página con una
00:07:13función diferente. Le dimos un prompt describiendo lo que queríamos y esta vez esperábamos totalmente
00:07:17que usara al asesor porque no era una tarea sencilla, pero siguió adelante e implementó
00:07:22los cambios enteramente por su cuenta sin consultar al asesor en absoluto. Lo trató todo como
00:07:27trabajo de implementación rutinario, lo cual claramente no era dado el alcance de la función. Cuando probamos la
00:07:31aplicación, encontramos múltiples problemas. Si modificábamos algo y pulsábamos el botón de ejecutar, cambios
00:07:37como actualizaciones de títulos o ajustes de color se reflejaban también en componentes fuera del panel de vista previa,
00:07:41lo cual no debería ocurrir. Además, queríamos que se sincronizara directamente en lugar de tener que pulsar
00:07:46ejecutar tras cada cambio. Así que le dimos otro prompt y le dijimos que usara al asesor para arreglar
00:07:51estos problemas. Ante nuestro prompt, primero invocó al agente asesor. El asesor analizó la
00:07:56implementación e identificó qué estaba causando realmente ambos problemas. Resultó ser una
00:08:00elección de componente errónea. Detalló qué debía cambiar y por qué el enfoque original había introducido esos
00:08:06problemas en primer lugar. El ejecutor tomó esa guía y la aplicó en toda la app. Cuando lo
00:08:10probamos de nuevo, el streaming funcionaba correctamente. Todos los cambios se reflejaban de inmediato al editar
00:08:16sin necesidad de pulsar ejecutar tras cada modificación. El problema de los cambios que se filtraban a otros componentes
00:08:20también se resolvió y todo se actualizaba correctamente dentro de sus límites. Así que hay veces
00:08:25en las que funciona exactamente como se espera, pero otras el ejecutor asume que la tarea es pequeña y
00:08:30decide no consultar al asesor. En esos casos, a menudo tienes que darle un empujón tú mismo para que siga
00:08:35el flujo de trabajo previsto. El modelo no siempre juzga la complejidad de una tarea de la misma forma que
00:08:40tú, y cuando juzga mal acabas con errores que el asesor habría detectado desde el principio. Además,
00:08:44si te gusta nuestro contenido considera pulsar el botón de Hype porque nos ayuda a crear más
00:08:49contenido como este y llegar a más gente. Con estados distribuidos en tiempo real de por medio, este
00:08:54enfoque todavía necesitó varias rondas de prompts antes de que todo funcionara correctamente.
00:08:58La estrategia ayudó, pero tiene un techo que deberías comprender antes de comprometerte con ella para un proyecto.
00:09:02Para aplicaciones de escala simple a media, la estrategia del asesor puede ahorrarte varias rondas
00:09:07de idas y venidas que de otro modo gastarías intentando llevar a Sonnet más allá de sus límites por sí
00:09:11solo. Si lo que estás construyendo requiere razonamiento profundo ocasional pero es principalmente una
00:09:16implementación directa, esta es una estructura genuinamente buena. Puedes construir más dentro de tus límites de tokens
00:09:20sin tener que vigilar al modelo en cada decisión o recurrir a Opus para toda la sesión.
00:09:25Para apps complejas con muchas dependencias conectadas o múltiples puntos de fallo, es mejor simplemente
00:09:30usar a Opus directamente como tu agente principal. Incluso cuando Sonnet sigue la guía del asesor correctamente,
00:09:36aún puede elegir el camino de implementación equivocado porque no tiene la profundidad de razonamiento para
00:09:40evaluar múltiples enfoques a la vez y sopesar las consecuencias posteriores. El asesor ayuda a cerrar
00:09:45esa brecha, pero no la cierra del todo. En esos casos, las idas y venidas pueden costarte más tiempo
00:09:50del que habría costado usar Opus desde el principio. Así que esta estrategia es útil cuando trabajas con
00:09:54límites ajustados de tokens y la aplicación no requiere un nivel de razonamiento de Opus en cada paso. Si
00:09:58ambas condiciones se cumplen en lo que estás creando, vale la pena configurarlo. Esto nos lleva al
00:10:03final de este video. Si quieres apoyar al canal y ayudarnos a seguir haciendo videos como este,
00:10:08puedes hacerlo usando el botón de Super Thanks abajo. Como siempre, gracias por vernos y los
00:10:12veré en el próximo.