Não estás a escrever código, estás a gerir uma “equipa de IA”

A maioria das pessoas usa um Coding Agent como se fosse um tech lead: revê a arquitetura pessoalmente, inspeciona cada linha, nada vai para produção sem o seu aval. A qualidade fica garantida, sim. Mas a que custo? Tu tornas-te o maior gargalo da linha de produção. Todas as decisões esperam por ti, todos os detalhes passam por ti, e a produtividade do Agent fica refém da tua atenção e do teu tempo.

Os freelancers que realmente ganham dinheiro já fizeram uma mudança de papel crítica: de TL para EM. Em linguagem simples: o TL olha para cada linha de código; o EM só olha para o resultado final. O TL pergunta “este código está correto?”; o EM pergunta “esta funcionalidade passou na aceitação?”. Parece subtil, mas é o que transforma a tua capacidade de “output de uma pessoa” em “output de uma equipa”.

Porque é que agora dá para largar o controlo: os modelos já passaram o ponto de viragem

Largar o controlo exige que a qualidade do código seja sólida. Esse pré-requisito já existe este ano: benchmarks públicos mostram que os modelos de topo ultrapassam os 80% de precisão em tarefas de código, com vantagem esmagadora sobre a geração anterior (as métricas variam conforme a avaliação — vai ver os dados mais recentes no Artificial Analysis e no SWE-Bench, não confies em resumos de segunda mão, incluindo o meu).

O que isto significa? Que o código da IA, com uma validação leve, raramente desvia do objetivo. O retorno marginal de reveres linha a linha já não compensa. Continuar em modo TL é gastar as tuas horas mais caras no controlo de qualidade com pior custo-benefício. O mercado não paga pela tua “precaução” — paga pelo resultado entregue.

Caminho 1: substitui a vigilância linha a linha por “validação de plano + execução por objetivo”

Como aplicar na prática? Primeiro passo: muda o fluxo de trabalho. Depois de definires a funcionalidade, revê o plano técnico com o Agent. Plano aprovado? Entrega-lhe o objetivo junto com o plano e deixa-o executar — escrever código, correr testes automatizados, tudo. A tua única tarefa é validar a funcionalidade no fim, não o código.

Aqui tens um template de prompt pronto a copiar:

1
2
3
4

Quero construir [descrição da funcionalidade].
Restrições: [stack técnica / plataforma / ambientes obrigatórios].
Primeiro apresenta o plano técnico: 1) divisão em módulos; 2) fluxo de dados; 3) armadilhas prováveis.
Só escreves código depois da minha aprovação. No fim, corre os testes e mostra-me os resultados.

Na aceitação, usa esta checklist para travar a qualidade sem abrir o código:

• Corre o fluxo principal manualmente, sem erros no caminho crítico
• Testa um caso-limite de cada tipo (input vazio, input gigante, sem rede)
• Todos os testes automatizados do Agent passam
• Bug encontrado? Não abras o código. Descreve o sintoma ao Agent, deixa-o reproduzir, corrigir e adicionar teste — e validas outra vez

O truque é antecipar o ponto de verificação. No modo TL validas ao nível do código — caríssimo. No modo EM validas ao nível da funcionalidade — uns cliques, uma execução, minutos. Em todo o ciclo, o teu tempo vai apenas para duas coisas: pensar bem no que fazer e confirmar que ficou bem feito.

Caminho 2: a escolha tecnológica deixa de ser “o que eu sei” e passa a ser “o que é melhor”

A mudança de papel traz um bónus escondido: as tuas decisões técnicas deixam de estar presas aos limites das tuas competências. Com mentalidade TL, escolhes a stack que dominas, porque se algo falhar consegues resolver. Com mentalidade EM, só precisas de julgar qual a tecnologia certa para o projeto — o resto fica com o Agent.

