Skip to content
Idaho AI Classroom
All lessons
AI FluencyApplication9-12.AIF.AP.2

Run It, Don't Worship It

9–1050 minutes90 minutes (extend hands-on and discussion)

Standard quoted exactly

Use AI tools to generate code for a simple coding project.

Clarification. Students run the code and evaluate the code's output but do not need to fully understand the code itself.

Student-friendly learning targets

  • I can use a district-approved AI tool (or teacher-provided generated code) to obtain a tiny program for a simple, defined job.
  • I can run that code in a browser, a Scratch-like environment, or a paper trace and record what it actually outputs.
  • I can evaluate output with test cases I choose, including at least one edge case, without claiming I fully understand every line.
  • I can describe one way the output was wrong, incomplete, or surprising, and I do not treat generated code as automatically correct.

Essential questions

  1. If I did not write the code, how can I still be responsible for what it does?
  2. What does a test case reveal that reading the code might miss?
  3. When is a tiny generated program good enough for a real Idaho job, and when must a human still check the result?
  4. What is the difference between running code and worshipping it?

Objectives

  1. Students will obtain code for one tiny project: a Fahrenheit–Celsius temperature converter, a wildfire-risk checklist, or a potato-grade counter.
  2. Students will run or trace the code with at least five inputs and complete an expected-versus-actual table.
  3. Students will mark pass/fail for each test, including one edge case (empty input, exact boundary, negative temperature, or humidity of zero).
  4. Students will write one evaluation sentence that judges the output, not the elegance of the code.
  5. Students will follow the offline path (printed generated code plus paper trace) whenever devices or approvals are unavailable, still meeting the standard.

Key vocabulary

Generative AI (Gen AI)
A subset of machine learning and AI specifically designed to create new content, including text, images, audio, code, video, or synthetic data based off a prompt.
Output
What the program prints, displays, or decides after it runs. In this lesson you judge the output, not whether you could have written the code yourself.
Trace
Stepping through code on paper: write the input, follow each line, and record the value of each result. Used when you cannot run the program on a computer.
Test case
A specific input chosen on purpose, with the output you expect written down before you run the code. Good test cases include normal values and edge cases.
Edge case
An input at a boundary or in an awkward situation: zero, a negative number, an empty list, or a value exactly on a cutoff. Edge cases often reveal mistakes.
Hallucination
Instances where an artificial intelligence system generates information that is incorrect, misleading, or entirely fabricated, but presents it as if it were true. Generated code can hallucinate a formula, a grade cutoff, or a library that does not exist.

Teacher background

Idaho standard 9-12.AIF.AP.2 asks students to use AI tools to generate code for a simple coding project. The clarification is exact and is the pedagogy: students run the code and evaluate the code's output but do not need to fully understand the code itself. This is not a computer-science unit on syntax. It is a fluency lesson on verification. Keep the project tiny so every student can finish five tests in one period. Three Idaho-flavored options cover different interests: a temperature converter (school weather stations, Stanley winter, seed packets in Celsius), a wildfire-risk checklist (humidity, wind, fuel dryness — familiar from fire season in the Boise Foothills, the Payette, and eastern Idaho), and a potato-grade counter (Magic Valley packing sheds counting how many tubers fall in a size band). Students may generate the code with a district-approved tool or receive teacher-provided generated code. They run it in a browser console, a Scratch-like environment, or on paper. Offline is first-class: print the generated JavaScript or pseudocode and a trace table. Never require students to install software or to understand every line. Never paste student names into the prompt. This lesson belongs in Semester 1, Weeks 10–14 ('Agents, code, and communication'); keep projects tiny and runnable, and name Idaho pathways in agriculture, energy, and public service when you talk about why output matters.

Materials and prep

Materials

  • District-approved AI tool for code generation, teacher account; student use only if approved.
  • Teacher-prepared generated code packets (offline and equity path) for all three tiny projects, each one page, with comments stripped of student names.
  • Run options: browser JavaScript console on a district page that does not require an account; a Scratch-like editor if already installed; or paper trace. Pick one default so you are not debugging three platforms.
  • Expected-versus-actual test table (five rows plus one edge-case row) with columns: input, expected output, actual output, pass/fail, note.
  • Known-answer keys for the teacher only: 32 F = 0 C; 212 F = 100 C; wildfire 'high' when humidity is below 20 and wind is above 15 and fuel is dry; potato Size A count for a published list of diameters.
  • Sample input lists: Boise and Stanley temperatures; a five-day humidity/wind table; a list of ten potato diameters in inches.
  • PII reminder card and the rule: prompts describe the task, never the student.
  • Projector for a live run of the temperature converter. Printed code on the document camera as backup.
  • Optional: four-function calculators for students who want to check the conversion formula by hand.

