a16z Última opinião: Quando o Agente de IA se torna o principal utilizador de software

Escrevendo: DeepThink Circle

Você já pensou que toda a lógica de construção de software pode ser completamente derrubada?
Nas últimas décadas, todo software foi projetado para humanos.
Gastamos incontáveis esforços otimizando interfaces de usuário, tornando botões mais fáceis de encontrar, menus mais claros, fluxos de operação mais suaves.
Mas e se, no futuro, os principais usuários do software não forem mais humanos, e sim agentes de IA?
Se uma empresa tiver cem pessoas, mas mil agentes de IA trabalhando, devemos então focar na otimização da interface para humanos?

Recentemente, em um episódio do podcast da a16z, Erik Torenberg, Steven Sinofsky e Martin Casado tiveram uma conversa extremamente profunda com Aaron Levie, CEO da Box.
O núcleo da discussão foi: quando agentes de IA se tornarem os principais usuários de softwares empresariais, como toda a indústria de software será reestruturada?
Essa conversa me fez perceber que estamos à beira de uma mudança de paradigma mais intensa do que a maioria imagina.
Não se trata apenas de adicionar funcionalidades de IA ao software existente, mas de repensar fundamentalmente como o software deve ser construído, como deve interagir e como deve ser utilizado.

O software deve ser feito para agentes de IA

Aaron Levie apresentou uma ideia que me fez refletir:
Se você tiver cem ou mil vezes mais agentes de IA do que funcionários, seu software precisa ser feito para esses agentes.
Não é uma questão de escolha, mas uma tendência inevitável.
A Box agora dedica tanto tempo pensando na interface de agentes quanto na interface de humanos.
A velocidade dessa mudança superou minhas expectativas.

A lógica por trás disso é simples. Quando agentes de IA se tornam os principais usuários, eles interagem com o sistema via API, CLI (interface de linha de comando) ou protocolos como MCP (Model Context Protocol).
E qual é o paradigma mais eficiente atualmente?
Dar a um agente que escreve código acesso às ferramentas SaaS, permitindo que ele acesse seus fluxos de trabalho de conhecimento e informações contextuais.
Esses agentes não apenas leem e compreendem informações, mas, mais importante, podem executar tarefas escrevendo código ou usando APIs.

Claude Code da Anthropic, aplicações super avançadas em desenvolvimento pela OpenAI e as funcionalidades de cálculo do Perplexity estão caminhando nessa direção.
Acredito que essa capacidade de crescimento composto está apenas começando.
Imagine um agente que não só entende você ao dizer “ajude-me a analisar os dados de vendas do último trimestre”, mas também escreve código para extrair, analisar e gerar visualizações, até descobrir tendências que você não percebeu.
Até onde essa capacidade pode chegar? Ainda não tenho uma resposta clara.

Mas há uma questão central que tenho refletido:
As pessoas costumam dizer “construa para o agente”, “faça marketing para o agente” ou “tenha boas APIs e linguagens de descrição de interfaces”.
Martin Casado, na conversa, apresentou uma visão contrária que acho muito acertada: essa abordagem está quase toda errada.
Por quê? Porque agentes são especialistas em encontrar as ferramentas e sistemas de backend corretos.
Eles não escolhem seu produto só porque sua documentação é bonita, mas com base em fatores como custo, confiabilidade do sistema, persistência de dados.
O que os agentes possuem é a inteligência coletiva de humanos usando essas plataformas.

Essa ideia me fez perceber algo importante:
Como setor, estamos focando demais na interface e na API, e negligenciando o essencial: construir sistemas melhores.
Os agentes vão nos impulsionar a voltar à essência tecnológica, não à estratégia de marketing.
No passado, as decisões de compra de software empresarial eram influenciadas por capacidade de vendas, marca ou até jantares de negócios.
Mas, num mundo dominado por agentes, esses fatores terão peso muito menor.
Agentes irão escolher com base na qualidade técnica, de forma mais racional.
Para empresas que realmente focam na tecnologia, isso representa uma grande oportunidade.

Barreiras do pensamento algorítmico: nem todo mundo consegue comandar um agente de IA

Uma parte da conversa que me impressionou foi a discussão sobre o desafio de usuários não técnicos operarem agentes de IA.
Steven Sinofsky destacou:
Pensar em algoritmos é extremamente difícil para a maioria das pessoas que trabalham.
Se pedir a alguém que desenhe um fluxo de trabalho para uma tarefa, provavelmente falhará.

