Desenvolvimento de Software Apoiado por IA — 2026.4

Aula 1
Apresentação da Disciplina

👨‍🏫 Prof. Gustavo Pinto 🏛️ UFPA 📅 1 de setembro de 2026 🕐 20h

A tese da disciplina

Se o agente escreve o código, o que sobra para o engenheiro de software?

Sobra decidir o que construir
Sobra especificar de forma que outra entidade consiga executar
Sobra revisar o que voltou
Sobra responder pelo que foi entregue

O que esta disciplina não é

Não é sobre construir agentes: não vamos implementar um harness nem treinar modelo
Não é sobre teoria de LLMs: vamos ver o mínimo para prever onde a ferramenta falha
Não é um curso de prompt: prompt é meio, não fim

O agente é o instrumento. O produto é o sistema de software que você entrega.

Três estudos, três respostas diferentes

Peng et al. 2023

Copilot acelerou uma tarefa controlada de forma significativa.

arxiv.org/abs/2302.06590

METR 2025

Devs experientes ficaram 19% mais lentos em bases que conheciam bem.

metr.org

Anthropic 2026

400 mil sessões reais de Claude Code, com taxas de sucesso que variam com a expertise.

anthropic.com/research

Por que os três podem estar certos ao mesmo tempo?

Quem decide o quê

Pessoas tomam cerca de 70% das decisões de planejamento
Pessoas tomam cerca de 20% das decisões de execução
A cada instrução, o agente executa em média 10 ações
Sessões de iniciantes: 15% de sucesso verificado. De especialistas: 28% a 33%

Compreensão do domínio pesa mais que anos de código. O agente trabalha melhor quando bem dirigido.

O que é Forward Deployed Engineer?

Engenheiro que se instala dentro do time do cliente: participa da daily, commita no repositório dele, e responde pela solução até ela estar em produção.

Nasceu na Palantir, para fechar a distância entre contrato assinado e código rodando
Hoje OpenAI, Anthropic e Google contratam para o mesmo perfil
Autonomia de fundador, rigor técnico de staff engineer, e contato direto com o problema real

Por que o FDE importa para vocês

O gargalo deixou de ser escrever código e passou a ser entender o problema
Quem entende o domínio dirige melhor a ferramenta, e entrega mais rápido
É um perfil que combina engenharia, contato com usuário e entrega em produção

O projeto desta disciplina é um exercício de FDE: achar um usuário real, entender o problema dele, e publicar algo que funcione.

O critério que organiza o semestre

Toda dupla termina com um sistema funcionando, publicado, em uma URL que qualquer pessoa abre.

Escopo pequeno e terminado vale mais que escopo grande e inacabado
A aplicação vai ao ar no Portão 1, ainda incompleta, e evolui publicada
Quem deixa a publicação para o fim costuma não publicar

Estrutura da disciplina

Parte I · Fundamentos

01/09 a 15/10

10 aulas e 2 laboratórios
Especificar, dirigir, revisar
Testar e publicar

Parte II · Projeto

20/10 a 10/12

3 portões de entrega
Clínicas e seminários
Aplicação no ar

Fechamento

10/12 a 22/12

Demo Day
Defesa oral
Buffer

Revisão e teste vêm antes de o projeto começar. Quem só aprende a gerar código, e não a julgar o código gerado, acumula dívida sem perceber.

Cronograma · Parte I

#	Data	Dia	Conteúdo
1	01/09	Ter	Apresentação. Quem decide o quê
2	03/09	Qui	Como um assistente de código funciona por dentro
—	08/09	Ter	CBSoft 2026, sem aula
—	10/09	Qui	CBSoft 2026, sem aula
L1	15/09	Ter	Lab: dirigindo o agente numa funcionalidade real
3	17/09	Qui	Decomposição de tarefas e engenharia de contexto
L2	22/09	Ter	Lab: AGENTS.md e smells de configuração. Entrega AP1
4	24/09	Qui	Spec-Driven Development, e a evidência contrária
5	29/09	Ter	Testes como contrato
6	01/10	Qui	Revisão de código gerado
7	06/10	Ter	Código legado
8	08/10	Qui	Qualidade e segurança do código gerado
9	13/10	Ter	Medição e entrega. Entrega AP2
10	15/10	Qui	Custo, limites e o que continua humano

Cronograma · Parte II

