El método de programación con IA de “correa corta” que vence a Fable

• Para usar agentes de programación con IA en software crítico para la seguridad, hace falta un enfoque de correa corta, en el que el desarrollador mantiene el control continuo de los cambios, en vez de delegarles una ejecución autónoma.
• Un enfoque estilo “vibe”, donde varios agentes crean y revisan código en paralelo, puede debilitar la comprensión del codebase y hacer que los problemas se descubran recién después de que la IA se salió off the rails.
• El procedimiento central va desde la planificación, la descomposición en etapas, la revisión del diff en los prompts de permisos, rechazos e intervenciones frecuentes, commits por subtarea, hasta una revisión final.
• En las revisiones de PR hay que usar IA y humanos en conjunto para reducir errores: la IA detecta rápido fallas comunes, y los humanos juzgan problemas de más alto nivel y la dirección general.
• Los PR en los que participó la IA deben ser revisados línea por línea por quien los envía, y deben ganar confianza indicando en la descripción del PR el modelo usado como AI Disclosure.

---

Premisas para usar agentes de programación con IA

• Este método se basa en la experiencia de usar agentes de IA para crear software de alta calidad en sistemas críticos para la seguridad.
• Está dirigido no a desarrolladores principiantes que deberían ver la IA como enemiga del aprendizaje, sino a desarrolladores expertos que, en su propio dominio de especialización, superan a los “frontier AI models”.
• El objetivo es usar la IA como herramienta para mejorar el rendimiento sin sacrificar la calidad del software.
• El alcance de la experiencia incluye explorar las limitaciones de los agentes de IA, crear herramientas propias de revisión con IA y mantener un fork personalizado de Crush, un agente de programación con IA.

Dónde tambalea el enfoque estilo “vibe”

• En las sesiones en las que se usan agentes de IA, pueden aparecer con frecuencia dos problemas:
  • La idea inicial es mala y recién más tarde se descubre que había un enfoque mejor.
  • El agente se sale off the rails en una dirección no deseada.
• Si varios agentes en paralelo y un orquestador trabajan al mismo tiempo, y el desarrollador queda fuera del proceso de programación, se vuelve difícil construir una comprensión directa del codebase.
• En situaciones donde la calidad no importa, este método puede estar bien, pero cuando la calidad es importante hace falta otro enfoque.
• El código escrito o revisado por Fable 5 puede funcionar, pero aun así ser ineficiente y feo.
• En nichos donde el modelo tiene pocos datos de entrenamiento de los que depender, estos problemas pueden ocurrir con más frecuencia.
• A diferencia del marketing de ciertos CEOs, desde este punto de vista los modelos no pueden razonar más allá de sus datos de entrenamiento.

Cómo funciona el método Short Leash

• El método Short Leash no es algo que cualquiera pueda usar; está orientado a desarrolladores de software expertos.
• Su ventaja es que puede lograr resultados que vencen a Fable incluso sin usar un frontier model.
• Antes de trabajar, en la etapa de planificación se investiga la tarea y se arma un plan.
  • Las tareas grandes se rastrean y se dividen en etapas con herramientas como tasks skill.
  • Esta parte tiene puntos en común con varios métodos de “vibe engineering”.
• Después, lo central es mantener a la IA siempre con correa corta.
  • No se usa el modo “YOLO” ni “dangerously skip permissions”.
  • No se deja que la IA trabaje sola mientras el usuario juega.
  • Se usa un agente de programación que, en los prompts de permisos, muestra el diff de los cambios que se van a aplicar.
  • El desarrollador analiza de verdad los cambios que propone la IA.
  • Con el diff del prompt de permisos, mantiene al día su comprensión del codebase y controla a la IA.
  • Si la IA intenta hacer algo no deseado, se rechaza el permiso.
  • Se interviene con frecuencia cuando hace falta para evitar que la IA pierda el rumbo.
• Cada vez que termina una subtarea, se crea un commit para impedir que la IA arruine o elimine trabajo previo.
  • Esto puede pasar en la práctica, y se han visto casos en Opus.
• En la etapa final se realiza una revisión.

La revisión con IA no reemplaza la revisión humana

• En comparación con PR revisados solo por humanos o solo por IA, los PR revisados por humanos e IA en conjunto pueden reducir más los errores.
• La IA puede tratarse como un linter.
  • Detecta rápido errores comunes.
  • Los humanos juzgan problemas de más alto nivel y la necesidad de cambiar de dirección.
