Teaching "AI in Your Pocket" to Architect mode (ages 15–18)

Hook & Warm-Up

Skip the mascot framing entirely — Architect mode treats students as near-adults evaluating real systems. Open with the lesson's hook line as a direct statement: "Your phone runs dozens of AI models — for face detection, voice recognition, and recommendations. Let's examine the AI stack inside everyday apps."

Frame it as a systems-design exercise rather than a discovery activity: "Every one of these apps represents a real engineering decision — where to run the model, how to compress it to fit on a phone, and what to optimize the system for. Some of those decisions serve you directly. Some of them serve the company's business model first, and you second. Today we're going to pull apart a handful of examples and be specific about which is which."

Optional framing for a portfolio-track class: "If you're considering a career in software, product, or ML, this is the level of detail you'd need to actually discuss in an interview or a design review — not just 'it uses AI,' but which technique, running where, optimized for what."

Set expectations for rigor: "I'm going to hold you to a higher bar than 'it uses AI' today. For every example, you should be able to say roughly what kind of model is involved, where it plausibly runs, and what tradeoff that choice represents. If you're not sure, say so and we'll reason through it together — guessing with confidence isn't the goal, reasoning from what we know about the constraints is."

Main Activity

Treat this as a technical walkthrough with an explicit engineering lens: for each system, name the technique, where it runs, and what tradeoff it represents.

1. On-device biometrics and personalization.

• Face ID — a neural network processes a depth map from ~30,000 projected infrared points and outputs a mathematical representation compared against an enrolled template, entirely on-device. This is a deliberate architecture choice: biometric data never needs to leave the phone, and there's no network latency in the authentication path.
• Smart Keyboard — a small, personalized language model runs locally, adapting predictions to an individual's vocabulary and usage patterns without sending keystrokes to a server.
• Battery AI — a model learns charge-cycle patterns and defers the final charge percentage overnight, trading a small convenience cost for reduced long-term battery degradation.
• Ruler App — not AI. Deterministic arithmetic (pixel count × known screen density); no model, no training, no inference step of any kind.

Discuss model optimization directly: running a capable model on constrained mobile hardware (limited memory, battery, and compute versus a data center GPU) requires shrinking it. Two standard techniques: quantization — reducing numerical precision (commonly FP32 → INT8) to cut model size and speed up inference, at a small, usually acceptable accuracy cost — and distillation — training a smaller "student" model to mimic a larger "teacher" model's outputs. This is why a phone can run real-time face detection without the phone getting hot or draining the battery in minutes.

2. Recommendation systems and platform economics.

• TikTok — a large-scale recommendation system combining collaborative filtering, content signals, and engagement prediction; it converges on personalized recommendations within roughly 40 minutes of use, which is a strikingly short cold-start period compared to older recommender systems.
• Netflix — an estimated 80% of watch time is attributed to recommendations. This is not incidental — recommendation quality is a direct driver of subscriber retention, which makes it a core, heavily-invested-in part of the product, not a side feature. Worth noting for a class discussing careers: recommendation engineering is one of the largest, best-funded areas of applied ML precisely because of this direct revenue link.
• FM Radio — not AI; a broadcast medium with no feedback loop or personalization mechanism at all.
• Spotify Discover Weekly — mines patterns across an estimated 4 billion playlists to surface tracks statistically adjacent to a listener's taste profile.

Introduce two-tower architectures as the standard pattern behind large-scale recommendation systems: a "user tower" encodes user features (history, behavior) and an "item tower" encodes item features (video, song, product) independently into the same vector space, so that retrieval of relevant items for a user becomes a fast nearest-neighbor search rather than scoring every item against every user directly — essential at platform scale.

Name the attention economy tension explicitly: systems like these are optimized for engagement (time on platform, watch-through rate), and that objective can conflict with a user's own wellbeing — it is not automatically aligned with what's good for the person using it, even when no individual recommendation is deceptive or wrong.

3. Shopping, maps, and computational imaging.

• Shopping recommendations — a substantial share of e-commerce purchases are attributed to AI-driven "customers also bought" recommendations, another example of a system whose business value is proportional to its personalization accuracy.
• Google Maps — ETA prediction fuses live traffic, historical time-series patterns for that route, and event data (concerts, closures) — a forecasting problem, not a simple current-speed calculation.
• Paper List — not AI, no data pipeline of any kind.
• Visual Search — an object-recognition/computer-vision model matches a camera frame against a product embedding database.

Note the retrieval pattern here mirrors the two-tower idea from recommendation systems: an image is encoded into a vector representation, and matching is a nearest-neighbor search against a database of product vectors, rather than comparing the raw image pixel-by-pixel against every catalog photo. The same underlying technique — encode into a shared vector space, then search that space efficiently — shows up across recommendation, visual search, and even the keyboard's word prediction. It's one of the more transferable ideas in this whole lesson.

