El Jefe de IA de Microsoft: La Trampa de Dos Personas

Microsoft reorganizó silenciosamente su estructura de IA este año, y el nuevo circuito recorre Core AI, un equipo que fusiona lo que solían ser universos separados: la división de desarrollo y el grupo de infraestructura en la nube. Jay Parikh, quien reporta directamente a Satya Nadella, ahora se encarga de todo, desde Visual Studio y herramientas al estilo de GitHub hasta los clústeres de Azure que entrenan y ejecutan modelos de lenguaje grandes. En lugar de transferir características de un lado a otro entre equipos aislados, Core AI opera como un único grupo de productos con un mandato: construir la infraestructura sobre la que todos los demás se basarán.

Parikh describe esa pila como "evolutiva", pero los contornos ya son claros. En la parte superior se encuentran herramientas nativas de IA que reinventan cómo se escribe, prueba y distribuye el software, con copilotos integrados a lo largo del ciclo de vida del desarrollo en lugar de añadidos a un IDE. Debajo de eso está Foundry, la denominada "fábrica de agentes" de Microsoft, una plataforma donde las empresas diseñan, implementan y supervisan agentes de IA que actúan más como empleados digitales que como aplicaciones estáticas.

Foundry no es solo una capa de alojamiento; es el punto de vista en el medio de la pila. Aquí es donde las empresas conectan agentes a datos internos, los conectan a herramientas y API, y los ven funcionar en producción con una observabilidad que se asemeja más a un centro de operaciones de seguridad que a un panel tradicional. Microsoft quiere que Foundry sea el lugar donde los desarrolladores dejen de luchar con modelos en bruto y comiencen a componer comportamientos de nivel superior.

Todo esto se fundamenta en una capa de seguridad y confianza que asume que la IA es no determinista y potencialmente peligrosa desde el principio. En lugar de auditorías posteriores, Core AI integra controles de políticas, medidas de protección y puntos de cumplimiento en la misma capa donde los agentes obtienen acceso a herramientas y datos. El objetivo es que "seguro por defecto" se aplique a sistemas de razonamiento que planifican, utilizan herramientas y actúan de manera autónoma dentro de los flujos de trabajo más sensibles de una empresa.

Finalmente, Microsoft está diseñando la pila para un despliegue flexible: primero en la nube, pero no solo en la nube. El mismo modelo de programación debe abarcar las regiones de Azure, nubes soberanas reguladas y hardware en el borde en fábricas, tiendas minoristas o dispositivos de campo. Para los creadores, esa abstracción es el punto: un modelo de cómo se comportan los agentes, independientemente de dónde se encuentren físicamente las GPUs, CPUs o datos.

El nuevo grupo de expertos en inteligencia artificial de Microsoft regresará a sus escritorios cinco días a la semana, y no es la nostalgia por 2019 lo que impulsa este cambio. Jay Parikh, vicepresidente ejecutivo de Core AI, argumenta que cuando los modelos, herramientas y protocolos como MCP cambian semanalmente, un equipo distribuido pierde demasiado tiempo debido a bucles de retroalimentación lentos y oportunidades perdidas de serendipia.

La propuesta de Parikh es simple: la IA avanza en una curva exponencial, y los humanos necesitan un bucle de aprendizaje igualmente rápido para mantenerse al día. Él dice que la única forma de lograr eso a gran escala es a través de una colaboración densa y presencial donde el coaching, la depuración y la experimentación ocurren de manera continua, no en bloques programados de una hora en Teams.

Dentro de los pisos de IA de Microsoft, un comentario casual puede ser tan valioso como una capacitación formal. Un ingeniero podría mencionar un nuevo patrón de Copilot que redujo el tiempo de ejecución de una suite de pruebas de horas a minutos, o un truco para encadenar herramientas a través de un agente que reduce a la mitad el tiempo de resolución de tickets de soporte, y de repente todo el equipo mejora.

