WEBVTT

00:00:00.500 --> 00:00:07.040
Listo para 10 días de Microsoft 365, Copilot y App, Azure y las personas que están dando forma al futuro del trabajo.

00:00:07.880 --> 00:00:11.240
Este enero, regresa a MM35 con y venimos a lo grande.

00:00:11.640 --> 00:00:12.360
Y venimos a lo grande.

00:00:12.860 --> 00:00:18.080
Únete a nosotros para sesiones en vivo, demostraciones reales y conocimientos prácticos de MVP y expertos de la industria de todo el mundo.

00:00:18.880 --> 00:00:20.920
Nada de diapositivas genéricas, nada de parada eliminable.

00:00:22.020 --> 00:00:23.400
Abordaremos desafíos reales.

00:00:23.780 --> 00:00:28.680
Copilots Studio, agentes de IA, Fabric, seguridad, gobernanza y automatización.

00:00:28.680 --> 00:00:34.360
Tanto si eres profesional de TI, desarrollador o líder empresarial, hay sesiones diseñadas para ti.

00:00:35.560 --> 00:00:39.960
Con 10 días completos, puedes explorar múltiples tecnologías y conectar con una comunidad global.

00:00:40.960 --> 00:00:44.340
Mira en vivo y lleva ideas prácticas de vuelta a tu organización.

00:00:45.160 --> 00:00:48.900
Enero de 2027, 10 días, una comunidad de Microsoft.

00:00:49.480 --> 00:00:50.460
El registro ya está abierto.

00:00:51.900 --> 00:00:55.580
Ve a m365com.net y asegura tu lugar hoy mismo.

00:00:56.000 --> 00:00:58.640
Eso es m365com.net.

00:00:59.680 --> 00:01:04.720
Únete ahora en m365com.net y nos vemos en vivo en enero.

00:01:05.180 --> 00:01:11.920
Si alguna vez has abierto una solución y te has sentido abrumado al instante por la red de archivos, referencias y errores esperando en buscarte, no estás solo.

00:01:12.400 --> 00:01:14.980
La mayoría de los desarrolladores trabajan de forma reactiva, pacheando aquí y depurando allá.

00:01:15.320 --> 00:01:19.680
El modo agente de GitHub Copilot tiene como objetivo mantener un contexto más amplio y coordinar cambios en varios archivos.

00:01:20.260 --> 00:01:25.040
En este video demostraremos cómo se ve ese flujo de trabajo dentro de un proyecto real de DonTonet y Azure.

00:01:25.580 --> 00:01:28.240
Analizaremos una solución en vivo y mostraremos el antes y el después de los cambios de la agenda.

00:01:28.660 --> 00:01:35.720
Verás cómo generar código para múltiples archivos con menos esfuerzo, resolver errores entre archivos más rápido e incluso usar lenguaje natural para estructurar funciones.

00:01:36.680 --> 00:01:41.040
Y antes de llegar a eso, comencemos con el costo oculto del ciclo de depuración en el que muchos de nosotros vimos a diario.

00:01:41.040 --> 00:01:43.460
El costo oculto de la depuración por parte

00:01:43.460 --> 00:01:45.880
Te sientas a corregir un error que parece bastante simple.

00:01:46.620 --> 00:01:49.880
La aplicación no compila y la consola marca una línea en tu archivo principal de proyecto.

00:01:50.680 --> 00:01:55.840
Ajustas el método, recompilas y crees que lo has resuelto hasta que el mismo mensaje reaparece de forma ligeramente distinta.

00:01:56.400 --> 00:01:59.180
Pasa otra media hora antes de que detectes el problema real.

00:01:59.720 --> 00:02:02.160
Una dependencia faltante escondida en otra carpeta del proyecto.

00:02:02.460 --> 00:02:06.780
Para cuando corriges la referencia y vuelves a implementar, gran parte de tu tarde se ha disuelto en parches.

00:02:07.320 --> 00:02:09.800
El trabajo de funciones que planeaste se pospone para mañana.

00:02:09.800 --> 00:02:11.740
El patrón es tan común que parece normal.

00:02:12.380 --> 00:02:15.300
En la superficie avanzas porque cada error que eliminas se siente como una victoria.

00:02:16.120 --> 00:02:17.360
La práctica está dando vueltas en cero.

00:02:17.840 --> 00:02:20.420
El ciclo es programar, compilar, error, corregir, repetir.

00:02:21.000 --> 00:02:23.560
Las horas se desvanecen persiguiendo un rastro de causa y efecto

00:02:23.560 --> 00:02:26.720
y el resultado neto es progreso reactivo en lugar de mejoras significativas.

00:02:27.260 --> 00:02:29.380
¿Cuántos de ustedes han perdido una tarde entera en este mismo ciclo?

00:02:29.700 --> 00:02:31.800
Deja un comentario brevele a la respuesta más destacada.

00:02:32.920 --> 00:02:37.000
Lo que hace este ciclo agotador es que las herramientas que nos rodean siguen avanzando, pero el patrón no.

00:02:37.000 --> 00:02:41.540
Los editores añaden funciones, los marcos evolucionan y las integraciones son más profundas,

00:02:41.760 --> 00:02:43.480
pero depurar sigue exigiendo un enfoque reactivo.

00:02:44.140 --> 00:02:46.480
Es como intentar frenar un incendio creciente con un balde de agua.

00:02:47.480 --> 00:02:50.580
Cada brote se controla al momento, pero las condiciones que lo provocaron permanecen,

00:02:50.680 --> 00:02:52.260
casi garantizando la siguiente llamarada.

