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.

As ferramentas de assistência à codificação baseadas em IA são geralmente discutidas no contexto de apoiar e aprimorar o trabalho individual. No entanto, a entrega de software é e continuará sendo um trabalho em equipe. Por isso, você deve procurar maneiras de criar assistentes de equipe baseados em IA que ajudem a criar a equipe 10x, o oposto de pessoas engenheiras 10x isoladas e habilitadas por IA. Felizmente, desenvolvimentos recentes no mercado de ferramentas estão nos aproximando de tornar isso uma realidade. Unblocked é uma plataforma que reúne todas as fontes de conhecimento de uma equipe e as integra de forma inteligente às ferramentas dos membros da equipe. E o Rovo da Atlassian traz a IA para a plataforma de colaboração em equipe mais utilizada, oferecendo às equipes novos tipos de pesquisa e acesso à sua documentação, além de desbloquear novas formas de automação e suporte a práticas de software com agentes Rovo. Enquanto esperamos que o mercado evolua ainda mais nesse espaço, temos explorado o potencial da IA para amplificação de conhecimento e suporte a práticas de equipe por conta própria: disponibilizamos como código aberto, o Haiven, nosso assistente à equipe baseado em IA e começamos a reunir aprendizados com assistência de IA para tarefas não relacionadas à codificação, como a análise de requisitos.

Prompt dinâmico de poucos disparos aprimora o conceito de few-shot prompting ao incluir dinamicamente exemplos específicos no prompt para guiar as respostas do modelo. Ajustar o número e a relevância desses exemplos otimiza o comprimento e a pertinência do contexto, melhorando assim a eficiência e o desempenho do modelo. Bibliotecas como scikit-llm implementam essa técnica utilizando a busca pelos casos mais similares para encontrar os exemplos mais relevantes alinhados com a consulta da usuária. Essa técnica permite uma melhor utilização da janela de contexto limitada do modelo e reduz o consumo de tokens. O gerador de código aberto do SQL, vanna, utiliza o dynamic few-shot prompting para aprimorar a precisão das respostas.

GraphQL para produtos de dados é a técnica de usar GraphQL como uma porta de saída para produtos de dados buscando o consumo do produto pela cliente. Nós citamos GraphQL como um protocolo de API e como ele permite com que desenvolvedoras criem uma camada de API unificada que abstrai a complexidade dos dados subjacentes, concedendo uma interface mais coesa e gerenciável para clientes. GraphQL para produtos de dados torna fácil para consumidoras descobrirem o formato dos dados e suas relações com o esquema do GraphQL, além de fazer uso de ferramentas que são conhecidas por esse público. Os nossos times estão explorando essa técnica em usos específicos como o de conversas sobre dados para analisar e descobrir insights de big data com a ajuda de grandes modelos de linguagem, onde as consultas GraphQL são construídas por LLMs com base no prompt da usuária e o esquema do GraphQL é usado nos prompts LLM para referência.

Agentes autônomos com tecnologia LLM estão evoluindo além de agentes únicos e sistemas multi-agentes estáticos com o surgimento de frameworks como o Autogen e o CrewAI. Essa técnica permite que desenvolvedoras dividam uma atividade complexa em várias tarefas menores realizadas por agentes, onde cada agente é designado a uma função específica. Desenvolvedoras podem utilizar ferramentas pré-configuradas para realizar a tarefa, e os agentes conversam entre si e orquestram o fluxo. A técnica ainda está em estágio inicial de desenvolvimento. Em nossos experimentos até agora, nossos times têm encontrado problemas como agentes entrando em loops contínuos e comportamento descontrolado. Bibliotecas como LangGraph oferecem um maior controle das interações do agente com a habilidade de definir o fluxo como um gráfico. Se você utiliza esta técnica, nós sugerimos implementar mecanismos de segurança contra falhas, incluindo timeouts e supervisão humana.

