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: Y estás escuchando «Heavy Strategy», el programa que intenta plantear las preguntas adecuadas, no 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 trataría una 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 darle a «ejecutar». [risas] Listo.

[0:55] – Andrew Wertkin: Sí. Sabes, es interesante, porque llevo desarrollando software desde que tengo uso de razón. Hay una razón por la que no sé escribir a mano: llevo toda la vida tecleando. Y he disfrutado muchísimo de este oficio. Pero ha sido interesante en lo que respecta a la red, 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 pre-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 adicional en 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 idea que me parece muy acertada, ¿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 volver 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 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, y demasiado rápido, en muchas ocasiones.

[3:41] – Andrew Wertkin: Sí. Lo que siempre oigo es «confianza», sobre todo para acciones repetitivas 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 bastante 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 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 el 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: Sin duda ofrece un enorme potencial, pero no se trata solo de desarrollo de software, ¿verdad? Se trata de depurar, de intentar averiguar qué está pasando en los entornos de producción y por qué no funciona. En algunas de esas áreas, siempre que cuentes con alguien con la experiencia adecuada y mantengas 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 indicárselos 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 buenas prácticas. Si utilizan mejores prácticas con la IA, llegarán al final de sus proyectos de automatización con más frecuencia. No los dejarán a medias o a tres cuartos, sin depurar del todo ni documentar por completo, ¿verdad? Y luego pasarán a la siguiente emergencia. Hay más posibilidades de que, en un solo día, o dos días, o una semana, o 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í. Gran parte tiene que ver simplemente con la arquitectura. Gran parte tiene que ver, bueno, por un lado, con 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: Lo cual es algo automático, ¿verdad? Todos los desarrolladores piensan en eso desde el primer día.

[6:58] – Andrew Wertkin: Sí. Exacto. [risas] Sí, sobre todo cuando todo empezó con: «Oh, 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 haber en esa automatización se repetirá, ¿verdad? ¿Cómo nos autenticamos? ¿Cuáles son las normas en materia de registro, o cómo queremos llevar a cabo el registro? ¿Cómo vamos a interactuar con nuestros dispositivos? ¿Cómo se almacenan las contraseñas en el almacén 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 se presente? Casi todo lo que acabo de enumerar es algo que se puede repetir siguiendo esta metodología adecuada. Entonces solo tienes que añadir tu lógica de negocio, sin necesidad de incluir necesariamente todas estas otras partes, 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 que elaboren ocho scripts o aplicaciones diferentes, totalmente funcionales, 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 son las mismas cosas 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 plena época de cambios rápidos y experimentación, ¿verdad? Si nos remontamos solo un par de años, 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, ¿verdad? ¿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, los estamos viendo sin duda, y hemos estado experimentando con algunos y adoptando un par de ellos. Creo que donde nosotros —mi empresa y yo personalmente— hemos tenido más éxito es, curiosamente, en la parte a la que probablemente he dedicado menos tiempo en mi carrera (no la empresa, sino yo personalmente), que es el desarrollo de especificaciones desde el principio y el trabajo con el LLM en 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? Así que ni siquiera sé cuáles son las ventajas e inconvenientes, así que, ¿hasta qué punto puedo confiar en lo que me devuelvan? Pero puedo empezar a un nivel muy general: quiero hacer esto. ¿Cuál es tu intención?

