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

HS136 – Patrocinado por Bluecat

[John Burke] (0:00 – 0:05)

Hola, soy John Burke, director técnico de Nemertes, y estoy aquí con mi copresentador.

[Scott Robohn] (0:05 – 0:14)

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

[John Burke] (0:16 – 0:28)

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.

[Andrew Wertkin] (0:28 – 0:30)

Gracias por invitarme. Estoy deseando que llegue el momento.

[John Burke] (0:30 – 0:52)

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?

[Andrew Wertkin] (0:54 – 2:08)

Sí, solo hay que ponerlo en modo permisivo y hacer clic en «Ir». Listo. Sí, ya sabes, es interesante porque, bueno, llevo desarrollando software desde que tengo uso de razón. Ya sabes, hay una razón por la que no sé escribir. Llevo toda la vida tecleando. Y he disfrutado muchísimo con este oficio. Pero, ya sabes, 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 red que están impulsando la automatización, como, ya sabes, la generación de código previa, antes de los modelos de lenguaje (LM), y que realmente intentan, por así decirlo, madurar la metodología de desarrollo de software de forma similar a como lo hacen las empresas de desarrollo de software. Y con la IA y con el código impulsado o generado por modelos de lenguaje (LM), sin esas buenas prácticas, da un poco de miedo pensar en lo que podría pasar en la red. Así que, ya sabes, probablemente todo se reduzca a una transformación más profunda en esos equipos hacia procesos más sofisticados en torno al desarrollo de software, porque cuanto más rápido se pueda crear algo, más cosas pueden fallar, probablemente.

[Scott Robohn] (2:09 – 3:24)

Tienes una idea que realmente me llega, ¿verdad? Diría que, ya sabes, 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, AutoCon 5, en Múnich, Alemania.

Y, ya sabes, empezamos ese debate sobre la reticencia a adoptar la automatización de redes antes de que la IA entrara en escena, ¿verdad? Así que siempre ha habido cierto nivel de resistencia a dejar que la automatización vaya a toda máquina. Y ahora, ya sabes, los bots y los agentes están entrando en escena y, ya sabes, se están poniendo los ojos en blanco y el escepticismo es fuerte. Me encantaría utilizar eso como parte de nuestra conversación aquí para decir: «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 eso. 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.

[John Burke] (3:24 – 3:42)

Sí, genial. Y creo que tienes toda la razón. El problema de la desconfianza hacia la automatización en el ámbito de las redes viene de hace 25 años. Quiero decir, nos ha salido mal. Nos ha salido muy mal por confiar en la automatización en exceso y demasiado rápido, muchas veces.

[Andrew Wertkin] (3:43 – 6:00)

Sí, lo que siempre oigo hablar es de confianza, sobre todo en el caso de acciones repetibles y basadas en plantillas. Sí. Si se sale de lo sencillo, repetible y basado en plantillas, entonces, sí, ahí es donde empieza a surgir esa falta de confianza, y se hace bastante patente. Y, ya sabes, como bien sabemos, nuestros colegas, que un proveedor venga diciendo «solo tienes que señalar y hacer clic», una automatización sencilla y fácil, es probablemente la peor forma de ganarse la confianza del cliente final. Ya sabes, cuanto más opaco es, más preocupación suele haber, lo cual, sí, es, ya sabes, lo que impulsa, simplemente acelera esa posible desconfianza en el mundo de la IA, ya sabes, y no sé, bueno, podemos hablar de formas de abordarlo y fomentar más confianza, pero, ya sabes, no se limita solo a las redes y a la infraestructura de red, ya sabes, es obviamente algo generalizado. Ya sabes, muchos de nosotros hemos trabajado en entornos en los que no se utilizaba el control de código fuente, en los que, ya sabes, 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 podría seguir y seguir y seguir.

Y puedes resolver, ya sabes, unas diez de esas incidencias graves en un solo día si lo has acelerado, pero ofrece un potencial enorme. Y no se trata solo del desarrollo de software, ¿verdad? Se trata de depurar lo que está pasando e intentar averiguar qué ocurre en entornos en 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 simplemente… es increíble, absolutamente increíble. Siempre y cuando no te limites a decir: «Ah, has dicho que es esto, vale, debería hacer esto, debería hacer aquello». Ahí es donde está el problema, porque sabemos que los LM, ya sabes, tienden —por mucho que les insistas en lo contrario— a verlo todo en blanco y negro, ya sabes, creen que han encontrado la causa raíz.

[John Burke] (6:01 – 6:43)

Me gusta la idea de acelerar la automatización, la idea de que vas a poder ayudar a la gente a acelerar las buenas prácticas; si utilizan buenas prácticas con la IA, llegarán al final de su proyecto de automatización con más frecuencia. No lo dejarán a medias o a tres cuartos, sin depurar del todo, sin documentar del todo. Exacto.

Y luego pasar a la siguiente emergencia. Hay más posibilidades de que, en un solo día, dos días, una semana o dos semanas, puedan completarlo todo y dejar algo que realmente puedan volver a utilizar con confianza, en lugar de, ya sabes, con cierto temor y nerviosismo.

[Andrew Wertkin] (6:44 – 6:58)

Sí, sí. En gran parte se trata simplemente de arquitectura. Gran parte tiene que ver con… Bueno, una cosa es, ya sabes, 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».

[Scott Robohn] (6:58 – 7:02)

Es automático, ¿verdad? Todos los desarrolladores piensan en eso desde el primer día.

[Andrew Wertkin] (7:02 – 9:15)

