[05/10/2023] ¿Quién no ha soñado alguna vez con estar tranquilamente junto a una piscina mientras las IA y las herramientas de bajo código mantienen la pila de la empresa funcionando sin problemas? Quizás por capricho, hemos decidido rediseñar una sección de nuestra última aplicación web popular. Sin abandonar el borde de la piscina, pronunciamos unos cuantos comandos. El código que necesitamos se genera y se lanza a la perfección, con todo bien hecho. Y ya está: nuestro trabajo del trimestre ha terminado. Ahora podemos relajarnos de verdad.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Es una bonita visión, pero la realidad actual se parece más a un chapuzón en la cara. Ninguna de las herramientas existentes funciona lo suficientemente bien como para ejecutarla sin una considerable interacción humana. A veces lo hacen bien. Un completado de código simplemente funciona, o una secuencia automatizada ajusta los parámetros de carga del servidor sobre la marcha. Podemos estar agradecidos por esos momentos en los que herramientas útiles nos facilitan la vida.
Pero esas herramientas y automatizaciones fallan, y cuando lo hacen, los resultados van de inconvenientes a catastróficos. Esta mañana, he pasado tiempo al teléfono con el registrador de mi dominio porque un simple cambio en un registro DMARC no funcionaba. La aplicación web afirmaba que el cambio se había realizado, pero el sistema no había compartido el nuevo valor DNS con el mundo. No importaba lo que intentaran los administradores, el sistema no cedía. Así que estoy buscando un nuevo registrador mientras el servicio técnico intenta averiguar qué está pasando.
Por cada cosa maravillosa que hace la automatización, hay un ejemplo igual y opuesto de cómo la fastidia. La automatización funciona la mayor parte del tiempo, así que la relación no es completamente simétrica. Pero es justo cuando quita las manos del volante (o se va de vacaciones) cuando estos sistemas parecen volverse locos.
He aquí seis formas en las que la automatización puede descarrilar.
Recogida de basura
En teoría, la asignación de memoria no es algo de lo que los genios humanos debamos preocuparnos. La mayoría de los lenguajes modernos tienen una capa que reparte trozos de memoria y luego los barre cuando los datos que contienen ya no son necesarios. Se dice que un buen recolector de basura libera a los programadores para que puedan pensar en cosas más importantes, como el valor de sus opciones sobre acciones.
Como la recolección de basura es automática, cabría esperar que las fugas de memoria fueran cosa del pasado. Desde luego, son menos frecuentes que antes. Pero los programadores todavía pueden asignar bloques de datos de forma que el recolector de basura los ignore. Y lo que es peor, los programadores ya no creen que sea su responsabilidad preocuparse por las fugas de memoria; ¡esa es tarea del recolector de basura! Así que, en lugar de buscar los datos mal asignados, se limitan a aumentar la cantidad de RAM en el servidor de la nube. ¿Qué parte de la RAM de la nube está llena de estructuras de datos que deberían haberse liberado?
Hay otros problemas con la gestión automatizada de la memoria. La asignación de objetos es uno de los mayores sumideros de tiempo para el código, y los programadores inteligentes han aprendido que el código se ejecuta más rápido si asignan un objeto al inicio del programa y luego siguen reutilizándolo. En otras palabras, configurar las cosas para que el recolector de basura no haga nada.
Como problema más general, ¿por qué la recolección de basura siempre parece ocurrir en el momento más inoportuno? Las rutinas de automatización garantizan que se produzca en el momento justo, y el recolector de basura no tiene forma de saber (o de preocuparse) si la latencia y el retraso arruinarán la experiencia del usuario. Los desarrolladores que crean interfaces de usuario o código que debe ejecutarse, por ejemplo, en hardware médico, tienen buenas razones para preocuparse por la sincronización de la recogida de basura.
Código interpretado
Los distintos lenguajes de programación han facilitado la codificación y han simplificado la creación de unas pocas líneas de código. Su relativa sencillez y su enfoque básico han ganado muchos adeptos, no sólo entre los programadores a tiempo completo, sino también en campos relacionados como la ciencia de datos. Por algo Python es ahora uno de los lenguajes de programación más enseñados.
Aun así, la automatización que facilita el uso de estos lenguajes interpretados también puede traer consigo ineficiencias y problemas de seguridad. Los lenguajes interpretados suelen ser más lentos, a veces drásticamente. La combinación de la gestión automatizada de la memoria, el poco tiempo para la optimización y la lentitud general de la interpretación en tiempo de ejecución puede ralentizar mucho el código.
Aprovechar la potencia de un buen compilador Just-in-Time (JIT) puede mejorar las cosas. Los desarrolladores de Python pueden utilizar Jython, que tiene incorporado un compilador JIT basado en Java. PHP y Python también tienen sus propios compiladores JIT -PyPy, Numba y Pyston, por nombrar algunos-, pero sigue habiendo límites a lo que puede hacer el intérprete.
Algunos dicen que el código interpretado es menos seguro. Los compiladores podrían dedicar más tiempo a escudriñar el código, mientras que el intérprete va en dirección contraria, esforzándose por mantener sus resultados "justo a tiempo". Además, la tipificación dinámica popular en los lenguajes interpretados puede facilitar la ejecución de ataques de inyección u otros esquemas. Por supuesto, el código compilado es a veces igual de vulnerable. Todos los programadores deben estar alerta, independientemente del lenguaje que utilicen.
Inteligencia artificial
La inteligencia artificial es un tema mucho más amplio que la automatización, y ya he hablado en otras ocasiones de los oscuros secretos y limitaciones de la IA. Aunque las IA pueden celebrarse como milagros modernos que son mejores de lo que nadie esperaba, sus resultados suelen ser insípidos y regurgitados una vez que pasa la novedad. Esto tiene sentido porque los grandes modelos lingüísticos (LLM, por sus siglas en inglés) son esencialmente promedios masivos de su conjunto de entrenamiento.
A veces, la IA empeora las cosas lanzando errores aleatorios. El sistema está escribiendo frases gramaticalmente perfectas y párrafos bien estructurados hasta que, espera, ¿qué? Para empeorar las cosas, la IA a veces suelta injurias, difamaciones y calumnias sobre personas vivas, que respiran y que son potencialmente litigantes. Vaya.
El mejor uso de las IA parece ser el de asistente no tan inteligente para humanos más ágiles e inteligentes, que pueden mantener a raya a este genio automatizado.
Consultas a bases de datos
En teoría, las bases de datos son la herramienta automatizada original que puede guardar todos nuestros datos en tablas estructuradas y responder a nuestras preguntas cuando queramos. Oracle incluso le puso la etiqueta de "autónoma" a su base de datos para enfatizar lo automatizado que estaba todo. La empresa moderna no podría funcionar sin la magia de las grandes bases de datos. Necesitamos su potencia bruta. Lo que ocurre es que los equipos de desarrollo aprenden rápidamente sus limitaciones.
A veces, los motores de consulta son demasiado potentes para su propio bien, como cuando los programadores crean consultas que tardan una eternidad en completarse. Escribir consultas SQL sencillas no es especialmente difícil, pero puede resultar muy complicado escribir una consulta compleja que además sea eficiente. Toda la automatización empleada en el almacenamiento y la recuperación da a los programadores la cuerda suficiente para atar su código con nudos.
Algunos equipos pueden permitirse contratar administradores de bases de datos especializados para que los bits fluyan sin problemas. Estos especialistas ajustarán los parámetros y se asegurarán de que haya suficiente RAM para manejar los índices sin que se produzcan colapsos. Cuando llega el momento de crear una consulta SQL con más de una cláusula, saben cómo hacerlo de forma inteligente, para que la máquina no se detenga.
Automatización de plataformas de código bajo
Algunas herramientas empresariales, portales y aplicaciones web son ahora lo suficientemente sofisticadas como para adaptarse sobre la marcha, con poca o ninguna programación nueva. A los equipos de ventas les gusta llamar a esta característica "código bajo" o incluso "sin código". No es inexacto, porque el nivel de automatización es bastante hábil. Pero el paquete no está exento de algunos quebraderos de cabeza.
El mayor problema es el mismo al que se enfrenta la industria de la ropa, donde los clientes saben que "talla única" significa en realidad "talla única". Cada empresa es un poco diferente, por lo que cada almacén de datos, canal de procesamiento e interfaz también deben ser diferentes. Sin embargo, las opciones de código bajo y sin código ofrecen un sistema generalizado. Cualquier personalización tiende a ser superficial.
Este código generalizado suele ser mucho más lento porque tiene que estar preparado para todo. Está constantemente comprobando los datos antes de formatearlos y reformatearlos. Todo el código de cola que se conecta automáticamente tiene que ejecutarse, a menudo cada vez que llegan nuevos datos. Esto dispara los costos de hardware y a veces lo ralentiza todo.
Muchos equipos harán que funcione incluso la automatización lenta, porque es más fácil y mucho más barato que dotar de personal a un proyecto para construir la pila. Pero esto significa vivir con algo que realmente no encaja y que a menudo es un poco más cutre y más caro de ejecutar.
Automatización del flujo de trabajo (RPA)
Un primo del desarrollo de código bajo y sin código es RPA, o automatización robótica de procesos. Tenga en cuenta que no hay robots de película a la vista. Las herramientas han encontrado un hogar en las oficinas porque son útiles para aplicar la IA a tareas administrativas comunes, como hacer malabares con documentos. Por desgracia, estas herramientas tienen todos los problemas potenciales de la IA y del código bajo.
Uno de los grandes argumentos de venta de los RPA es que pueden dotar de una interfaz moderna a las pilas heredadas, al tiempo que añaden un poco de integración. Puede ser una forma rápida de poner una cara bonita sin cambiar nada del código antiguo. Por supuesto, también significa que el código antiguo no se actualiza ni se reescribe según los estándares modernos, por lo que las entrañas están repletas de estructuras de datos y algoritmos que datan de la era de las tarjetas perforadas. RPA es como poner cinta aislante técnica en un código que apenas funciona.
El verdadero peligro llega cuando el software funciona lo suficientemente bien como para adormecer a los humanos. La automatización se encarga de los pasos manuales que, de otro modo, darían tiempo a un procesador humano para darse cuenta de si hay algo mal en una factura o un pedido. Ahora, algún gestor se limita a iniciar sesión y pulsar el botón "aprobar todo". Poco a poco, los fraudes y errores empiezan a acumularse, a medida que se erosionan los controles y equilibrios de los procedimientos tradicionales de oficina. La única persona que queda -a tiempo parcial, por supuesto- carece de las herramientas y los conocimientos necesarios para comprender lo que está ocurriendo antes de que sea demasiado tarde.
Automatización cero
Lo único peor que añadir más automatización es no añadir ninguna. La deuda técnica nunca se soluciona. La pila de software se queda tan obsoleta que ya no merece la pena actualizarla. A medida que la pila se osifica lentamente, también lo hace todo el mundo en la oficina. La empresa se queda atascada haciendo las cosas como siempre se han hecho. La pila de software gobierna el flujo de trabajo.
Está muy bien quejarse y tomar nota de cómo falla la automatización del software, pero a veces lo mejor es utilizar lo que sabemos sobre las trampas para planificar estratégicamente. En otras palabras, hay que tener en cuenta los inconvenientes y tratar de evitarlos o encontrar una solución mejor. Lo único peor que el progreso es la falta de progreso.
Basado en el artículo de Peter Wayner (InfoWorld) y editado por CIO Perú
Peter Wayner es autor de más de 16 libros sobre diversos temas, como software de código abierto ("Free for All"), coches autónomos ("Future Ride"), computación con privacidad mejorada ("Translucent Databases"), transacciones digitales ("Digital Cash") y esteganografía ("Disappearing Cryptography").