÷ÈÓ°Ö±²¥

As organiza??es adotam ativamente a mentalidade de produto para dados como uma pr¨¢tica padr?o para gerenciar os ativos de dados. Essa abordagem trata os dados como um produto com seu pr¨®prio ciclo de vida, padr?es de qualidade e foco em atender ¨¤s necessidades da pessoa consumidora. Agora a recomendamos como padr?o para o gerenciamento de dados, independentemente de as organiza??es escolherem arquiteturas como malha de dados (data mesh) ou lakehouse.

Enfatizamos a import?ncia do foco na pessoa consumidora na mentalidade de produto para dados, com o fim de promover maior ado??o e realiza??o de valor. Isso implica antes dos casos de uso. Tamb¨¦m damos foco em capturar e gerenciar metadados relevantes para os neg¨®cios e metadados t¨¦cnicos usando cat¨¢logos de dados modernos como DataHub, Collibra, Atlan e Informatica. Essas pr¨¢ticas melhoram a capacidade de descoberta e a usabilidade dos dados. Al¨¦m disso, adotamos a mentalidade de produto para dados para escalar iniciativas de IA e criar dados prontos para IA. Essa abordagem inclui o gerenciamento abrangente do ciclo de vida, garantindo que os dados n?o sejam apenas bem administrados e de alta qualidade, mas tamb¨¦m descartados em conformidade com os requisitos legais e regulamentares quando n?o forem mais necess¨¢rios.

Teste de fuzzing, ou simplesmente fuzzing, ¨¦ uma t¨¦cnica de teste que existe h¨¢ muito tempo, mas ainda ¨¦ uma das menos conhecidas. O seu objetivo ¨¦ fornecer a um sistema de software todos os tipos de entradas inv¨¢lidas e observar o seu comportamento. Para um endpoint HTTP, por exemplo, requisi??es inv¨¢lidas deveriam resultar em erros 4xx, mas o teste de fuzzing provoca erros 5xx ou piores. Bem documentado e suportado por ferramentas, o teste de fuzzing se tornou mais relevante do que nunca, especialmente com o aumento do c¨®digo gerado por IA e sua complac¨ºncia. Isto significa que ¨¦ uma boa hora para adotar o teste de fuzzing para garantir que o c¨®digo continue robusto e seguro.

Desde o nosso blip inicial em 2021, a gera??o de lista de materiais de software (SBOM) passou de uma pr¨¢tica emergente para um um padr?o sensato em nossos projetos. O ecossistema amadureceu significativamente, oferecendo um conjunto de ferramentas robusto e integra??o perfeita com CI/CD. Ferramentas como Syft, Trivy e Snyk fornecem uma gera??o de SBOM, desde c¨®digo fonte at¨¦ imagens de cont¨ºineres e an¨¢lises de vulnerabilidades. Plataformas como a FOSSA e a Chainloop aprimoram a gest?o de riscos de seguran?a ao se integrarem com o fluxo de desenvolvimento e aplicarem pol¨ªticas de seguran?a. Embora um padr?o universal de SBOM ainda esteja evoluindo, o amplo suporte ao e ao CycloneDX minimizou os desafios de ado??o. Sistemas de IA tamb¨¦m exigem SBOMs, como demonstrado pelo do governo do Reino Unido e pelo da CISA. Continuaremos monitorando os avan?os nesse espa?o.

No cen¨¢rio em constante evolu??o de desenvolvimento de software impulsionado por IA, a ¨¦ mais essencial do que nunca para construir software seguro, mantendo a agilidade e evitando o ¡°sandu¨ªche de seguran?a¡±. A modelagem de amea?as ¡ª um conjunto de t¨¦cnicas para identificar e classificar amea?as potenciais ¡ª aplica-se em v¨¢rios contextos, , que introduzem . Para ser eficaz, ela deve ser realizada regularmente ao longo do ciclo de vida do software e funciona melhor em conjunto com outras pr¨¢ticas de seguran?a. Essas incluem definir requisitos de seguran?a interfuncionais para abordar riscos comuns nas tecnologias do projeto e utilizar scanners de seguran?a automatizados para monitoramento cont¨ªnuo.

