÷ÈÓ°Ö±²¥

Las organizaciones adoptan activamente pensamiento de producto de datos como pr¨¢ctica est¨¢ndar para gestionar activos de datos. Este enfoque trata los datos como un producto con su propio ciclo de vida, est¨¢ndares de calidad y un enfoque en conocer las necesidades del consumidor. Ahora lo recomendamos como la elecci¨®n predeterminada para la gesti¨®n de datos, independientemente de si las organizaciones eligen arquitecturas como data mesh o lakehouse.

Enfatizamos la orientaci¨®n al consumidor en el pensamiento de producto de datos para impulsar un mayor adopci¨®n y generaci¨®n de valor. Esto significa trabajando desde los casos de uso hacia atr¨¢s. Tambi¨¦n nos enfocamos en capturar y gestionar tanto metadatos relevantes del negocio como metadatos t¨¦cnicos usando cat¨¢logos de datos modernos como DataHub, Collibra, Atlan e Informatica. Estas pr¨¢cticas mejoran el descubrimiento y usabilidad de los datos. Adicionalmente, aplicamos el pensamiento de producto de datos para escalar iniciativas de IA y crear datos listos para IA. Este enfoque incluye una gesti¨®n integral del ciclo de vida, asegurando que los datos no solo est¨¦n bien gobernados y sean de alta calidad, sino que tambi¨¦n se retiren en cumplimiento con los requisitos legales y regulatorios cuando ya no sean necesarios.

Fuzz testing , o simplemente fuzzing, es una t¨¦cnica de pruebas que ha existido durante mucho tiempo, pero sigue siendo una de las t¨¦cnicas menos conocidas. El objetivo es proporcionar a un sistema de software todo tipo de entradas inv¨¢lidas y observar su comportamiento. Para un endpoint HTTP, por ejemplo, las solicitudes incorrectas deber¨ªan resultar en errores 4xx, pero el fuzz testing a menudo provoca errores 5xx o peores. Bien documentado y soportado por herramientas, el fuzz testing es m¨¢s relevante que nunca con mayor cantidad de c¨®digo generado por IA y Complacencia con el c¨®digo generado por IA. Esto significa que ahora es un buen momento para adoptar el fuzz testing y asegurar que el c¨®digo siga siendo robusto y seguro.

Desde nuestro primer blip sobre Software Bill of Materials (SBOM) en 2021, la generaci¨®n de SBOM ha pasado de ser una pr¨¢ctica emergente a una pr¨¢ctica por defecto en nuestros proyectos. El ecosistema ha madurado significativamente, ofreciendo un conjunto de herramientas robusto y una integraci¨®n fluida con CI/CD. Herramientas como Syft, Trivy y Snyk permiten la generaci¨®n integral de SBOM, desde el c¨®digo fuente hasta las im¨¢genes de contenedores, adem¨¢s de escaneo de vulnerabilidades. Plataformas como FOSSA y Chainloop mejoran la gesti¨®n de riesgos de seguridad al integrarse con los flujos de desarrollo y reforzar pol¨ªticas de seguridad. Aunque un est¨¢ndar universal para SBOM sigue en evoluci¨®n, el amplio soporte para y CycloneDX ha reducido los desaf¨ªos de adopci¨®n. Los sistemas de IA tambi¨¦n requieren SBOM, como lo demuestran el del gobierno del Reino Unido y el de CISA. Seguiremos monitoreando los avances en este ¨¢mbito.

En el panorama en r¨¢pida evoluci¨®n del desarrollo de software impulsado por IA, el es m¨¢s crucial que nunca para crear software seguro, manteniendo la agilidad y evitando el security sandwich. El modelado de amenazas; un conjunto de t¨¦cnicas para identificar y clasificar potenciales amenazas, se aplica en diversos contextos, , que introducen . Para que sea eficaz, debe realizarse con frecuencia a lo largo del ciclo de vida del software y funciona mejor junto con otras pr¨¢cticas de seguridad. Entre ellas se incluye la definici¨®n de requisitos de seguridad interfuncionales para abordar riesgos comunes en las tecnolog¨ªas del proyecto y el aprovechamiento de esc¨¢neres de seguridad automatizados para monitoreo continuo.

