Técnicas

Por muitos anos, temos usado a abordagem de implantação canário para incentivar o feedback inicial sobre novas versões de software, ao mesmo tempo em que reduzimos o risco por meio da implementação incremental para usuárias selecionadas. O 1% canary é uma técnica útil em que lançamos novos recursos para um segmento muito pequeno (digamos 1%) de usuárias cuidadosamente escolhidas dentre várias categorias. Isso permite que as equipes capturem feedback rápido da usuária e observem o impacto dos novos lançamentos em categorias como desempenho e estabilidade, aprendendo e respondendo conforme necessário. Essa técnica se torna especialmente crucial quando as equipes estão lançando atualizações de software para aplicativos móveis ou uma frota de dispositivos como os de computação de ponta ou veículos definidos por software. Com observabilidade adequada e feedback precoce, ela oferece a oportunidade de conter o raio de impacto em caso de cenários inesperados em produção. Embora a implantação canário possa ser útil para obter feedback mais rápido de usuárias, acreditamos que começar com uma pequena porcentagem de usuárias também é obrigatório para reduzir e conter o risco de lançamentos de funcionalidades em grande escala.

O teste automatizado continua sendo a base do desenvolvimento de software eficaz. Para testes de front-end, podemos discutir se a distribuição de diferentes tipos de teste deve ser a pirâmide de teste clássica ou se deve ter o formato de um troféu. Em ambos os casos, porém, as equipes devem se concentrar em testes de componentes , pois os conjuntos de testes devem ser estáveis e executados rapidamente. Em vez disso, o que estamos notando é que as equipes abrem mão de dominar os testes de componentes, em favor de testes ponta a ponta baseados em navegador, bem como testes unitários definidos de forma muito restrita. Os testes unitários tendem a forçar os componentes a expor o que deveria ser uma funcionalidade puramente interna, enquanto os testes baseados em navegador são lentos, mais instáveis e mais difíceis de depurar. Nossa recomendação é ter uma quantidade significativa de testes de componentes e usar uma biblioteca como jsdom para executar os testes de componentes na memória. Ferramentas de navegador como Playwright ainda têm um lugar em testes ponta a ponta, mas não devem ser usadas para testes de componentes.

Acreditamos que as organizações devem adotar práticas de implantação contínua sempre que possível. Implantação contínua é a prática de implantar automaticamente em produção todas as mudanças que passam nos testes automatizados. Essa prática é um facilitador chave para ciclos de feedback rápidos e permite que as organizações entreguem valor às clientes de forma mais rápida e eficiente. A entrega contínua difere da implantação contínua no sentido de que apenas requer que o código possa ser implantado a qualquer momento, já que não exige que cada mudança realmente seja implantada em produção. Hesitamos em mover a implantação contínua para o anel de Adoção no passado, pois é uma prática que requer um alto nível de maturidade em outras áreas de entrega de software e, portanto, não é apropriada para todas as equipes. No entanto, o recente livro da Thoughtworker Valentina Servile, Continuous Deployment, fornece um guia abrangente para implementar a prática em uma organização. Ele oferece um roteiro para as organizações seguirem a fim de alcançar o nível de maturidade necessário para adotar práticas de implantação contínua.

Geração aumentada por recuperação (RAG) é o padrão preferido por nossas equipes para melhorar a qualidade das respostas geradas por um modelo de linguagem de grande porte (LLM). Nós a usamos com sucesso em muitos projetos, incluindo a plataforma Jugalbandi AI. Com RAG, informações sobre documentos relevantes e confiáveis são armazenadas em um banco de dados. Para um determinado prompt, o banco de dados é consultado, documentos relevantes são recuperados, e o prompt é aumentado com o conteúdo dos documentos, fornecendo assim um contexto mais rico ao LLM. Isso resulta em uma saída de maior qualidade e alucinações drasticamente reduzidas. A janela de contexto — que determina o tamanho máximo da entrada do LLM — cresceu significativamente com os modelos mais recentes, mas selecionar os documentos mais relevantes ainda é uma etapa crucial. Nossa experiência indica que um contexto menor cuidadosamente construído pode produzir melhores resultados do que um contexto amplo e grande. Usar um contexto grande também é mais lento e mais caro. Costumávamos confiar apenas em embeddings armazenados em um banco de dados vetorial para identificar contexto adicional. Agora, estamos vendo reclassificação e busca híbrida: ferramentas de busca como Elasticsearch Relevance Engine, bem como abordagens como GraphRAG que utilizam grafos de conhecimento criados com a ajuda de um LLM. Uma abordagem baseada em grafos funcionou particularmente bem em nosso trabalho de compreensão de bases de código legadas com GenAI.

