Relatório da ACM sobre IA em Código Aberto Alerta que Programação Mais Rápida Está Sobrecarregando a Revisão Humana

O relatório da ACM sobre IA em código aberto identifica uma inversão custosa: a IA pode produzir patches rapidamente, mas os humanos ainda precisam decidir quais mudanças merecem confiança. Esse desequilíbrio está acrescentando trabalho para mantenedores que já operam com tempo, financiamento e capacidade de revisão limitados.

Publicado pelo Technology Policy Council da Association for Computing Machinery, o relatório examina os efeitos da IA no software de código aberto. Sua preocupação central não é se a IA consegue escrever código útil. É se projetos conduzidos por humanos podem absorver com segurança um fluxo muito maior de contribuições assistidas por máquinas.

A distinção importa porque o software de código aberto sustenta telefones, veículos, serviços de nuvem e sistemas de IA. Ainda assim, muitos projetos importantes dependem de voluntários ou de pequenas equipes. Godot, curl e outros projetos já endureceram as regras de contribuição após encontrarem envios de IA de baixa qualidade. A promessa de código abundante está se chocando com a realidade da escassa atenção humana.

O Relatório da ACM sobre IA em Código Aberto Desloca a Atenção para a Revisão

O relatório argumenta que uma produção de código mais rápida não elimina o gargalo humano. Ela transfere esse gargalo para a revisão, a governança e a manutenção.

O ACM TechBrief foi publicado em 2026 por seis autores que atuam por meio do Technology Policy Council da ACM. Eles incluem Arunachalam Balasubramanian Shrinivass, Simson Garfinkel, Josiah Dykstra, Andy Oram, Nina Shamsi e Jonathan M. Smith.

O documento aborda quatro pressões conectadas: cibersegurança, manutenção de software, sustentabilidade financeira e o conhecimento limitado das organizações sobre suas dependências de código aberto. A IA afeta cada área, mas não as afeta da mesma forma.

Sistemas de IA podem encontrar vulnerabilidades, propor patches, escrever testes e automatizar trabalho rotineiro de desenvolvimento. Essas capacidades podem ajudar um projeto bem administrado a resolver problemas definidos mais rapidamente. Também podem ajudar um colaborador a preparar documentação ou explorar uma base de código desconhecida.

No entanto, um pull request é apenas uma proposta para mudar o projeto. Um mantenedor confiável precisa determinar se ele resolve o problema declarado, preserva a compatibilidade, atende aos padrões do projeto e evita novos riscos de segurança.

Essa decisão frequentemente exige mais do que ler as linhas modificadas. Revisores podem precisar reproduzir o problema, inspecionar módulos relacionados, avaliar consequências arquiteturais e testar o comportamento em ambientes compatíveis.

A IA reduz o custo de criar uma contribuição plausível. Ela não reduz, no mesmo ritmo, o custo de compreender todas as consequências.

Essa assimetria muda a economia da participação. Um colaborador pode gerar vários patches enquanto um mantenedor ainda revisa o primeiro. O remetente também pode sair após abrir a solicitação, enquanto o projeto herda todas as questões não resolvidas.

A reportagem original descreve isso como mais código para humanos verificarem. A formulação captura o problema imediato, mas a consequência mais ampla é mais grave.

Lançamentos de código aberto dependem de confiança delegada. Mantenedores decidem quais colaboradores, processos e artefatos são confiáveis o suficiente para entrar em uma compilação oficial. Portanto, um aumento de resultados não verificados cria trabalho de governança, não apenas trabalho de programação.

O relatório não afirma que toda contribuição assistida por IA seja ruim. Ele reconhece que a qualidade dos modelos pode melhorar. O problema não resolvido é que cada envio adicional ainda exige algum nível de julgamento humano.

Esse julgamento é especialmente caro quando o código gerado parece convincente. Um patch pode compilar e passar nos testes visíveis enquanto interpreta mal uma premissa não documentada. Ele também pode adicionar complexidade que parece inofensiva até que mudanças posteriores a exponham.

O relatório da ACM sobre IA em código aberto, portanto, altera a questão central. O problema já não é simplesmente se a IA torna desenvolvedores individuais mais rápidos. É se a capacidade de revisão em nível de projeto cresce junto com sua produção.

Esse reenquadramento cria o principal conflito do artigo: abundância gerada por máquinas versus confiança controlada por humanos.

