How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Human-in-the-loop — Ai Mastery

Day 19 · ~12 min●

Some actions shouldn't fire automatically. Sending money. Posting publicly. Modifying customer data. The pattern: agent prepares → human approves → agent acts.

Three steps:

Agent describes what it wants to do
A request goes to a human (we'll send an email to yourself — a Slack-like notification using whatever channel you have)
Code reads an approval signal; only acts if approved

python

# 1. Prepare
action = {"type": "send_email", "to": "customer@x", "body": "..."}

# 2. Notify (email to self — production: Slack message, dashboard alert, SMS)
toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": user_email,
    "subject": "[APPROVAL NEEDED] Send to customer",
    "body": f"Action proposed: {action}\n\nReply 'approve' to proceed.",
})

# 3. Read signal & act
if approved:
    perform(action)
else:
    log_skip(action)

And the script just sits there waiting for me to approve?

In a real system — yes, with a polling loop or a webhook. In the sandbox we simulate the approval signal with a hardcoded value, because true wait-for-human exceeds the sandbox's runtime. The pattern is the gate, not the wait — agent decides, human signals, code branches.

Why email to self?

Because the curriculum's connector set is gmail / googletasks / sheets / docs / slides / linkedin / calendar — no Slack. Self-email gets the notification onto your phone via Gmail push, which is a valid HITL channel.

Human-in-the-loop — gate risky actions

python

def hitl_action(action_description, approved_signal):
    # 1. Notify a human (email yourself — production: Slack/SMS/dashboard alert)
    notify_human(action_description)

    # 2. Read approval signal
    if not approved_signal:
        return {"status": "declined", "acted": False}

    # 3. Perform the action
    result = perform(action_description)
    return {"status": "approved", "acted": True, "result": result}

Why split prepare from act

Agents are powerful and probabilistic. The same prompt today produces a different decision tomorrow. For high-stakes actions (transactions, public posts, privileged data), you want a human checkpoint every time until trust is earned.

The notification channel

Whatever reaches a human reliably:

Email-to-self — works on every device, persists in inbox, works over poor connectivity
Calendar event — creates a literal calendar item with the action description (yes/no in the response)
Sheet append — pending row with a status column the human flips
Production: Slack / Teams / SMS / dashboard — outside this curriculum's connector set

All four are equivalent — the channel is whatever puts the request in front of a human and then provides a way to read the response.

The approval signal

Where does the approved boolean come from?

Polling a Sheet — read a cell, check for "yes"
Polling Gmail — search for a reply with subject containing [APPROVED]
Webhook — production-grade; agent pauses, webhook resumes
Sandbox simulation — for this lesson, hardcoded — the gate is the lesson, not the polling

What "acted" looks like

The gate has two outputs: {acted: true, result} or {acted: false, reason}. Always return both — downstream code (or the eval suite) can branch on whether the action fired.

Retry vs gate

Different failure modes:

Retry = transient failure, repeat the same action
Gate = permanent decision, either fire or skip

Combining: a gated action that fires can be wrapped in retry; a gate that returns declined doesn't retry — it logs and moves on.

Day 19 · ~12 min●

Some actions shouldn't fire automatically. Sending money. Posting publicly. Modifying customer data. The pattern: agent prepares → human approves → agent acts.

Three steps:

Agent describes what it wants to do
A request goes to a human (we'll send an email to yourself — a Slack-like notification using whatever channel you have)
Code reads an approval signal; only acts if approved

python

# 1. Prepare
action = {"type": "send_email", "to": "customer@x", "body": "..."}

# 2. Notify (email to self — production: Slack message, dashboard alert, SMS)
toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": user_email,
    "subject": "[APPROVAL NEEDED] Send to customer",
    "body": f"Action proposed: {action}\n\nReply 'approve' to proceed.",
})

# 3. Read signal & act
if approved:
    perform(action)
else:
    log_skip(action)

And the script just sits there waiting for me to approve?

Why email to self?

Human-in-the-loop — gate risky actions

python

def hitl_action(action_description, approved_signal):
    # 1. Notify a human (email yourself — production: Slack/SMS/dashboard alert)
    notify_human(action_description)

    # 2. Read approval signal
    if not approved_signal:
        return {"status": "declined", "acted": False}

    # 3. Perform the action
    result = perform(action_description)
    return {"status": "approved", "acted": True, "result": result}

Why split prepare from act

The notification channel

Whatever reaches a human reliably:

Email-to-self — works on every device, persists in inbox, works over poor connectivity
Calendar event — creates a literal calendar item with the action description (yes/no in the response)
Sheet append — pending row with a status column the human flips
Production: Slack / Teams / SMS / dashboard — outside this curriculum's connector set

All four are equivalent — the channel is whatever puts the request in front of a human and then provides a way to read the response.

The approval signal

Where does the approved boolean come from?

Polling a Sheet — read a cell, check for "yes"
Polling Gmail — search for a reply with subject containing [APPROVED]
Webhook — production-grade; agent pauses, webhook resumes
Sandbox simulation — for this lesson, hardcoded — the gate is the lesson, not the polling

What "acted" looks like

The gate has two outputs: {acted: true, result} or {acted: false, reason}. Always return both — downstream code (or the eval suite) can branch on whether the action fired.

Retry vs gate

Different failure modes:

Retry = transient failure, repeat the same action
Gate = permanent decision, either fire or skip

Combining: a gated action that fires can be wrapped in retry; a gate that returns declined doesn't retry — it logs and moves on.

Human-in-the-loop — gate risky actions

Why split prepare from act

The notification channel

The approval signal

What "acted" looks like

Retry vs gate

Human-in-the-loop — gate risky actions

Why split prepare from act

The notification channel

The approval signal

What "acted" looks like

Retry vs gate

Human-in-the-loop — gate risky actions

Why split prepare from act

The notification channel

The approval signal

What "acted" looks like

Retry vs gate

Sign up to practice

Human-in-the-loop — gate risky actions

Why split prepare from act

The notification channel

The approval signal

What "acted" looks like

Retry vs gate

Sign up to practice