October workshops are openBuild a Search AI Agent$99 early bird

Enroll now
Skip to content

ENGINEERING & ENVIRONMENT · CAPSTONE PROJECT

Robotics-club parts planner

Plan a tabletop robot from a fictional catalog and independently verify its compatibility and cost.

Beginner-friendly path · 9 guided lessons · editable JavaScript · runs in your browser · no API key

START WITH A QUESTION

Can individually valid parts still form an invalid design?

Predict why checking each component's price alone cannot establish a compatible complete robot.

Reveal what to look for

The verifier checks the fictional compatibility matrix, required components, and total cost independently of the proposed parts list.

9 guided lessons · learn at your pace

YOUR FINISHED BUILD

Robotics-club parts planner

A bill of materials, compatibility evidence, cost, and a validated preview or explicit unsatisfied constraints.

WHY THIS FIELD USES THE IDEA

Engineering design works with interacting constraints; a bill of materials needs system-level checks as well as component details.

SEE THE IDEAChoose a step

See the idea before you code it

Read the input

A toy design goal, required components, explicit compatibility matrix, inventory, cost limit, call budget, and teacher approval.

function solve(input, tools) { /* your workflow */ }

Click a step to inspect this project's flow. The final workspace runs your JavaScript with original, authored records and checks.

A COMPLETE PATH TO YOUR BUILD

One small step at a time.

You can begin at the first lesson, resume shared skills you already practiced, or open the project IDE when you are ready.

01 · UNDERSTAND

Start with the essentials

No coding experience needed. These common lessons stay completed across every project.

  1. 1A model is one part of the systemFirst understand a model, a fixed workflow, and an agent that chooses its next tool call.
  2. 2Your first few lines of codeStart from zero: read values, objects, functions, and the result your code returns.
  3. 3Make a rule you can testWrite a small condition, change the input, and observe how the output changes.
  4. 4Turn an idea into a clear goalTurn the project's deliverable into a specific goal, allowed actions, and a visible stopping rule.

02 · PRACTICE

Learn the tools your project needs

Short explanations, clickable diagrams, and a small coding lab for each skill.

  1. 5A tool needs a clear contractInspect component records and the explicit compatibility-check contract.
  2. 6What should the agent remember?Reuse a verified part read within a limited call budget.
  3. 7Ask before changing somethingSeparate a reviewed bill of materials from a real purchase.
  4. 8A proposal must earn acceptanceAccept the proposed design only after independent constraint checks.

03 · BUILD

Make your project work

Follow the project-specific ideas, insert the explained snippets, and inspect your real execution trace.

  1. 9Robotics-club parts plannerBuild and test your own version: A bill of materials, compatibility evidence, cost, and a validated preview or explicit unsatisfied constraints.

04 · TEST & REFLECT

Try to break it. Explain what holds.

4 runnable cases check the final project. Passing them demonstrates these examples, with limitations still to explore.

Change one thing

Replace one part with a cheaper incompatible option and confirm that the proposed design fails verification.

Keep a useful learning record

Which physical properties would real engineering need that this fictional catalog cannot establish?

Inputs, checks, and project boundaries
Your starting material
A toy design goal, required components, explicit compatibility matrix, inventory, cost limit, call budget, and teacher approval.
What your agent must check
  • Cache/deduplicate reads and accept equality at the budget.
  • An omitted compatibility pair must block acceptance.
  • Coverage must use observed kinds, not a proposal's completeness claim.
  • Keep teacher review separate from technical checks.
Keep the scope clear
No physical actuation, hazardous wiring, fabrication control, real purchase, or assertion of real-world engineering safety.
Research behind this project path

Original explanations and authored practice records draw on these research and engineering ideas. The source organizations do not endorse this course or supply its fictional results.

Anthropic · Writing effective tools for agents — with agents

Design distinct tools with clear parameters, relevant returned information, and evaluations of how the agent actually uses them.

A description or schema does not guarantee the right action. A live tool can return different data for the same arguments as its environment changes.

Anthropic · Demystifying evals for AI agents

Define tasks, trials, and graders; inspect both execution records and final outcomes; repeat trials when model behavior varies.

A score depends on its cases and grading rules. Repeating a deterministic classroom case does not measure the variability of a live model.

Google DeepMind · AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms

Propose programs, execute and score candidates, then use evaluation feedback and a program database to guide later proposals.

This research-system description is not a classroom SDK. A bounded practice loop is an adaptation, not a reproduction of AlphaEvolve or its scientific results.

Your JavaScript really runs. The model decisions and school data are authored simulations, so you can learn without an API key. Every workspace also includes a separate real SDK example to explore next. Passing the lab’s cases is practice, not proof that an agent is ready for real-world use.