• Se recomienda que todos los PR pasen por una revisión con IA.
• Las revisiones con IA necesitan suficiente contexto.
  • Issue
  • Descripción del PR
  • Codebase
  • Cambios
• Para la revisión se recomienda usar el modelo más reciente disponible.

AI Disclosure y responsabilidad de quien envía el PR

• Si se usó IA para escribir un PR, en la sección AI Disclosure de la descripción del PR se debe revelar el modelo exacto utilizado.
• Esta divulgación tiene varios propósitos.
  • Informar a los mantenedores que se usó IA.
  • Permitir que sugieran un modelo mejor si se usó uno débil.
  • Señalar que no se está intentando colar IA a escondidas.
• Todo PR que use IA debe ser revisado directamente por la “persona autora” del PR.
• Un PR asistido por IA en realidad se parece más a un PR de una IA con ayuda humana, por lo que quien lo envía debe entender lo que está enviando.
• Quien envía el PR debe mirarlo como si fuera el PR de otra persona y revisarlo directamente line-by-line.
• Después de terminar la autorrevisión, puede confirmar su aprobación y solicitar la revisión de los mantenedores.
• Este proceso sirve para crear y demostrar que quien envía el PR entiende el codebase.

Cómo lo aplica okTurtles

• okTurtles usa la IA con este método.
• La política oficial está resumida en AI Usage Policy.
• El texto en sí fue escrito por una persona e incluye un AI Disclosure que indica que, antes de publicarlo, solo se realizó una corrección ortográfica con estilo de IA.

[GN⁺]

Opiniones en Hacker News

• Este enfoque de “correa corta” parece más una muleta que una herramienta de apoyo, y da la impresión de que desde el principio no se le explicó lo suficiente el problema a la IA, o de que no se revisó ni se iteró sobre el resultado.
  Llevar de la mano a un modelo potente como Fable durante la etapa de implementación es una pérdida de tiempo y un desperdicio de Fable. Mientras más fuerte es el modelo, más sutiles pueden ser las discusiones de diseño, y escribe código mucho mejor que antes. El proceso mismo de discutir el diseño y la implementación, preguntar por las partes que se ven raras y leer de verdad las respuestas de la IA ayuda a encontrar mejores soluciones.
  Hace un tiempo, mientras intentaba crear una solución con un algoritmo voraz, en una conversación con Opus me sugirió que el problema podía resolverse con precisión usando una biblioteca MILP existente; yo ni siquiera había oído hablar de MILP, pero la implementación final quedó mejor y más simple que si la hubiera hecho solo.

  • Dicen que con modelos fuertes se pueden tener discusiones más sutiles, pero cuando le pregunté a Claude por qué había hecho un cambio pequeño que no entendía, me respondió que había “razonado desde primeros principios” basándose en la ruta del código.
    Pero no funcionaba, y cuando le pedí que explicara ese paso de razonamiento desde primeros principios, respondió que en realidad simplemente se lo había inventado. Por eso me cuesta creer en eso de las discusiones sutiles con el modelo.
  • En general estoy de acuerdo.
    Si invertiste lo suficiente en la etapa de planificación y la arquitectura y las convenciones existentes del proyecto son sólidas, quizá no haga falta tanta supervisión en la etapa de implementación como se plantea aquí.
    Eso de que “la idea inicial era tonta y puedes descubrir que hay una forma mejor” normalmente se descubre a alto nivel en la etapa de planificación y arquitectura.
    El problema de que el agente se “descarrile” hacia una dirección no deseada tampoco es tan grave como antes, y para cambios con impacto debería haber al menos una cobertura mínima de pruebas. Incluso si esas pruebas solo sirven para “fijar” el comportamiento implementado. La discusión final de revisión es una buena oportunidad para comprobar cosas más allá de lo que haya encontrado una revisión o un agente de revisión adversarial.
  • Me cuesta un poco entender exactamente con qué parte estás en desacuerdo. Leer las respuestas de la IA y revisar el código, al final, me parece el mismo enfoque.
    El ejemplo de MILP no es algo que este enfoque impediría, y habría salido a la luz en la etapa de planificación.
    Al final, los detalles importan, y la forma en que das el prompt al iniciar la tarea influye. Aun así, es indispensable verificar el resultado, involucrarse en lo que hace el modelo y preguntarle insistentemente por qué quiere hacerlo de esa manera.
  • El artículo se siente como micromanagement de la IA. Si lo piensas como un empleado junior, mediante micromanagement puedes lograr que haga lo que quieres de la forma que quieres.
    Pero las ideas de ese empleado no llegan a la mesa, y también desaparecen aportes que a largo plazo podrían beneficiar a todo el equipo.
  • Yo lo uso de esta manera.
    Me permite entender todo lo que se genera y mantener continuamente un conocimiento operativo de la base de código. También puedo hacerlo cambiar de dirección con facilidad.

