Técnicas

Cumplimiento continuo es la práctica de garantizar que los procesos y tecnologías de desarrollo de software cumplan de manera constante con los estándares regulatorios y de seguridad mediante la automatización. Las verificaciones manuales de cumplimiento pueden ralentizar el desarrollo e introducir errores humanos, mientras que las auditorías y verificaciones automatizadas ofrecen retroalimentación más rápida, evidencia más clara y reportes simplificados. Al integrar herramientas de política como código, como Open Policy Agent, y generar SBOMs dentro de los pipelines de CD alineados con las guías de SLSA los equipos pueden detectar y resolver problemas de cumplimiento de manera temprana. La codificación de reglas y buenas prácticas permite aplicar los estándares de forma consistente entre equipos sin generar cuellos de botella. OSCAL también muestra un gran potencial como marco para automatizar el cumplimiento a gran escala. Las prácticas y herramientas para el cumplimiento continuo ya han madurado lo suficiente como para considerarse el estándar recomendado, por lo que hemos movido nuestra recomendación a Adoptar. El uso creciente de la IA en la programación y el riesgo asociado de complacencia con el código generado por IA hacen que incorporar el cumplimiento dentro del proceso de desarrollo sea más importante que nunca.

Para los equipos que utilizan activamente la IA en la entrega de software, el siguiente paso es ir más allá del prompting individual y avanzar hacia prompts compartidos seleccionados para equipos de software. Esta práctica ayuda a aplicar la IA de manera efectiva en todas las tareas de entrega (no solo en la codificación) mediante el uso compartido de prompts comprobados y de alta calidad. La forma más sencilla de implementarla es incorporando archivos de instrucciones, como AGENTS.md, directamente en el repositorio del proyecto. La mayoría de las herramientas de codificación con IA, incluidas Cursor, Windsurf y Claude Code, permiten compartir prompts a través de comandos personalizados barra (/) o flujos de trabajo. Para las tareas que no implican código, pueden configurarse bibliotecas de prompts a nivel organizacional listas para usar. Este enfoque sistemático permite la mejora continua: en cuanto un prompt se perfecciona, todo el equipo se beneficia, garantizando acceso constante a los mejores prompts para interactuar con la IA.

Los Git hooks existen desde hace mucho tiempo, pero consideramos que siguen siendo poco utilizados. El auge de la programación asistida por IA y agéntica ha incrementado el riesgo de hacer commit accidentalmente de secretos o de código problemático. Si bien existen muchos mecanismos de validación de código, como la integración continua, los hooks de pre-commit son una medida de protección simple y efectiva que más equipos deberían adoptar. Sin embargo, sobrecargar los hooks con verificaciones lentas puede desincentivar su uso, por lo que es mejor mantenerlos mínimos y enfocados en los riesgos que pueden detectarse de manera más eficaz en esta etapa del flujo de trabajo, como el escaneo de secretos.

En los últimos meses, hemos visto evidencia clara de que usar GenAI para comprender bases de código heredadas puede acelerar significativamente el entendimiento de sistemas grandes y complejos. Herramientas como Cursor, Claude Code, Copilot, Windsurf, Aider, Cody, Swimm, Unblocked y PocketFlow-Tutorial-Codebase-Knowledge ayudan a los desarrolladores a identificar reglas de negocio, resumir lógica e identificar dependencias. Usadas junto con frameworks abiertos y prompting directo a LLMs, reducen drásticamente el tiempo necesario para entender bases de código heredadas. Nuestra experiencia con múltiples clientes muestra que la comprensión asistida por GenAI de sistemas heredados es ahora una práctica estándar, más que un experimento. El esfuerzo de configuración varía, especialmente en enfoques avanzados como GraphRAG, y tiende a escalar con el tamaño y la complejidad de la base de código analizada. Aun así, el impacto en la productividad es constante y considerable. GenAI se ha convertido en una parte esencial de cómo exploramos y comprendemos sistemas heredados.

AGENTS.md es un formato común para proporcionar prompts a agentes de IA dedicados al desarrollo de software dentro de un proyecto. En esencia, funciona como un archivo README para agentes y no requiere campos ni formatos específicos más allá del uso de Markdown, confiando en la capacidad de los agentes de codificación basados en LLM para interpretar instrucciones escritas y legibles por humanos. Los usos típicos incluyen consejos sobre el uso de herramientas en el entorno de desarrollo, prompts de prueba y prácticas recomendadas para la gestión de commits. Aunque las herramientas de IA admiten varios métodos de ingeniería de contexto, el valor de AGENTS.md radica en establecer una convención sencilla para un archivo que sirva como punto de partida.

