Meta e Google desafiando o ecossistema da Nvidia

A Nvidia não ficou gigante só porque fez uma GPU rápida e mandou uma nota fiscal junto. Ela ficou gigante porque transformou um detalhe técnico em hábito cultural: a ideia de que “fazer IA de verdade” é, por definição, fazer IA em CUDA.

Isso é mais poderoso do que um chip. Um chip você troca quando aparece outro melhor. Um hábito você troca quando a dor de mudar fica menor do que a dor de continuar do mesmo jeito.

Durante anos, o mercado contou uma história confortável para explicar o domínio da Nvidia: “as GPUs são as mais avançadas”. Essa frase tem um pedaço de verdade, só que ela serve melhor como marketing do que como explicação. Se desempenho bruto fosse o único juiz, a coroa teria mudado de cabeça várias vezes. Houve gerações em que concorrentes ficaram perto, houve soluções mais baratas, houve momentos em que o custo por desempenho parecia tentador. Mesmo assim, quase ninguém fez a troca em massa.

Porque o trono da Nvidia não fica só no silício. O trono fica na camada onde as equipes gastam anos da vida: ferramentas, bibliotecas, kernels, rotinas de treino distribuído, perfiladores, receitas de otimização, tutoriais, exemplos, bugs conhecidos, jeitos de debugar, jeitos de contratar. Um ecossistema que vira padrão não precisa obrigar ninguém. Ele só precisa fazer o resto parecer trabalhoso.

E aí entra o que mudou, com o peso de um “clique” que desencaixa um império: Google e Meta estão mirando exatamente a peça que sustenta esse aprisionamento invisível, o software. Em dezembro de 2025, a Reuters noticiou que o Google está trabalhando num projeto interno chamado TorchTPU, com o objetivo de tornar as TPUs mais naturais para quem desenvolve em PyTorch, com colaboração próxima da Meta, grande apoiadora do PyTorch, e com possibilidade de abrir partes do software para acelerar adoção.

A ambição é simples de dizer e brutal de executar: permitir que empresas mudem de Nvidia para TPU sem precisar reescrever as partes críticas do código, sem desmontar o stack inteiro, sem abandonar PyTorch. Se essa fricção cair, a conversa deixa de ser “Nvidia ou caos” e vira “Nvidia ou concorrência”. A Nvidia pode continuar excelente e ainda assim perder a coisa que mais importa em mercados maduros: poder de barganha.

O lock-in que ninguém assina, mas todo mundo sente

Quando se fala em lock-in, muitos imaginam contrato, cláusula, exclusividade. No caso da Nvidia, a amarra é mais elegante, e por isso mais perigosa: ela se esconde no custo prático da mudança.

Uma equipe que diz “nosso modelo roda em PyTorch” geralmente quer dizer algo mais específico, mesmo que não verbalize: “nosso modelo foi escrito, treinado, ajustado, validado e colocado em produção num mundo em que CUDA era o chão”.

CUDA, na prática, virou o sistema nervoso periférico do stack de IA. Não é só “um jeito de rodar na GPU”. É um conjunto de escolhas acumuladas:

• bibliotecas de alto desempenho para operações essenciais,
• caminhos de precisão mista e quantização que foram refinados por anos,
• comunicação entre GPUs e entre nós de cluster, com soluções já testadas no inferno do tráfego real,
• profilers, ferramentas de debug, mecanismos de compilação, kernels otimizados e, talvez o mais importante, a “memória muscular” dos times.

Mudar isso não é trocar uma peça. É mexer na base do prédio enquanto tem gente morando dentro.

Por isso o lock-in da Nvidia sempre foi mais psicológico e operacional do que técnico. Em empresas, risco é uma moeda cruel. Risco de regressão, risco de instabilidade, risco de atraso, risco de gastar meses para descobrir que um detalhe do pipeline não tem equivalente. A conclusão prática era automática: ficar na Nvidia parecia racional, mesmo quando era caro.

E aqui tem um ponto curioso, quase irônico: a Nvidia nunca controlou o PyTorch. O PyTorch nasceu dentro da Meta e cresceu como projeto aberto, virando o framework dominante por mérito próprio, do laboratório à produção. O que a Nvidia fez, com genialidade de quem entende o jogo, foi se integrar tão bem que parecia dona.

Integração não é posse. Se o PyTorch ganhar um caminho “sem drama” para rodar bem fora de CUDA, a maior barreira de saída começa a virar poeira.

Por que “existem alternativas” nunca foi suficiente

“Mas já existem alternativas”, alguém sempre diz, e tecnicamente isso é verdade. AMD tem ROCm, Intel tem seus esforços, há aceleradores específicos, há chips especializados em inferência. Só que o mercado de IA em escala não premia apenas a existência de uma alternativa, ele premia uma alternativa que tenha três coisas ao mesmo tempo:

1. performance competitiva em cargas relevantes,
2. maturidade operacional, aquela sensação de “isso não vai me trair em produção”,
3. compatibilidade com o jeito que o mundo já trabalha.

A maioria falha na terceira. Algumas falham na segunda. Várias falham nas duas.

A Nvidia virou o “default” porque fez o caminho parecer inevitável. Não por decreto, por conforto. Quando tudo funciona, quando os tutoriais batem com a realidade, quando a equipe encontra respostas, quando dá para contratar gente que já sabe o stack, a escolha vira hábito. E hábito é um tipo de monopólio emocional.

É por isso que a movimentação do Google assusta: ela não tenta vencer a Nvidia “na pancada” só com hardware. Ela tenta vencer no ponto onde o hábito se forma, a experiência do desenvolvedor.

TPUs: o problema nunca foi músculo, foi idioma

As TPUs do Google sempre carregaram um ar de “poder oculto”, aquele tipo de hardware que a gente ouve falar como se fosse uma arma interna, restrita, feita para as necessidades do próprio Google. A leitura confortável para a Nvidia era: “isso não importa para o mercado, porque ninguém fora do Google usa”.

Só que essa leitura era superficial. O próprio Google Cloud descreve TPUs como aceleradores desenhados para treinamento e inferência de modelos de IA, e elas já sustentam cargas gigantes dentro do ecossistema do Google. O que travava a adoção ampla não era falta de desempenho. Era o idioma de software.

