Stanford ensina alunos a enviar patches aos mantenedores: por dentro do curso CS146S

O que pedir aos alunos quando um agente faz tudo sozinho

É um problema conhecido: você passa uma tarefa a um desenvolvedor júnior, e o Claude Code ou outro agente a resolve com um único prompt. Os professores enfrentam a mesma situação. As tarefas do ano passado deixaram de avaliar o que o aluno aprendeu.

Mihail Eric ministra em Stanford o curso CS146S, The Modern Software Developer, e lidera a área de IA na startup Monaco. Na segunda edição do curso, ele mudou o próprio formato de avaliação. Mantenedores de projetos de código aberto passaram a participar. O aluno precisa entender um repositório desconhecido, propor uma alteração e explicar o patch à pessoa que poderá integrá-lo.

Isso se aproxima bastante do trabalho real. Gerar código agora é barato. O que custa caro é entender uma base de código de terceiros, manter o contexto e se responsabilizar pelo diff. Um mantenedor não vai avaliar a elegância do prompt: vai perguntar por que a alteração é necessária e o que ela vai quebrar.

O que sobreviveu ao contato com produção

Em um episódio do podcast Latent Space que celebra a marca de um milhão de inscritos do canal AI Engineer, Eric apresenta o programa de dez semanas do curso. Ele conta quais lições foram úteis para sua própria equipe de engenharia. Os temas incluem a arquitetura do ciclo, das ferramentas e da estrutura de execução (harness) de um agente de programação; engenharia de contexto para um repositório grande; e as habilidades que ajudam a entender um diff, em vez de aceitá-lo às cegas.

Uma seção específica trata da decisão entre desenvolver e comprar. A Monaco criou internamente seus agent workspaces, ou seja, ambientes de trabalho para cada agente. As ferramentas de revisão de código foram compradas. Já o agente de plantão recebeu acesso ao Datadog e ao GitHub para examinar alertas e relacioná-los ao código por conta própria. Eric resume a fórmula assim: compre para aprender, desenvolva para manter.

Outros assuntos discutidos incluem como preparar um repositório para o trabalho dos agentes, o que fazer quando a revisão de código vira um gargalo, segurança, dependências e permissões de acesso, agentes em segundo plano como o Stripe Minions, portais MCP e a questão de qual trabalho resta aos desenvolvedores.

Limitações e lições práticas

É uma conversa de duas horas, não um estudo com métricas. Até agora, vimos apenas o anúncio e o sumário; os detalhes e números específicos precisam ser conferidos no próprio episódio. Parte do material é abertamente promocional: tanto o próprio canal do podcast quanto a Monaco promovem suas próprias pautas.

Ainda assim, a lição prática é útil. Se você contrata ou desenvolve profissionais juniores, substitua a avaliação de quem escreveu código pela de quem entendeu código de terceiros e defendeu uma alteração. Se está montando uma equipe em torno de agentes, decida antes o que considera uma competência central a ser mantida internamente e o que vai comprar. E, acima de tudo, prepare o repositório para o agente: estrutura clara, testes, acesso à observabilidade e permissões limitadas. Caso contrário, a revisão será o gargalo, e não a geração.