Sí, sí, sí, sí, sí. Sobre todo cuando todo empezó con: «Oh, ya sabes, necesitamos un script rápido para intentar resolver este problema». Y, ya sabes, y luego alguien lo encuentra seis meses después o… Así que gran parte de ello se reduce a la arquitectura, ya sabes, porque gran parte de lo que va a haber en esa automatización se repetirá, ¿verdad? Como, por ejemplo, ¿cómo nos autenticamos? ¿Cuáles son los estándares en torno al registro de eventos? ¿Cómo queremos registrar los eventos? O, ya sabes, simplemente, ¿cómo vamos a interactuar con nuestros dispositivos? ¿Cómo se gestionan los errores de contraseña y cómo las sacamos de los almacenes de claves? Y, ya sabes, ¿cómo queremos realizar las pruebas o cómo deberíamos plantearnos revertir los cambios, o lo que sea que surja? Casi todo lo que acabo de enumerar es algo repetible y forma parte de esta metodología adecuada. Bueno, ahora solo tienes que añadir tu lógica de negocio, no necesariamente todas estas otras partes. Y, por lo tanto, todo el código se mantiene actualizado y se va probando una y otra vez. Pero, ya sabes, 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, de forma diferente, scripts o aplicaciones totalmente funcionales, ya sabes, de la A a la Z, sea lo que sea lo que estemos creando. Así que es que hay, ya sabes, probablemente sea más importante que nunca empezar con buen pie y empezar a pensar en cómo vamos a hacer que esto sea sostenible y, ya sabes, en qué puntos intervendrán las personas y en qué momentos es fundamental que intervengan.

Y, ya sabes, ¿qué tipo de prácticas vamos a adoptar para hacer esto de forma segura? Todas estas cosas son simplemente, ya sabes, muchas de ellas son las mismas que siempre hemos tenido en cuenta o que nos han preocupado a la hora de desarrollar software a lo largo de, ya sabes, las últimas décadas. Exacto. En parte se debe simplemente a la rapidez con la que ahora se puede hacer. Y no es como si la gente se limitara a copiar y pegar cosas de Stack Exchange.

[Scott Robohn] (9:16 – 10:33)

Cualquiera puede generar código que funcione en ese entorno, ya sabes, es fácil de hacer, y eso no era así hace dos años; creo que estábamos en medio de una época experimental y de rápidos cambios, ¿verdad? Si nos remontamos solo un par de años, ya sabes, la gente tuvo sus primeras experiencias con herramientas basadas en chat y obtuvo resultados muy dispares. Ya sabes, todo ese tema del no determinismo de los modelos de lenguaje grande (LLM); esas fueron nuestras primeras experiencias. Y luego, ya sabes, vemos la llegada de la programación por intuición 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, frente a metodologías emergentes como el desarrollo basado en especificaciones y el desarrollo basado en pruebas. Creo que estamos asistiendo a la aparición de: «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. Exacto. ¿Qué estás observando en esos frentes, ya sabes, en cuanto a la aparición de estas estrategias y herramientas repetibles que están surgiendo?

[Andrew Wertkin] (10:34 – 11:59)

Sí, no, los estamos viendo sin duda y hemos estado experimentando y adoptando un par de ellos. Creo que estamos… Mi empresa y yo personalmente hemos tenido más éxito, curiosamente, precisamente 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 las especificaciones iniciales y el trabajo con el modelo de lenguaje (LM) sobre las compensaciones, y ahí es donde puedo aportar mi experiencia y cómo deberíamos abordar esto, dedicando ese tiempo desde el principio, desglosándolo en partes razonables y, ya sabes, establecer las medidas de seguridad adecuadas y, bueno, ese tipo de cosas han supuesto una transformación, en comparación con, ya sabes, intentar escribir una instrucción que describa exactamente lo que quieres; simplemente el tipo de desarrollo iterativo de especificaciones y pruebas que realmente empieza con: «Vale, quiero crear un registrador TCEBF de alta velocidad». Exacto. Nunca lo he hecho antes. Vale. Y, por lo tanto, ni siquiera sé cuáles son las ventajas e inconvenientes. Así que, ya sabes, no estoy… no estoy… ya sabes, ¿hasta qué punto puedo confiar en, ya sabes, lo que sea? Pero puedo empezar desde un nivel muy alto. Quiero hacer esto. ¿Qué es lo que no sé?

[John Burke] (11:59 – 12:47)

Intención. 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, porque cuando el software ajusta la configuración del hardware en tu red, modificar los ajustes equivocados interrumpe el flujo de tráfico o sobrecarga tanto los procesadores que se producen, ya sabes, terribles caídas de rendimiento, ya que puede que dedique todo su tiempo a generar registros y enviarlos. Así que, ya sabes, te encuentras en un ámbito en el que pueden producirse errores de infraestructura, y pueden ocurrir a la velocidad de la automatización y tener consecuencias realmente enormes.

[Andrew Wertkin] (12:47 – 14:57)

Sí. Sí. Quiero decir, en nuestro mundo del DNS, solo en el ámbito público, si nos fijamos en las últimas grandes interrupciones del servicio anunciadas por grandes empresas públicas, creo que, ya sabes, el 80 % de ellas se debieron a cambios en el DNS impulsados por la automatización que lo dejaron todo fuera de servicio, ya sabes, y, bueno, no voy a culpar ni remotamente a un LLM por eso. Es solo que… pero, cuanto más rápido puedas dar con las soluciones y, sobre todo, cuanto más seguro esté tu compañero de programación o de depuración, tu compañero de rendimiento —sea cual sea el caso de uso—, cuanto más seguros estén ellos, más probable es que tú pienses: «Vale, ya sabes, y luego, ya sabes, todo el mundo sufre de «fatiga de permisos» y… Simplemente pones los dedos sobre la tecla «Intro» y no paras de pulsarla, ya sabes, así que, en definitiva, todo se reduce también a: ¿cómo supervisamos adecuadamente el comportamiento y nos aseguramos de que esas cosas no sucedan?

Pero, sí, y, ya sabes, cuanto más eficaz es esa «expresión de intención», más incluye esas cosas. Ya sabes, ¿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? Ahora bien, no necesitas saber todo eso desde el principio, pero tener la experiencia adecuada para saber qué tipo de categorías de aspectos probablemente deberías tener en cuenta es bueno, ya sabes, pero lo que no hace falta hacer —y creo que esto ha madurado mucho tanto en las herramientas como en los procesos durante los últimos seis meses, un periodo de tiempo increíblemente corto—, es empezar escribiendo un documento de cuatro páginas sobre exactamente qué hay que entregar, ¿verdad? Lo haces si utilizas, por ejemplo, un modelo más económico, más orientado a la tasa de ejecución, no un modelo de vanguardia, sino simplemente un modelo de vanguardia en el que redactas las especificaciones para el modelo de tasa de ejecución. Ya sabes, no hace falta; nunca serás tan bueno como un LLM a la hora de generar instrucciones.