Por muito tempo, o Google apostou com força em JAX e no universo de compilação ligado ao XLA. De novo, tecnicamente faz sentido. Só que o mercado não funciona como seminário de compiladores. Enquanto o Google empurrava um caminho mais “puro”, o resto do planeta consolidava outro caminho: PyTorch.

Para a maioria das empresas, adotar TPU significava adotar um jeito diferente de pensar, adaptar pipelines, revalidar tudo, treinar equipe, e no final ainda ficar com a sensação de estar fora do fluxo principal da indústria. Empresas não migram frameworks por hobby. Elas migram quando são empurradas por dor extrema ou quando a migração é suave.

O que o TorchTPU tenta fazer é inverter a lógica: em vez de pedir que o desenvolvedor se adapte ao hardware, o hardware passa a “se adaptar” ao desenvolvedor.

“Mas já existe PyTorch em TPU”, então qual é o drama?

Aqui entra uma camada importante, que separa “dá para rodar” de “dá para viver”.

O mundo já tem, faz tempo, o PyTorch/XLA, que conecta PyTorch a dispositivos XLA como TPUs. Isso está documentado oficialmente e existe como projeto público. E até em notas antigas do próprio Google Cloud aparece a ideia de suporte via integração PyTorch/XLA.

Então por que ainda existe espaço para um TorchTPU “novo”?

Porque “rodar” não significa “rodar do jeito que o desenvolvedor espera”. Na prática, muitas integrações desse tipo carregam pequenas fricções que, somadas, viram um pedágio enorme: diferenças de cobertura de operadores, comportamentos inesperados, caminhos mais frágeis para debug, diferenças no desempenho por tipo de modelo, desafios de distribuição, tooling menos maduro, e um detalhe que virou central no PyTorch moderno: a experiência eager, aquela sensação de que você escreve o código e ele responde na hora, com o mesmo modelo mental em todo lugar.

Em outubro de 2025, surgiu no próprio repositório do PyTorch/XLA uma proposta explícita para evoluir a experiência e chegar mais perto de algo “nativo”, com a ambição de fazer tensor.to('tpu') parecer tão natural quanto tensor.to('cuda'). Esse é o tipo de frase que parece pequena, até você perceber o que ela realmente significa: transformar TPU de “backend especial” em “cidadão de primeira classe” dentro do PyTorch.

E isso muda o jogo porque reduz a parte mais cara da migração, a parte humana: reaprender o mundo.

O que o TorchTPU realmente ameaça na Nvidia

O mercado gosta de imaginar batalhas de hardware como corrida de cavalos: quem tem mais FLOPS, quem tem mais memória, quem tem mais largura de banda. Só que a Nvidia construiu uma fortaleza onde o hardware é apenas a muralha visível. O fosso está no software, e o fosso é feito de custo de troca.

O TorchTPU, pelo que foi reportado, mira exatamente isso: tornar TPUs amigáveis para o maior framework do planeta, sem exigir que times mudem seu código nem abandonem PyTorch, com colaboração da Meta, e com possibilidade de abrir partes do stack para ganhar tração mais rápido. Essa ameaça não é “as GPUs vão morrer”. Essa ameaça é “as GPUs deixam de ser a única resposta sensata”.

Em mercados de infraestrutura, “única resposta sensata” é como se fabrica margem alta. Quando o cliente não tem alternativa viável, ele aceita preço, prazo, pacote completo, aceitação resignada. Quando aparece uma alternativa boa o suficiente, o cliente não precisa nem migrar para já mudar a conversa. Ele só precisa conseguir dizer, com credibilidade: “eu posso ir embora”.

A Nvidia, por anos, vendeu previsibilidade. “Seu código roda aqui, seu time sabe mexer aqui, seu risco é menor aqui.” Isso sustenta múltiplos altos porque vira uma espécie de seguro embutido. Só que seguro perde valor quando a apólice concorrente fica boa.

Por que a Meta muda o peso específico dessa história

Se esse movimento viesse só do Google, parte do mercado trataria como mais um capítulo do “Google tentando competir com Nvidia”. O Google tem histórico de projetos tecnicamente brilhantes que demoram a virar hábito fora da própria casa.

A Meta muda isso por três motivos. Primeiro, porque a Meta tem interesse econômico brutal em diversificar. O custo de treinamento e inferência em escala de rede social global é um monstro que nunca dorme. Depender de um único fornecedor, num mercado com filas, prazos e preços agressivos, é aceitar fragilidade estratégica. Segundo, porque a Meta é o berço do PyTorch e continua sendo uma força determinante na sua evolução. Quando a empresa que ajudou a criar o framework participa da portabilidade de forma ativa, a chance de isso virar padrão aumenta, porque não é um “plugin lateral”, é o coração do ecossistema se mexendo. Terceiro, porque isso cria efeito cascata. Quando o criador do framework dá sinais de que múltiplos backends importam, ferramentas ao redor se adaptam, bibliotecas seguem, integradores entram, provedores oferecem suporte, e a profecia começa a se autorrealizar.

Esse ponto conversa com outra peça do tabuleiro: não é só software. O Google também tem buscado expandir o negócio de TPUs para fora do seu “jardim murado”, com reportagens indicando oferta de TPUs para uso em data centers de clientes e interesse de grandes compradores. Quando você junta “hardware disponível” com “experiência de PyTorch mais nativa”, o obstáculo deixa de ser filosófico e vira operacional, e isso é o tipo de coisa que compras e infraestrutura entendem muito bem.

O que muda quando “sair” deixa de ser impensável

Aqui é onde o mercado às vezes erra o foco. O preço da ação pode reagir pouco no começo porque o mundo ama narrativas simples, e a narrativa simples é: “Nvidia continua líder, ponto”. Só que a ameaça verdadeira costuma ser lenta, silenciosa e burocrática. Ela nasce em comitê de arquitetura, em prova de conceito, em planilha de custo por inferência.

Quando existe alternativa real, acontecem mudanças bem específicas:

• Negociação: o cliente passa a negociar preço e condições com mais força, mesmo sem trocar nada no curto prazo.
• Planejamento: times começam a desenhar pipelines com portabilidade em mente, para não serem reféns.
• Padronização: ferramentas passam a assumir múltiplos backends como normal, e isso reduz a vantagem do “default histórico”.
• Margem: margens caem antes da participação de mercado cair, porque o poder de precificação é o primeiro a sofrer.