IA para migraciones de código abarca diversas formas de migración de código, desde reescrituras de lenguaje hasta actualizaciones de dependencias o frameworks— y rara vez son triviales, ya que suelen requerir meses de esfuerzo manual. Uno de nuestros equipos, al actualizar su versión de .NET framework, experimentó con el uso de IA para acortar el proceso. En el pasado, mencionamos OpenRewrite, una herramienta de refactorización determinista basada en reglas. El uso exclusivo de la IA para este tipo de actualizaciones ha demostrado ser, con frecuencia, costoso y propenso a generar conversaciones dispersas. En su lugar, el equipo combinó pipelines de actualización tradicionales con asistentes de codificación basados en agentes para gestionar transiciones complejas. En lugar de delegar toda la actualización, dividieron el proceso en pasos más pequeños y verificables: analizar errores de compilación, generar diferencias de migración y validar pruebas de forma iterativa. Este enfoque híbrido posiciona a los agentes de codificación con IA como colaboradores pragmáticos en el mantenimiento de software. Ejemplos en la industria, como la migración a gran escala de Google de int32 a int64, reflejan una tendencia similar. Aunque nuestros resultados son mixtos en cuanto al ahorro de tiempo medible, el potencial de IA para migraciones de código para reducir el trabajo repetitivo de las personas desarrolladoras es claro y merece seguir siendo explorado.

Liquid clustering es una técnica para tablas de Delta Lake que actúa como una alternativa al particionamiento y al Z-ordering. Tradicionalmente, optimizar las tablas Delta para mejorar el rendimiento de lectura requería definir las claves de partición y Z-order al momento de crear la tabla, basándose en los patrones de consulta previstos. Modificar estas claves más adelante implicaba reescribir por completo los datos. En cambio, clustering utiliza un algoritmo basado en árboles para agrupar los datos según las claves designadas, las cuales pueden modificarse de forma incremental sin necesidad de reescribir toda la información. Esto ofrece mayor flexibilidad para admitir diversos patrones de consulta, reduciendo los costos de cómputo y mejorando el rendimiento de lectura. Además, el Databricks Runtime para Delta Lake admite el liquid clustering automático, que analiza los historiales de consultas, identifica las columnas óptimas y agrupa los datos en consecuencia. Tanto los usuarios de Delta Lake independiente como los del entorno Databricks Runtime pueden aprovechar esta técnica para optimizar el rendimiento de lectura.

Usamos la expresión autoservicio de prototipado UI con GenAI para describir una técnica emergente en la que herramientas como Claude Code, Figma Make, Miro AI y v0 permiten a las personas product managers generar prototipos interactivos y aptos para pruebas de usuario directamente a partir de indicaciones en texto. En lugar de crear manualmente los wireframes, los equipos pueden generar artefactos funcionales en HTML, CSS y JS en cuestión de minutos, ofreciendo la velocidad de un boceto pero con interactividad real y mayor fidelidad. Estos prototipos “desechables” sacrifican el detalle acabado por un aprendizaje rápido, lo que los hace ideales para la validación temprana durante los design sprints. Sin embargo, una mayor fidelidad puede generar un enfoque indebido en detalles menores o expectativas poco realistas sobre el esfuerzo de producción, por lo que es fundamental establecer un marco y expectativas claras. Usada junto con la investigación de usuarios, esta técnica acelera la fase de descubrimiento al convertir ideas abstractas en experiencias tangibles que las personas usuarias pueden evaluar. No obstante, los equipos deben procurar que estas herramientas no sustituyan el proceso de investigación en sí. Bien aplicada, el autoservicio de prototipado acorta los ciclos de retroalimentación, reduce las barreras para quienes no son diseñadores y ayuda a los equipos a iterar con rapidez manteniendo un equilibrio saludable entre velocidad y calidad.

La salida estructurada de LLMs es la práctica de restringir a un modelo de lenguaje grande para que genere respuestas en un formato predefinido, como JSON o una clase de programación específica. Esta técnica es esencial para crear aplicaciones confiables y listas para producción, transformando el texto típicamente impredecible del LLM en un contrato de datos determinista y legible por máquina. Basados en un uso exitoso en producción, movemos esta técnica de Assess a Trial. Los enfoques van desde un simple formateo basado en prompts y model-native structured outputs, hasta métodos de decodificación restringida más robustos mediante herramientas como Outlines e Instructor, que aplican máquinas de estados finitos para garantizar salidas válidas. Hemos utilizado con éxito esta técnica para extraer datos complejos y no estructurados de diversos tipos de documentos y convertirlos en JSON estructurado para su uso en la lógica de negocio posterior.