Esas micro-lecciones rara vez se transmiten por Slack o correo electrónico con la misma fidelidad. En un pasillo, alguien puede tomar una laptop, reproducir el aviso, ajustar la estructura y ver cómo cambian los resultados en tiempo real, mientras otras tres personas contribuyen en ventanas de contexto, datos fundamentados o barreras de seguridad.

Parikh lo plantea como la construcción de un "laboratorio en vivo" donde el descubrimiento es social y continuo. En lugar de que los individuos experimenten en silencio con Copilot de forma aislada, los equipos se agrupan para abordar problemas difíciles: cómo lograr que un agente opere de manera segura con datos de producción, cómo reducir las alucinaciones en un flujo de trabajo financiero, cómo diseñar indicaciones que puedan mantener personas que no son ingenieros.

La parte contraintuitiva es que dominar una herramienta digital primero depende en gran medida de la presencia física. La opinión de Parikh: cuanto más capaz sea la IA, más importante se vuelve el intercambio de patrones entre humanos, porque la superficie de flujos de trabajo posibles se amplía y ningún conjunto de documentación puede mantenerse al día.

El trabajo remoto aún tiene sentido para sistemas estables y bien entendidos. Pero para la vanguardia en inteligencia artificial de Microsoft—donde los modelos, SDKs y objetivos de implementación cambian de la nube a dispositivos perimetrales en meses—Parikh está apostando que la proximidad, no el ancho de banda, es el verdadero multiplicador de productividad.

La cultura, no la computación, domina la agenda de Jay Parikh. Él dice que aproximadamente el 90 por ciento de sus conversaciones con ejecutivos de Fortune 500 no tienen nada que ver con el tamaño de los modelos, la cantidad de GPU o la superficie de los centros de datos, y todo que ver con si sus organizaciones están dispuestas a cambiar cómo se realiza el trabajo día a día.

Microsoft está tratando de actuar como un conejillo de Indias para ese cambio. Dentro de Core AI, Parikh señala un programa llamado Thrive Inside, que rastrea cómo los empleados pasan su tiempo y luego aborda el estancamiento de "gestionar el negocio": informes de estado, coordinación, documentación manual—con agentes al estilo de Copilot que resumen, redactan y envían el trabajo automáticamente.

El objetivo suena simple y brutal: recuperar horas y redistribuirlas al producto. En lugar de que los ingenieros y gerentes de producto pierdan tiempo en la sobrecarga operativa, Thrive Inside busca dedicar más tiempo a diseñar nuevas características, realizar experimentos y hablar con los clientes, precisamente el tipo de trabajo que la IA aún no puede hacer por ellos.

Esa reorientación cambia la forma en que los equipos desarrollan software. En lugar de crear manualmente un solo prototipo y esperar semanas para recibir comentarios, Parikh quiere que los equipos generen cinco variaciones generadas por IA a la vez, las envíen a usuarios internos o externos y observen qué es lo que realmente funciona.

El prototipado rápido y paralelo solo funciona si la dirección acepta un proceso más desordenado. Significa más ideas a medio cocinar frente a los usuarios, más experimentos que se eliminan rápidamente y hojas de ruta de productos que se ajustan según lo que dicen los datos en lugar de lo que decidió un comité directivo el trimestre pasado.

Parikh argumenta que ahí es donde la mayoría de las empresas se estancan. Las aprobaciones de presupuesto llegan, los proveedores se alinean, hay talento disponible, pero la empresa se niega a reescribir los flujos de trabajo, las cadenas de aprobación y las estructuras de incentivos alrededor de las formas de trabajo nativas de la IA.

Entonces, la verdadera ventaja competitiva no es el acceso a modelos o asociaciones como las de OpenAI. Se trata de si una empresa rediseñará su sistema operativo para coincidir con la pila de IA verticalmente integrada que Microsoft está promoviendo en Core AI y en Introducing CoreAI – Platform and Tools - The Official Microsoft Blog.