A Nvidia não precisa perder o trono para perder poder. Ela só precisa deixar de ser inevitável.

A parte difícil que quase todo mundo subestima

A história seria fácil se bastasse “rodar PyTorch na TPU” e pronto. Não é assim. Construir paridade prática com CUDA em ambientes corporativos é o tipo de trabalho ingrato que exige anos de engenharia, testes e acertos finos. A própria existência de discussões públicas sobre tornar o backend mais “nativo” mostra que ainda há estrada pela frente.

Alguns desafios que costumam aparecer nesse tipo de migração, mesmo quando o código do modelo não muda:

• cobertura completa de operadores e casos de borda,
• estabilidade e previsibilidade em produção, com observabilidade madura,
• desempenho consistente em modelos variados, não só em benchmarks “favoráveis”,
• suporte a treinamento distribuído e inferência em escala com ergonomia de engenharia,
• ecossistema ao redor, como quantização, kernels customizados, serving, compilação, profiling.

O detalhe é que essa lista não precisa ficar perfeita para ameaçar o lock-in. Ela precisa ficar boa o suficiente em um subconjunto valioso, por exemplo, inferência massiva de modelos populares, ou treinamento de certas famílias de arquitetura. Em infraestrutura, atacar um pedaço muito caro do custo já é suficiente para criar “saídas” na fortaleza.

E a Nvidia, fica parada?

Seria estranho imaginar a Nvidia olhando isso de braços cruzados. Ela tem recursos, talento e uma vantagem real: maturidade de ecossistema, ferramental e rede de parceiros.

O que tende a acontecer, como dinâmica de mercado, é uma corrida em duas frentes:

1. A Nvidia reforça o valor do seu ecossistema, com melhores ferramentas, melhor performance, melhores bibliotecas, mais integração com frameworks, mais facilidades que façam o custo de ficar parecer ainda menor.
2. O resto do mercado tenta reduzir o custo de sair, criando caminhos compatíveis, “nativos”, que façam a troca parecer só uma decisão de infraestrutura.

O segundo ponto é exatamente o que torna TorchTPU interessante, e por que a participação da Meta é um multiplicador, não um detalhe.

O cenário mais plausível, se essa peça encaixar

Em vez de imaginar um “colapso” da Nvidia, a visão mais realista é um deslocamento gradual do centro de gravidade:

• no começo, TPUs viram alternativa crível para alguns workloads, principalmente onde custo por inferência pesa mais que qualquer outra coisa,
• depois, empresas começam a adotar postura multi fornecedor, mesmo mantendo Nvidia como base,
• com o tempo, a pressão competitiva aparece em preços, prazos e contratos, antes de aparecer em manchetes dramáticas.

Esse é o tipo de mudança que, vista de perto, parece lenta. Vista de longe, parece inevitável.

Uma última observação, que vale ouro para não cair em torcida: nada disso é destino. É uma hipótese de engenharia e mercado. Se o TorchTPU virar uma integração meia boca, se a experiência continuar “especial”, se o desempenho for inconsistente, se o suporte corporativo for frágil, a Nvidia segue com o fosso cheio de crocodilos. Se o TorchTPU entregar uma experiência realmente banal, previsível e eficiente, aquela palavra que sustenta impérios, inevitável, começa a perder o sentido.

---

Referências

Exclusive: Google works to erode Nvidia's software advantage with Meta's help https://www.reuters.com/business/google-works-erode-nvidias-software-advantage-with-metas-help-2025-12-17/

Cloud Tensor Processing Units (Cloud TPUs) https://cloud.google.com/tpu

PyTorch/XLA https://github.com/pytorch/xla

Evolving PyTorch/XLA for a more native experience on TPU https://github.com/pytorch/xla/issues/9684

Cloud TPU release notes https://docs.cloud.google.com/tpu/docs/release-notes

Meta and Google could be about to sign a mega AI chip deal - and it could change everything in the tech space https://www.techradar.com/pro/meta-and-google-could-be-about-to-sign-a-mega-ai-chip-deal-and-it-could-change-everything-in-the-tech-space

Leia Mais

O desenvolvimento da tecnologia e economia

Um jeito para começar é admitir o óbvio que esquecemos: a economia global é, em grande parte, um gigantesco sistema de informação disfarçado de “mercado”. Dinheiro é informação. Preço é informação. Juros são informação. Estoque parado em um galpão é informação atrasada, quase sempre cara. Quando você olha por esse ângulo, tecnologia deixa de ser “um setor” e vira um tipo de infraestrutura cognitiva que permite que bilhões de decisões descentralizadas aconteçam com menos atrito.

E é aqui que a conversa fica interessante: o que chamamos de “desenvolvimento tecnológico” não é só a invenção de novas possibilidades, é a criação de meios para reduzir incerteza, coordenar ações e automatizar confiança. Parece abstrato? Vamos entender melhor isso.

Pensa num produtor de café no interior de Minas Gerais no Brasil, negociando com uma torrefadora na Europa. Décadas atrás, esse contrato dependia de telefonemas, intermediários, papelada, bancos correspondentes, prazos longos, taxas gordas e uma boa dose de fé. Hoje, ele pode acompanhar preço em tempo real, travar parte do risco com instrumentos financeiros acessíveis, emitir nota, rastrear logística e receber em prazos menores. A colheita é a mesma, o que mudou foi o “sistema nervoso” que conecta oferta e demanda.

Esse sistema nervoso é feito de tecnologias atuais que costumamos tratar como coisas separadas: computação em nuvem (infraestrutura sob demanda, paga conforme uso), redes móveis, plataformas, APIs (interfaces de programação de aplicações, “tomadas” digitais que conectam sistemas), aprendizado de máquina (modelos estatísticos que aprendem padrões a partir de dados), criptografia (técnicas matemáticas para proteger e validar informação). Só que o efeito econômico aparece quando elas se combinam e viram capacidade de coordenação.

