¿Por qué tanto impulso por la IA agéntica si los modelos apenas pueden seguir una instrucción simple?

• En la realidad actual, donde los modelos de IA para programación ni siquiera pueden ejecutar de forma confiable una sola instrucción, se están generando expectativas excesivas sobre la programación agéntica que opera de manera autónoma en segundo plano
• El autor experimentó problemas con GPT-5 y Gemini Pro incluso después de proporcionar una función de Golang de unas 100 líneas como código de referencia: ambos omitieron parte de la lógica o dejaron actualizaciones sin aplicar
• Que un sistema agéntico procese de forma autónoma 50 archivos y múltiples funciones es poco realista con el nivel tecnológico actual, y existe el riesgo de que termine consumiendo más tiempo en depuración
• Las respuestas de la comunidad se dividen entre quienes opinan que puede usarse con éxito de forma limitada mediante prompting estructurado, documentación y verificación paso a paso, y quienes creen que lo agéntico todavía no es práctico
• Los LLM actuales son sistemas basados en conocimiento, no inteligencia, así que el enfoque realista es un uso instrumental en el que el desarrollador proporciona el contexto directamente y valida cada paso

---

Planteamiento del problema por parte del autor original

• Caso de fallo con una instrucción simple: proporcionó una función de Golang de 100 líneas como referencia y pidió actualizar otra función con la misma estructura, pero tanto GPT-5 como Gemini Pro omitieron parte de la lógica o dejaron cambios sin aplicar
• Lo poco realista de la programación agéntica: si ni una sola función puede resolverse correctamente, preocupa que un enfoque agéntico que modifique de forma autónoma múltiples funciones en 50 archivos provoque todavía más problemas
• Pregunta sobre la actualización de un archivo de 6000 líneas: pidió a la comunidad opiniones sobre cómo modificar de forma segura un archivo de unas 6000 líneas, por ejemplo en una actualización de versión de Stripe

Casos de uso positivos y metodologías

Enfoque de documentación e indexación sistemáticas

• Uso de archivos de referencia Markdown: guardar referencias en archivos .md y pedirle a la IA que los lea mejora la consistencia y la precisión
  • Ejemplo de prompt: "Consulta el archivo adjunto goLang_Update_reference.md, resume los puntos clave de la función update y, con base en ello, redacta un borrador de actualización del software"
• Construcción de un índice local: en archivos grandes (más de 6000 líneas), escanear en bloques de 1000 líneas para crear un índice con nombres de funciones y referencias de línea
  • En trabajo de frontend, se puede usar un índice separado solo para un área específica, como fr.index.md

Gestión de agentes y estructuración del trabajo

• Especialización de agentes: organizar agentes por roles como diseño (architect), exploración de código (codeseeker) y programación (coder), y proporcionar archivos de reglas .md para cada uno
• Enfoque de slice vertical: dividir el trabajo en unidades pequeñas de funcionalidad que puedan completarse con menos de 100 mil tokens
  • Si se superan los 100 mil tokens, la probabilidad de mal funcionamiento del agente aumenta drásticamente
• Forzar la documentación del trabajo: hacer obligatoria la actualización de docs/TASKS.md, docs/WORKLOG.md y docs/DECISIONS.md para asegurar continuidad

Uso de Plan Mode y Ask Mode

• Plan Mode: revisar el proyecto completo, elaborar un plan según la solicitud y luego avanzar paso a paso
• Ask Mode: útil para consultar el codebase, explorar ideas, revisar opciones y como sustituto de Google/StackOverflow

Enfoque de pruebas unitarias primero

• Desarrollo guiado por pruebas: escribir primero las pruebas unitarias antes de crear la función, y hacer que la IA genere iterativamente código que las pase
  • La probabilidad de obtener código funcionalmente correcto aumenta mucho, y luego solo quedan tareas de optimización y limpieza

Posturas escépticas y reconocimiento de límites

Límites reales de lo agéntico

• Trabajar sin supervisión es una temeridad: con el nivel tecnológico actual, asignar tickets y dejar que trabaje de manera autónoma en segundo plano tiene una alta probabilidad de fallar
• Posibilidad de mentir: el modelo tiene más probabilidades de generar alucinaciones que aciertos, y en el peor caso puede destruir código existente
• Redundancia de Planning Mode: pedirle un plan detallado al modelo base ya es suficiente; Planning Mode no aporta realmente una función nueva

