O que um construtor de apps com IA faz e não faz hoje

Um construtor de apps com IA gera um app full-stack funcionando a partir de uma descrição, e para muito software do dia a dia isso basta. O que ele não faz é substituir o julgamento sobre segurança, conformidade e arquitetura, e alguém do seu time continua responsável por isso.

A gente faz uma ferramenta dessas, então leia com esse filtro. Mesmo assim, prefiro que você escolha a ferramenta certa a ficar frustrado na terceira semana. Segue onde eu acho que a linha passa.

Onde funciona bem

O ponto ideal é software feito de formulários, listas, tabelas, regras e telas em volta de um banco de dados. Isso cobre bem mais coisa do que o pessoal admite.

• Ferramentas internas: fila de aprovação, controle de estoque, painel administrativo que substitui aquela planilha compartilhada.
• Apps de cadastro (CRUD): qualquer coisa em que pessoas criam, consultam, editam e apagam registros, com alguns perfis de acesso.
• Páginas de agendamento e solicitação: consultas, orçamentos, formulários de triagem com visão do operador.
• Dashboards: ler dados que você já tem e mostrar de forma clara.
• Landing pages e sites institucionais pequenos.
• Protótipos e primeiros MVPs, quando o objetivo é aprender rápido e poder mudar de rumo.

Nesses casos o código gerado é convencional, o risco é baixo e o ganho é velocidade. Você descreve o app num chat, vê o preview ao vivo e corrige o que ficou diferente do que queria.

Onde não serve bem

Algoritmo customizado pesado vem primeiro. Otimização de rotas, motor de preço com regras fora do comum, tudo em que a parte difícil é a matemática. O modelo pode rascunhar, mas você precisa de um engenheiro que prove que está certo e rápido.

Tempo real em grande escala vem em segundo. Estado compartilhado entre jogadores, leilão ao vivo, dados em streaming para milhares de usuários. Aqui a arquitetura pesa mais que as telas e exige desenho cuidadoso e teste de carga.

Trabalho regulado, o terceiro. Prontuário médico, dados de pagamento, qualquer coisa que um auditor vai olhar. O código gerado serve de ponto de partida, mas precisa de revisão qualificada, e o processo em volta importa tanto quanto o código. Se envolve dados pessoais, LGPD entra na conversa desde o começo.

Sistema de marca no pixel, o quarto. Você ganha uma interface limpa e consistente rápido. Se o time de design tem um sistema detalhado, com tokens e regras de animação rígidas, conte com um bom tempo para ajustar o resultado.

E apps nativos de celular. O StarBuild cria apps web e ainda não suporta apps mobile. Um app web que funciona bem na tela do celular não é o mesmo que um app nas lojas, e prefiro dizer isso logo de cara.

Alguém ainda precisa ler o código

Código gerado é código. Pode estar errado de formas silenciosas: uma checagem de permissão que faltou, uma consulta lenta com dado real, uma regra que funciona no exemplo que você deu e quebra no caso de borda que você esqueceu de contar.

Para qualquer coisa além de protótipo, peça a um dev que revise como revisaria o pull request de um colega. Por isso exportar para o Git importa. Se o código está no seu repositório, valem a sua revisão, a sua governança e as suas ferramentas. Se você não consegue tirar o código, não consegue revisar direito e fica preso.

Segurança básica que você mesmo confere

• Segredos: chaves de API e senhas ficam em configuração do servidor, nunca no código que o navegador recebe. Pergunte onde ficam guardadas e quem consegue ver.
• Autenticação: o login deve vir de um mecanismo consolidado, e toda tela e endpoint sensível precisa checar quem está pedindo, não só esconder um botão.
• Dados: saiba onde ficam, quem pode ler, se há backup e como você apagaria os dados de um usuário que pedir.
• Dependências: apps gerados usam bibliotecas. Alguém precisa mantê-las atualizadas.

O que "verificado antes de você ver" prova

Antes de você ver uma mudança, o StarBuild roda typecheck, lint, build e um teste no navegador, e mostra um recibo do que passou. É útil. Diz que o código compila, segue regras básicas de estilo, builda e que um caminho roteirizado pelo app funcionou.

Não prova que o app é seguro, que as regras de negócio são as que você queria, que aguenta carga, nem que atende a uma norma. Recibo verde quer dizer "nada óbvio quebrado". Nunca quer dizer "correto". Pense num detector de fumaça, não numa vistoria.

Controle de custo sem susto

Cobrança por uso é onde a confiança se perde, então aqui vai como funciona. Você compra créditos pré-pagos e cada mensagem gasta alguns. Antes de a mensagem rodar, aparece uma estimativa e um teto, então você sabe o máximo antes de enviar. Se a IA quebrar algo no caminho, ela conserta sem cobrar ou volta para a versão anterior. Você também pode voltar a qualquer versão antiga por conta própria.

Seja qual for a ferramenta, o princípio vale: você deve conseguir prever o pior caso de uma ação antes de executá-la.

Perguntas para fazer a qualquer fornecedor

• Posso exportar o código-fonte completo para o meu Git, hoje, sem pedir permissão a ninguém?
• O que exatamente é verificado antes de eu ver o resultado, e o que não é?
• Existe estimativa e teto antes de cada ação que custa dinheiro?
• O que acontece quando a IA quebra algo? Eu pago pelo conserto?
• Consigo voltar a uma versão anterior com um passo só?
• Onde ficam meus dados e segredos, e quem do fornecedor tem acesso?
• O que vocês não suportam? Peça a lista e desconfie se não houver nenhuma.

Fornecedor bom responde rápido e sem rodeio. Resposta vaga também é resposta. Se você é PO, faça um piloto pequeno antes de se comprometer: escolha uma ferramenta interna de que você realmente precisa, construa, peça a um dev para revisar o código e veja como foi o processo. Uma semana disso ensina mais que qualquer demo e mostra cedo se a ferramenta combina com o jeito de trabalhar do seu time.