Los títulos de trabajo como "gerente de producto" e "ingeniero front-end" empiezan a verse inseguros cuando un prompt puede cruzar esas fronteras en segundos. El grupo de IA Central de Microsoft habla de "creadores" en lugar de desarrolladores por una razón: el trabajo ahora abarca un continuo desde la idea hasta el despliegue, y la IA llena los vacíos entre roles tradicionales. Las salvaguardas siguen siendo importantes, pero los muros entre disciplinas se están desmoronando.

Un gerente de producto que antes vivía en Jira y PowerPoint ahora puede solucionar un error de bajo riesgo pegando un rastreo de pila en GitHub Copilot o un modelo local y pidiendo un parche. Puede generar pruebas unitarias, ejecutar la pipeline y lanzar una corrección urgente sin esperar a que un ingeniero esté libre. Esto no reemplaza a los especialistas, pero cambia radicalmente quién puede tocar el código de producción.

Por otro lado, los ingenieros de sistemas y los SRE que nunca abrieron Figma ahora esbozan flujos de interfaz de usuario con un aviso. Describen un panel para la utilización de GPU en centros de datos, y Copilot en Visual Studio Code genera componentes de React, Tailwind CSS e incluso gráficos de telemetría de ejemplo. Un diseñador puede refinarlos más tarde, pero el primer prototipo interactivo existe en horas, no en semanas.

El trabajo deja de parecer una carrera de relevos entre silos y comienza a parecer un lienzo compartido. Una persona puede: - Redactar texto de UX - Generar stubs de API - Conectar el registro - Lanzar un experimento detrás de una bandera de función

Todo con la misma cadena de herramientas impulsada por IA, mientras seguimos incorporando expertos para escalar, garantizar la seguridad y pulir.

La propia visión de "fábrica de agentes" de Microsoft incorpora esto en la arquitectura: la misma plataforma Foundry soporta la creación, implementación y observación de agentes en la nube y en el borde. Este pipeline unificado fomenta que equipos multifuncionales trabajen juntos, iterando indicaciones, ajustando el código de soporte y llevando a producción en ciclos rápidos. Menos transferencias significan menos requisitos perdidos y una retroalimentación más rápida.

La convergencia también desbloquea ideas más extrañas y ambiciosas. Un ingeniero de seguridad puede prototipar un bot de incidentes autocomponible. Un analista financiero puede construir un microservicio de pronóstico. Cuando todos pueden construir, desplegar y operar, los títulos de trabajo importan menos que quién tiene la pregunta más interesante y quién puede poner en funcionamiento a un agente para responderla.

Jay Parikh dice que la mayoría de las personas que conoce se dividen en dos grupos sobre la IA. Grupo 1 se aleja de una respuesta decente de Copilot diciendo: “Wow, eso es magia.” Grupo 2 se aleja de la misma respuesta murmurando: “¿Por qué no hizo también X, Y y Z?” y de inmediato comienza a experimentar.

El Grupo 1 utiliza la IA como un gadget novedoso. Copian un correo electrónico corto, piden un resumen, tal vez generan una diapositiva una vez a la semana y se detienen tan pronto como reciben la primera respuesta extraña o alucinación. Su curva de habilidad es prácticamente plana porque sus expectativas se mantienen bajas y su uso es superficial.

El Grupo 2 trata la IA como un sistema operativo para su jornada laboral. Encadenan indicaciones, integran datos de la empresa y empujan a los agentes a manejar proyectos de varios pasos: redactar contratos, refactorizar código heredado, construir informes de clientes a partir de archivos CSV en bruto. Viven en los mensajes de error, aprenden de los fracasos y continúan aumentando la dificultad a medida que los modelos mejoran mes a mes.

Los propios equipos de Parikh dentro de Microsoft se sitúan claramente en ese segundo grupo. Los ingenieros de IA central se reúnen en persona para descubrir cómo hacer que Copilot escriba arneses de prueba, genere paneles de telemetría o razone sobre registros extensos. Prueban algo, observan cómo falla, cambian los comandos y las herramientas, y lo intentan de nuevo, porque así es como se mantiene en lo que Parikh llama la trayectoria exponencial de esta tecnología.