Test && commit || revert (TCR) es un flujo de trabajo de programación derivado del desarrollo guiado por pruebas (TDD) que promueve pasos muy pequeños y continuos mediante una regla simple: después de cada cambio, si las pruebas pasan, se hace commit de los cambios; si fallan, los cambios se revierten. Implementar TCR es sencillo: solo se necesita definir un script que automatice este ciclo dentro de la base del código. Originalmente introducido en un artículo canónico de Kent Beck, hemos comprobado que TCR refuerza buenas prácticas de codificación como YAGNI y KISS. Vale la pena evaluarlo mientras experimentamos con nuevos flujos de trabajo para construir software con GenAI.

En el Radar anterior, las pruebas de IU impulsadas por IA (AI-powered UI testing) se centraban principalmente en las pruebas exploratorias donde señalamos que el carácter no determinista de los LLM podía introducir inestabilidad. Con el auge de MCP ahora vemos que los principales frameworks para pruebas de interfaz de usuario como Playwright y Selenium han incorporado sus propios servidores MCP (playwright-mcp, mcp-selenium). Estos permiten una automatización de navegador más confiable mediante sus tecnologías nativas lo que facilita que los asistentes de codificación generen pruebas de interfaz de usuario estables en Playwright o Selenium. Aunque las pruebas de interfaz de usuario con IA siguen siendo un campo en rápida evolución (la versión más reciente de Playwright, por ejemplo, introdujo Playwright Agents), nos entusiasman estos avances y esperamos ver más orientación práctica y experiencias de campo en el futuro cercano.

En el pasado, mencionamos el patrón de plantillas de servicio a la medida, que ayudó a las organizaciones que adoptan microservicios al proporcionar configuraciones predeterminadas razonables para crear nuevos servicios e integrarlos sin problemas con la infraestructura existente. Con el tiempo, sin embargo, la divergencia de código entre estas plantillas y los servicios existentes tiende a aumentar a medida que surgen nuevas dependencias, frameworks y patrones arquitectónicos. Para mantener buenas prácticas y coherencia arquitectónica, especialmente en la era de los agentes de codificación hemos estado experimentando con anclar los agentes de codificación a una aplicación de referencia. Este patrón guía a los agentes de código generativo al proporcionar una aplicación de referencia viva y compilable en lugar de ejemplos estáticos en los prompts. Un servidor Model Context Protocol (MCP) expone tanto el código de la plantilla de referencia como los diffs de commits, lo que permite a los agentes detectar divergencias y proponer correcciones. Este enfoque transforma las plantillas estáticas en planos vivos y adaptables que la IA puede consultar de forma inteligente, manteniendo la coherencia, reduciendo la divergencia y mejorando el control sobre el scaffolding impulsado por IA a medida que los sistemas evolucionan.

Ingeniería de contexto es el diseño y la optimización sistemática de la información proporcionada a un modelo de lenguaje grande (LLM, por sus siglas en inglés) durante la inferencia, con el fin de producir de manera confiable el resultado deseado. Implica estructurar, seleccionar y secuenciar los elementos contextuales como prompts, datos recuperados, memoria, prompts y señales del entorno para que las capas internas del modelo operen en un estado óptimo. A diferencia de la ingeniería de prompts, que se enfoca únicamente en la redacción de los mismos, la ingeniería de contexto considera toda la configuración del contexto: cómo se organiza y entrega el conocimiento relevante, los prompts y el contexto previo para lograr los resultados más efectivos. Actualmente, se utilizan una variedad de técnicas que pueden agruparse en tres áreas: configuración del contexto que abarca tácticas de curación como el uso de prompts del sistema mínimos, ejemplos few-shot canónicos y herramientas eficientes en tokens para acciones decisivas; gestión del contexto para tareas de largo horizonte con ventanas de contexto finitas mediante resumen de contexto, toma de notas estructurada para mantener memorias externas y arquitecturas de subagentes que aíslan y resumen subtareas complejas, y recuperación dinámica de información que depende de la recuperación de contexto justo a tiempo (JIT), donde los agentes cargan datos externos de forma autónoma sólo cuando son inmediatamente relevantes, maximizando la eficiencia y la precisión.

