A App Store morreu. O runtime agora é intenção, contexto e ferramentas.

Eu não acho que a App Store vai acabar. Eu acho pior: ela vai virar um detalhe burocrático, como instalar driver em 2003.

Quando a unidade de valor deixa de ser “um app” e vira “uma capacidade”, o catálogo perde o sentido. Não porque não existam apps bons, mas porque o que eu preciso, na maioria dos dias, não é um produto. É um arranjo momentâneo.

Andrej Karpathy escreveu isso do jeito mais concreto possível. Karpathy não é um comentarista aleatório. Ele é pesquisador e líder técnico em IA. Passou por OpenAI e Tesla. Virou um bom barômetro de para onde a prática está indo.

Ele queria acompanhar um experimento pessoal de cardio por oito semanas. Um objetivo específico. Um sensor específico. Uma rotina específica. Ele não foi procurar “o app perfeito”. Ele conversou com um agente. Saiu um dashboard web em cerca de uma hora. Umas 300 linhas de código.

E aí vem a frase que dói.

Tradução livre: “nunca vai existir, e nem deveria, um app específico na App Store para um caso desses”.

Não é arrogância. É economia.

Quando o problema é singular, transformar isso em produto é desperdício. A App Store é um mecanismo de produto. Ela só funciona quando você empacota para muitos.

A cauda longa sempre existiu. O que muda é o custo de atender a cauda longa. Antes, a cauda longa era descartada. Agora, a cauda longa vira o mapa inteiro.

O que morreu não é o app. É o modelo mental.

O modelo mental antigo é simples: eu tenho uma necessidade, eu procuro no catálogo, eu instalo um artefato estável, eu me adapto ao fluxo do artefato.

Esse modelo é uma fábrica de fricção. Primeiro porque a necessidade real quase nunca é “um app“. Segundo porque eu não quero adaptar minha vida a um produto. Eu quero adaptar o software ao meu contexto.

Eu sei que isso soa como “customização”. Só que não é.

Customização é escolher entre opções pré-definidas. Tema escuro. Layout A ou B. Campos extras.

O que está aparecendo agora é outra coisa: software que nasce do nada e se encaixa em você. E que pode morrer amanhã, sem trauma.

Isso é software efêmero. Não é software mal feito. É software com TTL (Time to Live).

TTL é “tempo de vida”. Existe o suficiente para responder uma intenção. Depois some. Ou se reescreve.

A efemeridade não é efeito colateral. É o que impede a sua vida digital, e a sua empresa, de virar cemitério.

A nova unidade de composição: sensores e atuadores.

Karpathy usa uma imagem boa: o futuro não é uma App Store mais esperta. É um mercado de sensores e atuadores feitos para serem usados por IA.

“AI-native“, aqui, não significa ter chatbot. Significa ter capacidades expostas do jeito que uma máquina consegue consumir com segurança.

Sensor é qualquer coisa que transforma o estado do mundo em dados. Uma esteira. Um relógio. Um CRM. Um extrato bancário. Um log.

Atuador é qualquer coisa que produz efeito. Enviar um e-mail. Abrir um chamado. Fazer um commit. Agendar uma consulta. Fazer uma transferência.

O app tradicional mistura sensores, atuadores, UI e workflow num pacote fechado. Você compra o pacote. Você paga, no pacote, pelo que não usa.

No mundo AI-native, eu não quero o pacote. Eu quero os conectores.

Eu quero uma API limpa. Eu quero schema. Eu quero limites de permissão. Eu quero tokens de curta duração. Eu quero logs. Eu quero auditoria.

E eu quero documentação consumível por agente. Sem “clique aqui, agora role a página”. Sem HTML decorativo que só funciona para olho humano.

Aqui está o ponto. A App Store morre porque ela é um catálogo de UIs. E a UI deixa de ser fixa.

Eu não compro uma interface. Eu instancio uma interface, com o contexto que importa naquele momento.

O caso da esteira é pequeno. A implicação é gigantesca.

No relato do Karpathy, o agente precisou fazer engenharia reversa da API cloud da esteira Woodway. Dá para sentir o tamanho do atraso do ecossistema.

Noventa e nove por cento dos serviços de hoje não são agent-friendly. Foram desenhados para um humano lendo tutorial e clicando em botões.

O agente tropeça no que nós toleramos. Pop-up de confirmação. Sessão que expira com redirecionamento. Documento que descreve campos sem contrato formal.

Mesmo assim, o dashboard saiu. E teve bugs. Unidade métrica versus imperial. Data errada. Dia trocado.

Isso é o tipo de defeito que some com maturidade. O deslocamento de escala não some.

Se eu saio do nada para uma solução útil em uma hora, eu mudo o limiar de decisão. Eu paro de discutir “projeto”. Eu começo a experimentar.

E quando o custo cai mais um pouco, eu paro de experimentar. Eu simplesmente faço.

A App Store é uma solução para um mundo de escassez. O mundo que está chegando é um mundo de abundância de software.

O que torna isso possível: tool-use, function calling e MCP.

A infraestrutura dessa virada não é um prompt bonito. É o que acontece quando o modelo consegue agir.