Coordenação é uma palavra que soa burocrática, só que ela é uma das forças mais caras do mundo. Em economia, existe um conceito útil chamado custo de transação (o custo de buscar informação, negociar, fiscalizar, garantir cumprimento). Se um país inteiro consegue reduzir custos de transação, ele “ganha produtividade” mesmo sem descobrir um novo mineral, mesmo sem aumentar a área plantada, mesmo sem achar um motor mágico. Ele passa a fazer mais com o que já tem. Isso ajuda a explicar por que softwares e sistemas, que parecem etéreos, conseguem mexer em coisas tão materiais quanto inflação, emprego e crescimento.

Aí aparece uma pergunta que incomoda: se tecnologia melhora produtividade, por que tantos sente a vida mais cara e mais instável? A resposta é bem mais complexa, é um conjunto de camadas. Ganhos de produtividade nem sempre viram salário, nem sempre viram preço mais baixo, às vezes viram concentração de mercado, às vezes viram novos custos (assinaturas, taxas, dependência), às vezes viram velocidade demais para instituições lentas. Tecnologia resolve problemas e cria outros, e os novos problemas costumam ser mais sutis.

Vamos falar de desenvolvimento de sistemas, porque é ali que a economia vira prática. “Sistema”, no mundo real, é uma rede de decisões automatizadas. Um ERP (Enterprise Resource Planning, software que integra finanças, estoque, compras e produção) não é só um programa, é um jeito de impor uma gramática à empresa: como se compra, como se registra, como se mede, como se audita. Quando uma empresa adota um ERP, ela está escolhendo um modelo de mundo. Essa escolha pode aumentar eficiência, mas também pode engessar processos ou esconder vieses, dependendo de como foi configurado.

Quem nunca ouviu alguém dizer “o sistema não deixa”? Esse “não deixa” é economia em ação. É governança (conjunto de regras e mecanismos de controle) codificada. E governança codificada pode ser maravilhosa quando reduz fraude e desperdício, pode ser péssima quando impede exceções humanas necessárias. Um hospital, por exemplo, precisa de protocolos; um protocolo rígido demais pode virar crueldade logística.

Essa ambivalência fica ainda mais forte quando sobemos para o nível global. Cadeias de suprimento modernas são sistemas distribuídos (partes independentes que cooperam por meio de comunicação e padrões). Distribuído aqui não é só “espalhado”, é um desenho em que cada nó toma decisões localmente, seguindo regras comuns. Isso dá resiliência, mas também abre portas para falhas sistêmicas: um porto congestionado, uma falta de semicondutores, um ataque cibernético, uma pandemia. O mundo fica eficiente e frágil ao mesmo tempo. Eficiência não é sinônimo de robustez; às vezes é o contrário.

A economia global vem buscando soluções justamente nesse dilema: como manter a produtividade sem aumentar a fragilidade? Uma resposta forte é observabilidade (capacidade de medir o que está acontecendo dentro de sistemas complexos a partir de dados e sinais). Observabilidade começou como um tema de engenharia de software, com logs, métricas e rastreamento. Hoje, ela virou peça econômica. Empresas querem enxergar seus fluxos quase como um organismo enxerga seus próprios batimentos.

E aqui aparece um ponto-chave: tecnologia não “cria riqueza” do nada; ela reorganiza informação, tempo e confiança. Quando você reorganiza esses três elementos, você altera o custo de coordenação e, por extensão, altera a produtividade. Esse é um dos motores discretos da economia digital.

Repara como esse ponto é menos glamouroso do que dizer “IA vai revolucionar tudo”. Só que ele explica mais. E por explicar mais, ele incomoda mais.

Falando em IA, o aprendizado de máquina não é “inteligência” no sentido humano; é uma coleção de técnicas para estimar funções a partir de dados, encontrando padrões úteis para previsão ou classificação. Um modelo pode prever inadimplência com boa precisão e ainda assim ser injusto, porque aprende padrões do passado, e o passado tem desigualdades. Se bancos automatizam crédito usando esses modelos, a economia ganha eficiência operacional, só que pode ampliar exclusão financeira se não houver governança e auditoria.

Auditoria algorítmica (processos para avaliar desempenho, vieses e impactos de modelos) vira um tema econômico porque crédito é energia do capitalismo. Crédito define quem investe, quem cresce, quem quebra. Um erro em escala não é um bug simpático, é uma força social.

Em desenvolvimento de sistemas, isso se traduz em uma mudança de mentalidade: não basta “funcionar”, precisa ser confiável, explicável em certo grau, seguro, compatível com leis, compatível com valores sociais. “Compatível com valores” pode soar moralista, só que é só realismo: sistemas moldam comportamento. Um aplicativo de transporte redefine como a cidade se move. Um marketplace redefine como pequenos vendedores competem. Uma plataforma de pagamentos redefine como informalidade vira formalidade, ou como novas taxas corroem margens.

Plataformas são outro conceito que merece definição, no sentido econômico, é uma estrutura que conecta grupos diferentes (por exemplo, compradores e vendedores) e cria efeitos de rede (quanto mais gente usa, mais valioso fica). Efeito de rede é poderoso porque gera concentração natural: as pessoas preferem onde já tem gente. Isso pode aumentar eficiência e reduzir custo de busca, mas também pode criar dependência e poder de mercado.

Você sente isso quando um pequeno negócio se torna refém de um app de entrega. O app resolve logística e acesso a clientes, só que cobra taxas, define regras, pode mudar o algoritmo de exposição. A empresa “ganha” mercado e “perde” autonomia. Economia digital é cheia dessas trocas: eficiência por controle.

E por falar em controle, a infraestrutura invisível do mundo atual é a nuvem. Nuvem não é “um lugar”; é um modelo de computação em que recursos são provisionados sob demanda, em data centers gigantes, com contratos e camadas de serviço. Isso permite que uma startup tenha poder computacional de corporação sem comprar servidores. É um choque de democratização produtiva. Só que também cria concentração: poucos provedores controlam a infraestrutura central de milhares de empresas. Um apagão na nuvem vira um mini-terremoto econômico.

Quando o tema é economia global, tecnologias que reduzem barreiras de entrada importam muito. Barreira de entrada é tudo aquilo que impede alguém de competir: capital inicial alto, necessidade de escala, regulação difícil, acesso a distribuição. Nuvem, ferramentas open source, pagamentos digitais e logística integrada baixam algumas barreiras. Isso explica por que tantos microempreendedores surgem e também explica por que a competição fica brutal. Se é mais fácil entrar, é mais fácil ser esmagado. O mercado vira um estádio com mais jogadores e regras mais rápidas.