00:02:52.940 --> 00:02:55.160
Y con cada cambio de pestaña, el costo oculto aumenta.

00:02:55.640 --> 00:02:59.580
Pasas de una casa de servicio a un archivo de configuración y luego saltas a un gráfico de dependencias.

00:03:00.260 --> 00:03:03.960
Cada cambio te saca del hilo lógico que sigues obligándote a un reinicio mental.

00:03:04.740 --> 00:03:06.480
No son solo los segundos al cambiar de ventana,

00:03:06.580 --> 00:03:09.300
es el desgaste mental de reconstruir el contexto una y otra vez.

00:03:10.220 --> 00:03:12.580
A lo largo del día, esos pequeños reinicios se acumulan en algo pesado.

00:03:13.160 --> 00:03:16.520
Para los desarrolladores individuales, la fatiga se manifiesta como frustración y tiempo perdido.

00:03:17.260 --> 00:03:19.760
Para los equipos en proyectos empresariales, el impacto se multiplica.

00:03:20.620 --> 00:03:22.740
Los ciclos de depuración desvían los objetivos del sprint,

00:03:22.880 --> 00:03:26.060
que trazan lanzamientos y crean una acumulación que crece más rápido de lo que se reduce.

00:03:26.880 --> 00:03:30.640
El fortalecimiento de la deuda técnica es solo otro efecto secundario de las horas perdidas apagando fuegos.

00:03:31.640 --> 00:03:35.540
Muchos equipos informan que una gran parte de su tiempo de desarrollo se consume en depuración reactiva.

00:03:35.960 --> 00:03:37.240
No es la parte emocionante de la ingeniería.

00:03:37.900 --> 00:03:41.600
Nadie planifica una hoja de ruta en torno a perseguir cinco veces la misma discrepancia de dependencias.

00:03:41.600 --> 00:03:43.920
Sin embargo, ahí es donde se va el ancho de banda, semana tras semana.

00:03:44.940 --> 00:03:46.960
Cuando corregir errores se vuelve la definición de progreso,

00:03:47.100 --> 00:03:48.620
crear nuevas funciones pasa a segundo plano

00:03:48.620 --> 00:03:50.640
y la arquitectura sufre silenciosamente.

00:03:51.400 --> 00:03:54.940
La verdad incómoda es que la depuración improvisada no solo ralentiza las cosas,

00:03:55.700 --> 00:03:58.100
refuerza una cultura de reacción en lugar de diseño.

00:03:58.740 --> 00:04:01.240
Pasas el tiempo apagando llamas, no construyendo sistemas.

00:04:02.380 --> 00:04:04.320
Eso puede mantener el producto a flote a corto plazo,

00:04:04.460 --> 00:04:07.540
pero limita la escalabilidad del equipo y la confianza al lanzar.

00:04:08.120 --> 00:04:09.720
Detengamos en esa imagen, apagar incendios.

00:04:10.400 --> 00:04:12.040
Corre al foco, echar agua y seguir adelante.

00:04:12.800 --> 00:04:14.680
El problema no es que los desarrolladores no sean buenos en eso.

00:04:15.000 --> 00:04:15.300
Lo son.

00:04:16.200 --> 00:04:17.800
El problema es que las llamas nunca se detienen realmente.

00:04:17.800 --> 00:04:21.660
Solo se mueven apareciendo nuevos archivos, proyectos y configuraciones,

00:04:21.780 --> 00:04:24.180
manteniendo a todos en modo respuesta en lugar de creación.

00:04:25.340 --> 00:04:28.360
Eso plantea la pregunta, ¿qué pasaría si el ciclo no dependiera solo de ti?

00:04:29.320 --> 00:04:32.940
¿Qué pasaría si las partes repetitivas, el ciclo de rastrear, cambiar y parchear,

00:04:33.020 --> 00:04:36.020
pudieran gestionarse de otra forma mientras tú te enfocas en construir?

00:04:36.020 --> 00:04:40.520
Porque si bien la presión de apagar incendios es obvia, hay otro punto crítico que aún no hemos tocado.

00:04:41.400 --> 00:04:44.460
El verdadero peso llega cuando tu proyecto no es solo un archivo o un módulo.

00:04:45.240 --> 00:04:47.580
Es cuando la solución que necesitas abarca varias capas a la vez.

00:04:48.400 --> 00:04:53.620
Imagina abrir una solución, donde la lógica se extiende, por diferentes proyectos, servicios y bibliotecas.

00:04:53.620 --> 00:04:57.520
La pieza que necesitas vive en tres lugares al mismo tiempo.

00:04:57.760 --> 00:04:59.720
Mantenerla clara en tu mente es toda una batalla.

00:05:01.120 --> 00:05:03.780
Caos entre múltiples archivos frente al control de contexto de la IA.

00:05:04.320 --> 00:05:08.360
Cuando los proyectos abarcan múltiples capas, el verdadero desafío no es escribir código,

00:05:08.720 --> 00:05:10.380
es mantener unidas todas las partes móviles.

00:05:11.000 --> 00:05:15.520
Aquí es donde la tensión entre el caos de múltiples archivos y el control de contexto por IA se muestra más claramente.

00:05:16.200 --> 00:05:19.000
Toma una solución tu net grande con una docena o más de proyectos.

00:05:19.480 --> 00:05:21.760
Cualquier función nueva suele tocar diferentes capas a la vez.

00:05:22.420 --> 00:05:27.160
Un controlador en un lugar, un servicio en otro y un conjunto de archivos de configuración que viven en otra parte.

00:05:27.980 --> 00:05:31.880
Antes de escribir una sola línea, pasas tiempo rastreando referencias y verificando dependencias,

