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 donde, entre otras cosas, 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. Unas horas desde la publicación de Sharma, Anthropic publicó un informe de riesgos de su su último modelo publicado, 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 de cómo construir armas químicas y trató de ejecutar acciones sin la autorización del usuario. Estos son justamente parte de los problemas en los que Mrinank Sharma había trabajado: cómo implementar barreras 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 consecuencias terribles que Mrinank advierte: ¿Hoy aún sirve de algo saber cómo se resuelven los problemas? Por mi trabajo estoy acostumbrado a entender al detalle el contexto de un problema y que dependa de mí tener la creatividad y capacidad de poder resolverlo. Aparentemente esto ya deja de ser tan relevante con las nuevas tecnologías que han salido, pero parte de mí siente que hay algo aún que es importante en lo que hemos desarrollado.
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. A lo que llamamos hoy inteligencia artificial es en realidad a los Large Language Models o LLMs, que son básicamente 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 de a poco nos dimos cuenta que aunque sea tonto en las preguntas rápidas (probablemente todos lo hemos experimentado), podemos usar su hablamiento a nuestro favor. Porque para hablar bonito se necesita responder bien a veces. Y si mandamos a un charlatán a armar un puzle, probablemente lo haga perfecto. Pero si el puzle es muy complicado, capaz que se ponga a cortar las piezas y trate 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 puzles. Pero en vez de puzles se trata de escribir líneas de código, que igual a un par de piezas de puzles que calzan juntas, el código tiene un conjunto de reglas estricto y simple 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 despache. 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.
Esto en la práctica 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) han hecho que las cosas se sientan cada vez más como ciencia ficción.
Los inicios
El primer modelo que fue disruptivo es GPT en su versión 3. La versión 2 fue también una noticia relevante, pero es de una generación de modelos que eran de más interés académico que general. No era mala, pero no servía para mucho. La versión 3 en cambio fue un cambio importante. OpenAI sacó una versión destilada y la disponibilizó al público en un chat web que bautizó con el nombre que ya usamos casi de sinónimo de inteligencia artificial: ChatGPT. Uno ya se lo mostraba a personas menos técnicas, no solo para mostrar la novedad, sino para despertar una curiosidad de las posibilidades que se abrían con un computador que supiera hablar bien. Obviamente la tentación era preguntarle sobre hechos. Obviamente el resultado era catastrófico. Si no sabía, inventaba, y lo que no sabía era mucho más de lo que sí sabía, pero hablaba bonito. Así que quedó como un buen corrector de ortografía y redactor de correos y ensayos de 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 cámbrica de modelos de distintas empresas y en los años siguientes salieron decenas de modelos entrenados para 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 de 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 harto. Muchas veces con 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 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 podido conseguir mil millones de dólares de ARR (menos de 24 meses): Cursor.
Cursor fue de los primeros que trató de entrar por el lado de las herramientas más que el modelo y sacaron su propia versión de VS Code (el editor hoy en día más usado en el mundo entre desarrolladores de software), que incluía un chat integrado para hablar con un agente, con acceso al archivo que tenías abierto para leerlo y modificarlo, y le podías referenciar también otros si se lo pedías en el chat para que usara de contexto. Pero lo que fue más impresionante fue la otra gran funcionalidad: el cursor tab.
Cuando uno escribe código muchas estructuras 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”, entonces los editores hace décadas que nos autocompletan ese tipo de casos con alta precisión. Nada nuevo ahí.
Pero Cursor, cual Usain Bolt, los dejó a todos atrás con su Cursor Tab. Era realmente impresionante para el estándar que teníamos en ese entonces. No solo te 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 para la lista de fechas que son feriados y escribía “productos_disponibles = [‘APV-A’, “ me autocompletaba con ‘APV-B’, ‘DC’, …, que no son conceptos que vienen de su entrenamiento, sino que del contexto del proyecto actual.
El único problema es que sus prácticas de chanta no se le pasan, así que terminaba con un nivel importante de chamullo. En el caso anterior era perfectamente esperable que para `productos_disponibles = [‘APV-A’, ` sugiriera `APV-B, APV-C, APV-D,`. Pero para cosas simples era un tremendo aporte.
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 una capa más arriba donde un agente trabaja sobre una lista interna de preguntas y respuestas que va modificando y respondiendo para llegar a una respuesta final que le 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, poca 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 le agarra la mano, a veces le decimos que no pida permiso para nada más (a esto Andrej Karpathy, uno de los fundadores de OpenAI, lo llamó vibe coding). Al principio los resultados eran al mismo tiempo impresionantes y horribles. El auto se veía como un deportivo de lujo, pero uno abría el capot y se encontraba con malas prácticas, ineficiencias, errores y cables que no se conectaban a ninguna parte. La tentación era grande de seguir pidiéndole al modelo corregir sus propios errores, pero era casi inevitable llegar a un punto donde simplemente no había vuelta. Había que borrar todo y empezar de nuevo a mano.
A medida que los modelos fueron mejorando y las herramientas 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 en este hito que el cambio se sintió fuerte e innegable. Ahora realmente uno puede avanzar extremadamente rápido cuando las piezas están claras y las instrucciones 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 aún están por descubrirse, así que me pregunto: ¿Sirve entender todavía cómo resolver un problema? Y yo creo que todavía sirve. Harto. Porque para evaluar la pega de un charlatán necesito entender cómo se resuelve el problema. Si no, no tengo cómo medir su trabajo y capaz que me apuñale por la espalda. Y mientras más astuto es el charlatán –y más poderosos los modelos– mejor tengo que entenderlo para atraparlo antes. Así que sí, todavía sirve.
