Claude Opus ajudou um analista de negócios a lançar dois aplicativos em duas semanas sem equipe

Um experimento com desenvolvimento de IA mostrou que uma pessoa sem experiência em programação já consegue levar um produto móvel ao mercado. Em duas semanas, um analista de negócios montou dois aplicativos Flutter para RuStore e gastou cerca de 80 horas nisso.

Como o experimento aconteceu

O autor abordou a tarefa como um teste de hipótese: se um analista de negócios sabe como decompor requisitos, escrever histórias de usuários e critérios de aceitação, isso pode ser suficiente para trabalhar com um assistente de IA em vez de um time comum. Para o teste, ele escolheu dois produtos diferentes — um rastreador de tempo "168 Horas" e F1 Tycoon, um jogo sobre gerenciar um time de Fórmula-1. Ele também selecionou a stack através do modelo: Flutter e Dart para desenvolvimento multiplataforma, Supabase como backend gratuito para o MVP.

O cronograma ficou quase como um sprint completo. Os primeiros dois dias foram gastos configurando Flutter e Android Studio, depois começou uma montagem em cadeia de telas para "168 Horas". Em seguida veio o primeiro estágio pesado — integração com Supabase, onde autorização e chamadas de rede rapidamente se transformaram em uma série de correções cíclicas.

Depois disso, o autor enfrentou F1 Tycoon, mas o projeto de jogo em si revelou a principal limitação dos modelos atuais: quanto mais arquivos e dependências, pior eles mantêm a arquitetura geral. No dia 14, ambos os aplicativos passaram pela moderação em RuStore, e as despesas diretas permaneceram em zero.

Onde a IA acelerou o trabalho

De acordo com o autor, os melhores resultados vieram não de ferramentas gratuitas, mas de modelos comerciais mais fortes. As opções gratuitas frequentemente produziam código que não compilava e UI no estilo de projetos acadêmicos antigos. GPT-5.2 mostrou-se notavelmente mais estável, mas foi Claude Opus que entregou o código mais limpo, interface moderna e melhor preservou o contexto do diálogo. Mas há algo mais importante: as habilidades de analista de negócios se alinharam inesperadamente com o que um bom prompting exige.

"IA é como um desenvolvedor júnior: quanto mais preciso o requisito,

mais preciso o resultado."

Na prática, isso não parecia magia, mas como um ciclo muito rápido de colocação de tarefas e verificação de resultados. O autor descrevia uma tela, recebia código, o inseria no projeto, executava no telefone e retornava erros específicos ao modelo. Esse modo era como trabalhar com um júnior remoto muito rápido: a resposta chega em minutos e as correções podem ser verificadas imediatamente em um dispositivo real. Nesse esquema, a IA mostrou-se particularmente útil para várias tarefas típicas:

• gerar componentes UI e telas em minutos
• escolher uma stack inicial para um iniciante sem time
• explicar erros e terminologia em linguagem simples
• escrever código boilerplate e lógica de negócios básica
• preparar para publicação: assinatura de build, chaves, configuração build.gradle

Onde os problemas começaram

A área mais dolorosa foi integrações. Conectar Supabase parecia simples no papel, mas na realidade, uma correção facilmente gerou o próximo bug. O autor descreve um cenário típico: o modelo corrige um erro de autorização por email, depois a tela de registro quebra, então o próximo patch toca outro arquivo.

Em tarefas curtas isso é tolerável, mas em um projeto grande vira um jogo exaustivo onde corrigir um problema local não garante que o app sequer compile como um todo. O segundo problema era a memória do modelo. Quando F1 Tycoon cresceu para 50+ arquivos, a IA parou de lembrar com confiança classes-chave, estrutura do projeto e decisões arquiteturais anteriores.

Para reduzir a perda de contexto, o autor criou um "arquivo de memória" separado descrevendo a estrutura e o fornecia ao modelo no início de cada sessão. Isso ajudou, mas não resolveu completamente o problema. Um risco adicional era os limites de requisições: em um momento crítico, o acesso ao melhor modelo poderia ser cortado por várias horas, e todo o desenvolvimento simplesmente parava.

Ao final do experimento, ambos os lançamentos chegaram à loja, mas juntos receberam apenas 14 downloads.

O que isso significa

A história não prova que a IA já substituiu desenvolvedores, mas mostra bem outra coisa: o limiar para criar um MVP caiu drasticamente. Se uma pessoa sabe como formular requisitos, dividir tarefas e debugar pacientemente, ela já consegue chegar a um lançamento funcional. Mas integrações complexas, arquitetura de projetos grandes e controle de qualidade ainda são áreas onde sem um engenheiro experiente, a velocidade rapidamente atinge um teto mesmo em experimentos solo.