Techniques

For many years, we've used the canary release approach to encourage early feedback on new software versions, while reducing risk through incremental rollout to selected users. The 1% canary is a useful technique where we roll out new features to a very small segment (say 1%) of users carefully chosen across various user categories. This enables teams to capture fast user feedback, observe the impact of new releases on performance and stability and respond as necessary. This technique becomes especially crucial when teams are rolling out software updates to mobile applications or a fleet of devices like edge computing devices or software-defined vehicles. With proper observability and early feedback, it gives the opportunity to contain the blast radius in the event of unexpected scenarios in production. While canary releases can be useful to get faster user feedback, we believe starting with a small percentage of users is mandatory to reduce and contain the risk of large-scale feature rollouts.

Automated testing remains a cornerstone of effective software development. For front-end tests we can argue whether the distribution of different test types should be the classic test pyramid or whether it should be a trophy shape. In either case, though, teams should focus on component testing because test suites should be stable and run quickly. Instead, what we're seeing is that teams forgo mastering component testing in favor of end-to-end browser-based testing as well as very narrowly defined unit tests. Unit tests have a tendency to force components to expose what should be purely internal functionality, while browser-based tests are slow, more flaky and harder to debug. Our recommendation is to have a significant amount of component tests and use a library like jsdom to run the component tests in memory. Browser tools like Playwright of course still have a place in end-to-end tests, but they shouldn't be used for component testing.

We believe organizations should adopt continuous deployment practices whenever possible. Continuous deployment is the practice of automatically deploying every change that passes automated tests to production. This practice is a key enabler of fast feedback loops and allows organizations to deliver value to customers more quickly and efficiently. Continuous delivery differs from continuous deployment in that it only requires that code can be deployed at any time; it doesn't require that every change actually is deployed to production. We've hesitated to move continuous deployment into the Adopt ring in the past, as it’s a practice that requires a high level of maturity in other areas of software delivery and is therefore not appropriate for all teams. However, Thoughtworker Valentina Servile’s recent book Continuous Deployment provides a comprehensive guide to implementing the practice in an organization. It offers a roadmap for organizations to follow in order to achieve the level of maturity required to adopt continuous deployment practices.

Retrieval-augmented generation (RAG) is the preferred pattern for our teams to improve the quality of responses generated by a large language model (LLM). We’ve successfully used it in many projects, including the Jugalbandi AI platform. With RAG, information about relevant and trustworthy documents is stored in a database. For a given prompt, the database is queried, relevant documents are retrieved and the prompt augmented with the content of the documents, thus providing richer context to the LLM. This results in higher quality output and greatly reduced hallucinations. The context window — which determines the maximum size of the LLM input — has grown significantly with newer models, but selecting the most relevant documents is still a crucial step. Our experience indicates that a carefully constructed smaller context can yield better results than a broad and large context. Using a large context is also slower and more expensive. We used to rely solely on embeddings stored in a vector database to identify additional context. Now, we're seeing reranking and hybrid search: search tools such as Elasticsearch Relevance Engine as well as approaches like GraphRAG that utilize knowledge graphs created with the help of an LLM. A graph-based approach has worked particularly well in our work on understanding legacy codebases with GenAI.

Domain-driven design (DDD) has become a foundational approach to the way we develop software. We use it to model events, to guide software designs, to establish context boundaries around microservices and to elaborate nuanced business requirements. DDD establishes a ubiquitous language that both nontechnical stakeholders and software developers can use to communicate effectively about the business. Once established, domain models evolve, but many teams find it hard to get started with DDD. There’s no one-size-fits-all approach to building an initial domain model. One promising technique we've encountered recently is domain storytelling. Domain storytelling is a facilitation technique where business experts are prompted to describe activities in the business. As the experts are guided through their narration, a facilitator uses a pictographic language to capture the relationships and actions between entities and actors. The process of making these stories visible helps to clarify and develop a shared understanding among participants. Since there is no single best approach to developing a domain model, domain storytelling offers a noteworthy alternative or, for a more comprehensive approach to DDD, companion to Event Storming, another technique we often use to get started with DDD.