Restricciones inherentes de los LLM

• Predicción, no razonamiento: los modelos funcionan prediciendo la siguiente palabra sin verificar el resultado, así que la confiabilidad seguirá siendo inestable hasta que mejoren el grounding, la memoria y el feedback
• Base de conocimiento sin inteligencia: un LLM es una base de conocimiento sofisticada sin inteligencia, por lo que el desarrollador debe aportar directamente la inteligencia (BYOI: Bring Your Own Intelligence) y el contexto
• Falta de memoria: el modelo no tiene memoria real y depende solo del contexto y de la caché de contexto, por lo que el contexto se reinicia cada vez que se inicia un chat nuevo

Sesgos de lenguaje y datos

• Desventaja relativa de Golang: Golang tiene menos codebases públicos que Python o JavaScript, por lo que el modelo dispone de menos patrones y convenciones aprendidos
  • Ese es un factor estructural que dificulta obtener resultados de edición o transformación consistentes

Guía práctica para un uso exitoso

Prompting y provisión de contexto

• Instrucciones claras y detalladas: usar gramática y puntuación correctas, y dar instrucciones explícitas en lugar de expresiones ambiguas
• Referencia explícita a todos los archivos relevantes: si no se especifican todos los archivos que el agente debe usar, aumenta la probabilidad de generar código espagueti
• Configuración de archivos de reglas: establecer reglas para todo el workspace y archivos de reglas por proyecto para guiar una generación de código consistente
• Uso de @Docs: aprovechar la referencia a documentación para proporcionar al agente el conocimiento clave que necesita (aunque en algunas versiones funciona de manera inestable)

Alcance del trabajo y verificación

• Dividir en unidades pequeñas: separar el trabajo en la unidad mínima manejable, validar cada etapa y solo entonces pasar a la siguiente
• Revisión en tiempo real: revisar en tiempo real todo el código generado y pedir correcciones de inmediato para evitar código espagueti
• Respaldo y control de versiones: crear respaldos en cada etapa y usar sistemas de control de versiones como GitHub
• Ejecutar pruebas: correr de forma incremental las pruebas afectadas con pytest --testmon -q y ejecutar la suite completa antes de terminar

Modularización y estructura del código

• Dividir archivos de 6000 líneas: tener 6000 líneas en un solo archivo no es modular y dificulta aportar contexto, por lo que es más efectivo dividirlo en 12 archivos de unas 500 líneas
• Preferencia por slices verticales: desarrollar en unidades pequeñas de funcionalidad ejecutables de punta a punta

Selección de modelo y gestión de costos

• Considerar primero Claude Sonnet 4.5: ofrece más consistencia y precisión que GPT o Gemini, por lo que vale el costo adicional
• Cuidado con el consumo de tokens: los planes grandes consumen muchos tokens, así que en la ejecución real es más eficiente en costos avanzar en pasos pequeños

Casos de uso especiales

Generación de scripts de una sola vez

• Scripts de análisis: si hay que escribir cientos de scripts desechables de análisis de datos al día, incluso con 50% de precisión pueden generarse y ejecutarse 1000 veces más rápido que escribiéndolos manualmente
• Posibilidad de verificar el resultado: como el resultado puede validarse directamente, una precisión baja sigue siendo práctica

Construcción de una app desde cero

• Estructura multiagente: al construir una app grande desde cero, un agente supervisor revisa el trabajo de otros agentes para mantener la consistencia
  • Es útil para mantener consistencia en nombres de imports, nombres de variables y evitar duplicación de código
• Eficiencia frente al costo: siguen haciendo falta modificaciones y refactorizaciones complejas, por lo que un enfoque por etapas termina siendo más barato a largo plazo

Resumen de opiniones de la comunidad

Experiencias positivas (mejora de productividad de 3 a 5 veces)

• Sitio web en Next.js: construcción en minutos de un sitio web totalmente funcional y desplegable desde cero
• Implementación de funciones complejas: implementación de la función de threads en una app de chat en 3 a 4 minutos (una tarea estimada en 3 días)
• Con un enfoque sistemático: combinar reglas claras, contexto suficiente y validación paso a paso puede llevar a éxitos consistentes

Experiencias negativas (por ahora no es práctico)

