O que é Stanford CS146S?
Stanford CS146S é CS146S: The Modern Software Developer, um curso ministrado por Mihail Eric e oferecido pela primeira vez no outono de 2025. Para a visão oficial da disciplina, o overview e os detalhes do syllabus, o ponto de partida é themodernsoftware.dev.
Para consultar os assignments e o material prático, o repositório oficial é mihail911/modern-software-dev-assignments. Esse repositório, publicado por mihail911 — a conta de Mihail Eric no GitHub —, se descreve como “Assignments for CS146S: The Modern Software Dev (Stanford University Fall 2025)”.
Esse enquadramento importa porque deixa clara a aposta do curso: Stanford já não trata AI coding como curiosidade, mas como parte do ofício. Minha crítica não é essa premissa. Minha crítica é que ainda falta uma disciplina muito mais explícita de arquitetura e substituibilidade para sistemas gerados por AI.
Stanford está formalizando algo real
O simples fato de Stanford lançar uma disciplina assim já diz bastante.
Durante anos, a posição respeitável foi tratar AI coding como brinquedo, atalho ou uma camada fina de produtividade em cima da “engenharia de verdade”. Essa posição já está envelhecendo mal.
Pelos materiais públicos do curso e pela sequência de assignments, CS146S cobre prompting, fluxos de trabalho com Cursor e Warp, servidores MCP, agents autônomos de codificação, security scanning, AI code review e geração de apps em múltiplas stacks. Isso não é um seminário de novidade. É o reconhecimento de que o próprio software development está sendo reorganizado em torno de modelos.
Stanford está certo nisso. O desenvolvedor de software moderno realmente precisa entender como escrever bons prompts, trabalhar com agents, conectar tools, inspecionar outputs e shippar mais rápido com AI dentro do loop. Fingir que isso não faz parte do trabalho agora é só ficar para trás do mercado.
A primeira versão nunca foi o problema
Onde eu acho que a conversa atual sobre AI development ainda subestima o problema é aqui: AI coding raramente falha na version one.
Version one é a parte fácil.
A tela de login funciona. O dashboard renderiza. O CRUD flow vai para produção. A demo recebe aplausos. Os problemas começam na mudança quatro, cinco e seis, quando o time precisa trocar o auth provider, substituir analytics, desfazer uma decisão inicial de styling ou adicionar uma feature sem quebrar outros três sistemas não relacionados.
É aí que a maioria dos codebases gerados por AI revela o que realmente é: rápido de produzir, caro de mudar.
O failure mode central não é o model escrever besteira. O failure mode central é o sistema gerado ter boundaries fracas, então toda mudança posterior carrega um raio de impacto invisível.
Fluência em ferramentas não é a mesma coisa que segurança estrutural
Um curso pode ensinar prompting, fluxos de trabalho de AI IDE, MCP, agent automation, Semgrep, Graphite e geração multi-stack. Tudo isso importa. Nada disso garante que o codebase resultante continue saudável depois de um mês de iteração.
Um time pode ser excelente em fluxos de trabalho AI-native e ainda assim construir um sistema em que:
- screens importam implementation details diretamente
- módulos gerados vazam vendor APIs para dentro do app code
- optional services são inicializados como hard dependencies
- uma segunda LLM review é tratada como verificação
- todo refactor vira trabalho arqueológico
Por isso eu não acho que a vantagem decisiva em AI-native development virá apenas do uso de ferramentas.
Ela virá de uma arquitetura que sobreviva a mudanças repetidas.
O tema que falta é substituibilidade
Todo subsystem gerado por AI deveria ser tratado como substituível por padrão.
Isso significa auth atrás de uma interface. Analytics atrás de uma interface. Storage atrás de uma interface. Styling atrás de um contract. Dependency construction em uma única composition root. Validation nas bordas do sistema. Deterministic checks em todo commit.
Se um módulo ruim puder ser apagado e reimplementado atrás do mesmo contract, a velocidade da AI se acumula. Se cada parte gerada meter a mão em todas as outras, o time vai inevitavelmente desacelerar, por melhores que sejam os prompts.
Esse é o tema que eu gostaria de ver muito mais explícito nas conversas sobre AI development.
A pergunta central não é apenas “AI pode nos ajudar a shippar a primeira versão mais rápido?”
A pergunta central é “quão barato conseguimos substituir a versão errada quando a realidade do produto aparecer?”
O desenvolvedor de software moderno ainda precisa de guardrails
Muito do conselho atual sobre AI ainda depende demais de gosto:
- escrever prompts melhores
- revisar com mais cuidado
- comparar múltiplas saídas do modelo
- dar mais contexto para o agent
- adicionar mais um AI reviewer
Isso ajuda. Não escala como fundação.
Review humano é inconsistente. Review do modelo é ainda mais inconsistente. O único padrão em que eu confio em escala é:
- deixar a AI gerar
- deixar regras determinísticas fazerem enforcement
- deixar humanos julgarem a specification e os tradeoffs
É por isso que eu sempre volto às mesmas coisas: contracts, boundary rules, composition roots, contract tests e checks rápidos não negociáveis. O objetivo não é fazer o modelo se comportar perfeitamente. O objetivo é tornar o sistema estruturalmente mais difícil de danificar.
Stanford está certo. O próximo passo é mais difícil.
CS146S importa porque formaliza uma verdade que a indústria já não pode mais ignorar: AI-native development agora faz parte do ofício.
Mas eu não acho que o desenvolvedor de software moderno seja definido apenas por fluência com AI tools.
A próxima barra é mais alta.
O desenvolvedor de software moderno também precisa saber como construir codebases em que partes geradas por AI possam ser limitadas, verificadas e substituídas sem arrastar o sistema inteiro para um rewrite.
Stanford está ensinando o desenvolvedor de software moderno.
Ótimo.
A aula que falta é a disciplina de arquitetura que impede um codebase AI-native de colapsar sob a própria velocidade.