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

Enroll now
Skip to content

COMPUTER SCIENCE & DATA · STARTER PROJECT

Coding-club issue sorter

Route bug reports from a fictional club website to a candidate file and test, using evidence from allowed reads.

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

START WITH A QUESTION

Can an agent find a useful test without pretending it fixed the bug?

Predict what evidence connects an issue description to a file and an existing test name.

Reveal what to look for

The agent reads only a tiny allowed repository and returns a candidate location with evidence. A candidate is not a proven repair.

9 guided lessons · learn at your pace

YOUR FINISHED BUILD

Coding-club issue sorter

An issue ID, candidate file, existing test name, evidence lines, and a flag for missing information. Do not claim the bug is fixed.

WHY THIS FIELD USES THE IDEA

Software triage connects a reported failure with inspectable code and tests before anyone proposes a patch.

SEE THE IDEAChoose a step

See the idea before you code it

Read the input

Sanitized issues, a tiny repository manifest, permitted file paths, test names, and a four-call budget.

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 contractDefine allowed repository reads and prevent arbitrary file access.
  2. 6Decide → act → observeInspect a tool observation before deciding the next read.
  3. 7What should the agent remember?Remember inspected paths without repeatedly spending the call budget.
  4. 8Return something another program can useReturn an issue, evidence, and existing test as a checkable object.

03 · BUILD

Make your project work

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

  1. 9Coding-club issue sorterBuild and test your own version: An issue ID, candidate file, existing test name, evidence lines, and a flag for missing information. Do not claim the bug is fixed.

04 · TEST & REFLECT

Try to break it. Explain what holds.

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

Change one thing

Use an ambiguous report and verify that the result admits missing information within its call budget.

Keep a useful learning record

What additional failing test would turn your location hypothesis into a reproducible bug?

Inputs, checks, and project boundaries
Your starting material
Sanitized issues, a tiny repository manifest, permitted file paths, test names, and a four-call budget.
What your agent must check
  • Use all four reads/checks without claiming a fix.
  • Request information instead of selecting an arbitrary candidate.
  • Retain observed evidence without inventing an unobserved test.
Keep the scope clear
Fixture-backed reads only: no shell, secrets, network, private repositories, or writes. Issue text cannot grant new permissions.
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.

Jimenez et al. · SWE-bench research team · SWE-bench: Can Language Models Resolve Real-World GitHub Issues?

Evaluate patches against repository issues and executable tests using a reproducible harness. Inspect the actual code change and its tested behavior.

Benchmark variants cover different tasks. Passing a repair case does not establish general coding ability or that a patch meets every unstated requirement.

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.