Tratar APIs como produto significa priorizar a experi¨ºncia da pessoa desenvolvedora, n?o apenas inserindo um design sensato e padronizado nas pr¨®prias APIs, mas tamb¨¦m fornecendo documenta??es abrangentes e boas experi¨ºncias de onboarding. Embora as especifica??es de OpenAPI (Swagger) possam documentar as interfaces de APIs efetivamente, o onboarding permanece um desafio. As desenvolvedoras precisam de acesso r¨¢pido a exemplos funcionais, com autentica??o pr¨¦-configurada e dados de testes realistas. Com o amadurecimento de ferramentas de clientes de API (como Postman, Bruno e Insomnia), recomendamos tratar a cole??o de requisi??es de API como um artefato do produto. Essas cole??es devem ser cuidadosamente projetadas para guiar efetivamente as desenvolvedoras atrav¨¦s dos principais fluxos de trabalho, auxiliando na compreens?o da funcionalidade e linguagem de dom¨ªnio da API com o m¨ªnimo de esfor?o. Para manter as cole??es atualizadas, recomendamos armazen¨¢-las em um reposit¨®rio e integrar ao pipeline de entrega das APIs.

Um dos desafios persistentes em grandes equipes de software ¨¦ determinar quem toma as decis?es arquiteturais que moldam a evolu??o dos sistemas. O revela que a abordagem tradicional dos Conselhos de Revis?o de Arquitetura ¨¦ contraproducente, muitas vezes prejudicando o fluxo de trabalho e correlacionando-se com baixo desempenho organizacional. Uma alternativa convincente ¨¦ um ¡ª uma abordagem descentralizada onde qualquer pessoa pode tomar qualquer decis?o arquitetural, desde que busque aconselhamento daqueles afetados e daqueles com experi¨ºncia relevante. Este m¨¦todo permite que as equipes otimizem o fluxo sem comprometer a qualidade arquitetural, tanto em pequenas quanto em grandes escalas. ? primeira vista, essa abordagem pode parecer controversa, mas pr¨¢ticas como Registros de Decis?o de Arquitetura e f¨®runs consultivos garantem que as decis?es permane?am informadas, enquanto capacitam aqueles mais pr¨®ximos do trabalho a tomar decis?es. Temos visto este modelo ter sucesso em escala em um n¨²mero crescente de organiza??es, incluindo aquelas em ind¨²strias altamente regulamentadas.

Em nossa ¨²ltima atualiza??o do RAG, introduzimos o GraphRAG, originalmente descrito no como uma abordagem de duas etapas: (1) divis?o de documentos em segmentos e uso de uma an¨¢lise baseada em modelos de linguagem de grande porte (LLMs) dos segmentos para criar um gr¨¢fico de conhecimento; (2) recupera??o de segmentos relevantes no momento da consulta por meio de embeddings, enquanto seguimos as bordas no gr¨¢fico de conhecimento para descobrir segmentos relacionados adicionais, que s?o ent?o adicionados ao prompt aumentado. Em muitos casos, essa abordagem aprimora as respostas geradas pelo LLM. Observamos benef¨ªcios semelhantes ao usar o GenAI para entender bases de c¨®digo legadas, em que usamos informa??es estruturais ¡ª como ¨¢rvores de sintaxe abstratas e depend¨ºncias ¡ª para criar o gr¨¢fico de conhecimento. O padr?o GraphRAG ganhou for?a com o surgimento de ferramentas e estruturas como o da Neo4j para oferecer suporte a ele. Tamb¨¦m consideramos que o Graphiti se encaixa em uma interpreta??o mais ampla do GraphRAG como um padr?o.

