Técnicas

Durante muchos años, hemos utilizado el enfoque de canary release para fomentar el feedback temprano sobre nuevas versiones del software, mientras reducimos el riesgo mediante un despliegue incremental a usuarios seleccionados. El 1% canary es una técnica útil en la que desplegamos nuevas funcionalidades a un segmento muy pequeño (digamos, el 1%) de usuarios cuidadosamente seleccionados de varias categorías de usuarios. Esto permite a los equipos capturar rápidamente el feedback de los usuarios y observar el impacto de las nuevas versiones en aspectos como el rendimiento y la estabilidad, para aprender y responder según sea necesario. Esta técnica se vuelve especialmente crucial cuando los equipos están implementando actualizaciones de software en aplicaciones móviles o en una flota de dispositivos, como dispositivos de edge computing o vehículos definidos por software. Con una adecuada observabilidad y feedback temprano, ofrece la oportunidad de limitar el alcance del impacto en caso de que surjan escenarios inesperados en producción. Aunque las canary releases pueden ser útiles para obtener un feedback más rápido de los usuarios, creemos que comenzar con un pequeño porcentaje de los usuarios es obligatorio para reducir y contener el riesgo en despliegues de funcionalidades a gran escala.

Las pruebas automatizadas siguen siendo la piedra angular del desarrollo eficaz de software. Para las pruebas de front-end podemos discutir si la distribución de distintos tipos de pruebas debería ser la clásica pirámide de pruebas o si debe tener forma de un trofeo. En cualquier caso, los equipos deberían centrarse en las pruebas de componentes porque los conjuntos de pruebas deben ser estables y ejecutarse rápidamente. En cambio, lo que estamos viendo es que los equipos renuncian a dominar las pruebas de componentes en favor de pruebas end-to-end basadas en el navegador, así como pruebas unitarias muy limitadas. Las pruebas unitarias tienden a forzar a los componentes a exponer lo que debería ser una funcionalidad puramente interna, mientras que las pruebas basadas en navegador son lentas, más inestables y más difíciles de depurar. Nuestra recomendación es tener una cantidad significativa de pruebas de componentes y utilizar una biblioteca como jsdom para ejecutar pruebas de componentes en memoria. Las herramientas de navegador como Playwright por supuesto, siguen teniendo un lugar en las pruebas de end-to-end, pero no deberían utilizarse para pruebas de componentes.

Creemos que las compañías deben adoptar prácticas de despliegue continuo siempre que sea posible. El despliegue continuo es la práctica de desplegar automáticamente a producción cada cambio que pasa las pruebas automatizadas. Esta práctica es un factor clave para lograr ciclos rápidos de retroalimentación y permite a las organizaciones entregar valor a los clientes de manera más rápida y eficiente. El despliegue continuo difiere de la entrega continua en que esta última sólo requiere que el código pueda ser desplegado en cualquier momento; no requiere que cada cambio realmente esté desplegado en producción. En el pasado habíamos dudado si mover el despliegue continuo hacia el anillo de Adopción, ya que es una práctica que requiere un alto nivel de madurez en otras áreas de la entrega de software y por lo tanto no es apropiada para todos los equipos. Sin embargo, el reciente libro de la Thoughtworker Valentina Servile Continuous Deployment proporciona una guía exhaustiva para implementar esta práctica en una organización. Ofrece un roadmap para que las organizaciones la sigan y así logren alcanzar el nivel de madurez requerido para adoptar prácticas de despliegue continuo.

Generación mejorada por recuperación (RAG) es el patrón preferido por nuestros equipos para mejorar la calidad de las respuestas generadas por un modelo de lenguaje de gran tamaño (LLM). Lo hemos utilizado con éxito en muchos proyectos, incluyendo la plataforma de IA Jugalbandi. Con RAG, la información sobre documentos relevantes y confiables se almacena en una base de datos. Para un prompt dado, se consulta la base de datos, se recuperan los documentos relevantes y se amplía el prompt con el contenido de los documentos, proporcionando así un contexto más completo al LLM. Esto resulta en una salida de mayor calidad y reduce considerablemente las alucinaciones. La ventana de contexto —que determina el tamaño máximo de la entrada del LLM— ha crecido significativamente con los modelos más nuevos, pero seleccionar los documentos más relevantes sigue siendo un paso crucial. Nuestra experiencia indica que un contexto más pequeño y cuidadosamente construido puede generar mejores resultados que un contexto amplio y grande. Utilizar un contexto grande también es más lento y costoso. Antes dependíamos únicamente de incrustaciones almacenadas en una base de datos vectorial para identificar el contexto adicional. Ahora estamos viendo re-ranking y búsqueda híbrida: herramientas de búsqueda como Elasticsearch Relevance Engine, así también enfoques como GraphRAG que utilizan grafos de conocimiento creados con la ayuda de un LLM. El enfoque basado en grafos ha funcionado particularmente bien en nuestro trabajo sobre la comprensión de bases de código heredado con GenAI.

