Artículos
El techo de tu uso de la IA es tu ambición: cuatro dimensiones, velocidad, altura, profundidad y amplitud
Felix Rieseberg, líder de ingeniería de Anthropic, desglosa «ser más ambicioso con la IA» en cuatro dimensiones: velocidad, altura, profundidad y amplitud. Este artículo resume su enfoque y sus ejemplos, y suma 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, líder de ingeniería de Anthropic, cuenta en «How to be more ambitious: A tutorial for humans with models» que, cuando ve a otras personas lograr resultados asombrosos con la IA, él y la gente a su alrededor suelen tener la misma reacción: «No estamos siendo lo suficientemente ambiciosos».
Mi lectura es esta: el límite de lo que las personas hacemos con la IA muchas veces está 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 solo campo y buscar soluciones 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 atora#
Hacer el mismo trabajo en menos tiempo. Felix considera que esto ya le resulta familiar a todo mundo, y el artículo lo pasa de largo.
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 lograr 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 corriera de forma continua y automática, primero tuvo que cambiar su propio proceso: facilitar el acceso a los reportes de crash, relacionar las versiones de la app con los commits de Git y dejar que Claude usara equipos 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 advierte dónde está el límite: en 2026, una meta vaga 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 la industria realmente usa. Los modelos muchas veces solo cambian el vocabulario y no el método, y se quedan en aventar una tabla en Markdown. Insiste en herramientas de análisis reales, como bases de datos y modelos estadísticos.
- Fijar una meta que parezca poco razonable y decirle al modelo que sí tiene solución. Su ejemplo: después de bajar la carga de un sitio web de 10 a 5 segundos, pedir 200 milisegundos. Cuando el modelo se echa para atrás, insistir en que la meta es alcanzable.
- Cuestionar los supuestos en los que crees. Darle 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 todavía no conoces y validarla con datos que el modelo no ha visto.
- Buscar un juez externo (Outside Judge). No dejar que el modelo se califique a sí mismo. Lo ideal es conectar una herramienta que el modelo pueda ejecutar directamente y que le dé retroalimentación 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». Pídele 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 «lograr en 30 minutos que personas muy ocupadas entiendan la causa y el efecto y decidan en la incertidumbre». Si defines la meta con un verbo, ves qué capacidades de qué campos hacen falta.
- Armar 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 contador 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 una computadora 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 un pipeline pasivo 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 de la meta, 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 obligar 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)