Ship Better Code, Faster

Appearance

Workshop 5: Slide Content ​

Deck title: AI-Assisted Development & Critical Evaluation Duration: 60 minutes · ~28 slides

Slide 1: Title [lavender title slide] ​

Title: Use AI well. / Then check its work. Eyebrow: Session 5 of 8 · AI-Assisted Development

Slide 2: Recap [white, headline + body] ​

Title: You've made the codebase faster. Now we let AI in. Subtitle: Where we are in the arc Body: Every working engineer today uses AI tools in their day-to-day work. The question isn't whether to use them, it's how to use them well. Today we generate code with AI, then review it as critically as we would a junior engineer's pull request.

Slide 3: Agenda [dark blue, agenda layout] ​

Title: Agenda Bullets (6):

  • 10 min: AI tools, good prompting, and the trap of cognitive offloading
  • 5 min: Live demonstration: good prompts versus bad prompts
  • 15 min: Refactor a god function in apps/api/src/routes/reports.ts, with a comprehension-preserving system prompt
  • 10 min: Generate tests for apps/api/src/services/auth.service.ts, then prove you understand them
  • 10 min: Code-review the AI output against a quality rubric
  • 10 min: Group discussion: where AI helped, where blind acceptance would have bitten you

Slide 4: Section divider [dark blue] ​

Big text: What "AI in / engineering" / actually means.

Slide 5: Three modes [white, 2-col] ​

Title: Three modes of working with AI Left subhead: Autocomplete Left body: Copilot, Cursor, your IDE. The AI suggests the next few lines as you type. Low-friction, high-volume. Great for boilerplate. Easy to over-trust because it feels harmless. Right subhead: Chat Right body: Claude, ChatGPT, Cursor's chat mode. You ask, it generates a chunk of code or explanation. Higher leverage per interaction, but the quality of the prompt matters a lot more. This is what we use today.

Slide 6: What good prompting looks like [white, title + body + bullets] ​

Title: What good prompting / actually looks like Body: The most common mistake is treating the AI like Google. The second most common mistake is treating it like a senior engineer who already knows your codebase. Treat it like a new contractor who can read everything you show it. Bullets (4):

  • Give context: paste the existing code, mention the conventions you follow.
  • Be specific: "rewrite this to use early returns" beats "make it better."
  • Ask for output you can validate: tests, types, before/after diffs.
  • When the answer is wrong, the prompt is usually wrong. Iterate the prompt, not the code.

Slide 6a: Section divider [dark blue] ​

Big text: The cost / nobody warns you about.

Slide 6b: What cognitive offloading is [white, headline + body] ​

Title: Cognitive offloading Subtitle: The thing to watch for Body: Offloading is when you hand the thinking to a tool and stop building the mental model yourself. A calculator does it for arithmetic, GPS does it for navigation, and that is mostly fine. With AI writing code it is different: it happens fast, it happens invisibly, and the output looks like you wrote it. You read code that works, you accept it, and you never form the understanding that writing it yourself would have forced.

Slide 6c: Why it matters for engineers [white, title + body + bullets] ​

Title: Why this is a real problem, / not a vibe Body: Typing was never the bottleneck in software. Understanding is. When you offload the understanding, the bill comes due later. Bullets (4):

  • You cannot debug, review, or extend code you never understood. The first incident finds the gap.
  • Over-trust ships subtle bugs: the code reads as correct, so nobody looks hard.
  • Skill atrophies. The reps you skip today are the judgment you lack next year.
  • On a team, the gaps compound. Nobody owns the parts the AI wrote and nobody read.

Slide 6d: The tell [dark, headline + body] ​

Title: One question tells you / if you offloaded Subtitle: Ask it every time Body: Could you re-derive this, or explain it to a teammate, without the AI in front of you? If yes, you offloaded the typing, which is fine. If no, you offloaded the comprehension, which is the trap. The output being correct does not save you: correct code you do not understand is a liability you have not noticed yet.

Slide 6e: Mitigation: the system prompt [white, title + body + bullets] ​

Title: Build comprehension into / the system prompt Body: The system prompt is the highest-leverage place to fight offloading, because it shapes every answer in the session. Instead of asking the AI to just emit code, instruct it to keep you in the loop. You will write your own version of this in the activity. Bullets (5):

  • Explain its reasoning, not just the result.
  • Surface its assumptions and the tradeoffs it accepted.
  • Offer at least one alternative and say why it picked this one.
  • Ask YOU clarifying questions instead of guessing.
  • Quiz you on the output so you have to articulate why it works.

Slide 6f: Mitigation: workflow habits [white, title + body + bullets] ​

Title: Habits that keep / the understanding yours Body: The system prompt sets the AI's behavior. These habits set yours. Bullets (5):

  • Read and understand before you accept. No exceptions for code that "looks right."
  • Rewrite the AI's explanation in your own words. If you cannot, you do not understand it yet.
  • Review AI code like a junior engineer's PR: assume nothing, check everything.
  • Write or understand the test first, so you can judge the code against intent.
  • Modify the output without AI to prove it is yours. If you cannot change it, you do not own it.

Slide 6g: The active-comprehension loop [dark, title + body + bullets] ​

Title: After the AI answers, / run the loop. Body: Three questions, every time the AI produces something you intend to keep. This is the loop you will practise in today's activity. Bullets (3):

  • Why does this work? Say it out loud or write it down.
  • What breaks if an assumption changes (an input is empty, a client times out, the schema shifts)?
  • What tradeoff did we accept by doing it this way instead of the alternative?

Slide 7: Live demo [dark, headline + body] ​