Tratar APIs como producto significa priorizar la experiencia del desarrollador(a), no s¨®lo mediante un dise?o razonable y estandarizado de dichas APIs sino tambi¨¦n proporcionando una documentaci¨®n completa y una experiencia de onboarding fluida. Aunque las especificaciones de OpenAPI (Swagger) pueden documentar interfaces de APIs de manera efectiva, el onboarding contin¨²a siendo un desaf¨ªo. Los desarrolladores(as) necesitan acceso r¨¢pido a ejemplos funcionales, con autenticaci¨®n pre-configurada y datos de prueba realistas. Con la evoluci¨®n de herramientas de clientes API (como Postman, Bruno e Insomnia), recomendamos tratar las colecciones de peticiones API como artefactos del producto API. Las colecciones de peticiones API deben ser dise?adas cuidadosamente para guiar a los desarrolladores(as) a trav¨¦s de flujos de trabajo clave, ayud¨¢ndoles a comprender el lenguaje y funcionalidad del dominio de la API con el m¨ªnimo esfuerzo. Para mantener estas colecciones actualizadas, recomendamos almacenarlas en un repositorio e integrarlas dentro del pipeline de despliegue de la API.

Uno de los retos constantes en equipos grandes de software es determinar qui¨¦n toma las decisiones arquitect¨®nicas que dan forma a la evoluci¨®n de los sistemas. El informe revela que el enfoque tradicional de las Juntas de Revisi¨®n de Arquitectura es contraproducente, y a menudo obstaculiza el flujo de trabajo y se correlaciona con un bajo rendimiento organizacional. Una alternativa convincente es ¡ª un enfoque descentralizado donde cualquiera puede tomar una decisi¨®n arquitect¨®nica, siempre que busque asesoramiento de los afectados y de aquellos con experiencia relevante. Este m¨¦todo permite a los equipos optimizar el flujo sin comprometer la calidad arquitect¨®nica, tanto a peque?a como a gran escala. A primera vista, esta alternativa puede parecer controversial, pero pr¨¢cticas como Architecture Decision Records y los foros de asesoramiento garantizan que las decisiones se mantengan informadas, mientras que tambi¨¦n empoderan a quienes est¨¢n m¨¢s cerca del trabajo a tomar decisiones. Hemos visto este modelo tener ¨¦xito a escala en un gran n¨²mero de organizaciones, incluyendo aquellas en industrias altamente reguladas

En nuestra ¨²ltima actualizaci¨®n de RAG, introdujimos GraphRAG , descrito originalmente en como un enfoque en dos pasos: (1) fragmentaci¨®n de documentos y uso de an¨¢lisis basado en LLM de los fragmentos para crear un grafo de conocimientos; (2) recuperaci¨®n de fragmentos relevantes en el momento de la consulta mediante incrustaciones mientras se siguen las aristas del grafo de conocimiento para descubrir fragmentos relacionados adicionales, que se a?aden al prompt aumentado. En muchos casos, este enfoque mejora las respuestas generadas por LLM. Hemos observado beneficios similares al utilizar IA generativa para comprender bases de c¨®digo heredadas, donde utilizamos informaci¨®n estructural, como ¨¢rboles sint¨¢cticos abstractos y dependencias, para construir el grafo de conocimiento. El patr¨®n GraphRAG ha ganado adeptos, con herramientas y frameworks como el de Neo4j, que est¨¢n surgiendo para soportarlo. Tambi¨¦n consideramos que Graphiti se ajusta a una interpretaci¨®n m¨¢s amplia de GraphRAG como patr¨®n.