El diseño guiado por dominios (DDD) se ha convertido en un enfoque fundamental en la forma en que desarrollamos software. Lo utilizamos para modelar eventos, guiar diseños de software, establecer límites de contexto alrededor de microservicios y elaborar requisitos de negocio matizados. DDD establece un lenguaje ubicuo que tanto las partes interesadas no técnicas y los desarrolladores de software puedan usar para comunicarse efectivamente acerca del negocio. Una vez establecido, los modelos de dominio evolucionan, pero a muchos equipos les resulta difícil comenzar con DDD. No existe un enfoque único para construir un modelo de dominio inicial. Una técnica prometedora que hemos encontrado recientemente es la narración de dominio (domain storytelling) . La narración de dominio es una técnica donde a los expertos en negocio se les solicita que describan las actividades en el negocio. A medida que los expertos son guiados a través de la narración, un facilitador usa un lenguaje pictográfico para capturar las relaciones y acciones entre las entidades y actores. El proceso de realizar estas historias ayuda visiblemente a clarificar y desarrollar un entendimiento compartido entre los participantes. Ya que no existe un único método correcto para desarollar un modelo de dominio, la naracción de dominio ofrece una alternativa digna de mención o, para un enfoque más completo de DDD, complementar con Event Storming, que es otra técnica que utilizamos a menudo para empezar con DDD.

Al desarrollar aplicaciones LLM basadas en generación mejorada por recuperación (RAG por sus siglas en inglés), la calidad de los embeddings impacta directamente tanto en la recuperación de documentos relevantes como en la calidad de las respuestas. Aplicar fine-tuning a embeddings puede mejorar la precisión y relevancia de los embeddings para tareas o dominios específicos. Nuestros equipos hicieron fine-tuning a los embeddings al desarrollar aplicaciones LLM de dominios específicos, donde la extracción de información precisa es crucial. Sin embargo, hay que considerar las ventajas y desventajas de este enfoque antes de apresurarse a afinarlos.

Llamada a funciones con LLMs se refiere a la capacidad de integrar los LLMs con funciones, APIs o herramientas externas; esto se logra identificando e invocando la función adecuada basada en una consulta dada y en la documentación asociada. Esta capacidad extiende la utilidad de los LLMs más allá de la generación de texto, permitiéndoles realizar tareas específicas como la recuperación de información, la ejecución de código y la interacción con APIs. Al invocar funciones externas o APIs, los LLMs pueden realizar acciones que antes estaban fuera de sus capacidades individuales. Esta técnica permite a los LLMs actuar sobre sus propios resultados, cerrando así la brecha entre el pensamiento y la acción, de manera similar a cómo los humanos usan herramientas para completar diversas tareas. Con la introducción de la llamada a funciones, los LLMs añaden determinismo y veracidad al proceso de generación, logrando un equilibrio entre creatividad y lógica. Este método permite a los LLMs conectarse a sistemas internos y bases de datos o incluso realizar búsquedas en internet a través de navegadores conectados. Modelos como la serie GPT de OpenAI admiten la llamada a funciones, y modelos perfeccionados como Gorilla están específicamente diseñados para mejorar la precisión y consistencia en la generación de llamadas a APIs ejecutables a partir de instrucciones en lenguaje natural. Como técnica, la llamada a funciones se sitúa dentro de la generación mejorada por recuperación (RAG) y arquitecturas de agentes. Debería verse como un patrón abstracto de uso, destacando su potencial como una herramienta fundamental en diversas implementaciones, más que como una solución específica.

Varios sistemas que construimos comparten dos importantes características: ser capaces de responder una pregunta acerca de un conjunto de datos extenso y ser casi imposible de saber cómo se ha llegado a la solución. A pesar de esta opacidad nosotros aun queremos evaluar y mejorar la calidad de las respuestas. Con el patrón LLM como juez , nosotros usamos LLM para evaluar la respuesta de otro sistema, que a su vez podría estar basado en un LLM. Hemos visto este patrón ser usado para determinar la relevancia de los resultados de búsqueda en un catálogo de productos y evaluar si un chatbot basado en LLM estaba guiando a los usuarios en una dirección sensata. Naturalmente, el sistema evaluador debe estar configurado y calibrado de manera cuidadosa. Puede generar ganancias significativas en eficiencia, lo que, a su vez, se traduce en costos más bajos. Esta es una área de investigación en curso, con un estado actualizado y resumido en este artículo.