Essa observação é crucial.
Imagine uma equipe de 50 profissionais de marketing, responsável por uma grande linha de produtos.
Provavelmente, só um ou dois entenderão e conseguirão documentar todo o fluxo de trabalho.
Se esses colaboradores usarem ferramentas de automação ou agentes de IA, sua capacidade de explicar “o que fazer” é limitada.

Aaron Levie respondeu:
Isso é apenas uma evolução no trabalho, você precisa aprender uma nova habilidade.
Nada de novo na história da tecnologia.
Ele deu um exemplo interessante:
Um profissional de marketing da Anthropic usou Claude Code para fazer o trabalho que antes levava cinco a dez pessoas.
Esse exemplo é significativo porque essa pessoa já tinha uma mentalidade sistêmica e conhecimento técnico suficiente.

Mas a questão principal é:
Se você imaginar que cada cargo tem um pool infinito de engenheiros para automatizar qualquer tarefa, como esse cargo evoluiria?
Acredito que agentes vão se tornar cada vez melhores em guiar usuários para o pensamento sistemático, mas, por enquanto, poucos sabem usar essas ferramentas efetivamente.

Steven Sinofsky fez uma analogia brilhante:
Sua prima, formada em uma escola de elite, entrou no mercado de trabalho na era do cálculo.
Ela nunca usou planilhas na pós-graduação, mas no primeiro emprego, gerenciou uma sala de estagiários — estudantes universitários que faziam toda a parte de planilhas.
Surpreendentemente, nos anos seguintes, ela e seus colegas se tornaram especialistas em planilhas.
A abstração evoluiu:
Antes, estagiários usavam calculadoras financeiras HP, agora ela mesma usava planilhas, podendo fazer 30 iterações em vez de duas.

Esse exemplo me fez perceber que estamos em uma fase semelhante na evolução dos agentes de IA.
Você pensa em dezenas de agentes pequenos coordenados por uma pessoa superinteligente.
Logo, esses agentes vão se fundir, formando um conjunto de habilidades — um código, um agente — que entende de marketing, por exemplo.
Você pode perguntar a ele sobre marketing, e depois pedir que execute tarefas.

A mudança de paradigma é:
Hoje, é preciso ser um especialista em foguetes para criar e fazer funcionar 42 agentes.
Mas essa barreira vai desaparecer rapidamente, e o conhecimento especializado voltará às mãos dos especialistas de domínio.
É uma trajetória semelhante à evolução das planilhas.

Medo empresarial: integração descontrolada e pesadelo de permissões

Um cenário que me tocou profundamente na conversa foi quando Aaron Levie contou que, recentemente, falou com CFOs e CIOs e recebeu a resposta:
“Você está louco, perdeu toda a credibilidade comigo.”
Por quê?
Porque ele afirmou que os problemas de integração se tornariam muito mais fáceis.

As preocupações desses líderes de TI não são infundadas.
Eles temem não só os agentes, mas também a autorização de integrações por humanos.
Quando você permite que funcionários criem novas integrações, é como dizer:
“Por favor, venham destruir meus sistemas centrais.”
Imagine alguém criando uma nova conexão API entre sistemas 27 e 38.
Se for só para gerar relatórios, tudo bem, é responsabilidade dele.
Mas e se envolver operações de escrita?

Aaron Levie acredita que, por um bom tempo (um N grande), teremos uma versão de agente apenas para leitura.
Muitos aplicativos de IA hoje são de consumo final — humanos são os usuários finais.
Mas, mesmo nesse nível, surgem novos desafios para as empresas.

A Box lançou recentemente a CLI oficial.
Aaron descreveu um cenário:
Você fornece ao Claude Code a CLI da Box, e agora pode interagir em linguagem natural com todo o sistema, usando modelos poderosos como o Opus 4.6 para orquestrar operações.
Parece incrível: dizer “faça upload desta pasta inteira” ou “processe todos os documentos nesta pasta” e tudo ser feito.

Mas o problema surge:
Imagine uma empresa com 5000 funcionários, todos acessando repositórios compartilhados de documentos de engenharia e marketing, usando CLI.
Como coordenar milhares de solicitações por hora?
Não é questão de desempenho, mas de garantir que, enquanto um agente move arquivos, outro não tente escrever na mesma pasta, e um terceiro não tente deletar algo.
Quando esses agentes operam freneticamente, surgem problemas que deixam CFOs e CIOs de cabelo em pé.

