What AERO-Ready Coding Looks Like in My Classes

First week of October, my Grade 6 coding class built a maze solver in Scratch. They were thrilled; I was less so. The task hit loops and conditionals, but when I held it against AERO-style performance expectations, we were thin on reflection and precision. AERO schools often thread coding through technology, math, and science practices—plan, test, refine, communicate reasoning—so a resource can be on-topic (variables! sprites!) yet miss the pathway’s emphasis on observable performance and vocabulary used in context.

What usually goes wrong: materials dump skills without grade-band language, assessments rely on right/wrong output instead of explaining and justifying algorithmic choices, and the word “debug” shows up as a step, not as a habit with evidence. I’ve learned to prefer tasks that demand a short design brief, explicit success criteria, and a final explanation in student voice. When I need fresh American · AERO coding resources to riff on, I’ll browse community-contributed tasks and keep a shortlist in the coding library so I’m not reinventing every unit. AERO fit isn’t a vibe; it’s visible in the products students make and the words they use to justify decisions—every single lesson.

Last Thursday my Grade 7s kept saying “the computer thinks” when they meant a Boolean condition. That’s my cue that the resource I gave them talked around core terms. For AERO alignment, I run three fast checks before I teach: vocabulary, task demands, and evidence style. Vocabulary means students meet words they’ll actually need—algorithm, condition, Boolean, trace, iterate—and they use them in context, not just matching definitions. Task demands should rise from define to apply to reflect within the same lesson, even if briefly.

Evidence style is the real discriminator. I want a product that shows reasoning (pseudocode or a flowchart), a working program, and a short reflection that names what changed through testing. If a worksheet ends with five multiple-choice questions on loops, it’s probably not doing the AERO job. When I’m unsure, I’ll spin up a quick draft and stress-test the objectives by generating two or three variations in a planning sandbox. If I can swap contexts (game, data, robotics) without changing the verbs in my success criteria, I know the rigor is about thinking, not a single tool.

On March 6th with Grade 7, I ran our “Traffic Light Timer” worked example. Students coded a simple controller that cycles red→green→yellow with adjustable timing. The objective used AERO-style verbs: “Students will plan, implement, test, and explain a timed decision structure using precise vocabulary.” I drafted the spine in ClassPods, then tuned it for our lab setup. Here’s the skeleton I actually used:

• Objective (2 min): Share success criteria: algorithm plan, working program, reflection using terms (condition, variable, iterate).
• Starter (6 min): Unplugged: students order jumbled pseudocode cards for the light cycle; quick pair talk to justify choices.
• Main task (30 min): Build the controller (block or Python). Add a variable for green time; test with at least three values. Midway pause to peer-trace a partner’s code.
• Formative check (10 min): Exit slip: identify the Boolean condition and describe one bug fixed; attach screenshot of test table.
• Plenary (7 min): Gallery walk; students explain how their algorithm prevents unsafe states.

If you want a ready-to-edit version with the same timings and prompts, you can generate the plan and tweak the success criteria to your grade band by starting a new lesson pack. The pieces stay the same; the complexity flexes.

Two weeks before spring break, my Grade 5s built a “Click Counter” app and I needed grades that meant something beyond “it works.” This is the rubric I now staple to every coding product. It matches the way AERO favors observable performance with clear descriptors students can self-assess against.

Criteria (score 1–4 each)

• Algorithm Plan: 1 = Missing/unclear steps; 2 = Steps listed but out of order or vague; 3 = Ordered pseudocode with conditions and loops labeled; 4 = Plan includes test cases and data ranges.
• Implementation: 1 = Code incomplete; 2 = Works for one case; 3 = Works for common cases with named variables; 4 = Generalized solution with input handling.
• Testing & Debugging: 1 = No evidence; 2 = One fix described; 3 = Test table with at least three cases; 4 = Systematic tests plus explanation of a non-obvious bug.
• Vocabulary & Explanation: 1 = Everyday language; 2 = Some terms misused; 3 = Correct use of key terms; 4 = Precise terms woven into reasoning.

Student reflection prompts: “Which condition controlled your main decision?”, “What changed after testing?”, “How would you adapt this for a different input?” If you’re costing out department tools to host and reuse versions of this rubric, you can check the current options on the pricing page.

In late January my Grade 8 bilingual (Arabic–English) section stalled on the phrase “evaluate a condition.” The code was fine; the language wasn’t. I now pre-teach five anchor terms with visuals and dual-language cards, and I build sentence frames into tasks: “My algorithm repeats until…” or “The Boolean is true when…”. During pair programming, I assign roles—navigator explains in English, driver can annotate in L1—then swap. Comments and docstrings can be bilingual; final reflections use assessed English terms.

Pacing-wise, I frontload planning time and cap free-build minutes so reflection doesn’t get squeezed. For homework, I set short code-tracing problems, a pseudocode-to-code translation, or a “debug diary” screenshot with two sentences on the fix. When I need a differentiated take-home set (two reading levels, same concept), I’ll generate parallel versions in ClassPods and keep the success criteria identical across both so grades stay comparable. If you want to try that workflow, you can make a quick duplicate and edit the prompts by starting a lesson pack and choosing the coding category.