El garantiza que los usuarios y sistemas solo tengan el acceso m¨ªnimo necesario para realizar las tareas. El abuso de credenciales privilegiadas es un factor clave en las , siendo la escalada de privilegios un vector de ataque com¨²n. Los atacantes suelen empezar con un acceso de bajo nivel y explotan vulnerabilidades del software o configuraciones err¨®neas para obtener privilegios de administrador, especialmente cuando las cuentas tienen permisos excesivos o innecesarios. Otro riesgo que a menudo se pasa por alto es el de los privilegios permanentes: accesos privilegiados disponibles de forma continua que ampl¨ªan la superficie de ataque. La gesti¨®n de acceso privilegiado justo a tiempo mitiga este riesgo al conceder acceso solo cuando es necesario y revocarlo inmediatamente despu¨¦s, minimizando la exposici¨®n. Un modelo de seguridad de menor privilegio garantiza que los usuarios, aplicaciones y sistemas tengan ¨²nicamente los derechos imprescindibles durante el m¨ªnimo tiempo posible, un requisito fundamental para el cumplimiento normativo y la seguridad regulatoria. Nuestros equipos lo han implementado a trav¨¦s de un flujo de trabajo automatizado que activa un proceso de aprobaci¨®n ligero, asigna roles temporales con acceso restringido e impone un tiempo de vida a cada rol, lo que garantiza que los privilegios expiren autom¨¢ticamente una vez completada la tarea.

Las han sido un factor clave del auge de la IA; el principio de que modelos m¨¢s grandes, conjuntos de datos m¨¢s extensos y mayores recursos de c¨®mputo conducen a sistemas de IA m¨¢s potentes. Sin embargo, el hardware de consumo y los dispositivos perimetrales a menudo carecen de la capacidad para soportar modelos a gran escala, lo que crea la necesidad de la destilaci¨®n de modelos.

La transfiere conocimiento de un modelo m¨¢s grande y potente (maestro) a un modelo m¨¢s peque?o y eficiente en coste (estudiante). El proceso suele implicar la generaci¨®n de un conjunto de datos de muestra a partir del modelo maestro y el ajuste del modelo estudiante para que capture sus propiedades estad¨ªsticas. A diferencia de la poda o la , que se enfocan en la compresi¨®n de modelos suprimiendo par¨¢metros, la destilaci¨®n intenta retener conocimiento espec¨ªfico del dominio, minimizando la p¨¦rdida de precisi¨®n. Tambi¨¦n se puede combinar con la ³¦³Ü²¹²Ô³Ù¾±³ú²¹³¦¾±¨®²Ô para una optimizaci¨®n adicional.

por Geoffrey Hinton y otros, la destilaci¨®n de modelos ha sido ampliamente adoptada. Un ejemplo destacado es Qwen/Llama la versi¨®n destilada de DeepSeek R1, que mantiene s¨®lidas capacidades de razonamiento en modelos m¨¢s peque?os. Con su creciente madurez, la t¨¦cnica ya no se limita s¨®lo a los laboratorios de investigaci¨®n; ahora se aplica en una amplia variedad de proyectos, desde industriales hasta personales. Proveedores como y ofrecen gu¨ªas para ayudar a los desarrolladores a destilar sus propios modelos de lenguaje reducido (SLMs, small language model, por sus siglas en ingl¨¦s). Creemos que la adopci¨®n de la destilaci¨®n de modelos puede ayudar a las organizaciones a gestionar los costes de despliegue de los LLM al tiempo que libera el potencial de la inferencia LLM en dispositivos.

Prompt engineering se refiere al proceso de dise?ar y refinar los prompts (instrucciones) para modelos de IA generativa, con el objetivo de producir respuestas de alta calidad conscientes del contexto. Esto implica elaborar indicaciones claras, espec¨ªficas y relevantes, ajustadas a la tarea o a la aplicaci¨®n, para optimizar el resultado del modelo. A medida que las LLM evolucionan, particularmente con las llegada de los modelos de razonamiento, las pr¨¢cticas del prompt engineering deben ser adaptadas. Basados en nuestra experiencia con la generaci¨®n de c¨®digo con IA, hemos observado que pueden ofrecer un menor rendimiento comparado con prompts sin ejemplos al trabajar con modelos de razonamiento. Adem¨¢s, la t¨¦cnica ampliamente usada de cadena de razonamiento o (CoT) puede el desempe?o de los modelos de razonamiento, probablemente debido a que el aprendizaje por refuerzo ya ha su mecanismo interno de CoT.

