Como Trabalhar com um Programador numa App Criada por IA

Para trabalhar bem com um programador numa app que construiu com IA, dê-lhe o código num repositório Git, um resumo de uma página sobre o que a app faz e porquê, e uma tarefa claramente delimitada com uma definição de conclusão. Combinem quem altera que partes para que você e a IA não sobrescrevam o trabalho dele, mantenha o repositório e as contas de alojamento em seu nome e partilhe os segredos através das definições adequadas, não por mensagens.

Muitas pessoas constroem a primeira versão de uma app com IA e só depois trazem um programador — para acrescentar pagamentos, corrigir algo que a IA continua a fazer mal, rever a segurança ou assumir a app à medida que cresce. Se ainda está a decidir se deve contratar alguém, veja contratar um programador ou construir com IA. Este guia parte do princípio de que já decidiu e quer que a colaboração corra bem.

Quando vale a pena um programador

Razões comuns para trazer alguém:

• Um problema que a IA não resolve após várias tentativas claras e reversões.
• Áreas de risco: pagamentos, permissões, dados sensíveis, migrações de base de dados.
• Uma revisão de segurança ou de código antes do lançamento ou antes de receber clientes maiores.
• Desempenho quando chega tráfego real.
• Crescimento: a app tornou-se um negócio e precisa de alguém que seja responsável pelo código.

Ser claro sobre qual destes casos é o seu molda tudo o que vem a seguir.

Passo 1: Coloque o código num local partilhável

Os programadores trabalham a partir de repositórios Git. Antes de contactar alguém:

1. Ligue o projeto a um repositório privado no GitHub (ou semelhante), ou exporte-o.
2. Certifique-se de que não há segredos no código nem no histórico. Veja como manter as chaves de API seguras.
3. Verifique se o projeto corre a partir de uma cópia nova — peça à IA que escreva os passos de configuração.

Escreva um README para um programador que se junta a este projeto: o que a app faz, a stack, como instalar e correr localmente, as variáveis de ambiente de que precisa (apenas os nomes), a estrutura de pastas e tudo o que for frágil ou invulgar.

Se o Git for novo para si, como usar o Git com uma app criada por IA explica o básico.

Passo 2: Escreva um resumo de uma página

O programador não assistiu ao seu histórico de conversas. Dê-lhe o contexto numa página:

• O que a app faz, para quem, e quantas pessoas a usam.
• O que mais importa — os fluxos que nunca podem falhar.
• Problemas conhecidos e o que já tentou.
• A tarefa, e como saberá que está concluída.
• Restrições: orçamento, prazo, coisas que não devem ser alteradas.

Uma boa "definição de conclusão" é testável: "Um utilizador com sessão iniciada pode pagar um plano mensal com o Stripe Checkout, o plano aparece na página da sua conta, e ao cancelar no portal do cliente é reduzido para o plano inferior no fim do período." Não "resolver os pagamentos".

Passo 3: Dê acesso de forma segura

• Código: adicione-o como colaborador no repositório. Não envie ficheiros ZIP para trás e para a frente depois de o trabalho começar.
• Criador: se o seu criador de apps com IA suportar membros de equipa, convide-o para um espaço de trabalho que contenha apenas este projeto.
• Segredos: adicione-os nas definições do seu alojamento, ou partilhe-os através de um gestor de palavras-passe. Nunca cole chaves em emails ou no chat.
• Contas de teste: crie-as com dados de teste, em vez de partilhar o seu próprio início de sessão.
• Dados de produção: só se realmente precisarem, e apenas o necessário.

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

Passo 4: Combinem quem altera o quê

A maior fonte de atrito são duas partes — você com uma IA, e o programador — a alterar o mesmo código ao mesmo tempo. Escolha uma regra:

Qualquer que seja a escolha: puxe o código mais recente antes de cada sessão de prompts e faça as alterações grandes em branches que a outra pessoa possa rever.

Passo 5: Comunique por escrito

• Comunique os problemas com passos, resultado esperado e resultado real. Veja como escrever um bom relatório de erro.
• Guarde as decisões num único sítio: um gestor de tarefas, um documento partilhado ou comentários nos pull requests.
• Peça-lhe que explique as alterações em linguagem simples em cada pull request.
• Combinem com que frequência vão fazer o ponto da situação.

Passo 6: Reveja o trabalho dele

Não precisa de ler código para rever trabalho. Verifique:

• Faz o que o resumo pedia, na pré-visualização ou na cópia de teste.
• Nada mais se estragou — teste os seus fluxos críticos.
• Explicou o que alterou e porquê.
• Não aparecem segredos no código.

Para uma análise mais detalhada, como rever código gerado por IA tem uma lista de verificação que também funciona para código escrito por pessoas. Pode também pedir ao seu criador de IA que lhe explique, em termos simples, o pull request de um programador.

Passo 7: Mantenha a propriedade clara

• O repositório, o alojamento, o domínio e as contas de terceiros continuam em seu nome.
• Ponha por escrito a propriedade do código que ele escrever antes de o trabalho começar. Verifique as regras locais ou um consultor para questões contratuais.
• Quando o trabalho terminar, remova o acesso dele e substitua quaisquer chaves que tenha visto.

Exemplos de prompts

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

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

Vou entregar os pagamentos a um programador. A partir de agora, não toque em nenhum ficheiro em src/payments nem nas rotas /api/billing. Se uma alteração precisar delas, diga-me em vez de a fazer.

Erros comuns

• Não ter um resumo. O programador gasta horas pagas a descobrir o que queria.
• Âmbito vago, como "corrigir os erros" ou "tornar pronto para produção".
• Ambos a editar ao mesmo tempo sem puxar primeiro, perdendo trabalho em conflitos.
• Partilhar o seu próprio início de sessão ou colar chaves no chat.
• Contas em nome do programador, o que dificulta separar-se dele.
• Esquecer de remover o acesso e substituir as chaves depois do trabalho.

Lista de verificação

• O código está num repositório privado em meu nome, sem segredos.
• Um README explica a configuração; um resumo de uma página explica a app e a tarefa.
• A tarefa tem uma definição de conclusão testável.
• O acesso é feito por convites de colaborador, e os segredos pelas definições ou por um gestor de palavras-passe.
• Combinámos quem altera o quê, e puxo antes de fazer prompts.
• O trabalho é revisto face ao resumo e aos fluxos críticos.
• A propriedade está por escrito; o acesso é removido e as chaves são substituídas quando o trabalho termina.

Trabalhar com um programador no Mythex

• Convide-o para um espaço de trabalho. Os proprietários podem convidar colaboradores ilimitados sem taxas por lugar; os membros trabalham nos projetos do espaço. Use um espaço de trabalho separado para que só veja este projeto. Os créditos das apps publicadas são faturados ao proprietário do espaço. Veja Convites.
• Sincronização com o GitHub e exportação (Pro). Ligue um repositório e envie/puxe alterações, ou exporte o projeto deixando de fora os segredos. Veja GitHub, exportação e importação.
• Partilhe uma ligação de pré-visualização para mostrar trabalho em curso a alguém sem conta no Mythex; apague-a quando terminar.
• O modo Pergunta responde a questões sobre o código sem o alterar — útil para perceber as alterações de um programador.

Se o programador for correr a app noutro sítio, veja como exportar e alojar por conta própria uma app criada por IA.

Perguntas