Mantenedores de Código Aberto Enfrentam uma Lacuna de Capacidade de Revisão

Os projetos sob maior pressão não são necessariamente aqueles com o pior código. São aqueles com ampla adoção e poucos revisores qualificados.

Um revisor qualificado precisa de mais do que habilidade geral de programação. O revisor deve compreender a arquitetura do projeto, suas promessas de compatibilidade, o processo de lançamento e as expectativas da comunidade.

Esse conhecimento se desenvolve lentamente. Um projeto maduro pode ter milhares de usuários, mas apenas um pequeno grupo capaz de aprovar mudanças consequentes. Adicionar outro gerador de código não cria automaticamente outro revisor confiável.

O problema se torna mais agudo quando a IA atrai colaboradores de primeira viagem. A nova participação pode fortalecer uma comunidade de código aberto quando os colaboradores aprendem suas normas e, eventualmente, assumem responsabilidades de manutenção.

A revisão tradicional desempenhou parcialmente essa função de mentoria. Um mantenedor explica por que uma mudança precisa ser revisada, e o colaborador leva esse conhecimento para trabalhos futuros.

A participação mediada por máquinas pode romper essa troca. O mantenedor ainda gasta tempo explicando os requisitos do projeto, mas a pessoa que envia o código pode não compreender nem reter a lição.

Godot tornou essa preocupação explícita ao anunciar regras de contribuição mais rígidas em 30 de junho de 2026. O motor de jogos de código aberto disse que seu grupo de revisores qualificados era pequeno e que seu acúmulo de pull requests já era difícil de administrar.

Godot afirmou que a IA reduziu o esforço necessário para criar um pull request sem reduzir o trabalho necessário para revisá-lo. A fundação também questionou o valor de feedback que não capacita nem o colaborador nem um futuro mantenedor.

As regras planejadas proíbem agentes autônomos de IA e código substancialmente criado por IA. Elas também exigem responsabilidade humana e divulgação quando colaboradores usam assistência limitada de IA.

A política não é simplesmente uma rejeição ideológica da IA. É uma tentativa de proteger um recurso escasso: o tempo de revisores bem informados.

O risco vai além dos envios de código. Projetos podem receber relatórios de bugs gerados, propostas de recursos, descobertas de segurança e comentários em discussões. Cada item compete pela atenção dos mesmos mantenedores.

Um relatório de vulnerabilidade aparentemente detalhado pode ser particularmente caro. Revisores precisam determinar se a falha alegada existe antes de poder descartá-la com segurança. Um relatório fabricado pode consumir horas mesmo sem produzir uma correção.

Um preprint de julho de 2026 descreveu esse padrão como uma inundação de contribuições de IA. Os pesquisadores analisaram 294 repositórios contendo mais de dois milhões de pull requests e issues.

Eles relataram que o volume de pull requests aumentou durante 2025, enquanto as taxas de merge caíram. Colaboradores de participação única registraram uma queda de 18,18 por cento nas taxas de merge em relação ao contrafactual modelado pelo estudo.

Os pesquisadores também entrevistaram profissionais e pesquisaram 229 participantes de código aberto. Eles identificaram estratégias defensivas que iam de modelos de contribuição mais rigorosos a restrições mais amplas sobre envios externos.

Essas conclusões não estabelecem que a IA causou todas as solicitações rejeitadas. Estudos de repositórios também enfrentam limitações de classificação e comparação. Elas mostram por que mantenedores percebem o novo volume como um problema de capacidade.

Outro estudo de 2026 examinou 11.097 repositórios do GitHub entre janeiro de 2023 e maio de 2026. Ele relatou um aumento de 5,3 por cento na profundidade da revisão após projetos adotarem agentes de programação com IA.

A profundidade da revisão mede a intensidade da interação durante a revisão, não a qualidade do software final. Ainda assim, o aumento sustenta um mecanismo consistente: geração mais rápida transfere trabalho para a validação.

O resultado é uma lacuna de capacidade de revisão. O volume de contribuições pode expandir-se por meio de automação barata, enquanto a revisão confiável continua ligada à escassa especialização humana.

Programação Mais Rápida com IA Cria uma Troca entre Confiança e Segurança