Before class

  • Generate the three tiny programs yourself before class on the approved tool. Save the exact code you will hand out. Run your own five tests and note at least one weakness (for example, no message when the list is empty).
  • Print code packets and test tables for every student. Assume a rural bandwidth day: the paper packet is the lesson.
  • Choose one run environment and post three steps to open it. If devices are one-to-few, run in pairs. If devices are none, everyone traces on paper.
  • Write the student prompt on the board so generation stays tiny: 'Write a short JavaScript function. Temperature: convert F to C and C to F. Wildfire: given humidity percent, wind mph, and fuel dry true/false, return low, moderate, or high using these cutoffs: high if humidity < 20 AND wind > 15 AND fuelDry is true; moderate if two of those three are true; otherwise low. Potato: given a list of diameters in inches, count how many are at least 1.875 and at most 3.25 (Size A band for this lesson). Print the result. Do not add extra features.'
  • Prepare a wrong-output warm-up: three wildfire outputs, one of which called a calm, humid day 'high.'
  • FERPA: no student names in prompts or in code comments. Do not have students email code to a public chatbot.
  • 90-minute block: keep this sequence. Add about 20 minutes so every student breaks the program on purpose with two more edge cases and writes a mini bug report, plus about 15 minutes of discussion comparing the three projects. Do not scale up into an app.

Instructional sequence

Which wildfire output is lying?

5 min
  1. Project three outputs from a 'wildfire risk' snippet for the same imaginary afternoon near Idaho City. Case 1: humidity 45%, wind 5 mph, fuel not dry, output HIGH. Case 2: humidity 12%, wind 25 mph, fuel dry, output HIGH. Case 3: humidity 12%, wind 25 mph, fuel dry, output LOW.
  2. Students mark on a mini whiteboard which case cannot be right, given the cutoff rule posted on the board.
  3. Reveal: Case 1 overstates risk; Case 3 understates it. Case 2 matches the rule. Name the day's claim: you do not have to understand every line to catch a bad output. You do have to run tests.
  4. Tell students they will generate or receive tiny code, run it, and judge it. They will not be graded on writing code from scratch.

The standard, the tiny project, and a live run

10 min
  1. Read the standard aloud exactly: 'Use AI tools to generate code for a simple coding project.' Read the clarification exactly: 'Students run the code and evaluate the code's output but do not need to fully understand the code itself.' Underline 'run' and 'evaluate' and 'do not need to fully understand.'
  2. Show the three project cards. Students will pick one: temperature converter (weather and greenhouses), wildfire-risk checklist (fire season), potato-grade counter (packing sheds). All three are small on purpose.
  3. Teacher model on the temperature converter. If the tool is up, paste the posted prompt from the teacher account and generate. If not, place the printed code on the document camera. Say: 'I am not going to explain every line. I am going to run it.'
  4. Run or trace three known answers: 32 F should be 0 C; 212 F should be 100 C; -10 F (a Stanley January morning) should be a negative C. Record expected versus actual in front of the class.
  5. If the generated code is wrong or refuses negatives, celebrate the catch. That is the standard. If it is right, still show the empty-input question: what does it do if I type nothing?
  6. Restate the integrity rule: you may use generated code for this assignment because you will test it. You may not turn in untested code, and you may not claim you wrote lines you did not write. Credit the tool on the test table header.

Trace one potato, as a class

10 min
  1. Place the potato-grade counter code on the projector (generated earlier). Read the Size A rule: diameter at least 1.875 inches and at most 3.25 inches for this lesson's simplified band.
  2. Give the class a list of five diameters, for example 1.5, 1.875, 2.4, 3.25, 4.0. Students predict the count on paper before anyone runs anything. (Expected: 1.875, 2.4, and 3.25 count; 1.5 and 4.0 do not. Count = 3.)
  3. Run the code or trace it line by line together. Fill expected versus actual. If the generated code used strict inequalities and dropped the boundary potatoes, that is a find, not a failure of the student.
  4. Name the evaluation sentence stem: 'The output is trustworthy for ___ and not trustworthy for ___ because ___.'
  5. Assign partners. Each pair picks one of the three projects. Pairs that cannot use a device receive the printed packet for their choice automatically.