O garante que sistemas e usu¨¢rias tenham apenas o acesso m¨ªnimo necess¨¢rio para realizar suas tarefas. O abuso de credenciais privilegiadas ¨¦ um fator significativo por tr¨¢s das , sendo a escalada de privil¨¦gios um vetor de ataque comum. Frequentemente, as invasoras come?am com acesso de baixo n¨ªvel e exploram vulnerabilidades de software ou configura??es incorretas para obter privil¨¦gios de administrador, especialmente quando as contas t¨ºm direitos excessivos ou desnecess¨¢rios. Outro risco negligenciado s?o os privil¨¦gios permanentes ¡ª acessos privilegiados dispon¨ªveis continuamente, que ampliam a superf¨ªcie de ataque. O gerenciamento de acesso privilegiado sob demanda mitiga esse risco, concedendo o acesso privilegiado apenas quando necess¨¢rio e revogando-o imediatamente ap¨®s o uso, minimizando a exposi??o. Um modelo de seguran?a que aplica rigorosamente o princ¨ªpio de menor privil¨¦gio garante que usu¨¢rias, aplica??es e sistemas tenham apenas os direitos essenciais pelo menor tempo poss¨ªvel ¨C um requisito cr¨ªtico para conformidade e seguran?a regulat¨®ria. Nossas equipes implementaram essa abordagem por meio de um fluxo de trabalho automatizado, que aciona um processo leve de aprova??o, atribui fun??es tempor¨¢rias com acesso restrito e imp?e um tempo m¨¢ximo de validade (TTL) para cada fun??o, garantindo que os privil¨¦gios expirem automaticamente assim que a tarefa for conclu¨ªda.

As t¨ºm sido um fator essencial no avan?o da IA ¡ª o princ¨ªpio de que modelos maiores, conjuntos de dados mais extensos e maior poder computacional resultam em sistemas de IA mais poderosos. No entanto, hardwares de consumo e dispositivos de borda frequentemente n?o possuem capacidade suficiente para suportar modelos em larga escala, criando a necessidade da destila??o de modelos.

A transfere conhecimento de um modelo maior e mais potente (professor) para um modelo menor e mais eficiente (aluno). O processo normalmente envolve a gera??o de um conjunto de dados amostral a partir do modelo professor e o ajuste fino do modelo aluno para capturar suas propriedades estat¨ªsticas. Diferente da poda ou da , que reduzem modelos removendo par?metros, a destila??o busca preservar o conhecimento espec¨ªfico do dom¨ªnio, minimizando a perda de precis?o. Al¨¦m disso, ela pode ser combinada com quantiza??o para otimiza??o adicional.

por Geoffrey Hinton et al., a destila??o de modelos tem sido amplamente adotada. Um exemplo not¨¢vel ¨¦ a vers?o destilada do Qwen/Llama do DeepSeek R1, que mant¨¦m fortes capacidades de racioc¨ªnio em modelos menores. Com sua crescente maturidade, a t¨¦cnica n?o est¨¢ mais restrita a laborat¨®rios de pesquisa; agora ¨¦ aplicada em projetos industriais e pessoais. Provedores como e oferecem guias para ajudar desenvolvedoras a destilar seus pr¨®prios modelos de linguagem de pequeno porte (SLMs). Acreditamos que a ado??o da destila??o de modelos pode ajudar as organiza??es a gerenciar os custos de implanta??o de modelos de linguagem de grande porte (LLMs), ao mesmo tempo em que desbloqueia o potencial da infer¨ºncia de LLM em dispositivos.

Engenharia de prompt se refere ao processo de projetar e refinar prompts de modelos de IA generativa para produzir respostas de alta qualidade e contextualizadas. Isso envolve a elabora??o de prompts claros, espec¨ªficos e relevantes para tarefas sob medida ou aplica??es, para otimizar a sa¨ªda do modelo. ? medida que as capacidades dos modelos de linguagem de grande porte (LLMs) evoluem, particularmente com o surgimento dos modelos de racioc¨ªnio, as pr¨¢ticas da engenharia de prompt devem tamb¨¦m se adaptar. Baseado em nossa experi¨ºncia em gera??o de c¨®digo com IA, n¨®s observamos que o pode ter uma performance inferior ao zero-shot prompting quando trabalhado com modelos de racioc¨ªnio. Adicionalmente, o amplamente utilizado (CoT) pode a performance de modelos de racioc¨ªnio ¡ª provavelmente porque a aprendizagem por refor?o j¨¢ tem embutido no macanismo CoT.

