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: Ambito, 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. (Opcional) restrições e ambito.

"Objectivo: permitir ao utilizador activar/desactivar notificações por tipo (marketing, produto, sistema). Analisar os ficheiros settings/* e componentes de UI já usados nas preferências."

Exemplo de guardrail: AGENTS.md

Contexto do Projeto

Refactor e modernização de uma plataforma de gestão de transportes de passageiros, originalmente desenvolvida em 2017 com Laravel 5.2, para Laravel 12.

Stack e Limites do Projeto

  • Backend Laravel 12 (apenas API, sem Blade)
  • Frontend React Native (projeto separado)

Arquitetura da API

Tipo de Aplicação: Exclusivamente API REST. Não utiliza Blade nem serve views.

Fluxo de Endpoint:

Route → FormRequest → Controller → Service → Model/Repository

Princípios: Reutilização de código; separação clara de responsabilidades; controllers magros, services robustos; injeção de dependências via constructor.

Responsabilidades por Camada

  • Route: Definição do endpoint e middleware.
  • FormRequest: Validação de dados de entrada.
  • Controller: Apenas chamadas a serviços; retorna JSON; sem lógica de negócio.
  • Service: Toda a lógica de negócio; pode chamar outros serviços e interagir com modelos.
  • Model/Repository: Representação de dados, relações e acesso aos dados.

Nomenclatura

Classes: PascalCase · Métodos/variáveis: camelCase · Constantes: SCREAMING_SNAKE_CASE · Tabelas/colunas: snake_case

Testes

Usar testes Feature (não Unit); testar endpoints de ponta a ponta; simular requests HTTP reais. Cobertura obrigatória: casos de sucesso, validações, autenticação/autorização, edge cases.

Execução obrigatória no final de cada implementação:

php -d memory_limit=1024M vendor/bin/phpunit

Documentação e Postman

Endpoints documentados em docs/api/ (por módulo, ex: docs/api/auth.md). Incluir: URL, método, payload, resposta, erros. Collection Postman em docs/postman/Tarsibus.postman_collection.json atualizada; cada endpoint com exemplo de request e descrição.

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)

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)

Processo recomendado

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

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

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

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