Impulsadas por la alianza FIDO y respaldadas por Apple, Google y Microsoft, las passkeys están cerca de alcanzar un nivel de usabilidad masivo. Al configurar un nuevo inicio de sesión con llaves de acceso, se generan un par de claves: el sitio web recibe la clave pública y el usuario mantiene la clave privada. El proceso del inicio de sesión utiliza criptografía asimétrica. El usuario demuestra que está en posesión de la clave privada, que se almacena en el dispositivo del usuario y nunca se envía al sitio web. El acceso a las llaves está protegido mediante biometría o un PIN. Las llaves de acceso pueden almacenarse y sincronizarse en los ecosistemas de las grandes tecnológicas, utilizando iCloud Keychain de Apple, Google Password Manager o Windows Hello. Para usuarios multiplataforma, el Client to Authenticator Protocol (CTAP) permite que las llaves de acceso se guarden en un dispositivo diferente al que crea la clave o la necesita para el inicio de sesión. La objeción más común al uso de las passkeys es que representan un desafío para los usuarios con menos conocimientos técnicos, lo cual creemos que es una visión contraproducente. Estos suelen ser los mismos usuarios que tienen una gestión deficiente de las contraseñas y, por lo tanto, serían los más beneficiados por métodos alternativos. En la práctica, los sistemas que usan llaves de acceso pueden recurrir a métodos de autenticación tradicionales si es necesario.

Los modelos de lenguaje de gran tamaño (LLM) han demostrado su utilidad en muchas áreas de aplicación, pero el hecho de que sean grandes puede ser una fuente de problemas: responder a una consulta requiere muchos recursos de cómputo, lo que hace que las consultas sean lentas y caras; los modelos son propietarios y tan grandes que deben ser alojados en una nube por un tercero, lo que puede ser problemático para los datos sensibles; y entrenar un modelo es excesivamente caro en la mayoría de los casos. El último problema puede resolverse con el patrón RAG, que evita la necesidad de entrenar y afinar los modelos básicos, pero los problemas de costo y privacidad suelen persistir. Por ello, cada vez hay más interés en los modelos de lenguaje pequeños (SLM). En comparación con sus hermanos más populares, tienen menos pesos y menos precisión, normalmente entre 3,5 y 10B parámetros. Investigaciones recientes sugieren que, en el contexto adecuado y si se configuran correctamente, los SLM pueden rendir o incluso superar a los LLM. Y su tamaño permite ejecutarlos en dispositivos periféricos. Ya hemos mencionado el Gemini Nano de Google, pero el panorama está evolucionando rápidamente, con Microsoft presentando su serie Phi-3, por ejemplo.

La creación de sets de datos sintéticos implica generar datos artificiales que puedan imitar escenarios del mundo real sin depender de fuentes de datos sensibles o de acceso limitado. Aunque los datos sintéticos para sets de datos estructurados se han explorado ampliamente (por ejemplo, para pruebas de rendimiento o entornos seguros para la privacidad), estamos viendo un uso renovado de los datos sintéticos para datos no estructurados. A menudo, las empresas se enfrentan a la falta de datos etiquetados específicos del dominio, especialmente para su uso en el entrenamiento o el ajuste de los LLM. Herramientas como Bonito y Microsoft's AgentInstruct pueden generar datos sintéticos de ajuste de instrucciones a partir de fuentes crudas como documentos de texto y archivos de código. Esto ayuda a acelerar el entrenamiento del modelo al tiempo que reduce los costes y la dependencia de la curación manual de datos. Otro caso de uso importante es la generación de datos sintéticos para tratar datos desequilibrados o dispersos, algo habitual en tareas como la detección de fraudes o la segmentación de clientes. Técnicas como SMOTE ayudan a equilibrar conjuntos de datos creando artificialmente instancias de clases minoritarias. Del mismo modo, en sectores como el financiero, las redes generativas adversariales (GAN) se utilizan para simular transacciones poco frecuentes, lo que permite que los modelos sean robustos a la hora de detectar casos extremos y mejorar el rendimiento general.