A IA pode ajudar a reparar software de código aberto, mas a mesma velocidade pode ampliar oportunidades de ataque e sobrecarregar as pessoas responsáveis por lançamentos seguros.

O relatório da ACM sobre IA em código aberto apresenta a IA como uma capacidade de uso duplo. Modelos podem localizar vulnerabilidades e propor correções. Técnicas semelhantes podem ajudar atacantes a procurar fraquezas ou gerar contribuições maliciosas convincentes.

O CodeMender do Google ilustra a promessa defensiva. Segundo o Google, o agente contribuiu com 72 correções de segurança para projetos de código aberto entre abril e outubro de 2025.

Alguns projetos visados continham até 4,5 milhões de linhas de código. A automação pode ser valiosa nessa escala porque equipes humanas não conseguem inspecionar manualmente todos os caminhos.

No entanto, uma correção automatizada ainda entra no processo de confiança de um projeto. Mantenedores precisam verificar o diagnóstico, revisar o patch, avaliar testes e coordenar o momento do lançamento.

Esse processo se torna mais difícil quando uma aplicação depende de muitos pacotes separados. Cada componente tem seus próprios mantenedores, cronograma de lançamento e usuários downstream.

Um sistema de IA pode encontrar rapidamente fraquezas relacionadas em várias bibliotecas. O ecossistema não consegue necessariamente corrigir, lançar e implantar todos os componentes afetados na mesma velocidade.

Atacantes não enfrentam as mesmas responsabilidades. Eles podem gerar muitas hipóteses, abandonar falhas e explorar o primeiro resultado útil. Defensores precisam investigar descobertas plausíveis sem quebrar sistemas existentes.

Repositórios abertos também criam um risco para a cadeia de suprimentos. Um agente malicioso pode enviar um pacote, patch ou atualização de dependência que parece útil enquanto oculta comportamento indesejado.

A IA pode tornar esses envios mais polidos. Ela pode gerar testes, documentação e explicações detalhadas que criam uma aparência de cuidado. A qualidade da apresentação não estabelece procedência nem segurança.

É por isso que uma suíte de testes aprovada não pode servir como a única barreira. Testes representam expectativas conhecidas. Eles raramente cobrem todos os limites de segurança, ambientes incomuns ou custos de manutenção de longo prazo.

Revisores devem perguntar quem entende a mudança e quem irá repará-la depois. Eles também precisam determinar se dependências adicionadas, arquivos gerados ou padrões desconhecidos ampliam a superfície de ataque do projeto.

Essa questão de responsabilidade separa assistência de delegação. Um desenvolvedor pode usar IA e ainda ser capaz de defender cada escolha de design. Um colaborador que não consegue explicar o patch transfere essa responsabilidade ao projeto.

Organizações que usam código aberto herdam as consequências. Muitas equipes mantêm uma base de conhecimento técnico, mas ainda carecem de um mapa atualizado de suas dependências de software.

Uma lista de materiais de software, ou SBOM, fornece um inventário legível por máquina dos componentes de uma aplicação. Ela pode ajudar uma equipe de segurança a localizar uma biblioteca afetada após a divulgação de uma vulnerabilidade.

Uma SBOM não consegue mostrar se o componente tem mantenedores suficientes. Ela não pode revelar se pull requests não resolvidos estão se acumulando ou se a governança de um projeto enfraqueceu.

Ela também não consegue determinar se uma correção gerada por IA recebeu revisão adequada. O inventário é necessário, mas a consciência organizacional deve incluir a saúde do projeto e as práticas de manutenção.

A contrapartida, portanto, não é IA versus segurança. É velocidade sem responsabilização versus velocidade apoiada por revisão, rastreabilidade e responsabilidade clara.

A IA pode encurtar o caminho entre a descoberta e um patch candidato. Ela não pode eliminar a necessidade de comprovar que o patch pertence a uma versão confiável.

O Modelo de Financiamento Não Corresponde ao Valor do Código Aberto

A IA está aumentando as demandas sobre mantenedores em um ecossistema cujo valor econômico supera amplamente o financiamento que chega a muitos projetos individuais.

O relatório da ACM cita pesquisas que estimam que as empresas gastariam 3,5 vezes mais com software se o código aberto não existisse. O mesmo estudo de valor econômico estimou seu valor mundial, do lado da demanda para as empresas, em US$ 8,8 trilhões.