Vamos dar um salto para um assunto que costuma passar: padrões. Padrão é chato, e exatamente por isso ele é revolucionário. Um padrão de dados (por exemplo, um formato de nota fiscal eletrônica, um protocolo de pagamento, um esquema de interoperabilidade) permite que sistemas “conversem” sem negociação individual. Interoperabilidade (capacidade de sistemas diferentes trocarem informação e operarem juntos) é uma forma de infraestrutura pública, mesmo quando é feita por consórcios privados.

Quando um país cria um sistema de pagamentos instantâneos, o efeito econômico não é só conveniência. Pagamentos instantâneos reduzem capital de giro necessário (dinheiro parado para cobrir prazo), reduzem risco de liquidação, permitem novos modelos de negócio e também aumentam rastreabilidade, o que muda a dinâmica de informalidade e arrecadação. A solução parece “tecnológica”, mas a consequência é macroeconômica.

Macroeconomia, aliás, vive sendo tratada como um bicho separado. Só que desenvolvimento de sistemas mexe com macroeconomia porque mexe com a velocidade do dinheiro, com a competição, com a formação de preços. Quando marketplaces comparam preços em milissegundos, o varejo muda. Quando algoritmos otimizam rotas, o custo logístico muda. Quando fintechs usam dados alternativos para crédito, o spread (diferença entre custo de captação e taxa cobrada) pode cair para alguns e subir para outros. Tudo depende de desenho, regulação e poder de mercado.

Regulação é outra palavra que costuma ser pintada como vilã ou heroína, quando ela é, na prática, um mecanismo de sincronização entre tecnologia e sociedade. Sem regulação, incentivos podem premiar o atalho perigoso: coletar dados demais, explorar trabalho, externalizar risco. Com regulação mal desenhada, você mata inovação e cria cartéis involuntários. O ponto difícil é calibrar.

E calibrar exige entender como inovação acontece. Existe uma visão ingênua de que inovação é um gênio inventando algo e pronto. No mundo real, inovação é uma cadeia: ciência básica, engenharia, produto, mercado, feedback, iteração, padronização, escala. Desenvolvimento de sistemas é o motor dessa iteração porque transforma hipótese em serviço operável. Operável significa rodar com milhões de usuários, com falhas previstas, com segurança, com monitoramento. Isso é uma ciência aplicada de altíssimo nível, mesmo quando é vendida como “um app”.

Segurança merece um parágrafo inteiro, porque ela é uma variável econômica. Cibersegurança (proteção de sistemas contra acesso indevido e ataques) custa dinheiro, e ataques também custam dinheiro, só que o custo aparece em lugares diferentes. Quando uma empresa economiza em segurança, ela reduz despesa hoje e aumenta risco sistêmico amanhã. Em escala global, isso é parecido com poluição: o incentivo individual pode produzir dano coletivo. A diferença é que o dano pode ser instantâneo e invisível. Um ransomware em hospital não é um incidente “digital”, é um incidente humano.

Aí volta a pergunta: tecnologia está “dando soluções” para a economia global? Sim, em vários sentidos mensuráveis: reduz custos de coordenação, amplia acesso, acelera inovação, melhora eficiência energética em alguns setores, otimiza recursos escassos. Só que ela também cria dilemas novos: concentração, precarização em alguns modelos, dependência de infraestrutura, assimetrias de informação ainda mais sofisticadas, e uma espécie de ansiedade sistêmica, porque o mundo fica mais rápido do que nossa capacidade de deliberar.

Talvez a parte mais delicada seja a assimetria de informação. Assimetria de informação é quando uma parte sabe muito mais do que a outra numa transação. A economia clássica já sabia que isso gera problemas: seleção adversa, moral hazard. No mundo digital, assimetria de informação vira uma arte. Plataformas sabem padrões de consumo, elasticidade de preço (o quanto a demanda muda quando o preço muda), propensão a compra, horários, renda provável. Isso permite personalização, o que pode ser ótimo, e também permite discriminação de preços, o que pode ser abusivo se não houver transparência.

E é aqui que dá para reforçar aquele ponto-chave: o eixo oculto dessa história é confiança automatizada. Quando sistemas conseguem registrar, validar e prever, eles substituem partes do tecido social que antes dependiam de instituições lentas ou relações pessoais. Essa substituição reduz fricção e aumenta produtividade, só que muda o poder de quem controla os mecanismos de validação. Quem decide o que conta como “verdade” no sistema? Quem tem o botão de desligar? Quem audita o auditor?

A economia global, hoje, é uma disputa por governança de infraestrutura digital. Não é só sobre gadgets. É sobre camadas: camada de dados, camada de computação, camada de pagamento, camada de identidade, camada de logística, camada de reputação. Reputação é especialmente interessante. Sistemas de reputação (notas, avaliações, histórico) resolvem um problema antigo: como confiar em estranhos. Eles fazem isso transformando comportamento em números. Só que números viram incentivos, e incentivos mudam comportamento. O motorista corre para manter nota, o vendedor implora avaliação, o consumidor usa a avaliação como arma.

Esse detalhe puxa outro: inovação técnica frequentemente resolve um gargalo e empurra o gargalo para outro lugar. Se você otimiza logística, o gargalo pode virar embalagem. Se você otimiza crédito, o gargalo pode virar inadimplência em crise. Se você otimiza produção, o gargalo pode virar descarte e sustentabilidade. Solução local, problema global. Um olhar científico pede que a gente trate isso como sistema dinâmico (sistema que muda no tempo com feedbacks). Feedback é quando uma saída do sistema volta como entrada e altera o comportamento. Mercados estão cheios de feedbacks: preço sobe, demanda cai, produção ajusta, preço cai. Tecnologia acelera esses loops.

A aceleração pode ser saudável ou caótica. Em mercados financeiros, por exemplo, automação e alta frequência tornaram o sistema mais eficiente em condições normais e mais propenso a eventos rápidos em condições extremas. Eficiência média e risco de cauda (eventos raros, muito danosos) podem andar juntos. Economia global vive tentando colher eficiência sem pagar a conta das caudas.