00:05:32.020 --> 00:05:34.940
esperando que un pequeño cambio no provoque errores inesperados más adelante.

00:05:36.100 --> 00:05:37.360
Ese flujo de trabajo no es una excepción.

00:05:37.360 --> 00:05:41.880
Es normal en aplicaciones empresariales, especialmente cuando los servicios de Azure y las integraciones entran en escena.

00:05:42.840 --> 00:05:44.680
La estructura de estos sistemas no es plana.

00:05:44.680 --> 00:05:49.380
Las interfaces, los mapeos de inyección de dependencias y las referencias entre proyectos juegan un papel importante.

00:05:50.040 --> 00:05:53.480
Con Azure en la mezcla, algunas dependencias salen completamente de la cárpeta de la solución,

00:05:53.580 --> 00:05:58.300
aplicaciones de funciones, enlaces de bus de servicio, configuraciones de recursos y conexiones de recursos y conexiones de almacenamiento.

00:05:59.040 --> 00:06:03.700
Estás coordinando entre código en tu IDE, archivos de configuración en disco y servicios definidos en la nube.

00:06:04.060 --> 00:06:06.040
A ninguno le importa que quisiera hacer menos clics.

00:06:06.500 --> 00:06:09.520
Cada vez que cambias de contexto, consumas energía reconstruyendo la visión general.

00:06:10.620 --> 00:06:12.940
La mayoría de nosotros intentamos manejar ese contexto en la memoria de Tron.

00:06:12.940 --> 00:06:16.500
Al principio es manejable, pero a medida que el proyecto crece, los errores se cuelan.

00:06:16.940 --> 00:06:19.540
Agregas un nuevo método en el servicio, pero olvidas su registro de DDI.

00:06:19.900 --> 00:06:25.060
Programas una función de Azure y más tarde te das cuenta de que el enlace nunca se agregó al host.json o a la plantilla de incrementación.

00:06:25.500 --> 00:06:28.400
Nada te avisa hasta el tiempo de ejecución cuando estás depurando en lugar de construir.

00:06:28.860 --> 00:06:30.240
El código en sí mismo no es la parte difícil.

00:06:30.540 --> 00:06:31.520
Es la coordinación entre archivos.

00:06:32.080 --> 00:06:34.220
Todos conocen la sensación de saltar entre pestañas.

00:06:34.640 --> 00:06:38.660
De un controlador a un servicio, luego a un modelo, después a archivos de configuración y de vuelta,

00:06:38.800 --> 00:06:41.500
solo para perder el rastro de por qué abriste ese archivo.

00:06:41.500 --> 00:06:44.540
Es una pequeña interrupción que se repite ocenas de veces en DDI.

00:06:45.100 --> 00:06:48.380
Esas interacciones se acumulan, creando una fricción que ralentiza el progreso real.

00:06:48.960 --> 00:06:53.680
El resultado es una entrega más lenta, no porque escribirse a lento, sino porque mantener todo sincronizado o al enfoque.

00:06:54.280 --> 00:06:56.380
Esta carga de trabajo crece en proyectos diseñados para DDI.

00:06:56.940 --> 00:06:59.320
Azure distribuye configuraciones clave en varios lugares.

00:06:59.740 --> 00:07:06.440
Archivos de configuración locales, variables de entorno, plantillas a RM o BICEP y canalizaciones CI, CD, CD.

00:07:06.440 --> 00:07:10.460
Lo que parece una simple solicitud de función a menudo se extiende por cuatro capas de abstracción.

00:07:11.440 --> 00:07:12.520
La complejidad no es opcional.

00:07:12.940 --> 00:07:14.780
Está integrada en la forma en que funciona el ecosistema.

00:07:15.480 --> 00:07:17.680
Aquí es donde el modo agente se presenta como un cambio potencial.

00:07:18.140 --> 00:07:22.380
En lugar de dejarle toda esa orquestación a usted, está diseñado para mantener un contexto más amplio entre múltiples archivos.

00:07:23.220 --> 00:07:26.420
No significa que cuando solicita un cambio en una capa, no ignora a las demás.

00:07:26.420 --> 00:07:37.780
En la demostración, crearé una nueva función de Azure y mostraré cómo ayuda a la gente generando el cuerpo del método, creando la configuración de enlace, actualizando host, ASON e incluso sugiriendo registro de dependencias correcto.

00:07:38.100 --> 00:07:40.960
Por lo general, es un proceso de varios pasos dispersos en diferentes archivos.

00:07:41.420 --> 00:07:43.200
Un agente puede simplificarlo todo en un solo flujo.

00:07:44.020 --> 00:07:49.540
No se trata de reemplazar su criterio, sino de eliminar el trabajo administrativo repetitivo para que pueda enfocarse en las decisiones de diseño.

00:07:50.600 --> 00:07:54.620
Los humanos podemos mantener un esquema general en la mente o dibujar una pizarra.

00:07:54.620 --> 00:07:57.680
Una IA puede rastrear los detalles archivo por archivo sin perder el hilo.

00:07:58.360 --> 00:08:01.800
Lo que para nosotros supone una gran carga cognitiva es solo contexto base para la gente.

00:08:02.360 --> 00:08:06.860
La diferencia en la práctica es pasar de hacer malabares con pestañas a cambios orquestados que se mantienen sincronizados.

00:08:07.300 --> 00:08:12.080
También mostraré el pull request o la diferencia creada por el agente durante la demo para que vea exactamente qué ediciones se hicieron.

00:08:12.680 --> 00:08:13.900
Esa visibilidad es importante.

