Что такое Stanford CS146S?

Stanford CS146S — это курс The Modern Software Developer, который ведет Mihail Eric и который впервые запускается осенью 2025 года. За официальным обзором курса и деталями программы стоит идти на themodernsoftware.dev. Задания вынесены в GitHub-репозиторий mihail911/modern-software-dev-assignments Михаила Эрика (mihail911). В описании репозитория прямо сказано: “Assignments for CS146S: The Modern Software Dev (Stanford University Fall 2025)”. Уже по этой связке видно главное: Stanford больше не считает AI coding периферийной темой, а признает его частью современной программной практики. Именно здесь курс прав — моя критика начинается там, где решающими становятся AI-архитектура, границы системы и заменяемость.

Stanford формализует нечто реальное

Сам факт того, что Stanford выделяет под этот сдвиг отдельный курс, формализует нечто реальное.

Годами респектабельной позицией было считать AI coding игрушкой, коротким путем или тонким слоем продуктивности поверх «настоящей инженерии». Эта позиция уже очень быстро устаревает.

Если смотреть на публичное описание курса и последовательность заданий, CS146S охватывает prompting, рабочие процессы Cursor и Warp, MCP servers, autonomous coding agents, security scanning, AI code review и multi-stack app generation. Это не семинар про модную новинку. Это признание того, что разработка программного обеспечения как таковая перестраивается вокруг моделей.

Stanford здесь прав. Современный разработчик программного обеспечения действительно должен понимать, как хорошо писать prompt, как работать с agents, как соединять инструменты, как проверять outputs и как быстрее выпускать продукт, когда AI находится в рабочем цикле. Делать вид, что это не часть профессии, значит просто отставать от рынка.

Проблемой никогда не была первая версия

Вот где, как мне кажется, нынешний разговор об AI development все еще недооценивает проблему: AI coding редко ломается на первой версии.

Первая версия — как раз самая легкая часть.

Login screen работает. Dashboard рендерится. CRUD flow выпускается. Demo получает аплодисменты. Проблемы начинаются на четвертом, пятом и шестом изменении, когда команде нужно заменить auth provider, поменять analytics, распутать раннее styling decision или добавить feature, не зацепив при этом еще три несвязанные системы.

Именно тогда большинство AI-generated codebases показывают, чем они являются на самом деле: быстро производятся, но дорого меняются.

Главный режим отказа не в том, что модель пишет ерунду. Главный режим отказа в том, что у сгенерированной системы слабые boundaries, поэтому каждое последующее изменение несет невидимый радиус воздействия.

Владеть инструментами — не то же самое, что иметь структурную безопасность

Курс может учить prompting, рабочим процессам AI IDE, MCP, agent automation, Semgrep, Graphite и multi-stack generation. Все это важно. Но ничто из этого не гарантирует, что получившийся codebase останется здоровым через месяц итераций.

Команда может отлично владеть AI-native рабочими процессами и все равно построить систему, где:

  • screens напрямую импортируют implementation details
  • generated modules протекают vendor APIs в app code
  • optional services инициализируются как hard dependencies
  • второй LLM review принимают за verification
  • любой refactor превращается в археологию

Именно поэтому я не думаю, что решающее преимущество AI-native development придет только из владения инструментами.

Оно придет из архитектуры, которая переживает повторяющиеся изменения.

Недостающая тема — replaceability

Любой AI-generated subsystem по умолчанию нужно считать replaceable.

Это означает: auth за interface. Analytics за interface. Storage за interface. Styling за contract. Dependency construction в одной composition root. Validation на system edges. Deterministic checks на каждом commit.

Если плохой module можно удалить и реализовать заново за тем же contract, скорость AI начинает compound’иться. Если каждая сгенерированная часть тянется ко всем остальным, команда неизбежно замедлится, какими бы хорошими ни были prompts.

Именно эту тему мне хотелось бы видеть гораздо более явной в разговорах об AI development.

Ключевой вопрос не только в том, «может ли AI помочь нам быстрее выпускать первую версию?»

Ключевой вопрос в том, «насколько дешево мы можем заменить неверную версию, когда проявится product reality?»

Современному разработчику программного обеспечения все еще нужны guardrails

Многие текущие советы про AI все еще слишком сильно опираются на вкус:

  • писать prompts лучше
  • тщательнее проверять
  • сравнивать несколько выводов модели
  • давать agent больше контекста
  • добавлять еще одного AI reviewer

Это помогает. Но как фундамент это не масштабируется.

Человеческая проверка непоследовательна. Проверка моделью еще более непоследовательна. Единственный паттерн, которому я доверяю в масштабе, выглядит так:

  • пусть AI generate’ит
  • пусть deterministic rules делают enforcement
  • пусть люди оценивают specification и tradeoffs

Поэтому я снова и снова возвращаюсь к одному и тому же: contracts, boundary rules, composition roots, contract tests и быстрые проверки, по которым нельзя торговаться. Цель не в том, чтобы заставить модель вести себя идеально. Цель в том, чтобы сделать систему структурно более трудной для повреждения.

Stanford прав. Следующий шаг сложнее.

CS146S важен потому, что формализует истину, которую индустрия больше не может игнорировать: AI-native development теперь часть ремесла.

Но я не думаю, что современный разработчик программного обеспечения определяется только свободным владением AI tools.

Следующая планка выше.

Современный разработчик программного обеспечения должен также понимать, как строить codebase, в которых AI-generated parts можно ограничивать, верифицировать и заменять, не втягивая всю систему в rewrite.

Stanford учит современного разработчика программного обеспечения.

И это хорошо.

Но по-прежнему не хватает курса про архитектурную дисциплину, которая не дает AI-native codebase рухнуть под собственной скоростью.