[Scott Robohn] (14:58 – 15:55)

Exacto. Bueno, yo he incorporado una técnica en la que, básicamente, le pido al LLM que me entreviste, y le proporciono, ya sabes, una página, página y media de especificaciones que son razonablemente detalladas. Y si utilizas este proceso para desarrollar todos, todos, todos los archivos Markdown adecuados para SDD, en primer lugar, es barato. Sé que hay un coste de tokens, pero, ya sabes, 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. Ya sabes, el código es «gratis» en el sentido de que, bueno, estamos acostumbrados a pensar que nosotros nos esforzamos por conseguir que el código quede 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?

[Andrew Wertkin] (15:56 – 16:32)

Exactamente. Y ese último punto es, bueno, a nivel personal, es como mi temor: cómo estará todo dentro de 10 años, pero también lo más crítico ahora mismo: sin el conocimiento del ámbito y ese tipo de experiencia y pericia sobre cómo las cosas pueden fallar, cómo deberían funcionar y cómo deberían fallar de forma controlada, y así sucesivamente, entonces… entonces te estás buscando problemas. Pero sí, me gusta ese enfoque y lo aplico, probablemente, de forma menos rigurosa que tú. Pero es ese tipo de: «¿En qué no estoy pensando aquí?». Exacto. ¿Qué más podría salir mal aquí?

[John Burke] (16:33 – 16:53)

Y cuando los LLM están igual de dispuestos a ofrecerte, ya sabes, una seta mortalmente venenosa que una seta sabrosa y comestible, y ambas parecen iguales a simple vista. Sí, ese tipo de conocimiento especializado del ámbito se vuelve insustituible y absolutamente necesario.

[Andrew Wertkin] (16:54 – 20:08)

Sí. Y esto es lo que pasa, y por eso el proceso es tan importante aquí: la gente se pone a trabajar y cree que está en sintonía con el LLM. Y, ya sabes, durante un par de semanas, parece que es así, como si aparentemente recordara cosas. Y luego, ya sabes, el séptimo día, empiezas una nueva sesión y, aparentemente, se ha olvidado de todo lo que sabía. Y se ha ido deteriorando a lo largo de la semana porque no lo has estado documentando. No has estado, ya sabes, guardando los recuerdos adecuados ni asegurándote de actualizar tus indicaciones y todo lo demás. Y entonces toma una decisión increíblemente ingenua. Y tú, como humanizamos estas cosas, tienes la sensación de que, ya sabes, estás trabajando con un doppelgänger o de «¿quién es esta persona con la que estoy trabajando?». Es como: «¿Cómo es posible que se haya olvidado de esto?». Y así 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 que, aunque no sea necesariamente determinista, al menos se basa en lo que hemos hecho en el pasado. Y entonces, ya sabes, sorpresa, ¿y cómo llamamos a eso? Bueno, en parte es el «coste del redescubrimiento». Así que, ya sabes, voy a gastar mucho dinero —en tokens, créditos o lo que sea— en redescubrir lo mismo una y otra y otra vez porque no está debidamente documentado. Y estas son cosas que los modelos de lenguaje (LM) en general, aunque, ya sabes, depende de la herramienta de programación. Pero, ya sabes, yo tiendo a usar mucho a Claude, pero, independientemente de cuál uses, hay varios. Pero, ya sabes, son muy buenos en eso de que, cada vez que termino una sesión, me preguntan: «¿Qué hemos hecho?». ¿Qué has tenido que volver a descubrir y qué es lo que has tenido que volver a descubrir? ¿Deberíamos documentarlo adecuadamente para que no tengas que volver a descubrirlo? Y eso no es todo, porque, ya sabes, la experimentación funciona. A veces se aprende muchísimo cuando se cometen errores, ya sabes, y quizá volviendo al lado personal, que sigue siendo el lado profesional, del software «endurecido», como el software que funciona, como decimos, que funciona en condiciones reales, no solo en el laboratorio. No solo funciona en los casos ideales, sino que, aunque se le exija al máximo, sigue funcionando. Y, ya sabes, llegar a ese punto requiere, ya sabes, la experiencia de haberlo hecho, pero sobre todo de haber fracasado al intentarlo; es como si, ya sabes, algo te huele mal porque ya cometiste ese error antes, ya sabes, o estabas presente cuando ocurrió. Y ese tipo de aprendizaje, que es, ya sabes, muy específico de la enorme capacidad de contexto de nuestros cerebros, es como si ni siquiera tuvieras que repasar tus apuntes. Detectarás ese patrón de inmediato si has tenido la experiencia de fracasar; simplemente está grabado en tu mente, y esas son cosas que no sé cómo van a suceder, ya sabes, sin un propósito, sin un propósito.

[John Burke] (20:09 – 21:10) Y a veces oigo a gente decir que ya no falta mucho para que, ya sabes, ni siquiera tengamos que recurrir a la IA para que 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 es como si creara la automatización por nosotros. Será la automatización misma. Claro. Y, en mi opinión, creo que lo que estás diciendo ahora mismo es la objeción a eso. Es como: «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?».

¿Va a recordar qué salió mal y cómo se solucionó? Quizás sí, quizás no. Creo que hasta que ese problema se resuelva —y se resuelva con soluciones que funcionen «en caliente», como tú dices—, es decir, 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.

[Andrew Wertkin] (21:11 – 24:34)