00:08:14.200 --> 00:08:18.680
Usted mantiene el control total para revisar y aprobar, mientras el trabajo, pese a actualizar varios archivos, se hace por usted.

00:08:18.680 --> 00:08:25.640
Así, en lugar de pasar la tarde uniendo fragmentos, dirige el cambio una vez, confirma las actualizaciones generadas y pasa al diseño de alto nivel y pasa a alto nivel.

00:08:26.360 --> 00:08:33.140
El alivio no está solo en ahorrar clics o teclas, sino en mantener el enfoque en resolver problemas reales en lugar de recordar cómo se conectan a una docena de archivos.

00:08:34.520 --> 00:08:41.680
Esta ventaja se nota más cuando las cosas fallan, porque incluso con un mejor manejo del contexto los sistemas fallan, las configuraciones se debían, las referencias incorrectas reaparecen.

00:08:41.680 --> 00:08:46.820
Y ahí es donde comienza la siguiente prueba, cómo se rastrean y resuelven los errores una vez que aparecen.

00:08:47.720 --> 00:08:49.300
De la búsqueda de errores a soluciones autónomas.

00:08:49.780 --> 00:08:53.220
Piensa en cuántas veces ha visto un mensaje de error que apunta directamente a un solo archivo.

00:08:53.860 --> 00:08:57.620
Sigue el seguimiento de pila hasta el método que menciona, hace un pequeño ajuste y vuelve a compilar.

00:08:58.460 --> 00:09:03.160
Parece la solución obvia, hasta que el mismo error aparece de nuevo, solo que de una forma ligeramente distinta.

00:09:03.720 --> 00:09:06.000
Es entonces cuando se da cuenta de que el seguimiento de pila es solo mostrador.

00:09:06.260 --> 00:09:11.620
El problema real vive en otra parte, tal vez en una clase de soporte o escondido en un archivo de configuración que no ha abierto en toda la semana.

00:09:12.060 --> 00:09:14.020
Todo desarrollador se ha enfrentado a ese tipo de desorientación.

00:09:14.380 --> 00:09:16.900
Lo que parece ser el problema no es donde realmente debe aplicarse la solución.

00:09:17.200 --> 00:09:18.160
Esto consume tiempo rápidamente.

00:09:18.560 --> 00:09:19.920
Ajustas una cosa, recompilas y espera.

00:09:20.760 --> 00:09:24.200
Luego aparece un nuevo error que te lleva a otro archivo, otro ajuste y otra recompilación.

00:09:25.100 --> 00:09:28.160
El ciclo parece productivo porque estás en movimiento, escribiendo y recompilando.

00:09:28.440 --> 00:09:31.640
Pero en el fondo es más ensayo y error que una solución real.

00:09:32.160 --> 00:09:35.980
Ese ciclo puede absorber horas, dejándote con pequeñas correcciones superficiales,

00:09:36.020 --> 00:09:38.240
pero sin avanzar realmente en la función con la que empezaste.

00:09:38.900 --> 00:09:40.200
El costo real aquí es la oportunidad.

00:09:40.200 --> 00:09:43.480
Mientras estás atrapado en el ritmo de recompilar y reintentar,

00:09:43.640 --> 00:09:47.200
no estás resolviendo problemas de negocio ni lanzando la funcionalidad que tus usuarios esperan.

00:09:48.060 --> 00:09:50.100
El impulso se pierde en conjeturas en lugar de diseño.

00:09:50.460 --> 00:09:55.520
Se siente activo en el momento, pero esas horas no suman mucho más allá de evitar que el sistema se rompa.

00:09:56.300 --> 00:10:00.900
En un equipo, este movimiento superficial ralentiza todo y crea un atraso de funciones que siguen posponiéndose.

00:10:00.900 --> 00:10:04.800
Aquí es donde un flujo de trabajo con agentes empieza a verse diferente.

00:10:05.340 --> 00:10:07.900
La idea no es detenerse en la línea que destaca tu rastro de pila.

00:10:08.280 --> 00:10:11.200
En cambio, está diseñado para mantener el contexto a nivel de sistema,

00:10:11.340 --> 00:10:13.140
preguntando no solo qué debería hacer este archivo,

00:10:13.680 --> 00:10:17.700
sino qué secuencia de cambios se necesita en las partes conectadas para restaurar la consistencia.

00:10:18.480 --> 00:10:22.020
En la práctica, esto significa que puedes verlo o proponer ediciones que abarcan múltiples archivos.

00:10:22.420 --> 00:10:25.080
Por ejemplo, verás en la demostración que cuando un método requiere cambios,

00:10:25.200 --> 00:10:28.720
puedes sugerir ediciones coincidentes en configuraciones relacionadas o plantillas de despliegue,

00:10:29.240 --> 00:10:30.480
en lugar de dejar que tú las busques.

00:10:31.040 --> 00:10:33.080
Ese es el salto del autocompletado a algo más amplio.

00:10:34.100 --> 00:10:35.340
El autocompletado termina líneas.

00:10:35.420 --> 00:10:38.200
Un agente coordina entre archivos y esa coordinación importa más

00:10:38.200 --> 00:10:40.320
cuando los errores no residen claramente en un solo lugar.

00:10:40.980 --> 00:10:42.100
Tomemos un escenario común de ASO.

00:10:42.640 --> 00:10:44.840
Creaste una nueva aplicación de funciones, pero una vez desplegada,

00:10:44.980 --> 00:10:47.660
el disparador decola falla porque el enlace no coincide con la firma del método.

00:10:49.040 --> 00:10:51.440
Normalmente, revisas registros, descubres que el enlace está mal,

00:10:51.440 --> 00:10:53.540
ajustas el JSON de la función manualmente,