Nuestra experiencia pr¨¢ctica se alinea con lo que se?ala la investigaci¨®n acad¨¦mica, que sugiere que ¡°los modelos m¨¢s avanzados podr¨ªan del prompt engineering en el desarrollo de software¡±. No obstante, las t¨¦cnicas tradicionales del prompt engineering seguir¨¢n teniendo un rol crucial en reducir alucinaciones y mejorar la calidad de las respuestas, especialmente considerando las diferencias en tiempos de respuestas y costos de tokens entre los modelos de razonamiento y los LLM generales. Al crear aplicaciones con agentes aut¨®nomos, recomendamos elegir los modelos estrat¨¦gicamente, con base en las necesidades y seguir refinando tanto las plantillas de prompts c¨®mo sus t¨¦cnicas correspondientes. Encontrar el equilibrio entre la calidad, el tiempo de respuesta y el costo de los tokens sigue siendo clave para maximizar la efectividad de los LLM.

El reciente anuncio de DeepSeek R1 es un gran ejemplo de por qu¨¦ los small language models (SLMs) siguen siendo interesantes. La versi¨®n completa de R1 tiene 671 mil millones de par¨¢metros y requiere alrededor de 1.342 GB de VRAM para funcionar, algo que solo se logra utilizando unmini cluster de ocho GPUs NVIDIA de ¨²ltima generaci¨®n. Pero DeepSeek tambi¨¦n est¨¢ disponible en versi¨®n en Qwen y Llama ¡ª modelos m¨¢s peque?os yopen-weight ¡ª, transfiriendo efectivamente sus capacidades y permitiendo que se ejecute en hardware mucho m¨¢s modesto. Aunque el modelo sacrifica algo de rendimiento en esos tama?os reducidos, a¨²n permite un gran salto en rendimiento respecto a los SLMs anteriores. El campo de los SLM sigue innovando en otros ¨¢mbitos, tambi¨¦n. Desde el ¨²ltimo Radar, Meta introdujo en tama?os de 1B y 3B, Microsoft lanz¨® , ofreciendo resultados de alta calidad con un modelo de 14B, y Google present¨® , un modelo de visi¨®n-lenguaje en tama?os de 3B, 10B y 28B. Estos son solo algunos de los modelos que se est¨¢n lanzando actualmente en tama?os m¨¢s peque?os y, sin duda, es una tendencia importante a seguir.

En los ¨²ltimos meses, el uso de GenAI para comprender bases de c¨®digo legado ha generado verdaderos progresos. Herramientas populares como GitHub Copilot se est¨¢n promocionando como . Herramientas como de Sourcegraph facilitan a los desarrolladores la navegaci¨®n y comprensi¨®n de bases de c¨®digo completas. Estas herramientas utilizan multitud de t¨¦cnicas de GenAI para proporcionar ayuda contextual, simplificando el trabajo con sistemas legados complejos. Adem¨¢s, frameworks especializados como est¨¢n mostrando c¨®mo los modelos de lenguaje extensos (LLMs) pueden manejar software cient¨ªfico de gran escala -como los escritos en Fortran o Pascal- llevando la comprensi¨®n mejorada por GenAI a bases de c¨®digo fuera de la TI empresarial tradicional. Creemos que esta t¨¦cnica continuar¨¢ ganando terreno dada la enorme cantidad de software legacy en el mundo.