Y sí, entonces no está resuelto. Y lo único que iba a añadir a eso es que te topas con el problema contrario de, de, um, ya sabes, porque los elementos coinciden básicamente con patrones. Eh, y entonces algo parece encajar en este patrón. Eso no significa que esa sea la respuesta. E irónicamente, como si solo tuvieras un par de casos de este tipo, ya sabes, algo ha fallado, y por eso conozco el patrón, entonces es más probable que se intente, ya sabes, encajar a la fuerza en eso, como, ya sabes, meter a la fuerza la clavija redonda en el agujero cuadrado si casi encaja, ¿sabes? Y, eh, y es que, creo que sigue habiendo una cierta brecha entre, eh, sobre todo en el mundo de Brownfield, pero, pero, eh, entre, bueno, «solo voy a expresar mi intención y se escribirán los scripts, se hará lo que haya que hacer. Nunca tendré que volver a mirarlo. Eh, para que eso se haga realmente en una red empresarial donde, eh, ya sabes, hoy en día no se dispone de todas las herramientas necesarias para llevarlo a cabo. Eh, tampoco se dispone necesariamente del presupuesto necesario para llevarlo a cabo. Eh, y hay antecedentes. Y esos antecedentes incluyen 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 es como si hubiera una cinta amarilla rodeándolo. Nadie sabe por qué, pero sabemos que si lo cambiamos, todo se estropea. Así que ya no lo cambiamos. Ya sabes, es que… esto nunca se documentó, simplemente no se documentó. Así que, eh, ya sabes, yo, yo vuelvo a, eh, uno de esos, eh, libros fundamentales muy conocidos sobre desarrollo de software en el que, ya sabes, las herramientas y las tácticas han cambiado, pero este libro sigue siendo tan válido como siempre lo ha sido, eh, «Refactoring», de Martin Fowler, que, creo que en el prólogo, en los primeros párrafos, dice algo así como: «Si no puedes probarlo, devuelve este libro a la estantería», parafraseando algo parecido a eso, es decir, que no puedes cambiarlo a menos que puedas probarlo. Y en este mundo de, eh, ya sabes, conocimientos tribales y casos puntuales, en el que no todo sigue un patrón, eh, ¿cómo, cómo vas a, cómo vas a abordar eso, eh, sobre todo si no hay nada con lo que probar en tu laboratorio, que no tiene esos casos puntuales, tu laboratorio, ya sabes, ¿cómo vamos a probar esto realmente de forma adecuada? Y, y, y eso es lo que provoca todo esto, ya sabes, un proceso de gestión del cambio más largo. Saben por experiencia que, si tocamos eso, se va a estropear. Así que eso solo va a suceder en una ventana de cambio como esta, en la que disponemos de tres horas y media y no se puede programar nada más durante ese periodo; y es como si nunca hubieran solucionado el problema subyacente, sino que lo han enmascarado con el proceso. Y por eso, ya sabes, las empresas, incluso las grandes, van a tener que plantearse, ya sabes, por dónde empezar con todo esto. Eh, y, por decir lo obvio, eh, lo nuevo es, eh, ya sabes, construirlo así desde el principio, genial, eh, cambiar algo que ya existe, ya sea software o una arquitectura de red, eh, eso es mucho más difícil para los humanos y los modelos de lenguaje grandes (LLM), eh, pero al menos en el caso de los humanos, esperemos que tengan algo de ese conocimiento tribal.

[Scott Robohn] (24:35 – 26:08)

Una de las… bueno, otra cosa emocionante que creo que tenemos por delante aquí es, ya sabes, en relación con todo lo que acabas de exponer. Eh… ya sabes, si tengo un LLM, todo parece una indicación, ¿verdad? Y creo que muchos de nosotros nos estamos dando cuenta de que, ya sabes, no todo supone un problema para un LLM. Y tenemos ante nosotros este conjunto de nuevas técnicas computacionales realmente interesantes y potencialmente útiles, sin haber descartado todas las demás. Por ejemplo, el aprendizaje automático sigue siendo muy útil para otras cosas en el ámbito de la IA; y, por lo que sé, la regresión estadística no me cuesta ningún token. Exacto.

Exacto. Así que estoy ampliando las herramientas de mi caja de herramientas y el rompecabezas realmente divertido al que nos enfrentaremos todos es cómo utilizar las herramientas adecuadas para cada tarea. Los LLM donde tengan sentido, el aprendizaje automático donde tenga sentido, la regresión donde tenga sentido… Eh, quizá para el problema que has mencionado, ya sabes, reinventar la rueda cada vez que se plantea la pregunta, quizá parte de mis limitaciones sean: «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 coincida en un 90 % o más con esta solicitud, hay que usar lo que hay en el catálogo y no gastar tokens en crear otra solución para ello. Y estoy, estoy improvisando un poco aquí, ¿verdad? Pero creo que todos estos son enfoques que debemos poner sobre la mesa mientras, entre todos, vamos resolviendo estas cuestiones.

Y soy mucho más optimista al respecto de lo que soy escéptico. Eh, pregúntame dentro de un año a ver si sigo pensando lo mismo.

[Andrew Wertkin] (26:08 – 30:11)