GenAI para ingeniería progresiva es una técnica emergente para modernizar sistemas heredados mediante descripciones generadas por inteligencia artificial sobre bases de código existentes. Introduce una etapa explícita centrada en qué hace el código heredado (su especificación), ocultando deliberadamente cómo está implementado actualmente. Está relacionada con el spec-driven development, aunque se aplica específicamente a la modernización de sistemas heredados. Al generar e iterar sobre descripciones funcionales antes de reescribir el código, los equipos pueden usar GenAI para revelar lógica oculta, dependencias y casos límite que de otro modo podrían pasarse por alto. Enfocarse en el espacio del problema en lugar del sistema existente también permite que los modelos de GenAI exploren soluciones más creativas y orientadas al futuro. El flujo de trabajo sigue un ciclo de ingeniería inversa → diseño/solución → ingeniería progresiva, lo que permite que tanto las personas como los agentes de IA razonen a un nivel más alto antes de comprometerse con una implementación. En Thoughtworks, estamos viendo a varios equipos aplicar con éxito este enfoque para acelerar la reescritura de sistemas heredados. El objetivo no es ocultar por completo los detalles de implementación, sino introducir una abstracción temporal que ayude a los equipos y agentes a explorar alternativas sin estar limitados por la estructura actual. Esta técnica está mostrando resultados prometedores al generar código más limpio, mantenible y preparado para el futuro, al tiempo que reduce el esfuerzo necesario para comprender las implementaciones existentes.

GraphQL como patrón de acceso a datos para LLMs es un enfoque emergente para crear una capa de acceso a datos uniforme y compatible con modelos, que mejora la ingeniería de contexto. Permite a los equipos exponer datos estructurados y consultables sin otorgar a los modelos acceso directo a las bases de datos. A diferencia de las API REST, que tienden a recuperar datos en exceso o requieren nuevos endpoints o filtros para cada caso de uso, GraphQL permite que el modelo obtenga solo los datos que necesita, reduciendo el ruido, mejorando la relevancia del contexto y disminuyendo el uso de tokens. Un esquema GraphQL bien definido también proporciona metadatos que los LLM pueden usar para razonar sobre las entidades y relaciones disponibles, lo que permite consultas dinámicas con reconocimiento de esquema para casos de uso con agentes. Este patrón ofrece un punto intermedio seguro entre REST y SQL, equilibrando los controles de gobernanza con un acceso flexible. Sin embargo, el enfoque depende de esquemas bien estructurados y nombres de campo significativos. Interpretar la semántica de los esquemas y navegar por estructuras complejas sigue siendo un desafío, y lo que resulta difícil de razonar para las personas suele ser igual de difícil para los LLM. También es importante tener en cuenta los vectores adicionales para ataques DoS, así como los desafíos habituales de GraphQL, como el almacenamiento en caché y el versionado.

Una pregunta que recibimos con frecuencia es ¿Cómo podemos mejorar la forma en que compartimos información entre nuestros equipos?. Las técnicas para gestionar el conocimiento organizacional siguen evolucionando y una perspectiva que hemos encontrado valiosa proviene del pensamiento sistémico: los conceptos de flujos de conocimiento y reservas de conocimiento. Originalmente provenientes de la economía, este enfoque invita a los equipos a ver su conocimiento organizacional como un sistema, donde las reservas representan el conocimiento acumulado y los flujos representan cómo ese conocimiento se mueve y evoluciona dentro de la organización. Aumentar el flujo de conocimiento externo hacia una organización tiende a impulsar la innovación. Una forma comprobada de mejorar este flujo es establecer comunidades de práctica, que de manera consistente muestran beneficios medibles. Otra es buscar deliberadamente fuentes de conocimiento diversas y externas. A medida que las herramientas de GenAI hacen que las reservas de conocimiento existentes sean más accesibles, vale la pena recordar que fomentar ideas frescas y perspectivas externas es tan importante como adoptar nuevas tecnologías.