Esses números descrevem o custo que as organizações evitam ao usar software compartilhado. Eles não representam receita recebida pelos mantenedores.

Essa lacuna importa porque a manutenção de código aberto envolve muito mais do que escrever código. Projetos precisam de gestão de versões, documentação, suporte a usuários, empacotamento, testes, captação de recursos e moderação da comunidade.

A IA pode ajudar em partes desse trabalho. Ela não pode decidir as prioridades de um projeto nem conciliar divergências entre usuários, colaboradores e patrocinadores.

O relatório da ACM sobre IA e código aberto destaca uma comparação institucional marcante. A Linux Foundation informou receita de US$ 292.217.236 em 2024. A Apache Software Foundation informou US$ 2.379.402.

Essas organizações diferem em escopo e modelo operacional, portanto suas receitas não devem ser tratadas como uma comparação direta de desempenho. Ainda assim, o contraste demonstra como os recursos podem fluir de forma desigual pelo ecossistema de código aberto.

A desigualdade mais importante existe no nível dos projetos. Um componente amplamente usado pode não ter uma organização dedicada, contrato de suporte ou mantenedor em tempo integral.

Empresas podem criar serviços lucrativos sobre esse componente sem saber quem aprova as versões. Elas talvez só investiguem sua governança depois que surge uma vulnerabilidade, abandono ou mudança incompatível.

Esse é o problema do carona: usuários recebem valor de um recurso compartilhado sem contribuir proporcionalmente para sua manutenção. A IA não cria esse problema, mas pode intensificá-lo.

Uma empresa pode usar ferramentas de programação com IA para produzir alterações em uma dependência externa. Se seus engenheiros enviarem essas mudanças upstream, o projeto que as recebe assume o custo da revisão.

A empresa obtém geração de código mais barata. O mantenedor voluntário recebe mais uma proposta para validar.

Mesmo um patch útil impõe trabalho de coordenação. Os mantenedores precisam garantir que ele atenda à comunidade de usuários mais ampla, e não apenas aos requisitos privados do colaborador.

Envios de baixa qualidade impõem um custo externo maior. A organização que enviou a solicitação pode abandoná-la, enquanto o projeto precisa encerrá-la, explicar a decisão ou administrar o conflito resultante.

O financiamento pode ampliar a capacidade de revisão, mas dinheiro por si só não cria expertise instantaneamente. Um novo mantenedor ainda precisa de tempo para aprender o projeto e conquistar a confiança da comunidade.

Isso significa que o apoio deve ir além de recompensas de curto prazo por bugs. Os projetos precisam de financiamento contínuo para documentação, integração de novos colaboradores, infraestrutura de testes, empacotamento e planejamento de sucessão.

As recomendações do relatório da ACM refletem essa necessidade mais ampla. Ele pede maior atenção à sustentabilidade financeira e ao trabalho organizacional que mantém os projetos utilizáveis.

Compradores corporativos deveriam tratar isso como gestão da cadeia de suprimentos. Se uma dependência crítica é mantida por um único voluntário exausto, essa condição representa risco operacional.

Equipes de compras avaliam rotineiramente a estabilidade de fornecedores comerciais. Elas raramente aplicam escrutínio equivalente a pacotes de código aberto porque nenhuma fatura dispara essa revisão.

A pressão das contribuições com IA torna essa omissão mais difícil de justificar. Mais produção automatizada pode chegar a um projeto, enquanto sua capacidade humana permanece invisível para usuários downstream.

A questão do financiamento é, portanto, inseparável da questão da revisão. Um sistema que gera mais propostas sem financiar o julgamento aprofundará o gargalo.

Proibições Gerais de IA Protegem a Atenção, mas Podem Restringir a Participação

Regras mais rígidas podem preservar a capacidade de revisão no curto prazo, mas restrições mal elaboradas também podem bloquear colaboradores legítimos e enfraquecer os futuros fluxos de mantenedores.

Um projeto que enfrenta uma enxurrada de envios de baixo valor tem várias opções. Ele pode exigir divulgação, limitar o tamanho das contribuições, demandar testes reproduzíveis, restringir novos recursos ou proibir certas formas de uso de IA.

Cada regra altera quem arca com o custo. Um modelo detalhado de envio obriga colaboradores a explicar seu trabalho antes que um mantenedor comece a revisá-lo.