Close with the Neural ISP (Image Signal Processor): modern phone cameras increasingly replace stages of the traditional, hand-engineered image processing pipeline with learned models for denoising, HDR, and detail enhancement — meaning the "photo" a phone produces is substantially a model's output, not a direct sensor reading.

Close the walkthrough with a synthesis prompt that ties the three sections together: "Notice the pattern across all of this — the constraint is never 'can we build a smart-enough model.' The constraint is almost always: memory, battery, latency, or business incentive. Quantization and distillation exist because of hardware limits. Two-tower architectures exist because of scale. The attention-economy tension exists because of what the business is optimizing for. Good systems thinking means always asking what constraint produced this particular design."

Discussion

Run this as a Socratic discussion rather than hands-raised Q&A where possible — these questions don't have single correct answers, and this age band tends to engage more when the format signals that a real position is being asked for, not a fact to recall.

• "Quantization trades some model accuracy for size and speed. Who decides where that tradeoff line is drawn, and what happens if it's drawn wrong — say, for a biometric security system versus a photo filter?" — Push for the asymmetry: a slightly blurrier photo filter is a minor cost; a slightly less accurate face-unlock model has real security implications, so the acceptable accuracy loss is not a fixed number, it depends entirely on what's at stake.
• "Two-tower architectures let a platform search millions of items efficiently. What does the existence of this kind of infrastructure suggest about the scale a company like TikTok or Spotify is actually operating at?" — Guide toward: the engineering investment itself is evidence of scale — you don't build specialized retrieval infrastructure for a small catalog; you build it when brute-force comparison becomes computationally impossible.
• "If Netflix's business model depends on maximizing watch time, and your wellbeing sometimes depends on watching less, is that a solvable engineering problem, or a structural conflict of interest? What would 'solving' it even look like?" — There's a real range of positions here. One is that better metrics (measuring satisfaction, not just time) could realign incentives; another is that as long as revenue is tied to attention, the conflict is structural regardless of measurement.
• "On-device AI is often framed as the privacy-friendly option. Is that framing complete, or does it leave out anything about what data still leaves the device for other reasons?" — Push students to distinguish the specific claim (biometric data for Face ID stays local) from the general one (the phone as a whole doesn't send data anywhere) — the second is false; plenty of other apps and services on the same phone still transmit data.
• "If you were designing a recommendation system from scratch, what would you optimize for besides engagement, and how would you measure whether you'd succeeded?" — Encourage concrete alternatives: self-reported satisfaction surveys, "did you regret this session" checkpoints, or capping how much a single session can escalate — and push on how each one would actually be measured, not just stated as a goal.

Quiz Walkthrough

Wrap-Up & Extension

Close with: "Nothing in your pocket is neutral. Every one of these systems reflects a design decision someone made about what to optimize for — speed, privacy, engagement, or accuracy — and those decisions have consequences for how you spend your time and what you see. Understanding the mechanism is what lets you evaluate it instead of just experiencing it."

Extension activity (25–30 minutes, suitable for a portfolio artifact): Have students pick one app they use daily and write a short technical teardown (half a page to a page): what AI technique it likely uses (recommendation system, computer vision, on-device personalization), where the model likely runs (device vs. cloud, and why), and one design tradeoff the company made that primarily benefits the company rather than the user. Students on a career-path track can extend this into a one-page "product critique" suitable for a portfolio, evaluating the system the way a UX researcher or ML engineer might.

Extended option for a full class period: have students work in pairs to sketch a rough system diagram for their chosen app — boxes for "on-device model," "server-side model," "user data collected," and "output shown to user," with arrows showing what data flows where. This doesn't need to be technically perfect; the value is in forcing an explicit decision about which parts plausibly run locally versus in the cloud, and defending that decision with the tradeoffs discussed in this lesson (latency, privacy, scale). Have a few pairs present their diagram and let classmates challenge any box they think is misplaced.

Timing note: the full technical walkthrough runs about 18–20 minutes at this depth, discussion 10–12 minutes given the more open-ended questions, and the quiz 5–6 minutes — putting the core lesson at roughly 35 minutes, with the diagramming extension filling a full period comfortably.

Leave students with a genuinely unresolved question rather than a tidy takeaway, since that's closer to the actual state of the field: the tools for building highly effective, highly personalized systems are well understood and widely deployed. What to optimize them for — pure engagement, measured wellbeing, some blend of both — is not a solved problem, technically or ethically, and it's one this generation of engineers and product designers will be the ones deciding.