Usar un LLM como juez para evaluar la salida de otro sistema, generalmente un productor basado en LLM, ha ganado atención por su potencial de ofrecer una evaluación automatizada y escalable en inteligencia artificial generativa. Sin embargo, movemos este tema de Trial a Assess para reflejar las nuevas complejidades y riesgos identificados. Si bien esta técnica ofrece velocidad y escala, a menudo falla como sustituto confiable del juicio humano. Las evaluaciones son propensas a sesgos de posición, sesgos de verbosidad y baja robustez. Un problema más grave es la contaminación por escala: Cuando se utiliza LLM como juez en pipelines de entrenamiento para el modelado de recompensas, puede introducir sesgos de autoafirmación, donde una familia de modelos favorece sus propias salidas y filtraciones de preferencias, difuminando la frontera entre entrenamiento y prueba. Estos defectos han generado resultados que inflan las métricas de rendimiento sin validez en el mundo real. Algunos estudios de investigación han realizado análisis más rigurosos sobre este patrón. Para contrarrestar estos problemas, estamos explorando técnicas mejoradas, como el uso de LLMs como jurado (empleando varios modelos para llegar a un consenso) o el razonamiento en cadena (chain-of-thought o CoT) durante la evaluación. Si bien estos métodos buscan aumentar la fiabilidad, también incrementan el costo y la complejidad. Recomendamos a los equipos tratar esta técnica con precaución, asegurando verificación humana, transparencia y supervisión ética antes de incorporar LLMs como jueces en flujos de trabajo críticos. El enfoque sigue siendo potente, pero menos maduro de lo que se creía.

La recuperación de información en el dispositivo es una técnica que permite ejecutar búsquedas, reconocimiento de contexto y generación aumentada por recuperación (RAG) directamente en los dispositivos del usuario —ya sean móviles, de escritorio o de borde (edge devices)— priorizando la privacidad y la eficiencia computacional. Esta técnica combina una base de datos local ligera con un modelo optimizado para inferencia en el propio dispositivo. Una implementación prometedora combina sqlite-vec, una extensión de SQLite que habilita búsquedas vectoriales dentro de la base de datos embebida, con EmbeddingGemma, un modelo de embeddings de 300 millones de parámetros construido sobre la arquitectura Gemma 3. Optimizada para la eficiencia y entornos con recursos limitados, esta combinación mantiene los datos cerca del borde –es decir, en los propios dispositivos– reduciendo la dependencia de las API en la nube y mejorando la latencia y la privacidad. Recomendamos que los equipos evalúen esta técnica para aplicaciones local-first y otros casos donde la soberanía de los datos, la baja latencia y la privacidad sean factores críticos.

SAIF (Secure AI Framework) es un framework desarrollado por Google que ofrece una guía práctica para gestionar los riesgos de seguridad en la inteligencia artificial. Aborda de forma sistemática amenazas comunes como la manipulación de datos (data poisoning) y la inyección de prompts, mediante un mapa de riesgos claro y análisis de componentes. SAIF también proporciona estrategias prácticas de mitigación para cada una de estas amenazas. Consideramos que su enfoque en los riesgos emergentes relacionados con la construcción de sistemas con agentes resulta especialmente oportuno y valioso. SAIF ofrece un manual conciso y accionable que los equipos pueden utilizar para fortalecer sus prácticas de seguridad en el uso de LLMs y aplicaciones impulsadas por IA.

Ya que aún persisten los costos y la complejidad operativa de las mallas de servicios (service meshes) basados en sidecars, nos entusiasma ver otra opción surgir para service mesh sin sidecar: Istio ambient mode. El ambient mode introduce una arquitectura en capas que separa las responsabilidades entre dos componentes clave: el proxy L4 por nodo (ztunnel) y el proxy L7 por espacio de nombres (Waypoint proxy). ztunnel garantiza que el tráfico L3 y L4 se transporte de manera eficiente y segura. Este hace funcionar el plano de datos ambient, obteniendo certificados para todas las identidades de nodo y, a su vez, gestiona la redirección del tráfico hacia y desde las cargas de trabajo habilitadas para ambient. El proxy Waypoint, un componente opcional del modo ambient, habilita características más avanzadas de Istio como gestión de tráfico, seguridad y observabilidad. Hemos tenido buenas experiencias con este modo en clústeres de pequeña escala y esperamos obtener más información y mejores prácticas a medida que crece su adopción.

Hemos observado un progreso constante en el desarrollo de small language models (SLMs) a lo largo de varios volúmenes del Radar Tecnológico. Con el creciente interés en la creación de soluciones agénticas, estamos viendo cada vez más evidencia de que los SLMs pueden impulsar la IA agéntica de manera eficiente. La mayoría de los flujos de trabajo basados en agentes actuales se centran en tareas específicas y repetitivas que no requieren razonamiento avanzado, lo que los convierte en una buena opción para los SLMs. Los avances continuos en modelos como Phi-3, SmolLM2 y DeepSeek sugieren que los SLMs ofrecen suficiente capacidad para este tipo de tareas, con beneficios adicionales de menor costo, menor latencia y menor consumo de recursos en comparación con los LLMs. Vale la pena considerar los SLMs como la opción predeterminada para los flujos de trabajo basados en agentes, reservando a los LLMs más grandes y con mayor consumo de recursos sólo para cuando sea necesario.