• Hice esto durante 2 semanas en un proyecto personal, pero al final terminé sin un modelo mental de la base de código.
  Me convencí aún más de que no hay forma de construir ese modelo sin hacerlo uno mismo.

  • Lamentablemente, tuve el mismo problema incluso antes de la IA.
    Por la curva del olvido, mi modelo mental no dura mucho más que el periodo inicial en que lo construí. Todavía no he descubierto cómo reconstruirlo.
  • Si fueras gerente de un proyecto grande, ¿cómo construirías ese modelo? Me refiero a una situación en la que, por tu puesto, necesitas entender todo el proyecto, pero en realidad no tienes que escribir ni revisar mucho código.
  • Puedes pedirle al modelo que te explique el código.
  • No estoy seguro. Creo que es posible, pero tienes que profundizar deliberadamente en las partes que no entiendes; esa es la pauta.
    Dicho eso, sí estoy de acuerdo en que no se desarrolla tan bien la “capacidad de construirlo yo mismo” como cuando lo escribes directamente.
    Por ejemplo, sé qué cambio tendría que hacer para lograr cierto efecto, y cuando de hecho lo hago obtengo el resultado esperado, así que sé que mi modelo mental funciona. Pero si tuviera que construir algo parecido desde cero, no creo que pudiera. Se siente como si el enfoque estuviera fuera de mi alcance, aunque es difícil de explicar.
  • La revisión de código me funciona bien.

• Pensé que cualquiera que realmente supiera programar usaba así la IA para cosas importantes.
  ¿Estoy equivocado? ¿Ahora todos simplemente la corren en modo YOLO?

  • Sí. Tengo una laptop que no me preocupa, y dejo que Claude toque lo que quiera dentro de WSL.
    Es la diversión del funemployment. Cuando vuelva a trabajar, creo que será un cambio bastante interesante.
    Por ahora lo dejo corriendo y, mientras tomo cerveza, paso como una hora ajustando críticas de alto nivel y retroalimentación de autoevaluación/bucle cerrado, y luego lo dejo volver a hacer lo que quiera. Es simple.
  • ¿Con “modo YOLO”, o sea “saltarse permisos de forma peligrosa”, te refieres a no usar eso?
    Me da curiosidad cómo usan Claude de otra forma que no sea con bypass-permissions. He intentado mantener durante mucho tiempo una lista de herramientas que Claude puede usar, pero una y otra vez, cuando volvía, se había detenido diciendo que intentó canalizar la salida de una herramienta a otra y que no estaba explícitamente permitido. Era algo tan simple como grep, pero que se detuviera igual era frustrante.
    Con bypass-permissions “simplemente funciona”. Claro, solo lo uso para analizar código existente y proponer cambios; si algo se rompe, para eso existe el control de versiones.

• En general estoy de acuerdo con el autor. Sobre todo, agregaría: no confíes en nada de lo que haga o diga un LLM.
  Hoy le pedí a Claude que unificara el comportamiento de 3 componentes, y se lo pedí 5 veces. Cada vez, al final, todavía había partes que no coincidían, y Claude encontraba una forma de racionalizarlo.
  Cuando le preguntaba, respondía “es mi responsabilidad” o “pensé que era una decisión intencional”, pero ni una sola vez preguntó primero qué tenía que hacer ni señaló el problema. Así que hay que mantenerlo con correa corta, ver su proceso de pensamiento y corregir las tonterías. Esto es con Sonnet 5 al día de hoy; mañana podría mejorar o empeorar. La forma de hablarle a Claude que funciona hoy puede dar resultados distintos mañana.