Exigências de permissão reduzem solicitações especulativas de recursos. Verificações automatizadas podem rejeitar erros de formatação ou testes ausentes antes da revisão humana.

Uma proibição geral oferece um limite mais claro, mas sua aplicação é difícil. Código gerado por IA não carrega um marcador técnico confiável, e trabalho escrito por humanos também pode ser ruim.

Ferramentas de detecção podem produzir falsos positivos. Colaboradores que escrevem em uma segunda língua ou usam recursos de acessibilidade podem ser questionados injustamente se textos bem redigidos se tornarem evidência de uso de IA.

Regras rígidas também podem dificultar a entrada de verdadeiros iniciantes. O código aberto depende de converter parte dos colaboradores de primeira viagem em participantes de longo prazo.

Se os projetos fecharem todos os caminhos acessíveis, poderão proteger os revisores de hoje enquanto reduzem o grupo de mantenedores de amanhã. Essa é a armadilha da sustentabilidade identificada por pesquisas recentes.

O relatório da ACM sobre IA e código aberto não oferece uma política universal de contribuição. A governança do código aberto permanece descentralizada, e os projetos variam amplamente em risco, escala e capacidade de revisão.

Um pequeno utilitário de linha de comando não pode copiar o processo de uma grande fundação. Uma biblioteca criptográfica deve aplicar requisitos de garantia diferentes dos de uma ferramenta experimental de design.

Ainda assim, as evidências dos mantenedores mostram amplo ceticismo. A pesquisa com mantenedores da Tidelift perguntou como o uso conhecido de IA afetaria a disposição para revisar contribuições.

Entre 344 respondentes, 64% disseram que estariam menos dispostos a revisar ou aceitar contribuições produzidas por IA. Nove por cento disseram que estariam mais dispostos, enquanto 27% não tinham certeza.

A pesquisa antecede os mais recentes agentes de programação, e as atitudes podem mudar à medida que as ferramentas melhoram. Ainda assim, ela mostra que a confiança nos colaboradores não pode ser presumida a partir da capacidade técnica.

O alvo mais justo das políticas é a responsabilização, não o estilo de escrita. Colaboradores devem entender suas alterações, divulgar automações relevantes, fornecer evidências e permanecer disponíveis para revisões.

Os projetos também podem separar assistência de baixo risco de delegação substancial. Conclusão de código, substituição mecânica e tradução podem gerar encargos diferentes do desenvolvimento autônomo de funcionalidades.

O tamanho da contribuição também importa. Um patch focado, com um bug reproduzido e testes direcionados, é mais fácil de avaliar do que uma refatoração ampla gerada sem discussão prévia.

Mantenedores precisam ter autoridade para encerrar envios que criam trabalho de revisão desproporcional. Também precisam de políticas que expliquem esse limite antes que colaboradores invistam tempo.

Plataformas como GitHub podem ajudar ao oferecer aos projetos controles de entrada mais robustos. Recursos úteis poderiam incluir permissões de contribuição, declarações estruturadas, limites de taxa e verificações específicas do repositório.

O suporte da plataforma não pode substituir a governança local. Ele pode reduzir o esforço administrativo necessário para aplicar as escolhas de cada comunidade.

O ponto cético continua importante: as evidências atuais não conseguem medir todo o trabalho assistido por IA. Colaboradores nem sempre divulgam o uso de ferramentas, e pesquisadores precisam inferir a adoção a partir de sinais incompletos.

Um aumento na atividade de revisão pode refletir projetos maiores ou mudanças nas populações de colaboradores. Isso não prova que cada comentário adicional de revisão represente produção nociva de máquinas.

As evidências disponíveis sustentam uma conclusão mais restrita. A capacidade de geração está crescendo mais rapidamente do que a capacidade de muitos projetos de validar contribuições, e os mantenedores estão respondendo com barreiras mais fortes.

Três Sinais Mostrarão se a Pressão Está Diminuindo

O próximo teste é saber se os projetos ganham capacidade de revisão, se as plataformas melhoram os controles de contribuição e se grandes usuários financiam as dependências das quais dependem.

O primeiro sinal é uma mudança mensurável nas filas dos repositórios. Pesquisadores e líderes de projetos devem acompanhar tempo de revisão, motivos de encerramento, taxas de integração e contribuições recorrentes.