E o que isso tem a ver com desenvolvimento de sistemas? Tudo, porque sistemas são a forma concreta como esses loops são implementados. Um bug num sistema de precificação pode gerar uma cascata. Um erro num sistema de estoque pode causar desperdício em massa. Um erro num modelo de previsão pode gerar falta de produto, inflação localizada, perda de confiança. Quando tudo é conectado, pequenos erros ganham alavanca.

É por isso que engenharia de software moderna fala tanto de capacidade de continuar operando sob falhas e de testes intencionais de falhas para entender comportamento. Parece papo de dev, só que é economia aplicada. Uma empresa aguenta choques sem quebrar, uma cadeia resiliente reduz risco de desabastecimento; um setor resiliente evita que um incidente local vire crise macro.

O desafio prático, para quem constrói sistemas e para quem pensa economia, é reconhecer que “solução” raramente é um objeto, solução é um arranjo. Arranjo de incentivos, de padrões, de governança, de auditoria, de infraestrutura e de cultura. Quando esse arranjo é bem desenhado, tecnologias atuais viram ferramentas de prosperidade distribuída. Quando é mal desenhado, viram amplificadores de desigualdade e fragilidade.

Leia Mais

Engenharia de software moderna

Software virou infraestrutura social. Ele está no banco, no hospital, no transporte, no comércio, na escola, no governo, no entretenimento, na logística, na indústria, no celular que acorda você e no sistema que decide se uma transação deve ser bloqueada. Essa presença ubíqua cria uma exigência dupla: de um lado, velocidade de entrega e adaptação a mudanças; de outro, confiabilidade, segurança e previsibilidade. O ponto central da engenharia de software, como disciplina, é lidar com essa tensão sem cair em dois extremos igualmente perigosos: improviso permanente (que reduz custo hoje e multiplica custo amanhã) e burocracia rígida (que dá sensação de controle, mas entrega pouco valor real).

Um modo de organizar o tema é pensar que engenharia de software não é “programar melhor”, e sim projetar, construir, verificar, medir, operar e evoluir sistemas com métodos que reduzam risco. Programação é parte do processo, mas o problema real é sistêmico: requisitos mudam, ambientes variam, integrações falham, pessoas interpretam de formas diferentes, a complexidade cresce, o produto envelhece por mudança e pressão de prazo produz atalhos. A disciplina existe para transformar esse cenário em um trabalho mais controlável, repetível e auditável.

Teste em aplicações Web: variabilidade, estado e integração contínua

Aplicações para Web têm um conjunto de características que ampliam o espaço de falhas possíveis. Primeira característica: heterogeneidade do ambiente. Um mesmo sistema precisa funcionar em navegadores distintos, versões diferentes, sistemas operacionais variados, tamanhos de tela diversos, conexões instáveis e contextos de uso imprevisíveis. Segunda: composição por camadas, tipicamente interface, serviços, banco de dados, cache, autenticação, mensageria, serviços externos. Terceira: alta dependência de rede, o que inclui latência, perda de pacotes, variações de banda e indisponibilidades parciais. Quarta: ritmo frequente de atualização, com deploys contínuos e mudanças incrementais.

Do ponto de vista prático, o teste em Web precisa ser visto como um conjunto de estratégias complementares. Testes de unidade ajudam a validar funções e componentes isolados; testes de integração verificam a interação entre módulos e serviços; testes de sistema avaliam o comportamento do produto como um todo; testes de regressão protegem contra efeitos colaterais de mudanças. Em Web, um desafio recorrente é o estado: sessão, cookies, tokens, armazenamento local, cache, filas, idempotência e concorrência. Falhas aparecem quando uma sequência de ações cria um estado raro, que não foi antecipado. Por isso, testes baseados em cenários (ou roteiros) têm relevância: eles simulam fluxos reais do usuário, incluindo caminhos de erro, expiração de sessão, reautenticação, interrupção de rede, repetição de requisições e comportamento sob latência.

Outro aspecto didático é separar testes funcionais (o sistema faz o que deve fazer) de testes não funcionais (o sistema atende propriedades como desempenho, disponibilidade, segurança, usabilidade). Em aplicações Web, ignorar não funcionais costuma ser caro, porque a percepção do usuário é dominada por tempo de resposta, clareza de erros e confiabilidade. Um sistema que “funciona” mas trava sob carga, ou retorna mensagens confusas, é percebido como defeituoso. Essa percepção tem impacto direto em adoção, conversão, suporte e reputação.

Automação torna-se quase obrigatória em Web quando há ciclos curtos de release. Testes manuais têm valor exploratório e ajudam a descobrir comportamentos inesperados, mas não escalam como barreira de regressão. Uma abordagem robusta combina: suíte automatizada rápida (executada a cada commit), suíte mais abrangente (executada em pipeline), testes de aceitação automatizados para fluxos críticos e monitoramento pós-deploy com métricas e alertas. Essa combinação não elimina falhas, só desloca o sistema para um regime mais controlado de detecção e resposta.

Teste de aplicativos móveis: fragmentação, sensores e condições reais

Aplicativos móveis adicionam complexidades próprias. O ecossistema é fragmentado: fabricantes, modelos, versões do sistema operacional, restrições de energia, gerenciamento agressivo de processos, permissões que variam por versão, políticas de armazenamento, APIs que mudam. O app também conversa com hardware: câmera, GPS, microfone, acelerômetro, biometria, Bluetooth, NFC. Há ainda o contexto de mobilidade: o usuário alterna de rede Wi-Fi para 4G/5G, atravessa áreas sem sinal, troca de orientação de tela, recebe notificação, muda de app, volta, bloqueia a tela, reabre, reinicia o aparelho.

Essa realidade cria uma regra prática: testar em emulador é necessário, mas insuficiente. Emuladores aceleram desenvolvimento e cobrem parte do espaço, só que diferenças de desempenho, sensores e políticas de energia fazem bugs aparecerem apenas em dispositivos reais. Um programa de testes minimamente científico para mobile precisa considerar amostras representativas de dispositivos e versões, além de testes voltados a interrupções: chamadas, notificações, perda de rede, mudança de permissões, falta de espaço, atualização do sistema, reinício forçado do processo. Também se torna importante avaliar consumo de bateria, uso de memória e impacto térmico, porque essas dimensões influenciam diretamente estabilidade e avaliação do usuário.

