Cómo está cambiando la IA el desarrollo de software empresarial

[0:02] – John Burke: [música] Hola, soy John Burke, director técnico de Nemertes, y estoy aquí con mi copresentador…

[0:07] – Scott Robohn: Soy Scott Robohn, director ejecutivo de Solutional y presentador de «Total Network Operations», un programa hermano aquí en Packet Pushers.

[0:14] – John Burke: Estás escuchando «Heavy Strategy», el programa que intenta plantear las preguntas adecuadas, en lugar de dar las respuestas correctas. Hoy nos acompaña Andrew Wertkin, director de estrategia de BlueCat Networks. Andrew, gracias por estar con nosotros.

[0:25] – Andrew Wertkin: Gracias por invitarme. Estoy deseando que llegue el momento.

[0:30] – John Burke: Y en el programa de hoy vamos a hablar precisamente de lo que hablaría cualquier empresa de gestión de redes: los retos que plantea el uso de la IA para la automatización de redes empresariales. Porque todos sabemos que los profesionales de TI están adaptando la IA a la tarea de acelerar los esfuerzos de automatización de redes. ¿Por qué no es tan sencillo como parece? ¿Por qué no podemos simplemente fiar de lo que dice Claude el 99 % de las veces?

[0:50] – Scott Robohn: Sí, ya sabes, solo hay que ponerlo en modo permisivo y hacer clic en «Ir». [risas] Listo.

[0:55] – Andrew Wertkin: Sí. Sabes, es interesante, porque llevo desarrollando software desde que tengo memoria. Hay una razón por la que no sé escribir a mano: me he pasado toda la vida tecleando. Y he disfrutado muchísimo con este oficio. Pero ha sido interesante en el ámbito de las redes, porque los equipos han estado haciendo un trabajo realmente bueno. Y cuando digo «los equipos», me refiero a los ingenieros de redes que están impulsando la automatización, la generación previa de código y el uso previo de los modelos de lenguaje grande (LLM), y que realmente están intentando madurar la metodología de desarrollo de software, de forma similar a como lo hacen las empresas de desarrollo de software.

[1:37] – Andrew Wertkin: Y con la IA, y con el código generado por modelos de lenguaje grande (LLM), sin esas buenas prácticas, da un poco de miedo pensar en lo que podría pasar en la red. Así que probablemente todo se reduzca a una transformación más profunda de esos equipos hacia procesos más sofisticados en torno al desarrollo de software, porque cuanto más rápido se puedan crear cosas, más cosas pueden fallar.

[2:04] – Scott Robohn: Tienes una tesis con la que realmente me identifico, ¿verdad? Diría que otra de mis facetas es la de cofundador de una organización llamada Network Automation Forum. Y, en el momento de grabar esto, acabo de salir de nuestra última reunión, la AutoCon 5 en Múnich, Alemania. Empezamos ese debate sobre los obstáculos a la adopción de la automatización de redes antes de que la IA entrara en escena, ¿verdad? Siempre ha habido un cierto nivel de resistencia a dejar que la automatización avance a toda máquina, y ahora que los bots y los agentes están entrando en escena, se ven gestos de incredulidad y el escepticismo es fuerte.

[2:55] – Scott Robohn: Me encantaría utilizar eso como parte de nuestra conversación aquí, para decir que estoy de acuerdo contigo. Necesitamos que se desarrollen buenas prácticas en ingeniería y desarrollo de software, porque gran parte de lo que hacemos en operaciones de red es consecuencia de ello. Sé que quizá me estoy extendiendo demasiado al principio, pero esa es mi perspectiva, y tengo mucho interés en mantener este diálogo contigo.

[3:20] – John Burke: Sí, genial, y creo que has dado en el clavo. La desconfianza hacia la automatización en el ámbito de las redes viene de lejos, de hace 25 años. Nos ha salido muy mal confiar demasiado en la automatización, demasiado rápido, en numerosas ocasiones.

[3:41] – Andrew Wertkin: Sí. De lo que siempre oigo hablar es de la confianza, sobre todo en el caso de acciones repetibles y basadas en plantillas.

[3:46] – John Burke: Sí.

[3:46] – Andrew Wertkin: Si se sale de lo sencillo, repetible y basado en plantillas, ahí es donde la falta de confianza empieza a hacerse notar con fuerza. Y, como sabemos por experiencia, que un proveedor se acerque y diga: «Solo tienes que señalar y hacer clic, es una automatización sencilla y fácil», es probablemente la peor forma de ganarse la confianza del cliente final. Cuanto más opaco es, más preocupación suele generar, lo que acelera esa posible desconfianza en el mundo de la IA. No lo sé. Podemos hablar de formas de abordarlo y fomentar una mayor confianza, pero no se trata solo de las redes. Es algo que, obviamente, se aplica a todos los ámbitos.

[4:44] – Andrew Wertkin: Muchos de nosotros hemos trabajado en entornos en los que no se utilizaba el control de código fuente, en los que las revisiones no se realizaban adecuadamente, en los que el código se copiaba y pegaba de otro sitio sin analizarlo para adaptarlo al entorno actual, y así sucesivamente. Y puedes toparte con diez de esos problemas graves en un solo día si lo has acelerado.

[5:11] – Andrew Wertkin: Es muy prometedor, pero no se trata solo de desarrollo de software, ¿verdad? Se trata de depurar, de intentar averiguar qué está pasando en entornos en producción y por qué no funciona. En algunas de esas áreas, siempre que se cuente con alguien con la experiencia adecuada y se mantenga una actitud crítica ante lo que te dicen, la cantidad de trabajo que se puede realizar en poco tiempo es sencillamente asombrosa. Simplemente increíble. Siempre y cuando no te limites a decir: «Ah, has dicho que es eso, así que es eso. Vale, debería hacer esto. Debería hacer aquello». Ahí es donde radica la preocupación, porque sabemos que los LLM, por mucho que intentes orientarlos de otra manera, tienden a ser bastante tajantes al pensar que han encontrado la causa raíz.