• Producción masiva de código espagueti: al dar objetivos amplios, aparecen problemas como omitir actualizaciones de documentación o no eliminar archivos residuales
• Errores semánticos: técnicamente funciona, pero con problemas estructurales como ubicar mal el código o reimplementar funciones existentes
• Fracaso en ejecuciones largas: los seguimientos largos de más de 5 minutos suelen producir resultados inútiles

[GN⁺]

Opiniones de Hacker News

• Por mi propia experiencia, siento que la mayoría de los LLM sí siguen bien mis instrucciones. Claro, necesitas prompts bien pulidos y planificación previa, pero si le agarras la mano a esas tres cosas, puedes volar bastante bien con estos agentes de programación. A veces fallan, quizá 1 de cada 10 veces, pero incluso en esos casos se corrige rápido si los detienes pronto y los reencaminas. Me sorprende que aquí en HN tanta gente sea escéptica sobre su efectividad. Obvio, hay muchas preocupaciones válidas como el costo o el cambio laboral, pero me sigue sorprendiendo ver tan seguido dudas sobre la utilidad de los agentes de código
  • Me gustaría ver videos o casos reales donde un sistema de agentes o un LLM realmente genere más valor que una búsqueda en Google o stack overflow
  • Si explicas bien el estado actual, el resultado deseado y cómo avanzar, puedes planear con el agente, refinar el plan y ejecutarlo. Así, el nivel técnico actual sí resulta bastante impresionante. Esperar que haga algo complejo con una sola frase es pedir demasiado. Es parecido a encargarle una tarea técnica a un practicante inteligente pero sin experiencia laboral: requiere tiempo y esfuerzo reales. La diferencia es que un agente de IA trabaja mucho más rápido que un practicante humano
  • Que “la mayoría de las veces funciona” básicamente significa que no hay ningún indicador real de confiabilidad
  • Justo ahorita, mientras paseaba al perro, usé Codex (gpt-5-high) para convertir una app en Python a Go de una sola vez. Probé el resultado y funciona bien. Me gustó poder desplegarlo como un binario único sin entorno virtual. No sé si la instrucción era tan fácil como para impresionar tanto
  • Para mí, “la mayoría de las veces funciona” no es suficiente. El problema más serio no es que no siga instrucciones, sino que no admite que está mal y sigue insistiendo. Cuando le pido algo de complejidad media o análisis de errores, bastante seguido se aferra a conclusiones incorrectas. Muchas veces no encuentra la salida hasta que yo mismo le señalo el problema. Para código simple o tareas boilerplate sí es muy bueno, y con algo de feedback incluso me ha ayudado a crear librerías nuevas. Pero como se equivoca seguido, no quiero confiarle cosas más complejas. Aun así, cuando estoy atorado lo uso para soltar ideas; aunque se equivoque, ayuda a motivarme
• Cuando la diferencia de experiencias entre desarrolladores con LLM es tan grande, la verdadera pregunta que deberíamos hacernos es: “¿por qué son tan distintas esas experiencias?”. La explicación más simple es “no lo estás usando bien”, pero incluso como desarrollador de sistemas de IA me sorprende cuánta gente espera resultados escribiendo solo cosas como “arréglalo” o “haz un reporte”, sin instrucciones complejas. También está el hype exagerado de la gerencia de que “la IA puede hacerlo todo”, algo que además se conecta con valuaciones y precio de la acción. El público en general también parece ver la IA como “inteligencia artificial real”. En realidad, la idea de que los LLM ni siquiera pueden seguir instrucciones simples no me parece muy creíble; lo importante es que todavía no hacen bien las tareas complejas
  • Otra teoría mía es que cada quien tiene una especificación en la cabeza, la escribe de forma desordenada y espera que el LLM la implemente, pero el resultado final casi siempre se desvía de esa especificación mental. Algunos desarrolladores luego ajustan esa especificación en retrospectiva o aceptan pequeñas diferencias, mientras que otros se decepcionan porque el LLM no coincidió con su plan mental. Es como una especie de “falso recuerdo” psicológico: algunos son más flexibles y negociadores, otros más rígidos. Yo mismo he vivido ambas cosas
  • A estas alturas quiero ver más screencasts, textos largos, lo que sea, donde alguien muestre todo el proceso real de construir una funcionalidad no trivial. Los influencers de IA casi siempre muestran herramientas de IA hechas con IA, o demos CRUD y hello world. Incluso desarrolladores veteranos dicen que la IA escribió más de la mitad del codebase, pero luego aclaran que casi todo lo descartaron y solo tomaron algunas referencias. La historia de “un solo prompt → app terminada” rápidamente se convierte en “sirve para motivarte frente a una pantalla vacía”. Ojalá más gente comparta con transparencia cómo la usan de verdad en trabajo real
  • En realidad, la categoría “desarrollador” es tan amplia que casi no significa mucho en esta discusión. Para ensamblar fragmentos de código tipo CRUD, a la mayoría los LLM les funcionan bastante bien
  • Todo el mundo trabaja en codebases diferentes y en tareas distintas. Casi nunca se habla de ese detalle importante. Mientras más los usas, más suben tus expectativas y más rápido notas sus límites. Si los usas de vez en cuando impresionan; si los usas todo el día, acabas acumulando decepción. Muchas veces incluso cosas que “ya debería poder hacer” terminan requiriendo correcciones
  • Estoy seguro de que no es que los resultados sean distintos, sino que las expectativas de cada quien son diferentes. El SVP de IT de mi empresa es un fanático de la IA. Hace poco estuve trabajando en un proyecto legacy en PHP que él había hecho antes, y me di cuenta de que su estándar de calidad de código siempre ha sido bajísimo. Yo también uso LLM todos los días, pero siempre termino corrigiendo el resultado. O sea, mientras más baja sea tu barra de calidad, más satisfecho quedas con lo que produce un LLM