No mobile, a disciplina de qualidade se beneficia de uma separação clara entre lógica de negócio e camadas de interface. Quanto mais o núcleo do sistema é testável de forma isolada, menor a dependência de testes de interface “frágeis” (que quebram com pequenas mudanças visuais). A arquitetura influencia testabilidade. Arquiteturas com boa modularidade favorecem testes unitários e testes de integração bem focados, reduzindo o custo de regressão.

Engenharia de segurança: ameaça, vulnerabilidade e controle contínuo

Segurança não é um evento, é um processo. Em sistemas conectados, a superfície de ataque é permanente: credenciais, tokens, APIs, dependências, configurações de nuvem, armazenamento, logs, integrações, dispositivos. Um erro de permissão, uma biblioteca vulnerável, um segredo exposto, uma validação ausente ou uma configuração permissiva pode ser suficiente para comprometer dados. Isso vale tanto para Web quanto para mobile, sistemas corporativos e aplicações públicas.

Um modelo didático útil é separar ameaça (o que pode atacar), vulnerabilidade (o que pode ser explorado), impacto (o dano potencial) e probabilidade (o quão viável é a exploração). Esse raciocínio estrutura gestão de risco em segurança. Em engenharia, fala-se também em princípios como menor privilégio, defesa em profundidade, validação de entrada, auditoria, criptografia adequada, segmentação, rotação de segredos, política de atualização e resposta a incidentes.

Há uma nuance relevante: segurança precisa ser tratada desde requisitos e projeto, não apenas no fim. O motivo é simples. Certas propriedades não podem ser “coladas” depois com baixo custo. Se a arquitetura não prevê isolamento de dados, rastreabilidade de ações e controle de acesso consistente, a correção tardia tende a ser invasiva e cara. Abordagens formais de modelagem de ameaças e revisão de projeto ajudam a reduzir surpresas. Em termos práticos, a disciplina se manifesta em pipeline (análise de dependências, varredura de vulnerabilidades, verificação de configuração), em código (revisão, padrões seguros), em operação (monitoramento, alertas, resposta a incidentes) e em governança (políticas, treinamento, auditoria).

Modelagem formal e verificação: quando testar não basta

Testes demonstram a presença de defeitos, não provam sua ausência. Em sistemas críticos, essa limitação é mais séria. Modelagem formal e verificação entram como ferramentas para reduzir incerteza em propriedades específicas: correção lógica, invariantes, ausência de certos tipos de falha, consistência de protocolos. Em termos simples, métodos formais constroem modelos matemáticos do comportamento do sistema e permitem provar propriedades sob hipóteses definidas.

Essas técnicas não são uma substituição universal para teste. O custo de modelagem, a complexidade do domínio e o grau de formalização necessário podem ser altos. O uso mais comum e eficaz é em partes onde o risco é elevado: algoritmos de consenso, controle de acesso, protocolos de autenticação, lógica de segurança, mecanismos de concorrência, sistemas embarcados críticos. Em contextos não críticos, técnicas formais ainda podem aparecer como verificações pontuais, contratos, tipos mais expressivos, análise estática e provas parciais. O objetivo é o mesmo: reduzir o espaço de comportamentos inesperados onde um defeito é caro demais para ser descoberto apenas em produção.

Gestão de configuração: controlar mudança para preservar integridade

Em software, a mudança é inevitável. A disciplina que permite mudar sem perder controle é a gestão de configuração. Ela envolve versionamento, rastreabilidade, controle de builds, gerenciamento de branches, estratégia de releases, controle de artefatos, política de merge, revisão de código e gestão de dependências. O objetivo é manter o sistema reprodutível: conseguir responder “o que foi entregue?”, “qual versão está em produção?”, “quais mudanças entraram neste release?”, “como reproduzir o build?”, “qual dependência mudou e por quê?”.

Sem gestão de configuração, a organização entra em uma zona de risco operacional: builds não reproduzíveis, correções que se perdem, regressões que reaparecem, divergência entre ambientes, dependências inconsistentes, hotfixes aplicados “direto em produção”. A complexidade moderna, com microserviços, múltiplas pipelines e infra como código, torna a disciplina ainda mais importante. Controle de mudança não significa impedir mudança; significa torná-la observável e reversível.

Métricas de produto: medir para decidir

Métricas existem para apoiar decisão. Métricas de produto podem olhar para tamanho, complexidade, qualidade e comportamento em operação. Medidas como densidade de defeitos, complexidade ciclomática, cobertura de testes, acoplamento, coesão, duplicação e taxa de falhas em produção podem orientar ações de melhoria. Métricas operacionais como latência, taxa de erro, disponibilidade, consumo de recursos e tempo de recuperação também entram na avaliação.

Há um cuidado metodológico: toda métrica é um modelo simplificado. Se ela vira alvo, tende a ser manipulada, consciente ou inconscientemente. Medir linhas de código como produtividade, por exemplo, distorce comportamento: incentiva verbosidade e reduz refatoração. Uma prática mais madura liga métricas a objetivos claros: reduzir incidentes, aumentar confiabilidade, melhorar previsibilidade, diminuir tempo de ciclo, reduzir custo de manutenção. Métrica deve ser contextualizada por domínio e risco. O que é aceitável em um protótipo não é aceitável em um sistema financeiro. O que é suficiente em um produto interno pode não bastar em escala pública.

Métricas de processo e projeto: capacidade, estabilidade e melhoria contínua

Métricas de processo observam como o trabalho flui: lead time, throughput, taxa de retrabalho, frequência de deploy, tempo de correção, taxa de falhas pós-release. Métricas de projeto procuram entender esforço, custo, prazos e aderência a planos, sempre reconhecendo incerteza. Em termos didáticos, processo não é “como deveria ser”, é “como realmente acontece”. Se a organização mede com honestidade, consegue identificar gargalos, desperdícios e causas de variabilidade.

Melhoria de processo é um tema que tende a ser mal interpretado como “implantação de um framework”. A parte científica é outra: identificar problema, coletar evidências, propor mudança, medir resultado, ajustar. Processo é um sistema socio­técnico: pessoas, ferramentas, comunicação, cultura, incentivos, restrições. A mesma prática pode funcionar bem em um time e falhar em outro por motivos de contexto. Melhorar processo exige experimentação controlada e feedback.