Um developer independente partilhou este percurso (segundo o post original, sem verificação independente): ao construir uma app de tradução de legendas, escolheu Electron por conhecer frontend, mas o desempenho nunca o satisfez. Mudou para Swift + AppKit nativo — stack que não dominava — com assistência de IA do início ao fim, sem bloqueios. Para o próximo produto multiplataforma, escolheu logo Rust, que nunca tinha escrito. Acredita ou não no caso, a lógica é testável: esta noite, pega numa stack que não conheces e pede ao Agent para te guiar numa ferramenta de 100 linhas. Vê se te trava. Resumindo: os teus limites deixaram de ser desculpa — escolhe-se o que é melhor, ponto final.

Caminho 3: transforma a velocidade de iteração na tua vantagem competitiva — e faz as contas

Com este modelo afinado, o ciclo de entrega passa de semanas para dias. O cliente pede de manhã, vê uma versão validável à tarde. O concorrente itera uma vez por semana; tu iteras uma vez por dia. Há muita gente a vender serviços de desenvolvimento com IA no Upwork, Fiverr e grupos de freelancers, mas a maioria ainda está na fase “a IA ajuda-me a escrever código”. Com o modo EM, jogas noutra liga.

Conceitos não chegam — vamos às contas (estimativas conservadoras, ajusta ao teu preço):

• Projeto típico de “ferramenta/app pequena”: €250 por trabalho
• Modo TL: 5 dias por projeto entre escrever e corrigir, 4 projetos por mês a full capacity → €1.000/mês
• Modo EM: plano + aceitação ocupam 1,5 dias; enquanto o Agent executa, já estás a fechar o próximo cliente. Ocupação real: 2 dias por projeto, 8-10 projetos por mês → €2.000-2.500/mês
• Custos: subscrição de IA no máximo ~€20/mês; taxa de retrabalho ~10% com a checklist; reserva meio dia de margem por projeto

Ou seja, no mesmo mês, a diferença ultrapassa os €1.000 — e no modo EM o teu limite é o volume de clientes, não a velocidade das tuas mãos. Escreve “versão funcional entregue em 48 horas” na tua página de serviços: é uma diferenciação que ninguém te copia.

O único gargalo és tu, quando não sabes o que construir

Este modelo tem uma restrição real: quando é preciso conceber uma nova versão grande ou uma nova direção de produto, o humano volta a ser o gargalo. Por mais forte que seja, o Agent só executa objetivos claros. Se tu não souberes o que construir, ele não produz uma linha útil.

Por isso, o modo EM exige mais de ti — não em profundidade técnica, mas em julgamento de produto. Tens de investir tempo a perceber o que os clientes procuram no Upwork e no Fiverr, que dores aparecem nos posts do Pinterest e do Lemon8, que ferramentas estão a explodir no TikTok. Todo o tempo que poupavas a rever código deve ir para “pensar no que construir”. É aí que o humano deve estar neste modelo.

Começa hoje: três passos para trocar de papel

Se ainda não fechaste nenhum trabalho, não penses já em duplicar capacidade. Entrada de baixo risco: publica um anúncio de “ferramentas personalizadas com IA” no Fiverr ou em grupos locais de freelancers, a €50-80, e corre o primeiro projeto com estes três passos. Sai de lá com um fluxo reutilizável e noção real de preços.

Primeiro passo: pega num projeto pequeno que tenhas em mãos e proíbe-te de abrir ficheiros de código. Só escreves o plano, defines o objetivo e fazes a aceitação funcional. Regista o tempo total — esses são os teus dados de primeira mão, mais valiosos que qualquer caso de estudo alheio. Segundo passo: torna automático o reflexo de “bug encontrado → descrever ao Agent para reproduzir e corrigir”, sem cair na tentação de mergulhar no código. Terceiro passo: no próximo projeto, escolhe deliberadamente uma stack que não dominas mas que é a ideal, e verifica se a IA te leva até lá.

O ponto de viragem da capacidade de código da IA já passou. A vantagem está a migrar de “quem sabe usar IA para programar” para “quem sabe gerir uma equipa de IA”. Esta noite, escolhe um projeto e corre o fluxo EM completo com o template e a checklist acima.