Tiempo de autoevaluación: en la última semana, ¿cuántas horas pasaste realmente dentro de una herramienta de IA? Si tu respuesta es "unos pocos comandos, tal vez 10 minutos en total", estás en el Grupo 1. Si mides el uso en horas por día y puedes nombrar al menos 3 flujos de trabajo específicos que has reconstruido alrededor de la IA, te estás inclinando hacia el Grupo 2.

Pregúntate algunas preguntas más difíciles: - ¿Mantienes un documento en curso de indicaciones y trucos que funcionaron? - ¿Has conectado la IA a tu calendario, repositorio de código, CRM o almacén de datos? - ¿Romper algo en el trabajo porque confiabas demasiado en un modelo y luego ajustaste tu proceso?

El Grupo 1 experimentará aumentos en la productividad marginal a medida que la IA mejore por defecto. El Grupo 2 reemplazará silenciosamente las descripciones de trabajo. Cuando Parikh dice que los roles tradicionales están difuminándose, se refiere a personas que utilizan la IA para realizar tres trabajos a la vez: ingeniero, analista y pensador de productos fusionados en un único "constructor".

Las carreras ahora dependen de qué curva elijas. Estar asombrado es opcional. Estar frustrado—y aprendiendo rápido—es obligatorio.

Los usuarios del Grupo 2 tratan a la IA como un nuevo lenguaje de programación en el que se niegan a ser mediocres. Realizan pruebas paralelas entre GPT-4o, Claude, Gemini y modelos de código abierto, intercambian prompts como fragmentos de código y mantienen criterios mentales sobre cuál sistema maneja mejor el razonamiento de largo contexto o la salida estructurada. No confían en la publicidad de los proveedores; confían en sus propios experimentos.

Los hábitos parecen casi obsesivos. Registran indicaciones, rastrean fallos y iteran hasta que un flujo de trabajo es lo suficientemente fiable como para ejecutarse a diario. Cuando un modelo presenta alucinaciones, no se encogen de hombros y siguen adelante; rediseñan la indicación, añaden herramientas o cambian el modelo, y luego documentan qué lo solucionó.

Detrás de escena, están aprendiendo silenciosamente ingeniería de contexto. Piensan en tokens y recuperación, no en sensaciones: qué entra en el aviso del sistema, qué se queda en la entrada del usuario, qué se mueve hacia un almacén de vectores. Diseñan esquemas, dividen documentos y prueban cómo diferentes ventanas de contexto y temperaturas afectan la latencia y el costo.

También comienzan a hablar el lenguaje de las métricas de evaluación. En lugar de “esto se siente mejor”, rastrean: - Tasas de éxito en tareas a través de 20–50 casos de prueba - Latencia y costo en dólares por tarea - Tipos de errores: alucinación, formato, seguridad, mal uso de herramientas Construyen pequeños arneses de evaluación en Python o utilizan herramientas de evaluación listas para usar para evitar enviar agentes basados en sensaciones a producción.

A partir de ahí, muchos se adentran en el ajuste fino y el aprendizaje por refuerzo. Realizan pequeños ajustes específicos de dominio en tickets de soporte o bases de código, y luego los comparan con un simple aviso. Juegan con el aprendizaje por refuerzo a partir de la retroalimentación humana en agentes internos, recompensando comportamientos como la disciplina en el uso de herramientas o la adherencia a la política de la empresa.

La frustración es su estado predeterminado—y su mejor señal. Cuando sigues chocando con los límites de lo que Copilot o ChatGPT pueden hacer, significa que tus ambiciones han superado el “autocompletado para el trabajo” y se han trasladado al diseño de sistemas. Chocar con esos muros te obliga a aprender cómo se comportan realmente los modelos.