#	Data	Dia	Conteúdo
KO	20/10	Ter	Kickoff do projeto: duplas e escolha do problema
—	22/10	Qui	Oficina: SPEC.md e primeira publicação
G1	27/10	Ter	Portão 1: SPEC.md, testes em CI e aplicação no ar
—	29/10	Qui	Clínica de código: revisão coletiva de PRs
S1	03/11	Ter	Seminário crítico de artigos
S2	05/11	Qui	Seminário crítico de artigos
—	10 e 12/11		Acompanhamento dos projetos
G2	17/11	Ter	Portão 2: sistema completo, legado e revisão
—	19/11	Qui	Acompanhamento dos projetos
—	24/11	Ter	Clínica de segurança: auditoria cruzada
—	26/11	Qui	Acompanhamento dos projetos
DO	01 e 03/12		Defesa oral individual
—	08/12	Ter	Nossa Senhora da Conceição, sem aula
G3	10/12	Qui	Portão 3: Demo Day
—	15, 17 e 22/12		Buffer, fechamento e notas

Avaliação

💻 Atividades Práticas	AP1 em 22/09, AP2 em 13/10	30 pts
🏗️ Projeto	Três portões: 27/10, 17/11, 10/12	50 pts
📝 Diário de uso	Uma entrada por aula, no repositório	10 pts
🎤 Defesa oral	Individual, em 01/12 e 03/12	10 pts

As duas atividades práticas

AP1 · do spec ao deploy

Escrever o SPEC.md antes do código, conduzir o agente até funcionar, e publicar.

Entrega em 22/09

AP2 · brownfield e revisão

Receber o repositório de outra dupla, adicionar funcionalidade e entregar uma revisão crítica.

Entrega em 13/10

Na AP2, a nota vem do rigor da revisão, não do tamanho da funcionalidade.

O projeto e os três portões

Portão 1 · 27/10

10 pontos

SPEC.md versionado
Testes em CI
Aplicação no ar
Sem URL, não passa

Portão 2 · 17/11

15 pontos

Sistema completo
Marco em código legado
Relatório de revisão
Custo medido

Portão 3 · 10/12

25 pontos

Demo ao vivo, 12 min
Na URL pública
Relatório final
Defesa das decisões

Tema livre, desde que exista um usuário identificável que não seja a própria dupla.

Diário de uso

Uma entrada por aula, em diario/AAAA-MM-DD.md, enviada por commit no dia. O histórico do git carimba a data de cada entrada.

# Aula 07 (06/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 índice em evento(data).
O que aprendemos. Ele não considera custo de consulta se a
   spec não menciona.

Registro honesto de falha vale mais nota do que registro que só relata sucesso.

Ferramentas

Agente

Claude Code como referência nas aulas. Cursor, Copilot, Codex e Gemini CLI são aceitos no projeto.

documente a escolha

Repositório

GitHub público, com código, SPEC.md, AGENTS.md, testes e diário.

um por dupla

Hospedagem

Vercel, Render, Fly.io, Supabase ou GitHub Pages.

livre, desde que gratuita

A stack é escolha da dupla. Não há linguagem obrigatória.

Regras de convivência com a ferramenta

O uso de agentes não é permitido, é obrigatório. É o objeto de estudo
Se o agente sugere X, entenda por que X e não Y, e saiba defender
Se ele escreveu 800 linhas e você não explica 20, essas 20 não deveriam ter entrado
Documente o processo no diário. Ocultar o uso é que é desonestidade acadêmica

Na apresentação final: se você vier apenas para ler o que o agente escreveu, por favor, nem venha.

Exercício: refazer um PR que já existe

Comecem agora, aqui. Terminem no computador, até a próxima aula.

Escolham um projeto de código aberto que vocês usam
Achem um pull request pequeno, já fechado e mergeado, que corrija um bug
Peçam ao agente a mesma correção, sem mostrar o patch
ENTENDAM o que o agente fez, e onde difere do que o projeto mergeou

Entrega: essa comparação, como primeira entrada do diário de uso.

Até a próxima aula

Formar as duplas e criar o repositório no GitHub
Criar a pasta diario/ e registrar ali o exercício
Instalar e autenticar um agente de código
Ler os três estudos e preparar a explicação da contradição

Na semana de 08 a 11/09 não haverá aula, por conta do CBSoft 2026. As atividades assíncronas vencem em 15/09.

Dúvidas?

Próxima aula: como um assistente de código funciona por dentro

📧 gpinto@ufpa.br

Aula 1Apresentação da Disciplina