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

Enroll now
Skip to content

COMPUTER SCIENCE & DATA · CAPSTONE PROJECT

Small patch, visible proof

Propose a small fix to a fictional club website, test it in isolation, and prepare a patch for review.

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

START WITH A QUESTION

Can a fix pass the example and still be wrong?

Predict a boundary input that a plausible patch might miss before you run the separate checks.

Reveal what to look for

A patch earns acceptance by changing allowed code and passing the authored tests; the resulting receipt only covers those tests.

Start from the basicsExplore the path

9 guided lessons · learn at your pace

YOUR FINISHED BUILD

Small patch, visible proof

A patch preview, before-and-after test results, changed paths, and unresolved limitations.

WHY THIS FIELD USES THE IDEA

Software engineering combines narrow edits, independent execution, and a reviewable diff instead of relying on a confident explanation.

SEE THE IDEAChoose a step

See the idea before you code it

Read the input

A tiny source tree, an issue, allowed edit paths, public and withheld fixture tests, execution limits, and reviewer 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 contractSeparate reading code, proposing a patch, and executing tests.
  2. 6Ask before changing somethingConstrain accepted edits to the allowed project files.
  3. 7Test behavior, not confidenceUse counterexamples to distinguish a useful fix from an example-only patch.
  4. 8A proposal must earn acceptanceTreat a generated patch as a candidate awaiting independent checks.

03 · BUILD

Make your project work

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

  1. 9Small patch, visible proofBuild and test your own version: A patch preview, before-and-after test results, changed paths, and unresolved limitations.

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

Compare a patch that handles one example with one that also handles the fixture's boundary inputs.

Keep a useful learning record

Which behavior remains untested even when every displayed case passes?

Open project IDEReflect & save your notes
Inputs, checks, and project boundaries
Your starting material
A tiny source tree, an issue, allowed edit paths, public and withheld fixture tests, execution limits, and reviewer approval.
What your agent must check
  • Show the original failure and verified improvement before saving a preview.
  • Reject a constant answer despite its approval fixture.
  • Keep test acceptance separate from action permission.
  • Reject an out-of-scope edit before executing the proposal.
Keep the scope clear
Execution stays in the lab's isolated runtime. No push, deployment, package install, or credentials. Passing the fixture tests does not prove general correctness.
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.

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.

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.

OpenAI · Guardrails and human review

Distinguish automatic checks from approval decisions, pause sensitive tool requests, retain state, and resume after an application approves or rejects them.

Model-generated approval text is not authorization. Resume examples that automatically approve a request do not establish that a person reviewed it.

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.