El cambio del Grupo 1 al Grupo 2 comienza con la intención. Reserva de 30 a 60 minutos al día para: - Realizar pruebas A/B entre modelos - Crear un aviso o agente reutilizable por semana - Anotar los fracasos y lo que cambiaste Recursos como Jay Parikh - Microsoft Build muestran hacia dónde se dirige esta mentalidad a gran escala; tu trabajo es recrear ese ciclo de experimentación en miniatura.

Copilot era solo el nivel tutorial. El grupo de IA Fundamental de Jay Parikh ya está jugando en otro juego: orquestando enjambres de agentes que se comunican entre sí más que contigo. En lugar de pedirle a un modelo que "escriba código", los equipos avanzados conectan planificadores, programadores, testers y revisores en una pequeña empresa de software que funciona con silicio.

Dentro de Microsoft, algunos de los grupos más avanzados ahora evitan tocar una sola línea de código fuente. Los ingenieros describen flujos de trabajo donde definen especificaciones de alto nivel, restricciones e interfaces, y luego entregan ese plano a un conjunto de agentes que operan en la plataforma interna de "fábrica de agentes" Foundry de Microsoft. La atención humana se desplaza a un nivel superior, hacia dar forma al comportamiento y establecer límites, no hacia la microgestión de la sintaxis.

Una pieza crítica de este conjunto es el agente de verificación. En lugar de enviar el código generado por IA a una cola de revisión humana, los agentes de verificación ejecutan automáticamente pruebas, análisis estático y comprobaciones de políticas, y luego retroalimentan comentarios estructurados a los agentes de codificación. El ciclo es el siguiente: generar → verificar → regenerar, repitiéndose múltiples veces antes de que un humano vea una diferencia.

Ese feedback no se limita a "pruebas fallidas". Los agentes de verificación pueden señalar casos límite faltantes, regresiones de rendimiento, violaciones de políticas de seguridad o rupturas en el contrato de la API. Luego, los agentes de codificación utilizan ese feedback de la máquina como contexto, actualizando sus propios prompts y estrategias para resolver problemas de manera autónoma. Los humanos intervienen cuando el ciclo se detiene, no cuando aparece cada error trivial.

Los equipos de Parikh están gestionando de manera efectiva fábricas de software donde los agentes son los dueños de la línea de ensamblaje. Un agente podría encargarse de la expansión de requisitos, otro estructura servicios, un tercero se ocupa de la observabilidad, mientras que otros se especializan en documentación y manifiestos de implementación. Cada agente expone herramientas y APIs a sus compañeros, convirtiendo un repositorio en un sistema multiagente vivo en lugar de un montón estático de archivos.

Tu papel en ese mundo se asemeja mucho menos al de “desarrollador” y mucho más al de “gerente de fábrica”. Decides qué agentes activar, qué capacidades otorgarles, cuán restringido debe estar su acceso a los datos y qué controles de verificación implementar. La verdadera influencia pasa a manos de quienes pueden diseñar, programar y gobernar estos ejércitos de agentes, ya que el trabajo de teclado se está convirtiendo rápidamente en la parte menos importante.

Los agentes de inteligencia artificial no deterministas no solo se comportan mal; crean una superficie de ataque completamente nueva. Las aplicaciones tradicionales siguen caminos de código fijos, pero los agentes pueden planificar, explorar herramientas e improvisar su camino hacia problemas, incluso cuando nadie codificó explícitamente el mal comportamiento. Esa imprevisibilidad quiebra décadas de suposiciones de seguridad construidas alrededor de flujos de trabajo repetibles y auditables.

La seguridad empresarial convencional se basa en listas de verificación estáticas: niveles de parches, controles de acceso basados en roles, atestaciones de cumplimiento. Los sistemas agentes superan ese modelo porque un único agente puede, en tiempo real, encadenar APIs, recorrer bases de conocimiento y sintetizar acciones a través de entornos SaaS, locales y de borde. Ya no solo estás asegurando puntos finales; estás asegurando comportamientos emergentes.