[5:58] – John Burke: Lo que me gusta de la idea de acelerar la automatización es que vas a poder ayudar a la gente a acelerar las mejores prácticas. Si utilizan mejores prácticas con la IA, llegarán al final de sus proyectos de automatización con mayor frecuencia. No los dejarán a medias o a tres cuartos, sin depurar por completo ni documentar al 100 %, ¿verdad? Para luego pasar a la siguiente emergencia. Hay más posibilidades de que, en un solo día, o en dos días, o en una semana, o en dos semanas, sean capaces de llevarlos a buen puerto y dejar algo que realmente puedan volver a utilizar con confianza, en lugar de hacerlo con cierto temor y nerviosismo.

[6:39] – Andrew Wertkin: Sí. Sí. En gran parte se trata simplemente de arquitectura. En gran parte se trata, bueno, por un lado, de la mentalidad adecuada del desarrollador, que es: «Estoy escribiendo esto para las personas que lo mantendrán en el futuro, así que voy a tenerlo en cuenta».

[6:58] – John Burke: Eso es automático, ¿verdad? Todos los desarrolladores piensan en ello desde el primer día.

[6:58] – Andrew Wertkin: Sí. Exacto. [risas] Sí, sobre todo cuando todo empezó con: «Vaya, necesitamos un script rápido para intentar resolver este problema», y luego alguien lo encuentra seis meses después.

[7:15] – Andrew Wertkin: Así que gran parte de ello se reduce a la arquitectura. Mucho de lo que va a incluir esa automatización se repetirá, ¿verdad? ¿Cómo nos autenticamos? ¿Cuáles son los estándares en materia de registro de eventos, o cómo queremos llevar a cabo dicho registro? ¿Cómo vamos a interactuar con nuestros dispositivos? ¿Cómo se almacenan las contraseñas en el almacén seguro y cómo las recuperamos de allí? ¿Cómo queremos realizar las pruebas, o cómo debemos plantearnos revertir los cambios, o lo que sea que pueda surgir? Casi todo lo que acabo de enumerar es algo que se puede repetir con esta metodología adecuada. Entonces solo tienes que añadir tu lógica de negocio, no necesariamente todos estos otros elementos, y así todo el código se mantiene actualizado, se somete a pruebas, etcétera.

[8:01] – Andrew Wertkin: Pero es muy fácil crear algo rápidamente. Y todo lo que acabo de enumerar también parece que va a llevar más tiempo que simplemente tener a ocho personas elaborando ocho scripts o aplicaciones diferentes, totalmente funcionales y de la A a la Z, sea lo que sea lo que estemos creando. Así que probablemente sea más importante que nunca empezar con buen pie y pensar en cómo vamos a hacer que esto sea sostenible, en qué puntos intervendrán las personas y en qué casos es fundamental que lo hagan, y qué prácticas vamos a poner en marcha para hacerlo de forma segura.

[8:50] – Andrew Wertkin: Muchas de estas cosas son las mismas que siempre hemos tenido en cuenta o que nos han preocupado a la hora de desarrollar software durante las últimas décadas, ¿verdad? En parte, se trata simplemente de la rapidez con la que se puede hacer ahora. Y no se trata solo de gente que copia y pega cosas de Stack Exchange; cualquiera puede generar código que funcione en ese entorno. Es fácil de hacer, y eso no era así hace dos años.

[9:28] – Scott Robohn: Bueno, creo que nos encontramos en medio de una época experimental y de rápidos cambios, ¿verdad? Si nos remontamos solo un par de años atrás, la gente tuvo sus primeras experiencias con herramientas basadas en chat y obtuvo resultados muy dispares. Todo ese tema del no determinismo de los modelos de lenguaje grande (LLM), esa fue nuestra primera experiencia. Y luego vimos la llegada de la programación intuitiva y lo útil que resulta para la creación de prototipos, pero también el lío de espaguetis que puede generar en el código base de una empresa, y ahora tenemos metodologías emergentes como el desarrollo basado en especificaciones y el desarrollo basado en pruebas. Creo que estamos asistiendo a la aparición de una mentalidad del tipo: «Vale, así es como utilizo las herramientas, y así es como puedo generar confianza en las tecnologías», en contraposición a mi primera experiencia con ChatGPT 3.x, ¿no? ¿Qué estás observando en esos frentes, con la aparición de estas estrategias y herramientas repetibles que están surgiendo?

[10:30] – Andrew Wertkin: Sí. No, sin duda las estamos viendo, y hemos estado experimentando con algunas y adoptando un par de ellas. Creo que donde nosotros —mi empresa y yo personalmente— hemos tenido más éxito es, curiosamente, la parte a la que probablemente he dedicado menos tiempo en mi carrera (no la empresa, sino yo personalmente), que es el desarrollo inicial de especificaciones y el trabajo con el LLM sobre las compensaciones. Ahí es donde puedo aportar mi experiencia: ¿cómo deberíamos abordar esto? Dedicar ese tiempo desde el principio, desglosarlo en partes razonables y, a continuación, establecer las medidas de seguridad adecuadas; ese tipo de cosas han supuesto una transformación, en comparación con intentar escribir una instrucción que describa exactamente lo que quieres.

[11:27] – Andrew Wertkin: Es el tipo de desarrollo iterativo de especificaciones y pruebas que realmente empieza con: «Vale, quiero crear un registrador eBPF de alta velocidad», ¿verdad? Nunca lo he hecho antes, ¿verdad? Y como ni siquiera sé cuáles son las ventajas e inconvenientes, ¿hasta qué punto puedo confiar en el resultado que obtenga? Pero puedo empezar desde un nivel muy general: quiero hacer esto. ¿Cuál es tu intención?

[11:57] – John Burke: Exacto. Sí. Creo que hay un punto realmente importante un nivel por debajo de eso, y es que resulta crucial expresar con mucha claridad tus intenciones y necesidades. Cuando el software modifica los ajustes del hardware en tu red, si se modifican los ajustes equivocados se interrumpe el flujo de tráfico o se sobrecarga tanto el procesador que se producen caídas de rendimiento terribles, ya que quizá dedique todo su tiempo a generar registros y enviarlos. Así que te encuentras en un entorno en el que pueden producirse errores de infraestructura, y pueden ocurrir a la velocidad de la automatización, con consecuencias realmente enormes.

