Technology Radar

Não, este texto temático não foi escrito pelo ChatGPT. A inteligência artificial (IA) vem borbulhando discretamente em áreas especializadas há décadas, e ferramentas como o GitHub Copilot já existem (e vêm gradualmente sendo adotadas) há alguns anos. No entanto, nos últimos meses, ferramentas como o ChatGPT nos reorientaram de maneira radical para o que é possível e tornaram as ferramentas amplamente disponíveis. Vários blips nesta edição do Radar abordam usos práticos de IA para projetos (além de sugerir qual código requer ajustes): Desenvolvimento orientado a testes auxiliado por IA, valendo-se da IA para ajudar a criar modelos de análise e muito mais. Semelhante a como as planilhas permitiram que os contadores parassem de usar máquinas de somar para recalcular planilhas complexas manualmente, a próxima geração de IA assumirá tarefas para aliviar os trabalhadores de tecnologia, incluindo pessoas desenvolvedoras, substituindo tarefas tediosas que exigem conhecimento (mas não sabedoria).

No entanto, alertamos contra usos excessivos ou inadequados. No momento, os modelos de IA são capazes de gerar um bom primeiro rascunho. Mas o conteúdo gerado sempre precisa ser monitorado por um humano que possa validá-lo, moderá-lo e usá-lo com responsabilidade. Se essas precauções forem ignoradas, os resultados podem levar a riscos de reputação e segurança para organizações e usuários. Até mesmo algumas demonstrações de produtos advertem os usuários: "O conteúdo gerado por IA pode conter erros. certifique-se de que é preciso e apropriado antes de usá-lo."

A acessibilidade tem sido uma consideração importante para as organizações há muitos anos. Recentemente, destacamos as experiências de nossas equipes com o crescente conjunto de ferramentas e técnicas que agregam acessibilidade aprimorada ao desenvolvimento, e várias regiões em que nossas equipes destacaram o conhecimento dessas técnicas por meio de campanhas de conscientização. Apresentamos blips relacionados à acessibilidade no desenvolvimento do pipeline de integração contínua, manuais de design, testes de acessibilidade guiados por inteligência, linting e testes de unidade. A crescente conscientização acerca deste tão importante tópico é bem-vinda; técnicas que dão a mais pessoas acesso à funcionalidade de maneiras aprimoradas, só podem ser uma coisa boa.

Funções sem servidor — AWS Lambdas — aparecem cada vez mais nas caixas de ferramentas de pessoas arquitetas e pessoas desenvolvedoras, e são empregadas em uma ampla variedade de tarefas úteis que trazem os benefícios da infraestrutura em nuvem. No entanto, como muitas coisas úteis, as soluções às vezes começam adequadamente simples, mas depois, a partir de um sucesso gradual e persistente, continuam evoluindo até ultrapassarem as limitações inerentes ao paradigma e afundarem na areia sob seu próprio peso. Ainda que vejamos muitas aplicações bem-sucedidas de soluções de estilo Serverless, também ouvimos muitas advertências a respeito de nossos projetos, como o antipadrão Lambda pinball. Também vemos mais ferramentas que parecem resolver problemas, mas são propensas a uso indevido. Por exemplo, ferramentas que facilitam o compartilhamento de código entre Lambdas ou orquestram interações complexas podem resolver um problema comum simples, mas correm o risco de recriar alguns antipadrões de arquitetura terríveis com novos blocos de construção. Se você precisa de uma ferramenta para gerenciar o compartilhamento de código e implantação independente em uma coleção de funções Serverless, talvez seja hora de repensar a adequação da abordagem. Como todas as soluções de tecnologia, o modelo sem servidor tem aplicações adequadas, mas muitos de seus recursos incluem compensações cujas desvantagens se tornam mais agudas à medida que a solução evolui.

Nós vimos por muito tempo "a incorporação da qualidade" como um aspecto essencial do desenvolvimento de análises e modelos de aprendizado de máquina confiáveis. Transformações orientadas a testes, testes de sanidade de dados e testes de modelo de dados fortalecem os pipelines de dados que alimentam os sistemas analíticos. A validação do modelo e a garantia de qualidade são cruciais para combater os vieses e garantir sistemas éticos de ML, com resultados equitativos. Ao integrar essas práticas, as empresas ficam mais bem posicionadas para aproveitar a IA e o aprendizado de máquina e criar soluções responsáveis e orientadas por dados que atendem a uma base de pessoas usuárias diversificada. O ecossistema de ferramentas correspondente não parou de crescer e amadurecer. Por exemplo, a Soda Core, uma ferramenta de qualidade de dados, permite a validação dos dados assim que chegam ao sistema, e verificações de monitoramento automatizadas para anomalias. O Deepchecks permite a interseção de integração contínua e validação de modelo, uma etapa importante na incorporação de boas práticas de engenharia em configurações de análise. O Giskard ajuda a garantir a qualidade de modelos de IA, permitindo que os designers detectem vieses e outras facetas negativas dos modelos, o que se alinha com nosso incentivo para pisar em águas éticas com cuidado ao desenvolver soluções com IA. Encaramos essas ferramentas de amadurecimento como mais uma evidência da integração de análise e aprendizado de máquina e sua integração às boas práticas de engenharia.

Uma discussão aparentemente perpétua que acontece em todas as reuniões do Radar ganhou destaque particular desta vez - para determinada tarefa, você deve escrever uma especificação declarativa usando JSON, YAML ou algo específico do domínio como HCL, ou deve escrever código em uma linguagem de programação de uso geral? Por exemplo, discutimos as diferenças entre Terraform Cloud Operator e Crossplane, usar ou não o AWS CDK e usar Dagger para programar um pipeline de implantação, entre outros casos. Especificações declarativas, embora geralmente mais fáceis de ler e escrever, oferecem abstrações limitadas que levam a código repetitivo. Linguagens de programação convencionais podem usar abstrações para evitar a duplicação, mas essas abstrações podem tornar o código consideravelmente mais difícil de seguir, especialmente quando as abstrações estão dispostas em camadas, após anos de alterações. Em nossa experiência, não há uma resposta universal para a pergunta acima. As equipes devem considerar ambas as abordagens e, quando uma solução for difícil de implementar de forma limpa em um tipo de linguagem, elas devem reavaliar o outro tipo. Pode até fazer sentido dividir preocupações e implementá-las com diferentes linguagens.