Tool-use é o modelo escolhendo ferramentas e executando chamadas. Buscar arquivo. Rodar query. Fazer um POST. Gerar um gráfico.

Se você preferir o termo em português, é isso: uso de ferramentas.

Function calling é o formato que tira parte da magia. Inputs e outputs declarados. JSON Schema. Validação. Erros tipados. Uma ponta de reprodutibilidade.

E aí aparece o MCP (Model Context Protocol). Tradução simples: um protocolo para conectar modelos a ferramentas e recursos de forma padronizada.

Eu gosto do MCP por um motivo prático: ele reduz a fricção de integração. Ele descreve resources. Ele descreve tools. Ele define fronteiras, como roots.

Isso começa a parecer um sistema operacional. Não pelo marketing. Pelo contrato. Entrada, saída, permissões.

Se a IA consegue compor o mundo assim, a App Store vira vitrine do que é estático.

O que nasce no lugar da App Store

Eu não acho que vamos viver sem catálogo. O que muda é o objeto catalogado.

No lugar de “apps”, o catálogo lista capacidades. Conectores. Sensores. Atuadores. Pacotes de política. Servidores MCP.

Você não instala “um app“. Você habilita um conjunto de tools. Você assina uma API de sensor com SLA (Service Level Agreement). Você libera um atuador com limites, trilha de auditoria e consentimento explícito.

Isso explica por que a App Store, como a gente conhece, fica ultrapassada. Ela cataloga o que é estático. O futuro cataloga o que é componível.

E quando um “app” existir, ele vai ser template de intenção.

O novo runtime: intenção + contexto + ferramentas

O que substitui o app não é um chat. É um runtime.

Runtime, aqui, é o ambiente que pega intenção e executa. “Rastreie meu cardio por 8 semanas.” “Crie um relatório de risco desse fornecedor.” “Me avise quando meu gasto com delivery passar de X.”

Ele carrega contexto. Quem sou eu. Quais são meus hábitos. Quais são minhas restrições. Qual é o meu vocabulário. Quais dados eu autorizo.

E ele chama ferramentas. Busca dados. Transforma dados. Executa ações. Produz interface, quando interface for a melhor forma.

A UI vira só mais uma ferramenta.

O custo real muda de lugar: de construção para governança

Se software fica barato de criar, o gargalo muda. O gargalo vira segurança, observabilidade e responsabilidade.

Eu não posso aceitar um agente que inventa automação sem trilha. Eu preciso saber o que ele fez, por que fez, com quais dados.

Isso é QA em produção. QA, aqui, é quality assurance. Garantia de qualidade.

É a única estratégia que faz sentido quando a construção é parcialmente não determinística.

Não basta teste antes do deploy. Deploy é “colocar em produção”. E, nesse mundo, a ida para produção pode acontecer toda vez que eu faço a pergunta.

Eu preciso de logs estruturados. Tracing. Replay. Métricas de sucesso. Alertas para comportamento estranho.

E preciso de modelo de promoção. O que nasce efêmero às vezes vira permanente. Só que, para virar permanente, precisa passar por gates. Evidência de uso. Revisão. Permissões mais rígidas.

A organização que não fizer isso vai afundar em shadow IT. E agora o shadow IT escreve código em minutos.

A fricção invisível: especificar bem ainda é difícil

Tem uma objeção popular: “minha avó não quer criar um app“.

Eu concordo com a frase e discordo da conclusão. Ela não quer criar um app. Ela quer o resultado.

O que falta não é vontade. É energia de especificação.

Pensar claramente no que eu quero é caro. Software tradicional terceirizou isso para designers e PMs.

No mundo novo, parte dessa carga volta para mim. Ou vai para o agente.

A solução é um agente que carrega contexto suficiente para inferir intenção sem me obrigar a escrever uma RFC (Request for Comments).

Isso é memória. Preferências. Histórico. Restrições.

E uma conversa que não é “chat”, é alinhamento.

Isso não começou com LLM

Há uma linhagem aqui.

Planilhas foram end-user development. HyperCard foi end-user development. Low-code e no-code foram end-user development.

O que muda agora é a interface. A interface vira linguagem natural. E a execução vira uso de ferramentas.

O resultado é um salto de acessibilidade. Não porque todo mundo virou desenvolvedor. Mas porque o custo de virar “autor de software” caiu o suficiente para que valha a pena.

Um conselho prático, sem romantismo

Se eu estivesse construindo produto, eu pararia de pensar em telas e começaria a pensar em ferramentas. Sensores e atuadores com API, schema, limites e auditoria.

Se eu estivesse liderando engenharia, eu trataria software efêmero como primeira classe. Expiração, promoção por evidência, observabilidade como requisito mínimo.

A frase final que eu quero deixar

A App Store não morreu por falta de apps. Ela morreu porque o mundo ficou específico demais.

O software não vai desaparecer. Ele vai se dissolver em todos os lugares onde há dados e ação.

E o computador que importa não é o do silício. É o runtime que traduz intenção em execução, usando contexto e ferramentas.

O resto é catálogo de passado.