AI Native Application Development - MERN

Overview

Welcome! This guide contains course-level information, instructions, and suggestions for instruction.

It is incredibly important to read through the information given within this guide, and the module-level guides provided within, to best facilitate learning in the classroom. These guides contain high-level breakdowns of lessons, assignments, and other material intended to give you the context necessary to deliver the content effectively. Additionally, suggestions for time allocation can be found within the module-level guides.

Course Syllabus

For a detailed breakdown of most course information, please refer to the course syllabus.

What Makes This Course AI-Native

This course (UCI 1018.3) delivers the same MERN fundamentals as UCI 1018.1, with one addition: every technical module is delivered as an AI-Native module that adds one graded AI lab. These labs progress learners through three roles:

1. AI as Socratic Tutor (Modules 2 through 7, and Module 9): The AI is forbidden from writing code. Learners configure it to ask guiding questions, and they do the work themselves. The learning objective is the underlying skill; the AI interaction teaches learners to extract understanding, not answers, from AI tools.
2. AI as Architect (planning-focused labs: Modules 8, 10, 12, and 13): The AI drafts plans, schemas, and architecture documents. Learners act as Product Managers: they write requirements, review the draft, request revisions, and approve. Learners do not let the AI write implementation code in this role.
3. AI as Builder (Module 11, and Modules 14 through 18): Learners direct Claude Code to write real code autonomously, then act as Engineering Managers: reviewing diffs, auditing for defects and security issues, testing, and approving commits.

AI-Native Modules and Lab Placement

Each technical module in this course has its own AI-Native module folder, named with an ai- prefix (for example, se/ai-302). These modules carry the same lessons and assessments as the standard module and add one graded AI lab.

Lessons in an AI-Native module are referenced from the standard module, not copied. A correction made to a standard lesson appears in the AI-Native module automatically, and a lesson added to a standard module appears in its AI-Native counterpart without a separate edit. Only the AI lab and a short module-outline note are unique to the AI-Native module.

Where an AI lab replaces a standard lab, the replaced lab is not present in the AI-Native module, so module timing does not grow and there is no ambiguity about which lab to assign. The standard module keeps that lab for every other version of the course.

AI Tooling Setup

During Module 1, ensure every learner has:

1. Logged into their Per Scholas-provided Claude Pro account at claude.ai.
2. Installed Claude Code (npm install -g @anthropic-ai/claude-code) and completed /login with the provided account. Node.js must be installed first; coordinate with the onboarding module.
3. Received their Anthropic API credits and stored their API key safely. Reinforce from day one: keys live in environment variables or .env files, never in committed code.

If a learner does not have access to a provided Pro account, every AI-Native lab includes a fallback note permitting free-tier Claude or an equivalent assistant. Expect free-tier learners to need more than one session for longer labs due to usage limits.

Verifying Understanding in an AI-Native Classroom

Because AI tools are present from Module 1, verification of individual understanding is even more important here than in UCI 1018.1:

• Use code reviews, informal technical discussions, and check-ins frequently from Module 1 onward.
• All major graded assignments should include some form of check-in that imparts confidence in the learner’s ability to explain what they have done, why, and how.
• The AI-Native labs generate review artifacts (dialogue transcripts, review logs, audit reports). Skim them; a transcript in which the AI wrote the learner’s code during a Socratic Tutor lab is an academic integrity conversation, not a grading footnote.
• Watch for learners who bypass the role constraints (for example, asking a second AI chat for the answer during a Socratic lab). The syllabus states explicitly that role boundaries are an academic integrity requirement.

General Facilitation Notes

• Use the professional development day during the week to prepare for teaching the four remaining days. The majority of the course is very interactive, containing many examples and synchronous activities. It is important to be familiar with the contents of these items in advance.
• Use Canvas announcements to publish an agenda for the upcoming day.
  • The agenda should include a time breakdown of the day, the content, activities, breaks, and a motivational quote or fun piece of information when appropriate.
  • Publish the agenda at the same time each evening before the next day’s lesson. Canvas supports delayed publishing, so you can create some or all announcements in advance.
• Review the lessons before administering them. Make sure that you know what the lesson contains, and are prepared to lead the activities within.
• Run the AI-Native labs yourself before assigning them. AI tools evolve; if a step no longer matches the current Claude or Claude Code interface, adapt live and report the discrepancy to the content team.

Workplace Simulation

Review the workplace simulation training materials provided below thoroughly to ensure you understand the expectations of you as the instructor.

Simulating a true workplace environment will aid learners in uncountable ways. To that end, we are always looking for feedback on how we can iterate upon and improve this framework!

Training Materials

• Onboarding Slideshow  for learners
• Workplace Simulation Guide  (instructor only)
• Weekly Check-In Template for Team Leads 

The AI-Native roles map naturally onto the workplace simulation: Socratic Tutor labs simulate pairing with a senior engineer, Architect labs simulate the Product Manager relationship, and Builder labs simulate managing a direct report. Leaning into this framing makes the labs feel like career preparation rather than tooling exercises.

In-Class Activities

Almost every lesson within the course contains an activity to reinforce learning. Leverage these activities in a variety of ways to make learning more dynamic and interesting. The activities are intentionally open-ended so that you as the instructor can determine if an activity should be solo, pair programming, group, instructor-led, code-along, etc.

Emphasize Self-Learning

Technology moves too quickly for us to keep up. It is important that learners understand that we are teaching them foundational skills that they can then carry with them to grow in industry. If learners expect everything they need to know to be contained within the lesson material in front of them, they will be set up for failure.