O design orientado a domínio (DDD) se tornou uma abordagem fundamental na forma como desenvolvemos software. Nós o utilizamos para modelar eventos, orientar designs de software, estabelecer limites de contexto em torno de microsserviços e elaborar requisitos de negócios detalhados. O DDD estabelece uma linguagem ubíqua que tanto as stakeholders não técnicas quanto as pessoas desenvolvedoras de software podem usar para se comunicar de forma eficaz sobre o negócio. Uma vez estabelecidos, os modelos de domínio evoluem, mas muitas equipes acham difícil começar com o DDD. Não há uma abordagem única para construir um modelo de domínio inicial. Uma técnica promissora que encontramos recentemente é a narrativa de domínio. Ela é uma técnica de facilitação na qual especialistas do negócio são incentivados a descrever atividades do negócio. À medida que as especialistas são guiadas em sua narrativa, uma facilitadora utiliza uma linguagem pictográfica para capturar as relações e ações entre entidades e atores. O processo de tornar essas histórias visíveis ajuda a esclarecer e desenvolver um entendimento compartilhado entre as participantes. Como não há uma única abordagem ideal para desenvolver um modelo de domínio, a narrativa de domínio oferece uma alternativa notável ou, para uma abordagem mais abrangente ao DDD, pode ser um complemento ao Event Storming, outra técnica que frequentemente usamos para começar com o DDD.

Ao construir aplicações de LLM baseadas em geração aumentada por recuperação (RAG), a qualidade dos embeddings impacta diretamente tanto na recuperação dos documentos relevantes quanto na qualidade da resposta. O fine-tuning em modelos de embedding pode aumentar a precisão e a relevância dos embeddings para tarefas ou domínios específicos. Nossas equipes realizaram ajustes finos dos embeddings ao desenvolver aplicações de LLM específicas para domínios onde a extração de informações precisas era crucial. No entanto, considere os contrapontos dessa abordagem antes de se apressar para ajustar seu modelo de embedding.

A chamada de função com LLMs refere-se à capacidade de integrar LLMs com funções externas, APIs ou ferramentas, determinando e invocando a função apropriada com base em uma determinada consulta e na documentação associada. Isso amplia a utilidade dos LLMs para além da geração de texto, permitindo que eles executem tarefas específicas, como recuperação de informações, execução de código e interação com APIs. Ao acionar funções externas ou APIs, os LLMs podem executar ações que antes estavam fora de seus recursos autônomos. Essa técnica permite que os LLMs atuem em seus resultados, preenchendo efetivamente a lacuna entre o pensamento e a ação, de forma muito semelhante à maneira como as pessoas usam ferramentas para realizar várias tarefas. Ao introduzir a chamada de função, os LLMs acrescentam determinismo e factualidade ao processo de geração, atingindo um equilíbrio entre criatividade e lógica. Esse método permite que os LLMs se conectem a sistemas e bancos de dados internos ou até mesmo realizem pesquisas na Internet por meio de navegadores conectados. Modelos como a série GPT da OpenAI suportam chamadas de função e modelos refinados, como o Gorilla, são projetados especificamente para aprimorar a precisão e a consistência da geração de chamadas de API executáveis a partir de instruções de linguagem natural. Como técnica, a chamada de função se encaixa na geração aumentada por recuperação (RAG) e nas arquiteturas de agentes. Ela deve ser vista como um padrão abstrato de uso, enfatizando seu potencial como uma ferramenta fundamental em diversas implementações, em vez de uma solução específica.

Muitos sistemas que construímos possuem duas características principais: serem capazes de prover uma resposta baseada em questões sobre um grande conjunto de dados e quase impossíveis de acompanhar como chegaram a essa resposta. Apesar desta opacidade, nós ainda queremos avaliar e melhorar a qualidade das respostas. Com o padrão de LLM como juíz, usamos uma LLM para avaliar as respostas de outros sistemas, que por sua vez pode ser baseado em um LLM. Notamos esse padrão ser utilizado para avaliar a relevância dos resultados de pesquisa em um catálogo de produtos e para avaliar quando um chatbot baseado em LLM guiou suas usuárias em uma direção sensata. Naturalmente, o sistema avaliador deve ser configurado e calibrado cuidadosamente. Isto pode gerar ganhos significativos, o que, por sua vez, se traduz em custos menores. Esta é uma área de pesquisa em andamento, tendo seu estado atual resumido neste artigo.

