Durante muchos años, en el mundo del software, el código era el activo más importante. Los artilugios que he inventado para ofuscar el código, encriptarlo, evitar que lo copien, que redistrubuyan los binarios… Como si tener una base de código secreta, extensa y robusta fuese la clave del éxito. (Y como si los clientes fueran a tener el tiempo y los conocimientos para hacerlo).
Me acaba de pasar que me pidieron recuperar una vieja función escrita hace años, algo que también implicaba traducirla a un lenguaje más moderno para simplificar compartirla por sí sola con una interfaz simple. Al final, me preguntaron cuánto me debían. Fue cuando me di cuenta que esa pieza de código vieja no valía nada, el valor era el ahorro de tiempo para el usuario que representaba usar esa función (y no, no le cobré, la preparé con ChatGPT en unos segundos y todo funcionó).
Pero hoy, después de vivir varias transformaciones tecnológicas, y sobre todo con la llegada de la inteligencia artificial generativa, es evidente que el código en sí ya no es lo valioso. Lo verdaderamente importante es saber cómo diseñar una buena solución. Cómo pensar un producto. Cómo generar valor real para las personas que lo van a usar.
Esto no significa que el código no importe, pero pasa a ser más como un plano, una receta o una partitura musical. Nadie va a decir que lo valioso de un restaurante es la receta escrita, lo valioso es el sabor, la experiencia, el ambiente, la presentación… En el software pasa lo mismo, más importante que el código escrito es el impacto que tiene.
Personalmente, no me costaría nada liberar meses enteros de trabajo como código abierto (y, de hecho, lo hice aunque no se haya vuelto popular). Porque sé que tener acceso al código no es suficiente para replicar el valor. Hay una enorme diferencia entre tener las herramientas y saber cómo usarlas, GitHub está lleno de proyectos increíbles que nadie supo usar bien. El diferencial está en el criterio, en la sensibilidad, en la capacidad de detectar qué necesita realmente un cliente y cómo resolverlo de manera simple, elegante y mantenible. El verdadero “know how”.
Diseñar software es un arte que mezcla empatía, técnica y visión de negocio, hay que entender al usuario, comprender su contexto, priorizar bien, saber cuándo conviene simplificar y cuándo invertir en una solución más robusta. También hay que saber decir que no. Muchas veces los clientes (o los propios equipos) piden features innecesarias, que terminan sumando complejidad sin aportar valor. Diseñar bien es, en parte, aprender a tomar decisiones que hacen que el producto sea más claro, más útil, más fácil de mantener.
Antes, las empresas protegían su código como si fuera oro. Hoy, muchos de los mejores productos del mundo están construidos sobre software libre. Y no solo eso, muchas empresas exitosas liberan activamente su propio código, como estrategia para ganar comunidad, reputación y colaboración. Porque entendieron que el secreto no está en esconder el cómo, sino en dominar el por qué.
Además, con la IA, estamos viendo una revolución silenciosa: Hoy se puede escribir buen código con ayuda de modelos como GitHub Copilot, ChatGPT o Claude. Pero ninguna de estas herramientas te va a decir qué vale la pena construir, para quién, cómo monetizarlo o cómo integrarlo en un sistema más grande. Eso sigue siendo terreno humano, y más que nunca, es lo que define el éxito o el fracaso de un proyecto.
Es un buen momento para volver a preguntarnos: ¿Qué estamos vendiendo realmente cuando trabajamos con software? ¿Horas de código? ¿Líneas escritas? ¿Tecnologías de moda? O estamos vendiendo soluciones, tiempo ganado, dolores evitados, oportunidades creadas…
El código, entonces, ya no es un commodity solamente porque hay mucho disponible en internet y una IA puede escribirlo. El commodity es lo que verdaderamente escasea: La capacidad de pensar bien, diseñar con criterio, ejecutar con propósito. De entender para quién estamos trabajando y por qué. Algo que se construye con experiencia, con errores, con conversaciones reales y con años de intentar resolver problemas que valgan la pena.
Así que si estás pensando en empezar un proyecto, no te obsesiones con tener el “código perfecto” o la arquitectura más sofisticada. Pensá primero en el problema, en las personas, en el impacto.