[12:47] – Andrew Wertkin: Sí. Exacto. Quiero decir que, en nuestro mundo del DNS, solo en el ámbito público, si nos fijamos en las últimas interrupciones importantes anunciadas por grandes empresas públicas, creo que el 80 % de ellas se debieron a cambios en el DNS impulsados por la automatización que lo dejaron todo fuera de servicio. Y no voy a culpar ni remotamente a un LLM por eso. Pero cuanto más rápido puedas encontrar las soluciones, y sobre todo cuanto más seguro esté tu compañero de programación, de depuración o de rendimiento —sea cual sea el caso de uso—, más probable es que acabes diciendo: «Sí, vale». Y entonces todo el mundo sufre «fatiga de permisos», y tus dedos se adelantan y sigues pulsando sin más. Así que eso también se reduce a cómo supervisamos adecuadamente el comportamiento y nos aseguramos de que esas cosas no sucedan.

[13:46] – Andrew Wertkin: Pero sí, la expresión más acertada de la intención incluye esas cosas. ¿Qué crees que podría salir mal? ¿Qué te preocupa? ¿Qué te aseguras de que se pruebe realmente? ¿Qué significa realmente «carga» en este contexto? ¿Cómo debería comportarse bajo carga? No necesitas saber todo eso desde el principio, pero es bueno tener la experiencia adecuada para conocer las categorías de aspectos que probablemente deberías tener en cuenta.

[14:21] – Andrew Wertkin: Pero lo que no hace falta hacer —y creo que esto ha madurado mucho, tanto en herramientas como en procesos, en los últimos seis meses, un periodo de tiempo increíblemente corto— es empezar escribiendo un documento de cuatro páginas con instrucciones precisas sobre qué hay que entregar. Lo haces si utilizas un modelo más económico, del tipo «run-rate», en lugar de un modelo «frontier», pero entonces basta con que un modelo «frontier» redacte las especificaciones para el modelo «run-rate». Nunca serás tan bueno como un LLM a la hora de generar instrucciones, ¿verdad?

[14:57] – Scott Robohn: Bueno, he incorporado una técnica en la que, básicamente, le pido al LLM que me entreviste. Traigo una página y media de intenciones bastante detalladas y, si utilizas este proceso para desarrollar todos los archivos Markdown adecuados para SDD, en primer lugar, sale barato. Sé que aquí hay un coste en tokens, pero estoy creando documentos legibles para humanos que puedo validar y verificar después de haber pasado por un proceso de entrevista. Y la semana pasada escuché un comentario estupendo: el código es gratis, en cierto sentido. Estamos acostumbrados a pensar que nos esforzamos por conseguir que el código sea perfecto, pero ahora les pedimos a los agentes que escriban el código, y podemos iterar y descartar lo que parece basura. Y aún así tienes que tener suficientes conocimientos del ámbito para saber que realmente es basura, ¿verdad?

[15:52] – Andrew Wertkin: Exactamente. Y ese último punto es, a nivel personal, en cierto modo mi temor de cómo estará todo dentro de 10 años, pero también es lo más importante ahora mismo. Sin el conocimiento del ámbito, y sin la experiencia y los conocimientos sobre cómo pueden fallar las cosas, cómo deberían funcionar, cómo deberían fallar de forma controlada, y un sinfín de cosas más, te estás buscando problemas. Pero sí, me gusta eso, y yo también lo hago, probablemente de una forma menos rígida que tú, pero ese tipo de: «¿En qué no estoy pensando aquí?».

[16:29] – John Burke: Exactamente. ¿Qué más podría salir mal aquí? Y cuando los modelos de lenguaje grande (LLM) están igual de dispuestos a ofrecerte la seta venenosa mortal que la seta sabrosa y comestible, y ambas parecen iguales [carraspea] a simple vista, ese tipo de conocimiento especializado se vuelve insustituible y absolutamente necesario.

[16:50] – Andrew Wertkin: Sí. Y esto es lo que ocurre, y por qué el proceso es tan importante aquí: la gente se sienta y cree que está en sintonía con el LLM, y durante un par de semanas parece que es así. Aparentemente, recuerda cosas. Pero luego, al séptimo día, empiezas una nueva sesión y parece que ha olvidado todo lo que sabía, y su rendimiento se ha ido deteriorando a lo largo de la semana porque no lo has documentado. No has guardado los recuerdos adecuados ni te has asegurado de actualizar tus indicaciones y todo lo demás. Y entonces toma una decisión increíblemente ingenua y, como humanizamos estas cosas, te asalta el pensamiento: «¿Estoy trabajando con un doppelgänger? ¿Quién es esta persona con la que estoy trabajando? ¿Cómo es posible que se haya olvidado de esto?».

[17:34] – Andrew Wertkin: Así pues, se producen muchos errores en esos momentos en los que el operador, el desarrollador, el gestor de red o quienquiera que lo utilice no tiene claro el estado de la memoria de la sesión y da por hecho que está a punto de ocurrir algo que, aunque no sea necesariamente determinista, al menos se basa en lo que hemos hecho en el pasado. Y entonces, sorpresa. ¿Y cómo llamamos a eso? En parte, es simplemente el «coste del redescubrimiento». Voy a gastar mucho dinero —en forma de tokens, créditos o lo que sea— redescubriendo lo mismo una y otra y otra vez porque no está debidamente documentado.

[18:22] – Andrew Wertkin: Y estas son cosas en las que los LLM, en general, dependiendo de la herramienta de programación, son realmente buenos. Yo suelo utilizar mucho Claude, pero, en cualquier caso, he utilizado varios. Cada vez que termino una sesión, pregunto: ¿Qué hemos hecho? ¿Qué has tenido que redescubrir? Y de lo que has tenido que redescubrir, ¿qué deberíamos documentar adecuadamente para que no tengas que volver a redescubrirlo? Y eso no es todo, porque la experimentación funciona. A veces se aprende muchísimo cuando se cometen errores.

[18:54] – Andrew Wertkin: Y quizá volviendo al aspecto personal, aunque siempre profesional, del software reforzado: software que funciona, como solemos decir, «en condiciones reales». No solo funciona en el laboratorio, ni solo en los casos ideales. Funciona. Si se le somete a presión, sigue funcionando. Llegar a ese punto requiere experiencia, no solo por haberlo hecho, sino, sobre todo, por haber fracasado al intentarlo.

