IA Aplicada a Coding

Há poucos anos, "IA para programar" significava sugestões de autocomplete — terminar a linha que já estavas a escrever. Ferramentas como Claude Code, Cursor ou GitHub Copilot mudaram isso: hoje um agente de coding consegue ler ficheiros inteiros do teu projeto, propor e aplicar alterações em vários ficheiros ao mesmo tempo, correr comandos no terminal, e até testar o resultado — tudo dentro de uma conversa.

A diferença entre "autocomplete" e "agente"

• Autocomplete: sugere a continuação do que já escreveste, uma linha ou um pequeno bloco de cada vez. Tu manténs o controlo total, decisão a decisão.
• Agente: recebe um objetivo em português ("adiciona um botão de exportar dados a este ecrã"), decide sozinho que ficheiros precisa de ler e alterar, faz as alterações, e reporta o resultado. Tu supervisionas o resultado final, não cada linha.

Nenhuma das duas formas substitui a outra — vais usar as duas consoante o problema. Um erro de sintaxe pequeno pede autocomplete; uma funcionalidade nova que toca em vários ficheiros pede um agente.

Porque isto não substitui saberes programar

Um agente de coding é tão bom quanto a supervisão que lhe dás. Se não perceberes lógica, tipos, estruturas de dados ou o que um erro significa, não vais conseguir avaliar se o que o agente produziu está correto, seguro, ou sequer a resolver o problema certo — só vais poder "esperar que funcione". Tudo o que aprendeste nas fases anteriores é exatamente o que te permite usar estas ferramentas com critério, em vez de às cegas.

Por si só, um modelo de IA só sabe gerar texto — não pode, sozinho, aceder à tua base de dados, ao teu terminal, ou a um serviço externo como o GitHub. É aí que entram os protocolos que ligam o modelo a ferramentas.

MCP (Model Context Protocol)

O MCP é um protocolo aberto que permite a um agente de IA ligar-se a serviços externos — uma base de dados, um sistema de ficheiros, uma API — de forma padronizada. Em vez de cada ferramenta ter de ser integrada à mão numa aplicação de IA específica, um servidor MCP expõe as suas capacidades de uma forma que qualquer agente compatível consegue usar. Na prática, isto significa que podes ligar o teu assistente de IA diretamente a, por exemplo, um repositório Git, uma base de dados, ou um sistema de gestão de tarefas, e pedir-lhe para agir sobre esses sistemas dentro de uma conversa.

Skills: instruções reutilizáveis para tarefas específicas

Uma skill é um pacote de instruções (e por vezes scripts ou ficheiros de referência) que ensina um agente como fazer bem uma tarefa específica e recorrente — por exemplo, como criar um relatório num formato específico, ou como seguir o estilo de código de um projeto em particular. Em vez de repetires as mesmas instruções detalhadas em cada conversa, uma skill fica disponível e é usada automaticamente quando relevante.

O que isto significa para ti agora

Não precisas de dominar como construir um servidor MCP ou uma skill nesta fase — precisas de saber que estas peças existem, e que é isso que torna um agente de coding capaz de fazer mais do que "só conversar": ligar-se a ferramentas reais é o que separa um chatbot de um verdadeiro colaborador técnico.

Os fornecedores de IA (Anthropic, OpenAI, Google, entre outros) costumam oferecer vários modelos, com diferenças reais de velocidade, custo e capacidade. Escolher bem não é só "usar sempre o mais avançado" — é escolher o que serve a tarefa.

Três fatores a pesar

1. 1Complexidade da tarefa. Corrigir um erro de sintaxe ou renomear uma variável não precisa do modelo mais capaz disponível — um modelo mais pequeno e rápido resolve isso perfeitamente. Planear a arquitetura de um sistema com várias partes interligadas, ou depurar um bug subtil e raro, beneficia de um modelo mais capaz.
2. 2Velocidade necessária. Se estás a iterar rapidamente (testar pequenas variações, várias vezes seguidas), um modelo mais rápido mantém-te no ritmo. Se a tarefa é única e importante, vale a pena esperar mais por uma resposta mais cuidada.
3. 3Custo. Modelos mais capazes custam tipicamente mais por uso. Para tarefas repetitivas em grande volume, isso soma-se rapidamente — vale a pena reservar o modelo mais caro para o que realmente precisa dele.