Aaron Levie testou isso na prática.
Ao tentar criar uma estrutura de diretórios para um plano de marketing, entrou em um ciclo infinito de criação de subdiretórios.
Brincou:
“Quero saber qual é o limite de profundidade de diretórios do Box, porque estou quase atingindo.”

Esse episódio revela um problema maior:
Quando agentes têm poder de execução, podem fazer coisas imprevisíveis.
E essa imprevisibilidade é o que mais assusta as empresas.

Tratar agentes de IA como funcionários? Não é tão simples

Uma discussão que achei muito interessante foi sobre como gerenciar agentes de IA.
Quando as pessoas começam a usar agentes pessoais, dão a eles chaves de API, e-mails próprios.
Como evitar que façam coisas que não deveriam?

Martin Casado compartilhou uma prática:
Dar ao agente seu próprio telefone, cartão de crédito (preferencialmente pré-pago), conta de Gmail.
O Gmail tem muitos mecanismos de controle de acesso baseados em papéis (RBAC).
Você pode argumentar que já existem sistemas assim, e que agentes devem ser tratados como pessoas independentes.

Aaron Levie imediatamente apontou um problema:
Num time de 50 pessoas, teríamos 100 “pessoas” — 50 humanos e 50 agentes — operando no mesmo espaço compartilhado.
Posso supervisionar totalmente meu agente, mas e se ele colaborar com outros e acessar recursos que não deveria?
Um agente autônomo, com estado, lidando com informações de terceiros.

Há um conflito fundamental aqui.
Para funcionários humanos, não podemos ver seus canais Slack, não podemos logar como eles, não podemos supervisionar cada movimento.
Eles são responsáveis por suas ações, e não somos punidos por seus erros.
Mas, com agentes, somos responsáveis por tudo que fazem.
Precisamos de supervisão total, sem privacidade.

E isso gera um paradoxo:
Queremos dar acesso ao agente, mas também precisamos poder revogar operações ou entrar nele para corrigir erros.
Se podemos logar como o agente, como garantir confidencialidade e segurança?
Na prática, o agente se torna uma extensão de nós, quase impossível de separar.

Aaron Levie levantou uma questão de segurança ainda mais profunda:
Ainda não sabemos como fazer agentes manterem segredo.
Se dissermos a um agente “não revele a informação X do contexto”, é difícil garantir isso.
Se tudo que entra no contexto do agente pode ser acessado por ele, há risco de vazamentos por prompt injection (injeção de comandos).

O que isso significa?
Se eu souber o e-mail do seu novo agente, posso enviar mensagens, fazer engenharia social — mais fácil do que com humanos.
E é difícil garantir que esse agente também não acesse documentos sensíveis, como informações de fusões e aquisições.

A maior barreira técnica atual dos agentes de IA é justamente essa:
Antes de resolverem esse problema, eles não podem ter autonomia total.
Continuarão sendo extensões humanas, não entidades independentes.

Vantagem das startups: abraçar o IA sem limites

Um ponto que me tocou foi:
A velocidade de disseminação das capacidades de IA será muito mais lenta do que os insiders de Silicon Valley pensam.
Por quê?
Porque as restrições enfrentadas por startups e grandes corporações são completamente diferentes.

Aaron Levie disse que startups podem construir do zero, sem os riscos que discutimos, porque não têm nada a perder.
Já grandes empresas, como o JPMorgan, enfrentam um enorme abismo.
Elas têm dezenas de sistemas legados, requisitos de conformidade, padrões de segurança de dados, mecanismos complexos de permissão.
Se um agente falhar, o máximo que acontece é uma piada ou um episódio de “Silicon Valley”.
Mas, se um banco grande vazar dados de clientes, pode ser o fim da empresa.

Steven Sinofsky fez uma previsão brilhante:
Startups vão gastar todo o capital disponível, fingindo que o custo não é problema.
Grandes empresas, por medo, vão congelar tudo.
Funcionários comuns vão começar a comprar e usar essas ferramentas por conta própria, fazendo o que as empresas não querem gastar para fazer.

Algumas empresas, por motivos financeiros, vão apostar cedo.
E essas podem se tornar líderes em seus setores, desde que mantenham saúde financeira.
Não haverá um medo paralisante de CFOs, mas erros acontecerão — e isso é normal.

Acredito que isso criará uma diferenciação de mercado interessante.
Empresas médias dispostas a arriscar cedo podem ganhar vantagem competitiva.
Elas terão recursos para investir em IA, sem as amarras de sistemas legados ou aversão ao risco.