• El problema con los artículos del tipo “cómo hacer X con IA” es que cada situación es completamente distinta. Por ejemplo, en un proyecto Symfony, subir de 3.1 a 8.1 tiene una ruta clara.
  Hay que seguir las guías de migración escritas para cada versión mayor y probar todas las rutas, flujos de autenticación, etc. Esas pruebas también se pueden seleccionar manualmente, y algunas pueden devolver 200 y otras 302.
  Opcionalmente, se puede escribir primero una red de seguridad para reducir las pruebas manuales y, por ejemplo, establecer una línea base de PHPStan.
  Si las rutas funcionan de extremo a extremo como se pretendía, eso es todo. Aquí también se pueden usar pruebas de snapshot.
  En estos casos no hace falta vigilar a la IA. Al final se puede revisar el código, pero no hay que aprobar manualmente cada paso intermedio, así que desactivo las funciones de seguridad.

  • Más que un problema de los “cómo hacer X con IA”, se parece a la forma en que se consume contenido de internet.
    La mayoría escribe desde un solo punto de vista, pero los puntos de vista reales son amplios, y lo que funciona en una situación no funciona en otra. En última instancia, toda la ingeniería de software se parece a tratar de entender qué aplicar, dónde y cuándo, e ignorar el resto.
    Muchas publicaciones de blogs corporativos te hacen creer que existe una bala de plata que funciona en todos los casos, pero normalmente no es cierto.
    Al final, como siempre ha ocurrido en ingeniería de software, se trata más bien de “ciertas cosas funcionan en ciertas situaciones”; no es tanto una cuestión de correcto o incorrecto, sino de que la aplicación práctica varía según el contexto, y eso es normal.
  • ¿Probaste rector?

• La IA está más o menos al nivel de un ingeniero junior a intermedio. Si la tratas así, puedes obtener tanto las ventajas del vibe coding como las de la ingeniería rigurosa sin toda esta paranoia.
  Desde el principio ejecuté Claude en modo YOLO dentro de una VM aislada. Es como darle a un ingeniero su propia laptop. Claude lleva una funcionalidad hasta un punto en que se puede hacer un PR, y yo reviso el diff como lo haría con otro ingeniero, luego lo dejo con la forma adecuada y sigo adelante.
  Un ingeniero inmaduro comete los mismos errores. He visto rm -rf, aunque no desde la raíz. Si hubiera micromanageado a alguien negándole todos los permisos, creo que me habría vuelto loco.

  • Estoy muy de acuerdo con este punto de vista, y por eso este artículo me resulta aún más difícil de entender. ¿Acaso el PR ya no es la puerta de entrada? No me importa lo que haga el agente dentro del espacio de trabajo, siempre que la contribución esté mediada por el repositorio git y el desarrollo no requiera algún acceso raro a producción.
    También estoy de acuerdo con la analogía del ingeniero junior/intermedio, pero con una gran salvedad. La IA es como un ingeniero junior que no sabe aprender.
    Es como trabajar con el protagonista de Memento. Cada día, cuando el LLM llega a trabajar, no ha aprendido nada del trabajo hasta ese momento, y todos los días son su primer día.
    Claro que, como con el protagonista de Memento, puedes ayudarlo repartiendo post-its y recordatorios por todo el espacio de trabajo. Con esfuerzo se puede acercar a algo parecido al “aprendizaje”, que es literalmente la característica más importante para todos los desarrolladores de software de un equipo.
    Pero no es fácil y las herramientas todavía son insuficientes. Lo mejor que he logrado es algo parecido a un “segundo cerebro” usando herramientas como Obsidian. Tristemente, creo que un segundo cerebro no reemplaza al primero. Sinceramente, si un ingeniero no pudiera aprender y crecer, como un agente de IA, lo habrían despedido después del primer mes en cualquiera de las empresas donde he trabajado.
    Aun así, soy bastante optimista de que los principales proveedores de IA, o alguien, mejorarán esto en el futuro. Si se combina una buena memoria con un sistema de razonamiento bien diseñado que inyecte mejor los recuerdos según el contexto, y si se puede capturar aprendizaje real sin supervisión, no parece una tarea imposible.
    Leo este tipo de artículos con la esperanza de que alguien ya haya resuelto este problema y yo simplemente me esté enterando tarde, pero por ahora solo he mejorado un poco mi capacidad de diseñar agentes respecto del inicio.
  • Mi experiencia es la misma. Yo lo veo más como un pasante muy inteligente y rápido. Se nota que llegará lejos y en muchos aspectos ya es mucho mejor que yo, pero todavía necesita que una mano experta le marque la dirección.
    Mi regla práctica es que cualquier proceso especial creado para la IA también debería tener sentido para las personas; si no, no vale la pena. Buenas herramientas de línea de comandos, resúmenes automáticos de salidas largas de comandos, documentación en Markdown y workflows también son útiles para las personas.
    Para prevenir errores y abusos, hay que usar sandboxes y permisos de alcance limitado, no micromanagement.
    Lo que quiero descubrir es un buen workflow de pair programming con agentes de IA. Puedo darle una tarea grande a un modelo de alto rendimiento y eso funciona bien. También puedo usar un modelo de bajo nivel como asistente en el IDE y eso también funciona bien. Pero son workflows separados.
    Lo realmente útil sería construir junto con un modelo de alto rendimiento, pasándonos el teclado. Pero no debería ejecutarse en modo YOLO total en mi máquina. Esa es la diferencia entre un humano y un LLM. Como es demasiado rápido, cuando se sale del camino es difícil arrebatarle de nuevo el teclado.
  • Si le das a Claude una laptop de verdad, también puede arreglar los problemas de audio Bluetooth en Linux ;)
  • ¿Qué VM/provisioning estás usando?
  • Decir que “la IA está al nivel de un ingeniero junior a intermedio” ya no es cierto, y engañarse con eso no ayuda.
    Nadie sabe exactamente qué es la IA, pero no es un ingeniero junior ni intermedio. Se parece más a un staff engineer nuclear que vive en una casucha, sin contexto de dominio y que despierta cada 5 horas sin memoria.