Así que, no, es interesante en lo que respecta al catálogo de servicios. Quiero decir, lo bueno es que basta con que el modelo de lenguaje compruebe si ya has resuelto el problema antes, ya sabes, y, eh, y, de nuevo, son muy buenos identificando patrones, encontrarán algo. Y eso es, en realidad, como todas las técnicas que he desarrollado, eh, durante el último año, digamos, eh, ese vínculo tan estrecho entre, eh, la documentación de lo que hice y lo que realmente hice es, eh, es, es, es genial tanto desde la perspectiva de, ya sabes, es, es, es una historia breve. Hace años y años, era director técnico de una empresa dedicada a la gestión del ciclo de vida de las aplicaciones. Así que creábamos software para ayudar a crear software y, concretamente, parte de nuestro cliente ideal se encontraba en el ámbito del software integrado relevante para la seguridad, donde un defecto podía causar daños al operador, por ejemplo, en el sector de la automoción o, ya sabes, lo que se te ocurra. Y, bueno, en ese ámbito hay todo tipo de normas, como la ISO 26000 y, y, eh, SPICE para automoción, y un sinfín más. Y parte de esas normas establece, por ejemplo, que debe haber trazabilidad entre los requisitos y el código. Exacto. Y si los requisitos cambian o el código cambia, ese rastro se vuelve, ya sabes, potencialmente problemático. Y voy a tener que revisar todo para detectar cualquiera de esos impactos y, por cierto, voy a tener que confirmar que, en este cambio, aunque haya modificado el código, el requisito sigue siendo correcto. El caso de prueba sigue siendo correcto. La arquitectura sigue siendo correcta. Voy a tener que hacer eso con todos esos rastros sospechosos. Y, ya sabes, no vas a convencer a alguien que desarrolla, eh, software B2B de que necesita ese nivel de trazabilidad. Exacto. Pero yo lo hago cuando desarrollo con modelos de lenguaje grande (LLM), porque es increíble, ya sabes, en primer lugar, bueno, lo disfruto, pero también porque el LLM se encarga de rastrear. Eh… y el LLM puede averiguar rápidamente por qué hicimos algo de la forma en que lo hicimos, porque puede remontarse a la documentación y… y… y a los LLM que escribieron esa documentación, y el LLM sabe cómo redactar la documentación por sí mismo, lo cual es algo que, ya sabes, como, um, eh, incluso si yo, a veces digo: «Escribe esto para un humano»; otras veces lo escribo pensando: «Escribe este documento para un cliente que puede que conozca o no el desarrollo de software, cómo funciona, o que quizá nunca haya instalado Python antes», sea cual sea el caso. Eh… pero a menudo, con esos documentos, pienso: «Eh… o bien incluyo un apéndice solo para un LLM o simplemente lo escribo para un LLM» y, eh… en primer lugar, es más conciso, pero en segundo lugar, ya sabes, los LLM se desenvuelven bastante bien a la hora de redactar documentos para que ellos mismos los lean y, eh, y, bueno, ya sabes, tanto desde el punto de vista de la eficiencia como del coste, a la hora de leerlo, ¿no? Ya sabes, la versión humana es más cara, pero, independientemente de eso, eso también se aplica a esto: vale, ahora he incluido el software adecuado para que la siguiente persona lo mantenga y también para que el siguiente LLM lo mantenga. Y, dada su capacidad, ya sabes, para 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 si fuera humano. Eh, nunca, eh, ya sabes, partiendo de la suposición, como la mayoría de los humanos, de que mientras lo escribes, eh, sí, me acordaré de esto. Sí, esto es bastante fácil de leer. Como si solo tuviera que leer el código, como si fuera obvio o cualquiera entendiera lo que quería decir con eso. Sí, exactamente. Sí. Dije: «ordenando, aquí estoy ordenando», ya sabes, y… y eso, que esas cosas dan lugar a una cantidad enorme de defectos, pero también lo hace… eso que, ya sabes, a veces es incluso peor. Quiero decir, ¿cómo es ese viejo refrán? Que lo único peor que, eh, no tener conexión a Internet es tener una conexión a Internet pésima. Así es.

Sí. Sí. Lo mismo ocurre con la documentación.

[John Burke] (30:11 – 30:48)

Así que, en cierto modo, um, ambos estáis guiando a vuestra IA para que mejore su experiencia en el ámbito. Le estáis enseñando más sobre lo que significa gestionar una red física de dispositivos físicos, cuáles son los riesgos y, eh, cuáles son los límites de la experimentación, etcétera. Eh, 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 con claridad, sin duda.

[Andrew Wertkin] (30:48 – 32:30)

No, es una buena… es una buena analogía porque, eh, eso es lo que suelo, eh, aconsejar a la gente, es como, eh, sí, sobre todo si son, si son desarrolladores con experiencia, como, eh, sí, imagínate que tienes a cuatro desarrolladores de software, desde principiantes hasta de nivel intermedio, trabajando contigo y, eh, que tienen bastante confianza en sí mismos, ya sabes, que están convencidos de que tienen razón, ¿sabes? Y, pues, si uno de ellos te dijera: «No, no, esta es la mejor forma de hacerlo», tú le dirías: «¿Por qué? ¿Qué pruebas tienes? ¿Tenemos pruebas suficientes? Ya sabes, ¿qué alternativas barajaste antes de llegar a esa solución?». Y si piensas en tus interacciones de esa manera, entonces, entonces siempre pensarás en cuál es la pregunta correcta, aunque en cuanto a la capacidad de generar código que funcione rápidamente, ya sabes, no se trata de un desarrollador de software junior o de nivel intermedio, pero en términos de proceso de pensamiento, eh, sí, en muchos casos, los desarrolladores de software de nivel intermedio tienen, tienen, tienen, ya sabes, tienen un mejor proceso de pensamiento, ya sabes, en otras palabras, porque es un proceso de pensamiento, no es, no es una simple coincidencia de patrones ni, ya sabes, la otra «magia» de los modelos de lenguaje (LM). Eh… y así, creo que ese es el mayor error, eh, de la gente, ya sea por sesgo —ya sabes, sesgo de confirmación o de otro tipo—, como, eh, la gente busca, eh, ese tipo de respuesta positiva: «Así es como lo vamos a hacer». Y, eh, y si dicen: «Oye, estaba pensando en esto, es una buena idea». Todos lo sabemos. Eh, esa es la peor forma de interactuar con un modelo de lenguaje grande (LLM), porque te responderá encantado: «Genial. ¡Guau!».

[Scott Robohn] (32:31 – 32:39)

Sí. Eres muy inteligente. Esa es la mejor forma en que lo he oído explicar nunca. Sí. Simplemente, simplemente no incluyas adulación en ninguno de tus problemas.

[Andrew Wertkin] (32:39 – 33:53)

Sí, no, hazlo al cien por cien. Porque yo… yo… no necesito eso de mis compañeros, mis empleados ni de mis padres. Desde luego que no lo necesito de un LLM, pero, eh, me gusta para mi mujer de vez en cuando. Eh, pero, pero independientemente de eso, y para mis hijos sin duda, pero al margen de eso, sí, no, es que… esa idea de que tú eres el experto aquí y estás trabajando con, eh, algo que tiene menos conocimientos que tú sobre lo que quieres crear, cómo debería funcionar, cómo se mide el éxito y cómo ha fallado en el pasado. Y mantén esa mentalidad, mantén esa mentalidad, mantén esa mentalidad. Y entonces, en algún momento, sientes que es como si tengo a los cuatro mejores becarios del mundo trabajando para mí, porque para mí, con el LLM, quizá cinco, a veces siete, pero es que, ya sabes, um, uh, la aceleración de poder terminar esto esta noche: «Por favor, pon en marcha 10 agentes en paralelo».