Five tests and one edge case

12 min
  1. Each pair obtains code: generate with the posted prompt on an approved tool, or open the teacher packet. No extra features. No student names in comments.
  2. Write five test cases before running, including expected output. Temperature examples: 32 F, 212 F, 68 F, -10 F, and a Celsius-to-Fahrenheit check. Wildfire: mix high, moderate, and low days using the posted cutoffs. Potato: include a boundary diameter and a tuber that is too small.
  3. Run or paper-trace each test. Fill actual output and pass/fail. Calculators are allowed to check the conversion formula.
  4. Add a sixth row: an edge case (empty list, humidity 0, wind 15 on the cutoff, letters typed instead of a number). Record what happened, even if it was an error message.
  5. Write one evaluation sentence. Credit the tool or write 'teacher-provided generated code.'

Real-world examples

  • A packing shed in the Magic Valley uses a simple counter to tally potatoes in a size band; a human still pulls misshapen tubers the script cannot see.
  • A Bureau of Land Management or Forest Service fire-weather briefing uses cutoff rules for humidity and wind; generated dashboards still get checked against a belt weather kit on the ridge.
  • A school greenhouse in Teton County converts Celsius on a European seed packet to Fahrenheit before setting a heat mat; a wrong formula cooks the starts.
  • An irrigation manager near Twin Falls might run a tiny script on pump times; the farmer still walks the field because a dry corner does not show up in a bad formula.
  • A student weather station in Rexburg logs overnight lows well below zero; a converter that crashes on negatives is useless in January.

Hands-on activity

Break it on purpose, then judge it

8 min
  1. Each pair tries to make the program fail or look foolish: empty input, a temperature below absolute nonsense (for example 1000 F), wind of 15 exactly, a potato diameter of 1.875. Record the output.
  2. Trade tables with another pair who chose the same project. One difference in pass/fail becomes a 30-second conference: who tested the boundary?
  3. On the board, collect three 'do not worship it' findings from the room (crashes, off-by-one at a cutoff, wrong formula, silent empty list).
  4. Block extension (90 minutes): students write a six-line bug report (what I typed, what I expected, what I saw, how a human should check this in the field, whether I would let this run a greenhouse or a fire board overnight, what I still do not understand and do not need to). Optional: one volunteer pastes a failing test back into the approved tool and asks for a fix, then re-runs the same table to see whether the fix broke a test that used to pass.

Discussion questions

  1. The clarification says you do not need to fully understand the code. What do you still need to understand about the job the code is doing?
  2. Which test case would have been easy to skip and would have hidden a mistake?
  3. Would you let today's program set a frost fan, post a fire-danger sign, or pay a grower by the hundredweight? Why or why not?
  4. How is running generated code different from copying an essay the chatbot wrote?
  5. If two chatbots give two different programs, how do you choose? (Answer you want: you run tests, you do not pick the one that 'looks smarter.')
  6. What should a worker at a packing shed or a fire desk write down when they use a generated script, so the next shift can trust or distrust it?

Differentiation

Support

  • Pre-assign the temperature converter and provide the five expected answers on a hint card after the student has written predictions.
  • Paper trace only, with numbered arrows on the printout so the student can follow without a device.
  • Pair a reader with a recorder; both names go on the table; both must speak one test result.
  • Allow yes/no evaluation ('It got 32 F right and failed on empty input') instead of a long sentence.

Challenge

  • Add a second cutoff (for example US No. 1 quality is not just size) and show that today's counter cannot see bruises, so output can pass while the load should fail.
  • Write one new test case that would be required before this code could advise a real fire desk, and explain why a classroom cutoff is not a forecast.
  • Compare generated JavaScript and a Scratch-like version of the same job; evaluate which output is easier for a non-programmer to test.