Nossa experi¨ºncia pr¨¢tica est¨¢ alinhada com as pesquisas acad¨ºmicas, que sugerem que ¡°modelos avan?ados podem de engenharia de prompt na engenharia de software.¡± No entanto, t¨¦cnicas de engenharia de prompt tradicionais ainda desempenham um papel crucial na redu??o de alucina??es e na melhoria da qualidade das respostas, especialmente considerando as diferen?as em tempo de resposta e custos de token entre modelos de racioc¨ªnio e LLMs gen¨¦ricos. Ao construir aplica??es de agente, n¨®s recomendamos a escolha estrat¨¦gica dos modelos com base nas suas necessidades, enquanto continua a refinar seus modelos de prompt e t¨¦cnicas correspondentes. Encontrar o equil¨ªbrio certo entre desempenho, tempo de resposta e custo de token continua sendo essencial para maximizar a efic¨¢cia dos LLMs.

O an¨²ncio recente do DeepSeek R1 ¨¦ um ¨®timo exemplo de por que modelos de linguagem de pequeno porte (SLMs) permanecem interessantes. O R1 em tamanho real tem 671 bilh?es de par?metros e requer cerca de 1.342 GB de VRAM para funcionar, o que s¨® ¨¦ poss¨ªvel usando um mini cluster de oito GPUs NVIDIA de ¨²ltima gera??o. Mas o DeepSeek tamb¨¦m est¨¢ dispon¨ªvel em Qwen e Llama ¡ª modelos menores e de peso aberto ¡ª transferindo efetivamente suas habilidades e permitindo que seja executado em hardware muito mais modesto. Embora o modelo perca algum desempenho nesses tamanhos menores, ele ainda permite um grande salto de desempenho em rela??o aos modelos de linguagem de pequeno porte anteriores. O espa?o dos SLMs continua a inovar em outros lugares tamb¨¦m. Desde o ¨²ltimo Radar, a Meta introduziu o nos tamanhos 1B e 3B, a Microsoft lan?ou o , oferecendo resultados de alta qualidade com um modelo 14B, e o Google lan?ou o , um modelo de linguagem de vis?o nos tamanhos 3B, 10B e 28B. Esses s?o apenas alguns dos modelos menores que est?o sendo lan?ados, consolidando uma tend¨ºncia importante a ser acompanhada.

Nos ¨²ltimos meses, o uso de GenIA para entender bases de c¨®digo legadas tem avan?ado significativamente. Ferramentas populares, como o GitHub Copilot, est?o sendo destacadas como . Ferramentas como o , est?o facilitando a navega??o e compreens?o de bases de c¨®digo inteiras. Essas ferramentas utilizam diversas t¨¦cnicas de GenIA para fornecer ajuda contextual, simplificando o trabalho com sistemas legados complexos. Al¨¦m disso, frameworks especializados como o est?o demonstrando como modelos de linguagem de grande porte (LLMs) podem lidar com softwares cient¨ªficos em larga escala ¡ª como aqueles escritos em Fortran ou Pascal ¡ª trazendo uma compreens?o aprimorada por GenIA para bases de c¨®digo fora do tradicional ambiente corporativo de TI. Acreditamos que essa abordagem continuar¨¢ ganhando for?a, dado o enorme volume de software legado existente no mundo.