00:10:53.640 --> 00:10:55.260
tal vez incluso alteras tu plantilla de infraestructuras

00:10:55.260 --> 00:10:56.360
y un valor tampoco coincide ahí.

00:10:58.060 --> 00:11:01.120
Cada paso es una búsqueda separada y cada corrección activa otra ejecución de prueba.

00:11:02.100 --> 00:11:03.840
Con el modo agente, el flujo de trabajo es diferente.

00:11:04.200 --> 00:11:05.400
Puede proponer el cambio de código,

00:11:05.640 --> 00:11:07.400
generar el enlace JSON de función correcto

00:11:07.400 --> 00:11:10.080
y mostrar ediciones para scripts de despliegue si no están alineados.

00:11:11.060 --> 00:11:15.080
Revisas, confirmas y avanzas sin pasar horas uniendo cada capa y acrofícola.

00:11:15.800 --> 00:11:18.800
Nadie debería sentir que se están realizando ediciones invisibles en segundo plan.

00:11:19.000 --> 00:11:20.240
Por eso el flujo de revisión es importante.

00:11:20.240 --> 00:11:22.020
En esta demostración lo recorremos juntos.

00:11:22.540 --> 00:11:24.100
El agente sugiere los cambios coordinados.

00:11:24.620 --> 00:11:27.060
Abriremos el DIF para inspeccionar exactamente lo que generó,

00:11:27.180 --> 00:11:28.400
ejecutar nuestras pruebas unitarias,

00:11:28.620 --> 00:11:29.860
validar la compilación localmente

00:11:29.860 --> 00:11:32.420
y solo entonces elegir si aceptamos o rechazamos los cambios.

00:11:33.580 --> 00:11:35.300
Ese ciclo de validación te mantiene en pleno control

00:11:35.300 --> 00:11:36.640
mientras elimina el trabajo pesado.

00:11:37.640 --> 00:11:40.220
Vale la pena recalcar que los agentes pueden ayudar a avanzar más rápido,

00:11:40.360 --> 00:11:41.800
pero no reemplazan las buenas pruebas de ingeniería.

00:11:42.360 --> 00:11:44.500
Debes seguir tratando las revisiones de código de integración continuada

00:11:44.500 --> 00:11:45.440
así como guardián en no negocio.

00:11:45.440 --> 00:11:47.920
Deja que la guía reduzca el tiempo que pasas en tareas de detective,

00:11:48.060 --> 00:11:50.900
pero mantén las verificaciones automáticas y la revisión humana como red de seguridad.

00:11:51.620 --> 00:11:53.160
Ese equilibrio resuelve el problema de confianza

00:11:53.160 --> 00:11:55.520
y asegura que la ganancia de velocidad no comprometa la estabilidad.

00:11:56.060 --> 00:11:57.560
La diferencia de velocidad no es teórica.

00:11:58.000 --> 00:12:00.740
Donde la búsqueda de errores y los parches manuales pueden consumir mediodía,

00:12:00.960 --> 00:12:02.840
las sugerencias coordinadas pueden reducirlo a minutos.

00:12:03.220 --> 00:12:07.220
Y el tiempo recuperado fluye de regreso al trabajo en el que realmente quieres invertir tu energía.

00:12:07.720 --> 00:12:11.060
Las funciones que notan tus usuarios y las decisiones de arquitectura que mejoran tu base de código.

00:12:11.060 --> 00:12:15.000
En lugar de apagar fuegos durante la ejecución, puedes diseñar con confianza desde el principio.

00:12:15.580 --> 00:12:17.700
Así que el ciclo de depuración ya no tiene por qué definir tu día.

00:12:18.440 --> 00:12:20.560
Con un agente que sugiere actualizaciones entre archivos,

00:12:20.720 --> 00:12:23.280
pasas de una búsqueda dispersa a un ritmo de revisar y aprobar,

00:12:23.900 --> 00:12:25.860
dejas de dar vueltas en círculos a través de los errores

00:12:25.860 --> 00:12:27.980
y comienzas a tratar la depuración como un paso estructurado,

00:12:28.180 --> 00:12:30.400
casi automatizado, casi automatizado en tu flujo de trabajo.

00:12:30.580 --> 00:12:33.520
Ese cambio libera espacio cognitivo y horas en el calendario para crear funciones,

00:12:33.640 --> 00:12:34.460
no solo para corregir fallas.

00:12:34.960 --> 00:12:37.640
Y una vez que corregir errores deja de tratarse de perseguir síntomas,

00:12:37.640 --> 00:12:39.020
se abre la puerta a algo más grande.

00:12:39.740 --> 00:12:42.280
¿Cómo podrías iniciar funciones completas de la misma manera estructurada?

00:12:42.900 --> 00:12:45.800
Imagina si el mismo flujo de trabajo que propone correcciones coordinadas

00:12:45.800 --> 00:12:48.280
pudiera también tomar una especificación en lenguaje sencillo

00:12:48.280 --> 00:12:50.220
y dar forma a una estructura funcional en torno a ella.

00:12:50.820 --> 00:12:52.660
Ahí es donde comienza la siguiente etapa del desarrollo.

00:12:53.620 --> 00:12:55.580
Desarrollo basado en especificaciones y en la sobrecarga misma.

00:12:56.320 --> 00:12:58.700
Uno de los cambios más interesantes ocurre cuando dejas de pensar

00:12:58.700 --> 00:13:00.140
solo en términos de archivos y métodos

00:13:00.140 --> 00:13:02.240
y comienzas a plantear el trabajo en lenguaje sencillo.