Multilingual learners

  • Test tables may use home-language notes in the 'note' column; the numbers stay Arabic numerals.
  • Provide a diagram of F versus C and of potato size bands with labeled arrows.
  • Read the posted prompt aloud and leave it visible; generation quality drops when the student is fighting English and the task at once.

IEP / 504

  • Fewer tests (three plus one edge case) with the same expected-versus-actual structure.
  • Large-print code packet and a calculator. No requirement to type code.
  • Oral trace: student tells a paraeducator or teacher the next value; adult scribes the table.
  • Noise-reducing seat during device runs. Credit for paper trace equal to credit for a console run.

Assessment

Formative

  • Warm-up identification of the lying wildfire output.
  • Predicted potato count before the class run.
  • Circulation check: expected column filled before the actual column.

Summative

  • Completed test table with five tests, one edge case, pass/fail, tool credited, and one evaluation sentence about output.
  • Exit ticket: 'Name one output you would not trust in a greenhouse, a packing shed, or a fire briefing, and why.'

Success criteria

  • Code was generated or provided; the student did not have to author it from scratch.
  • The student ran or traced the code and recorded actual output, not guesses after the fact.
  • At least one test failed, one boundary was probed, or the student clearly stated that all tests passed and named a risk still untested.
  • The evaluation judges output. The student does not claim full understanding of every line, and is not penalized for lacking that understanding.

Responsible use, ethics, and privacy

Responsible use

Use a district-approved tool or teacher-provided generated code. Prompts describe a tiny task, not a student. Credit the tool on the table. Do not paste generated code into a live control system, a gradebook, or anyone's homework for another class. Do not download random scripts from the open web for this lesson. If the tool offers to 'explain every line,' students may read the explanation after tests, not instead of tests. Offline packets are full credit.

Ethics

Running untested code can waste a crop, mislead a fire desk, or simply spread a wrong number. The ethical move is to test with known answers and to say when you would not trust the output. Pretending you understand code you have not run is a different problem from using generated code honestly. Both are addressed here: you may use the generator; you may not skip evaluation; you may not take credit for writing what you did not write. A script that counts potato size still cannot see rot; over-trust is a harm.

Privacy

No student names, IDs, or class lists in prompts or in code comments. Do not use personal weather-station data that includes a home address. Use school or public sample numbers (Boise airport temperatures, a made-up list of diameters). Do not photograph classmates' screens for social media. FERPA: a file named with a student's last name plus 'code' is an education record; keep it in the district system or on paper in the classroom. Public chatbots are not a drop box for classwork.

Reflection

  1. Which test taught me the most, and would I have thought of it if I had only read the code?
  2. Where would this program be 'good enough' and where would it be dangerous?
  3. What did I not understand in the code, and why was that allowed today?
  4. How will I talk about generated code on a job site so a supervisor knows I tested it?

Homework

Add two more test cases to your table, including one that uses a number from real life (tonight's forecast high in your town, a seed-packet temperature, or a potato you measure with a ruler). Students without internet use the printed code and a paper trace. Do not install new apps. Optional: ask a family member in farming, trades, or wildland fire what number they still check by hand even when a screen already shows it, and write that sentence on the back of the table.

Closing

Read the clarification one more time. You ran the code. You evaluated output. You did not have to fully understand the code. Collect test tables. Three students name one failed or shaky test. End on the title: run it, do not worship it. Preview tomorrow's idea: if today's script only does one job, an agent is a recipe for a job that may use several tools — and a human still checks every step.

Extensions and cross-curricular links

Go further

  • Re-run the wildfire checklist against a printed National Weather Service fire-weather discussion for southern Idaho and mark where a three-rule script is too simple.
  • Visit (or video-call) an agriculture teacher or a local grower and ask how size grading actually works beyond one diameter band.
  • In CS club, rewrite the converter in a second language after the fluency lesson, still keeping the same test table.
  • 90-minute block gallery: three stations, one per project; students rotate to run one test on a project they did not choose.
Mathematics
Unit conversion, inequalities, and boundary values. Students write expected C from F before they trust a program.
Earth science / agriculture
Fire-weather factors and potato grading as real measurement jobs where a wrong output has a cost.
Computer science (optional)
This lesson is a doorway, not a syntax unit. Interested students may read the code after they have tested it, never as a gate to credit.
Career and technical education
Documenting tests is a workplace habit: operators initial a reading because the display can be wrong.