Observabilidade 2.0 representa uma mudança de ferramentas de monitoramento tradicionais e díspares para uma abordagem unificada que promove dados de eventos estruturados e de alta cardinalidade em um único armazenamento de dados. Este modelo captura eventos ricos em sua forma bruta, com metadados detalhados, para oferecer uma única fonte de verdade para uma análise abrangente. Ao armazenar eventos em sua forma bruta, ele simplifica a correlação e oferece suporte a análises em tempo real e forense, além de permitir insights mais profundos em sistemas complexos e distribuídos. A abordagem permite monitoramento de alta resolução e capacidades de investigação dinâmica. Observabilidade 2.0 prioriza a captura de dados de alta cardinalidade e alta dimensionalidade, permitindo um exame detalhado sem gargalos de desempenho. O armazenamento de dados unificado reduz a complexidade, oferecendo uma visão coerente do comportamento do sistema e alinhando as práticas de observabilidade mais de perto com o ciclo de vida do desenvolvimento de software.

Modelos de linguagem de grande porte (LLMs) agora podem ser executados em navegadores da internet e em dispositivos móveis como smartphones e laptops, permitindo a construção de aplicações de IA em dispositivos. Isso proporciona uma manipulação segura de dados sensíveis, eliminando a necessidade de transferi-los para a nuvem, a baixa latência para tarefas computacionais e processamento em tempo real de imagens e vídeo nos dispositivos, e a redução de custos pela execução computacional local e funcionamento das aplicações mesmo quando a conectividade à internet é instável ou indisponível. Esse é um campo de pesquisa ativo e em crescimento. No passado, nós destacamos MLX, uma ferramenta de código aberto para aprendizado de máquina eficiente em processadores Apple. Outras ferramentas emergentes incluem Transformers.js e Chatty. Transformers.js possibilita a execução de Transformers em navegadores usando ONNX Runtime, dando suporte a modelos convertidos de PyTorch, TensorFlow e JAX. Chatty, por sua vez, roda LLMs de forma nativa e privada nos navegadores através da WebGPU, enriquecendo a experiência de IA com uma gama completa de funcionalidades.

Saída estruturada de LLMs se refere a prática de restringir a resposta de um modelo de linguagem a um esquema definido. Isso pode ser alcançado tanto através de um modelo generalizado, para que ele responda em um formato específico, quanto ajustando um modelo para que ele nativamente produza um JSON, por exemplo. A OpenAI agora suporta saídas estruturadas, permitindo que as desenvolvedoras forneçam um esquema JSON, pydantic ou um objeto Zod para restringir as respostas do modelo. Essa capacidade é especialmente valiosa para permitir chamadas de função, integração com APIs e realizando integrações externas, onde a precisão e conformidade com o formato são críticas. A saída estruturada não apenas aprimora a maneira como as LLMs podem interagir com o código, mas também suporta casos de uso mais amplos, como a geração de marcação para renderizar gráficos. Além disso, a saída estruturada demonstrou reduzir a probabilidade de erros nas respostas do modelo.

Assistentes de codificação de IA como GitHub Copilot e Tabnine tornaram-se muito populares. De acordo com a pesquisa de desenvolvedoras da StackOverflow em 2024, 72% de todas as pessoas entrevistadas são favoráveis ou muito favoráveis às ferramentas de IA para desenvolvimento. Embora também vejamos seus benefícios, estamos cautelosas sobre o impacto de médio a longo prazo que isso terá na qualidade do código e alertamos as desenvolvedoras sobre a complacência com o código gerado por IA. É muito tentador sermos menos vigilantes ao revisar sugestões de IA após algumas experiências positivas com um assistente. Estudos como este da GitClear mostram uma tendência de bases de código crescendo mais rapidamente, o que suspeitamos coincidir com pull requests maiores. E este estudo do GitHub nos faz questionar se o aumento mencionado de 15% na taxa de merge de pull requests é realmente uma coisa boa ou se as pessoas estão mesclando pull requests maiores mais rapidamente porque confiam demais nos resultados da IA. Ainda estamos usando o conselho que compartilhamos há mais de um ano de como iniciar o uso, que é ter cuidado com o viés de automação, a falácia do custo irrecuperável, o viés de ancoragem e a fadiga de revisão. Também recomendamos que as programadoras desenvolvam uma boa estrutura mental sobre onde e quando não usar e confiar na IA.

