Quando criar software fica barato o difícil passa a ser descobrir o que merece existir

Na semana passada eu tive o prazer de assistir a uma belíssima conversa organizada pelo Atlantico com Mike Krieger, cofundador brasileiro do Instagram, e que também atua como Chief Product Officer (CPO) na Anthropic. O papo teve como anfitrião Julio Vasconcellos, sócio da Atlantico e intermediação de outros 3 convidados: Michael Mac-Vicar (Enter), Lucas Smaria (Vetto) e Vitor Olivier (Decade).

A primeira reflexão que quero fazer é: o que acontece quando mais pessoas conseguem construir? No mundo digital, reduzir a distância entre uma ideia e sua publicação mudou tudo. Com a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →, essa distância começa a diminuir também para quem precisa de software.

Há uma mudança econômica e uma mudança no planejamento e desenvolvimento produto. Um software pode justificar sua existência por resolver bem um problema específico, durante um período curto. Não precisa necessariamente se tornar uma plataforma, conquistar milhões de usuários ou sustentar anos de roadmap.

Pense em uma situação hipotética: três parceiros precisam organizar uma ação comercial que dura seis semanas. Há responsáveis, entregas, documentos e pendências compartilhadas, mas cada empresa trabalha de um jeito. Uma planilha resolve parte do problema. Um sistema de gestão resolve outra parte, desde que todos adaptem o processo à ferramenta. Desenvolver uma solução específica poderia custar mais do que o benefício esperado.

Se a geração da aplicação fica mais barata, essa conta muda. Surge espaço para software que antes não seria feito: um simulador para uma negociação, uma interface para revisar um conjunto de propostas, um painel temporário de operação ou um fluxo de aprovação para um evento.

A documentação de Artifacts dá materialidade a essa possibilidade. A Anthropic descreve aplicações interativas que podem incorporar IA e ser compartilhadas; a página do anúncio registra posteriormente suporte a armazenamento persistente e MCP. Isso confirma uma direção de produto, sem provar que qualquer aplicação gerada já seja adequada ao uso empresarial.

Aplicação pública de flashcards indicada pela Anthropic como exemplo de Artifacts. Ilustra a passagem de uma resposta para uma ferramenta interativa; não é o aplicativo privado mencionado por Mike.

Para um desenvolvedor, a oportunidade aparece tanto na aplicação quanto nas condições para que ela exista com segurança. Alguém precisa tornar simples autenticar participantes, limitar acesso, exportar dados, acompanhar erros e encerrar o ambiente. A facilidade de gerar telas não elimina esses requisitos. Ela aumenta o número de pessoas que vai esbarrar neles.

O que muda no desenho da solução

Eu separaria os casos pelo efeito da aplicação e pela duração do compromisso com os dados. Essa classificação é uma proposta de implementação, não uma taxonomia apresentada por Mike.

A distinção ajuda a estimar o trabalho que a demonstração não mostra. Gerar uma interface resolve a apresentação do problema. Encerrar a aplicação sem perder decisões resolve parte de sua responsabilidade operacional.

Software temporário também deixa consequências permanentes

O exemplo das três empresas merece ser levado a sério justamente porque colaboração entre organizações envolve fronteiras. Uma ferramenta pode ser temporária; a informação comercial, a autorização concedida e a decisão registrada continuam tendo consequências depois que o projeto acaba.

A interface de acompanhamento pode desaparecer. Os registros de aprovação precisam ser exportáveis. As permissões devem expirar. O responsável pelos dados precisa estar definido desde o início.

Isso permite uma abordagem mais econômica do que tentar transformar todo protótipo em um sistema corporativo completo. Um painel que só lê dados já autorizados pode ter um caminho de implantação simples. Uma aplicação que altera o cadastro de fornecedores exige controles adicionais. A duração do projeto não é uma boa aproximação do risco; o efeito de suas ações é muito mais importante.

Eu gostaria de ver mais equipes brasileiras experimentando esse tipo de software, acompanhadas por plataformas internas que ofereçam uma base comum. Templates de autenticação, ambientes isolados, limites de consumo e um mecanismo claro de desligamento podem viabilizar dezenas de pequenas soluções. A engenharia passa a multiplicar a capacidade de criação de outras áreas.

O problema dos últimos dez por cento

Na mesma conversa, Mike trouxe um freio importante à empolgação. Ao descrever o desenvolvimento de uma experiência de apresentações, comentou a diferença entre conseguir uma primeira versão relativamente boa e entregar um produto com as interações desejadas. Para explicar a dificuldade, reproduziu uma formulação de uma postagem interna da Anthropic que considerou especialmente precisa:

“Agora com o AI a gente faz os primeiros 90% com muita facilidade, mas os últimos 10% ainda são bem difíceis.”

Mike Krieger

Essa distinção interessa muito a quem vende software. O usuário raramente precisa apenas o objetivo final do software. Ele precisa conseguir revisar, corrigir, compartilhar, recuperar e continuar o trabalho. Uma apresentação visualmente convincente pode deixar de servir ao propósito se a exportação desorganizar o material ou se os dados importados perderem sua relação com a fonte.