Title: Watch what bad prompting produces Subtitle: Live demo, 5 minutes Body: Compare two prompts side by side on the same task. First: "make this function better." Second: a careful prompt with the file, the conventions, the test we want to pass, and a request for a unified diff. The two responses are visibly different in quality. The point: prompts are first-class code.

Slide 8: Section divider [dark blue] ​

Big text: Refactor / a real function.

Slide 9: Meet the god function [white, headline + body] ​

Title: Open apps/api/src/routes/reports.tsSubtitle: This is the target Body: A ~130-line function that builds a CSV report. It queries tasks, hydrates assignees, computes completion rates, applies a timezone, buckets results, and sends a notification on the way out. It does about ten things. We're going to ask AI to split it apart, and then verify the AI didn't break anything.

Slide 10: Workshop: refactor [white, headline + body] ​

Title: Workshop, 15 minutes Subtitle: Refactor reports.ts with AI help Body: We do this together, following along in your own clone. First, set your comprehension-preserving system prompt from workshops/05-ai/starter/active-comprehension-prompt.md. Then use the prompt template in workshops/05-ai/starter/refactor-prompt.md. Paste the contents of reports.ts. Ask for a refactor that splits the function into smaller pieces with the same behavior. Apply the AI's suggestion. Run the existing tests to confirm nothing broke. If anything fails, you have two pieces of work: fix the regression, and update the prompt so future attempts don't repeat the mistake. Before we move on, prove comprehension: name each helper the AI extracted and what it does, without re-reading the code. Record your results in your logbook as we go.

Slide 11: Section divider [dark blue] ​

Big text: Generate tests / for code that has none.

Slide 12: The untested service [white, headline + body] ​

Title: Open apps/api/src/services/auth.service.tsSubtitle: Zero tests Body: This file hashes passwords, signs JWTs, validates tokens. It is absolutely worth testing. It has no tests. Today you write them, with AI help. The same prompt template applies: give it the file, give it your testing conventions, ask for tests that cover both the happy path and the error cases.

Slide 13: Workshop: generate tests [white, headline + body] ​

Title: Workshop, 10 minutes Subtitle: Write tests for auth.service.ts with AI Body: We do this together, system prompt still on. Use the prompt at workshops/05-ai/starter/test-gen-prompt.md. Generate tests. Run them. They probably won't all pass on the first try: AI gets imports wrong, invents APIs, makes plausible-looking type assertions that aren't true. Fix what's broken. Record what failed and why in your logbook as we go. Comprehension check: for one test, change the assertion to something you know is wrong and predict the failure before you run it. If the actual failure surprises you, you didn't understand the test.

Slide 14: Section divider [dark blue] ​

Big text: Now grade / its work.

Slide 15: The rubric [white, title + body + bullets] ​

Title: Grade the AI output / against four axes. Body: The full rubric is in workshops/05-ai/starter/evaluation-rubric.md. The short version is four questions you ask of every AI-generated piece of code. Bullets (4):

  • Correctness: does it pass the existing tests? Does the behavior match the spec?
  • Maintainability: would a teammate be able to read and modify this six months from now?
  • Coverage: does the AI handle edge cases, or only the happy path?
  • Idiom: does it match the conventions of the surrounding code?

Slide 16: Workshop: code review [white, headline + body] ​

Title: Workshop, 10 minutes Subtitle: Review your AI output Body: Together, for each piece of AI output we applied (refactor + tests), we grade it on all four rubric axes. Capture specific examples: "the AI didn't handle the empty-tasks case" beats "coverage was okay." Record your grades and justifications in your logbook as we go.

Slide 17: Failure modes [dark, title + body + bullets] ​

Title: What AI tends / to get wrong. Body: A pattern of failures you'll see across many tools. Bullets (4):

  • Confident hallucinations of APIs that don't exist (imported from packages you don't have).
  • Edge cases silently ignored: empty arrays, nulls, error returns.
  • "Plausibly typed" but actually wrong TypeScript: types compile but lie.
  • Code that solves a slightly different problem than the one you asked about.

Slide 18: Section divider [dark blue] ​

Big text: Group / discussion.

Slide 19: Discussion [white, headline + body] ​

Title: Where did AI help, and where would blind acceptance have bitten you? Subtitle: Workshop, 10 minutes Body: Around the room: each person shares one place where AI saved them real time, and one place where accepting the output without understanding it would have shipped a bug or left a gap. Name a moment from the comprehension checks where you thought you understood the code and didn't. Record these in your logbook as we go: they are the inputs to the engineering policy we write in Session 7. The successes and the near-misses you call out today determine the rules we set for the team.

Slide 20: The career angle [dark, headline + body] ​

Title: Engineers who use AI well are pulling ahead Subtitle: What this means for you Body: Hiring managers across the industry are watching for engineers who can direct AI without being directed by it. The skill is judgment: what to ask for, what to accept, what to throw away, when to write it yourself. Judgment is built on understanding, which is exactly what offloading erodes. The engineers pulling ahead use AI to go faster and keep the mental model. That is what you're practicing today. It compounds.

Slide 21: Session 6 preview [white, title + body + bullets] ​

Title: Session 6: Experimentation and measuring impact Body: You have a measurably faster pipeline, a better developer experience, and some AI-assisted improvements. Next session, you prove all of it with metrics. Bullets (3):

  • Revisit your Session 1 baselines and compare against today.
  • Learn the DORA metrics every engineering leader cares about.
  • Design a rollout plan for introducing your changes to a broader team.

Slide 22: Questions [dark blue, Big Stat layout] ​

Big text: Questions?