When building LLM applications based on retrieval-augmented generation (RAG), the quality of embeddings directly impacts both retrieval of the relevant documents and response quality. Fine-tuning embedding models can enhance the accuracy and relevance of embeddings for specific tasks or domains. Our teams fine-tuned embeddings when developing domain-specific LLM applications for which precise information extraction was crucial. However, consider the trade-offs of this approach before you rush to fine-tune your embedding model.

Function calling with LLMs refers to the ability to integrate LLMs with external functions, APIs or tools by determining and invoking the appropriate function based on a given query and associated documentation. This extends the utility of LLMs beyond text generation, allowing them to perform specific tasks such as information retrieval, code execution and API interaction. By triggering external functions or APIs, LLMs can perform actions that were previously outside their standalone capabilities. This technique enables LLMs to act on their outputs, effectively bridging the gap between thought and action — similar to how humans use tools to accomplish various tasks. By introducing function calling, LLMs add determinism and factuality to the generation process, striking a balance between creativity and logic. This method allows LLMs to connect to internal systems and databases or even perform internet searches via connected browsers. Models like OpenAI's GPT series support function calling and fine-tuned models like Gorilla are specifically designed to enhance the accuracy and consistency of generating executable API calls from natural language instructions. As a technique, function calling fits within retrieval-augmented generation (RAG) and agent architectures. It should be viewed as an abstract pattern of use, emphasizing its potential as a foundational tool in diverse implementations rather than a specific solution.

Many systems we build have two key characteristics: being able to provide an answer based on questions about a large data set, and being next to impossible to follow how it arrived at that answer. Despite this opacity we still want to assess and improve the quality of the responses. With the LLM as a judge pattern we use an LLM to evaluate the responses of another system, which in turn might be based on an LLM. We've seen this pattern used to evaluate the relevance of search results in a product catalog and to assess whether an LLM-based chatbot was guiding its users in a sensible direction. Naturally, the evaluator system must be set up and calibrated carefully. It can drive significant efficiency gains, which, in turn, translates to lower costs. This is an ongoing area of research, with the current state summarized in this article.

Shepherded by the FIDO alliance and backed by Apple, Google and Microsoft, passkeys are nearing mainstream usability. Setting up a new login with passkeys generates a key pair: the website receives the public key and the user keeps the private key. Handling login uses asymmetric cryptography. The user proves they're in possession of the private key, which is stored on the user’s device and never sent to the website. Access to passkeys is protected using biometrics or a PIN. Passkeys can be stored and synced within the big tech ecosystems, using Apple's iCloud Keychain, Google Password Manager or Windows Hello. For multiplatform users, the Client to Authenticator Protocol (CTAP) makes it possible for passkeys to be kept on a different device other than the one that creates the key or needs it for login. The most common objection to using passkeys claims that they are a challenge for less tech-savvy users, which is, we believe, self-defeating. These are often the same users who have poor password discipline and would therefore benefit the most from alternative methods. In practice, systems that use passkeys can fall back to more traditional authentication methods if required.

Large language models (LLMs) have proven useful in many areas of applications, but the fact that they are large can be a source of problems: responding to a prompt requires a lot of compute resources, making queries slow and expensive; the models are proprietary and so large that they must be hosted in a cloud by a third party, which can be problematic for sensitive data; and training a model is prohibitively expensive in most cases. The last issue can be addressed with the RAG pattern, which side-steps the need to train and fine-tune foundational models, but cost and privacy concerns often remain. In response, we’re now seeing growing interest in small language models (SLMs). In comparison to their more popular siblings, they have fewer weights and less precision, usually between 3.5 billion and 10 billion parameters. Recent research suggests that, in the right context, when set up correctly, SLMs can perform as well as or even outperform LLMs. And their size makes it possible to run them on edge devices. We've previously mentioned Google's Gemini Nano, but the landscape is evolving quickly, with Microsoft introducing its Phi-3 series, for example.