La seguridad para los agentes se parece más al control de tráfico aéreo continuo que a una prueba de penetración única. Las empresas necesitarán: - Permisos detallados y revocables para herramientas y datos - Motores de políticas que evalúen cada paso en el plan de un agente - "Interruptores automáticos" en tiempo de ejecución que detengan cadenas de acción sospechosas Todo eso deberá ser observable, registrado y explicable a los auditores que preguntarán por qué una IA hizo lo que hizo a las 3:17 a.m.

Parikh regresa a un punto: la seguridad y la confianza no se pueden añadir más tarde. Si un agente puede conectarse de forma autónoma a un CRM, ERP y repositorio de código, cualquier mala configuración se convierte en un problema de radio de explosión, no en un problema de un solo error. Las protecciones, la gobernanza y los equipos de ataque simulado deben estar presentes en cada capa de la pila de IA, desde la selección de modelos y la estructuración de indicaciones hasta el despliegue y la supervisión.

La plataforma Foundry de Microsoft—su llamada "fábrica de agentes"—es donde esos principios se convierten en herramientas para las empresas. Foundry tiene como objetivo hacer cumplir una orquestación consciente de políticas, negar por defecto el acceso a herramientas y datos, y ofrecer una profunda observabilidad a través de miles de agentes que operan en Azure, en las instalaciones o en el borde. La propuesta es simple pero agresiva: si vas a desatar ejércitos de agentes, la función de Foundry es evitar que un solo agente deshonesto o comprometido se convierta en un SolarWinds interno.

Fairwater, el último campus de centros de datos de IA de Microsoft, es una aceptación silenciosa de que el auge de la IA ahora es tanto un problema de infraestructura como un problema de modelo. Entrenar y ejecutar Copilot, modelos de clase GPT-4 y flotas de agentes ya no depende únicamente de arquitecturas ingeniosas; depende del concreto, el acero y los megavatios. Microsoft está gastando decenas de miles de millones de dólares al año en nuevos centros de datos, redes personalizadas y refrigeración líquida solo para mantenerse al día con la demanda.

La conversación sobre los “GPUs oscuros” — aceleradores de alta gama supuestamente inactivos — choca con lo que Jay Parikh describe en el terreno. La capacidad existe, pero está fragmentada entre regiones, SKU y topologías de red, y a menudo está reservada con meses de anticipación para entrenamientos a gran escala. Los verdaderos cuellos de botella se encuentran en la entrega de energía, los envolventes de enfriamiento y en conseguir interconexiones de alto ancho de banda y baja latencia a los racks adecuados, no en paletas de H100s sin usar acumulando polvo.

La energía ahora se presenta como el límite inquebrantable. Los centros de datos de IA ya consumen decenas de teravatios-hora anualmente, y las proyecciones de la industria de utilidades y reguladores indican un crecimiento de dos dígitos porcentuales en la carga de los centros de datos durante la próxima década. Los operadores de la red en EE. UU. y Europa están advirtiendo que los grandes campus de IA pueden requerir entre 1 y 5 GW cada uno, equivalente a una ciudad de tamaño medio, lo que obliga a actualizaciones a largo plazo en la transmisión y generación.

La respuesta de Microsoft no es solo "construir más centros de datos", sino "mover más inteligencia al borde". El equipo de Parikh está diseñando un modelo de programación donde las aplicaciones agenciales pueden operar en cuatro planos: nube, centros de datos regionales, infraestructura local y dispositivos en el borde. Esta distribución reduce los viajes de ida y vuelta a la nube, recorta el ancho de banda y desplaza parte del procesamiento lejos de las instalaciones con mayor restricción de energía.

Los agentes orientados a la periferia también crean una historia de eficiencia diferente. Si un agente en el suelo de la fábrica puede razonar localmente en una puerta de enlace equipada con GPU, la nube solo ve un estado resumido, no flujos de datos de sensores crudos. La visión más amplia de Microsoft sobre la "fábrica de agentes", detallada en From Software Factory to Agent Factory: How Microsoft Is Reimagining Development, depende de este continuo: un entrenamiento intenso en centros de datos de hiperescalabilidad, orquestación en la nube y una inferencia rápida y consciente del consumo energético en el extremo.