[11:57] – John Burke: Lo has pillado. Sí. Creo que hay un punto realmente importante, un nivel por debajo de eso, y es que expresar tu intención y tus necesidades con mucha claridad es crucial. Cuando el software ajusta la configuración del hardware de tu red, si se modifican los parámetros 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í. Sí. Quiero decir, en nuestro mundo del DNS, solo en el ámbito público, si nos fijamos en las últimas interrupciones importantes anunciadas por grandes corporaciones 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 modelo de lenguaje grande (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 forma más acertada de expresar la intención incluye esas cosas. ¿Qué crees que podría salir mal? ¿Qué te preocupa? ¿De qué te aseguras de que se pruebe realmente? ¿Qué significa realmente «carga» en este contexto? ¿Cómo debería comportarse bajo carga? No necesitas tener todo eso claro desde el principio, pero es bueno contar con la experiencia adecuada para saber qué tipo de aspectos 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 harías si estuvieras utilizando 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 especificaciones bastante detalladas y, si utilizas este proceso para desarrollar todos los archivos Markdown adecuados para el SDD, en primer lugar, sale barato. Sé que aquí hay un coste de 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 genial: 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: Exacto. Y ese último punto es, desde el punto de vista personal, en cierto modo mi temor a 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 elegante, 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 LLM están igual de dispuestos a traerte la seta venenosa mortal que la seta sabrosa y comestible, y parecen iguales [carraspea] a simple vista, ese tipo de experiencia en el ámbito se vuelve insustituible y absolutamente necesaria.

[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, aparentemente, se ha olvidado de todo lo que sabía, y su rendimiento ha ido empeorando a lo largo de la semana porque no lo has documentado. No has guardado los recuerdos pertinentes 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í que se producen muchos errores en esos momentos en los que el operador, el desarrollador, el operador de red o quienquiera que lo esté utilizando no tiene claro el estado de la memoria de la sesión y da por hecho que va a ocurrir algo —no necesariamente determinista, pero al menos basado 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 usar mucho Claude, pero, en cualquier caso, he utilizado varios. Cada vez que termino una sesión, pregunto: «¿Qué hemos hecho? ¿Qué habéis tenido que redescubrir? Y de lo que habéis tenido que redescubrir, ¿qué deberíamos documentar adecuadamente para que no tengáis 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 «endurecido»: software que funciona, como decimos, «en condiciones reales». No solo funciona en el laboratorio, no solo funciona en los casos ideales. Funciona. Si lo sometes a presión, sigue funcionando. Llegar a ese punto requiere experiencia, la que se adquiere al haberlo hecho, pero, sobre todo, al 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 la enorme capacidad de contexto de 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 tu mente. 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 estos programas por nosotros. Simplemente le diremos lo que queremos que suceda. Ella pondrá en marcha un programa en segundo plano, lo enviará y lo hará. 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 nos cree la automatización; 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 la réplica a eso. Es como decir: «Vale, pero la segunda vez que se encuentre con este problema y llegue el momento de generar un programa para resolverlo, ¿se acordará de cómo lo resolvió la última vez? ¿Recordará qué salió mal 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 buscan coincidencias de 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 los proyectos de reestructuración, entre «Vale, «solo voy a expresar mi intención, y se escribirán los scripts, se hará lo que haya que hacer, y nunca tendré que volver a mirarlo»» y que eso se lleve a cabo realmente 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 está rodeado de una cinta amarilla de «no pasar». 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: Así que vuelvo a uno de los libros fundamentales más conocidos del 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 todo este proceso de gestión del cambio más prolongado. 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 periodo. 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 es 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 las herramientas de 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, el análisis de regresión donde tenga sentido. Quizá para el problema que has planteado, 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: Así que 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, yo era director técnico de una empresa dedicada a la gestión del ciclo de vida de las aplicaciones. Creábamos software para ayudar a crear software, y parte de nuestro perfil de cliente ideal se centraba en el software integrado relacionado con 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 ámbito hay todo tipo de normas, como la ISO 26262 y Automotive SPICE, y un sinfín más. Y parte de esas normas consiste en que debe haber 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 y 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 trabajo en desarrollo basado en LLM, porque es increíble. Por un lado, bueno, sobre todo lo disfruto, pero también porque el LLM se encarga de rastrear 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 humano». Otras veces digo: «Escribe este documento para un cliente que puede que sepa 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 incluyan un apéndice específico para un LLM, o que simplemente lo escriban para 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 trata de 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 extraer 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 escrito tanta documentación como ser humano, jamás, partiendo de la suposición que tienen la mayoría de las personas cuando escriben: «Sí, esto me lo recordaré. 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ás enseñando a tu IA a mejorar su experiencia en el ámbito, enseñándole más sobre lo que significa 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, le estás enseñando a ser un buen miembro del equipo haciendo cosas como documentar su código y explicar su propio funcionamiento.

[30:42] – Andrew Wertkin: Por supuesto. 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 tienen bastante confianza en 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ú 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 esa 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 modelo de lenguaje grande (LLM), porque te responderá encantado: «Genial. Vaya. Sí, eres muy inteligente. Es la mejor idea que he oído nunca».

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

[32:38] – Andrew Wertkin: [risas] Sí. No, al 100 %, hazlo, porque no necesito eso de mis compañeros, de mis empleados ni de mis padres, así que desde luego no lo necesito de un LLM. Pero sí que me gusta que mi mujer lo haga 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. Quizá cinco, a veces siete. Pero es la rapidez con la que se puede 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 los proveedores como tú pueden hacer 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 manejar, con las medidas de seguridad adecuadas. Así, la sierra circular tiene un sistema de apagado automático, por lo que 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, como la mayoría de los proveedores de software hoy en día, 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: «Vale, vamos a integrar nuestras herramientas OpenAPI en este nuevo protocolo, lo expondremos y el LLM se las apañará». 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 modelo de lenguaje grande (LLM) puede averiguar bastante rápido cómo usar una API REST, y si está integrado en herramientas de 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; 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 un punto de vista propio, 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 la palabra más adecuada. Es ingenuo dar por sentado que el LLM resolverá bien estas cosas, 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 del desarrollo de software, y ahora nuestros clientes pueden generar montones de scripts de automatización y otras soluciones para nuestros productos. Genial. ¿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 elementos como los asesores de red y otras herramientas, 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 de nuevo a un ejemplo del daño que puede producirse si no hay procesos que regulen la forma de desarrollar software. Estaban, por así decirlo, aprendiendo por su cuenta a crear scripts para nuestro producto, y tenían un usuario con privilegios de administrador. 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. Tenía que romperse el cristal.

[38:05] – Andrew Wertkin: Y están ahí sentados, y me lo puedo imaginar. Yo he pasado por eso antes. 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 desasosiego de «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 escriben —cuantas más, mejor— sea una métrica adecuada es una locura.

[39:13] – Andrew Wertkin: Exacto. Pues 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 fijarse en el menor número de líneas de código como única métrica podría causar otros problemas, ¿verdad? Y, de nuevo, una de las cosas que más me entusiasma de todo este contexto 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 con toma 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: Entonces, el pensamiento sistémico, y hay un conocimiento tribal que otra persona va a…

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

[40:40] – Scott Robohn: John, esto podría ir por muchos caminos. ¿Hacia dónde quieres llevarlo?

[40:40] – John Burke: Bueno, creo que, para redondear el tema, quiero profundizar en esta idea de que la gente del sector tiene que 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 el sistema de licencias? ¿En qué otros aspectos cambia las cosas?

[41:18] – Andrew Wertkin: Sin duda. Creo que parte de ello tiene que ver con 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 deberíamos saber 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 tendrán que averiguar cuál va a ser la métrica adecuada. Muchas empresas están pasando a, vale, va a ser por 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 modelos de lenguaje grande (LLM) o las propias empresas 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 presentarse y decir: «Vaya, lo sentimos, tu factura de este mes es el doble, porque hemos cambiado la proporción entre crédito y tokens. Y, por cierto, hemos mejorado nuestro producto, así que ahora 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 estamos oscilando entre la plataforma y lo mejor de su clase, la plataforma y lo mejor de su clase? Creo que vamos a volver a inclinar la balanza hacia «lo mejor de su clase», porque la interoperabilidad entre diferentes productos se ha vuelto mucho más sencilla de resolver, sobre todo con soluciones como MCP. Ya no creo que sea necesario contar con 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 específicas. Así que, en ciertos ámbitos, va a suponer una disrupción para las 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 feos sistemas centralizados que nadie podía cambiar, 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 mala actualización de este enorme sistema interno».

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

[44:29] – Andrew Wertkin: Sí, no fue 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, la disrupción de esos sistemas se produjo cuando todas esas nuevas empresas introdujeron sistemas basados en SaaS que eran fáciles de usar. Los grandes sistemas seguían siendo el sistema de referencia, pero aparecía este nuevo sistema de interacción para RR. HH., para la gestión de viajes, para compras, para cualquier parte de ese sistema. Y entonces, por supuesto, las grandes empresas de ese sector se dedicaban a comprar esas empresas, una tras otra, tras otra, tras otra. Hasta cierto punto, no estoy del todo seguro de que se produzcan adquisiciones; habrá demasiadas empresas que adquirir. Veremos cómo muchas empresas proponen valor añadido similar al de un «sistema 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 participació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á. Solo las IA que trabajan para nosotros entienden 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 hacer 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 una especie de 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, sobre todo 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 multivendedor. ¿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? ¿Y si elijo la equivocada aquí? ¿Y con qué rapidez puedo cambiarla?

[47:25] – Andrew Wertkin: Y, al parecer —y esta parte no la entiendo porque no es mi forma de trabajar—, la gente también tiende a caer fácilmente en el sesgo: «Ah, sí, han dicho que pueden encargarse de todo esto por mí, así que me lo voy a creer 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 sí lo he hecho. Aún así, no podría 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 hacer. Simplemente estableciendo las cosas de las que hablábamos antes, como los criterios y los criterios de salida, y las cosas que me preocupan, consigo 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 sigue necesitando aprender estas cosas para poder aplicar esa experiencia en el futuro.

[48:48] – Andrew Wertkin: Y, por mucho que aprecie esta tecnología, ese es mi mayor temor. Los peores errores siempre empiezan cuando alguien cree que tiene razón, y los demás están demasiado intimidados, deslumbrados, impresionados o simplemente son 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 propensos serán a darlo por bueno sin más—, porque debe de haber algo que falla. ¿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.