Los agentes de ingenier¨ªa de software supervisados son cada vez m¨¢s capaces de identificar actualizaciones necesarias e implementar cambios m¨¢s extensos en una base de c¨®digo. Al mismo tiempo, se observa un mayor nivel de complacencia con el c¨®digo generado por IA, con desarrolladoras y desarrolladores que se resisten a revisar conjuntos de cambios extensos realizados por IA. Una justificaci¨®n t¨ªpica para esta actitud es la percepci¨®n de que la calidad del c¨®digo orientado a humanos no es tan cr¨ªtica porque la IA podr¨¢ encargarse de futuras modificaciones; sin embargo, los asistentes de codificaci¨®n basados en IA funcionan mejor con bases de c¨®digo bien estructuradas y dise?adas, lo que hace que un c¨®digo amigable hacia la IA sea crucial para su mantenibilidad. Afortunadamente, un buen dise?o de software para humanos tambi¨¦n beneficia a la IA. Los nombres significativos proporcionan contexto de dominio y funcionalidad; la modularidad y las abstracciones permiten a la IA gestionar mejor el contexto al limitar las modificaciones necesarias; y el principio DRY (Don¡¯t Repeat Yourself o No te repitas) reduce el c¨®digo duplicado, ayudando a que la IA tenga un comportamiento m¨¢s predecible. Hasta ahora, los patrones m¨¢s amigables con la IA coinciden con las mejores pr¨¢cticas establecidas en el desarrollo de software. A medida que la IA siga evolucionando, es probable que surjan patrones a¨²n m¨¢s espec¨ªficos para su optimizaci¨®n, por lo que tener esto en cuenta al dise?ar c¨®digo ser¨¢ de gran utilidad.

Est¨¢n surgiendo nuevas t¨¦cnicas de asistencia impulsadas por IA en equipos de desarrollo de software, m¨¢s all¨¢ de la mera generaci¨®n de c¨®digo. Un ¨¢rea que est¨¢ ganando tracci¨®n es la de pruebas de IU impulsadas por IA , que se apoyan en la capacidad de los LLMs para interpretar interfaces gr¨¢ficas de usuario. Existen diversas aproximaciones para esto. Hay una categor¨ªa de herramientas que usan LLMs multimodales ajustados para el procesamiento de instant¨¢neas de la IU, que permiten a los scripts de prueba escritos en lenguaje natural, navegar por la aplicaci¨®n. Ejemplos en este espacio son o . Otro enfoque, visto en Browser Use, combina modelos de base multimodal con las perspectivas que Playwright extrae de la estructura de la pagina web, en lugar de apoyarse en modelos finamente ajustados.

Al integrar pruebas de IU impulsadas por IA en una estrategia de pruebas, es crucial considerar donde producen m¨¢s valor. Estos m¨¦todos pueden complementar las pruebas manuales exploratorias, y aunque la falta de determinismo de los LLMs puede introducir fallos aleatorios, su imprecisi¨®n puede ser una ventaja. Esto puede ser ¨²til para probar aplicaciones heredadas con selectores faltantes o aplicaciones que cambian frecuentemente sus etiquetas y rutas de clic.

define las reglas b¨¢sicas que gobiernan sistemas adaptativos, incluyendo los sistemas socio-t¨¦cnicos involucrados en software de construcci¨®n y operaci¨®n. Un concepto clave en esta teor¨ªa es el de Competence envelope ¡ª el l¨ªmite en el que un sistema puede funcionar robustamente frente a fallas. Cuando un sistema es llevado m¨¢s all¨¢ de su competence envelope, se vuelve fr¨¢gil y es m¨¢s propenso a fallar. Este modelo provee un lente valioso para comprender fallas sist¨¦micas, como se pudo observar en las que llevaron a la ca¨ªda de Canva de 2024. , un desarrollo reciente en Software Architecture Thinking, ofrece una forma de poner a prueba el Competence Envelope de un sistema a partir de la introducci¨®n deliberada de factores de estr¨¦s a dicho sistema, y el posterior an¨¢lisis de c¨®mo ¨¦ste se ha adaptado a estos estresores de manera hist¨®rica a lo largo del tiempo. Los enfoques se alinean con los conceptos de anti-fragilidad, resiliencia y robustez en sistemas socio-t¨¦cnicos, y nos entusiasma ver aplicaciones pr¨¢cticas emerger en este campo.

