Deja de mirar el código

Los tiempos obligan a repensar qué consideramos buenas prácticas. A exprimir una herramienta se aprende usándola. Dejar de mirar código es necesario para producir sistemas que aguanten lo que viene.

“Oh, ahora ya no necesito programadores, mira mi superaplicación vibecodeada disponible en.... localhost:3000”.

El chiste está tan usado que ya da hasta vergüenza, pero se sigue viendo. Y, con todo, el pequeño atisbo de soberbia que suele acompañarlo no es lo peor. Lo peor es que yerra en el enfoque.

La intención de la broma es dejar caer, de forma más o menos velada, que no es para tanto. Que un programador sabe cosas que ese contable que se hace herramientas sencillas para casos de uso específicos necesita. Que es poco más o menos que irreemplazable. Lo dicho, que hay un poso de soberbia. “¿Cómo me va a pasar a mí, que soy ingeniero, lo mismo que a los cajeros del súper o a quienes blandían la manguera de la gasolinera?” Al palo. Quizá sea mejor ver qué pasó con los contables.

Podríamos parar aquí y dedicar el post a repetir de nuevo que los LLM son tan solo la nueva capa de abstracción sobre la que construimos; que ya no usamos software estático para hacer documentos sino software modelos y agentes para fabricar software personalizado en tiempo real. Pero not today, lo siento.

Hoy vamos a hablar directamente del trabajo de los programadores profesionales y de cómo vamos a tener que rediseñar la forma en que producimos software.

Me encanta VS Code. Uso Claude con su extensión ahí empotrado. También uso Antigravity en modo full IDE (al final es un fork, son casi idénticos). Hay algo de atavismo: me gusta ver el código, saber que si la IA comete un error podré bajar al barro y arreglarlo a mano tirando de oficio.

Algo que, por otra parte, cada vez pasa menos.

Alguna cosilla toco a mano, pero muy poco. En general los modelos más actuales implementan razonablemente bien los casos de uso cotidianos. Y si se les escapa algún detalle en sus múltiples pasadas de test... les paso la traza de error y el modelo caza el problema.

Ahora que todos somos expertos en La Odisea (y confieso que no he visto todavía la nueva película de Nolan pero ando liado con el libro), hay una escena en el Canto XIII donde Atenea, la de ojos de lechuza, se revela ante Odiseo en las playas de Ítaca. La diosa no aparece allí para sustituir la astucia del héroe, sino para ayudarle: anticipa los problemas y le ayuda a evitarlos. Odiseo no se pone a afilar lanzas en pleno combate; confía en el criterio sobrehumano de su aliada.

Nosotros estamos viviendo nuestro propio momento homérico frente al editor de código.

Pero vamos más allá: ¿y si la afición por mirar el código y tocarlo a mano fuese una mala práctica?

Para la mayoría del software que hacemos, con modelos disponibles que poseen altísimas capacidades en materia de ciberseguridad (tanto en ataque como en defensa), que detectan defectos que llevaban años escondidos ante los ojos de los mejores programadores del mundo, ¿es sensato seguir editando líneas a mano?

Este debate se parece mucho al del coche autónomo. Escribíamos en 2018 al hilo de una noticia sobre la primera víctima de un coche autónomo que la última víctima no sería noticia:

Un día los coches autónomos provocarán menos accidentes que los hasta ahora convencionales; y no será noticia porque tendemos a pasar por alto cuando las cosas sencillamente funcionan.

Y retomábamos la idea en 2023 (Tendrás coche, pero no lo conducirás):

Si el software conduce estadísticamente mejor que las personas, ¿no sería precisamente lo más ético priorizar que sea la máquina la que conduzca el coche para minimizar las víctimas?

Con datos de 2025, los vehículos autónomos producen entre un 60% y un 80% menos accidentes que los humanos (CBC). Aún más a su favor si consideramos que los coches autónomos reportan por obligación legal todos los incidentes a la policía mientras los humanos resolvemos un 30% de los roces con un parte amistoso sin que quede registro policial formal. El algoritmo nos gana aquí también.

Hay un pasaje de Criptonomicón de Neal Stephenson (ya saben, una de mis debilidades literarias) que me viene a la cabeza. Un operario, incapaz de confiar del todo en las instrucciones que recibe, introduce su propio criterio al generar unas claves que deberían ser completamente aleatorias pero dejan de serlo debido precisamente a eso. El resultado es, precisamente por eso, menos seguro.

Es una buena metáfora de lo que empieza a ocurrirnos con el código: llega un momento en que nuestra intervención manual deja de ser una garantía de calidad y puede convertirse en una fuente de errores.

Volvamos al software: llegado el momento en que el software es capaz de encontrar defectos que tú no viste y evitarlos durante la implementación antes de que lleguen a producción, ¿es buena idea que metas tus zarpas en el código? No hay que tener miedo a dejar que la máquina haga el código.

Pasa el tiempo y actualizamos la definición de lo que consideramos buenas prácticas. Eso lo sabe cualquiera que lleve suficientes trienios picando piedra. Hoy sale una librería, mañana seguir usándola te hace quedar mal (jQuery, ¡qué la tierra te sea leve!).

Empresas como Google ya empujan a sus ingenieros a no tocar código fuente a mano. Y no lo hacen por fardar ni por token maxxing. Lo hacen porque dada la pendiente de aprendizaje y desarrollo de los LLMs, lo más inteligente que podemos hacer es delegar la producción de código y centrar el intelecto humano en otra parte del proceso. Nuestro lugar en el bucle es otro: la concepción y la validación (y en tareas cuya validación sea automatizable más en la primera que en la segunda).

Esto deja dos lecciones sobre la mesa.

1. La brecha de calidad. En breve el código hecho por máquina va a ser tan superior que tú versión manual va a verse tosca. Si no eres muy top programando, seguramente para ti esto ya sea verdad.

2. El cambio de herramientas. A usar una herramienta se aprende usándola. Si la forma de crear código y operar sistemas pasa por prompts, skills, e orquestación de agentes, cuanto antes adquieras soltura en ese diálogo, antes volverás a ser relevante.

¿Dónde es mejor el humano que el bot (al menos por ahora)? Entendiendo qué hay que hacer y decidiendo hacia dónde ha de ir el producto. Se nos da sensiblemente mejor el diseño de soluciones extremo a extremo y la visión holística, mientras que la IA tiende a ir a lo microlocal y termina parcheando de mala manera si no se la supervisa.

Y todo está bien. Magnus Larssen juega al ajedrez mejor que Kasparov gracias a la inteligencia artificial. Seguiremos haciendo software, nos lo vamos a pasar en grande siendo creativos y resolviendo problemas, pero no como antes. Vamos a hacerlo de otra forma. Non ti preoccupare.

[Imágenes: Jose Alcántara con ChatGPT.]