Dev & EngARTIGO

Stanford reformula curso de engenharia de software depois que alunos passaram a resolver a lição com um agente

No CS146S, disciplina que Mihail Eric leciona em Stanford e testa na prática como líder de IA na Monaco, o dever de casa agora é mandar patch para projeto open source de verdade, porque exercícios fechados já caem num único prompt.

Stanford reformula curso de engenharia de software depois que alunos passaram a resolver a lição com um agente
Imagem gerada por IA
Artigo · Dev & Eng
Leitura
6 min
Fontes
1

No CS146S, disciplina que Mihail Eric leciona em Stanford e testa na prática como líder de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → na Monaco, o dever de casa agora é mandar patch para projeto open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → de verdade, porque exercícios fechados já caem num único prompt.

No CS146S, disciplina que Mihail Eric leciona em Stanford e testa na prática como líder de IA na Monaco, o dever de casa agora é mandar patch para projeto open source de verdade, porque exercícios fechados já caem num único prompt.

Mihail Eric dá duas respostas diferentes para a mesma pergunta: o que um engenheiro de software precisa saber para trabalhar hoje. Uma resposta é o CS146S, disciplina eletiva que ele leciona em Stanford sob o nome The Modern Software Developer. A outra é a rotina de líder de IA na Monaco, startup onde colegas usam agentes de código tanto para lançar funcionalidades quanto para investigar incidentes em produção. Ele contou as duas em entrevista de mais de uma hora ao podcast Latent Space, publicada em 8 de novembro de 2026 pelo editor swyx, como prévia da conferência AI Engineer CODE que acontece na semana seguinte em São Francisco.

O relato interessa a quem contrata, treina ou é júnior agora: mostra, com nomes e números, o que uma universidade de ponta já considerou obsoleto no espaço de um ano letivo.

Quando o exercício vira prompt único

A primeira turma do CS146S, no outono de 2025, tinha nove exercícios e um projeto final. Um deles pedia que o aluno rodasse um revisor de código baseado em IA sobre um repositório e avaliasse o retorno. Fazia sentido pedagogicamente: expunha o estudante à ferramenta e ao tipo de feedback que ela gera.

O problema apareceu na segunda oferta da disciplina. Mihail Eric percebeu que boa parte desses exercícios virava tarefa de um prompt só. Em pesquisa informal com a turma, formada por estudantes do segundo e terceiro ano, nenhum aluno disse mais escrever código à mão: todos já usavam algum agente no dia a dia. Um exercício pensado para ensinar virou, na prática, um teste de quem sabia formular melhor o pedido.

A lição agora é mandar patch para humano revisar

A solução não foi complicar o enunciado. Foi trocar o alvo. Parte do dever de casa da nova turma é contribuir de fato com um projeto open source, com a mantenedora ou mantenedor do repositório revisando o patch enviado pelo aluno. O agente ainda resolve a implementação em uma tarde. O que ele não resolve é descobrir se a mantenedora quer aquela mudança, por que o código se comporta daquele jeito específico e o que o patch pode quebrar em outro lugar do sistema.

Mihail EricLíder de IA na Monaco

Você compra para aprender, e constrói para manter.

No original: You buy to learn, and you build to keep.

Fonte: Latent Space

É esse atrito, a conversa com quem decide o que entra no projeto, que falta em um exercício fechado. Mihail Eric descreve o mecanismo como o mesmo que faz um engenheiro júnior aprender com um sênior: não é a linha de código, é o motivo por trás dela.

Nota da redação: as descrições de ferramentas e casos de terceiros citados nesta matéria (explain-diff, de Geoffrey Litt, e Minions, da Stripe) se baseiam no relato do entrevistado e nas notas do episódio da Latent Space, não em documentação oficial dos respectivos fabricantes. Valide o funcionamento dessas ferramentas antes de usar em produção.

Uma ferramenta citada na entrevista ajuda exatamente nesse ponto e serve para qualquer PR gerado por agente, não só para sala de aula. Segundo Mihail Eric, a skill explain-diff, de Geoffrey Litt, pega uma alteração de código e transforma em um passo a passo visual, seguido de perguntas sobre o que mudou. Rodar isso sobre o último patch que um agente escreveu é um jeito concreto de descobrir qual pergunta só se responde reabrindo o código.

Comprar para aprender, construir para manter