Estimativas: lidar com incerteza de modo explícito

Estimativa em software não é adivinhação, é modelagem sob incerteza. O problema é que software envolve descoberta. Muitas vezes não se sabe, no início, o que será necessário para satisfazer necessidades reais do usuário. Mesmo quando o requisito é claro, a solução pode ser incerta por causa de integrações, desempenho, migrações, dados legados, variabilidade de ambiente, dependências externas.

Estimativas robustas costumam decompor o trabalho, identificar riscos e construir faixas, não números únicos. Elas se beneficiam de histórico (dados de projetos anteriores), de modelos paramétricos (quando aplicáveis) e de revisão iterativa conforme o entendimento melhora. Em termos de gestão, uma estimativa madura vem acompanhada de premissas: o que está dentro do escopo, o que está fora, quais dependências existem, qual nível de qualidade é exigido, quais incertezas permanecem, quais critérios definem “pronto”. Sem premissas, estimativa vira promessa, e promessa vira conflito quando a realidade muda.

Cronograma: coordenação, dependências e visibilidade de progresso

Cronogramas em software têm utilidade quando refletem dependências reais e quando incorporam margens para incerteza. O erro recorrente é tratar cronograma como instrumento de pressão, não de coordenação. Quando o prazo vira dogma, o time tende a sacrificar teste, refatoração, revisão e documentação. O resultado costuma ser uma entrega rápida que cria custo elevado de manutenção e regressão, com efeito líquido negativo no médio prazo.

Um cronograma didático e racional liga atividades a entregas verificáveis: protótipos, incrementos, releases, validações. Ele mapeia dependências externas (por exemplo, aprovação regulatória, integração com fornecedor, dados disponíveis, infraestrutura pronta). Ele descreve marcos que podem ser auditados por evidência, não por sensação. Em engenharia, progresso não é “percentual”, é capacidade de demonstrar comportamento funcionando em condições definidas.

Gestão de riscos: antecipar, mitigar e preparar resposta

Risco é a combinação de probabilidade e impacto. Em projetos de software, riscos comuns incluem: requisitos instáveis, subestimação de esforço, dependências externas, dívida técnica acumulada, falta de dados de produção, falhas de segurança, indisponibilidade de pessoal-chave, complexidade arquitetural, mudanças de prioridade, limitações de infraestrutura, ausência de testes, migrações mal planejadas.

Gestão de risco não é pessimismo, é engenharia. Identificar riscos cedo permite mitigação com custo menor. Mitigar pode significar prototipar cedo uma integração crítica, criar ambientes de teste realistas, automatizar regressão, endurecer segurança, reduzir escopo, fatiar entregas, treinar equipe, revisar arquitetura, criar planos de rollback. Também envolve monitorar sinais. Um risco não some porque foi escrito em um documento; ele exige acompanhamento.

Manutenção e reengenharia: o ciclo de vida real do software

A maior parte do custo de um sistema, ao longo do tempo, está na manutenção. Manutenção inclui correção de defeitos, adaptação a mudanças externas, melhoria de desempenho, evolução funcional, refatoração e ajustes de segurança. O motivo é estrutural: sistemas vivem em ambientes que mudam. Não é realista imaginar que um software possa ser “finalizado” e permanecer estável. A engenharia madura planeja manutenção como parte do produto.

Reengenharia aparece quando o custo de manutenção cresce demais, ou quando há necessidade de modernizar tecnologia, migrar arquitetura, separar componentes, reduzir complexidade, extrair serviços, reestruturar dados. Reengenharia não é reescrever “do zero” por impulso. Uma abordagem responsável avalia risco de migração, preservação de regras de negócio, compatibilidade com dados, continuidade operacional. Muitas organizações fracassam ao reescrever porque subestimam conhecimento incorporado no sistema antigo: exceções, detalhes de domínio, comportamentos emergentes, dependências não documentadas.

Um programa de evolução sustentável combina refatoração contínua, melhoria incremental, testes robustos, observabilidade e decisões arquiteturais com base em evidência. Quando essas práticas faltam, a organização entra em um ciclo de “remendos” que aumentam complexidade e reduzem previsibilidade.

Tendências emergentes: escala, automação e sistemas inteligentes

Tendências em engenharia de software costumam intensificar a complexidade: distribuição em microserviços, computação em nuvem, infraestrutura como código, automação de pipelines, observabilidade avançada, segurança integrada ao ciclo de desenvolvimento, uso de modelos de aprendizado de máquina, arquiteturas orientadas a eventos. A disciplina evolui para lidar com sistemas mais dinâmicos, com atualizações frequentes e maior interação com terceiros.

Uma consequência dessa tendência é a centralidade de dados e telemetria. Sistemas modernos precisam ser observáveis: logs estruturados, métricas, rastreamento distribuído, auditoria, alertas significativos. Sem isso, problemas se tornam longos e caros para diagnosticar. Outra consequência é o fortalecimento de práticas de confiabilidade: testes de carga, engenharia de caos, análise de falhas, planos de continuidade, exercícios de incidentes. Em ambientes complexos, falha não é hipótese distante; é evento esperado, cujo impacto deve ser controlado.

Síntese: disciplina como redução sistemática de incerteza

Engenharia de software pode ser entendida como um conjunto de métodos para reduzir incerteza em um domínio que muda continuamente. Testes em Web e mobile enfrentam variabilidade de ambiente e estado; segurança exige pensamento orientado a ameaça e controle contínuo; métodos formais reduzem incerteza em propriedades críticas; gestão de configuração controla mudança e preserva reprodutibilidade; métricas apoiam decisões e melhoria; estimativas e cronogramas precisam reconhecer descoberta e risco; manutenção e reengenharia representam o ciclo de vida real; tendências emergentes aumentam a importância de automação, observabilidade e confiabilidade.

A disciplina não elimina falhas, prazos apertados ou mudanças de requisito. Ela cria um terreno onde essas forças deixam de ser pura improvisação e passam a ser fenômenos administráveis, com evidências, estratégias e mecanismos de controle. Quando aplicada com rigor e adaptação ao contexto, a engenharia de software transforma o desenvolvimento em uma prática tecnicamente consistente, verificável e sustentável — exatamente o que sistemas críticos e produtos de longo prazo exigem.

Leia Mais