[19:21] – Andrew Wertkin: Es como si algo te oliera mal porque ya cometiste ese error antes, o porque estabas presente cuando ocurrió. Y ese tipo de aprendizaje es muy específico de los enormes contextos que puede abarcar nuestro cerebro. Ni siquiera tienes que revisar tus apuntes. Detectarás ese patrón de inmediato si has tenido la experiencia de fracasar. Simplemente está integrado en nuestro cerebro. Y no sé cómo esas cosas van a suceder sin un propósito. Sin un propósito.

[20:08] – John Burke: Y a veces oigo a gente decir que no pasará mucho tiempo antes de que ni siquiera necesitemos que la IA desarrolle estos scripts o programas por nosotros. Simplemente le diremos lo que queremos que suceda. Ella ejecutará un programa en segundo plano, lo enviará y se encargará de que se haga. Y la próxima vez que lo necesitemos, generará un programa y lo enviará para que se ejecute, y ya estará hecho. Así que no será que cree automatización para nosotros; será la automatización misma.

[20:34] – Andrew Wertkin: Claro.

[20:34] – John Burke: Y, en mi opinión, creo que lo que estás diciendo ahora mismo es una réplica a eso. Es como decir: «vale, pero la segunda vez que detecte este problema y llegue el momento de generar un programa para resolverlo, ¿se acordará de cómo lo resolvió la última vez? ¿Recordará qué falló y cómo se solucionó?». Quizá sí, quizá no. Creo que hasta que ese problema no se resuelva, y se resuelva con soluciones que funcionen «en caliente», como tú dices, de modo que, por muy enfadado que esté cuando escriba la instrucción a la IA, esta me siga dando la respuesta correcta y la respuesta adecuada, entonces no estará resuelto.

[21:08] – Andrew Wertkin: Sí, entonces no está resuelto. Y lo único que iba a añadir a eso es que te encuentras con el problema contrario, porque los LLM básicamente comparan patrones. Así que, si algo parece encajar en este patrón, no significa que esa sea la respuesta. E, irónicamente, si solo tienes un par de casos de este tipo, como, ya sabes, algo falló, este es el motivo, conozco el patrón, entonces es más probable que se intente encajar algo a la fuerza en eso. Metirán a la fuerza la clavija redonda en el agujero cuadrado si casi encaja.

[21:52] – Andrew Wertkin: Y creo que sigue habiendo una cierta brecha, sobre todo en el ámbito de las redes ya existentes, entre «Vale, «solo voy a expresar mi intención, y se escribirán los scripts, se hará lo necesario, y nunca tendré que volver a ocuparme de esto»» y que eso se lleve realmente a cabo en una red empresarial, donde hoy en día no se dispone de todas las herramientas necesarias para lograrlo. Hoy en día no se dispone necesariamente del presupuesto para llevarlo a cabo. Y existe un historial, y ese historial incluye aspectos que no son positivos en el mundo de la IA, como el «conocimiento tribal» y las soluciones puntuales. Y, ya sabes, esto se hizo por una razón muy concreta, pero hay una cinta amarilla a su alrededor. Nadie sabe por qué, pero sabemos que si lo cambiamos, todo se estropea, así que ya no lo cambiamos. Esto nunca se documentó. Aquello tampoco se documentó.

[22:43] – Andrew Wertkin: Vuelvo a uno de los libros fundamentales más conocidos sobre desarrollo de software. Las herramientas y las tácticas han cambiado, pero este libro sigue siendo tan válido como siempre: «Refactoring», de Martin Fowler. Creo que en el prólogo, en los dos primeros párrafos, dice que si no puedes probarlo, devuelve este libro a la estantería. Lo estoy parafraseando, pero es algo parecido a eso: no puedes cambiarlo a menos que puedas probarlo. Y en este mundo de conocimientos tribales y casos únicos, en el que no todo sigue un patrón, ¿cómo vas a abordar eso? Especialmente si no hay nada con lo que compararlo. Tu laboratorio no cuenta con esos casos únicos. En tu laboratorio, la pregunta es: ¿cómo podemos probar esto de forma adecuada?

[23:39] – Andrew Wertkin: Y eso es lo que provoca que todo este proceso de gestión de cambios sea tan largo. La organización ha aprendido que, si tocamos eso, se va a estropear. Así que eso solo va a suceder en este tipo de ventana de cambio, en la que disponemos de tres horas y media y no se puede programar nada más durante ese intervalo. Nunca han solucionado el problema subyacente; simplemente han creado un proceso a su alrededor. Por eso, las empresas también tendrán que plantearse por dónde empezar con todo esto. Y, por decir lo obvio, lo nuevo se construye así desde el principio. Genial. Cambiar algo que ya existe, ya sea software o arquitectura de red, es mucho más difícil tanto para los humanos como para los modelos de lenguaje grandes (LLM). Pero al menos los humanos, con suerte, cuentan con algo de ese «conocimiento tribal».

[24:33] – Scott Robohn: Otra cosa emocionante que creo que tenemos ante nosotros, en relación con lo que acabas de exponer: si tengo un LLM, todo parece una instrucción, ¿verdad? Y creo que muchos de nosotros nos estamos dando cuenta de que no todo supone un problema para un LLM. Tenemos ante nosotros este conjunto de nuevas técnicas computacionales realmente interesantes y potencialmente útiles, y aún no nos hemos deshecho de todas las demás. El aprendizaje automático sigue siendo muy útil para otras cosas en el ámbito de la IA. La regresión estadística, por lo que sé, no me cuesta realmente ningún token, ¿verdad?

[25:11] – John Burke: Exacto.

[25:11] – Scott Robohn: Así que estoy ampliando mi caja de herramientas. Y el rompecabezas realmente divertido al que nos enfrentaremos todos es utilizar las herramientas adecuadas para cada tarea: los modelos de lenguaje grande (LLM) donde tengan sentido, el aprendizaje automático (ML) donde tenga sentido y la regresión donde tenga sentido. Quizá, en cuanto al problema que has mencionado, el de reinventar la rueda cada vez que surge la pregunta, parte de mis limitaciones podrían ser: vale, he resuelto un problema y lo he incluido en mi catálogo de servicios de TI. Y si hay algo en mi catálogo de servicios que se ajuste en un 90 % o más a esta solicitud, utilizar lo que hay en el catálogo de servicios y no gastar tokens en crear otra solución para ello. ¿Verdad? Y estoy improvisando un poco aquí, ¿no? Pero creo que todos estos son enfoques que debemos poner sobre la mesa mientras resolvemos esto entre todos. Y me siento mucho más optimista al respecto que escéptico. Pregúntame dentro de un año a ver si sigo pensando lo mismo.