La salida estructurada de LLMs se refiere a la pr¨¢ctica de restringir la respuesta de un modelo de lenguaje, a un esquema definido. Esto se puede lograr ya sea a trav¨¦s de instruir a un modelo generalizado que responda en un formato particular o realizando fine-tuning a un modelo para obtener una salida ¡°nativa¡±, por ejemplo, JSON. OpenAI ahora soporta salida estructurada, permitiendo a los desarrolladores proporcionar un esquema JSON, pydantic o un objeto Zod para limitar las respuestas de un modelo. Esta capacidad es particularmente valiosa ya que permite llamadas a funciones, interacciones con una API e integraciones externas, donde la precisi¨®n y el cumplimiento de un formato son cr¨ªticas. La salida estructurada no solo mejora la forma en que los LLMs pueden interactuar con el c¨®digo, sino que tambi¨¦n soporta un mayor cantidad de casos de uso, como generaci¨®n de markup para el renderizado de gr¨¢ficos. Adicionalmente, la salida estructurada ha demostrado reducir las posibilidades de alucinaciones en la salida de un modelo.

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 API de IA (por ejemplo, OpenAI o Anthropic), lo que hace tentador usar la IA como cinta adhesiva ¡ª uniendo integraciones que antes no eran posibles, como convertir mensajes de chat de un sistema en llamadas a la API de un ERP mediante IA. 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 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.

A medida que los asistentes de IA para escritura de c¨®digo ganan peso, tambi¨¦n lo hace el n¨²mero de investigaciones y datos que traen a la luz la preocupaci¨®n por la complacencia con el c¨®digo generado por IA. El ¨²ltimo estudio de calidad de c¨®digo de GitClear's (?) muestra que, en el 2024, el c¨®digo duplicado y la rotaci¨®n de c¨®digo aumentaron m¨¢s de lo previsto, mientras la actividad de refactorizaci¨®n en el historial de commits disminuy¨®. Adem¨¢s, como reflejo de la complacencia en el c¨®digo generado por IA, un estudio de Microsoft (?) sobre trabajadores de conocimiento mostr¨® que la confianza generada por la IA suele venir a costa del pensamiento cr¨ªtico, un patr¨®n que hemos observado a medida que la complacencia se instala con el uso prolongado de asistentes de programaci¨®n. El auge de los agentes de ingenier¨ªa de software supervisados (https: //www.thoughtworks.com/es/radar/techniques/software-engineering-agents)?) amplifica a¨²n m¨¢s los riesgos, ya que, cuando la IA genera conjuntos de cambios cada vez m¨¢s grandes, los desarrolladores se enfrentan a mayores desaf¨ªos a la hora de revisar los resultados. La aparici¨®n de la , donde los desarrolladores permiten que la IA genere c¨®digo con una revisi¨®n m¨ªnima, ilustra la creciente confianza en los resultados generados por la IA. Si bien este enfoque puede ser adecuado para prototipos u otros tipos de c¨®digo descartable, recomendamos encarecidamente no usarlo para c¨®digo de producci¨®n.

Las organizaciones se mantienen cautelosas con respecto a las IAs asistentes de c¨®digo de terceros, particularmente debido a preocupaciones con respecto a la confidencialidad del c¨®digo. Como resultado, muchos desarrolladores est¨¢n considerando asistentes de c¨®digo locales , IAs que corren completamente en sus propias m¨¢quinas, eliminando la necesidad de enviar c¨®digo a servidores externos. Sin embargo, los asistentes locales a¨²n se quedan atr¨¢s de sus contrapartes de nube, que conf¨ªan en modelos m¨¢s grandes y m¨¢s capaces. Incluso en m¨¢quinas de desarrollo de alta gama, los modelos m¨¢s peque?os mantienen capacidades limitadas. Hemos encontrado que tienen dificultades con prompts complejos, carecen de la ventana de contexto necesaria para problemas m¨¢s grandes y a menudo no pueden gatillar integraciones de herramientas o llamadas a funciones. Estas capacidades son especialmente esenciales para los flujos de trabajo agentivos, los cuales son la vanguardia en asistencia de c¨®digo actualmente.

As¨ª que, si bien recomendamos proceder con bajas expectativas, existen algunas capacidades que son v¨¢lidas a nivel local. Ciertos IDEs populares actualmente incorporan modelos m¨¢s peque?os en sus caracter¨ªsticas centrales, tales como el completado de c¨®digo predictivo de Xcode y . Y LLMs que puedan correr localmente como son un paso hacia sugerencias locales en l¨ªnea y manejo de queries simples de c¨®digo. Se puede probar estas capacidades con Continue, que soporta la integraci¨®n de modelos locales v¨ªa tiempo de ejecuci¨®n como Ollama.