Haverá também uma nova onda de empresas de serviços.
Imagine criar uma agência de marketing, consultoria de engenharia ou firma de arquitetura baseada inteiramente em agentes de IA, do zero, sem barreiras de informação, com todo o contexto necessário, podendo programar tudo a qualquer momento.
Essas empresas terão um impacto disruptivo por um tempo, até que as grandes corporações possam se libertar dessas limitações.

Orçamento de tokens: o novo campo de batalha na gestão de engenharia

Uma discussão sobre o orçamento de tokens me pareceu realista e absurda ao mesmo tempo.
Aaron Levie disse:
“Conversas sobre orçamento de computação serão uma das mais loucas nos próximos anos.”

Por quê?
Porque os custos de computação representam de 14% a 30% da receita de qualquer grande empresa de tecnologia listada.
O custo de cálculo é o dobro ou triplo do custo de engenharia, e essa diferença pode afetar o lucro por ação (EPS).

Steven Sinofsky acredita que ainda não temos a resposta, e os CFOs querem respostas para perguntas que nem sabem fazer.
Wall Street os força a dar números, e eles podem ser demitidos se não cumprirem.
Esse ciclo se repete — já aconteceu com largura de banda, tubos de vácuo, transistores, número de programadores.

Aaron Levie insiste:
Este momento é diferente.
Nunca tivemos uma situação em que cada usuário final pudesse iniciar recursos de forma tão elástica.
E, muitas vezes, esses recursos são totalmente razoáveis.

Isso lembra a transição de CapEx para OpEx na era do cloud, no início dos anos 2000.
Na época, CFOs diziam:
“Você não entende, somos uma empresa agrícola, só entendemos CapEx”, ou “Somos uma empresa de OpEx, gostamos de nuvem”.
As regras contábeis influenciam fortemente a adoção tecnológica.

Mas o orçamento de tokens é mais granular.
Como líder de engenharia, você precisa decidir:
Devo fazer meus engenheiros considerarem o orçamento toda vez que usarem um prompt?
Devo preferir prompts longos ou curtos?
Devo paralelizar experimentos?
Qual é a tolerância ao desperdício de tokens?

Aaron acha que, agora, é melhor gastar muitos tokens, pois isso permite experimentar.
Deve-se incentivar a equipe a rodar múltiplos experimentos simultâneos, mesmo que 90% dos tokens sejam desperdiçados, para encontrar um caminho de sucesso.
Ou é melhor planejar tudo com perfeição antes de começar?

Quando essa conversa foi gravada, as pessoas estavam preocupadas com o novo plano Max do Claude Code, que limita o uso a três prompts.
Esse será um tema real até que consigamos ampliar a capacidade de centros de dados.

Por outro lado, concordo com Sinofsky:
No final, esse problema vai desaparecer.
Porque é preciso fazer cálculos matemáticos ao estilo Benioff.
Se você paga um milhão por ano a um vendedor, precisa saber quanto seu ferramenta vale.
Se paga X dólares a um engenheiro, seu investimento deve fazer sentido em algum momento.

E a lei dos grandes números vai ajudar:
Com muitos engenheiros usando recursos de cálculo, as coisas tendem ao equilíbrio.
Estamos em uma fase de transição, e muitos pensaram que IA era só um chatbot.
Mas estavam errados: é uma mudança de plataforma, uma transformação de paradigma.

O futuro do SaaS: o valor da camada de dados

Uma discussão sobre o futuro dos sistemas empresariais me chamou atenção.
Martin Casado apontou que os fornecedores de SaaS não vendem dados de linhas de negócio, mas inteligência, conhecimento de domínio e sistemas completos.
Por outro lado, agentes querem comprar dados, autorizar acesso a eles, mas isso nunca foi o modelo de negócio.

Essa tensão é antiga, com sistemas como Workday e SAP.
Eles enfrentaram várias reformulações de plataformas para permitir mais acesso via API.
Na prática, o que significa um sistema de registro (system of record) quando há desejo de acesso a dados?

Steven Sinofsky disse de forma direta:
“Fazer um sistema como SAP usando vibe coding é absurdo.”
Todo conhecimento de domínio no SAP não está só na camada de dados, mas também na interface, na lógica intermediária, na forma como você usa o sistema.