[26:05] – Andrew Wertkin: Pues no, es interesante en lo que respecta al catálogo de servicios. Quiero decir, la buena noticia es que basta con que el LLM compruebe si ya has resuelto este problema antes y, de nuevo, son muy buenos identificando patrones. Encontrarán algo. Y, de hecho, de todas las técnicas que he desarrollado durante el último año, digamos que ese estrecho vínculo entre la documentación de lo que hice y lo que realmente hice es [resopla] muy valioso, tanto desde la perspectiva de…

[26:43] – Andrew Wertkin: Una breve anécdota. Hace muchos años, era director técnico de una empresa dedicada a la gestión del ciclo de vida de las aplicaciones. Desarrollábamos software para ayudar a crear software, y parte de nuestro perfil de cliente ideal se centraba en el software integrado relevante para la seguridad, en el que un defecto podía causar daños al operador, por ejemplo, en el sector de la automoción o en cualquier otro ámbito.

[27:08] – Andrew Wertkin: Y en ese contexto, existen todo tipo de normas, como la ISO 26262 y Automotive SPICE, y un sinfín más. Y parte de esas normas establece que debe existir trazabilidad entre los requisitos y el código, ¿verdad? Y si los requisitos cambian o el código cambia, esa trazabilidad se vuelve potencialmente problemática, y tendré que intervenir para buscar cualquiera de esos impactos. Tendré que indicar, ante este cambio, por cierto, que he modificado el código, pero que el requisito sigue siendo correcto, el caso de prueba sigue siendo correcto y la arquitectura sigue siendo correcta. Tendré que hacer eso con todos esos rastros sospechosos.

[27:38] – Andrew Wertkin: Y no vas a convencer a alguien que desarrolla software B2B de que necesita ese nivel de trazabilidad, pero yo lo hago cuando desarrollo con modelos de lenguaje grande (LLM), porque es increíble. Por un lado, bueno, sobre todo lo disfruto, pero también porque el LLM se encarga de realizar el seguimiento y puede averiguar rápidamente por qué hicimos algo de la forma en que lo hicimos, ya que puede remontarse a la documentación. Y es el propio LLM el que redacta esa documentación, y sabe cómo redactarla por sí mismo.

[28:14] – Andrew Wertkin: Eso es algo que, aunque… A veces digo: «Escribe esto para un ser humano». Otras veces digo: «Escribe este documento para un cliente que puede que conozca o no cómo funciona el desarrollo de software, o que quizá nunca haya instalado Python antes, sea cual sea el caso». Pero a menudo, con esos documentos, digo que o bien se incluya un apéndice solo para un LLM, o que simplemente se escriba pensando en un LLM. Y, en primer lugar, es más conciso; pero, en segundo lugar, los LLM son bastante buenos escribiendo documentos para que ellos mismos los lean, tanto desde el punto de vista de la eficiencia como del coste de leerlos, ¿verdad? La versión humana es más cara.

[28:57] – Andrew Wertkin: Pero, independientemente de eso, también se reduce a lo siguiente: vale, ahora, además de escribir software para que lo mantenga la siguiente persona, he incluido escribir software para que lo mantenga el próximo LLM y, obviamente, dotarlo de la capacidad de recopilar y analizar gran cantidad de texto rápidamente. Sí, nunca he tenido mejor documentación, ni en mi código ni fuera de él. Nunca habría hecho tanta documentación como ser humano, jamás, partiendo de la suposición que tienen la mayoría de las personas cuando escriben: «Sí, me acordaré de esto. Sí, esto es bastante fácil de leer. Solo tengo que leer el código, es obvio», o «Cualquiera entendería lo que quería decir con eso».

[29:46] – John Burke: Sí, exactamente.

[29:46] – Andrew Wertkin: Sí, dije «clasificando». «Estoy clasificando aquí», ya sabes. Y esas cosas provocan una cantidad enorme de defectos, pero también lo hace, a veces incluso peor… ¿Cómo dice el viejo refrán? Lo único peor que no tener conexión a Internet es tener una conexión a Internet pésima.

[30:05] – John Burke: Así es. Sí.

[30:05] – Andrew Wertkin: Sí. Lo mismo ocurre con la documentación.

[30:05] – John Burke: Así que, en cierto modo, estáis guiando a vuestra IA para que mejore su conocimiento del ámbito, enseñándole más sobre lo que supone gestionar una red física de dispositivos físicos, cuáles son los riesgos, cuáles son los límites de la experimentación, etcétera, y, al mismo tiempo, la estáis guiando para que sea un buen miembro del equipo, haciendo cosas como documentar su código y explicarse a sí misma.

[30:42] – Andrew Wertkin: Sin duda. No, es una buena analogía, porque eso es lo que suelo aconsejar a la gente, sobre todo si son veteranos: imagina que tienes a cuatro desarrolladores de software, desde principiantes hasta de nivel intermedio, trabajando contigo, que se muestran bastante seguros de sí mismos y están convencidos de que tienen razón. Así que, si uno de ellos te dijera: «Esta es la mejor forma de hacerlo», tú le responderías: «¿Por qué? ¿Qué pruebas tienes? ¿Tenemos pruebas suficientes? ¿Qué alternativas barajaste antes de llegar a esta solución?». Si piensas en tus interacciones de esta manera, siempre se te ocurrirá la pregunta adecuada.

[31:32] – Andrew Wertkin: En cuanto a su capacidad para generar código que funcione rápidamente, no se trata de un desarrollador de software junior o de nivel intermedio. Pero en cuanto al proceso de pensamiento, en muchos casos un desarrollador de software de nivel intermedio tiene un mejor proceso de pensamiento. En otras palabras, se trata del proceso de pensamiento. No se trata de la coincidencia de patrones ni de la «magia» de los modelos de lenguaje grande (LLM).

