Andrej Karpathy, uno de los fundadores de OpenAI y quien hizo funcionar el piloto automático de Tesla, dijo hace unos meses algo que me resultó sorprendente viniendo de él: que nunca se había sentido tan rezagado como programador.
No lo dijo con angustia. Lo dijo con la curiosidad de alguien que acaba de ver algo que cambia las reglas del juego. Y creo que vale la pena detenerse en eso, porque lo que describe no es una anécdota personal. Es una señal de que el paradigma cambió.
Software 1.0, 2.0, 3.0
Durante décadas programamos de la misma manera: le decíamos a la máquina exactamente qué hacer, línea a línea. Eso es el Software 1.0. Instrucciones explícitas, deterministas, sin ambigüedad.
Luego vino el Software 2.0: en lugar de escribir reglas, organizábamos datos y entrenábamos redes neuronales. Ya no programabas la lógica directamente, sino que la aprendías de los ejemplos. El código se volvió implícito.
Ahora estamos en el Software 3.0. Y aquí la palanca de programación es el lenguaje natural. Lo que pones en el contexto de un modelo de lenguaje es tu forma de instruir al intérprete. El LLM es ese intérprete. Y la pregunta ya no es qué función escribo, sino qué texto le doy a mi agente.
Eso no es solo una metáfora. Es un cambio en cómo concebimos la construcción de software. Y la mayoría de nosotros todavía está usando la mentalidad del paradigma anterior.
El momento en que algo hizo click
Karpathy describe que en diciembre pasado, durante sus vacaciones, empezó a notar algo distinto. Los fragmentos de código que pedía simplemente salían bien. Ya no tenía que corregirlos. Y siguió pidiendo más. Y seguían saliendo bien. Hasta que se dio cuenta de que no recordaba la última vez que había tenido que editar algo manualmente.
Lo que vivió no es solo una mejora cuantitativa en las herramientas. Es una transición cualitativa en el flujo de trabajo. Y creo que muchos developers estamos justo en ese borde, sin haberlo atravesado todavía, o habiéndolo cruzado sin nombrarlo.
Hay un agujero de conejo ahí adentro. Una vez que confías en el sistema, tus proyectos personales se multiplican. Las cosas que antes parecían demasiado grandes para empezarlas solas, de repente son abordables. Eso tiene un costo, claro, porque también tienes que aprender a dirigir, no solo a ejecutar.
El problema de la inteligencia irregular
Pero seamos honestos. Estos modelos son notablemente inconsistentes. Karpathy los llama "irregulares". Un modelo puede refactorizar una base de código de 100,000 líneas y encontrar vulnerabilidades de día cero, y en el mismo día decirte que camines 50 metros para lavar tu carro porque está "muy cerca".
Eso no es un error menor. Es una señal de cómo funcionan por dentro. Los modelos son entrenados con aprendizaje por refuerzo sobre dominios donde la verificación es posible: código, matemáticas, lógica formal. En esos dominios, avanzan rápidísimo. En dominios donde no hay señal de recompensa clara, el modelo navega a ciegas.
La conclusión práctica es importante: si tu problema vive dentro de los circuitos que el modelo entrenó bien, vas a volar. Si estás fuera de esos circuitos, vas a pelear. Y la única forma de saber en cuál estás es explorando. No hay manual. Hay que probar.
Vibe coding vs. ingeniería agéntica
Hay una distinción que me parece clave y que a menudo se mezcla: el vibe coding y la ingeniería agéntica no son lo mismo.
El vibe coding sube el piso. Cualquier persona, con conocimiento técnico limitado, puede construir algo funcional. Eso es enorme. Democratiza la creación de software de maneras que hace cinco años eran impensables.
Pero la ingeniería agéntica busca otra cosa: mantener los estándares de calidad del software profesional mientras usas agentes para ir más rápido. No introduces vulnerabilidades porque "el agente lo hizo". Sigues siendo responsable. Lo que cambia es la velocidad a la que puedes operar.
El techo sube, no baja. Y quienes aprenden a coordinar agentes con criterio de ingeniería son los que van a operar en ese techo. Eso requiere algo que ningún modelo tiene todavía de forma confiable: gusto, juicio, diseño.
Qué sigue valiendo la pena
Si los modelos se encargan de los detalles de las APIs, de los parámetros de las funciones, de la sintaxis específica de cada framework, ¿qué queda para nosotros?
Queda lo más difícil: entender qué estamos construyendo y por qué. Saber que hay un tensor subyacente y qué implica manipular su vista. Diseñar que los usuarios tengan un ID único y que todos los sistemas lo usen, en lugar de intentar cruzar correos electrónicos de distintas plataformas. Eso es diseño de sistemas. Eso es criterio. Y ningún modelo lo va a sustituir en el corto plazo, no porque sea imposible, sino porque nadie ha puesto esa señal de recompensa todavía.
La comprensión no se puede externalizar. Puedes delegar el pensamiento, pero no el entendimiento. Y si no entiendes qué le estás pidiendo al agente, estás firmando en blanco.
El momento en que estamos
Estamos en un punto raro. Las herramientas cambiaron de forma suficientemente profunda como para que los flujos de trabajo viejos ya no sean los óptimos, pero la mayoría del ecosistema todavía está organizado para humanos. La documentación está escrita para que la lea una persona. Los procesos de contratación evalúan si resuelves puzzles algorítmicos. Las empresas miden productividad con métricas diseñadas antes de que existieran los agentes.
Todo eso va a cambiar. Ya está cambiando. Y quienes se adapten primero no son los que abandonen el rigor técnico, sino los que aprendan a aplicarlo en este nuevo paradigma: dirigiendo agentes con la misma exigencia con la que antes escribían código.
La pregunta ya no es si sabes programar. Es si sabes dirigir.
Este artículo está basado en ideas expresadas por Andrej Karpathy en una conversación reciente sobre el estado actual del desarrollo de software y la inteligencia artificial.
Fuente: https://x.com/stephzhan/status/2049518659513852109
No comments:
Post a Comment