Cuando se habla de codificaci¨®n en pares, inevitablemente surge el tema de . Nuestra profesi¨®n tiene una relaci¨®n de amor-odio con ella: algunos la adoran, otros no la soportan. Los codificadores en pares plantean ahora la siguiente pregunta: ?puede un humano trabajar en par con la IA, en lugar de con otro humano, y obtener los mismos resultados para el equipo? GitHub Copilot incluso se llama a s¨ª mismo ?tu codificador en parejas de IA?. Aunque creemos que un asistente de programaci¨®n puede aportar algunas de las ventajas de la programaci¨®n en parejas, desaconsejamos totalmente . Enmarcar a los asistentes de programaci¨®n como codificadores en pareja ignora uno de los principales beneficios de la programaci¨®n en pareja: mejorar el equipo, no s¨®lo a los colaboradores individuales. Los asistentes de programaci¨®n pueden ser ¨²tiles para desbloquearse, aprender sobre una nueva tecnolog¨ªa, incorporarse o agilizar el trabajo t¨¢ctico para que podamos centrarnos en el dise?o estrat¨¦gico. Pero no contribuyen a ninguno de los beneficios de la colaboraci¨®n en equipo, como mantener bajo el trabajo en curso, reducir los traspasos y el re-aprendizaje, hacer posible la integraci¨®n continua o mejorar la propiedad colectiva del c¨®digo.

Estamos observando una preocupante proliferaci¨®n del llamado Reverse ETL. Los procesos ETL tradicionales tienen su lugar en las arquitecturas de datos convencionales, donde transfieren informaci¨®n desde sistemas de procesamiento transaccional hacia un sistema de an¨¢lisis centralizado, como un data warehouse o un data lake. Si bien esta arquitectura tiene limitaciones bien documentadas, muchas de las cuales son abordadas por un data mesh, sigue siendo com¨²n en las empresas. En este contexto, mover datos desde un sistema de an¨¢lisis centralizado de vuelta a un sistema transaccional puede tener sentido en ciertos casos, como cuando el sistema central puede agregar datos de m¨²ltiples fuentes o como parte de una arquitectura transicional en el proceso de migraci¨®n hacia un data mesh. Sin embargo, estamos viendo una creciente tendencia en la que proveedores de productos utilizan Reverse ETL como excusa para trasladar cada vez m¨¢s l¨®gica de negocio a una plataforma centralizada: su propio producto. Este enfoque agrava muchos de los problemas que generan las arquitecturas de datos centralizadas, por lo que recomendamos tener extrema precauci¨®n al introducir flujos de datos desde una plataforma de datos centralizada y expansiva hacia sistemas de procesamiento transaccional.

Observamos una adopci¨®n continua de (Scaled Agile Framework?). Tambi¨¦n seguimos observando que los procesos excesivamente estandarizados y basados en fases de SAFe generan fricci¨®n, que puede promover silos y que su control de arriba hacia abajo genera desperdicios en el flujo de valor y desalienta la creatividad del talento de ingenier¨ªa, mientras limita la autonom¨ªa y experimentaci¨®n en los equipos. Una raz¨®n clave para su adopci¨®n es la complejidad de hacer que una organizaci¨®n se vuelva ¨¢gil, con empresas que esperan que un marco como SAFe ofrezca un atajo simple y basado en procesos para volverse ¨¢giles. Dada la amplia adopci¨®n de SAFe -incluso entre nuestros clientes- hemos capacitado a m¨¢s de 100 consultores de ÷ÈÓ°Ö±²¥ para apoyarlos mejor. A pesar de este conocimiento profundo y los m¨²ltiples intentos, nuestra impresi¨®n es que a veces simplemente no hay una soluci¨®n simple para un problema complejo, y seguimos recomendando un enfoque ¨¢gil, basado en entrega de valor y gobernanza que funcionen en conjunto con un programa integral de cambio.

Scaled Agile Framework? y SAFe? son marcas comerciales de Scaled Agile, Inc.