[32:00] – Andrew Wertkin: Creo que ese es el mayor error. Ya sea por sesgo, sesgo de confirmación o cualquier otra cosa, la gente busca ese tipo de respuesta positiva del tipo «así es como lo vamos a hacer». Y si dicen: «Oye, estaba pensando en esto. ¿Es una buena idea?», todos sabemos que esa es la peor forma de interactuar con un LLM, porque te responderá encantado: «Genial. Vaya. Sí, eres muy inteligente. Es la mejor forma que he oído nunca».

[32:33] – Scott Robohn: Simplemente incluye «sin adulación» en cada una de tus indicaciones.

[32:38] – Andrew Wertkin: [risas] Sí. No, al 100 %, hazlo, porque no necesito eso de mis compañeros, mis empleados ni mis padres, así que desde luego no lo necesito de un LLM. Pero sí que me gusta que mi mujer me lo diga de vez en cuando, y mis hijos, sin duda. Pero, independientemente de eso, sí. Esa idea de que tú eres el experto aquí y estás trabajando con algo que tiene menos conocimientos que tú sobre lo que quieres crear, cómo debería funcionar, cómo es el éxito y cómo ha fallado en el pasado: mantén esa mentalidad. Mantén esa mentalidad. Mantén esa mentalidad.

[33:12] – Andrew Wertkin: Y entonces, en algún momento, sientes que tienes a los cuatro mejores becarios del mundo trabajando para ti, porque para mí eso es lo que son todos ellos. Quizá cinco, a veces siete. Pero es la rapidez con la que puedes hacer esto esta misma noche: «Por favor, pon en marcha 10 agentes en paralelo». Aunque, por cierto, yo no diría «por favor». «Inicia 10 agentes en paralelo y ejecuta nuestro protocolo de pruebas relámpago». Y luego me despierto por la mañana y todo un equipo ha estado trabajando toda la noche, y no me siento culpable. Me tomo mi café y reviso los resultados. Es muy potente.

[33:51] – John Burke: Sí. Y creo que, de forma implícita, estás diciendo lo que pueden hacer proveedores como vosotros para apoyar este tipo de trabajo en los departamentos de redes de las empresas, y eso consiste básicamente en crear las herramientas potentes que esas IA puedan utilizar, con las características de seguridad adecuadas. Es como la sierra circular, que tiene un sistema de apagado automático, por lo que ya no te puedes cortar los dedos tan fácilmente como antes. Cosas así. Quieres ayudarles a que no colapsen la red por no hacer lo más obvio al utilizar tus herramientas potentes.

[34:29] – Andrew Wertkin: Sí. No, es interesante, porque, al igual que la mayoría de los proveedores de software actuales, una de las cosas que producimos son servidores MCP para nuestros productos de back-end, y tenemos varios productos de back-end. Y creo que, al igual que muchos proveedores, al principio pensábamos simplemente: «Vale, vamos a envolver nuestras herramientas OpenAPI en este nuevo protocolo y lo expondremos así, y el LLM se las arreglará». Pero te das cuenta bastante rápido de que ese no es en absoluto el enfoque adecuado. Simplemente vas a malgastar un montón de tokens. Habrá un montón de conjeturas. Te quedas ahí sentado viendo cómo el LLM adivina, adivina y adivina.

[35:03] – Andrew Wertkin: Sí, un LLM puede averiguar con bastante rapidez cómo utilizar una API REST, y si está integrado en herramientas MCP, aún más rápido. Pero eso no significa que entienda tu ámbito de especialización. Y sí, los modelos de vanguardia, en particular, se han entrenado no solo en tu ámbito de especialización; probablemente entiendan más sobre tu producto de lo que tú mismo te imaginas.

[35:33] – Andrew Wertkin: Pero parte de lo que ofrecemos no son solo herramientas más específicas del dominio que una OpenAPI. Se trata de que haya más comunicación entre el servidor MCP y nuestro servidor back-end de la que ve el LLM. Tomemos como ejemplo una captura de paquetes: no hay razón para enviar al LLM una captura de paquetes de 20 megabytes. Eso no va a servir de nada. O enviarle toda una serie temporal que deberías enviar al aprendizaje automático (ML), no a la IA. Entonces, ¿cómo le proporciono los datos que necesita? Datos resumidos, quizá incluso datos con una perspectiva propia, porque conocemos bien nuestros sistemas, así que con una especie de opiniones incorporadas.

[36:15] – Andrew Wertkin: ¿Qué necesita el LLM para responder a la pregunta del usuario, que podría haber sido: «¿Por qué no funciona esto?» Hay que reflexionar sobre esas cosas, en lugar de simplemente… Usaría la palabra «perezoso», pero «ingenuo» es más acertado. Es ingenuo dar por sentado que el LLM resolverá bien estas cuestiones, sobre todo si quieres que sean mínimamente repetibles. Así que sí, hacemos eso, pero es mucho más que eso.

[36:39] – Andrew Wertkin: Bien, acabamos de repasar los aspectos relacionados con el desarrollo de software, y ahora nuestros clientes pueden generar montones de scripts de automatización y otras soluciones para nuestros productos. Estupendo. ¿Cómo codificamos las mejores prácticas para hacerlo, de modo que nuestros clientes no provoquen tiempos de inactividad al automatizar? Para que lo sepan. Y eso se plasma en herramientas como los asesores de red y otros recursos, ya sea a través de indicaciones, código específico, funcionalidades o material formativo, que ayudan a nuestros clientes a tener éxito en la automatización. Porque en nuestro sector, en el ámbito del DDI, especialmente en el mundo del DNS y el IPAM, el motor de este sector siempre ha sido la automatización. Hay que cambiar estas cosas más rápido. Y por eso queremos que nuestros clientes tengan éxito.

[37:30] – Andrew Wertkin: Nos duele. Hace unos años, mucho antes de los LLM, tuvimos un cliente, y esto nos lleva a un ejemplo del daño que puede producirse si no existen procesos que regulen la forma de desarrollar software. Estaban, por así decirlo, aprendiendo por su cuenta a crear scripts para nuestro producto, y contaban con un usuario administrativo. Escribieron un script, fueron a probarlo y borraron todo el entorno DNS de la empresa, lo que les dejó inmediatamente sin acceso a los sistemas. Active Directory dejó de funcionar, y lo estaban utilizando para LDAP, y bla, bla, bla. Era inevitable que se rompiera el cristal.