00:13:03.200 --> 00:13:05.820
Ahí es donde entra el desarrollo basado en especificaciones y en la sobrecarga misma.

00:13:05.820 --> 00:13:07.980
Imagina redactar una solicitud de función sencilla.

00:13:08.460 --> 00:13:11.180
Añade un flujo de trabajo de informes que genere resúmenes mensuales,

00:13:11.300 --> 00:13:13.900
los almacene y los haga disponibles a través de una página de administración.

00:13:14.600 --> 00:13:16.720
En lugar de obtener solo unos pocos fragmentos aislados,

00:13:16.940 --> 00:13:19.420
obtienes una estructura funcional ya mapeada a través de tu aplicación.

00:13:20.220 --> 00:13:23.900
Controladores preparados, modelos creados, servicios registrados y configuración conectada.

00:13:24.780 --> 00:13:28.280
Ese paso de describir la intención a ver aparecer un andamiaje concreto en tu proyecto

00:13:28.280 --> 00:13:31.260
es donde este enfoque finalmente se siente práctico en lugar de teórico.

00:13:31.820 --> 00:13:35.620
En configuraciones tradicionales, el desarrollo basado en especificaciones tiene una reputación pesada.

00:13:35.820 --> 00:13:39.160
En grandes organizaciones, generalmente significa largos documentos de requisitos,

00:13:39.340 --> 00:13:42.100
hojas de diseño de varias páginas y diagramas rígidos que retrasan a todos.

00:13:42.380 --> 00:13:44.760
Tienen sentido en industrias reguladas o equipos distintos globalmente,

00:13:44.840 --> 00:13:47.500
pero para la programación diaria, la mayoría de los desarrolladores los omiten.

00:13:47.980 --> 00:13:51.560
Escribir y mantener especificaciones detalladas añada un costo para que nadie tiene paciencia ni tiempo.

00:13:52.240 --> 00:13:55.800
Es trabajo extra acumulado sobre la entrega de funciones y a medida que se acercan los plazos,

00:13:56.120 --> 00:13:57.740
esos ciclos adicionales suelen sacrificarse.

00:13:58.340 --> 00:14:01.080
La ironía es clara, a los desarrolladores en realidad les gusta pensar en términos generales.

00:14:01.980 --> 00:14:03.840
Conocer la estructura de antemano es tranquilizador.

00:14:04.300 --> 00:14:05.880
El problema no es la intención, sino el mantenimiento.

00:14:06.440 --> 00:14:08.700
Una vez que la especificación empieza a perder sincronización con la realidad,

00:14:09.100 --> 00:14:10.100
el mantenimiento se vuelve una carga.

00:14:10.660 --> 00:14:14.280
Por eso, gran parte del trabajo real deriva hacia la improvisación en lugar del diseño completo,

00:14:14.400 --> 00:14:17.360
incluso en empresas que técnicamente respaldan una planificación exhaustiva.

00:14:18.020 --> 00:14:19.760
Un flujo de trabajo con agentes ofrece un alternativo.

00:14:19.760 --> 00:14:22.000
En lugar de exigir un documento de diseño pulido,

00:14:22.100 --> 00:14:22.680
puede ser un pulido,

00:14:22.820 --> 00:14:25.700
puede dar a traducir una especificación en lenguaje sencillo a una base de refinar.

00:14:26.180 --> 00:14:29.200
No necesitas diagramas, UML, ni mapas de interfaz escritos a mano.

00:14:29.900 --> 00:14:30.780
Simplemente puedes decir,

00:14:30.920 --> 00:14:33.280
crea un módulo de informes con un nuevo endpoint de API,

00:14:33.700 --> 00:14:36.360
vincularlo al almacenamiento y asegurarlo con acceso basado en roles.

00:14:36.780 --> 00:14:39.640
Y el sistema genera una base en los archivos de tu solución .net.

00:14:40.160 --> 00:14:43.540
En la demostración, leeré una especificación en lenguaje sencillo.

00:14:43.540 --> 00:14:45.980
En voz alta, mostraré los archivos que produjo el agente,

00:14:46.100 --> 00:14:47.920
controladores, modelos y registro de servicios.

00:14:47.920 --> 00:14:50.500
Y señalaré los puntos que aún necesitaba un refinamiento manual.

00:14:51.280 --> 00:14:53.220
De esa manera, puedes juzgar la calidad por ti mismo.

00:14:53.880 --> 00:14:56.120
Esto establece un punto medio entre dos modos de desarrollo.

00:14:56.860 --> 00:15:00.640
Por un lado está la programación intuitiva, rápida, libre, pero frágil, pero frágil para sistemas de labor.

00:15:01.140 --> 00:15:03.400
Por el otro lado está el diseño basado en especificaciones.

00:15:03.800 --> 00:15:05.200
Fiable, pero dolorosamente lento.

00:15:06.340 --> 00:15:08.740
Con el apoyo de un agente, describes la idea con palabras naturales,

00:15:08.860 --> 00:15:09.760
aparece la estructura base,

00:15:09.760 --> 00:15:12.360
y puedes iterar casi tan rápido como con la programación intuitiva,

00:15:12.460 --> 00:15:14.080
manteniendo el beneficio de una estructura organizada.

00:15:14.400 --> 00:15:16.100
Tomemos de nuevo ese flujo de trabajo de informe.

00:15:16.100 --> 00:15:19.620
Normalmente tendrías que crearlo, el modelo, construir el servicio de datos,

00:15:19.760 --> 00:15:23.380
conectar el controlador, configurar la seguridad y vincular todo en el inicio.

00:15:23.820 --> 00:15:26.720
Esto significa saltar entre múltiples archivos esperando que la consistencia se mantenga.