Deja de tratar a ChatGPT o Copilot como si fueran un truco de magia. Trátalos como si fueran pasantes con bajo rendimiento a los que estás decidido a convertir en operadores a nivel de personal. Si todavía estás "asombrado" de que un LLM puede escribir un correo electrónico, eleva el nivel: exige código funcional, análisis de múltiples pasos y borradores de proyectos de principio a fin, y luego presiona nuevamente cuando fallen.

Comienza cada semana eligiendo una tarea dolorosa y preguntando: "¿Qué haría Grupo 2 con IA aquí?" Lleva el modelo a través de tres o cuatro iteraciones, cambia de modelos (GPT-4, Claude, Gemini) y conecta herramientas reales: tu IDE, calendario, CRM o almacén de datos. Mídete por los resultados: horas ahorradas, errores corregidos, experimentos realizados.

El aprendizaje interdisciplinario se convierte ahora en una habilidad de supervivencia. Si eres ingeniero, utiliza GitHub Copilot o GPT-4 para crear un prototipo de experiencia de usuario en Figma y redactar el informe de lanzamiento. Si eres gerente de producto, haz que la IA te guíe a través de la depuración de una prueba fallida, genera un parche y abre una solicitud de extracción. Los diseñadores pueden usar modelos para crear consultas SQL, tableros de telemetría básicos o incluso modelos de amenaza.

Piensa en sistemas, no en indicaciones. Toma un proyecto complicado—digamos, lanzar una nueva herramienta interna—y divídelo en agentes: - Agente de investigación: mercado, competidores, entrevistas a usuarios - Agente arquitecto: requisitos, diagramas, compensaciones - Agente de ejecución: código, pruebas, scripts de despliegue - Agente de equipo rojo: seguridad, abusos, modos de fallo

Luego, redactar cómo entregan el trabajo, se revisan entre ellos y te escalan a ti.

Dentro de tu empresa, conviértete en la persona que habla sobre la cultura, no solo sobre herramientas. Realiza breves "ejercicios de IA" en las reuniones de equipo, comparte logros y fracasos concretos en una publicación semanal, y presiona a los líderes para que recompensen los experimentos, incluso aquellos que no salen bien. Si el grupo central de IA de Microsoft necesita colaboración en persona para mantenerse al día, tu equipo probablemente necesite al menos un manual de IA que esté vivo y en funcionamiento.

¿Cuál es el nuevo equipo de IA Core de Microsoft?

Es una nueva división combinada liderada por el EVP Jay Parikh, que integra herramientas para desarrolladores, infraestructura básica y plataformas de IA para crear un 'stack' unificado para construir, desplegar y asegurar agentes y aplicaciones de IA.

¿Por qué el equipo de Jay Parikh vuelve a la oficina a tiempo completo?

Parikh cree que el rápido y exponencial ritmo del desarrollo de la IA requiere colaboración en persona, capacitación y aprendizaje. Argumenta que los equipos aprenden y se adaptan más rápido juntos, lo cual es crítico para mantenerse a la vanguardia de la innovación en IA.

¿Cómo está cambiando la inteligencia artificial el papel de un desarrollador de software?

La inteligencia artificial está difuminando las líneas entre roles como la ingeniería, el producto y el diseño. Empodera a las personas para realizar tareas fuera de su dominio tradicional, cambiando el enfoque de escribir código a orquestar agentes de IA, crear contexto y validar resultados.

¿Cuáles son los dos tipos de usuarios de IA que describe Jay Parikh?

El Grupo 1 se asombra fácilmente por la IA y la utiliza con poca frecuencia, manteniendo bajas expectativas. El Grupo 2 utiliza la IA constantemente para tareas complejas, a menudo se frustra por sus limitaciones y está empujando activamente sus fronteras, aprovechando así la curva de aprendizaje exponencial.