¿Qué es Stanford CS146S?
Stanford CS146S es CS146S: The Modern Software Developer, un curso impartido por Mihail Eric y ofrecido por primera vez en otoño de 2025. Para la visión oficial del curso, el overview y los detalles del syllabus, la referencia principal es themodernsoftware.dev.
Para consultar las tareas y el material práctico, el repositorio oficial es mihail911/modern-software-dev-assignments. Ese repositorio, publicado por mihail911 —la cuenta de GitHub de Mihail Eric—, se presenta como “Assignments for CS146S: The Modern Software Dev (Stanford University Fall 2025)”.
Ese contexto importa porque aclara la apuesta del curso: Stanford ya no trata el AI coding como una curiosidad, sino como parte del oficio. Mi crítica no es esa premisa. Mi crítica es que la conversación todavía necesita una disciplina mucho más explícita de arquitectura y reemplazabilidad para sistemas generados con AI.
Stanford está formalizando algo real
Que Stanford lance una asignatura así ya dice bastante.
Durante años, la postura respetable fue tratar el AI coding como un juguete, un atajo o una capa delgada de productividad encima de la “ingeniería real”. Esa postura ya está envejeciendo mal.
Por la descripción pública del curso y la secuencia de tareas, CS146S cubre prompting, flujos de trabajo con Cursor y Warp, servidores MCP, agentes de codificación autónomos, security scanning, AI code review y generación de apps en múltiples stacks. No es un seminario de novedad. Es el reconocimiento de que el propio software development se está reorganizando alrededor de los modelos.
Stanford tiene razón en esto. El desarrollador de software moderno sí necesita entender cómo escribir buenos prompts, cómo trabajar con agentes, cómo conectar herramientas, cómo revisar outputs y cómo shippear más rápido con AI dentro del loop. Fingir lo contrario es simplemente quedarse atrás del mercado.
La primera versión nunca fue el problema
Donde creo que la conversación actual sobre AI development sigue quedándose corta es aquí: el AI coding rara vez falla en la versión uno.
La versión uno es la parte fácil.
La pantalla de login funciona. El dashboard renderiza. El flujo CRUD sale a producción. La demo recibe aplausos. Los problemas empiezan en el cambio cuatro, cinco y seis, cuando el equipo necesita cambiar el auth provider, reemplazar analytics, desenredar una decisión temprana de styling o añadir una feature sin romper otros tres sistemas no relacionados.
Ahí es donde la mayoría de los codebases generados con AI muestran lo que realmente son: rápidos de producir, caros de cambiar.
El failure mode central no es que el modelo escriba tonterías. El failure mode central es que el sistema generado tiene boundaries débiles, así que cada cambio posterior arrastra un radio de impacto invisible.
Saber usar herramientas no es lo mismo que tener seguridad estructural
Un curso puede enseñar prompting, flujos de trabajo de AI IDE, MCP, agent automation, Semgrep, Graphite y generación multi-stack. Todo eso importa. Nada de eso garantiza que el codebase resultante siga sano después de un mes de iteración.
Un equipo puede ser excelente en flujos de trabajo AI-native y aun así construir un sistema donde:
- las screens importan implementation details directamente
- los módulos generados filtran vendor APIs hacia el app code
- los optional services se inicializan como hard dependencies
- una segunda LLM review se trata como verificación
- cada refactor se convierte en trabajo arqueológico
Por eso no creo que la ventaja decisiva del AI-native development vaya a venir solo del dominio de herramientas.
Va a venir de una arquitectura que sobreviva cambios repetidos.
El tema que falta es la reemplazabilidad
Todo subsistema generado por AI debería tratarse como reemplazable por defecto.
Eso significa auth detrás de una interfaz. Analytics detrás de una interfaz. Storage detrás de una interfaz. Styling detrás de un contract. La construcción de dependencias en una sola composition root. Validation en los bordes del sistema. Checks deterministas en cada commit.
Si un mal módulo puede borrarse y reimplementarse detrás del mismo contract, la velocidad de AI se acumula. Si cada parte generada mete mano en todas las demás, el equipo acabará frenándose sin importar lo buenos que sean los prompts.
Este es el tema que me gustaría ver mucho más explícito en las conversaciones sobre AI development.
La pregunta clave no es solo “¿Puede la AI ayudarnos a sacar la primera versión más rápido?”
La pregunta clave es “¿Qué tan barato podemos reemplazar la versión equivocada cuando aparezca la realidad del producto?”
El desarrollador de software moderno sigue necesitando guardrails
Gran parte del consejo actual sobre AI todavía se apoya demasiado en el gusto:
- escribir mejores prompts
- revisar con más cuidado
- comparar múltiples salidas del modelo
- darle más contexto al agente
- añadir otro AI reviewer
Eso ayuda. No escala como base.
La revisión humana es inconsistente. La revisión del modelo es todavía más inconsistente. El único patrón en el que confío a escala es:
- dejar que la AI genere
- dejar que las reglas deterministas hagan enforcement
- dejar que los humanos juzguen la specification y los tradeoffs
Por eso sigo volviendo a lo mismo: contracts, boundary rules, composition roots, contract tests y checks rápidos no negociables. El objetivo no es hacer que el modelo se comporte perfecto. El objetivo es hacer que el sistema sea estructuralmente más difícil de dañar.
Stanford tiene razón. El siguiente paso es más difícil.
CS146S importa porque formaliza una verdad que la industria ya no puede ignorar: el AI-native development ya forma parte del oficio.
Pero no creo que el desarrollador de software moderno quede definido solo por su fluidez con AI tools.
La siguiente barra es más alta.
El desarrollador de software moderno también necesita saber cómo construir codebases donde las partes generadas por AI puedan limitarse, verificarse y reemplazarse sin arrastrar todo el sistema a un rewrite.
Stanford está enseñando al desarrollador de software moderno.
Bien.
La clase que falta es la disciplina de arquitectura que evita que un codebase AI-native colapse bajo su propia velocidad.