Spec-driven development es un enfoque emergente para los flujos de trabajo de codificación asistida por IA. Aunque la definición del término aún está evolucionando, generalmente se refiere a flujos de trabajo que comienzan con una especificación funcional estructurada y luego avanzan a través de varios pasos para descomponerla en partes más pequeñas, soluciones y tareas. La especificación puede adoptar muchas formas: un único documento, un conjunto de documentos o artefactos estructurados que capturan diferentes aspectos funcionales. Hemos visto a muchas personas desarrolladoras adoptar este estilo (e incluso tenemos una versión propia que compartimos internamente en Thoughtworks). Tres herramientas en particular han explorado recientemente interpretaciones distintas de spec-driven development. Kiro de Amazon guía a las personas usuarias a través de tres etapas de flujo de trabajo: requisitos, diseño y creación de tareas. spec-kit de GitHub sigue un proceso similar de tres pasos, pero añade una orquestación más rica, prompts configurables y una “constitución” que define principios inmutables que siempre deben cumplirse. Tessl Framework (aún en beta privada en septiembre de 2025) adopta un enfoque más radical, en el que la propia especificación se convierte en el artefacto mantenido, en lugar del código. Encontramos este espacio fascinante, aunque los flujos de trabajo siguen siendo elaborados y prescriptivos. Estas herramientas se comportan de manera muy diferente según el tamaño y tipo de tarea; algunas generan archivos de especificación extensos y difíciles de revisar, y cuando producen PRDs o historias de usuario, a veces no queda claro para quién están dirigidos. Puede que estemos reaprendiendo una bitter lesson, elaborar reglas detalladas a mano para la IA, en última instancia, no es escalable.

El equipo de agentes de codificación se refiere a una técnica en la que una persona desarrolladora orquesta varios agentes de codificación con IA, cada uno con un rol distinto (como arquitecto, especialista en back-end, tester) para colaborar en una tarea de desarrollo. Esta práctica cuenta con el respaldo de herramientas como Claude Code, Roo Code y Kilo Code, que permiten el uso de subagentes y múltiples modos de operación. Basándose en el principio comprobado de que asignar roles y perfiles específicos a los LLM mejora la calidad de los resultados, la idea es obtener mejores resultados al coordinar varios agentes con roles definidos, en lugar de depender de uno solo de propósito general. El nivel óptimo de granularidad de los agentes aún se está explorando, pero puede ir más allá de una simple correspondencia uno a uno con los roles tradicionales de un equipo. Este enfoque marca una transición hacia pipelines de desarrollo asistidos por IA, orquestados y de múltiples etapas.

Las GPU y LPU han dejado de ser dispositivos independientes para convertirse en redes estrechamente acopladas de aceleradores cuyo rendimiento depende de la ubicación y la topología. En sistemas a escala de rack como el NVL72 de NVIDIA, 72 GPUs comparten más de 13 TB de VRAM y funcionan como un único acelerador, hasta que las cargas de trabajo cruzan las islas de conmutadores, convirtiendo las operaciones colectivas en cuellos de botella. De manera similar, la arquitectura de Groq (planificada por software en tiempo de compilación) asume un movimiento de datos determinista; una planificación aleatoria rompe esas suposiciones y su previsibilidad. Incluso dentro de un mismo centro de datos, el rendimiento de las GPU puede variar significativamente, generando la necesidad de una programación consciente de la topología que considere tanto el diseño del hardware como su variabilidad al asignar trabajos. Los planificadores ingenuos que ignoran la topología de NVLink, PCIe o NIC suelen distribuir cargas de trabajo multi-GPU de forma arbitraria, lo que provoca una degradación en los tiempos de ejecución y la eficiencia. Las cargas de entrenamiento, que son síncronas y dependientes del ancho de banda, se benefician de islas NVLink contiguas con rutas uniformes y de alta velocidad para las etapas de all-reduce y pipeline. Estos trabajos deben programarse en función del ancho de banda del tejido, evitando saltos entre conmutadores y tratando los límites de enlace, conmutador y nodo como dominios de falla. Las cargas de inferencia, por el contrario, están limitadas por la latencia y los SLO, y suelen equilibrar la replicación para alta disponibilidad entre dominios, combinándola con particionamiento (sharding) para mantener la localidad de los mixture of experts (MoE) y las cachés KV en las rutas más cortas. Optimizar la ubicación para las fases de prefill y decode, el microprocesamiento por lotes (micro-batching) y el aislamiento de inquilinos mejora aún más la eficiencia. Creemos que la programación consciente de la topología se volverá esencial a medida que el rendimiento de los aceleradores dependa cada vez más de la red y la topología del centro de datos. Nuestros equipos ya están evaluando Kueue y proyectos relacionados para mejorar la precisión en la asignación, incrementar el rendimiento y garantizar una escalabilidad confiable para nuestros clientes.