La IA Generativa (GenAI) y los modelos de lenguaje de gran tamaño (LLMs) pueden ayudar a los desarrolladores a escribir código y entenderlo. Esta ayuda es especialmente útil en el caso de bases de código heredado con documentación deficiente, incompleta y/o desactualizada. Desde nuestra última actualización sobre este tema, las técnicas y herramientas sobre el usar GenAI para entender las bases de código heredado han evolucionado significativamente. Hemos utilizado con éxito algunas de estas técnicas en la práctica, especialmente para apoyar esfuerzos de ingeniería inversa en la modernización de mainframes. Una técnica especialmente prometedora que hemos utilizado es un enfoque de generación aumentada por recuperación(RAG), en el cual la recuperación de información se realiza a partir de un grafo de conocimiento del código. Este grafo puede conservar información estructural sobre la base de código que va más allá de lo que un modelo de lenguaje de gran tamaño (LLM) podría extraer únicamente del código textual. Esto resulta particularmente útil en bases de código heredado que son menos autodescriptivas y cohesivas. Además, hay una oportunidad adicional para mejorar la comprensión del código, ya que el grafo puede enriquecerse aún más con documentación existente y generada por IA, dependencias externas, conocimientos del dominio de negocio o cualquier otro recurso disponible que facilite el trabajo de la IA.

AI coding assistance tools are mostly talked about in the context of assisting and enhancing an individual contributor's work. However, software delivery is and will remain team work, so you should be looking for ways to create AI team assistants that help create the 10x team, as opposed to a bunch of siloed AI-assisted 10x engineers. Fortunately, recent developments in the tools market are moving us closer to making this a reality. Unblocked is a platform that pulls together all of a team's knowledge sources and integrates them intelligently into team members' tools. And Atlassian's Rovo brings AI into the most widely used team collaboration platform, giving teams new types of search and access to their documentation, in addition to unlocking new ways of automation and software practice support with Rovo agents. While we wait for the market to further evolve in this space, we've been exploring the potential of AI for knowledge amplification and team practice support ourselves: We open-sourced our Haiven team assistant and started gathering learnings with AI assistance for noncoding tasks like requirements analysis.

Dynamic few-shot prompting builds upon few-shot prompting by dynamically including specific examples in the prompt to guide the model's responses. Adjusting the number and relevance of these examples optimizes context length and relevancy, thereby improving model efficiency and performance. Libraries like scikit-llm implement this technique using nearest neighbor search to fetch the most relevant examples aligned with the user query. This technique lets you make better use of the model’s limited context window and reduce token consumption. The open-source SQL generator vanna leverages dynamic few-shot prompting to enhance response accuracy.

GraphQL for data products is the technique of using GraphQL as an output port for data products for clients to consume the product. We've talked about GraphQL as an API protocol and how it enables developers to create a unified API layer that abstracts away the underlying data complexity, providing a more cohesive and manageable interface for clients. GraphQL for data products makes it seamless for consumers to discover the data format and relationships with GraphQL schema and use familiar client tools. Our teams are exploring this technique in specific use cases like talk-to-data to explore and discover big data insights with the help of large language models, where the GraphQL queries are constructed by LLMs based on the user prompt and the GraphQL schema is used in the LLM prompts for reference.

LLM-powered autonomous agents are evolving beyond single agents and static multi-agent systems with the emergence of frameworks like Autogen and CrewAI. This technique allows developers to break down a complex activity into several smaller tasks performed by agents where each agent is assigned a specific role. Developers can use preconfigured tools for performing the task, and the agents converse among themselves and orchestrate the flow. The technique is still in its early stages of development. In our experiments, our teams have encountered issues like agents going into continuous loops and uncontrolled behavior. Libraries like LangGraph offer greater control of agent interactions with the ability to define the flow as a graph. If you use this technique, we suggest implementing fail-safe mechanisms, including timeouts and human oversight.

Observability 2.0 represents a shift from traditional, disparate monitoring tools to a unified approach that leverages structured, high-cardinality event data in a single data store. This model captures rich, raw events with detailed metadata to provide a single source of truth for comprehensive analysis. By storing events in their raw form, it simplifies correlation and supports real-time and forensic analysis and enables deeper insights into complex, distributed systems. This approach allows for high-resolution monitoring and dynamic investigation capabilities. Observability 2.0 prioritizes capturing high-cardinality and high-dimensional data, allowing detailed examination without performance bottlenecks. The unified data store reduces complexity, offering a coherent view of system behavior, and aligning observability practices more closely with the software development lifecycle.