No diría, por ejemplo: «Por favor, por cierto, pon en marcha 10 agentes en paralelo y ejecuta nuestro protocolo de pruebas relámpago». Y luego me levanto por la mañana y todo un equipo ha estado trabajando toda la noche y, eh, yo… no me siento culpable. No me siento, ya sabes, me tomo mi café y reviso los resultados, y es algo muy potente.

[John Burke] (33:53 – 34:32)

Y, en cierto modo, creo que estás dando a entender lo que los proveedores como tú pueden hacer para apoyar este tipo de trabajo en los entornos de redes empresariales, y eso es, ya sabes, básicamente crear las herramientas potentes que esas IA puedan manejar con las características de seguridad adecuadas. Así que, ya sabes, la, la, eh, sierra circular tiene el apagado automático, para que no te puedas cortar los dedos tan fácilmente como antes. Eh, lo que quieres es ayudarles a que no colapsen la red por no hacer lo más obvio al manejar tus herramientas eléctricas.

[Andrew Wertkin] (34:32 – 39:51)

Sí. No, es interesante. Porque, ya sabes, como, um, la mayoría de los, eh, proveedores de software hoy en día, una de las cosas que hacemos es producir nuestros servidores MCP para nuestros productos de backend.

Tenemos varios productos de backend y, y, um, y creo que, como muchos proveedores que hay por ahí, al principio pensábamos: «Vale, vamos a integrar nuestras herramientas de API abierta con este nuevo protocolo». Y simplemente lo expondremos y, ya sabes, eh, el LM se las arreglará. Pero te das cuenta bastante rápido de que, eh, ese no es el enfoque adecuado en absoluto. Solo vas a malgastar un montón de tokens. Puede suponer un montón de conjeturas. Te quedas ahí sentado viendo cómo el modelo de lenguaje (LM) adivina una y otra vez. Y, eh, ya sabes, uno piensa: «Sí, no, yo puedo averiguar bastante rápido cómo usar una API REST». Y si está integrado en, en, eh, herramientas MCP, aún más rápido, pero eso no significa que entiendan tu ámbito de negocio. Y sí, sobre todo los modelos de Frontier no solo se han entrenado en tu ámbito, sino que probablemente entienden más sobre tu producto de lo que te imaginas. Eh, pero, pero ninguno de ellos, eh, como parte de, parte de lo que ofrecemos, es, no es solo, eh, ya sabes, eh, más, eh, herramientas específicas del ámbito que una API abierta. Como, ya sabes, hay más comunicación entre el servidor MCP y nuestro servidor backend de la que el modelo de lenguaje tiene que ver. No, no envíes el… eh… hay un ejemplo de captura de paquetes. No hay razón para enviar al LM una captura de paquetes de 20 megabytes que… eso no va a servir de nada, ni enviarle una serie temporal completa que deberías enviar a, eh, ML, no a IA, ya sabes, y, bueno, ¿cómo consigo los datos que necesito? Datos resumidos, quizá incluso datos con un toque de opinión, porque conocemos bien nuestros sistemas, así que, ya sabes, con, digamos, opiniones incorporadas. ¿Qué necesita el modelo de lenguaje (LM) para responder a la pregunta del usuario, que podría haber sido algo así como, ya sabes, «¿por qué no funciona esto?», y reflexionar sobre esas cosas en lugar de simplemente… es un poco… voy a usar la palabra «perezoso», pero es «ingenuo». Creo que es la palabra más adecuada. Es ingenuo dar por sentado que los modelos de lenguaje (LM) resolverán bien estas cosas. Y sobre todo si quieres que todo esto sea mínimamente repetible. Eh… pues sí, hacemos eso, pero es mucho más que eso. Por ejemplo, acabamos de repasar temas de desarrollo de software. Y, bueno, sí, nuestros clientes ahora pueden generar montones de scripts de automatización y demás para nuestros productos, genial. ¿Cómo codificamos las mejores prácticas para hacerlo? Para que nuestros clientes no, ya sabes, se metan en, eh, tiempos de inactividad por culpa de la automatización. Para que, eh, para que lo sepan, y eso se refleja en cosas como, ya sabes, eh, los asesores de red y otras herramientas que, que, eh, ya sea a través de indicaciones o, eh, código específico, capacidades o material de formación, como, ayuden a nuestros clientes a tener éxito en la automatización, porque en nuestro sector, especialmente en el ámbito del DDI, en el mundo del DNS y el IPAM, el motor de este sector siempre ha sido la automatización. Hay que cambiar las cosas más rápido. Y por eso queremos que nuestros clientes tengan éxito. Nos duele. Eh, tuvimos un cliente hace unos años, mucho antes de los LM, y volviendo a un ejemplo de, eh, los desastres que pueden ocurrir si no hay procesos que regulen la forma de desarrollar software: se estaba enseñando a sí mismo a crear scripts para nuestro producto. Tenía una cuenta de usuario administrativo, escribió un script, fue a probarlo y borró todo el entorno DNS de la empresa, lo que le dejó inmediatamente sin acceso a los sistemas; Active Directory dejó de funcionar —y lo usaban para LDAP y bla, bla, bla—; la situación se volvió crítica. Y fue así, y él estaba allí sentado, um, como si pudiera imaginarlo… Yo he tenido esa experiencia antes, ya sabes, como, um, 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 había… bueno, no se podía controlar la semilla. No podías, ya sabes, tres horas de trabajo. Lo único que podía hacer era reiniciar el ordenador. Ya sabes, sé que ese tipo de situaciones… ese es uno de varios ejemplos, algunos profesionales, esa sensación de hundimiento de: «Oh, mierda». Sí, nosotros… y me imagino lo que le pasaba por la cabeza a ese tipo, ¿sabes? Y, eh, bueno, sí, obviamente ese es un ejemplo extremo, pero lo que quiero decir es que, eh, cuanto más… eh, en el desarrollo de software siempre nos preguntan sobre métricas y mediciones, y siempre hay alguien que dice: «Bueno, ¿por qué no usáis simplemente las líneas de código o algo así?». Y es que, sí, la idea de que, para cualquiera en ingeniería de software, el número de líneas de código que escriba —cuantas más, mejor— sea una métrica adecuada es una locura, ¿verdad? Así que no hacemos eso ni lo sugerimos. Pero lo que quiero decir es que, cuando empiezas a pensar en las métricas adecuadas, bueno, sin duda en el mundo de SAS, pero ahora también en el mundo de, por ejemplo, estos scripts, no se trata solo de eso; la pregunta es: ¿funcionó como esperábamos? ¿Ha sido una automatización satisfactoria? Eh… y, ¿qué hemos aprendido de lo que no ha salido bien? Y, ¿cómo incorporamos eso a un ciclo de retroalimentación? Y, bueno, no es que… ya sabes, quiero decir, yo pensaba que cuantas menos líneas de código se usaran para resolver un problema, mejor, pero, sobre todo, ¿realmente resolvió el problema?

