AI Policy

See also: GradingGrading
See also: Syllabus · Lectures

Tech 1 Grading Plan

Assessment and Grading Breakdown




#
Component
Weightage (%)




1
Attendance and Class... · SyllabusSyllabus
See also: Lectures · Grading · AI Policy

Course Title: Tech 1 — Web & Mobile Ecosystem Fundamentals

Course Objective: Gain a foundational understanding of the core technologies, p...

In most courses, an AI policy is a list of things you can't do. This course is different: using AI to generate code is the expected way of working here. The skill this course teaches is directing AI tools well — which means the policy is less about restriction and more about honesty.

The short version

Use AI for everything. Understand everything you ship. Show your process. Never present work you can't explain.

What is encouraged

  • Generating code with AI — Claude, Cursor, v0, Lovable, Figma Make, Copilot, whatever works. Switching tools mid-project is fine; tool fluency is part of the point.
  • Using AI to learn — asking it to explain code it (or someone else) wrote, decode error messages, compare approaches, or quiz you before a presentation.
  • Using AI as a research assistant — for exercises like Exercise - Mobile Ecosystem ComparisonExercise - Mobile Ecosystem Comparison
    iOS vs Android, from a product team's chair

    Compare and contrast the iOS and Android ecosystems for app development and distribution, highlighting the differences that would actually change a prod...    , with the caveat below about verification.
  • Iterating in plain language — a well-written prompt log is a design artifact. Keep yours.

What is required

  1. Understanding. If you shipped it, you can explain it — at the level this course teaches. "Where does this data live?", "What happens when I click this?", "Why is this an API call?" are fair questions about your own project, in any crit or exam, and "the AI did it" is not an answer.
  2. Process documentation. Every submission includes your prompt log or equivalent history: key prompts, major iterations, dead ends. This is how I grade process — and it's also what protects you if originality is ever questioned.
  3. Verification. AI states things confidently and is sometimes wrong. Any number, fee, policy, or fact that an AI gives you gets checked against a primary source before it goes in your work. Stale App Store fees in a submission tell me you didn't check.
  4. Attribution. Cite datasets, templates, fonts, images, substantial code you took from other humans, and the work of classmates. AI-generated code doesn't need a citation — but the inputs you gave it (someone else's design, someone's copyrighted assets) keep their original owners.

What is dishonest

  • Presenting work you can't explain at the level this course teaches.
  • Hiding or fabricating your process — a prompt log written after the fact to look tidy is fiction, not documentation.
  • Submitting another student's project, prompts, or documentation with cosmetic changes.
  • Having AI (or anyone) impersonate you in things that must be your own voice — peer feedback, reflections, exam answers where stated.

Practical safety rules

These aren't academic-integrity rules; they're don't-get-burned rules, and they're graded as craft:

  • Never put API keys or secrets in front-end code or a public repo. Ask the AI "are any secrets exposed to the client?" — then verify yourself.
  • Don't paste personal data (yours or anyone else's) into AI tools or deploy it to public projects. Class-collected data stays anonymised.
  • You are responsible for what your product does. If your AI-built guestbook lets strangers post anything to a public page, that was a design decision you made by not making it.

A note on why

You will spend your career working with tools like these. Employers will not ask whether you used AI; they will ask whether the thing works, whether it's well-designed, and whether you understand it. This policy is practice for that reality.

Violations of academic integrity are handled according to institutional policies.