[11/11/2023] Todo desarrollador de software conoce el sueño. Nos sentamos en algunas poltronas junto a la piscina, mientras la inteligencia artificial y las capas sin código mantienen el stack empresarial funcionando sin problemas. Quizás tengamos el capricho o la necesidad de rediseñar alguna sección de la aplicación web, o tal vez incluso refactorizar todo por completo. Sin levantar la cabeza, simplemente pronunciamos algún comando y la generación automática de código hace todo bien. Voilà. Hemos hecho nuestro trabajo del trimestre y ahora podemos realmente relajarnos.
Ja. Ninguna de estas herramientas funciona tan bien. Oh, a menudo hacen algunas cosas bien. De vez en cuando, completarán correctamente el código o ajustarán los parámetros para manejar con éxito la nueva carga. Hay muchas formas en que la inteligencia artificial y las innovaciones en codificación nos hacen la vida más fácil.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Pero normalmente son geniales hasta que fallan, lo cual ocurre con demasiada frecuencia. Esta mañana pasé una hora hablando por teléfono con el registrador de mi dominio porque mi simple cambio a un registro DMARC no funcionaba. Oh, la aplicación web me afirmó que el cambio se realizó con éxito hace 48 horas, pero eso no significa que su maquinaria estuviera compartiendo este nuevo valor de DNS con el mundo. No. Así que estoy buscando un nuevo registrador mientras su personal de soporte técnico intenta descubrir qué está pasando.
Es un poco como la ley de Newton. Por cada cosa maravillosa que hace la automatización, hay un ejemplo igual y opuesto de cómo la automatización se equivocó. Estas fuerzas no siempre son simétricas porque la automatización suele funcionar bien la mayor parte del tiempo. Es sólo que cuando uno le quita la vista o se va de vacaciones, la automatización encuentra la manera de volverse completamente loca.
Con el fin de desahogarnos un poco y tal vez ayudarnos a abordar la automatización con más cautela y menos desánimo, hagamos una breve pausa para una reevaluación con ojos de acero. A continuación, seis formas en las que la inteligencia artificial que nos ahorra trabajo, el maravilloso 'sin código' y otras inteligencias avanzadas pueden salir mal.
Recoger basura
En teoría, la asignación de memoria no es algo por lo que los genios humanos deban preocuparse. Los lenguajes modernos tienen una capa que reparte trozos de memoria, y luego los barre cuando los datos que contienen ya no son necesarios. Los recolectores de basura permiten a los programadores pensar en cosas más importantes, como el valor de sus opciones de acciones.
Y los recolectores de basura normalmente funcionan bastante bien, excepto en los márgenes. Debido a que funcionan automáticamente, se podría pensar que las pérdidas de memoria son cosa del pasado. Ciertamente son menos comunes, pero los programadores aún pueden asignar bloques de memoria de manera que los recolectores de basura no los toquen. Para empeorar las cosas, los programadores ya no creen que sea su responsabilidad preocuparse por las pérdidas de memoria; por lo que, en lugar de buscar una mala asignación, a menudo simplemente se dan por vencidos y aumentan la cantidad de RAM en su servidor en la nube. ¿Cuánta RAM de la nube está llena de estructuras de datos que podrían haberse liberado?
Hay otros problemas con la gestión automatizada de la memoria. La asignación de objetos es una de las mayores pérdidas 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 lo siguen reutilizando. En otras palabras, configure las cosas para que el recolector de basura no haga nada.
Y luego está el problema general de que la recolección de basura siempre parece ocurrir en el momento más inconveniente. Las rutinas de automatización simplemente entran en acción, sin forma de saber o preocuparse si la latencia y el retraso arruinarán su experiencia. 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 cuándo se producirá el problema de la recolección de basura.
Código interpretado
Los distintos lenguajes de programación han hecho que sea mucho más sencillo eliminar unas pocas líneas de código. Su relativa simplicidad y amabilidad se han ganado muchos fanáticos, no solo entre los programadores de tiempo completo, sino también en campos relacionados como la ciencia de datos. Hay una razón por la que Python es ahora uno de los lenguajes de programación más enseñados.
Aun así, la dosis adicional de automatización que hace que estos lenguajes interpretados sean más fáciles de usar también puede generar ineficiencias y problemas de seguridad. Los lenguajes interpretados suelen ser más lentos, a veces radicalmente. La combinación de administración automatizada de memoria, poco tiempo para la optimización y el trabajo general de interpretación del tiempo de ejecución pueden realmente ralentizar su código.
La velocidad ha mejorado a medida que los programadores descubrieron cómo aprovechar el poder de las implementaciones de tiempo de ejecución alternativas o los buenos compiladores justo a tiempo (JIT, por sus siglas en inglés). Los desarrolladores de Python han recurrido a empresas como Cython, Jython, Numba, PyPy, Pyston y ahora Pyjion para lograr una ejecución más rápida. Pero todavía existen límites a lo que puede hacer un intérprete.
Algunos afirman que el código interpretado es menos seguro. Los compiladores podrían entonces dedicar más tiempo a examinar el código mientras el intérprete va en la dirección opuesta, esforzándose por mantener sus resultados "justo a tiempo”. Además, la escritura 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 puede ser igualmente vulnerable. Todos los programadores deben estar atentos, sin importar el lenguaje que utilicen.
La inteligencia artificial
La inteligencia artificial es un tema mucho más amplio que la automatización, y he discutido los diversos oscuros secretos y limitaciones de la inteligencia artificial en otros lugares. Los problemas son simples de entender. Si bien las inteligencias artificiales pueden ser milagros modernos que son mejores de lo que nadie esperaba, a menudo producen resultados insípidos y regurgitados, completamente carentes de espíritu o individualidad. Y eso tiene sentido porque los modelos de lenguaje grandes (LLM, por sus siglas en inglés) son esencialmente promedios masivos de su conjunto de entrenamiento.
A veces, la inteligencia artificial empeora las cosas y genera errores aleatorios que surgen de la nada. El sistema ametralla oraciones gramaticalmente perfectas y párrafos bien estructurados hasta que -espera, ¿qué?- de repente alucina un hecho inventado. Para empeorar las cosas, la inteligencia artificial a veces arroja calumnias, calumnias y calumnias sobre personas reales que viven, respiran y son potencialmente litigantes. Ups.
El mejor uso de la inteligencia artificial parece ser como un asistente no tan inteligente para humanos más inteligentes y ágiles, que pueden mantener al genio automatizado bajo control.
Consultas de bases de datos
En teoría, las bases de datos son la herramienta automatizada original que puede mantener todos nuestros bits en tablas estructuradas y agradables, y responder nuestras preguntas en cualquier momento que queramos. Oracle incluso puso la etiqueta "autónoma” en su base de datos para enfatizar cuán automatizado estaba todo. La empresa moderna no podría funcionar sin la magia de las grandes bases de datos. Necesitamos su poder puro. Lo que pasa es que los equipos de desarrollo aprenden rápidamente sus limitaciones.
A veces, los motores de consulta sofisticados son demasiado potentes para su propio bien, como cuando los programadores crean consultas que tardan una eternidad en completarse. Escribir consultas SQL simples no es especialmente difícil, pero puede resultar muy difícil escribir una consulta compleja que también sea eficiente. Toda la automatización invertida en el almacenamiento y la recuperación les da a los desarrolladores la cuerda suficiente para atar su código.
Algunos equipos pueden permitirse el lujo de 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 problemas. Cuando llega el momento de crear una consulta SQL con más de una cláusula, saben cómo hacerlo de manera inteligente, para que la máquina no se detenga.
Plataformas de código bajo y sin código
Algunas herramientas, portales y aplicaciones web empresariales ahora son lo suficientemente sofisticados como para modificarlos sobre la marcha, con poca o ninguna programación nueva. A los equipos de ventas les gusta llamar a esta función "código bajo” o incluso "sin código”. No es inexacto porque el nivel de automatización es bastante hábil. Pero todavía hay algunos dolores de cabeza incluidos en el paquete.
El mayor problema es el mismo que enfrenta la industria de la confección, donde los clientes saben que "una talla les queda a todos” en realidad significa "una talla no le queda a nadie”. Cada empresa es un poco diferente, por lo que cada almacén de datos, canal de procesamiento e interfaz también deberían 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 cualquier cosa que cualquier usuario potencial pueda lanzarle. Comprueba constantemente los datos antes de formatearlos y reformatearlos. Todo el código adhesivo que conecta el front end y el back end debe ejecutarse, a menudo cada vez que llegan nuevos datos. Esto aumenta los costes del hardware y, a veces, ralentiza todo.
Incluso una automatización lenta puede ahorrar tanto tiempo y gastos de desarrollo que muchos equipos simplemente tendrán que ingeniárselas, en lugar de contratar personal para un proyecto destinado a construir el stack de la manera correcta. Pero arreglárselas significa vivir con algo que realmente no encaja y, a menudo, es un poco más complicado y costoso de administrar.
Automatización del flujo de trabajo (RPA)
Un primo del desarrollo con código bajo y sin código es la RPA, o automatización robótica de procesos. Tenga en cuenta que no hay robots de calidad cinematográfica a la vista. Estas herramientas han encontrado un lugar en las oficinas porque son expertas en aplicar inteligencia artificial a tareas administrativas comunes, como hacer malabarismos con los documentos. Desafortunadamente, la RPA tiene todos los problemas potenciales tanto de la inteligencia artificial como del código bajo.
Un gran punto a favor de las RPA es que pueden incorporar una interfaz moderna a stacks previos y, al mismo tiempo, agregar un poco de integración. Esta 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 el interior está lleno de estructuras de datos y algoritmos que datan de la era de las tarjetas perforadas y los tubos de vacío. La RPA es como pegar cinta adhesiva técnica a un código que apenas se ejecuta.
El verdadero peligro surge 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, podrían darle tiempo a un procesador humano para notar si hay algún problema con una factura o un pedido. Ahora, algún administrador simplemente inicia sesión y hace clic en el botón "aprobar todo”. Poco a poco, el fraude y los errores empiezan a acumularse, a medida que se erosionan los controles y contrapesos de los procedimientos tradicionales de oficina. La única persona que queda --a tiempo parcial, por supuesto-- carece de las herramientas y la visión para comprender lo que está sucediendo 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 aceptar las dificultades y utilizar lo que sabemos sobre ellas para planificar estratégicamente. En otras palabras, tener en cuenta los inconvenientes al tiempo que intentamos evitarlos o encontrar una solución mejor. Lo único peor que la fe ciega en el progreso es la falta de progreso.
Basado en el artículo de Peter Wayner (InfoWorld) y editado por CIO Perú