[Scott Robohn] (39:52 – 40:36)

Bueno, al intentar, ya sabes, reducir al mínimo las líneas de código, como… como lo hacen otros, um, podría causar otros problemas, ¿verdad? Y, de nuevo, una de las cosas que realmente me entusiasma de todo este entorno y esta conversación es que el arte de especificar nuestras restricciones se está volviendo mucho más importante, um, probablemente más de lo que nunca lo ha sido en nuestras carreras, ¿verdad? Ya sabes, tenemos herramientas eléctricas, ¿dónde vamos a poner las protecciones adecuadas para las cuchillas? Y estaban los enchufes con toma de tierra. Eh… mi abuelo fabricaba herramientas eléctricas para Porter Cable. Y, de hecho, tengo algunos de sus viejos prototipos que nunca usaría para construir una terraza porque les faltan piezas y siempre acabas perdiéndote dedos. Exacto. Así que el pensamiento sistémico… y existe el conocimiento tribal.

[Andrew Wertkin] (40:36 – 40:39)

Porque sí. Otra persona puede, eh, eso estaba bien.

[Scott Robohn] (40:39 – 40:44)

Sin duda, John, esto podría ir por muchos caminos. O sea, ¿hacia dónde quieres llevar esto?

[John Burke] (40:44 – 41:20)

Bueno, creo que, para redondearlo, quiero seguir con esta idea de que, eh, la gente del sector ahora tiene que pensar en su cartera de software como herramientas potentes que, en última instancia, serán manejadas por manos robóticas, no por manos humanas. Y, eh, cómo eso va a cambiar el panorama del software empresarial. Ya sabes, hemos hablado un poco de cómo cambia el proceso dentro de la empresa, eh, a la hora de utilizarlo, pero ¿qué hay del resto?

¿Cambia la licencia? ¿Cambia, eh, ya sabes, cómo se hacen las cosas, sin duda?

[Andrew Wertkin] (41:20 – 44:13)

Y creo, quiero decir, ya sabes, en parte es algo parecido a lo que has visto en los mercados privados en general con, eh, con la devaluación de algunas empresas de software, lo cual, eh, ya sabes, todos deberíamos saber que el mercado de valores es… es algo aparte. Es algo que va por su cuenta. Sí. Eh, pero, aparte de eso, um, sin duda va a cambiar los modelos de licencia. Eh, ya sabes, si tu modelo de licencia se basa únicamente en el número de usuarios —y no digo que todo el mundo esté en apuros, solo voy a decir que, vale, un agente es un usuario—. Y, y, eh, ya sabes, es, es, es, sí.

Las empresas van a tener que averiguar, eh, ya sabes, cuál va a ser la métrica adecuada. Y, ya sabes, muchas empresas están optando por… vale, serán créditos. Y ahí está el valor real: en cuánto has utilizado este modelo de lenguaje o cuánto… y, ya sabes, a las empresas no les gustan las facturas sorpresa cada mes.

Eh… a ellos les gusta la coherencia, ¿sabes? Y por eso, eh, creo que, eh, ya sabes, las empresas incipientes, sobre todo las propias empresas de modelos de lenguaje (LM) o las propias empresas de IA, obviamente están muy centradas en una especie de modelo crediticio opaco, en el que todos sabemos que el precio no va a dejar de subir y subir. No podremos trabajar con los proveedores de redes.

No podrás entrar ahí y subir. Lo siento, tu factura de este mes es, eh, sí, es el doble este mes porque, sí, hemos cambiado la proporción entre, eh, crédito y token. Y, eh, y por cierto, eh, hemos mejorado nuestro sistema. Así que es mejor. Así que vas a pagar más. Es como si en nuestro mundo no funcionara así. Y por eso, sí, creo que los modelos de licencia van a tener que cambiar. Y, eh, eh, eh, pero mucho, mucho más que eso, creo que va a haber… Creo que ahora tenemos la oportunidad, ya sabes, de cómo siempre vamos dando vueltas entre la plataforma y lo mejor de su clase, y la plataforma y lo mejor de su clase. Creo que vamos a volver a decantarnos por las soluciones «best-of-breed», porque la interoperabilidad entre diferentes productos se ha vuelto, eh, mucho más sencilla de resolver. Eh, sobre todo con cosas como MCP; ya no creo que necesite necesariamente una integración específica con, eh, los sistemas ITSM, porque todos los sistemas ITSM, eh, son compatibles con MCP. Y así, eh, resulta más fácil, eh, elegir una plataforma en lugar de soluciones «best-of-breed», pero, en ciertas áreas, va a suponer un cambio disruptivo para las empresas en las que, ya sabes, si su único objetivo era meter todo lo posible en nuestra plataforma, eh, y que nadie pudiera competir con nosotros, eh, eso va a cambiar. Eh, ya sabes, y… ¿debería lanzarme con esto? Sí, haré la versión de 60 segundos y la de 30 segundos.

[Scott Robohn] (44:13 – 44:13)

30 segundos.

[Andrew Wertkin] (44:14 – 44:29)

Sí. Sí. Antes era como en el mundo de esos sistemas centrales enormes y complicados que nadie puede cambiar, como los grandes sistemas ERP y cosas por el estilo, en los que las empresas tenían que incluir en sus informes de resultados algo como: «No hemos cumplido los objetivos este trimestre debido a una mala actualización de este enorme sistema interno».

[Scott Robohn] (44:29 – 44:31)

No fue hace tanto tiempo.

[Andrew Wertkin] (44:31 – 45:58)