Large language models (LLMs) can now run in web browsers and on edge devices like smartphones and laptops, enabling on-device AI applications. This allows for secure handling of sensitive data without cloud transfer, extremely low latency for tasks like edge computing and real-time image or video processing, reduced costs by performing computations locally and functionality even when internet connectivity is unreliable or unavailable. This is an active area of research and development. Previously, we highlighted MLX, an open-source framework for efficient machine learning on Apple silicon. Other emerging tools include Transformers.js and Chatty. Transformers.js lets you run transformers in the browser using ONNX Runtime, supporting models converted from PyTorch, TensorFlow and JAX. Chatty leverages WebGPU to run LLMs natively and privately in the browser, offering a feature-rich in-browser AI experience.

Structured output from LLMs refers to the practice of constraining a language model's response into a defined schema. This can be achieved either through instructing a generalized model to respond in a particular format or by fine-tuning a model so it "natively" outputs, for example, JSON. OpenAI now supports structured output, allowing developers to supply a JSON Schema, pydantic or Zod object to constrain model responses. This capability is particularly valuable for enabling function calling, API interactions and external integrations, where accuracy and adherence to a format are critical. Structured output not only enhances the way LLMs can interface with code but also supports broader use cases like generating markup for rendering charts. Additionally, structured output has been shown to reduce the chance of hallucinations within model output.

AI coding assistants like GitHub Copilot and Tabnine have become very popular. According to StackOverflow's 2024 developer survey, "72% of all respondents are favorable or very favorable of AI tools for development". While we also see their benefits, we're wary about the medium- to long-term impact this will have on code quality and caution developers about complacency with AI-generated code. It’s all too tempting to be less vigilant when reviewing AI suggestions after a few positive experiences with an assistant. Studies like this one by GitClear show a trend of faster growing codebases, which we suspect coincide with larger pull requests. And this study by GitHub has us wondering whether the mentioned 15% increase of the pull request merge rate is actually a good thing or whether people are merging larger pull requests faster because they trust the AI results too much. We're still using the basic "getting started" advice we gave over a year ago, which is to beware of automation bias, sunk cost fallacy, anchoring bias and review fatigue. We also recommend that programmers develop a good mental framework about where and when not to use and trust AI.

Creating enterprise-wide integration test environments is a common, wasteful practice that slows everything down. These environments invariably become a precious resource that's hard to replicate and a bottleneck to development. They also provide a false sense of security due to inevitable discrepancies in data and configuration overhead between environments. Ironically, a common objection to the alternatives — either ephemeral environments or multiple on-prem test environments — is cost. However, this fails to take into account the cost of the delays caused by enterprise-wide integration test environments as development teams wait for other teams to finish or for new versions of dependent systems to be deployed. Instead, teams should use ephemeral environments and, preferably, a suite of tests owned by the development team that can be spun up and discarded cheaply, using fake stubs for their systems rather than actual replicas. For other techniques that support this alternative take a look at contract testing, decoupling deployment from release, focus on mean time to recovery and testing in production.

Rather than instituting blanket LLM bans in the workplace, organizations should focus on providing access to an approved set of AI tools. A ban only pushes employees to find unapproved and potentially unsafe workarounds, creating unnecessary risks. Much like the early days of personal computing, people will use whatever tools they feel are effective to get their work done, regardless of the barriers in place. By not providing a safe and endorsed alternative, companies risk employees using unapproved LLMs which come with intellectual property, data leakage and liability risks. Instead, offering secure, enterprise-approved LLMs or AI tools ensures both safety and productivity. A well-governed approach allows organizations to manage data privacy, security, compliance and cost concerns while still empowering employees with the capabilities that LLMs offer. In the best case, well-managed access to AI tools can accelerate organizational learning around the best ways to use AI in the workplace.

When people talk about coding assistants, the topic of pair programming inevitably comes up. Our profession has a love-hate relationship with it: some swear by it, others can't stand it. Coding assistants now beg the question, can a human pair with the AI, instead of another human, and get the same results for the team? GitHub Copilot even calls itself "your AI pair programmer." While we do think a coding assistant can bring some of the benefits of pair programming, we advise against fully replacing pair programming with AI. Framing coding assistants as pair programmers ignores one of the key benefits of pairing: to make the team, not just the individual contributors, better. Coding assistants can offer benefits for getting unstuck, learning about a new technology, onboarding or making tactical work faster so that we can focus on the strategic design. But they don't help with any of the team collaboration benefits, like keeping the work-in-progress low, reducing handoffs and relearning, making continuous integration possible or improving collective code ownership.