A criação de ambientes de testes de integração em toda empresa é uma prática comum e ineficiente que deixa tudo mais lento. Esses ambientes invariavelmente se tornam um recurso precioso, difícil de replicar e um gargalo no desenvolvimento. Eles também dão uma falsa sensação de segurança devido a inevitável discrepância nos dados e na sobrecarga de configuração entre os ambientes. Ironicamente, uma objeção comum às alternativas — como ambientes efêmeros ou múltiplos ambientes de testes locais — é o custo. No entanto, isso não leva em conta o custo de atraso causado pela utilização de ambientes de testes de integração em toda companhia, como times de desenvolvimento esperando por outros times terminarem ou por novas versões de sistemas dependentes serem implementados. Em vez disso, as equipes devem utilizar ambientes efêmeros e, preferencialmente, uma suíte de testes mantida pela equipe de desenvolvimento, que pode ser criada e descartada de forma barata, usando stubs falsos para seus sistemas em vez de réplicas reais. Para outras técnicas que suportam esta alternativa veja sobre testes de contrato, desacoplamento da implantação do lançamento, foco no tempo médio de recuperação e testes em produção.

Em vez de instituir proibições gerais de LLM no local de trabalho, as organizações devem se concentrar em fornecer acesso a um conjunto aprovado de ferramentas de IA. Uma proibição apenas leva as funcionárias a encontrarem soluções alternativas não aprovadas e potencialmente inseguras, criando riscos desnecessários. Assim como nos primeiros dias da computação pessoal, as pessoas usarão quaisquer ferramentas que considerem eficazes para realizar seu trabalho, independentemente das barreiras existentes. Ao não fornecer uma alternativa segura e endossada, as empresas correm o risco de que as funcionárias usem LLMs não aprovados, o que traz riscos de propriedade intelectual, vazamento de dados e responsabilidade legal. Em vez disso, oferecer LLMs ou ferramentas de IA seguras e aprovadas pela empresa garante tanto a segurança quanto a produtividade. Uma abordagem bem governada permite que as organizações gerenciem preocupações com privacidade de dados, segurança, conformidade e custos, ao mesmo tempo em que empoderam as funcionárias com as capacidades que LLMs oferecem. No melhor cenário, o acesso bem gerenciado às ferramentas de IA pode acelerar o aprendizado organizacional sobre as melhores maneiras de usar a IA no local de trabalho.

Quando as pessoas falam sobre assistentes de programação, o tópico programação em pares inevitavelmente aparece. Nossa profissão tem uma relação de amor e ódio com isso: algumas pessoas acreditam veemente, outras não suportam. Assistentes de programação agora imploram pela pergunta: pode um ser humano parear com uma IA, ao invés de outro ser humano, e obter os mesmos resultados para o time? GitHub Copilot chama a si mesmo deseu programador em par de IA. Enquanto acreditamos que um assistente de programação pode trazer alguns dos benefícios da programação em pares, nós aconselhamos totalmente contra substituir programação em pares por IA. Visualizar assistentes de código para o pareamento ignora um dos benefícios chave da programação em pares: fazer o time, não apenas os indivíduos que contribuem, melhor. Assistentes de código podem oferecer benefícios para se desbloquear, aprender sobre uma nova tecnologia, integrar ou tornar o trabalho tático mais rápido para que possamos focar em design estratégico. Mas eles não ajudam com nenhum dos benefícios de colaboração de time, como manter em baixo nível o trabalho em progresso, reduzir handoffs e reaprendizados, tornando a integração contínua possível ou melhorando a propriedade coletiva de código.