Sí, no fue hace tanto tiempo. Sí. Y eso fue como… eso fue como toda la campaña de marketing inicial de Salesforce con lo de «sin software». Y te explicamos todo eso y todas esas ventajas sobre, eh, el SAS, um, eh, en ese mundo, cómo empezaron a verse afectados por la disrupción: todas esas nuevas empresas que estaban introduciendo sistemas basados en SAS que eran fáciles de usar. Siguen siendo el sistema de referencia, pero ahora hay estos nuevos sistemas para RR. HH., para la gestión de viajes, para compras, para lo que sea, cualquier parte de ese sistema. Y luego, por supuesto, esas grandes empresas del sector se dedicaban a comprar esas empresas una tras otra, tras otra, tras otra. Así que, hasta cierto punto, yo, al margen de eso, no estoy muy seguro de que la adquisición vaya a producirse en… en… eh… puede que haya demasiado que adquirir.

Eh… vas a ver que muchas empresas están ideando sistemas de interacción, como propuestas de valor 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. Y, eh, y eso va a suceder mucho más rápido que, que, eh, la gestión de viajes y, y, eh, ya sabes, los objetivos en el ámbito de RR. HH. o de compras, o cualquiera que fueran esos sistemas de interacción que empezaron a hacer algo parecido con un gran sistema interno. Así que, en ese 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 para usar, creo que eso nos va a llevar, ya sabes, de vuelta a lo mejor de cada categoría.

[John Burke] (45:59 – 46:42)

E incluso puedo, ya sabes, imaginar llevarlo, eh, muy lejos por ese camino. Eh, solo las IA que trabajan para nosotros entienden realmente cuál es la cartera de software actual, porque cuando surge un nuevo servicio, ven que si pueden hacer la mitad de lo que hay que hacer en el área funcional X mejor, más rápido y más barato. Así que ahora tengo dos opciones en esa área y es la IA la que gestiona qué trabajo se asigna a cada una. Y, ya sabes, es como un enfoque de matriz redundante de proveedores de software. Eh, simplemente elegiré la opción que mejor se adapte a los criterios que mi IA, eh, entiende que son los más importantes para mí: ahorrar tiempo, ahorrar dinero, obtener un mejor rendimiento, lo que sea. Sí. Sí.

[Andrew Wertkin] (46:43 – 50:10)

Sí. Porque yo, cuando voy a alguna feria tecnológica hoy en día, sobre todo de redes, pero, eh, ya sabes, prácticamente en cualquier área relacionada con la tecnología. Y vas a ver una empresa tras otra tras otra, eh, vendiendo su plataforma de IA; ya sabes, independientemente de dónde vengan, ahora tienen una plataforma de IA que va a ser multivendedor. ¿Por qué no? Todo el mundo tiene servidores MCP. Y, entonces, ¿qué vas a tener como empresa? ¿Varias plataformas para operaciones de agentes, eh, una única plataforma, um, eh, ya sabes, un metaagente que gestione un montón de otras plataformas de agentes? ¿Y si pongo aquí la equivocada? Y… ¿con qué rapidez puedo cambiarla? Y… bueno, parece que… y no entiendo esta parte porque no es mi forma de trabajar, pero la gente también tiende a tener prejuicios de facilidad.

Oh. Oh, sí. Dicen que pueden encargarse de todo esto por mí. Así que me lo voy a creer, ¿sabes? Y, eh, y todo se reduce a este tema. Es curioso, ya sabes, antes dije que puse un ejemplo real. Nunca había escrito un EBPF, como, eh, ya sabes, un registrador de alta velocidad en espacio interno. Y, eh, y ahora que lo he hecho, sigo sin saber escribir uno. Eh, claro.

Lo utilizo como un experimento para ver qué pasa si sigo este proceso en un ámbito en el que, sí, sé perfectamente cómo funciona todo esto, pero en el que nunca he escrito software. ¿Qué aprenderé? Lo que aprendí fue lo rápido que puedo hacer algo que antes no sabía hacer. Eh, y simplemente con establecer las cosas de las que hablábamos antes, como, ya sabes, los criterios y los criterios de salida y las cosas que me preocupan, tengo algo que funciona. No sé si es la mejor forma de resolver el problema con el que empecé. No sé si… bueno, lo único que sé es que es un código mantenible que… que funciona.

Quiero decir, ya sabes, yo sé más que eso. Está muy bien documentado. Así que, supongo que lo que quiero decir es que, um, eh, igual que la gente sigue necesitando aprender estas cosas, ya sabes, para, por así decirlo, aportar esa experiencia. Y eso, quiero decir, por mucho que aprecie esta tecnología, mi mayor temor es simplemente que, eh, los peores errores siempre empiezan cuando alguien cree que tiene razón. Y la gente o bien se siente demasiado intimidada, o está demasiado deslumbrada, o es demasiado rara, o simplemente demasiado perezosa para cuestionar a alguien que, sin duda, sabe cómo hacer algo. Y el resultado final son cosas que se podrían haber evitado y que causan, eh, problemas. Y vemos eso en, ya sabes, todo, desde la tecnología hasta, eh, los entornos sociales y en cualquier otro sitio, ya sabes, y, eh, el pensamiento de grupo o, pero, pero, ya sabes, es… eh… para eso confío en mis expertos, eh, ya sabes, incluso si no lo saben, incluso si suena bien. De hecho, cuanto más bien les suena, menos probable es que se lo crean a pies juntillas, eh, porque ahí… ahí debe de haber algo que no cuadra. ¿Qué es? Es un rompecabezas. Se trata, ya sabes, de ingenieros en muchos casos. Y, y, eh, eh, por mucho que aprecie la tecnología, la utilice y la impulse, como por ejemplo creando valor con ella, eh, hay una parte que simplemente me hace sentir incómodo.

[John Burke] (50:12 – 50:35)

Eh, una nota de precaución muy acertada con la que poner fin a la conversación. Sí. Gracias, Andrew, por acompañarnos hoy. Ha sido tremendamente interesante y da mucho que pensar a los estrategas empresariales a la hora de plantearse cómo seguirán las cosas, eh, en sus departamentos de TI. Eh, Scott, muchísimas gracias también por acompañarnos hoy. Y, como siempre, gracias a todos los que nos estáis viendo.