• En el foro de Cursor siempre repiten “lo estás usando mal”, pero lo que de verdad me interesa es la confiabilidad, el proceso y la aplicación real en trabajo productivo. Aquí también tengo la impresión de que casi no se ven casos de uso a gran escala. Nosotros usamos la IA más bien como un “compañero torpe”, y experimentamos más con ella en side projects con menos restricciones. Mi impresión es que los agentes son puro hype, o algo muy de nicho
  • La razón de los malos resultados del OP es que usa Cursor. Cursor recorta el contexto sin piedad para ahorrar costos. A diferencia de los proveedores de modelos, tiene que pagar precio minorista por el uso del LLM, así que compite en desventaja. Cursor no es transparente sobre cuánto contexto corta y, en mi experiencia, lo hace de forma tan agresiva que tienes que volver a cargar los mismos archivos una y otra vez para que entienda qué está pasando. Mi consejo es dejar de invertir tiempo en Cursor. El código que genera Cursor solo te deja deuda. Me cambié a Codex y Claude y estoy mucho más satisfecho
  • Me da curiosidad saber qué mejoras concretas quisiera ver. La publicación original no trae ejemplos específicos, prompts ni metodología; solo dice “sé escribir buenos prompts”, y así es difícil evaluar o aconsejar algo. También entiendo el escepticismo hacia los flujos agentic, pero al final tampoco le dio a la gente una oportunidad real de responder con argumentos. Yo llevo meses trabajando con agentes y todavía sigo aprendiendo qué funciona y qué falla. En mi experiencia:
    • la orquestación es indispensable con frameworks como agent-os
    • es importante equilibrar supervisión y autonomía
    • la planificación previa es realmente importante, sobre todo en código legacy
    • un ejemplo mío: en un sistema legacy me pasaba seguido del límite de la ventana de contexto, y cuando resumía el contexto siempre se perdía información esencial, así que repetía los mismos errores
    • lo que sí funcionó: estructurar claramente el problema, documentar de forma explícita cada hallazgo y aprendizaje, y dividir el trabajo en subagentes muy específicos (para poder controlar la ventana de contexto). Solo entonces los agentes empezaron a ayudar de forma real al explorar código legacy
  • He tenido casos donde un agente encontró varios bugs de producción que yo no había detectado (bugs ajenos y raros a los que no pude dedicarles suficiente tiempo). Claro, hay muchos más bugs que no encuentra, pero comparado con una hora de un ingeniero de software, es casi gratis, y si de vez en cuando funciona ya es una estrategia útil
  • Un texto con ejemplos prácticos y concretos tendría mucho más valor y daría pie a mejores respuestas. Sería más útil mostrar un problema real de trabajo y el proceso en el que el LLM falló
  • El valor de negocio real es muchísimo menor de lo que la gente cree, y eso me desespera. Sí, en boilerplate o en áreas conocidas a veces lo hace mejor que un humano. Pero los demás problemas —dependencia de big tech, contaminación de datos, información imposible de verificar, deterioro de la creatividad, colapso de la originalidad, ignorancia de los fanáticos de la IA, consumo energético, apropiación del trabajo creativo humano, etc.— son demasiado grandes. Me cuesta creer que esto sea un beneficio neto para la humanidad