Agentes de engenharia de software supervisionados est?o cada vez mais capazes de identificar atualiza??es necess¨¢rias e fazer altera??es maiores em uma base de c¨®digo. Ao mesmo tempo, vemos uma crescente complac¨ºncia com c¨®digo gerado por IA e desenvolvedoras demonstrando resist¨ºncia em revisar grandes conjuntos de mudan?as feitas por IA. Uma justificativa comum para isso ¨¦ a ideia de que a legibilidade do c¨®digo voltada para humanos importa menos, j¨¢ que a IA pode lidar com modifica??es futuras. No entanto, assistentes de c¨®digo baseados em IA tamb¨¦m t¨ºm um desempenho melhor em bases de c¨®digo bem estruturadas, tornando o design de c¨®digo compat¨ªvel com IA essencial para a manuten??o.

Felizmente, boas pr¨¢ticas de design de software para humanos tamb¨¦m beneficiam a IA. Nomes bem definidos fornecem contexto de dom¨ªnio e funcionalidade; modularidade e abstra??es mant¨ºm o contexto da IA gerenci¨¢vel ao limitar as mudan?as necess¨¢rias; e o princ¨ªpio DRY (¡°don¡¯t repeat yourself¡±, ou ¡°n?o se repita¡±) reduz a duplica??o de c¨®digo, facilitando para a IA manter a consist¨ºncia do comportamento. At¨¦ agora, os melhores padr?es compat¨ªveis com IA est?o alinhados ¨¤s boas pr¨¢ticas j¨¢ estabelecidas. ? medida que a IA evolui, mais padr?es espec¨ªficos devem surgir, por isso, considerar o design de c¨®digo com isso em mente ser¨¢ extremamente ¨²til.

°Õ¨¦³¦²Ô¾±³¦²¹²õ novas de assist¨ºncia baseada em IA para equipes de software est?o surgindo al¨¦m da simples gera??o de c¨®digo. Uma ¨¢rea que est¨¢ ganhando destaque ¨¦ o teste de UI baseado em IA , aproveitando a capacidade dos modelos de linguagem de grande porte (LLMs) de interpretar interfaces gr¨¢ficas de usu¨¢rio. Existem v¨¢rias abordagens para isso. Uma categoria de ferramentas utiliza LLMs multimodais ajustados para o processamento de snapshots, permitindo que scripts de teste sejam escritos em linguagem natural para navegar em uma aplica??o. Exemplos nessa ¨¢rea incluem ou . Outra abordagem, vista no Browser Use, combina modelos fundacionais multimodais com Playwright, oferecendo insights sobre a estrutura de uma p¨¢gina em vez de depender de modelos ajustados.

Ao integrar testes de UI baseados em IA em uma estrat¨¦gia de testes, ¨¦ crucial considerar onde eles agregam mais valor. Esses m¨¦todos podem complementar os testes explorat¨®rios manuais e, embora ao n?o determinismo dos LLMs possa introduzir instabilidades, sua flexibilidade pode ser uma vantagem. Isso pode ser ¨²til para testar aplica??es legadas com seletores ausentes ou aplica??es que frequentemente mudam r¨®tulos e caminhos de cliques.

define as regras b¨¢sicas que regem os sistemas adaptativos, incluindo os sistemas sociot¨¦cnicos envolvidos na cria??o e opera??o de software. Um conceito fundamental nessa teoria ¨¦ o envolt¨®rio de compet¨ºncia - o limite dentro do qual um sistema pode funcionar robustamente diante de uma falha. Quando um sistema ¨¦ levado al¨¦m de seu envolt¨®rio de compet¨ºncia, ele se torna fr¨¢gil e tem maior probabilidade de falhar. Esse modelo fornece uma lente valiosa para entender a falha do sistema, como visto nas que levaram ¨¤ interrup??o do Canva em 2024. A , um desenvolvimento recente no pensamento da arquitetura de software, oferece uma maneira de testar o envolt¨®rio de compet¨ºncia de um sistema introduzindo deliberadamente fatores de estresse e analisando como o sistema se adaptou aos fatores de estresse hist¨®ricos ao longo do tempo. As abordagens se alinham com os conceitos de antifragilidade, resili¨ºncia e robustez em sistemas sociot¨¦cnicos, e estamos ansiosas para ver aplica??es pr¨¢ticas dessas ideias no setor.

