Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / La IA agéntica reescribe DevOps: cómo los agentes de IA transforman .NET, Azure y la productividad de los desarrolladores (Doblaje IA)

Transcript

La IA agéntica reescribe DevOps: cómo los agentes de IA transforman .NET, Azure y la productividad de los desarrolladores (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
¿Qué pasaría si su equipo de desarrollo de software tuviera un compañero adicional,
0:03
alguien que nunca se cansa, aprende más rápido que nadie y realiza el trabajo tedioso sin quejarse
0:06
y realiza sin quejarse? Eso es esencialmente lo que se está convirtiendo en la IA Gente.
0:10
En este video, primero definiremos qué significa realmente la IA Gente,
0:14
luego mostraremos cómo funciona el flujo de trabajos reales de Duntonet y Azure,
0:17
y finalmente exploraremos el impacto que puede tener en la proteína de su equipo.
0:21
Al final, conocerá un pequeño experimento para probar en su propia canalización de Duntonet esta semana.
0:25
Pero antes de llegar a las aplicaciones y los resultados, debemos analizar qué hace que la IA Gente
0:28
sea realmente diferente de las herramientas de autocompletado que ya ha visto.
0:32
¿Qué hace diferente a la IA Gente?
0:35
Lo que distingue a la IA Gente no es solo que pueda generar código,
0:37
sino que opera más como un sistema de compañeros de equipo con capacidades distintas.
0:42
Para entender esto, podemos desglosarlo entre rasgos clave.
0:44
La forma en que cada agente mantiene el contexto y la memoria,
0:47
la forma en que múltiples agentes se coordinan como equipo,
0:49
y la diferencia entre la automatización simple y la verdadera autonomía adaptativa.
0:53
Primero, veamos qué hace que un agente individual sea único,
0:55
el contexto, la memoria y la orientación a objetivos.
0:57
El autocompletado tradicional predice la siguiente palabra o línea,
1:01
pero olvida todo lo demás una vez que se realiza la predicción.
1:04
Un agente de IA, en cambio, tiene una comprensión del proyecto más amplio.
1:08
Recuerda lo que ya se ha intentado, saber dónde reside el código
1:11
y ajusta su resultado cuando algo cambia.
1:13
Esa persistencia lo hace más parecido a trabajar con un desarrollador junior,
1:17
alguien que aprende con el tiempo en lugar de solo adivinar lo que usted quiere en el momento.
1:20
La diferencia clave aquí es entre predecir y planificar.
1:22
En lugar de reaccionar a cada pulsación de tecla de forma aislada,
1:25
un agente realiza un seguimiento de los objetivos y se adapta a medida que evoluciona la situación.
1:29
Lo siguiente es cómo trabajan juntos múltiples agentes.
1:31
Un gran malentendido es pensar en la IA agente como un script de desarrollo
1:34
o una macro que solo automatiza tareas repetitivas.
1:36
Pero en proyectos de software reales, el trabajo se divide entre diferentes roles.
1:40
Arquitectos, revisores, probadores, operadores.
1:43
Los agentes pueden reflejar esta división cada uno manejando una parte del ciclo de vida
1:46
con perfecta memoria y consistencia.
1:48
Imagina un agente dedicado al diseño del sistema
1:50
que propone patrones de arquitectura y marcos de trabajo que se ajustan a los objetivos comerciales.
1:54
Tres, otro revisa los cambios de código, detectando problemas
1:57
mientras permanece consciente de todo el historial del proyecto.
2:00
Un tercero podría ampliar la cobertura de pruebas basada en datos de usuario,
2:03
generando casos de pruebas sin que usted tenga que solicitarlos.
2:06
Cada agente está especializado, pero se coordinan como un equipo,
2:08
siempre disponibles, siempre consistentes y fácilmente escalables según la carga de trabajo.
2:12
Donde los humanos perden energía, contexto o enfoque,
2:14
los agentes se mantienen constantes y recuerdan detalles con precisión.
2:18
La última pieza es la distinción entre automatización y autonomía.
2:22
La automatización ha existido durante mucho tiempo en el design.
2:24
Pensemos en scripts, tuberías de CFSD y plantillas.
2:27
Estos son rígidos por diseño.
2:29
Siguen instrucciones exactas paso a paso, pero fallan
2:31
cuando las condiciones cambian inesperadamente.
2:33
La autonomía adopta un enfoque diferente.
2:35
Los agentes de IA pueden responder a cambios sobre la marcha
2:37
ajustándose cuando cambia una versión de dependencia
2:39
o reconsiderando la elección de un servicio cuando entra en un servicio
2:41
cuando entran en juego las restricciones de costos.
2:43
En lugar de ejecutar rutas predefinidas,
2:45
toman decisiones bajo condiciones dinámicas.
2:48
Es un cambio de la ejecución estática a la resolución de problemas adaptativos.
2:51
El efecto resultante es que estos agentes van más allá de esperar órdenes.
2:55
Pueden proponer soluciones a medida que surgen problemas,
2:57
resaltar riesgos antes de que lleguen a producción
2:59
y redactar planes que ahorran horas de configuración.
3:03
Si el GitHub Copilot de hoy puede completar fragmentos,
3:05
la versión del mañana actúa más como un colaborador de proyecto,
3:08
trazando hojas de ruta,
3:09
sugiriendo estrategias de lanzamiento
3:10
e incluso señalando decisiones arquitectónicas que podrían causar problemas a futuro.
3:14
Eso no significa que cada implementación se ejecutará sin intervención humana,
3:17
pero puede reducir significativamente las tareas repetitivas
3:20
y dar a los desarrolladores más tiempo para enfocarse en las partes creativas
3:22
y de alto valor de un proyecto.
3:25
Para aclarar un tipo de frase anterior en este espacio,
3:27
en lugar de decir,
3:27
¿qué sucede cuando el aprovisionamiento de recursos de Azure
3:29
no necesita un humano en absoluto?
3:31
No necesita un humano en absoluto.
3:33
Una declaración más precisa sería,
3:34
estas herramientas pueden reducir la cantidad de configuración humana necesaria
3:37
manteniendo al mismo tiempo los controles clave bajo supervisión humana.
3:41
El resultado sigue siendo transformador,
3:43
sin sugerir que la supervisión humana desaparezca por completo.
3:46
La gran conclusión es que la IA Agente
3:48
no es solo otro complemento que acelera una tarea aquí o allá.
3:51
Comienza a funcionar como un miembro real del equipo,
3:54
manejando el trabajo de fondo para que los desarrolladores
3:56
no se queden atrapados persiguiendo detalles
3:57
que podrían haber sido rastreados por un homólogo siempre activo.
3:59
La capacidad de todo el equipo se amplifica porque ARIA es clave.
4:02
Tienen agentes digitales trabajando junto a especialistas humanos.
4:06
Entender la teoría es importante,
4:07
pero lo que realmente importa es cómo se desarrolla esto en entornos conocidos.
4:11
Aquí está la versión de curiosidad.
4:12
¿Qué cambia realmente el primer día de un nuevo proyecto
4:14
cuando los agentes están activos desde el inicio?
4:17
A continuación, veremos un escenario concreto
4:19
dentro del ecosistema Duntanet
4:20
donde esos cambios comienzan a aparecer
4:22
incluso antes de haber escrito la primera línea de código.
4:25
Reimaginar el flujo de trabajo del desarrollador en Duntanet.
4:27
En el desarrollo con Duntanet,
4:28
el cambio más visible comienza con la forma
4:30
en que los proyectos se ponen en marcha.
4:32
Reimaginar el flujo de trabajo del desarrollador
4:34
aquí se resume en tres ventajas tácticas.
4:37
Estructuración de arquitectura más rápida,
4:38
crítica a nivel de proyectos sobre la marcha
4:40
y una notable reducción de la fatiga de configuración.
4:42
La primera es de estructuración acelerada.
4:44
En lugar de abrir Visual Studio y mirar una solución vacía,
4:46
un agente de I puede proponer opciones de arquitectura
4:49
que se ajusten a tu caso de uso específico.
4:52
Al planificar una API web con actualizaciones en tiempo real,
4:54
el agente sugiere un diseño en capas limpio
4:56
y señala cómo si la R encaja naturalmente en el flujo.
4:58
Para una aplicación financiera,
5:00
alinea Entity Framework con seguridad de tipos fuerte
5:02
e integración con Azure Active Directory
5:03
antes de haber creado una sola carpeta.
5:06
Lo que normalmente requiere rondas de discusión
5:08
u horas de investigación
5:08
se condensan unos pocos puntos de partida personalizados.
5:11
Sin embargo, estos no son planos finales,
5:13
son borradores.
5:13
Los equipos deben validar cada sugerencia
5:15
ejecutando una lista de verificación rara.
5:17
La autenticación cumple con los requisitos.
5:19
El registro de eventos se configurado correcto.
5:21
¿Existen casos de prueba básicos?
5:22
Esa gobernanza ligera asegura
5:24
que la velocidad no sacrifique la estabilidad.
5:25
La segunda ventaja es la crítica continua.
5:29
Piense en ello, menos como un auto completado de código
5:31
y más como un asesor que vigila la alineación del diseño.
5:34
Si implementas un patrón de repositorio
5:36
para el acceso a datos,
5:36
el agente señala si te estás desviando
5:38
de la separación de responsabilidades.
5:40
Añade un nuevo controlador
5:41
y propondrá pruebas unitarias correspondientes
5:43
o resaltará inconsistencias con el resto del proyecto.
5:46
En lugar de dejarte con código repetitivo,
5:48
impulsa la estructura de tu sistema
5:49
hacia patrones mantenibles con cada confirmación.
5:51
Para un experimento práctico,
5:53
intenta habilitar Copilot en Visual Studio
5:55
en un pequeño prototipo de ASP.NET Core.
5:58
Luego compara cuánto tardas en servir
6:00
la primera solicitud significativa,
6:01
un endpoint con autenticación y persistencia de datos
6:03
frente a hacerlo todo manualmente.
6:06
No es una garantía de ahorro de tiempo,
6:07
pero realizar el ejercicio comparativo
6:09
en tu propio entorno suele ser la forma más rápida
6:11
de medir si estos agentes tienen un impacto real.
6:14
La tercera ventaja es la reducción
6:15
de la configuración y la carga con it.
6:17
Gran parte del trabajo inicial de un proyecto
6:19
es repetitivo.
6:20
Conectar middleware de autenticación,
6:22
importar paquetes Nougat,
6:23
configurar registros con Application Insights,
6:25
crear pipelines YAML.
6:26
Un agente puede generar esas piezas de inmediato
6:28
incluyendo pruebas de integración base
6:29
que conocen qué dependencias están presentes.
6:32
Solo no elimina tu control,
6:33
sino que cambia hacia dónde se dirige tu energía.
6:35
En lugar de pelearte con archivos de configuración
6:37
durante un día,
6:37
pasas ese tiempo implementando
6:38
la lógica de negocio que realmente importa.
6:41
La fatiga del trabajo de configuración desaparece,
6:43
dejando margen para decisiones de diseño creativo
6:45
en lugar de tareas mecánicas.
6:47
Donde esto se siente diferente
6:48
a la automatización tradicional
6:49
es en la flexibilidad.
6:50
Una plantilla de proyecto
6:51
te ofrece valores determinados estáticos.
6:53
Un agente adapta su estructura
6:54
basándose en tu objetivo de negocio declarado.
6:56
Si estás construyendo una aplicación de colaboración,
6:58
las estrategias de caché como Redis
7:00
y el diseño basado en eventos
7:01
con Azure Service Bus
7:02
aparecen en el plan estructurado.
7:04
Si cambias hacia cargas de trabajo programadas,
7:06
aparecen en su lugar servicios
7:07
en segundo plano y procesamiento de código.
7:08
Esa capacidad de respuesta
7:09
separa la guía con agentes de la scripting simple,
7:11
ofreciendo recomendaciones
7:12
que reflejan el rol de un miembro señor del equipo
7:14
que ayuda a guiar las decisiones iniciales.
7:16
El contraste con el uso actual de Copilot es evidente.
7:19
En este momento,
7:20
la mayoría de los desarrolladores
7:21
lo ven como una forma de acelerar
7:22
la sintaxis común o el código repetitivo.
7:24
Hacen una pregunta de la herramienta completa a la línea.
7:27
Con capacidades de agente,
7:28
la herramienta comienza a asesorar
7:29
a nivel de sistema,
7:30
ofreciendo alternativas conscientes del contexto
7:32
y revelando las compensaciones
7:33
al inicio del ciclo.
7:35
El salto consiste en pasar
7:36
de generar fragmentos de código
7:37
a curar diseños viables.
7:38
Y eso cambia no solo cómo se escribe el código,
7:41
sino cómo los equipos estructuran
7:42
toda la solución
7:43
antes de comprometerse
7:44
con una dirección única.
7:46
Nada de esto elimina
7:47
la necesidad del juicio humano.
7:49
Los agentes pueden sugerir
7:49
marcos de trabajo,
7:50
dependencias y prácticas,
7:51
pero verificarlos
7:52
sigue siendo responsabilidad del equipo.
7:53
Trate cada recomendación
7:54
como una propuesta prelimina.
7:56
Acepte las partes
7:57
que se alineen con sus estándares,
7:58
revise las que no
7:59
y capture las lecciones
8:00
para la próxima iteración del proyecto.
8:02
De ahí a se encarga
8:03
el trabajo pesado y repetitivo,
8:04
mientras los miembros del equipo
8:05
se enfocan en alinear
8:06
las decisiones tecnológicas
8:07
con la estrategia.
8:08
Hasta ahora hemos visto
8:08
cómo los agentes remodelan
8:10
la experiencia de codificación
8:11
dentro de Duntonet,
8:12
pero su participación
8:13
no termina en el diseño
8:14
de la solución
8:15
o la estructura del proyecto.
8:16
Una vez establecidos los cimientos,
8:18
la misma inteligencia
8:18
comienza a extenderse
8:19
hacia el aprovisionamiento,
8:20
despliegue y gestión
8:21
de la infraestructura
8:21
en la que dependen
8:22
esas aplicaciones.
8:24
Ahí es donde otra
8:25
gran transformación
8:25
está tomando forma
8:26
y no se limita
8:27
al flujo de trabajo local
8:28
del desarrollador.
8:29
Se trata del entorno
8:30
en la nube que lo rodea.
8:32
Agentes en la nube
8:32
ejecutando Azure
8:33
en piloto automático.
8:34
Así que cambiamos el enfoque
8:35
hacia lo que sucede
8:36
cuando la gestión de Azure
8:37
empieza a funcionar
8:37
en piloto automático
8:38
con la ayuda de agentes.
8:40
La forma original
8:40
en que se plantea esta discusión
8:41
suele sonar a ciencia ficción.
8:43
¿Qué sucede
8:43
cuando el aprovisionamiento
8:44
de recursos de Azure
8:44
ya no requiere intervención
8:45
humana en absoluto?
8:47
Una mejor manera
8:48
de pensarlo es esta.
8:50
¿Qué sucede
8:51
cuando el aprovisionamiento rutinario
8:52
y la detección de desviaciones
8:53
requieren menos intervención manual
8:54
porque los agentes
8:55
gestionan tareas repetibles
8:56
bajo límites definidos?
8:59
Ese cambio es importante
9:00
porque no se trata
9:01
de eliminar personas
9:01
sino de descargar
9:02
el trabajo repetitivo
9:03
mientras se mantiene
9:04
la supervisión.
9:05
Si alguna vez ha construido
9:06
un entorno de Azure serio
9:07
ya sabe lo desordenado
9:08
que puede volverse.
9:09
Se hacen malabares
9:10
con plantillas,
9:11
scripts y archivos
9:11
de canalización
9:12
mientras se alterna
9:13
entre comandos de CLI
9:14
por velocidad
9:15
y el portal para excepciones.
9:17
Cada atajo
9:17
se convierte en deuda técnica
9:18
esperando aparecer.
9:20
Una máquina virtual
9:20
encendida fuera de horario,
9:22
costos que crecen sin aviso
9:23
o una cuenta de almacenamiento
9:23
expuesta cuando no debería estarlo.
9:25
Y en las operaciones
9:26
en la nube
9:26
incluso los pequeños errores
9:28
crean dolores de cabeza enormes.
9:29
Facturas que se disparan,
9:30
regiones que afectan
9:31
la resiliencia
9:32
o brecha de cumplimiento
9:33
que descubre
9:33
en el peor momento posible.
9:35
Esta es la rutina
9:36
de la que la mayoría
9:36
de los equipos
9:37
quieren librarse
9:37
y es donde un agente
9:38
comienza a sentirse
9:39
como un ingeniero
9:39
de despliegue autónomo.
9:40
La idea es sencilla.
9:42
Usted proporciona
9:43
objetivos de negocio,
9:43
requisitos de rendimiento,
9:45
necesidad de recuperación,
9:46
reglas de cumplimiento
9:47
y tolerancias de presupuesto
9:48
y el agente traduce
9:49
esa intención
9:49
en configuraciones
9:50
de infraestructura.
9:51
En lugar de cambiar
9:52
entre varias consolas
9:53
o unir identificadores
9:54
manualmente,
9:54
usted obtiene plantillas
9:55
y así así
9:56
que ya están alineadas
9:57
con sus objetivos expresados.
9:58
A partir de ahí,
9:59
el mismo agente
9:59
permanece atento,
10:00
ejecutando comprobaciones
10:01
de cumplimiento,
10:02
simulando posibles
10:03
configuraciones erróneas
10:04
y aplicando soluciones
10:04
propuestas antes de que
10:05
los problemas escalen
10:06
a producción.
10:08
La diferencia
10:08
con la automatización
10:09
existente radica
10:10
en la adaptabilidad.
10:11
Un pipeline de CIC
10:12
de normal trata
10:13
sus definiciones YAML
10:14
como si fueran ley.
10:15
Funcionan hasta que
10:16
la realidad cambia,
10:17
ya sea por una actualización
10:18
de dependencia,
10:19
un pico repentino de demanda
10:20
o un nuevo mandato
10:20
de cumplimiento.
10:21
Entonces,
10:21
esas instrucciones estáticas
10:23
fallan o ejecutan
10:24
algo que parece válido
10:24
pero no satisface
10:25
las necesidades del negocio.
10:26
Un pipeline impulsado
10:28
por agentes
10:28
se comporta de forma distinta.
10:29
Trata esas definiciones
10:30
como puntos de referencia
10:31
pero las actualiza
10:32
cuando las condiciones cambian.
10:34
En lugar de esperar
10:34
a que una persona
10:35
escale un servicio
10:36
o ajuste la distribución regional,
10:37
detecta patrones de carga,
10:38
predice los umbrales probables
10:40
y aprovisiona capacidad
10:41
adicional de antemano.
10:44
Esa capacidad de adaptación
10:45
hace que los escenarios
10:45
sean menos propensos
10:46
a errores en la presentación.
10:47
Imagina una aplicación
10:47
de un internet
10:48
que gestiona tráfico
10:49
principalmente en ECO.
10:50
Una semana después
10:51
aparecen nuevos usuarios
10:52
en Europa.
10:53
La latencia aumenta,
10:54
pero nadie incluye
10:54
otra región en el YAML original.
10:56
La automatización tradicional
10:57
lo ignora.
10:58
Solo se da cuenta
10:59
después de que llegan las quejas
11:00
y se analizan los registros.
11:01
En cambio,
11:01
un agente detecta el patrón,
11:03
despliega una réplica europea
11:04
y configura el enrutamiento
11:05
mediante Azure Front Door
11:06
de inmediato.
11:07
No solo despliegue,
11:08
se desentiende.
11:09
Alinea constantemente
11:09
los recursos con la intención.
11:11
Casi como un operador 24-7
11:13
que nunca se cansa,
11:14
el beneficio real
11:15
va más allá del escalado.
11:17
La seguridad
11:17
y el cumplimiento
11:18
se integran en el ciclo.
11:19
Esto puede significar
11:20
que el agente observe
11:21
un contenedor de almacenamiento
11:22
expuesto accidentalmente
11:23
y lo bloquee automáticamente
11:24
o que detecte desviaciones
11:26
en la base de parches
11:26
de una máquina virtual
11:27
y la restaure.
11:29
Son tareas de alta frecuencia
11:30
y baja visibilidad
11:30
que los humanos
11:31
suelen detectar tarde
11:32
y solo después
11:33
de mucho esfuerzo.
11:34
Al incorporarlas
11:35
al ciclo continuo,
11:36
no elimina a los operadores
11:37
sino que los libera.
11:39
En lugar de gastar energía
11:40
apagando fuego,
11:41
se centran en la planificación
11:42
y estrategia de alto nivel.
11:43
Y ese es un mate importante.
11:45
Supervisión humana
11:46
no desaparece.
11:46
Su rol cambia
11:47
de marcar casillas
11:48
línea por línea,
11:49
definir directrices
11:49
desde el principio.
11:50
¿Qué regiones están permitidas?
11:53
¿Qué costos son aceptables
11:53
y qué estándares de cumplimiento
11:54
no pueden infringirse?
11:56
Infringir.
11:57
Un paso práctico
11:58
para cualquier equipo curioso
11:59
por probar esto
11:59
es definir límites
12:00
de política desde el inicio.
12:02
Establezca techos de costos,
12:03
designe regiones aprobadas
12:04
y añada límites de cumplimiento.
12:06
El agente actúa entonces
12:07
como un ejecutor,
12:08
no como un operador
12:08
sin restricción.
12:09
Ese es el principio fundamental.
12:11
Usted mantiene el control
12:12
de la dirección estratégica
12:13
mientras el agente
12:14
ejecuta labores
12:14
de protección a escala.
12:16
Tampoco significa
12:16
que deba poner la producción
12:17
en manos del agente
12:18
desde el primer día.
12:19
¿Prefiere evitar riesgos?
12:20
Comience en un entorno
12:21
de pruebas controlado.
12:23
Exponga al agente
12:23
a una carga de trabajo
12:24
no crítica
12:24
o seleccione un servicio único
12:26
como infraestructura
12:26
de almacenamiento registro
12:27
y deje que gestione
12:28
la deriva
12:28
y el aprovisionamiento allí.
12:30
De esta forma,
12:31
usted genera confianza
12:31
en cómo interpreta las barreras
12:33
antes de ampliar su alcance.
12:35
Piénselo como realizar
12:36
un proyecto piloto
12:36
con un alcance bien definido
12:37
y bajo riesgo,
12:38
tal como maduran
12:39
la mayoría de las prácticas
12:40
confiables de DevOps.
12:42
En esencia,
12:43
un enfoque basado en agentes
12:44
para Azure IRC
12:44
se parece menos
12:45
a escribir docenas
12:46
de scripts estáticos
12:47
y más a gestionar
12:47
una lista de verificación dinámica.
12:49
Genere plantillas,
12:50
ejecute comprobaciones
12:51
previas al despliegue,
12:52
monitore la deriva
12:53
y proponga soluciones.
12:54
Todo dentro de los límites
12:55
que usted configure.
12:56
Es lo suficientemente
12:57
estructurado para generar confianza,
12:58
pero lo suficientemente
12:59
flexible la producción
13:00
es cambiando.
13:01
Por supuesto,
13:01
el aprovisionamiento
13:02
y escalado a la infraestructura
13:03
es solo una cara
13:03
de la confiabilidad.
13:05
El problema más difícil
13:06
suele surgir después.
13:07
Asegurar que el código
13:08
que despliega en ese entorno
13:09
realmente resiste
13:10
en condiciones del mundo real.
13:12
Y ahí es donde
13:12
el siguiente desafío
13:13
comienza a manifestarse,
13:14
la cuestión de detectar errores
13:15
que los humanos
13:15
simplemente no ven
13:16
hasta que ya están en producción.
13:19
Pruebas autónomas,
13:19
errores que los humanos
13:20
pasan por alto.
13:21
Las pruebas solo cubren
13:22
lo que los humanos
13:22
pueden imaginar
13:23
y esa es la limitación principal.
13:25
La mayoría de los fallos
13:26
en producción
13:26
no provienen de lo previsto,
13:28
sino de lo que escapa
13:28
a la imaginación humana.
13:30
Los agentes de pruebas autónomas
13:32
se entran en este vacío,
13:33
centrándose en casos extremos
13:34
y condiciones dinámicas
13:35
que nunca llegarían
13:35
a un conjunto de pruebas típico.
13:37
Considera la condición
13:38
de cargador en 3.
13:39
Una aplicación
13:40
Tontonet en Azure
13:41
puede funcionar perfectamente
13:42
bajo carga pesada
13:43
en una prueba de estrés planificada,
13:44
pero introduzca
13:45
eventos de escalado,
13:46
nuevas instancias
13:46
que inician en medio del tráfico
13:47
y de repente
13:48
aparecen errores
13:48
en el manejo de sesión.
13:50
A menos que alguien
13:50
haya diseñado una prueba
13:51
específicamente
13:52
para esa coincidencia
13:53
pasar desapercibido.
13:54
Un agente autónomo
13:55
detecta la anomalía
13:56
a la isla
13:56
y genera una nueva prueba
13:57
de regresión
13:57
basada en esa condición.
13:59
La próxima vez
14:00
que ocurra un escalado,
14:01
esa protección ya estará presente,
14:02
convirtiéndolo
14:03
en un riesgo oculto
14:03
en un escenario mitoreado.
14:05
Otro ejemplo
14:09
de datos seguros
14:09
o predecible,
14:10
nombres de usuario válidos,
14:12
cargas útiles de API correctas
14:13
o casos extremos obvios
14:14
como cadenas vacías.
14:15
Un agente,
14:16
por el contrario,
14:17
comienza a experimentar
14:18
con variaciones
14:18
que a los desarrolladores
14:19
no se les ocurriría cubrir.
14:20
Solicitudes excesivas,
14:21
codificaciones extrañas,
14:23
ligeros retrasos
14:23
entre llamadas de varios pasos.
14:25
Al hacerlo,
14:25
puede provocar fallos
14:26
que conjuntos de pruebas manuales
14:27
pasarían por alto
14:28
por completo.
14:29
El valor no está
14:29
solo en la velocidad,
14:30
sino en la diversidad.
14:31
Los agentes exploran
14:32
rincones extraños
14:33
de los espacios de entrada
14:34
más rápido
14:34
de lo que jamás podrían hacer
14:35
nuevos casos escritos
14:36
por humanos.
14:37
Lo que diferencia
14:37
este cambio
14:38
de la automatización tradicional
14:39
es cómo evoluciona
14:39
la suite de pruebas.
14:41
Un paquete de regresión
14:41
diseñado por humanos
14:42
permanece relativamente estático.
14:44
Refleja el conocimiento
14:45
y las suposiciones del equipo
14:46
en un momento determinado.
14:48
Los agentes convierten
14:49
eso en un proceso útil.
14:50
Expanden la suite
14:51
a medida que el sistema cambia,
14:52
siempre buscando
14:53
estados no contemplados.
14:55
En lugar de que los desarrolladores
14:56
actualicen laboriosamente
14:57
scripts frágiles
14:58
tras cada iteración,
14:59
se generan nuevos casos
15:00
dinámicamente
15:00
según cómo se comporta
15:01
el sistema realmente.
15:03
Aún así,
15:04
hay una advertencia importante.
15:04
No toda prueba generada
15:06
por agentes
15:06
merece vivir
15:07
en su suite permanente.
15:08
Las pruebas inestables
15:09
o irrelevantes
15:10
pueden acumularse rápido,
15:11
desperdiciando tiempo
15:11
y minando la confianza
15:12
en la automatización.
15:14
Por eso la gobernanza
15:14
importa.
15:15
Los equipos necesitan
15:16
un proceso de revisión.
15:17
Los desarrolladores
15:17
o ingenieros de Kiva
15:18
deben validar
15:19
cada prueba propuesta
15:20
por su estabilidad
15:21
y relevancia
15:21
antes de integrarla
15:22
al paquete de regresión estable.
15:25
Como con cualquier automatización,
15:26
la supervisión asegura
15:27
que estas herramientas
15:27
amplifiquen la fiabilidad,
15:29
en lugar de abrumar
15:30
a los equipos con ruido.
15:31
Otro concepto erróneo
15:32
que vale la pena aclarar
15:33
de que los agentes
15:34
corrigen errores.
15:35
No reescriben
15:36
el código de producción
15:36
ni parchen fallos
15:37
por sí mismos.
15:38
Lo que hacen
15:38
excepcionalmente bien
15:39
es mostrar escenarios
15:40
reproducibles
15:41
con detalles diagnósticos claros.
15:43
Para un desarrollador,
15:44
tener una serie
15:44
de pasos capturados
15:45
por un agente
15:45
marca la diferencia
15:46
entre horas de sus posesiones
15:47
y una resolución rápida.
15:48
En algunos casos,
15:49
los agentes pueden sugerir
15:50
una posible solución
15:51
basada en patrones conocidos,
15:52
pero la decisión final
15:53
y el cambio
15:54
permanecen en manos humanas.
15:56
Visto así,
15:56
la división del trabajo
15:57
se vuelve más clara.
15:58
Las máquinas hacen
15:58
el descubrimiento,
15:59
los humanos hacen
16:00
el juicio y la reparación.
16:01
El impacto empresarial
16:02
aquí es menos gestión de crisis.
16:04
Los equipos
16:04
ven menos tickets nocturnos,
16:06
menos regresiones
16:07
tras los lanzamientos
16:07
y una reducción notable
16:08
en el tiempo perdido
16:10
reproduciendo pasos.
16:12
Las peculiaridades
16:13
de rendimiento
16:13
se detectan
16:14
en entornos controlados
16:15
en lugar de aparecer
16:16
primero ante los usuarios finales.
16:17
Los fallos de seguridad
16:18
salen a la luz
16:19
durante las pruebas internas.
16:20
No después de un escaneo
16:21
de cumplimiento
16:21
o un ejercicio de penetración.
16:23
Ese cambio
16:23
da espacio al QA
16:24
para enfocarse
16:25
en cuestiones de mayor nivel
16:26
como usabilidad,
16:27
fluidez del flujo
16:27
de trabajo
16:28
y accesibilidad.
16:29
Áreas que ningún motor autónomo
16:30
puede juzgar
16:31
de manera significativa.
16:32
Para los profesionales
16:33
interesados en probar el terreno
16:34
empiecen poco a poco.
16:35
Ejecuten un agente
16:36
de pruebas autónomo
16:37
en un entorno de pruebas
16:38
o preproducción
16:39
durante un periodo definido.
16:41
Comparen la lista
16:42
de problemas
16:42
que descubren
16:43
con su backlog actual.
16:44
Traten el ejercicio
16:45
como una recopilación de datos.
16:46
¿Son los nuevos hallazgos
16:47
realmente útiles?
16:48
¿Se solapan
16:48
con las pruebas existentes?
16:49
¿Revelan puntos ciegos
16:50
importantes para su negocio?
16:52
Enmarcado así
16:53
se mide el retorno
16:53
de inversión
16:54
en lugar de apostar
16:55
la calidad de sus lanzamientos
16:56
a una técnica no probada.
16:58
Y cuando los equipos
16:58
realizan este tipo de pilotos
16:59
surge un patrón.
17:01
Patrón.
17:02
El verdadero beneficio
17:02
a largo plazo
17:03
no es solo detectar
17:04
errores adicionales
17:05
sino que tan rápido
17:05
esas lecciones
17:06
puedan reintegrarse
17:07
al ciclo general
17:07
de desarrollo.
17:09
Cada anomalía capturada
17:10
y cada idea registrada
17:11
representa un conocimiento
17:12
que no debería desaparecer
17:13
al finalizar un sprint.
17:14
La cuestión es
17:15
cómo se almacena,
17:16
comparte y transmite
17:16
esa inteligencia
17:17
para que los mismos
17:18
errores no se repitan
17:19
bajo nombres
17:20
de proyectos diferentes.
17:22
Cerrando el ciclo
17:23
de inteligencia en DevOps.
17:24
En DevOps
17:25
uno de los problemas
17:25
más difíciles de resolver
17:26
es la rapidez
17:27
con la que el conocimiento
17:27
se desvanece en el sprint.
17:29
Los problemas se registran
17:30
y los post-mortem se escriben
17:31
pero cuando comienza
17:32
el siguiente proyecto
17:33
muchas de esas lecciones
17:34
no llegan al flujo de trabajo.
17:36
Cerrar el ciclo de inteligencia
17:37
en DevOps
17:37
significa detener
17:38
ese ciclo de pérdida
17:39
y asegurar
17:39
que lo que los equipos
17:40
aprendan realmente mejor
17:41
es lo que viene después.
17:42
La IA gente ayuda
17:43
a esto conectándose
17:44
a los lugares
17:44
donde el conocimiento
17:45
ya está fluyendo.
17:47
El primer punto de integración
17:48
es la ingesta
17:48
de registros y telemetría.
17:50
En lugar de requerir
17:51
que los ingenieros
17:51
revisen paneles
17:52
o incidentes archivados
17:53
los agentes escanean
17:54
continuamente métricas
17:55
tasas de error
17:56
y rastros de rendimiento
17:57
conectando anomalías
17:58
entre lanzamientos.
18:00
Segundo es el análisis
18:01
del historial de solicitudes
18:02
de extracción
18:02
y revisiones de código.
18:03
Las decisiones tomadas
18:04
en los comentarios
18:05
a menudo contienen
18:05
contextos sobre compensaciones
18:07
o riesgos
18:07
que nunca llegan
18:08
a la documentación.
18:09
Al procesar esas conversaciones
18:11
los agentes preservan
18:11
el porqué de lo ocurrido
18:12
no solo lo que se fusionó.
18:14
El tercero es asignar
18:15
los fallos observados
18:16
a recomendaciones de arquitectura.
18:18
Si ciertas estrategias
18:19
de caché crean
18:19
repetidamente
18:20
un exceso de memoria
18:21
o si los patrones de escalado
18:22
provocan tiempos de espera
18:23
esas ideas surgen
18:24
durante la planificación
18:24
antes de que los mismos errores
18:26
ocurran en un nuevo sistema.
18:28
Juntos estos puntos de integración
18:29
mejoran la memoria institucional
18:30
sin prometer la perfección.
18:32
El valor no está
18:33
en que los agentes
18:33
recuerden impecablemente
18:34
cada detalle
18:35
sino en que aumentan
18:36
las probabilidades
18:36
de que las lecciones pasadas
18:37
reaparezcan en el momento adecuado.
18:39
Supervisión humana
18:40
sigue siendo importante.
18:41
Los desarrolladores
18:41
deben validar la relevancia
18:43
de las ideas surgidas
18:43
y las organizaciones
18:45
deben programar auditorías periódicas
18:46
de lo que capturan los agentes
18:47
para evitar que la desviación
18:48
o el ruido
18:49
se infiltren en el sistema.
18:51
Con una revisión cuidadosa
18:52
la inteligencia se vuelve práctica
18:53
en lugar de abrumadora.
18:55
La gobernanza
18:55
es otra pieza
18:56
que no se puede emitir.
18:57
Alimentar un sistema
18:58
de agentes con registros
18:59
solicitudes de extracción
19:00
y resultados de implementación
19:01
plantea interrogantes
19:02
sobre privacidad
19:02
retención y cumplimiento.
19:04
No todos los artefactos
19:05
deben vivir para siempre.
19:06
No todos los datos
19:07
deben ser accesibles
19:07
para cada rol.
19:09
Antes de implementar
19:10
este tipo de capa de memoria
19:11
los equipos deben definir
19:12
límites claros
19:12
de retención de datos
19:13
establecer políticas de acceso
19:15
y asegurarse
19:16
de que los datos sensibles
19:17
sean depurados o enmascarados.
19:18
Sin esos límites
19:19
corre el riesgo
19:20
de crear un repositorio
19:21
en la sombra no gobernado
19:22
del historial de la empresa
19:22
que complica a las auditorías
19:24
en lugar de apoyarlas
19:25
en lugar de apoyar.
19:26
Para los desarrolladores
19:26
el impacto más notable
19:27
ocurre durante el inicio del proyecto.
19:29
En lugar de recuerdos vagos
19:30
de lo que salió mal
19:31
la última vez
19:31
las ideas aparecen
19:32
directamente en contexto.
19:34
Inicie una nueva API web
19:35
de Domptonet
19:36
y el sistema podría sugerir.
19:38
El año pasado
19:38
esta biblioteca de Cacheca
19:40
usó fugas de memoria
19:40
bajo carga
19:41
consideró una alternativa
19:42
o durante la planificación
19:44
podría señalar
19:44
que ciertos patrones
19:45
de inyección de dependencias
19:46
crearon inestabilidad.
19:47
Los recordatorios
19:48
son oportunos
19:49
no retrospectivos
19:50
por lo que desplazan
19:50
el enfoque de reaccionar
19:51
ante problemas a prevenirlos.
19:53
Así es como
19:53
la inteligencia del proyecto
19:54
se acumula
19:55
en lugar de reiniciarse
19:55
cada vez que comienza
19:56
un nuevo sprint.
19:57
También cambia
19:58
la naturaleza
19:58
de las retrospectivas.
20:00
Las retrospectivas tradicionales
20:01
recopilan comentarios
20:02
en un momento determinado
20:02
y luego siguen a dar.
20:03
Con agentes integrados
20:05
ese conocimiento
20:05
no queda archivado.
20:07
Se reincorpora continuamente
20:08
al ciclo de desarrollo.
20:10
Los registros de este mes
20:11
anomalías de escalado
20:12
del último trimestre
20:13
o revisiones de rendimiento
20:14
de hace dos años
20:15
informan las recomendaciones
20:16
de hoy.
20:18
Al convertir cada lanzamiento
20:19
en parte de un ciclo
20:20
de formación continua
20:21
los equipos reducen
20:21
la posibilidad
20:22
de repetir fallos
20:22
del pasado.
20:24
Así los resultados
20:25
deben medirse
20:25
no suponerse.
20:26
Un primer paso sencillo
20:27
es integrar al agente
20:28
con una única fuente
20:29
de telemetría
20:29
como registros
20:30
de aplicaciones
20:30
o una fuente APM
20:31
y ejecutarlo
20:32
durante 12p.
20:33
Luego compare
20:33
y detectó al agente
20:34
patrones
20:34
que usted no había notado.
20:36
Condujeron estos patrones
20:37
a cambios reales
20:38
en el código
20:38
de la infraestructura
20:39
y mejoró notablemente
20:40
la calidad
20:40
de los lanzamientos.
20:42
Si la respuesta es sí
20:43
entonces tiene sentido
20:44
expandirse
20:44
al historial de PR
20:45
o al mapeo arquitectónico.
20:47
Si no,
20:47
el experimento mismo
20:48
revela que necesita ajustes
20:49
ya sean fuentes de datos,
20:51
gobernanza
20:51
o procesos de revisión.
20:53
Con el tiempo
20:54
la recompensa
20:54
es acumulativa.
20:55
Al mejorar
20:56
la memoria institucional
20:57
la velocidad
20:57
de lanzamiento
20:58
se estabiliza
20:59
y la arquitectura
20:59
se vuelve más resiliente
21:00
y se desperdicia
21:01
menos energía
21:02
en redescubrir
21:02
viejos errores.
21:05
El conocimiento
21:06
deja de perderse
21:07
y en su lugar
21:07
se acumula
21:07
como un recurso útil
21:08
en el que los equipos
21:09
pueden confiar
21:09
y en ese punto
21:11
el papel de la agente
21:11
parece distinto.
21:13
Ya no es solo
21:13
un asistente
21:14
en una etapa
21:14
del desarrollo.
21:15
Empieza a unir
21:15
todo el proceso
21:16
transmitiendo
21:17
las lecciones aprendidas
21:17
en lugar de dejar
21:18
que caduquen.
21:20
Esa continuidad
21:21
es lo que transforma
21:22
DevOps
21:22
de un conjunto
21:23
de tareas aisladas
21:24
a un ciclo de vida
21:24
más conectado
21:25
preparando el terreno
21:26
para el cambio generalizado
21:27
en los equipos de software.
21:30
La IA Gente
21:30
señala un cambio práctico
21:31
en el desarrollo.
21:33
Concepto
21:34
no es un asistente
21:34
de código
21:35
sino un sistema
21:35
que conserva memoria
21:36
con texto
21:37
y objetivos
21:37
durante todo el ciclo de vida.
21:39
Aplicación
21:40
Los puntos de entrada
21:40
más claros
21:41
para equipos
21:41
de Tonto,
21:42
Net y Azure
21:42
son la creación
21:43
de nuevos proyectos
21:43
permitir que los agentes
21:44
manejen el aprovisionamiento
21:45
rutinario
21:46
y experimentar
21:46
con pruebas automatizadas.
21:48
Impacto
21:49
si se hace con cuidado
21:50
esto agiliza
21:50
los flujos de trabajo
21:51
reduce los costos
21:52
de configuración
21:52
y disminuye
21:53
la posibilidad
21:53
de repetir fallos
21:54
del pasado
21:55
en futuros proyectos.
21:56
El mejor siguiente paso
21:57
es probarlo
21:57
en su propio entorno.
21:59
Prueba habilitar Copilot
22:00
en un pequeño prototipo
22:01
o ejecuta a un agente
22:02
en el entorno de pruebas
22:03
y luego sigue una métrica
22:03
tiempo ahorrado
22:04
errores descubiertos
22:05
o desviaciones evitadas.
22:07
Si tienes un desafío
22:07
de DevOps recurrente
22:08
que ralentiza tu equipo
22:09
déjalo en los comentarios
22:10
para que otros puedan comparar.
22:12
Si quieres consejos
22:13
más prácticos
22:14
sobre Tonto, Net y Azure
22:14
y la adopción de IA
22:15
suscríbete
22:16
para futuros análisis.
22:18
Las ganancias
22:18
parecen pequeñas al principio
22:20
pero se multiplican
22:20
con gobernanza
22:21
y supervisión constante.