• En 2025, el marketing ya se hace muy bien en Reddit, LinkedIn y todos los foros: las marcas se meten en la conversación. CEOs, “pensadores” de IA y VCs promocionan los LLM como si fueran magia y venden v0, Lovable y demás como la próxima gran innovación. Y las respuestas del liderazgo son todas parecidas (video relacionado). Pero en la práctica, por más que armes cosas como CLAUDE.md o cursorrules, casi no sirven. Al final el LLM tiene que seguir instrucciones, y en realidad se siente aleatorio. Ni siquiera respeta reglas muy simples, así que me da la impresión de que la gente que publica en el foro de Cursor son todos amateurs. Y además, los LLM son realmente malos para escribir código nuevo. Suponen librerías que ni existen y generan puro texto inútil. Yo literalmente los uso como si fueran speech-to-text; ahí sí detectan mejor que yo algunos edge cases, best practices o detalles de sintaxis que se me pasan
  • [1] Los resultados de búsqueda, Perplexity y similares son en su mayoría puro material de marketing sembrado por equipos de marketing
  • Coincido totalmente en que los LLM son terribles para escribir código nuevo. Los modelos SOTA actuales sí pueden producir boilerplate o estructuras simples en frameworks muy conocidos y con patrones consistentes, como MVC. Donde realmente destacan es en tareas de revisar mucha información y encontrar algo dentro de ella (un codebase, logs, stack traces, etc.). Pero el marketing de que “el agente crea todo el codebase” me parece, hoy por hoy, pura ficción
  • Mi experiencia es exactamente la opuesta. Durante la última semana, Claude Code prácticamente corrigió por su cuenta problemas de compilador que yo mantengo. Salvo algunos momentos frustrantes, arregló de manera constante incluso bugs sutiles de generación de código y del parser, y las veces que tuve que intervenir estaban más relacionadas con límites de la herramienta, como el manejo de compaction. Incluso implementó enfoques que normalmente requerirían consultar libros, y confirmé que funcionaban al ejecutarlos. Tal vez no sea algo totalmente nuevo ni realmente “innovador”, pero la verdad es que casi ningún código lo es. En mi experiencia, si le das instrucciones siguiendo una guía bien estructurada, suele obedecer bastante bien. No basta con aventar cosas a CLAUDE.md y ya. La clave está en guiar con detalle el proceso. Mi forma de trabajar se divide en: 1) guía de debugging por proyecto, 2) criterios de aceptación claros, 3) ejecutar tests con frecuencia y hacer que registre en archivos los cambios pequeños por unidad. Así puedo dejar a Claude trabajando varias horas casi sin supervisión (solo dándole “continue” de vez en cuando o usando /compact). No produce código perfecto cada vez, pero yo tampoco. Aun así, casi siempre termina en cambios positivos y me ahorra mucho esfuerzo. Todavía no recomiendo usarlo para bootstrap sin diseño adecuado, aunque a veces también lo logra (pero con revisión previa). Últimamente incluso he pensado en dejar a Claude resolviendo problemas de forma continua durante días
  • Me parece fascinante que las experiencias con LLM puedan ser tan distintas. En mi caso, con codex-cli siento un aumento de productividad de 5x. Pude convertir fuentes con estructuras muy inusuales y trazas internas de ejecución SVG a un formato custom de grafos JSON, y también extraer documentación precisa de un codebase mixto Python/C++ bastante complejo, incluso con kernel RISCV de bajo nivel. De verdad me intriga por qué con la misma herramienta salen resultados tan diferentes
  • Programar con Claude se siente como jugar a la tragamonedas. A veces te da exactamente lo que querías, pero mucho más seguido no, o se va totalmente por otro lado. Sería peligroso dejarlo operar solo sin supervisión
  • A mí también me parece que el valor más constante de los LLM es detectar errores pequeños que los humanos suelen pasar por alto, además de sugerir buenos ejemplos o sintaxis correcta. Por eso, como revisor de PRs, puede servir si lo tomas con reservas