Orientadas pela aliança FIDO e apoiadas pela Apple, Google e Microsoft, as passkeys estão se aproximando da usabilidade convencional. A configuração de um novo login com passkeys gera um par de chaves: o site recebe a chave pública e a usuária fica com a chave privada. O processamento do login usa criptografia assimétrica. A usuária prova que está de posse da chave privada, que é armazenada no dispositivo da usuária e nunca é enviada ao site. O acesso às senhas é protegido por meio de biometria ou de um PIN. As chaves de acesso podem ser armazenadas e sincronizadas dentro dos grandes ecossistemas de tecnologia, usando o iCloud Keychain da Apple, o Password Manager do Google ou o Windows Hello. Para usuárias de várias plataformas, o Client to Authenticator Protocol (CTAP) possibilita que as senhas sejam mantidas em um dispositivo diferente daquele que cria a chave ou que precisa dela para o login. A objeção mais comum ao uso de chaves de acesso alega que elas são um desafio para as usuárias menos experientes em tecnologia, o que acreditamos ser contraditório. Em geral, essas são as mesmas usuárias que têm pouca disciplina com senhas e que, portanto, se beneficiam mais com métodos alternativos. Na prática, os sistemas que usam passkeys podem recorrer a métodos de autenticação mais tradicionais, se necessário.

Modelos de linguagem de grande porte (LLMs) têm se provado muito úteis em várias áreas de aplicação, mas o fato de serem grandes pode ser uma fonte de problemas: responder a um prompt requer grandes recursos computacionais, tornando as consultas lentas e caras; os modelos são proprietários e tão grandes que eles devem ser hospedados em uma nuvem por um terceiro, o que pode ser problemático quanto a dados sensíveis; e treinar um modelo é proibitivamente caro na maioria dos casos. Esse último problema pode ser resolvido com o padrão RAG, que contorna a necessidade de treinar e otimizar modelos fundamentais, mas preocupações quanto ao custo e a privacidade geralmente persistem. Em resposta, temos identificado um crescente interesse em modelos de linguagem de pequeno porte (SLMs). Em comparação ao seu irmão mais popular, eles têm menos peso e menor precisão, geralmente entre 3,5 e 10B de parâmetros. Pesquisas recentes sugerem que, no contexto correto, quando configurados corretamente, SLMs podem performar ou até mesmo superar os LLMs. E seu tamanho torna possível rodá-los em dispositivos de borda. Nós mencionamos anteriormente o Gemini Nano da Google, mas o cenário está evoluindo rapidamente, com a Microsoft introduzindo a série Phi-3, por exemplo.

A criação de conjuntos de dados sintéticos envolve a geração de dados artificiais que podem imitar cenários do mundo real sem depender de fontes de dados sensíveis ou de acesso limitado. Embora os dados sintéticos para conjuntos de dados estruturados tenham sido explorados extensivamente (por exemplo, para testes de desempenho ou ambientes seguros em termos de privacidade), estamos notando um uso renovado de dados sintéticos para dados não estruturados. As empresas frequentemente enfrentam dificuldades com a falta de dados rotulados específicos do domínio, especialmente para uso no treinamento ou ajuste fino de LLMs. Ferramentas como Bonito e Microsoft's AgentInstruct podem gerar dados sintéticos de ajuste de instrução a partir de fontes brutas, como documentos de texto e arquivos de código. Isso ajuda a acelerar o treinamento do modelo, reduzindo custos e a dependência da curadoria manual de dados. Outro caso de uso importante é a geração de dados sintéticos para abordar dados desbalanceados ou esparsos, o que é comum em tarefas como detecção de fraudes ou segmentação de clientes. Técnicas como SMOTE ajudam a equilibrar conjuntos de dados criando artificialmente instâncias de classes minoritárias. Da mesma forma, em indústrias como a financeira, redes adversárias generativas (GANs) são usadas para simular transações raras, permitindo que os modelos sejam robustos na detecção de casos de borda e melhorando o desempenho geral.

A IA generativa e os modelos de linguagem de grande porte (LLMs) podem auxiliar pessoas desenvolvedoras a escrever e entender código. O auxílio na compreensão de código é especialmente útil em caso de bases de código legadas com documentação escassa, desatualizada e errônea. Desde a última vez que escrevemos sobre isso, as técnicas e produtos para usar GenIA para entender bases de código legadas evoluiram ainda mais, e nós temos utilizado com sucesso algumas delas na prática, principalmente para auxiliar nos esforços de engenharia reversa para modernização de mainframes. Uma técnica particularmente promissora que temos utilizado é a geração aumentada por recuperação (RAG), uma abordagem onde a recuperação da informação é feita em um grafo de conhecimento da base de código. O grafo de conhecimento consegue preservar as informações estruturais sobre a base de código que vão além do que uma LLM pode extrair apenas do código textual. Isso é especialmente útil em bases de código legadas que são menos autodescritivas e coesas. Uma oportunidade adicional para melhorar a compreensão do código é que o grafo pode ser enriquecido com a documentação existente e gerada por IA, dependências externas, conhecimento do domínio do negócio ou qualquer outro recurso disponível que possa facilitar o trabalho da 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.