Synthetic data set creation involves generating artificial data that can mimic real-world scenarios without relying on sensitive or limited-access data sources. While synthetic data for structured data sets has been explored extensively (e.g., for performance testing or privacy-safe environments), we're seeing renewed use of synthetic data for unstructured data. Enterprises often struggle with a lack of labeled domain-specific data, especially for use in training or fine-tuning LLMs. Tools like Bonito and Microsoft's AgentInstruct can generate synthetic instruction-tuning data from raw sources such as text documents and code files. This helps accelerate model training while reducing costs and dependency on manual data curation. Another important use case is generating synthetic data to address imbalanced or sparse data, which is common in tasks like fraud detection or customer segmentation. Techniques such as SMOTE help balance data sets by artificially creating minority class instances. Similarly, in industries like finance, generative adversarial networks (GANs) are used to simulate rare transactions, allowing models to be robust in detecting edge cases and improving overall performance.

Generative AI (GenAI) and large language models (LLMs) can help developers write and understand code. Help with understanding code is especially useful in the case of legacy codebases with poor, out-of-date or misleading documentation. Since we last wrote about this, techniques and products for using GenAI to understand legacy codebases have further evolved, and we've successfully used some of them in practice, notably to assist reverse engineering efforts for mainframe modernization. A particularly promising technique we've used is a retrieval-augmented generation (RAG) approach where the information retrieval is done on a knowledge graph of the codebase. The knowledge graph can preserve structural information about the codebase beyond what an LLM could derive from the textual code alone. This is particularly helpful in legacy codebases that are less self-descriptive and cohesive. An additional opportunity to improve code understanding is that the graph can be further enriched with existing and AI-generated documentation, external dependencies, business domain knowledge or whatever else is available that can make the AI's job easier.

Las herramientas de asistencia de codificación de IA se mencionan principalmente en el contexto de la asistencia y la mejora del trabajo de un colaborador individual. Sin embargo, la entrega de software es y seguirá siendo un trabajo en equipo, por lo que se debería buscar formas de crear asistentes de IA para equipos que ayuden a crear el equipo 10x, en lugar de un grupo aislado de ingenieros 10x asistidos por IA. Afortunadamente, los recientes desarrollos en el mercado de herramientas nos acercan a hacer de esto una realidad. Unblocked es una plataforma que reúne todas las fuentes de conocimiento de un equipo y las integra de forma inteligente en las herramientas de los miembros del equipo. Rovo de Atlassian incorpora la IA a la plataforma más utilizada de colaboración en equipo, brindando a los equipos nuevos tipos de búsqueda y acceso a su documentación, además de desbloquear nuevas formas de automatización y soporte a prácticas de software con agentes Rovo. Mientras esperamos que el mercado siga evolucionando en este ámbito, hemos estado explorando el potencial de la IA para la amplificación del conocimiento y el soporte a las prácticas de equipo: abrimos nuestro asistente de equipo Haiven y comenzó a recopilar aprendizajes con asistencia de IA para tareas no asociadas a la programación, como el análisis de requerimientos.

El prompting dinámico con pocas muestras se basa en el prompting con pocas muestras, incluyendo de forma dinámica ejemplos específicos en la instrucción (prompt) para guiar las respuestas del modelo. Ajustar el número y relevancia de estos ejemplos optimiza la extensión del contexto y su relevancia, mejorando así la eficiencia y el rendimiento del modelo. Hay librerías de código, como scikit-llm, que implementan esta técnica usando la búsqueda del vecino más cercano para encontrar los ejemplos más relevantes de acuerdo con la consulta del usuario. Esta técnica permite hacer un mejor uso del limitado marco contextual del modelo y reducir el consumo de tokens. El generador de código SQL de código libre vanna utiliza prompting dinámico con pocas muestras para mejorar la precisión de sus resultados.