[38:05] – Andrew Wertkin: Y ahí están, me lo puedo imaginar. Yo ya he pasado por eso. Creo que una vez, en la universidad, escribí un bucle infinito en una aplicación que se ejecutaba en un viejo PC de IBM, en el que no se podía pulsar Control-C. Tres horas de trabajo, y lo único que podía hacer era reiniciar el ordenador. Ese es uno de varios ejemplos, algunos de ellos profesionales, de esa sensación de desánimo en la que piensas «oh, mierda». [risas] Sí. Y me puedo imaginar lo que le pasaba por la cabeza a ese chico.

[38:42] – Andrew Wertkin: Y bueno, sí, obviamente ese es un ejemplo extremo, pero lo que quiero decir es que, en el desarrollo de software, siempre nos preguntan por las métricas y las mediciones, y siempre hay alguien que dice: «Bueno, vosotros solo usáis líneas de código o algo así», y eso es como…

[39:00] – Scott Robohn: Así es. Sí. La idea, para cualquiera que se dedique a la ingeniería de software, de que el número de líneas de código que escriba —cuantas más, mejor— sea una métrica adecuada es una locura.

[39:13] – Andrew Wertkin: Exacto. Nosotros no hacemos eso, y nadie lo sugiere. Pero lo que quiero decir es que, cuando empiezas a pensar en las métricas adecuadas, sin duda en el mundo del SaaS, pero ahora también en el de estos scripts, no se trata solo de eso. La pregunta es: ¿funcionó como esperábamos? ¿Fue una automatización exitosa? ¿Verdad? ¿Y qué aprendimos de lo que no salió bien, y cómo lo incorporamos para crear un ciclo de retroalimentación? Quiero decir, cuantas menos líneas de código se necesiten para resolver un problema, mejor, pero sobre todo: ¿resolvió realmente el problema?

[39:52] – Scott Robohn: Bueno, y optar por el menor número de líneas de código como otra métrica podría causar otros problemas, ¿verdad? Y, de nuevo, una de las cosas que más me entusiasma de todo este entorno y esta conversación es que el arte de especificar nuestras restricciones está cobrando mucha más importancia, probablemente más que nunca en nuestras carreras, ¿verdad? Tenemos herramientas eléctricas. ¿Dónde vamos a colocar las protecciones adecuadas para las cuchillas y el enchufe de tierra? Mi abuelo fabricaba herramientas eléctricas para Porter-Cable, y de hecho tengo algunos de sus antiguos prototipos que nunca utilizaría para construir una terraza, porque les faltan piezas que me impiden perder dedos.

[40:27] – Andrew Wertkin: Exacto. Sí.

[40:27] – Scott Robohn: Así que el enfoque sistémico, y hay un conocimiento tribal que alguien más va a…

[40:34] – Andrew Wertkin: [risas] Sin duda.

[40:40] – Scott Robohn: John, esto podría ir en muchas direcciones. ¿Por dónde quieres que sigamos?

[40:40] – John Burke: Bueno, creo que, para redondear el tema, quiero profundizar en esta idea de que la gente del sector debe empezar a pensar en su cartera de software como herramientas potentes que, en última instancia, serán manejadas por manos robóticas, no humanas, y en cómo eso va a cambiar el panorama del software empresarial. Hemos hablado un poco de cómo cambia el proceso de uso dentro de la empresa, pero ¿qué hay del resto? ¿Cambia la concesión de licencias? ¿En qué otros aspectos cambia las cosas?

[41:18] – Andrew Wertkin: Sin duda. Creo que parte de ello se debe a lo que se ha visto en el mercado de valores, y en los mercados privados en general, con la devaluación de algunas empresas de software; aunque, bueno, todos sabemos que el mercado de valores es un mundo aparte.

[41:33] – John Burke: Sí.

[41:41] – Andrew Wertkin: Pero, aparte de eso, sin duda va a cambiar los modelos de licencia. Si tu modelo de licencia se basa únicamente en el número de usuarios —y no digo que sea porque todo el mundo vaya a despedir a todo el mundo—, solo voy a decir: vale, ¿qué es un agente? ¿Es un agente un usuario? Las empresas van a tener que averiguar cuál va a ser la métrica adecuada. Muchas empresas están pasando a un sistema de créditos, y el valor real es cuánto has procesado a través de este LLM. Pero a las empresas no les gustan las facturas sorpresa cada mes.

[42:20] – Andrew Wertkin: Les gusta la coherencia. Y creo que, al principio, sobre todo las propias empresas de LLM o las de IA, están obviamente muy centradas en un modelo opaco, tipo crédito, en el que todos sabemos que el precio no va a dejar de subir y subir. Nosotros no podremos hacer eso. Los proveedores de redes no podrán entrar ahí y decir: «Vaya, lo sentimos, tu factura de este mes es el doble, porque hemos cambiado la proporción entre crédito y token. Y, por cierto, hemos mejorado nuestro producto, así que es mejor, por lo que vas a pagar más». En nuestro mundo eso no funciona así. Así que sí, creo que los modelos de licencia tendrán que cambiar.

[42:57] – Andrew Wertkin: Pero es mucho más que eso. ¿Sabes cómo siempre vamos y venimos entre «plataforma» y «lo mejor de su clase», «plataforma» y «lo mejor de su clase»? Creo que vamos a volver a inclinar la balanza hacia los «mejores de su clase», porque la interoperabilidad entre diferentes productos se ha vuelto mucho más sencilla de resolver, especialmente con soluciones como MCP. Ya no creo que sea necesaria una integración específica con los sistemas ITSM, porque todos los sistemas ITSM son compatibles con MCP.

[43:43] – Andrew Wertkin: Eso facilita la elección entre una plataforma y las mejores soluciones de su clase. Así que, en ciertos ámbitos, va a suponer una disrupción para aquellas empresas cuyo único objetivo era incluir todo lo posible en su plataforma, y con las que nadie podía competir. Eso va a cambiar, y creo que… ¿Debería entrar en detalles sobre esto?

[44:05] – John Burke: Sí.

[44:05] – Andrew Wertkin: Haré la versión de 60 segundos… la de 30 segundos.

[44:10] – Scott Robohn: 30 segundos. Sí.

[44:10] – Andrew Wertkin: Sí. Antes, en el mundo de los grandes y complicados sistemas centrales que nadie podía modificar, como los grandes sistemas ERP, las empresas solían decir en sus informes de resultados: «No hemos cumplido los objetivos este trimestre debido a una actualización fallida de este enorme sistema interno».

