Hace unos días Mrinank Sharma, autodefinido como poeta e investigador, renunció a su posición dentro de Anthropic (creadores de Claude, uno de los modelos de inteligencia artificial más populares y potentes) con una publicación en la que hacía un llamado a mantener presente el poder de cambio que van a traer modelos cada vez más poderosos.
En su carta de despedida dice “We appear to be approaching a threshold where our wisdom must grow in equal measure to our capacity to affect the world, lest we face the consequences".
Sugiere que nuestra capacidad de cambiar el mundo en el que vivimos va a aumentar considerablemente con el poder de nuevos modelos y tecnologías, y nos advierte que si no tenemos la madurez y sabiduría suficiente, las consecuencias pueden ser terribles.
Horas después de la publicación de Sharma, Anthropic publicó un informe de riesgos de su último modelo, Opus 4.6, que rompió récords en algunos benchmarks (pero que a las horas fueron superados por GPT 5.3 de OpenAI). En ese informe también reportaron que Opus 4.6 había dado instrucciones para fabricar armas químicas y tratado de ejecutar acciones sin la autorización del usuario. Esto es parte de los problemas en los que Mrinank Sharma había trabajado: ¿cómo implementar filtros para que los modelos sean más seguros para quienes interactúan con ellos?
Pero yo me pregunto, tal vez desde una posición más ingenua y egocéntrica, más allá de las posibles y terribles consecuencias que Mrinank advierte: ¿sirve de algo —aún hoy— saber cómo se resuelven los problemas? Por mi trabajo estoy acostumbrado a entender a detalle el contexto de un problema: depende de mí tener la creatividad y la capacidad de poder resolverlo. Aparentemente esto está dejando de ser tan relevante con las nuevas tecnologías. Pero una parte de mí siente que hay algo en lo desarrollado que sigue siendo importante.
La inteligencia artificial ya es un componente más de nuestra humanidad. Tiene un nombre espectacularmente marketero que vende como el charlatán que es. Lo que llamamos hoy “inteligencia artificial” es, en realidad, un conjunto de Large Language Models o LLMs, que son redes neuronales de miles de millones de conexiones que son capaces de predecir la siguiente palabra de una secuencia de caracteres. Y resulta que esa capacidad se parece mucho a lo que usamos los humanos para medir inteligencia en su nivel más superficial: el lenguaje.
Porque si alguien habla bonito, debe ser inteligente. Y por eso digo que es un charlatán: porque le enseñaron a hablar bonito. Pero poco a poco nos dimos cuenta que, aunque sea tonto en las preguntas rápidas (probablemente todos lo hemos experimentado), podemos usar su perorata a nuestro favor. Porque para hablar bonito se necesita responder bien a veces. Y si mandamos a un charlatán a armar un rompecabezas, probablemente lo haga perfecto. Pero si el rompecabezas es muy complicado, capaz que se pone a cortar las piezas y trata de convencernos que sí lo armó.
Las nuevas herramientas que han cambiado el paradigma de cómo escribimos código se parecen a un charlatán armando rompecabezas. Pero en vez de estos pasatiempos, se trata de escribir líneas de código, que igual a un par de piezas de rompecabezas que calzan juntas, el código tiene un conjunto de reglas estricto y simple acerca de cómo calzan estas líneas entre ellas. Para usar una variable, antes hay que definirla. Para mostrar un número en la pantalla, antes hay que calcularlo. Para mandar un correo, antes hay que conectarse a un servidor que lo envíe. Y por eso es que si le pasamos las piezas con reglas bien estructuradas, y le damos una instrucción difícil de malinterpretar (para que este charlatán no nos haga trampa), lo más probable es que lo haga bien.
En la práctica, esto avanzó muy rápido (y lo sigue haciendo), pero hace unos meses se empezó a consolidar con mucha fuerza, como ya mencionó Mrinank Sharma. La llegada de herramientas como Claude Code y modelos cada vez más poderosos (y ya no tan baratos) hicieron que las cosas se sintieran cada vez más como ciencia ficción.
Los inicios
El primer modelo disruptivo fue GPT en su versión 3. La versión 2 también fue noticia relevante, pero pertenece a una generación de modelos que eran de mayor interés académico, y no general. No era mala, pero no servía para mucho. La versión 3, en cambio, fue un cambio importante. OpenAI lanzó una versión destilada y la ofreció al público en un chat web que bautizó con el nombre que ya usamos casi de sinónimo de inteligencia artificial: ChatGPT.
Uno se lo mostraba a personas menos técnicas, no solo para presumir la novedad, sino para despertar curiosidad de todas las posibilidades que se abrían con una computadora que sabía hablar bien. Desde luego, la tentación era preguntarle sobre hechos. Desde luego, el resultado era catastrófico. Si no lo sabía, lo inventaba. Y lo que no sabía era mucho más de lo que sabía, pero hablaba bonito. Así que quedó como un buen corrector de ortografía y redactor de correos y ensayos para la universidad.
A nivel de código, era más bien mediocre. Se equivocaba en sintaxis, inventaba dependencias y tenía mala memoria.
El autocomplete
El potencial de los LLMs causó una explosión de modelos de distintas empresas y en los años siguientes salieron decenas de modelos entrenados para desarrollar distintas tareas y objetivos. Algunos mejores para conversar, otros que alucinaban menos, y empezaron a salir modelos finetuneados para escribir código. De los primeros estuvo Codex de OpenAI, que usó GPT-3 como base para integrarlo en VS Code, el editor de código de Microsoft (que tenía en ese entonces licencia exclusiva para usar GPT-3). Las expectativas fueron altas, pero la recepción fue dividida. Tenía las limitaciones propias del modelo y se equivocaba muchísimo. A menudo eran errores difíciles de identificar que terminaban tomando más tiempo que haberlo escrito a mano. Pero se empezaba a esbozar un cambio en la forma en la que interactuábamos con el código en nuestros editores.
El 2023 llegó una nueva solución y vino de una de las empresas que más rápido ha levantado mil millones de dólares de ARR (menos de 24 meses): Cursor. Esta empresa fue pionera en entrar por el lado de las herramientas, más que por el modelo. Y fue así que lanzaron su propia versión de VS Code (el editor más usado en el mundo hoy, entre desarrolladores de software). Incluía un chat integrado para hablar con un agente, con acceso al archivo que tenías abierto para leerlo y modificarlo, le podías referenciar también otros, si se lo pedías en el chat, para que lo usara de contexto. Pero lo que fue más impresionante fue la otra gran funcionalidad: el cursor tab.
Cuando uno escribe código, hay muchas estructuras que son predecibles. Por ejemplo, si estoy calculando la suma de dos variables “edadAlicia” y “edadRoberto” y estoy escribiendo “total = edadA”, es fácil saber que lo más probable es que escriba “edadAlicia”. Los editores, hace décadas que nos autocompletan este tipo de casos con alta precisión. Nada nuevo hasta ahí.
Pero Cursor, cual Usain Bolt, los dejó a todos atrás con su Cursor Tab. Era impresionante para el estándar que teníamos en ese entonces. No sólo sugería implementaciones completas (y muchas veces correctas) de funciones complejas, sino que aparentemente entendía el contexto y podía inferir abstracciones de más alto nivel. Por ejemplo si tenía definidas variables con la lista de días feriados y escribía “productos_disponibles = [‘APV-A’, el modelo autocompletaba con ‘APV-B’, ‘APV-DC’, etcétera. No porque esos conceptos vinieran de su entrenamiento general, sino porque los estaba infiriendo del contexto específico del proyecto en el que se estaba trabajando.
Ese salto fue relevante. El problema fue que su lado charlatán no desapareció del todo. Así que muchas veces completaba con demasiada seguridad, aunque estuviera inventando. En el ejemplo anterior, era razonable que sugiriera una secuencia lógica como `productos_disponibles = [‘APV-A’, `sugiriera `APV-B, APV-C, APV-D,`. Pero cuando el problema se volvía más complejo, también podía empezar a rellenar huecos con creatividad excesiva.
Para tareas simples, era un aporte enorme. Para decisiones más delicadas, había que mirarlo con lupa.
Los agentes
A medida que los modelos se hicieron más poderosos y empezamos a conocer mejor los límites intrínsecos que tenían (por ejemplo, aún les cuesta contar cuántas “r” hay en strawberry), empezaron a aparecer herramientas que se alejaban de la respuesta instantánea con funcionalidades de “razonamiento” o “análisis”.
Estas pasan a un nivel superior donde un agente trabaja sobre una lista interna de preguntas y respuestas que va modificando y respondiendo para llegar a una respuesta final que entrega al usuario. En el fondo, cada operación que hace sigue siendo una red neuronal que escupe la siguiente palabra de una secuencia de palabras, pero ahora le estamos pidiendo instrucciones cortas y simples.
Primero haz un plan. Fácil. Copia y pega. Después revísalo. Ok, fácil también. Ahora expande el primer punto. Perfecto, dice que tengo que buscar la palabra “calcular edad” dentro del archivo “simulador.py”. Eso se hace ejecutando el comando “grep -i ‘calcular\s*edad’ simulador.py”.
En ese punto, la herramienta se da cuenta que el modelo sugirió ejecutar un comando. Así que le pido permiso al usuario y entrega tres opciones: rechazar la sugerencia (y escribir una nueva instrucción), aceptarla y ejecutar el comando, o confirmar y además aceptar todos los comandos parecidos en el futuro.
Cuando sentimos que ya le entendimos el ritmo, a veces le decimos que no pida permiso para todo (a esto Andrej Karpathy, uno de los fundadores de OpenAI, lo llamó vibe coding). Al principio, los resultados eran al mismo tiempo impresionantes y desastrosos. El auto se veía como un deportivo de lujo, pero abrías el cofre y te encontrabas con malas prácticas, ineficiencias y cables que no se conectaban con nada. La tentación de seguir pidiéndole al modelo corregir sus propios errores era grande, pero casi siempre llegaba un punto en que ya no había arreglo. Así que tocaba borrar todo y empezar de nuevo, a mano.
A medida que los modelos fueron mejorando y las herramientas también fueron adaptándose mejor a lo que conocíamos, el conjunto de cambios que se podían hacer de manera autónoma iba creciendo, y en diciembre del 2025 (según Karpathy) hubo un punto de inflexión. Herramientas como Claude Code, Codex, OpenCode y el mismo Cursor ya se sentían naturales dentro del flujo de trabajo. Y al mismo tiempo, los modelos se equivocaban menos y entendíamos más sus límites naturales.
Fue durante este hito, que el cambio se sintió fuerte y tangible. Ahora realmente uno puede avanzar extremadamente rápido cuando las piezas están claras y las instrucciones son precisas. Si quiero cambiar la palabra “cuenta” por “perfil” en todo el código lo va a hacer perfecto. También si le pido que lo cambie por su traducción al inglés, o que me traduzca todos los correos a inglés. Y si le pido que cambie la forma de mandar correos para que use gmail en vez de SES, probablemente también. Pero si le pido que implemente un servicio que reemplace gmail, probablemente lo haga pésimo.
Los modelos van a seguir avanzando y los límites de lo que hacen bien o mal todavía están por descubrirse. Entonces me pregunto: ¿sigue sirviendo entender cómo resolver un problema? Yo creo que sí. Y mucho.
Porque para evaluar el trabajo de un charlatán necesitamos entender cómo se resuelve el problema. Si no, no hay manera de medir su trabajo y, en una de esas, nos apuñala por la espalda. Mientras más astuto es el charlatán, y más poderosos los modelos, mayor debe ser el criterio para identificar sus errores a tiempo. Así que sí, todavía sirve.