Esses detalhes também mudam de acordo com o público. Um protótipo usado uma vez pelo próprio criador pode tolerar instruções manuais. Uma aplicação usada por centenas de pessoas precisa explicar seu funcionamento, responder a falhas e manter comportamentos previsíveis. O produto começa a se diferenciar quando entende essas exigências específicas.

Não interpreto a fala como uma garantia de proteção para empresas estabelecidas. O que hoje exige trabalho especializado pode se tornar trivial no próximo modelo. A pergunta útil para um fundador é quais dificuldades continuam aparecendo quando o cliente tenta obter o resultado completo, e com que velocidade a empresa aprende a resolvê-las.

Criatividade também depende de escolher entre possibilidades

Mais adiante, a conversa voltou ao Instagram e ao que significa inventar um produto. Mike explicou que o Instagram reuniu elementos que já existiam, como fotos, mídia social e publicações. Sobre o resultado, comentou:

“Alguma coisa nessa combinação realmente funcionou”

Sua explicação foi que elementos já existentes encontraram uma combinação que funcionava bem no contexto do iPhone. Isso não reduz a importância da criação. Mostra que o trabalho criativo também está na seleção, na combinação e na adequação a uma experiência concreta.

Mike contou ainda que havia montado um protótipo de escrita no qual o modelo, em vez de oferecer uma única continuação, apresentava alternativas: “ele mostra oito”. A escolha de como continuar a história abriu uma experiência que ele considerou interessante.

Vejo aí uma aplicação prática para times de produto. Em vez de pedir ao modelo a solução final para uma tela, o time pode pedir oito propostas com hipóteses realmente diferentes: uma que reduza a quantidade de decisões, outra que privilegie comparação, uma terceira que organize o trabalho por exceções. A exploração só tem valor se produzir diferenças que um usuário consiga experimentar.

O custo de gerar variantes cai, mas a atenção para avaliá-las continua limitada. Portanto, gerar mais não basta. É preciso decidir o que cada variante tenta aprender, escolher algumas e observar como as pessoas usam. Se oito telas compartilham a mesma hipótese equivocada, a abundância visual não trouxe aprendizagem.

Ao mencionar a criação de jogos e o processo de experimentar protótipos, Mike retornou a esse limite: “esse processo precisa desse playtest”.

O exemplo de Big Walk, citado por ele, reforça a importância de experiências que dependem da interação entre pessoas. O site oficial apresenta um jogo cooperativo; a interpretação sobre como o protótipo orientou seu desenvolvimento é o relato de Mike sobre uma entrevista que leu, não uma observação minha do processo do estúdio.

O novo gargalo da equipe de produto

O relato sobre protótipos e playtests traz o raciocínio de volta ao contato com usuários. Na minha leitura, reduzir o tempo de construção não elimina o tempo necessário para compreender uma necessidade e observar se uma solução funciona. [Gravação, 35:37–36:25]

Se construir uma versão passa a levar horas, mas conseguir acesso a um usuário leva três semanas, a principal restrição mudou. A equipe precisa olhar para a frequência de seus testes, a qualidade de suas perguntas e a capacidade de transformar observação em decisão.

Dario Amodei oferece uma lente útil para esse gargalo. Em Machines of Loving Grace, publicado em outubro de 2024, o CEO da Anthropic discute como inteligência adicional encontra limites na velocidade dos experimentos, na disponibilidade de dados e nas restrições humanas. Sua expressão é “marginal returns to intelligence”. Ele também admite que esses limites podem mudar com novas ferramentas. É uma hipótese sobre o impacto de IA muito poderosa, não uma medição dos produtos atuais.

Minha aplicação dessa ideia ao desenvolvimento é prática: se o gargalo está em conseguir uma decisão do cliente, gerar mais código não o resolve automaticamente. O time pode usar IA para preparar melhores protótipos e organizar evidências, mas ainda precisa de um mecanismo para obter a decisão. Antes de trocar de modelo, eu mediria onde o trabalho fica parado.

A pesquisa sobre a curva J da produtividade oferece um contexto mais amplo: tecnologias de uso geral demandam investimentos complementares em processos, organização e conhecimento antes que todo o ganho apareça. A ligação com software gerado por IA é minha leitura desse trabalho, não um resultado específico dos autores sobre Artifacts.

Para começar, um experimento contaria com quatro decisões:

1. Problema: escolher uma necessidade temporária, com usuários acessíveis e consequências limitadas.
2. Critério: definir o resultado esperado e o que demonstraria que a aplicação falhou.
3. Teste: criar poucas variantes com hipóteses diferentes e observar uma delas em uso real.
4. Destino: decidir quando encerrar, manter ou incorporar a solução a outro sistema, com os registros necessários exportados.

A história do aplicativo entre três empresas me interessa porque aponta para um mercado de necessidades que nunca chegou a virar backlog. Há muito trabalho à espera de uma ferramenta adequada. A IA amplia a capacidade de construí-la; a qualidade da nossa escuta continua determinando se vale a pena.