[44:29] – John Burke: No fue hace tanto tiempo.

[44:29] – Andrew Wertkin: Sí, no hace tanto tiempo. Y esa fue toda la campaña de marketing inicial de Salesforce, con lo de «sin software» y «nosotros nos encargamos de eso por ti» y todas esas maravillas sobre el SaaS.

[44:40] – Andrew Wertkin: En ese contexto, lo que empezó a alterar esos sistemas fue la llegada de todas estas nuevas empresas que ofrecían sistemas basados en SaaS que eran fáciles de usar. Los grandes sistemas seguían siendo el sistema de registro, pero aparecieron estos nuevos sistemas de interacción para RR. HH., para la gestión de viajes, para compras y para cualquier otra parte de ese sistema. Y entonces, por supuesto, las grandes empresas de ese sector se dedicaron a comprar esas empresas, una tras otra, tras otra y tras otra. Hasta cierto punto, no estoy del todo seguro de que se vayan a producir adquisiciones; habrá demasiadas empresas que adquirir. Veremos cómo muchas empresas presentan propuestas de valor similares a las de los «sistemas de interacción» para las plataformas existentes, con el fin de ir restando poco a poco la interacción de los usuarios o la interacción con el sistema.

[45:28] – Andrew Wertkin: Y eso va a suceder mucho más rápido de lo que ocurrió con la gestión de viajes y los objetivos en el ámbito de RR. HH., o con las compras, o con cualquiera que fueran esos sistemas de interacción que empezaron a aplicar esto a los grandes sistemas internos. Así que, en un mundo en el que es más sencillo revolucionar —o, al menos, mejorar— una pequeña parte de una plataforma existente, con la integración prácticamente lista, creo que eso nos llevará de vuelta a lo mejor de cada categoría.

[45:54] – John Burke: E incluso puedo imaginar llevar esto mucho más allá por ese camino. Solo las IA que trabajan para nosotros comprenden realmente cuál es la cartera de software actual, porque surge un nuevo servicio y ven que puede hacer la mitad de lo que necesitan en el área funcional X mejor, más rápido y más barato. Así que ahora tengo dos opciones en ese ámbito, y es la IA la que gestiona qué trabajo se asigna a cada una. Es como un enfoque de matriz redundante de proveedores de software. Simplemente elegiré la opción que mejor se adapte a los criterios que mi IA entiende que son más importantes para mí: ahorrar tiempo, ahorrar dinero, obtener un mejor rendimiento, lo que sea.

[46:36] – Scott Robohn: Sí. Interesante.

[46:42] – Andrew Wertkin: Sí. Porque si vas a cualquier feria tecnológica hoy en día, especialmente en el ámbito de las redes, pero prácticamente en cualquier área relacionada con la tecnología, verás una empresa tras otra vendiendo su plataforma de IA. No importa de dónde vengan, ahora tienen una plataforma de IA que va a ser multiproveedor. ¿Por qué no? Todo el mundo tiene servidores MCP. Entonces, ¿qué vas a tener como empresa? ¿Varias plataformas para operaciones de agentes? ¿Una única plataforma? ¿Un metaagente que gestione un montón de otras plataformas de agentes? ¿Qué pasa si elijo la incorrecta aquí, y con qué rapidez puedo cambiarla?

[47:25] – Andrew Wertkin: Y, al parecer —aunque no entiendo esta parte porque no es mi forma de trabajar—, la gente también tiende a dejarse llevar fácilmente por prejuicios: «Ah, sí, han dicho que pueden encargarse de todo esto por mí, así que voy a comprarlo sin más». Y todo se reduce a este tema. Es curioso, antes puse un ejemplo real: nunca había escrito un registrador de alta velocidad eBPF en el espacio del núcleo, y ahora lo he hecho. Sigo sin ser capaz de escribir uno. Lo utilicé como experimento: ¿qué pasaría si siguiera este proceso en un ámbito en el que conozco bien cómo funcionan las cosas, pero en el que nunca he escrito software? ¿Qué aprendería?

[48:05] – Andrew Wertkin: Lo que aprendí fue lo rápido que puedo hacer algo que antes no sabía cómo hacer. Simplemente estableciendo las cosas de las que hablábamos antes, como los criterios y los criterios de salida, y las cuestiones que me preocupan, he conseguido algo que funciona. No sé si es la mejor forma de resolver el problema con el que empecé. Lo único que sé es que es un código mantenible que funciona. Es más, sé algo más: está muy bien documentado. Así que supongo que lo que quiero decir es que la gente todavía tiene que aprender estas cosas para poder aprovechar esa experiencia.

[48:48] – Andrew Wertkin: Y, por mucho que valore esta tecnología, ese es mi mayor temor. Los peores errores siempre empiezan cuando alguien cree que tiene razón, y los demás se sienten demasiado intimidados, deslumbrados, sobrecogidos o, simplemente, demasiado perezosos para cuestionar a la persona que, sin duda, sabe cómo hacer las cosas. Y el resultado final son problemas que se podrían haber evitado. Lo vemos en todos los ámbitos, desde la tecnología hasta los entornos sociales y en cualquier otro lugar; el pensamiento de grupo, o…

[49:27] – Andrew Wertkin: Pero para eso cuento con mis expertos. Aunque a ellos les parezca correcto, de hecho, cuanto más correcto les parezca, menos probable es que se lo crean a pies juntillas, porque debe de haber algo que no cuadra. ¿Qué es? Es un rompecabezas. En muchos casos, se trata de ingenieros. Así que, por mucho que aprecie la tecnología, la utilice, la impulse y genere valor con ella, hay una parte que simplemente me incomoda.

[50:12] – John Burke: Una nota de precaución muy acertada con la que poner fin a la conversación.

[50:12] – Andrew Wertkin: Sí.

[50:18] – John Burke: Gracias, Andrew, por acompañarnos hoy. Ha sido tremendamente interesante, y hay mucho en lo que los estrategas empresariales pueden reflexionar mientras piensan en cómo avanzarán las cosas en sus departamentos de TI. Scott, muchísimas gracias también por acompañarnos hoy. Y, como siempre, gracias a todos los que nos estáis viendo.