El ya conocido chiste de que la S en MCP significa “seguridad” oculta un problema muy real. Cuando los agentes se comunican entre sí, ya sea mediante la invocación de herramientas o llamadas a API, pueden encontrarse rápidamente con lo que se ha denominado la tríada letal: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicación externa. Los agentes que combinan estos tres elementos son altamente vulnerables. Dado que los LLMs tienden a seguir las instrucciones incluidas en su entrada, cualquier contenido que contenga una orden para exfiltrar datos a una fuente no confiable puede generar fácilmente filtraciones de datos. Una técnica emergente para mitigar este riesgo es el análisis de flujo tóxico (toxic flow analysis), que examina el grafo de flujo de un sistema de agentes para identificar posibles rutas de datos inseguras que requieren una investigación más profunda. Aunque todavía se encuentra en una etapa temprana, el análisis de flujo tóxico representa una de las aproximaciones más prometedoras para detectar los nuevos vectores de ataque a los que los sistemas de agentes y los servidores MCP están cada vez más expuestos.

La IA está reduciendo las barreras para que quienes no codifican puedan crear e integrar software por sí mismos, en lugar de esperar a que el departamento de TI se encargue de sus necesidades o requisitos. Aunque nos entusiasma el potencial que esto desbloquea, también nos preocupan los primeros indicios de TI en la sombra acelerado por IA. Las plataformas de automatización de flujos de trabajo sin código ahora admiten la integración de APIs de IA (por ejemplo, de OpenAI o Anthropic), lo que hace tentador usar la IA como cinta adhesiva — haciendo integraciones que antes no eran posibles mediante IA, como convertir mensajes de chat de un sistema en llamadas a la API de un ERP. Al mismo tiempo, los asistentes de codificación impulsados por IA se están volviendo más autónomos, lo que permite a quienes no codifican, pero que tienen una formación básica, la posibilidad de crear aplicaciones de utilidad internas.

Esto tiene todas las características de la próxima evolución de las hojas de cálculo que aún impulsan procesos críticos en algunas empresas — pero con un alcance mucho mayor. Si no se controla, esta nueva TI en la sombra podría provocar la proliferación de aplicaciones no gobernadas y potencialmente inseguras, dispersando los datos en cada vez más sistemas. Las organizaciones deben ser conscientes de estos riesgos y evaluar cuidadosamente las ventajas y desventajas entre la rápida resolución de problemas y la estabilidad a largo plazo.

La clave del éxito de las prácticas modernas de desarrollo de software es mantener el foco en el flujo de trabajo. Los equipos alineados al flujo se concentran en un único flujo de valor, como un recorrido de usuario o un producto, lo que les permite entregar valor de extremo a extremo de manera eficiente. Sin embargo, estamos observando una tendencia preocupante hacia el capacity-driven development, dónde equipos alineados de esta forma asumen características o funcionalidades de otros productos o flujos cuando tienen capacidad disponible. Aunque esto puede parecer eficiente a corto plazo, representa una optimización local más adecuada para manejar picos repentinos de demanda. Cuando se normaliza, aumenta la carga cognitiva y la deuda técnica, y en el peor de los casos puede provocar un colapso por congestión, ya que el costo del cambio de contexto entre productos se acumula. Los equipos con capacidad disponible obtienen mejores resultados al centrarse en mejorar la salud del sistema. Para gestionar la capacidad de manera efectiva, utiliza límites al trabajo en progreso (WIP) para controlar el trabajo entre flujos adyacentes, considera la capacitación cruzada para equilibrar los períodos de alta demanda y aplica técnicas de dynamic reteaming cuando sea necesario.

