Technology Radar

Dois tipos de discussões sobre licenças surgiram durante nossa reunião. O primeiro ponto diz respeito ao fato de que, por muitos anos, o ecossistema de desenvolvimento de software de código aberto confiou em um conjunto de licenças catalogadas pela Open Source Initiative (OSI), com um pequeno número de licenças populares usadas na maioria dos casos. Recentemente, no entanto, observamos uma agitação nessa paisagem anteriormente serena. Várias ferramentas de destaque receberam má publicidade recentemente, quando seus mantenedores mudaram - em alguns casos abruptamente - de uma licença de código aberto para um modelo comercial. Não temos nenhum problema em pagar por software e aceitamos o modelo comum de licenças comerciais para funcionalidades adicionais. No entanto, consideramos problemático quando a funcionalidade central de uma ferramenta amplamente utilizada é repentinamente colocada atrás de um paywall, especialmente quando um ecossistema se desenvolveu em torno da ferramenta. O segundo ponto de desenvolvimento interessante diz respeito ao software que se autoproclama código aberto, mas funcionalidades fundamentais só aparecem após o pagamento de assinaturas ou outras taxas por parte das pessoas usuárias. Embora esse modelo de negócio já existisse anteriormente, ele parece ser mais explorado com muitas das novas ferramentas de IA – oferecendo recursos incríveis, um pouco escondidos sob as letras miúdas. Aconselhamos especial diligência em relação às questões de licença. Preste atenção às ressalvas e certifique-se de que todos os arquivos em um repositório estejam cobertos pela licença no nível superior.

A Inteligência Artificial (IA) dominou nossas conversas, ocupando cerca de um terço dos tópicos abordados no Radar. Discutimos diversas ferramentas de IA voltadas para pessoas desenvolvedoras, como GitHub Copilot, Codium AI, aider e Continue. Além disso, conversamos bastante sobre como o uso holístico de IA por toda a equipe modifica aspectos do desenvolvimento de software. Analisamos diversas ferramentas que não entraram na seleção final, incluindo terminais assistidos por IA como o Warp, a capacidade de converter screenshots em código, ChatOps baseados em LLMs e vários outros tópicos. Embora as ferramentas voltadas para desenvolvimento tendam a ter um grau maior de maturidade, suspeitamos que todos os aspectos do desenvolvimento de software possam se beneficiar gradualmente do uso pragmático de IA e ferramentas derivadas. Por isso, estamos acompanhando ativamente as inovações em todo o panorama do desenvolvimento. É claro que, com os novos recursos quase mágicos oferecidos pela IA, surgem também novos riscos para a qualidade e segurança do software. Isso exige que as equipes permaneçam vigilantes, incluindo manter pessoas não desenvolvedoras informadas sobre os potenciais perigos.

Padrões são populares no mundo da tecnologia porque fornecem um nome sucinto para uma solução a um problema específico. Com o uso crescente dos modelos de linguagem de grande porte (LLMs), estamos começando a ver o surgimento de padrões de arquitetura específicos para suportar contextos comuns. Por exemplo, discutimos o NeMo Guardrails, que permite que as pessoas desenvolvedoras construam políticas de governança em torno do uso de LLM. Também falamos sobre ferramentas como Langfuse que permitem maior observabilidade nas etapas que levam à saída de um LLM e como lidar (e validar) bases de código infladas cheias de código gerado. Discutimos como a geração aumentada por recuperação (RAG) é nosso padrão preferido para melhorar a qualidade das saídas do LLM, especialmente no ecossistema corporativo. Além disso, discutimos técnicas como o uso de um LLM de menor potência (e custo) para produzir material que é seletivamente examinado por um LLM mais poderoso (e caro). Padrões formam um vocabulário importante para tecnologias, e esperamos ver uma explosão de padrões (e os inevitáveis antipadrões) à medida que a IA generativa continua a permear o desenvolvimento de software.

A Thoughtworks sempre foi uma forte defensora de ciclos rápidos de feedback durante o desenvolvimento de software e, por isso, uma grande apoiadora da integração contínua (CI). Para auxiliar na adoção, construímos o primeiro servidor de CI da história - CruiseControl - que foi open-sourced no final dos anos 1990. Recentemente, nosso cientista-chefe, Martin Fowler, atualizou a definição canônica de integração contínua em seu bliki para renovar a atenção nessa prática. No entanto, muitas de nossas equipes são obrigadas a ignorar a parte de CI do CI/CD porque se encontram em situações onde pull requests (PRs) são obrigatórias. Embora a prática de PRs tenha sido originalmente desenvolvida para gerenciar equipes open-source massivamente distribuídas e colaboradores não confiáveis, elas se tornaram um sinônimo de revisão por pares, mesmo em equipes de entrega pequenas e coesas. Nessas circunstâncias, muitos desenvolvedores anseiam pelo mesmo senso de fluxo que obtêm ao praticar a CI real. Analisamos diversas ferramentas que tentam aliviar as dores dos processos de revisão de PRs, incluindo gitStream e fila de merge do Github merge queue. Também discutimos técnicas como diferenciais empilhados que prometem se alinhar aos princípios centrais da CI, permitindo um controle mais granular sobre o processo de integração, e debatemos métodos para derivar métricas de PRs para identificar ineficiências e gargalos durante a entrega de software. O uso de ferramentas ajuda bastante nessa área devido à tendência de IA generativa para programação Com assistentes de programação por IA, o rendimento de programação aumenta, o que leva à tendência de criar PRs maiores. Isso pressiona ainda mais os processos de revisão de código assíncronos. Mesmo que ainda prefiramos a prática original de CI, incentivamos as equipes que não podem usá-la devido a restrições externas a encontrar maneiras de melhorar a precisão da integração e a velocidade de seu ciclo de feedback.