GraphQL para productos de datos es la técnica de usar GraphQL como un punto de acceso para los productos de datos para que clientes consuman el producto. Hemos hablado acerca de GraphQL como un protocolo de API y cómo permite a desarrolladores crear una capa unificada de API que abstrae la complejidad de los datos subyacentes, entregando una interfaz más cohesionada y manejable a los clientes. GraphQL para productos de datos facilita a los consumidores la tarea de descubrir el formato y relaciones de los datos con el esquema de GraphQL y usar herramientas de cliente familiares para GraphQL. Nuestros equipos están explorando esta técnica en casos de uso específicos como talk-to-data para explorar y descubrir insights de big data con la ayuda de grandes modelos de lenguaje (LLMs por sus siglas en inglés) donde las consultas de GraphQL están construidas por LLMs basadas en los prompts del usuario y el esquema de GraphQL es usado en los prompts de la LLM como referencia.

Los agentes autónomos impulsados por modelos de lenguaje a gran escala (LLM) están evolucionando más allá de agentes individuales y sistemas multiagente estáticos con la aparición de frameworks como Autogen y CrewAI. Esta técnica permite a los desarrolladores descomponer una actividad compleja en varias tareas más pequeñas, realizadas por agentes a los que se les asigna un rol específico. Los desarrolladores pueden utilizar herramientas preconfiguradas para ejecutar las tareas, mientras que los agentes se comunican entre sí y orquestan el flujo de trabajo. La técnica aún se encuentra en sus primeras etapas de desarrollo. En nuestros experimentos hasta ahora, nuestros equipos han encontrado problemas como agentes que entran en bucles continuos y comportamientos descontrolados. Librerías como LangGraph ofrecen un mayor control sobre las interacciones de los agentes, permitiendo definir el flujo como un gráfico. Si decides utilizar esta técnica, sugerimos implementar mecanismos a prueba de fallos, como límites de tiempo y supervisión humana.

Observabilidad 2.0 representa un cambio de las herramientas de monitoreo tradicionales y dispersas hacia un enfoque unificado que aprovecha datos estructurados y de alta cardinalidad de eventos en un único repositorio de datos. Este modelo captura eventos enriquecidos y sin procesar con metadatos detallados para proporcionar una fuente de verdad única para un análisis exhaustivo. Al almacenar los eventos en su forma cruda, simplifica la correlación y soporta el análisis forense y en tiempo real, permitiendo obtener una visión más profunda sobre sistemas distribuidos complejos. Este enfoque permite un monitoreo de alta resolución y capacidades de investigación dinámicas. Observabilidad 2.0 da prioridad a la captura de datos con alta cardinalidad y alta dimensión, permitiendo un análisis detallado sin cuellos de botella de rendimiento. El repositorio de datos unificado reduce la complejidad, ofreciendo una visión coherente del comportamiento del sistema y alineando las prácticas de observabilidad más estrechamente con el ciclo de vida del desarrollo de software.

Los modelos de lenguaje de gran tamaño o LLMs (siglas en inglés para Large Language Model) ahora son capaces de correr en navegadores web y dispositivos de usuario final, como teléfonos inteligentes y computadores portátiles, permitiendo que aplicaciones de AI se ejecuten en el dispositivo. Esto permite el manejo seguro de datos sensibles sin necesidad de transferir datos hacia la nube, muy baja latencia en tareas como edge computing y procesamiento de imagen o video en tiempo real, costos reducidos al realizar cómputos localmente y mantener funcionalidad incluso cuando no se cuenta con una conexión estable a internet. Ésta es un área de continua investigación y desarrollo. En ediciones pasadas mencionamos MLX, un framework de código abierto para machine learning eficiente en procesadores Apple silicon. Otras herramientas que están emergiendo incluyen Transformers.js y Chatty. Transformers.js nos permite correr Transformers en el navegador usando el ONNX Runtime, soportando modelos convertidos desdecomo PyTorch, TensorFlow y JAX. Chatty se apalanca en WebGPU para correr LLMs de forma nativa y privada en el navegador, ofreciendo una experiencia de AI enriquecida dentro del mismo.

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.

