El arte de no esperar

El otro día compartí en LinkedIn un artículo que me pareció muy acertado: Software efímero: el futuro de la programación es usar y tirar. Lo leí y pensé que no hablaba de un futuro posible, sino de algo que ya vivimos: equipos que se ven abocados a resolver por su cuenta, no porque quieran quitarle trabajo al proveedor, sino porque el roadmap es ajeno, opaco y avanza a otro ritmo. Y mientras tanto la urgencia aprieta.

Todos hemos pasado por ahí. Pides una mejora “pequeña” y la respuesta es inmediata: “nadie nos ha pedido ese cambio nunca”. Como si la ausencia de tickets oficiales borrara la necesidad real. Lo pasan a desarrollo, lo valoran en comité y prometen que quizá se atienda el próximo trimestre. Mientras tanto, en los grupos de WhatsApp de usuarios, el sentir es unánime: ese botón haría falta, ese flujo ahorraría pasos, esa automatización aliviaría la tarea repetitiva que consume horas cada semana. Pero la lógica del proveedor y la del cliente rara vez coinciden, y el equipo sigue esperando. Hasta que un día alguien decide que no vale la pena seguir esperando.

La realidad es que esto no es nuevo. Desde hace décadas los usuarios se las ingenian para sobrevivir con lo que tienen a mano. Ahí están las macros de Excel, los atajos con VBScript, las recetas en Power Automate, los scripts sueltos en Python, los atajos con AutoHotkey. Piezas improvisadas que aliviaban la carga diaria sin pedir permiso a nadie. Siempre hubo alguien en la oficina que sabía “trucar” el sistema, el perfil que hacía magia con fórmulas o atajos, el que conectaba dos aplicaciones a base de cinta aislante digital.

La diferencia es que hoy esas herramientas han dado un salto cualitativo. No hace falta picar código ni entender la sintaxis: basta con describir lo que quieres y dejar que la IA complete el resto. Lo que Karpathy bautizó como vibe coding es justo eso: conversar con la máquina hasta que algo funciona. Y cuando funciona, la sensación es la misma de siempre, solo que multiplicada: alivio inmediato, ahorro en tiempo y energía, independencia frente a un proveedor que no se mueve al mismo ritmo.

Porque el coste de montar un apaño rápido es menor que el de seguir repitiendo la tarea absurda, y mucho menor que el de encargar un desarrollo formal. No es cuestión de preferencias, es pura supervivencia. Si el problema se resuelve hoy con un flujo casero, lo hacemos. Aunque sepamos que no es “lo correcto”.

Lo delicado viene después. Lo que nació como experimento temporal puede quedarse demasiado tiempo. Un script improvisado se convierte en parte del proceso, una automatización casera empieza a ser crítica… y de pronto lo efímero se incrusta en la operación como si siempre hubiera estado ahí. Entonces aparecen las preguntas: ¿quién lo mantiene?, ¿qué pasa si falla?, ¿cómo se explica a alguien nuevo? El problema no es improvisar, sino olvidar que improvisamos.

Por eso me interesaba aquel artículo. No tanto por la definición de software efímero, sino porque ayuda a mirar el dilema desde los dos lados. Para los desarrolladores, entender que hay clientes que no pueden (ni quieren) esperar siempre. Y para los clientes, asumir que se puede resolver con medios propios, pero que cada apaño tiene un coste oculto en memoria y en responsabilidad futura.

La paradoja es vieja: antes el Excel lleno de macros, hoy el flujo en n8n con ayuda de la IA. Antes un script en AHK para simular teclas, hoy un prompt a ChatGPT que devuelve un bot funcional. La diferencia es que la economía del apaño se ha abaratado tanto que ya no es un recurso marginal, sino un hábito cotidiano. Lo que antes hacían dos frikis en un departamento hoy lo puede hacer cualquier equipo con un mínimo de curiosidad y una tarde libre.

No todo merece un producto bien hecho, como tampoco todo puede sostenerse con parches. Entre la catedral y el refugio de cartón hay espacio para soluciones rápidas que cumplen su función y desaparecen después. Lo difícil es no confundirlas con casas permanentes.

Quizá el verdadero reto no sea programar más rápido, sino aprender a limpiar. Decidir qué merece quedarse y qué debe desaparecer a tiempo. Dejar claro, aunque sea en una nota, por qué hicimos algo y cuándo conviene borrarlo sin remordimientos.

Lo urgente siempre gana a lo perfecto, y cada vez tenemos más medios para no esperar. La pregunta es cómo convivir con ello sin engañarnos: que lo efímero es legítimo, sí, pero solo si recordamos que era efímero… y solo si no caemos en la tentación de dejar que la máquina piense por nosotros.

Y entonces aparecen dudas que no son técnicas, sino culturales. ¿Es productiva una persona que dedica parte de su tiempo laboral a crear estas herramientas que su proveedor no le da? ¿Es productivo un equipo que depende de apaños que nunca llegan a convertirse en producto? ¿Están los programas preparados para vivir en una época en la que los clientes ya no esperan?

Preguntas que, en el fondo, dialogan con lo que escribía en Piensa conmigo, no por mí: porque no se trata solo de resolver deprisa, tampoco de delegarlo todo en la máquina, sino de encontrar el lugar donde nuestra pericia y la urgencia conviven sin que se pierda lo esencial.