• Los LLM siguen siendo predictores del siguiente token. Que logren encontrar los pasos correctos aunque les des instrucciones más ambiguas no significa que sean inteligentes. Significa que estás hablando el mismo lenguaje que el arnés usado para entrenar el modelo.
  Y eso tiene límites. Si te quedas en pruebas de concepto o apps simples, quizá no notes lo limitados que siguen siendo los modelos actuales. En esos casos hay que dividir el trabajo, no confiar en un predictor de tokens que enumera pasos plausibles.
  En algún lugar tiene que haber necesariamente un humano en el circuito. Si empiezas a saltarte permisos, en el mejor de los casos te va de maravilla, pero lo más probable es que obtengas soluciones subóptimas y desperdicio de tokens. Lo realmente aterrador es cuando el modelo ignora las instrucciones y hace una estupidez que te arruina el día.
  Esto es filoso como una máquina CNC. No es que no sea útil, pero puede ser peligroso. Si no sabes estacionarte en paralelo, mejor no intentes tallar madera con una máquina monstruosa ni meter un Ferrari en un barrio estrecho.

  • La predicción del siguiente token no es un algoritmo, sino una interfaz. El proceso de “predecir el siguiente token” puede ser arbitrariamente complejo o simple, y su capacidad para realizar una tarea dada puede ser tan alta o baja como sea.
    Decir que un LLM puede o no puede hacer algo porque es un “predictor de tokens” es un error de categoría. La interfaz no es un límite rígido.
  • No sé cómo defines inteligencia cuando dices “no es inteligencia”.
    Me pregunto cómo sería posible una definición que excluya a los modelos de lenguaje e incluya a los humanos sin usar como axioma previo que los LLM no tienen inteligencia.
  • Entonces tú también eres solo alguien que dice la siguiente palabra.
  • Llamar a los LLM “predictores del siguiente token” es completamente reduccionista y deshonesto. Técnicamente es correcto, pero lo mismo aplica para ti.
    Normalmente lo que se quiere decir con eso es que “solo predicen el siguiente token de los datos de entrenamiento, es decir, de internet”, lo cual podría ser cierto para modelos base. Pero los modelos pasan por postentrenamiento, así que ni siquiera esa descripción sigue siendo correcta.
    Decir “no es inteligencia” no es útil y, en mi opinión, es falso. A quién le importa si encaja con tu definición de inteligencia. Sigue haciendo cosas impresionantes, y también cosas mucho más notables de lo que insinúas.
  • ¿A partir de qué umbral lo llamarías inteligente?