A medida que los asistentes y agentes de codificación con IA ganan terreno, también aumenta la cantidad de datos e investigaciones que señalan preocupaciones sobre la complacencia con el código generado por IA. Si bien existe amplia evidencia de que estas herramientas pueden acelerar el desarrollo (especialmente en proyectos de prototipado y greenfield), los estudios demuestran que la calidad del código puede deteriorarse con el tiempo. La investigación de GitClear (2024) reveló que el código duplicado y el code churn han aumentado más de lo esperado, mientras que la actividad de refactorización en los historiales de commits ha disminuido. En una tendencia similar, una investigación de Microsoft sobre trabajadores del conocimiento muestra que la confianza impulsada por la IA suele darse a costa del pensamiento crítico, un patrón que también hemos observado cuando se afianza la complacencia tras el uso prolongado de asistentes de codificación. El auge de los agentes amplifica aún más estos riesgos, ya que la IA ahora genera conjuntos de cambios más grandes y difíciles de revisar. Como en cualquier sistema, acelerar una parte del flujo de trabajo aumenta la presión sobre las demás. Nuestros equipos han comprobado que usar la IA de forma efectiva en entornos de producción requiere un enfoque renovado en la calidad del código. Recomendamos reforzar prácticas consolidadas como TDD y el análisis estático, e integrarlas directamente en los flujos de trabajo de codificación, por ejemplo, mediante prompts compartidos seleccionados para equipos de software.

Las organizaciones están cada vez más interesadas en permitir que los agentes de IA interactúen con sus sistemas existentes, a menudo intentando una conversión directa y sin fricciones de las API internas al Model Context Protocol (MCP). Un número creciente de herramientas, como MCP link y FastAPI-MCP, buscan facilitar este proceso. Aconsejamos evitar esta conversión ingenua de API a MCP. Las API suelen estar diseñadas para desarrolladores humanos y a menudo consisten en acciones granulares y atómicas que, al ser encadenadas por una IA, pueden generar un uso excesivo de tokens, contaminación del contexto y bajo rendimiento de los agentes. Además, estas API (especialmente las internas) suelen exponen datos sensibles o permiten operaciones destructivas. Para los desarrolladores humanos, esos riesgos se mitigan mediante patrones de arquitectura y revisiones de código; sin embargo, cuando las API se exponen de forma ingenua a los agentes a través de MCP, no existe una forma confiable ni determinista de evitar que un agente de IA autónomo haga un uso indebido de estos endpoints. Recomendamos diseñar un servidor MCP dedicado y seguro, específicamente adaptado a los flujos de trabajo agéntico, construido sobre las API existentes.

Organizar equipos de ingeniería de datos separados para desarrollar y poseer pipelines y productos de datos, independientes de los dominios de negocio alineados al flujo que atienden, es un antipatrón que genera ineficiencias y resultados de negocio débiles. Esta estructura repite errores del pasado, como aislar las funciones de DevOps, testing o despliegue, creando silos de conocimiento, cuellos de botella y esfuerzos desperdiciados. Sin una colaboración estrecha, las personas ingenieras de datos suelen carecer del contexto de negocio y del dominio necesarios para diseñar productos de datos significativos, lo que limita tanto su adopción como su valor. En contraste, los equipos de plataformas de datos deberían centrarse en mantener la infraestructura compartida, mientras que los equipos de negocio multifuncionales construyen y poseen sus propios productos de datos, siguiendo los principios de data mesh. Colocamos esta práctica en Hold para desincentivar con firmeza los patrones organizativos en silos, especialmente ahora que la necesidad de datos ricos en contexto y listos para IA sigue creciendo.

Text to SQL utiliza LLMs para traducir lenguaje natural en SQL ejecutable, pero su confiabilidad suele estar por debajo de lo esperado. Hemos movido este blip a Hold para desalentar su uso en flujos de trabajo no supervisados, por ejemplo, al convertir dinámicamente consultas generadas por usuarios cuando el resultado se oculta o se ejecuta de forma automática. En estos casos, los LLMs suelen alucinar debido a una comprensión limitada del esquema o del dominio, lo que puede provocar recuperaciones de datos incorrectas o modificaciones no intencionadas. La naturaleza no determinista de las salidas de los LLM también dificulta depurar y auditar errores. Aconsejamos usar Text to SQL con precaución. Se debe exigir revisión humana de las consultas generadas. Para inteligencia de negocio agéntica, evita el acceso directo a bases de datos y utiliza en su lugar una capa semántica de abstracción de datos gobernada, como Cube o la capa semántica de dbt, o bien una capa de acceso semánticamente rica como GraphQL o MCP.