Aaron Levie discorda:
Se você fizer muitas iterações, o agente vai acabar sendo responsável por escolher as ferramentas que usa.
Embora não possa substituir sistemas empresariais, com o tempo, o agente pode perceber obstáculos e dizer:
“Você precisa eliminar seu sistema legado de RH, senão não consigo automatizar esse fluxo.”

Essa é uma ideia disruptiva.
Imagine que, com milhares de agentes, se essa situação se repetir, será necessário construir uma pilha de software específica para eles.
Alguns sistemas, como ERPs, podem resistir, mas tudo o mais será acessado pelos agentes.
Assim, a infraestrutura de TI da empresa deve ser configurada para suportar esses agentes de forma eficiente.

Martin Casado fez uma distinção que acho fundamental:
Muita gente fala de “marketear para o agente”, “criar APIs” ou “ter boas linguagens de descrição de interfaces”.
Ele acha que isso está quase todo errado.
O que os agentes realmente fazem bem é encontrar as melhores ferramentas de backend.
Eles não escolhem só pelo visual ou documentação, mas pelos custos, persistência, confiabilidade.
Na verdade, eles possuem a inteligência coletiva de quem usa essas plataformas.

Ele deu um exemplo:
Quando um agente escolhe uma nuvem, ele usa critérios relevantes, não só a interface.
Como setor, estamos focando demais na aparência, e isso nos impede de construir sistemas melhores, que realmente serão preferidos.

Acho essa visão muito profunda.
Na era dos agentes, a qualidade técnica será mais importante que o marketing.
Produtos tecnicamente superiores vão se destacar, enquanto os que dependem só de vendas terão dificuldades.

Minha reflexão: subestimamos a escala dessa mudança

Ao ouvir toda a conversa, minha maior impressão foi:
Wall Street e o setor estão usando uma estrutura errada para entender o impacto econômico dessa transformação.
Aaron Levie tem razão: o maior problema é que todos tentam estimar os benefícios econômicos, mas estão subestimando a escala real.

Steven Sinofsky trouxe exemplos históricos:
Quando olhamos para os PCs, achávamos que o consumo de MIPS (milhões de instruções por segundo) era limitado.
Não imaginávamos o que aconteceria se colocássemos esses MIPS em cada desktop.
E pensávamos que o software vinha junto com o hardware, com poucos jogadores, como Bill Gates e Paul Allen vendendo software separadamente.

O mesmo aconteceu com cloud computing.
Achávamos que era só mover servidores para data centers de terceiros, com cerca de 60 mil servidores por ano.
Ninguém previu o crescimento de mil vezes na utilização.

Para IA, o cenário é semelhante.
Wall Street pensa em um mercado fixo, uma fatia de receita constante.
Mas, na realidade, a adoção de agentes vai expandir exponencialmente o uso de software, dados e computação.
Não é uma transferência de tarefas, mas uma criação de novas possibilidades e valor.

Aaron Levie, como investidor, observa que as empresas de infraestrutura que conhece têm crescido de forma quase linear nos últimos meses.
Por quê?
Porque há mais software sendo escrito do que nunca.
Com mais agentes, mais recursos de computação serão consumidos.
Quando dispositivos móveis e IA no edge se tornarem realidade, o uso pode aumentar bilhões de vezes.

Acredito que estamos vivendo um “momento transistor”.
Steven Sinofsky usou o exemplo das válvulas de vácuo:
Houve um tempo em que se pensava que todo o Dakotas seria coberto por armazéns de válvulas, trocando-as com patins de gelo nos corredores, só para a guerra.
Depois, veio a sugestão de usar transistores.

Tokens podem ser como os MIPS da IBM.
A IBM vendia mais MIPS a preços menores, mas continuava cobrando por MIPS até que alguém percebeu que a curva de custos caía mais rápido do que a de preços.
O mesmo acontecerá com tokens.

No curto prazo, veremos muita confusão e incerteza.
Empresas vão lutar para decidir quanto investir, como controlar custos e gerenciar riscos.
Startups vão apostar alto e agir rápido.
Haverá fracassos e sucessos.
Mas, a longo prazo, a direção é clara:
Software deve ser feito para agentes, APIs serão mais importantes que interfaces, a qualidade do sistema será mais relevante que marketing, e o custo de computação continuará caindo enquanto o uso cresce exponencialmente.

Não estamos apenas atualizando ferramentas, estamos mudando o paradigma de cálculo fundamental.
Quem entender isso e agir será quem moldará a tecnologia na próxima década.
Quem ficar preso ao velho quadro pode ficar para trás.

Essa mudança está apenas começando.