00:15:27.200 --> 00:15:29.380
Con este enfoque, la estructura base se coloca en su lugar de inmediato.

00:15:30.000 --> 00:15:33.980
El verdadero ahorro proviene menos de escribir menos líneas y más de evitar errores entre archivos,

00:15:34.180 --> 00:15:36.720
como olvidar registrar un nuevo servicio después de haberlo construido.

00:15:36.940 --> 00:15:38.720
Por supuesto, siempre está la cuestión del estilo.

00:15:39.360 --> 00:15:41.820
Forzar a la IA un código repetitivo o ignorar a las convenciones.

00:15:41.820 --> 00:15:45.980
En la práctica, los agentes a menudo reflejan los patrones de proyectos existentes en sus sugerencias.

00:15:46.480 --> 00:15:48.000
En la demostración verás ambas caras.

00:15:48.740 --> 00:15:51.840
Lugares donde coincidió perfectamente con la estructura de controlador de nuestro equipo

00:15:51.840 --> 00:15:54.020
y lugares donde sus suposiciones se desviaron.

00:15:54.420 --> 00:15:55.120
Esa mecha es importante.

00:15:55.720 --> 00:15:57.960
Sabrás en qué puedes confiar y qué necesitas ajustar todavía.

00:15:58.600 --> 00:16:00.100
El resultado final no es código estandarizado.

00:16:00.560 --> 00:16:03.480
Sigues sintiéndose como tu proyecto, solo que con menos trabajo manual de estructura.

00:16:04.160 --> 00:16:08.320
Mantienes la velocidad y sigues contando con una base que puedes perfeccionar para el crecimiento futuro,

00:16:08.320 --> 00:16:12.580
en lugar de que el trabajo de especificación se limite a arquitectos con paciencia para diagramas.

00:16:12.740 --> 00:16:14.660
Se convierte en una herramienta para cualquier desarrollador

00:16:14.660 --> 00:16:16.740
que quiera experimentar rápidamente sin sacrificar el orden.

00:16:18.060 --> 00:16:19.920
Y cuando esto se vuelve parte de tu flujo diario,

00:16:20.080 --> 00:16:22.620
la especificación deja de sentirse como un paso empresarial formal

00:16:22.620 --> 00:16:24.740
y más como una taquigrafía ligera, ligera.

00:16:25.220 --> 00:16:27.440
Tú describes tu intención, el sistema sienta las bases

00:16:27.440 --> 00:16:29.060
y tú te enfocas en dar forma a los detalles.

00:16:29.640 --> 00:16:32.100
El mayor impacto no proviene solo del código que generas,

00:16:32.200 --> 00:16:34.800
sino de lo que el ahorro de tiempo significa semana tras semana.

00:16:35.440 --> 00:16:37.760
Más horas para funciones, menos trabajo pesado en la configuración.

00:16:38.320 --> 00:16:41.340
Eso nos lleva directamente a la pregunta que más le importa a todo desarrollador.

00:16:41.900 --> 00:16:44.660
¿A qué equivalen realmente estos cambios en términos de productividad?

00:16:45.640 --> 00:16:46.620
La recompensa de la productividad.

00:16:47.300 --> 00:16:49.780
La verdadera pregunta no es si ahorras unos minutos aquí o allá,

00:16:49.880 --> 00:16:54.100
sino cómo esos pequeños cambios se acumulan en horas significativas a lo largo de una semana.

00:16:55.120 --> 00:16:56.220
Esta es la recompensa de la productividad.

00:16:56.760 --> 00:16:59.680
Recuperar tiempo que suele escaparse desapercibido a través del cambio de contexto,

00:16:59.860 --> 00:17:01.840
ciclos de compilación repetidos y parches manuales.

00:17:02.160 --> 00:17:05.460
La mayoría de los desarrolladores aceptan esas pequeñas pérdidas como parte del trauma.

00:17:05.460 --> 00:17:07.820
10 minutos aquí buscando un valor de configuración,

00:17:07.920 --> 00:17:10.040
otros 15 volviendo a ejecutar tras una referencia fallida

00:17:10.040 --> 00:17:11.720
o saltando entre archivos para verificar conexión.

00:17:12.180 --> 00:17:13.520
Por sí solos parecen insignificantes,

00:17:14.100 --> 00:17:18.000
pero sumados a lo largo de un sprint completo determinan cuánto valor real se entrega.

00:17:18.800 --> 00:17:21.860
Lo que parece movimiento rutinario esconde un lastre real en los tiempos de entrega.

00:17:22.420 --> 00:17:24.960
El peso oculto no está en los tiempos de compilación ni en la velocidad de escrito.

00:17:25.460 --> 00:17:27.380
Está en el ritmo de pausas impuesto tu concentración.

00:17:27.380 --> 00:17:30.580
Cada vez que pasas de un archivo a otro, tu cerebro se reinicia.

00:17:31.360 --> 00:17:32.240
Ese reinicia tiene un costo.

00:17:32.620 --> 00:17:35.220
Delegar correcciones repetitivas a un agente aligera esa carga.

00:17:36.040 --> 00:17:38.040
En lugar de reconstruir constantemente el contexto,

00:17:38.360 --> 00:17:41.400
dedicas tu enfoque donde importa resolviendo los problemas de diseño más grandes.

00:17:42.380 --> 00:17:45.440
Muchos equipos no rastrean estos microcostos porque no aparecen en los tickets de Jera

00:17:45.440 --> 00:17:46.240
ni en el historial de Git.

00:17:46.960 --> 00:17:49.720
Trabajo que no lleva a ninguna parte, no se registra, pero aún así consume energía.

