Desenvolvimento de Software Apoiado por IA
Horário
Terça e Quinta, 20h. De 01/09/2026 a 22/12/2026.
Objetivo
Capacitar o aluno a construir e entregar sistemas de software reais usando agentes de IA como ferramenta de trabalho, sabendo especificar, dirigir, revisar, testar e responder pelo que a ferramenta produz.
Esta não é uma disciplina sobre como construir agentes. É sobre como construir software com eles. O agente é o instrumento; o produto é o sistema.
Ementa
Agentes de código: harness, laço de execução, ferramentas e capacidades. Engenharia de contexto e decomposição de tarefas. Skills e conhecimento procedural versionado. Specification-Driven Development (SDD, desenvolvimento guiado por especificação). Model Context Protocol. Loop engineering. Testes como contrato e revisão de código gerado. Evolução de código legado. Qualidade, segurança e custo do código gerado.
O que se espera
Todas as atividades são feitas em duplas: não individualmente, não em trio.
Ao fim do semestre, cada dupla entrega um sistema funcionando e publicado, em uma URL que qualquer pessoa consiga abrir no dia da apresentação. Desse critério decorre o resto:
- Escopo pequeno e terminado vale mais do que escopo grande e inacabado.
- Deploy (publicação em produção) desde cedo. O sistema vai ao ar no Portão 1, ainda incompleto, e evolui publicado. Quem deixa a publicação para o final costuma não publicar.
- Você responde pelo que assina. O agente escreve o código, mas a decisão é sua, e você vai defendê-la no Demo Day.
- Medir antes de opinar. Toda afirmação sobre o que a ferramenta melhorou vem com o número que a sustenta.
Não se espera que vocês implementem agentes do zero nem escrevam código melhor que o agente. Espera-se que saibam especificar, dirigir, revisar e entregar.
A Parte I, de 01/09 a 20/10, tem oito aulas e uma atividade prática, e termina com o papel do forward deployed engineer. A Parte II, de 22/10 a 15/12, é o projeto. Revisão e teste vêm antes de o projeto começar, porque quem só aprende a gerar código, e não a julgar o código gerado, acumula dívida técnica sem perceber.
Ferramentas
Usaremos o Claude Code como referência nas aulas. Cada dupla pode adotar outra ferramenta no projeto (Cursor, GitHub Copilot, Codex, Gemini CLI), desde que documente o uso e saiba justificar a escolha. Quem tiver dificuldade de acesso pago deve falar comigo na primeira semana.
Cada dupla mantém um repositório público no GitHub com o código, o SPEC.md, o AGENTS.md, os testes e o diário de uso. A hospedagem é livre, desde que gratuita: Vercel, Render, Fly.io, Supabase ou GitHub Pages atendem. A stack é escolha da dupla.
Avaliação
- Atividade Prática (AP1): 30 pontos
- Projeto de Disciplina (AP2): 50 pontos
- Diário de uso: 20 pontos
Atividade Prática
AP1, uma aplicação de verdade com SDD. Lançada em 29/09, apresentada em 01/10. 30 pontos.
Cada dupla escolhe e constrói uma aplicação não trivial, conduzindo o agente pelo fluxo spec, plan, tasks visto na Aula 5. Exemplos: pedido de comida, carona e divisão de viagens, avaliação de lugares. A escolha é da dupla.
Requisitos: aplicação publicada em URL pública, pelo menos 100 mil linhas de código, uma spec datada para cada parte do sistema na pasta SPEC/, escrita antes do código, e o registro de todos os prompts, do primeiro ao último, com a ferramenta e o modelo usados. Na apresentação de 01/10, cada dupla mostra a aplicação no ar e percorre os prompts.
As diretrizes da AP1 trazem a estrutura de pastas, a organização das specs, o registro de prompts, o padrão de commits, a contagem de linhas e o roteiro da apresentação.
Diário de uso
Em toda aula, cada dupla registra o que fez com o agente, em diario/AAAA-MM-DD.md, enviado por commit no dia. O histórico do git carimba a data de cada entrada, então dez registros escritos na véspera aparecem como dez registros escritos na véspera.
Cada entrada cabe em dez linhas:
# Aula 07 (01/10)
**Objetivo.** Adicionar filtro por data na listagem de eventos.
**Ferramenta.** Claude Code, ~40 min, 3 iterações.
**O que o agente entregou.** Filtro funcionando, mas consultando o banco a cada tecla.
**O que mudamos à mão.** Debounce de 300ms e um índice em `evento(data)`.
**O que aprendemos.** Ele não considera custo de consulta se a spec não menciona.
O diário alimenta o relatório de processo dos Portões 2 e 3. Registros honestos sobre falhas valem mais nota do que registros que só relatam sucesso.
Projeto de Disciplina
AP2, elevar o nível da aplicação de outra dupla. Lançada em 22/10, no kickoff. 50 pontos.
Tema. As mesmas duplas da AP1 assumem a aplicação da AP1 de outra dupla, escolhida da lista apresentada no kickoff. Ninguém escolhe um projeto em que trabalhou, e cada projeto fica com uma única dupla. Os autores originais passam a ser os clientes: respondem às perguntas da dupla, mas não escrevem código.
A dupla trabalha como forward deployed engineer (Aula 8), responsável pelo negócio e pela técnica: estuda o código, entende o que foi feito, define o que ainda falta e implementa.
Requisitos.
- Em hipótese alguma o projeto é reescrito. Trocar linguagem ou framework, abrir repositório novo ou apagar módulos inteiros para refazer anula a entrega. Refatorar pode, de forma localizada, justificada numa issue e coberta por teste.
- Investigação do uso real antes de mudar. O que foi construído foi de fato usado? Há gamificação (pontos, níveis, conquistas, ranking), ela funciona e engajou alguém? Toda resposta vem com evidência: registros no banco, logs, deploy, histórico de commits e issues.
- 100 mil linhas novas, sem atalhos, contadas com o mesmo
clocda AP1 como diferença entre o fork e o último commit da AP1. O que o projeto já tinha não entra na conta. Código duplicado, gerado em massa ou morto só para inflar a contagem não conta. - Os artefatos de sempre: specs novas datadas em
SPEC/, escritas antes do código; todas as sessões do agente emprompts/sessoes/; commits com os trailersAgent:eSpec:; histórico sem reescrita. - Fork
dsai-ap2-<nome>publicado em URL pública, com testes em integração contínua (CI), a partir do Portão 1.
Critérios. A avaliação segue o que, na Aula 8, ficou com os humanos. Cada critério precisa de evidência no repositório: uma spec, um commit, um PR ou um teste.
| Etapa | O que a dupla precisa demonstrar |
|---|---|
| Requisitos | Qual problema escolheu resolver e o que deixou fora do escopo, numa spec datada na pasta SPEC/ |
| Dados | O modelo de dados fixado e cada dependência nova aprovada, com a justificativa |
| Testes | Critérios de aceite e casos de borda (entrada nula, permissão, concorrência) definidos pela dupla, e cada teste novo falhando sem a mudança |
| Revisão | Cada merge aprovado pela dupla, com leitura linha a linha do que toca autenticação, migração e segredos |
| Produção | Integração contínua, aplicação no ar, plano de rollback e orçamento de tokens documentados |
Portões.
- Portão 1, em 29/10. Fork no ar com testes em CI, relatório de investigação do uso real (incluindo a gamificação) e a primeira spec nova. Sem URL e sem CI, não passa. 10 pontos.
- Portão 2, em 19/11. Funcionalidades novas em produção, relatório de revisão do código gerado e custo de uso medido. 15 pontos.
- Portão 3, em 15/12. Demonstração ao vivo de 12 minutos na URL pública, relatório final e defesa das decisões técnicas e de processo. 25 pontos.
Sobre o uso de agentes
Nesta disciplina o uso de agentes não é permitido, é obrigatório. É o objeto de estudo.
O que muda é o padrão de exigência. Se o agente sugere X, entenda por que X e não Y, e saiba defender a escolha. Se ele escreveu 800 linhas e você não sabe explicar 20 delas, essas 20 não deveriam ter entrado no repositório. Ocultar o uso é que configura desonestidade acadêmica, não usar.
E, na apresentação final: se você vier apenas para ler o que o agente escreveu, por favor, nem venha.
Atividades Assíncronas
Na semana de 08 a 11/09 estarei no CBSoft 2026, no IME-USP, e não haverá aula em 08/09 e 10/09. Entregas para 17/09: a leitura dirigida da Aula 1, com uma página explicando a contradição entre os três estudos, e as duas entradas de diário da semana.
Cronograma
Passível de alterações. Verificar o calendário acadêmico oficial da UFPA para feriados estaduais e municipais.
| # | Data | Dia | Conteúdo |
|---|---|---|---|
| 1 | 01/09 | Ter | O que é um agente. Quem decide o quê: 70% do planejamento é humano, 80% da execução é do agente |
| 2 | 03/09 | Qui | Agentes: memória, ferramentas e planejamento. O laço de execução, e uma primeira olhada em MCP |
| — | 08/09 | Ter | CBSoft 2026, sem aula (atividade assíncrona) |
| — | 10/09 | Qui | CBSoft 2026, sem aula (atividade assíncrona) |
| — | 15/09 | Ter | Sem energia elétrica na UFPA, aula não realizada |
| 3 | 17/09 | Qui | Engenharia de contexto e decomposição de tarefas |
| 4 | 22/09 | Ter | Skills: conhecimento procedural versionado, SKILL.md, divulgação progressiva |
| 5 | 24/09 | Qui | Specification-Driven Development, e a evidência que contraria a promessa |
| AP1 | 29/09 | Ter | Lançamento da AP1: escolha da aplicação e início da construção com SDD |
| AP1 | 01/10 | Qui | Apresentação da AP1: aplicação no ar e percurso dos prompts |
| — | 06/10 | Ter | Sem aula |
| 6 | 08/10 | Qui | Model Context Protocol: dando ferramentas ao agente, e a superfície de risco que vem junto |
| 7 | 13/10 | Ter | Loop engineering: agentes disparados por evento, critério de parada, ponto de escalação |
| — | 15/10 | Qui | Dia do Professor, sem aula |
| 8 | 20/10 | Ter | Forward deployed engineer: o engenheiro que trabalha dentro do cliente. O que continua humano |
| KO | 22/10 | Qui | Kickoff do Projeto (AP2): escolha da AP1 de outra dupla, investigação do uso real e regras |
| — | 27/10 | Ter | Acompanhamento dos projetos |
| — | 29/10 | Qui | Acompanhamento dos projetos |
| — | 03/11 | Ter | Acompanhamento dos projetos |
| — | 05/11 | Qui | Acompanhamento dos projetos |
| — | 10/11 | Ter | Acompanhamento dos projetos |
| — | 12/11 | Qui | Acompanhamento dos projetos |
| — | 17/11 | Ter | Acompanhamento dos projetos |
| G2 | 19/11 | Qui | Apresentação dos projetos |
| — | 24/11 | Ter | Buffer |
| — | 26/11 | Qui | Buffer |
| — | 01/12 | Ter | Buffer |
| — | 03/12 | Qui | Passagem para o cliente: PR de volta ao repositório original, com notas de passagem (o que mudou, rollback, custo em tokens) |
| — | 08/12 | Ter | Nossa Senhora da Conceição, sem aula (feriado municipal em Belém) |
| — | 10/12 | Qui | Buffer |
| G3 | 15/12 | Ter | Portão 3, Demo Day: apresentações finais, 12 minutos por dupla |
| — | 17/12 | Qui | Buffer |
| — | 22/12 | Ter | Buffer, fechamento e notas |
Leituras
Uma leitura de referência por aula, marcada em negrito. As demais são complementares.
Aula 1, o que é um agente. Anthropic (2026), How Claude Code is used in practice, com cerca de 400 mil sessões. Complementares: METR, 2025 e Peng et al., 2023. Os três se contradizem, e explicar isso é a atividade da semana.
Aula 2, harness e capacidades. Vats e Golev (2026), The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable, que mediu até 40 vezes de diferença em tokens por tarefa resolvida trocando só o harness, com a taxa de acerto variando de 0 a 8 pontos. Complementar: Harness Engineering for Agentic AI Coding Tools.
Aula 3, contexto. Anthropic, Effective context engineering for AI agents. Complementar: Barke, James e Polikarpova, Grounded Copilot, OOPSLA 2023.
Aula 4, skills. From Anatomy to Smells: An Empirical Study of SKILL.md, que analisou 238 skills reais e derivou uma taxonomia dos seus componentes. Complementares: Anthropic, Agent Skills, e Agent Skills in the Wild, que encontrou vulnerabilidade em 26,1% de 31 mil skills. Sobre AGENTS.md: a especificação e Santos et al., Configuration Smells in AGENTS.md Files, que achou ao menos um problema em 91 de 100 repositórios.
Aula 5, SDD. Hill (2026), Does Spec-Driven Development Reduce Defects?, que testou a promessa em 100.247 PRs e não encontrou a redução anunciada. Complementares: Spec Kit e Piskala, 2026.
Aula 6, MCP. Model Context Protocol at First Glance: Studying the Security and Maintainability of MCP Servers, sobre 1.899 servidores de código aberto. Complementar: MCP, Security Best Practices.
Aula 7, loop engineering. Lulla, Nersesyan, Mohsenimofidi, Treude e Baltes (2026), Loop Engineering: Building Blocks, Adoption, and Impact, que varreu 36.710 repositórios e encontrou loops autônomos operando em 217 deles, com quase nenhum versionando os arquivos de estado do loop.
Aula 8, forward deployed engineer. ML4SE (2026), O que é um Forward Deployed Engineer?. Complementares: Orosz, What are Forward Deployed Engineers, and why are they so in demand?, The Pragmatic Engineer, 2025; Orosz, The Pulse: Forward deployed engineering heats up again, 2026; Orosz, What’s the ROI of software engineers’ spending on AI?, 2026; e Bloomberry, I analyzed 1000 Forward Deployed Engineer jobs.
Material de apoio
- ANTHROPIC. Claude Code — documentação e Best practices for Claude Code. Apoio para a AP1.
- GITHUB. Spec Kit.
- HOU, X. et al. (2024). Large Language Models for Software Engineering: A Systematic Literature Review. ACM TOSEM. (ponto de partida para os seminários)
Entrega atrasada
Entregas após o prazo serão aceitas, mas os pontos referentes não serão contabilizados.
Política de plágio e uso de IA
O uso de ferramentas de IA é obrigatório nesta disciplina, mas deve ser documentado, não ocultado. Submeter trabalho gerado por agente sem registrar o processo, e sem ser capaz de explicá-lo, é considerado desonestidade acadêmica.
Duplas são encorajadas a discutir ideias entre si. Copiar solução ou parte de solução de outra dupla configura plágio, e nesse caso as duplas envolvidas não receberão os pontos da atividade.