• El texto original se siente como si todavía estuviera en 2025.
  Dice que “la IA se saldrá del camino varias veces y solo te darás cuenta cuando pruebes el software de verdad”, pero ahora esa IA puede usar directamente el software para encontrar y corregir bugs, y también impulsar nuevas funciones.
  Sigue ocurriendo que los agentes empiecen a hacer cosas no deseadas, pero mucho menos que antes, y el argumento a favor de los agentes totalmente autónomos no se está debilitando, sino fortaleciendo.
  La frase “es humanamente imposible que una persona entienda el codebase” también suena anticuada. Creo que vamos hacia un punto en que los humanos ya no necesitan entender el codebase y la IA toma la dirección.

  • Las empresas de IA tienen incentivos para impulsar este slopmaxxing imprudente. El resultado final es que tu negocio depende completamente de ellas y todo el valor del producto también proviene de ellas.
    Mucha gente se está subiendo a esto, pero yo lo veo como una moda tonta.
  • Exacto, entender algo es demasiado de 2025.
  • Esto puede ser cierto para software no esencial, como entretenimiento o medios.
    Pero en sistemas con grandes riesgos de seguridad, de ninguna manera. En banca, aviación o defensa, la IA sin duda contribuirá, pero no podrá operar de forma independiente de la comprensión de la ingeniería humana.
  • Alguien con una intuición suficientemente buena sobre programación y arquitectura efectivas no estaría de acuerdo con que la IA use directamente el software para encontrar bugs y crear funciones.
    El método de correa corta es una forma de garantizar buenos resultados cuando trabajas fuera de los datos de entrenamiento. Diría que, para cualquier programador apenas por encima del promedio, es la única forma de garantizar desarrollo rápido y de buena calidad con LLM.
    La idea de que los humanos ya no necesitan entender el codebase parece venir de no conocer el mundo de la programación, donde la IA todavía es desastrosamente torpe. He visto de forma constante cómo arruina el manejo de memoria en lenguajes con gestión manual de memoria. No es tan simple como dejarla en un bucle con Valgrind.
  • No siento que el argumento a favor de los agentes totalmente autónomos se esté fortaleciendo. Esto me pasó hace unas semanas con Claude Code + Opus 4.8. La tarea no era muy compleja: cuatro endpoints nuevos de API y eventos transmitidos por websocket al cliente.
    Afiné varias veces las definiciones de la API, los modelos de solicitud/respuesta, el esquema de base de datos y el flujo completo, y eliminé contradicciones y corregí documentación muchas veces a mano. Opus seguía desviándose y el documento final superó las 500 líneas.
    También hubo que ir y volver con las pruebas de integración de la API. Como la IA no pudo crear pruebas directamente a partir del documento, primero hice placeholders con comentarios Given-When-Then, los revisé y corregí a mano, y en una segunda iteración implementó las pruebas. Hubo muchos errores que corregí tras la revisión.
    En la etapa de implementación proporcioné la documentación de la API, pruebas funcionales, hooks de bloqueo de modificaciones, más de seis skills de “buenas prácticas”, agentes de “rubber duck” y “simplificación de código”, y scripts para revisar errores de pruebas, linter y compilación. Tras planificación, ejecución, revisión y varias correcciones, la función quedó implementada y todas las pruebas pasaron.
    En la revisión de código encontré, en promedio, un problema cada 20 líneas de código. Incluso dejando de lado el estilo, había uso de semáforos en memoria en un servicio de Kubernetes, 8 llamadas a la DB para intentar actualizar el mismo registro durante una sola solicitud, actualizaciones de una columna a la vez, lecturas-modificaciones-guardados sin transacción, y errores de lógica de negocio, recuperación y autorización.
    El resultado fue casi una semana laboral, más de 100 dólares en tokens y solo la sensación de “¿valió la pena este esfuerzo?”. Tengo un equipo de 2 desarrolladores, y acabo de revisar el PR de uno: 80% era slop.

• Probé un enfoque parecido, pero no me funcionó bien. Casi no hubo mejora de velocidad, o no hubo ninguna. Creo que para ganar productividad hace falta cierto modo YOLO dentro de un sandbox.
  El objetivo debería ser subcontratarle al modelo la mayor cantidad posible de trabajo, minimizando el esfuerzo necesario para entender y revisar el resultado.
  Por ejemplo, encargarle al modelo encontrar la causa de un bug, hacer una prueba de concepto de X, optimizar algo de forma gradual o realizar refactorizaciones bien definidas con una guía.
  Lo que la gente describe como crear bucles es muy parecido: maximizar lo que hace el modelo y minimizar lo que yo tengo que hacer para controlarlo.

• El artículo no tenía mucho contenido.

  • Solo seguía la frase de moda del momento.
    El año pasado era “la IA no es más que un loro estocástico”.
    Este año es “la IA puede escribir código, ¡pero los humanos todavía tienen que revisarlo!”. Claro que para esa revisión también se usa IA.
    Si pasa apenas un año más, la narrativa será: “solo la IA puede hacer revisión de código, y solo la IA puede revisar la revisión de la IA. Los humanos solo tienen que leer la opinión final de la IA para mantener una supervisión significativa”.
    Los arcos siempre se mueven, pero la certeza nunca