Artículos
El techo de tu uso de la IA es tu ambición: cuatro dimensiones, velocidad, altura, profundidad y amplitud
Felix Rieseberg, responsable de ingeniería de Anthropic, desglosa «ser más ambicioso con la IA» en cuatro dimensiones: velocidad, altura, profundidad y amplitud. Este artículo recoge su enfoque y sus ejemplos, y añade mis notas de práctica: dar instrucciones orientadas a objetivos y coordinar un equipo de expertos de Multi-AI Agents para una revisión cruzada desde varias perspectivas que mejore la calidad del trabajo.
· 7 min de lectura
Felix Rieseberg, responsable de ingeniería de Anthropic, cuenta en «How to be more ambitious: A tutorial for humans with models» que, cuando ve a otras personas conseguir resultados asombrosos con la IA, él y la gente que le rodea suelen tener la misma reacción: «No estamos siendo lo bastante ambiciosos».
Mi lectura es esta: el límite de lo que las personas hacemos con la IA suele estar en nuestra propia ambición e imaginación, no en el modelo.
Desglosa la «ambición» en cuatro dimensiones:
- Velocidad (Speed): hacer el mismo trabajo en menos tiempo.
- Altura (Altitude): subir el nivel de abstracción y mirar el resultado final, no una tarea aislada.
- Profundidad (Depth): trabajar con los estándares, las herramientas y los métodos de los mejores expertos del campo.
- Amplitud (Range): salir de un único campo y buscar soluciones a caballo entre varias disciplinas.
Primero la conclusión: si das instrucciones precisas y orientadas a objetivos, y coordinas un equipo de expertos de Multi-AI Agents para colaborar desde varias perspectivas y hacer revisión cruzada, la calidad del trabajo sube en conjunto.
1. Velocidad: la más básica y en la que menos gente se atasca#
Hacer el mismo trabajo en menos tiempo. Felix considera que esto ya es muy familiar para todos y el artículo lo pasa por alto.
Mi opinión: la velocidad es el valor más evidente de la IA, pero si solo persigues velocidad, tu forma de colaborar no cambia mucho. Lo que de verdad marca la diferencia son las otras tres dimensiones.
2. Altura: pregúntate por «el objetivo detrás del objetivo»#
La pregunta clave: ¿cuál es el siguiente resultado que realmente quiero? ¿Cuál es el objetivo detrás del objetivo?
Los ejemplos de Felix:
- De arreglar un crash a conseguir que la app deje de fallar. Al principio le pedía a Claude que arreglara un solo crash; después pasó a pedirle que la app se mantuviera en cero crashes. Para que eso funcionara de forma continua y automática, primero tuvo que cambiar su propio proceso: facilitar el acceso a los informes de crash, relacionar las versiones de la app con los commits de Git y dejar que Claude usara máquinas con Windows, macOS y Linux para reproducir los fallos y verificar las correcciones.
- Una mejora en tres niveles de la revisión trimestral de negocio (QBR):
- Partir lo más posible de los datos en bruto y explicar qué cambió este trimestre, por qué y qué hacer a continuación.
- Identificar las 3 decisiones más urgentes y escribir los argumentos a favor y en contra de cada una.
- Diseñar un mecanismo alternativo que detecte los problemas antes que la presentación trimestral, probarlo con datos históricos y ejecutarlo en paralelo con el proceso actual durante un trimestre.
También avisa de dónde está el límite: en 2026, un objetivo difuso como «Claude, ve a ganar dinero por mí» todavía no funciona, pero espera que el nivel de abstracción que los modelos pueden manejar siga subiendo.
3. Profundidad: exigir las especificaciones de los mejores expertos del campo#
El método de Felix:
- Usar las herramientas que el sector usa de verdad. Los modelos a menudo solo cambian el vocabulario y no el método, y se quedan en soltar una tabla en Markdown. Insiste en herramientas de análisis reales, como bases de datos y modelos estadísticos.
- Fijar un objetivo que parezca poco razonable y decirle al modelo que tiene solución. Su ejemplo: tras bajar la carga de un sitio web de 10 a 5 segundos, pedir 200 milisegundos. Cuando el modelo se echa atrás, insistir en que el objetivo es alcanzable.
- Cuestionar los supuestos en los que crees. Dar al modelo los datos en bruto y contrastarlos desde un ángulo adversarial. Por ejemplo: «Creemos que la fuga de usuarios se debe al onboarding; intenta reproducir esa conclusión a partir de los datos en bruto».
- Generar conocimiento nuevo. Construir una simulación a partir de los Logs, encontrar la señal más temprana de abandono que aún no conoces y validarla con datos que el modelo no ha visto.
- Buscar un juez externo (Outside Judge). No dejar que el modelo se corrija a sí mismo. Lo ideal es conectar una herramienta que el modelo pueda ejecutar directamente y que le dé respuesta inmediata para verificar.
Su regla para los prompts: lo que se pide es una «versión más profunda», no una «versión más grande». Pide al modelo que diga qué haría de más un profesional de primer nivel, dónde están los datos más en bruto, qué métodos y herramientas usar y qué, aparte del modelo o de tu criterio, puede demostrar que el resultado es correcto.
4. Amplitud: verbos en lugar de sustantivos y un equipo de expertos#
- Verbos en lugar de sustantivos. Felix toma esta idea de The Art of Innovation. Más que «una presentación», una QBR es «conseguir en 30 minutos que personas muy ocupadas entiendan la causa y el efecto y decidan en la incertidumbre». Si defines el objetivo con un verbo, ves qué capacidades de qué campos hacen falta.
- Formar un equipo. Para una buena presentación, busca un analista, un periodista y un editor; para exponerla, suma un diseñador de movimiento y sonido. Para una revisión adversarial, recurre a un investigador de un fondo bajista y a un contable forense.
- No hagas juegos de rol sin sentido. No se trata de decirle al modelo «escribe con el tono de un fondo bajista», sino de que ejecute de verdad el método de una parte de la investigación de un fondo bajista. Cambiar solo el tono no mejora el resultado.
La condición previa: el modelo necesita un ordenador donde pueda instalar software y acceso a los datos pertinentes, por ejemplo mediante un conector MCP.
5. Mis notas de práctica: de «pasar datos» a «lograr la intención»#
Lo que sigue es una extensión mía que combina arquitectura de software y práctica de ingeniería; no forma parte del artículo original.
1. Jobs to be Done y orientación a la intención (Intent-Based)#
- No preguntes «qué hacer», pregunta «qué lograr». El diseño no debería quedarse en una canalización pasiva de paso de datos como
generate_deck_pdf(), sino subir a una intención de transición de estado como resolve_leadership_uncertainty_and_commit_budget().
- Define la función de pérdida real. Si solo pides un entregable, el modelo genera palabrería de apariencia perfecta; si pides resolver la incertidumbre de una decisión, el modelo y los Sub-agent tapan por iniciativa propia los huecos lógicos y los límites de riesgo.
2. Divergir al explorar, converger al validar#
- Al explorar, primero divergir para buscar posibilidades y luego converger.
- Al validar, no volver a divergir. Preguntas sin límites como «¿de qué otra forma se podría hacer esto?» solo traen respuestas genéricas.
- Escribe con claridad el alcance del objetivo, las restricciones y las herramientas de verificación objetivas (scripts de prueba concretos, umbrales de indicadores de negocio), para que el equipo de Multi-Agent haga pruebas de estrés dentro de un marco enfocado y entregue resultados de alta calidad.
Resumen de aprendizajes#
- Orientación a objetivos: verbos en lugar de sustantivos. Entregar el resultado que resuelve el problema, no un producto hecho solo para cumplir.
- Exploración y convergencia: al explorar, divergir para buscar posibilidades; al validar, converger con rigor y comprobar los límites.
- Enfoque de abstracción: partir de la pregunta clave y rediseñar todo el flujo de la tarea.
- Profundidad experta: no limitarse a imitar el tono de un experto, sino forzar al modelo a resolver el problema con las herramientas y los métodos de los mejores expertos.
Artículo original: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 13-10-2026)