00:17:49.720 --> 00:17:53.140
A medida que las bases de código escala en esta fricción no solo se suman de forma lineal,

00:17:53.140 --> 00:17:56.160
más capas significan más dependencias que mantener en memoria

00:17:56.160 --> 00:17:59.760
y más oportunidades de perder tiempo simplemente alineando la estructura antes de seguir avanzando.

00:18:00.360 --> 00:18:03.300
Los flujos de trabajo con agentes cambian la ecuación al atacar directamente estas pérdidas.

00:18:03.700 --> 00:18:05.220
No solo completan los métodos vacíos más rápido,

00:18:05.700 --> 00:18:09.280
reducen los bucles de búsqueda, parches y ejecuciones que se consumen las tardes.

00:18:09.940 --> 00:18:13.780
Los equipos que usan flujos de trabajo con agentes reportan tiempos de desbloqueo más cortos en muchos casos.

00:18:14.060 --> 00:18:17.900
En este video demostraremos una tarea de antes y después para que puedas juzgar el impacto.

00:18:18.600 --> 00:18:21.520
Registraré el tiempo que toma implementar la misma función de Azure manualmente

00:18:21.520 --> 00:18:25.480
y luego con el agente para que puedas ver la ganancia de productividad en términos concretos.

00:18:26.200 --> 00:18:28.760
Desde una perspectiva empresarial, el valor se refleja en la velocidad del proyecto.

00:18:29.340 --> 00:18:31.860
Los ciclos más rápidos no se tratan solo de la satisfacción del desarrollo.

00:18:32.200 --> 00:18:35.200
Determinan si las funciones se lanzan en esta versión o si se postergan varios trimestres.

00:18:35.600 --> 00:18:38.920
Influyen en la deuda técnica ya que menos parches y regresiones se acumulan en el backlog.

00:18:39.920 --> 00:18:44.240
Un flujo más fluido permite a los equipos avanzar con limpieza en lugar de retomar trabajo roto de sprints anteriores.

00:18:45.280 --> 00:18:48.740
Esa consistencia se traduce en menos situaciones de emergencia y una entrega más sólida con el tiempo.

00:18:48.740 --> 00:18:53.000
También existe el factor humano. Un día perdido persiguiendo errores deja a cualquier ingeniero agotado.

00:18:53.760 --> 00:18:57.320
Cuando hay fatiga, el diseño limpio se vuelve difícil, los detalles escapan y surgen errores.

00:18:58.080 --> 00:19:01.900
Al delegar los arreglos mecánicos a un agente, los desarrolladores se mantienen alertas por más tiempo.

00:19:02.720 --> 00:19:05.500
Ese enfoque adicional mejora tanto la productividad como la calidad.

00:19:06.260 --> 00:19:10.800
Cuando no te agotas por la fricción constante, eres libre de pensar de forma amplia y planificar mejor.

00:19:11.280 --> 00:19:12.540
La diferencia en la práctica se ve así.

00:19:12.540 --> 00:19:17.620
Una nueva función de Azure con múltiples enlaces e integraciones podría tomar dos días completos sin ayuda.

00:19:18.720 --> 00:19:23.560
Entre la configuración, las pruebas y corregir referencias incorrectas, la tarea se prolonga.

00:19:24.380 --> 00:19:26.900
Con la ayuda de un agente, la misma función puede estar lista en medio día.

00:19:27.720 --> 00:19:31.940
No porque se tomen atajos, sino porque la configuración entre archivos y la orquestación funcionan bien a la primera.

00:19:31.940 --> 00:19:35.560
El cronograma se reduce al eliminar comienzos falsos y esfuerzos redundantes.

00:19:36.360 --> 00:19:38.160
Algunos desarrolladores expresan una preocupación mágica.

00:19:38.460 --> 00:19:41.200
Confiar en una idea para mantenimiento debilita tus propias habilidades.

00:19:41.660 --> 00:19:43.740
Esa perspectiva suele pasar por alto lo que realmente está cambiando.

00:19:44.580 --> 00:19:49.260
Delegar la configuración repetitiva no debilita tu experiencia, sino que la preserva para el diseño y la arquitectura.

00:19:50.400 --> 00:19:54.920
En realidad, ganas espacio para practicar la resolución de problemas complejos en lugar de malgastar energía en correcciones.

00:19:55.560 --> 00:19:58.540
Si pruebas esto, comenta cuántas horas has recuperado en un sprint.

00:19:58.920 --> 00:20:00.860
Incluiré las respuestas interesantes en futuros videos.

00:20:00.860 --> 00:20:06.700
Saber cómo otros equipos experimentan este cambio da a todos una mejor idea del valor real, más allá de las demos.

00:20:07.500 --> 00:20:10.320
Una nota de precaución, automatización ayuda, pero la seguridad sigue siendo importante.

00:20:10.840 --> 00:20:14.320
Ejecuta siempre tus pruebas y usa la revisión de código para validar los cambios creados por la gente.

00:20:15.020 --> 00:20:18.040
Confía en que el trabajo pesado se reduce, pero mantén las mismas salvaguardas.

00:20:18.620 --> 00:20:21.020
La diferencia de velocidad solo vale la pena si la calidad se mantiene constante.

00:20:21.380 --> 00:20:25.740
Pruebas sólidas y una revisión inteligente de PR protegen tu canal de lanzamiento de una automatización frágil.

00:20:25.920 --> 00:20:28.380
El beneficio no es escribir líneas de código más rápido,

00:20:28.380 --> 00:20:32.780
sino liberar espacio para producir soluciones más sólidas, con menos fatiga y menos.