A segunda metade da entrevista sai da sala de aula e entra na engenharia da Monaco, onde Mihail Eric lida com a mesma pergunta em escala de produto. A equipe avaliou várias ferramentas de revisão de código automatizada e manteve o Devin. Para workspaces de agente, ambiente onde um agente roda o produto, reproduz uma falha e testa o próprio patch, o caminho foi outro: construir internamente, porque o detalhe de como a nuvem da empresa está configurada não se resolve com produto de prateleira.

Mihail Eric resume o critério assim:

Você compra para aprender, e constrói para manter.

Mihail Eric, líder de IA na MonacoYou buy to learn, and you build to keep.

O resultado interno chama-se Hal. Um engenheiro pede para investigar algo que quebrou e abrir um PR. Uma pessoa de vendas pergunta ao mesmo sistema como uma funcionalidade do produto funciona. A saída útil não é a mesma nos dois casos: para quem programa, é uma mudança revisável; para quem vende, é uma explicação que dá para repassar ao cliente. Entregar um despejo de log de debug para as duas pessoas serviria só a uma delas.

O review virou o gargalo, e os números confirmam

A entrevista cita um dado do estudo How to Kill the Code Review, produzido pela Faros: equipes com adoção alta de IA fecharam 98% mais pull requests, mas o tempo de revisão desses PRs ficou 91% maior. O agente acelera a escrita; quem revisa não acelerou na mesma proporção. Isso bate direto com o motivo de Stanford ter trocado exercício fechado por mantenedor de carne e osso: a etapa que resiste à automação é justamente a de decidir se a mudança deve entrar no projeto.

Para equipes que já sentem esse engarrafamento, a entrevista também recupera as Cinco Etapas de Adoção de IA, framework de Boris Cherny usado como referência no fim da conversa para separar adoção pessoal (um dev usando agente sozinho) de autonomia de equipe (processo e revisão redesenhados em torno do agente). São estágios diferentes, e confundir um com o outro é como medir produtividade individual e achar que ela resolve o review coletivo.

O que falta: memória institucional do código

Um agente enxerga o estado atual do repositório. O que ele não enxerga, segundo o ponto levantado na entrevista a partir do conceito de Authority Map (da Basis), é por que a equipe rejeitou uma mudança parecida seis meses atrás. Essa lacuna de contexto histórico é o motivo pelo qual Mihail Eric aposta que repositórios open source vão virar fábricas de software operadas por agente, com humano ainda decidindo o que entra. É também por isso que mandar um estudante conversar com uma mantenedora hoje continua valendo a pena: alguém precisa guardar essa memória que o agente não tem de onde puxar.

A conversa cita ainda, segundo o relato do entrevistado e as notas do episódio, o caso dos Minions, da Stripe, como exemplo em produção de agente em segundo plano com ambiente próprio e caminho definido até a revisão de um engenheiro, e menciona de passagem a convergência de infraestrutura em torno de portais MCP como tendência discutida no episódio.

O que não muda

Mihail Eric é explícito sobre o limite da própria disciplina: CS146S não substitui ciência da computação tradicional, não ensina algoritmo do zero e pressupõe aluno com base sólida. O recorte da aula é o que fazer com essa base quando o trabalho de implementação pode ser delegado a um agente: arquitetura, trade-off de sistema, e a régua de contratação que ele descreve como bem mais alta para quem entra júnior hoje, próxima do que se esperava de um sênior há poucos anos. Para quem contrata no Brasil, o recado é menos sobre qual ferramenta comprar e mais sobre que parte do trabalho ainda exige alguém decidindo, não só gerando.

Fonte

Latent Space, "How Stanford Teaches AI-Native Engineering, Mihail Eric, Monaco" (https://latent.space/p/cs146s/), publicado em 8 de novembro de 2026.

Fonte: Latent Space

Highlights

  1. Stanford trocou exercícios fechados por contribuição a projetos open source porque agentes resolvem tarefas isoladas em um prompt
  2. Todas as turmas de CS146S já usam agentes; mudança é arquitetura, trade-off de sistema e decisão sobre o que entra
  3. Estudantes aprendem agora conversando com mantenedores, não gerando código; memória institucional ainda requer humano
  4. Monaco construiu internamente seu ambiente de agentes (Hal) porque particularidades da nuvem não se resolvem com produto de prateleira
  5. Equipes com alta adoção de IA abrem 98% mais PRs, mas revisão ficou 91% mais lenta; review é o novo gargalo

Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.

Alan AndradeColunista

Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.

Mais de Alan Andrade
Ver perfil →