Uma intervenção saudável deve reduzir envios de baixo valor sem eliminar iniciantes bem-sucedidos. Filas mais curtas, por si só, não bastam se os projetos as alcançarem fechando a participação externa.

A evidência mais robusta combinaria volume e qualidade. Projetos devem informar se as alterações aceitas exigem menos revisões, criam menos regressões e atraem colaboradores que permanecem envolvidos.

O segundo sinal é o suporte em nível de plataforma para a responsabilização. Hosts de repositórios podem tornar a divulgação e a verificação mais fáceis sem tentar identificar autoria por IA por meio de detecção pouco confiável.

Campos estruturados de envio poderiam exigir que colaboradores descrevessem os testes, explicassem escolhas de design e confirmassem sua capacidade de manter a alteração.

Os projetos também precisam de ferramentas para limitar tipos de contribuição de alto custo. Um mantenedor deve poder exigir discussão prévia para grandes refatorações ou envios de agentes autônomos.

Se as plataformas introduzirem esses controles, o diagnóstico do relatório da ACM sobre IA e código aberto ganha uma resposta operacional. Se elas se concentrarem apenas em aumentar a produção dos agentes, o desequilíbrio cresce.

O terceiro sinal é o financiamento contínuo de organizações que dependem de código aberto. Subsídios pontuais ajudam, mas a manutenção exige apoio recorrente e tempo remunerado de revisores.

As empresas devem identificar quais dependências afetam produção, segurança e conformidade. Em seguida, devem examinar concentração de mantenedores, atividade de lançamentos, qualidade da documentação e capacidade de resposta.

Um SBOM pode iniciar esse processo ao identificar componentes. A etapa mais difícil é conectar o inventário a decisões de propriedade, governança e investimento.

As equipes de segurança também devem distinguir disponibilidade de patch de implantação de patch. A IA pode encontrar uma falha rapidamente, mas produtos downstream podem permanecer expostos até que todas as dependências sejam atualizadas.

Esse atraso é em parte técnico e em parte organizacional. Um projeto com equipe reduzida pode se tornar o elo mais lento em muitos sistemas comerciais.

Desenvolvedores também têm responsabilidades. Qualquer pessoa que use uma ferramenta de programação com IA para trabalho de código aberto deve verificar a saída e compreender o código ao redor.

Um envio deve incluir uma declaração clara do problema, escopo focado, testes relevantes e uma explicação que o colaborador consiga defender sem consultar o modelo.

As organizações podem reduzir custos externos de revisão ao designar engenheiros experientes para apoiar suas alterações upstream. Elas não devem tratar mantenedores da comunidade como garantia de qualidade não remunerada.

Os mantenedores, por sua vez, precisam de permissão para projetar processos de contribuição em torno de sua capacidade real. Abertura não exige aceitar produção ilimitada e não verificada.

A oportunidade de longo prazo não é eliminar a IA do código aberto. É usar automação onde ela reduz trabalho repetitivo sem separar o código da responsabilidade humana.

A revisão assistida por IA pode, eventualmente, ajudar nesse equilíbrio. Pesquisas envolvendo 587 revisões de patch constataram que apenas uma minoria dos comentários gerados foi aceita diretamente, embora comentários adicionais tenham sido considerados úteis como orientação.

Esse resultado misto sugere que ferramentas de revisão podem apoiar o julgamento humano sem substituí-lo. Os projetos precisarão de evidências de seus próprios fluxos de trabalho antes de depender desses sistemas.

A inversão central permanecerá até que esses sistemas amadureçam. A geração de código está se tornando abundante, enquanto o julgamento contextual continua escasso.

Leitores que desenvolvem produtos com base em open source deveriam fazer três perguntas práticas. Quais dependências deixariam de receber atualizações seguras se um mantenedor saísse? Quem financia o trabalho de revisão delas? Como sua equipe responderia se envios automatizados consumissem a capacidade restante?

O relatório da ACM sobre IA em open source torna essas perguntas urgentes porque a pressão já é visível. Observe os acúmulos nos repositórios, os controles das plataformas e o financiamento recorrente da manutenção nos próximos meses.

Se os três melhorarem, a IA poderá se tornar uma contribuição líquida para a capacidade do open source. Se o volume de envios aumentar sem eles, uma programação mais rápida continuará produzindo uma confiança mais lenta.