Damia Group Loyal Talent
Workshop

IA para Programação

Overview + Processo do Dia-a-Dia

Faz scroll ou usa as setas para avançar

Objectivo da sessão

  • Objectivo: dar um overview geral sobre a utilização de ferramentas de IA orientadas para tarefas de programação.
  • Durante a sessão: conceitos essenciais, exemplos e boas práticas.
  • No final: explicamos o processo que utilizamos no nosso dia-a-dia.

O que a IA traz (e o risco principal)

  • A IA acelera: planeamento, execução, revisão, testes, documentação
  • A IA não é fonte de verdade
  • Regra base: o humano decide, a IA executa
  • Risco principal: não detectarmos o erro a tempo

Ferramentas e formatos de utilização

  • Formatos: IDE, Terminal, Web/Cloud
  • Exemplos: Cursor (IDE), Claude Code (Terminal), Codex (Web/Cloud)
  • Hoje, muitos são funcionalmente equivalentes
  • O que muda: ergonomia e integração no fluxo
  • Cada dev usa o formato com que produz melhor, mantendo o mesmo processo

Ferramenta vs Modelo

  • Ferramenta = interface + workflow
  • Modelo = o 'motor' que gera o resultado (qualidade do planeamento, consistência do código, revisão)
  • Na prática, o modelo influencia mais o resultado do que a ferramenta
  • Ainda assim, o mais importante é ter processo: planear, executar por fases e validar

Padrões práticos

  • Claude: forte em planeamento, ambiguidade e UI; tipicamente mais caro
  • OpenAI/Codex: consistente a programar/corrigir; por vezes mais lento, mas tende a errar menos
  • Gemini: muito usado em UI/multimodal; alternativa competitiva
  • Diferenciador real: modelo + contexto + processo

O que é um prompt

  • Prompt = instrução escrita que dás à IA sobre a tarefa a realizar
  • Deve indicar o objectivo e, quando útil, o tipo de resposta pretendido
  • Um bom prompt é claro no resultado
  • Prompt sozinho não chega: precisa de contexto

O que é contexto

Contexto = informação adicional que ajuda a IA a entender o teu cenário e evitar suposições.

Pode vir de:

  • 1) Dev (no pedido)
  • 2) Equipa (guardrails no repo)
  • 3) Ferramenta (ficheiros/diffs, pesquisa, histórico)

Contexto típico: regras, decisões, fontes de verdade, limitações.

Guardrails no repositório

  • Guardrails = contexto persistente que fica no repositório e orienta humanos e agentes
  • Exemplos: AGENTS.md • CLAUDE.md • .cursor/rules
  • Define regras simples: escopo, validação, estilo e segurança
  • Objectivo: consistência + segurança + menos deriva

Exemplo: mau vs bom prompt

Tarefa: criar página de “Definições” para gerir notificações

Mau prompt

"Cria uma página de definições de notificações."

Bom prompt (mínimo viável)

Objectivo claro + contexto essencial. (Opcional) restrições e escopo.

"Objectivo: permitir ao utilizador activar/desactivar notificações por tipo (marketing, produto, sistema). Contexto: manter o estilo actual e reutilizar componentes existentes. Ambito: analisar os ficheiros settings/* e componentes de UI já usados nas preferências."

Exemplo genérico de guardrail: AGENTS.md

  • Para tarefas > 30 min: gerar plano curto antes de alterar código
  • Trabalhar por fases; evitar diffs grandes
  • Commits pequenos e frequentes (checkpoints)
  • Não alterar fora do escopo pedido
  • Não adicionar dependências sem justificar
  • Terminar com checklist de verificação (testes/docs quando aplicável)
  • Segurança: nunca incluir tokens/API keys/credenciais em prompts/outputs

3 modos de trabalho com IA

Planeamento

Clarificar → plano → riscos

Execução

Implementar por fases

Revisão

IA como revisor exigente (bugs, regressões, testes)

Contexto tem limites

  • Dependendo do modelo, a janela de contexto tem limites diferentes
  • Contexto acumula e pode degradar qualidade
  • “Ruído” piora resultados: mais texto ≠ melhor
  • Regra prática: reiniciar por tarefa
    • nova conversa/janela (IDE)
    • nova sessão (terminal)
    • nova tarefa (cloud agent)
  • Guardar decisões fora do chat (PR/issue/nota)

Segurança: o que nunca deve entrar no prompt

  • Nunca partilhar: API keys, tokens, credenciais, segredos
  • Evitar: dados reais de clientes/produção (preferir exemplos sintéticos)
  • Atenção a: .env, logs, screenshots, dumps
  • Regra: se não pode ir para um ticket público, não vai para o chat

Git como ponto de controlo

  • Trabalhar com IA → iterações e alterações mais rápidas no código
  • Git = checkpoints:
    • commits pequenos e frequentes em tarefas longas
    • mensagens com intenção (o que/porquê)
    • reverter rapidamente se algo correr mal
  • Evitar: mega-diffs difíceis de rever

Processo recomendado

  1. Prompt com objectivo da tarefa (Modo Planeamento)
  2. Validar o plano / pedir alterações
  3. Execução por fases (diff pequeno + commits frequentes)
  4. Validação (checklist + guardrails: testes, documentação, etc.)
  5. PR / Entrega

Resumo final

  • Diferencial: processo, suportado por contexto e guardrails
  • Planear primeiro reduz iterações e erros
  • Executar por fases + commits frequentes = controlo e reversão
  • Validar sempre (checklist + testes/docs quando aplicável)
  • Segurança: nunca partilhar segredos ou dados sensíveis

Modo avançado

  • Explorar regularmente novos modelos e ferramentas (o “melhor” muda depressa)
  • Trabalhar em paralelo com Git worktrees (múltiplas tarefas sem trocar de branch/estado)
  • Bots em canais (Teams/Slack/Discord), por exemplo OpenClaw:
    • lançamento/planeamento de tarefas em threads
    • execução e acompanhamento visíveis para toda a equipa
  • Outras ideias para evoluir:
    • “PR review bot” com checklist (riscos, testes em falta, segurança)
    • “Docs bot” para gerar notas de release e documentação curta
    • “Triage bot” para tickets: clarificação, passos de reprodução, impacto e prioridade
    • “Bench bot” para correr checks/benchmarks e devolver resultados num thread