Los asistentes de código con IA como GitHub Copilot y Tabnine se han hecho muy populares. Según la encuesta para desarrolladores de StackOverflow de 2024, “el 72% de todos los encuestados están a favor o muy a favor de las herramientas con IA para el desarrollo”. Aunque también vemos sus ventajas, desconfiamos del impacto a medio y largo plazo que esto tendrá en la calidad del código y advertimos a los desarrolladores sobre la complacencia con el código generado por IA. Tras unas cuantas experiencias positivas con un asistente, resulta demasiado tentador ser permisivos al revisar las sugerencias de la IA. Estudios como éste, de GitClear, muestran una tendencia a un crecimiento más rápido de las bases de código, que sospechamos coincide con un mayor número de pull requests. Y este estudio de GitHub nos hace preguntarnos si el mencionado aumento del 15% de la tasa de fusión de pull requests es realmente algo bueno o si la gente está fusionando pull requests más grandes más rápido porque confían demasiado en los resultados de la IA. Seguimos utilizando los consejos básicos “para empezar” que dimos hace más de un año, que consisten en tener cuidado con el sesgo de automatización, la falacia del costo hundido, el sesgo de anclaje y la fatiga de revisión. También recomendamos que los programadores desarrollen un buen framework mental sobre dónde y cuándo no utilizar o confiar en la IA.

Crear entornos de pruebas de integración para toda la empresa es una práctica frecuente y costosa que lo ralentiza todo. Estos entornos invariablemente se convierten en recursos valiosos que son difíciles de replicar y un cuello de botella para el desarrollo. También proveen de una falsa sensación de seguridad por sus inevitables discrepancias en los datos y configuraciones entre entornos. Irónicamente, la objeción habitual a sus alternativas — ya sean entornos efímeros o múltiples entornos de prueba locales — es su costo. Sin embargo, no se considera el costo de los retrasos causados por los entornos de integración para toda la empresa, como tener equipos de desarrollo en espera de que otros equipos terminen, o a los despliegues de nuevas versiones de sistemas dependientes. En su lugar, los equipos deberían usar entornos efímeros y, preferiblemente, un conjunto de pruebas propias del equipo de desarrollo que puedan ser ejecutadas y descartadas a bajo costo, usando stubs para sus sistemas en vez de réplicas reales. Para otras técnicas que soportan esta alternativa echa un vistazo a pruebas de contrato guiados por el consumidor, desacoplar el despliegue de la publicación, centrarse en el tiempo medio de recuperación y pruebas en producción.

En lugar de imponer prohibiciones al uso de LLMs en el lugar de trabajo, las organizaciones deberían enfocarse en proveer acceso a un conjunto de herramientas de IA aprobadas. Una prohibición sólo empuja a los empleados a encontrar soluciones alternativas no aprobadas y potencialmente inseguras, creando riesgos innecesarios. Como en los días primarios de la computadora personal, la gente va a utilizar cualquier herramienta que sienta efectiva para hacer su trabajo, a pesar de las barreras impuestas. Al no proveer una alternativa segura y respaldada, las compañías corren el riesgo de que los empleados utilicen LLM no aprobados que vienen acompañados de riesgos de propiedad intelectual, fuga de datos y responsabilidad. Por otro lado, ofrecer LLMs o herramientas de IA seguras y aprobadas por la empresa, garantiza la seguridad y productividad. Un enfoque bien gobernado permite a las organizaciones manejar sus inquietudes sobre privacidad de datos, seguridad, cumplimiento y costos, al mismo tiempo que empodera a los empleados con las capacidades que los LLMs ofrecen. En el mejor de los casos, un acceso bien manejado a herramientas IA puede acelerar el aprendizaje organizacional acerca de las mejores maneras de usar IA para el trabajo.

Cuando se habla de codificación en pares, inevitablemente surge el tema de pair programming. 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 reemplazar la programación en parejas por la IA. 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.