Um hábito prático

Antes de pedires ajuda numa tarefa, pergunta-te: "isto é uma correção mecânica, ou uma decisão que exige raciocínio?" Tarefas mecânicas (formatar, renomear, traduzir um erro simples) servem-se bem de ferramentas rápidas e baratas. Decisões de arquitetura, debugging complexo ou código com implicações de segurança merecem o modelo mais cuidadoso que tiveres disponível — e, mesmo assim, a tua própria revisão final.

Um pedido vago produz uma resposta genérica; um pedido específico produz uma resposta útil. Isto não é diferente de pedir ajuda a um colega: "o meu código não funciona" ajuda muito menos do que "esta função devia devolver a lista ordenada por data, mas está a devolver undefined — aqui está o código e o erro exato".

Os quatro ingredientes de um bom pedido técnico

1. 1Contexto. Em que fase estás, que tecnologias estás a usar, o que já tentaste.
2. 2O problema exato. Cola o código relevante e a mensagem de erro completa (lembra-te da Fase 0: onde, o quê, que tipo de erro).
3. 3O comportamento esperado vs o observado. "Esperava X, mas está a acontecer Y."
4. 4Restrições. Se não queres que a IA reescreva tudo, ou queres manter um determinado estilo, diz isso explicitamente — sem essa informação, a IA não tem como adivinhar.

Itera em vez de pedir tudo de uma vez

Para problemas complexos, é normalmente melhor pedir em passos: primeiro pede um plano ou uma explicação da abordagem, confirma que faz sentido, e só depois pedes a implementação. Isto é exatamente o que os prompts desta plataforma (como o desta fase, no topo da página) te pedem para fazeres — e é um hábito que vais levar para qualquer ferramenta de IA que uses no futuro.

O que NÃO pedir

Evita pedir "resolve isto todo" para problemas que ainda não decompuseste tu mesmo, mesmo que informalmente. Se não consegues descrever o problema em 2-3 frases claras, provavelmente ainda não o percebeste bem o suficiente para avaliar se a resposta da IA está certa — volta primeiro ao pseudocódigo da Fase 1.

Quando um agente de coding pode gerar centenas de linhas em segundos, o risco real não é "a IA enganar-se" — é tu deixares de perceber o que o teu próprio projeto faz. Este tema propõe um fluxo de trabalho para evitar isso.

1. Planeia antes de gerar

Descreve a funcionalidade, discute a arquitetura (que ficheiros, que estrutura de dados, que rotas), e só depois pedes a implementação. É o mesmo princípio da Fase 1: pseudocódigo antes de código.

2. Revê tudo o que for gerado, linha a linha

Não aceites alterações que não consegues explicar por palavras tuas. Se uma função gerada por IA usa algo que não reconheces, pergunta o que faz antes de a aceitares — é exatamente a mesma disciplina de leitura de código que praticaste desde a Fase 0.

3. Testa incrementalmente

Não peças "constrói a aplicação inteira" de uma vez. Pede uma parte, testa-a, confirma que funciona, e só depois avanças para a seguinte — os mesmos hábitos de tabela de teste e verificação manual que praticaste ao longo de todo este plano continuam a aplicar-se, agora a código que não escreveste tu mesmo à mão.

4. Usa Git como rede de segurança

Faz commit do teu código antes de pedires uma alteração grande a um agente. Se o resultado não for o que esperavas, tens sempre a versão anterior a um git checkout de distância (Fase 7). Isto elimina o medo de "experimentar" e permite-te ser mais ambicioso nos pedidos.

O desafio final: mini-SaaS

O último exercício desta fase pede-te para planear e construir uma pequena aplicação completa — com frontend, backend e base de dados — usando IA como copiloto do início ao fim, mas seguindo exatamente este fluxo. É o teste real de tudo o que aprendeste nesta plataforma: se conseguires supervisionar esse processo com confiança, já não estás a aprender a programar — já estás a programar.