• En nuestra empresa aplicamos el enfoque clásico de XP. Para desarrollar nuevas funciones en una app brownfield, dividimos el trabajo en casi 8 subagentes como “red-test-writer”, “minimal-green-implementer” y “refactorer”. Ahora solo le escribo a Claude Code: “con este proceso TDD, crea la funcionalidad X”, y en 30 minutos entrega código mucho mejor, con 90% de cobertura de pruebas y listo para aceptar de inmediato. Claro, esto se apoya en años de experiencia con XP, pair programming y TDD, pero desde hace más de un año, 95% del código de producción lo ha escrito la IA (incluyendo funciones complejas no triviales). Y sin ningún secreto especial; simplemente funciona muy bien. Para nosotros, el impacto ha sido enorme
• Aquí hay una diferencia de opiniones enorme. Si cada quien no explica en qué falló, en qué tipo de tareas lo usa y en qué contexto, es imposible tener una discusión seria. Si no hablamos de categorías concretas de éxito o fracaso de los LLM, todo esto es poco más que ruido
  • En este tipo de discusiones habría que detallar lenguaje/framework, dominio del problema, nivel SRE, LLM (modelo/versión), agentic harness (Claude Code, Codex, Copilot, etc.), casos de éxito/fracaso y hasta nivel de experiencia del usuario con LLM. También influyen cosas como si el ingeniero lleva 10 años en un solo codebase o alterna varios proyectos, si es desarrollo nuevo (Greenfield) o mantenimiento, investigación innovadora o CRUD, etc.
• Desde la perspectiva de un científico, muchas veces hay que repetir boilerplate ligeramente distinto para cada dataset, y los agentes de programación ayudan bastante con eso. Aunque sí me pasa que, incluso si le digo a Claude cinco veces en mayúsculas “NO INVENTES DATOS, NO USES np.random”, a veces me ignora. Eso resulta sorprendentemente absurdo. Cuando funciona es fantástico, pero cuando falla, ni siquiera da una señal de que falló. Desde la lógica de marketing de los LLM, hasta me imagino un agente tipo “PIPA (Performance Improvement Plan Agent)” vigilando al agente programador en tiempo real para ver si realmente está trabajando bien. PIPA revisaría su desempeño para que RR. HH. o la gerencia puedan gestionar a los empleados de IA (agentes); hasta podría ser así como llegue el futuro
  • Si te dicen “¡no pienses en un elefante con tutú rosa!”, ¿no es justo eso lo que imaginas? Si eres científico, deberías saber que por su naturaleza los LLM no entienden bien las negaciones. Como aprenden token por token, aunque pongas “NO ELEPHANTS”, la palabra “elephant” sigue presente en el contexto. Entonces, más bien los orientas hacia eso. Es mejor usar instrucciones positivas
  • Solo imaginar PIPA ya da miedo
• La clave es usar prompts que permitan al modelo encontrar por sí mismo el contexto adecuado, como buenos mensajes de error, y dividir el trabajo en partes muy pequeñas y consistentes para poder pasar al siguiente paso los resultados de tests iterativos o por etapas. Un 50% de los problemas encaja en este enfoque, y en otro 50% el loop con LLM es apenas menos engorroso que la automatización tradicional, pero de esos solo la mitad vale realmente la inversión. Al final, si existe un “mágico 12.5%” de casos, el mejor enfoque es un agente fuertemente restringido
  • Sería buenísimo transmitir en vivo ese proceso tal cual por YouTube o algo así, no como tutorial sino como live coding natural; daría insights interesantes
• Hace casi 30 años, cuando empecé en IA, escuché este consejo: cuando oigas la expresión “intelligent agent”, piensa en “una hormiga entrenable”
  • Me gustaría saber más
• Para mí, el mayor problema es que el rendimiento de las herramientas de IA varía muchísimo según la tarea, y es difícil predecir dónde van a fallar, así que terminas gastando tiempo. Uno pensaría que con más experiencia mejoraría mi habilidad para escribir prompts, pero sigue siendo frustrante. Aun así, hay zonas donde se traslapan la utilidad de los agentes y la IA, por ejemplo para generar automáticamente el boilerplate de un proyecto nuevo. En esos casos, el “modo agente” sí se siente más cómodo. Igual, todavía me falta experiencia práctica real
  • Mientras mejor funciona, más suben tus expectativas y más amplías su uso; pero cuando chocas con sus límites, la decepción acaba siendo todavía mayor que al principio