Como Trabalhar com um Desenvolvedor em um App Criado com IA

Para trabalhar bem com um desenvolvedor em um app que você criou com IA, dê a ele o código em um repositório Git, um resumo de uma página sobre o que o app faz e por quê, e uma tarefa claramente delimitada com uma definição de pronto. Combinem quem muda quais partes, para que você e a IA não sobrescrevam o trabalho dele; mantenha o repositório e as contas de hospedagem no seu nome e compartilhe os segredos pelas configurações adequadas, não por mensagens.

Muita gente cria a primeira versão de um app com IA e depois traz um desenvolvedor, para adicionar pagamentos, corrigir algo que a IA continua errando, revisar a segurança ou assumir o app conforme ele cresce. Se você ainda está decidindo se deve contratar, veja contratar um desenvolvedor ou construir com IA. Este guia parte do princípio de que você já decidiu e quer que a colaboração seja tranquila.

Quando vale a pena contratar um desenvolvedor

Motivos comuns para trazer alguém:

• Um problema que a IA não resolve depois de várias tentativas claras e reversões.
• Áreas de risco: pagamentos, permissões, dados sensíveis, migrações de banco de dados.
• Uma revisão de segurança ou de código antes do lançamento ou antes de atender clientes maiores.
• Desempenho quando o tráfego real chegar.
• Crescimento: o app virou um negócio e precisa de alguém que seja dono do código.

Ser claro sobre qual desses motivos se aplica molda tudo o que vem a seguir.

Passo 1: coloque o código em um lugar que possa ser compartilhado

Desenvolvedores trabalham a partir de repositórios Git. Antes de entrar em contato com alguém:

1. Conecte o projeto a um repositório privado no GitHub (ou similar), ou exporte-o.
2. Garanta que nenhum segredo esteja no código ou no histórico. Veja como manter as chaves de API seguras.
3. Verifique se o projeto roda a partir de uma cópia limpa: peça à IA que escreva os passos de configuração.

Escreva um README para um desenvolvedor que está entrando neste projeto: o que o app faz, a stack, como instalar e rodar localmente, as variáveis de ambiente de que precisa (apenas os nomes), a estrutura de pastas e tudo o que for frágil ou incomum.

Se Git é novidade para você, como usar o Git com um app criado com IA explica o básico.

Passo 2: escreva um resumo de uma página

O desenvolvedor não acompanhou o seu histórico de conversa. Dê a ele o contexto em uma página:

• O que o app faz, para quem e quantas pessoas o usam.
• O que mais importa: os fluxos que nunca podem quebrar.
• Problemas conhecidos e o que você já tentou.
• A tarefa e como você saberá que ela está concluída.
• Restrições: orçamento, prazo, coisas que ele não deve mudar.

Uma boa "definição de pronto" é testável: "Um usuário logado consegue pagar um plano mensal com o Stripe Checkout, o plano aparece na página da conta dele, e cancelar pelo portal do cliente rebaixa o plano ao fim do período." Não "resolver os pagamentos".

Passo 3: dê acesso com segurança

• Código: adicione a pessoa como colaboradora no repositório. Não fiquem enviando arquivos ZIP de um lado para o outro depois que o trabalho começar.
• Criador: se o seu criador de apps com IA suporta membros de equipe, convide a pessoa para um workspace que contenha apenas este projeto.
• Segredos: adicione-os nas configurações da sua hospedagem ou compartilhe por um gerenciador de senhas. Nunca cole chaves em e-mails ou no chat.
• Contas de teste: crie contas com dados de teste, em vez de compartilhar o seu próprio login.
• Dados de produção: só se a pessoa realmente precisar, e apenas o necessário.

Mantenha o repositório, o domínio e as contas de hospedagem no seu nome. Adicione pessoas; não entregue contas.

Passo 4: combinem quem muda o quê

A maior fonte de atrito é ter duas partes, você com uma IA e o desenvolvedor, mudando o mesmo código ao mesmo tempo. Escolham uma regra:

Qualquer que seja a escolha: puxe o código mais recente antes de cada sessão de pedidos, e faça mudanças grandes em branches que a outra pessoa possa revisar.

Passo 5: comuniquem-se por escrito

• Relate problemas com passos, resultado esperado e resultado real. Veja como escrever um bom relatório de bug.
• Mantenha as decisões em um só lugar: um rastreador de tarefas, um documento compartilhado ou comentários no pull request.
• Peça que ele explique as mudanças em linguagem simples em cada pull request.
• Combinem com que frequência vão conversar.

Passo 6: revise o trabalho dele

Você não precisa ler código para revisar o trabalho. Verifique:

• Faz o que o resumo pedia, na prévia ou na cópia de staging.
• Nada mais quebrou: rode seus fluxos críticos.
• Ele explicou o que mudou e por quê.
• Nenhum segredo apareceu no código.

Para uma análise mais de perto, como revisar código gerado por IA traz uma checklist que também funciona para código escrito por pessoas. Você também pode pedir ao seu criador de IA que explique em termos simples o pull request de um desenvolvedor.

Passo 7: mantenha a propriedade clara

• O repositório, a hospedagem, o domínio e as contas de terceiros continuam sendo seus.
• Registre por escrito a propriedade do código que ele escrever, antes do início do trabalho. Consulte as regras locais ou um consultor para questões contratuais.
• Quando o trabalho terminar, remova o acesso dele e troque as chaves que ele viu.

Exemplos de prompts

Um desenvolvedor alterou o código do checkout no último pull. Explique em linguagem simples o que ele mudou e se mais alguma parte do app depende disso.

Liste as partes deste app que são mais complexas ou arriscadas, para que eu possa indicar a um desenvolvedor onde focar a revisão.

Estou passando os pagamentos para um desenvolvedor. A partir de agora, não toque em nenhum arquivo em src/payments ou nas rotas /api/billing. Se uma mudança precisar deles, me avise em vez de mexer.

Erros comuns

• Não ter um resumo. O desenvolvedor gasta horas pagas tentando adivinhar o que você queria.
• Escopo vago, como "corrigir os bugs" ou "deixar pronto para produção".
• Os dois editando ao mesmo tempo sem puxar antes, e perdendo trabalho em conflitos.
• Compartilhar o seu login ou colar chaves no chat.
• Contas no nome do desenvolvedor, o que dificulta a separação depois.
• Esquecer de remover o acesso e de trocar as chaves depois do trabalho.

Checklist

• O código está em um repositório privado no meu nome, sem segredos.
• Um README explica a configuração; um resumo de uma página explica o app e a tarefa.
• A tarefa tem uma definição de pronto testável.
• O acesso é feito por convites de colaborador, e os segredos pelas configurações ou por um gerenciador de senhas.
• Combinamos quem muda o quê, e eu puxo antes de pedir.
• O trabalho é revisado em relação ao resumo e aos fluxos críticos.
• A propriedade está registrada por escrito; o acesso é removido e as chaves trocadas quando o trabalho termina.

Trabalhando com um desenvolvedor no Mythex

• Convide a pessoa para um workspace. Os donos podem convidar colaboradores ilimitados, sem taxa por assento; os membros trabalham nos projetos do workspace. Use um workspace separado para que a pessoa veja apenas este projeto. Os créditos para apps publicados são cobrados do dono do workspace. Veja Convites.
• Sincronização com GitHub e exportação (Pro). Conecte um repositório e envie e receba mudanças, ou exporte o projeto deixando os segredos de fora. Veja GitHub, exportação e importação.
• Compartilhe um link de prévia para mostrar um trabalho em andamento a alguém que não tem conta no Mythex; exclua-o quando terminar.
• O modo Perguntar responde perguntas sobre o código sem alterá-lo, o que é útil para entender as mudanças de um desenvolvedor.

Se o desenvolvedor vai rodar o app em outro lugar, veja como exportar e hospedar por conta própria um app criado com IA.

Perguntas