Sa¨ªda estruturada de LLMs se refere ¨¤ 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 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.

A IA est¨¢ diminuindo as barreiras para que pessoas que n?o programam construam e integrem software por conta pr¨®pria, em vez de esperar que o departamento de TI atenda ¨¤s suas necessidades. Embora estejamos entusiasmadas com o potencial que isso desbloqueia, tamb¨¦m estamos atentas aos primeiros sinais da TI invis¨ªvel acelerada por IA. Plataformas de automa??o de fluxo de trabalho sem c¨®digo agora oferecem suporte ¨¤ integra??o de API de IA (por exemplo, OpenAI ou Anthropic), tornando tentador usar a IA como tapa-buraco ¡ª unindo integra??es que antes n?o eram poss¨ªveis, como transformar mensagens de chat em chamadas de API de ERP via IA. Ao mesmo tempo, assistentes de programa??o de IA est?o se tornando mais ¡°ag¨ºnticos", ou aut?nomos, permitindo que pessoas com treinamento b¨¢sico construam aplicativos de utilidade interna.

Isso tem todas as caracter¨ªsticas da pr¨®xima evolu??o das planilhas que ainda alimentam processos cr¨ªticos em algumas empresas ¡ª mas com uma pegada muito maior. Se n?o for controlada, essa nova TI invis¨ªvel pode levar a uma prolifera??o de aplicativos n?o regulamentados e potencialmente inseguros, espalhando dados por cada vez mais sistemas. As organiza??es devem estar cientes desses riscos e avaliar cuidadosamente as compensa??es entre a resolu??o r¨¢pida de problemas e estabilidade a longo prazo.

? medida que os assistentes de programa??o de IA continuam a ganhar for?a, o mesmo acontece com o crescente conjunto de dados e pesquisas que destacam as preocupa??es sobre a complac¨ºncia com c¨®digo gerado por IA. A mais recente da GitClear mostra que, em 2024, c¨®digos duplicados e a rejei??o de c¨®digos aumentaram ainda mais do que o previsto, enquanto a atividade de refatora??o nos hist¨®ricos de commit diminuiu. Tamb¨¦m refletindo isso, uma sobre ¡°trabalhadoras do conhecimento¡± descobriu que a confian?a impulsionada pela IA geralmente ocorre ¨¤s custas do pensamento cr¨ªtico (um padr?o que observamos ¨¤ medida que a complac¨ºncia se instala com o uso prolongado de assistentes de programa??o). O surgimento de agentes de engenharia de software supervisionados amplia ainda mais os riscos, pois quando a IA gera conjuntos de altera??es cada vez maiores, as desenvolvedoras enfrentam desafios maiores na revis?o dos resultados. O surgimento da , em que desenvolvedoras permitem que a IA gere c¨®digo com revis?o m¨ªnima, ilustra a confian?a crescente nos resultados gerados pela IA. Embora essa abordagem possa ser apropriada para coisas como prot¨®tipos ou outros tipos de c¨®digo descart¨¢vel, advertimos fortemente contra seu uso para c¨®digo de produ??o.

As organiza??es continuam cautelosas em rela??o aos assistentes de programa??o com IA de terceiros, especialmente devido a preocupa??es com a confidencialidade do c¨®digo. Como resultado, muitas desenvolvedoras est?o considerando o uso de assistentes de programa??o locais ¡ª IAs que rodam inteiramente em suas m¨¢quinas ¡ª eliminando a necessidade de enviar c¨®digo para servidores externos. No entanto, os assistentes locais ainda ficam atr¨¢s das vers?es baseadas na nuvem, que utilizam modelos maiores e mais avan?ados. Mesmo em m¨¢quinas de alto desempenho, os modelos menores continuam apresentando limita??es. Observamos que eles t¨ºm dificuldades com prompts complexos, n?o possuem uma janela de contexto suficientemente grande para problemas mais amplos e, muitas vezes, n?o conseguem ativar integra??es de ferramentas ou chamadas de fun??es. Essas capacidades s?o especialmente cruciais para os workflows baseados em agentes, que representam o estado da arte na assist¨ºncia ¨¤ programa??o atualmente.