Every lesson contains opportunities for self-guided learning, some more obvious than others. Challenge learners to find the answers to their own questions whenever possible, and to validate those answers through practical application.

A curated list of additional resources is located at the end of most lessons as a starting point for this journey, but encourage learners to go farther. They will find many incorrect answers and bad practices, but learning how to separate and validate the good information is the cornerstone of a successful developer.

Technologies

Canvas

As your primary interface, it is important to know how to navigate Canvas quickly and efficiently. Familiarize yourself with the course’s layout on Canvas, and contact the delivery team and/or content developer with any concerns well before encountering them in class.

Claude and Claude Code

This course standardizes on Anthropic Claude for AI-Native activities. Familiarize yourself before the course begins:

• Create or receive your own account, and spend time in claude.ai conversations and Projects. The Socratic Tutor labs rely on Project custom instructions to hold the role; practice setting one up.
• Install Claude Code and complete at least one small feature end to end with it, including reviewing its proposed changes and using git diff before committing. You will be coaching learners through exactly this workflow in the Builder labs.
• Understand CLAUDE.md files (standing project instructions) and Plan Mode (Shift+Tab cycles modes; Plan Mode proposes without editing). Architect labs depend on Plan Mode; Builder labs depend on permission review.
• Review Anthropic’s documentation at https://platform.claude.com/docs  for the API labs, particularly authentication and the Messages API.

Sandpack and CodeSandbox

This course makes extensive use of CodeSandbox and its associated tool Sandpack for displaying live, interactive code examples alongside their results.

For this reason, it is important that you familiarize yourself with the platform and its controls before the course begins:

• Set up an account.
• Create or fork a few sandboxes.
• Play around with some applications.
• Experiment with the native Sandpack examples within lessons…
  • …and how these can interact with CodeSandbox and GitHub.
• Perhaps most importantly, get acquainted with the process of attaching a sandbox to a GitHub repository, and/or downloading it for local development.
  • Both of these techniques will be useful to provide alternative options for development for the learners.

This Thing

Yes, this platform which is currently hosting the content you are reading is fairly new (and built entirely with technologies you are likely familiar with)!

If you have questions, comments, concerns, suggestions, etc. regarding the content platform (not Canvas), please feel free to reach out to Matthew Eckart via Slack (or email, but Slack is better).

Additionally, if you would like the ability to directly report content issues or contribute to the content repository, reach out to request access to the GitHub repository.

Important Module Information

Each module has its own outline available as its index page, which is accessible to both learners and instructors. This outline contains a breakdown of the module that includes time allocations and high-level information for each item, and should be reviewed well ahead of introducing the module in class.

Some modules have special considerations as a part of this particular course, as follows:

Module 1: Google AI Professional

This module now opens the course, unlike UCI 1018.1/1018.2 where it appeared mid-course. Learners will lean on AI tools for the remainder of the course, so this module must also complete the AI tooling setup described above, and set expectations about the three AI roles and academic integrity.

The Google AI Professional badge coursework is introduced here; your delivery team will provide enrollment details.

Module 2: Version Control

It is expected that learners will continue to use their GitHub accounts to submit most assignments throughout the remainder of the course.

Ensure learners have set up a viable, professional GitHub (with an appropriate username and avatar), before exiting this module.

Module 3: HTML and CSS Review, with Accessibility and Module 5: JavaScript Review

Learners should have completed the tech prep work before entering the class, and therefore be sufficiently familiar with much of the content within this module.

Using the information gathered from the pre-exam as well as conversations with your learners, you can determine how much time should be spent on certain topics within this module. If the learners are well-learned, spend time on Accessibility and then move on. If they are struggling, spend a bit of extra time on the topics within the module.

Recommendations for where to “find” the time, if borrowed:

• Module 6: The Document Object Model
  • Learners will likely have a solid understanding of many topics within this module as a result of their tech prep work.
• Module 13: MongoDB Fundamentals
  • The MongoDB-without-Mongoose sections can be covered very quickly to get to the practical knowledge.
• Module 16: Unifying User Interfaces with Web Applications
  • These are concepts that the learners have been doing throughout the course without drawing specific attention to it; therefore, this can be covered rather quickly or assigned as additional asynchronous material in a worst-case scenario.

Module 7: TypeScript and Advanced JavaScript

Following the completion of this module, it is expected that learners complete most if not all of their code in TypeScript.

Due to the modular nature of our curriculum materials, the proceeding modules do not highlight this as an absolute requirement (in case they are included in courses that do not teach TypeScript).

It is your responsibility as the instructor to remind learners to continue with TypeScript throughout the course, and enforce this requirement.

Module 17: Deploying MERN Applications

This module contains a lot of information for the curious learner, but most of it is not necessary to complete this course. Ensure learners are focused on the finish line during this module, not consumed by the intricacies of web-app deployment.

Module Assessments and Project Weeks

It is beneficial to introduce the module-end assessments (SBAs) and section-end projects at the beginning of their respective module or section, to give learners an idea of what they are working toward.

Allow and encourage learners to iteratively work on these items throughout modules, even if the designated “SBA Day” or “Project Week” has not officially begun, provided they are keeping up with the more immediate material.

All SBAs and Projects should involve a code review and/or technical interview to prepare learners for discussing their work with industry experts, and to ensure academic integrity. In this course, that conversation should also cover how the learner used AI: what they delegated, what they reviewed, and what they would do differently.