Portanto, embora seja importante ter expectativas moderadas, algumas funcionalidades ainda s?o vi¨¢veis localmente. Algumas IDEs populares agora incorporam modelos menores em seus recursos principais, como a conclus?o preditiva de c¨®digo do Xcode e a . Al¨¦m disso, LLMs que podem ser executados localmente, como o , representam um avan?o para sugest?es inline locais e o manuseio de consultas simples de programa??o. Voc¨º pode testar essas capacidades com o Continue, que suporta a integra??o de modelos locais por meio de runtimes como o Ollama.

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? O GitHub Copilot chama a si mesmo de seu 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 desaconselhamos totalmente . Visualizar assistentes de c¨®digo para o pareamento ignora um dos benef¨ªcios chave da programa??o em pares: tornar o time, n?o apenas os indiv¨ªduos que contribuem, melhor. Assistentes de programa??o 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. No entanto, eles n?o contribuem para os benef¨ªcios da colabora??o em equipe, como manter o trabalho em andamento em um n¨ªvel baixo, reduzir handoffs e reaprendizados, possibilitar a integra??o cont¨ªnua ou melhorar a propriedade coletiva do c¨®digo.

Estamos observando uma prolifera??o preocupante do chamado ETL reverso. Os processos tradicionais de ETL t¨ºm seu lugar nas arquiteturas de dados convencionais, onde transferem dados de sistemas de processamento de transa??es para um sistema centralizado de an¨¢lise, como um data warehouse ou um data lake. Embora essa arquitetura tenha limita??es bem documentadas ¡ª muitas das quais s?o abordadas por uma abordagem de malha de dados ¡ª, ela ainda ¨¦ comum em empresas. Numa arquitetura desse tipo, mover dados de volta de um sistema central de an¨¢lise para um sistema de transa??es faz sentido em certos casos ¡ª por exemplo, quando o sistema central pode agregar dados de v¨¢rias fontes ou como parte de uma arquitetura transicional ao migrar para uma malha de dados. No entanto, estamos observando uma tend¨ºncia crescente em que fornecedoras de produtos usam ETL reverso como uma desculpa para mover cada vez mais l¨®gica de neg¨®cios para uma plataforma centralizada ¡ª o produto delas. Essa abordagem agrava muitos dos problemas causados pelas arquiteturas de dados centralizadas, e sugerimos extrema cautela ao introduzir fluxos de dados de uma plataforma centralizada e abrangente para sistemas de processamento de transa??es.

Vemos uma ado??o cont¨ªnua do (Scaled Agile Framework?). Tamb¨¦m continuamos a observar que os processos de SAFe, padronizados em excesso e com etapas faseadas, criam fric??o, podem promover silos e que seu controle de cima para baixo gera desperd¨ªcio no fluxo de valor e desestimula a criatividade dos talentos de engenharia, ao mesmo tempo em que limita a autonomia e a experimenta??o das equipes. Um dos principais motivos para a ado??o do SAFe ¨¦ a complexidade de tornar uma organiza??o ¨¢gil, com empresas esperando que um framework como esse ofere?a um atalho simples, baseado em processos, para alcan?arem a agilidade. Dada a ado??o generalizada do SAFe ¡ª inclusive entre nossas clientes ¡ª treinamos mais de 100 consultoras da ÷ÈÓ°Ö±²¥ para oferecer melhor suporte a elas. Apesar desse conhecimento aprofundado e de muita tentativa, chegamos ¨¤ conclus?o de que, ¨¤s vezes, simplesmente n?o existe uma solu??o simples para um problema complexo e continuamos a recomendar abordagens e governan?a mais enxutas e orientadas por valor que funcionem em conjunto com um programa abrangente de mudan?a.

Scaled Agile Framework? e SAFe? s?o marcas registradas da Scaled Agile, Inc.