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.

Day 26 · ~11 min●

Week 3 introduced PII (L15), retry (L16), fallback (L17) — three guardrails in isolation. Production wraps all of them around every call. The pattern: nest them.

python

def safe_call(query):
    clean = redact(query)             # guardrail 1: PII
    return with_retry(
        lambda: with_fallback([primary, secondary])(clean),
        max_attempts=3,
    )

Reading inside-out: the core is the LLM call, wrapped in fallback (try primary then secondary), wrapped in retry (each tier gets retried on rate-limit), and the input is redacted before any of it. Three layers of defense.

Order matters?

Yes. PII redaction is outermost on the input — you never want raw PII to reach any downstream tier, including the cache. Retry is inside fallback because retrying a primary that's permanently down wastes time; fall back to secondary first, retry within the secondary if needed.

Why decorators?

Pure functional composition. Each decorator wraps a function, returns a new function with the guardrail attached. You write the core call once, layer guardrails on top by chaining decorators. The same @with_retry @with_fallback @with_redaction stack ships across hundreds of call sites.

Guardrail composition

python

def with_pii_redaction(fn):
    def wrapper(query, *args, **kwargs):
        clean = redact(query)
        return fn(clean, *args, **kwargs)
    return wrapper

def with_retry(fn, max_attempts=3):
    def wrapper(*args, **kwargs):
        for attempt in range(max_attempts):
            try:
                return fn(*args, **kwargs)
            except RateLimitError:
                if attempt == max_attempts - 1:
                    raise
                time.sleep(2 ** attempt)
    return wrapper

def with_fallback(strategies):
    def wrapper(*args, **kwargs):
        for s in strategies:
            try:
                return s(*args, **kwargs)
            except Exception:
                continue
        raise RuntimeError("all strategies failed")
    return wrapper

Composition order

  Input → [PII redact] → [retry] → [fallback] → [LLM] → Output
              ↓             ↓          ↓           ↓
         OUTERMOST     middle    inner    CORE

PII redact OUTSIDE — clean input never touches anything downstream
Retry MIDDLE — same input, retried until success or cap
Fallback INNER — different strategy when retry exhausts
LLM CORE — the actual call you're guarding

Why composition, not a god-function

python

# god function — fragile, hard to test
def the_call_with_everything(query):
    clean = redact(query)
    for attempt in range(3):
        for strategy in [primary, secondary]:
            try:
                return strategy(clean)
            except RateLimitError:
                time.sleep(2 ** attempt)
            except Exception:
                continue
    raise RuntimeError("failed")

Three concerns mixed; bug in one breaks the others. Composition keeps each guardrail independent: tested separately, swapped independently, reused across call sites.

What you don't compose

HITL gate — fundamentally control-flow, not transparent wrapping. Stays explicit.
Caching — depends on the function signature, hard to make generic. Often inlined in the call site.
Rate-limit observation — observability, not guardrail. Uses logging (yesterday's lesson).

Production-grade patterns

Libraries like tenacity provide @retry decorators with exponential backoff, jitter, retry-on-specific-exception, and stop-after-N-attempts as kwargs. The composition is the same — tenacity just packages the implementation.

Day 26 · ~11 min●

Week 3 introduced PII (L15), retry (L16), fallback (L17) — three guardrails in isolation. Production wraps all of them around every call. The pattern: nest them.

python

def safe_call(query):
    clean = redact(query)             # guardrail 1: PII
    return with_retry(
        lambda: with_fallback([primary, secondary])(clean),
        max_attempts=3,
    )

Reading inside-out: the core is the LLM call, wrapped in fallback (try primary then secondary), wrapped in retry (each tier gets retried on rate-limit), and the input is redacted before any of it. Three layers of defense.

Order matters?

Yes. PII redaction is outermost on the input — you never want raw PII to reach any downstream tier, including the cache. Retry is inside fallback because retrying a primary that's permanently down wastes time; fall back to secondary first, retry within the secondary if needed.

Why decorators?

Pure functional composition. Each decorator wraps a function, returns a new function with the guardrail attached. You write the core call once, layer guardrails on top by chaining decorators. The same @with_retry @with_fallback @with_redaction stack ships across hundreds of call sites.

Guardrail composition

python

def with_pii_redaction(fn):
    def wrapper(query, *args, **kwargs):
        clean = redact(query)
        return fn(clean, *args, **kwargs)
    return wrapper

def with_retry(fn, max_attempts=3):
    def wrapper(*args, **kwargs):
        for attempt in range(max_attempts):
            try:
                return fn(*args, **kwargs)
            except RateLimitError:
                if attempt == max_attempts - 1:
                    raise
                time.sleep(2 ** attempt)
    return wrapper

def with_fallback(strategies):
    def wrapper(*args, **kwargs):
        for s in strategies:
            try:
                return s(*args, **kwargs)
            except Exception:
                continue
        raise RuntimeError("all strategies failed")
    return wrapper

Composition order

  Input → [PII redact] → [retry] → [fallback] → [LLM] → Output
              ↓             ↓          ↓           ↓
         OUTERMOST     middle    inner    CORE

PII redact OUTSIDE — clean input never touches anything downstream
Retry MIDDLE — same input, retried until success or cap
Fallback INNER — different strategy when retry exhausts
LLM CORE — the actual call you're guarding

Why composition, not a god-function

python

# god function — fragile, hard to test
def the_call_with_everything(query):
    clean = redact(query)
    for attempt in range(3):
        for strategy in [primary, secondary]:
            try:
                return strategy(clean)
            except RateLimitError:
                time.sleep(2 ** attempt)
            except Exception:
                continue
    raise RuntimeError("failed")

Three concerns mixed; bug in one breaks the others. Composition keeps each guardrail independent: tested separately, swapped independently, reused across call sites.

What you don't compose

HITL gate — fundamentally control-flow, not transparent wrapping. Stays explicit.
Caching — depends on the function signature, hard to make generic. Often inlined in the call site.
Rate-limit observation — observability, not guardrail. Uses logging (yesterday's lesson).

Production-grade patterns

Libraries like tenacity provide @retry decorators with exponential backoff, jitter, retry-on-specific-exception, and stop-after-N-attempts as kwargs. The composition is the same — tenacity just packages the implementation.

Day 26 · ~11 min●

Week 3 introduced PII (L15), retry (L16), fallback (L17) — three guardrails in isolation. Production wraps all of them around every call. The pattern: nest them.

python

def safe_call(query):
    clean = redact(query)             # guardrail 1: PII
    return with_retry(
        lambda: with_fallback([primary, secondary])(clean),
        max_attempts=3,
    )

Reading inside-out: the core is the LLM call, wrapped in fallback (try primary then secondary), wrapped in retry (each tier gets retried on rate-limit), and the input is redacted before any of it. Three layers of defense.

Order matters?

Yes. PII redaction is outermost on the input — you never want raw PII to reach any downstream tier, including the cache. Retry is inside fallback because retrying a primary that's permanently down wastes time; fall back to secondary first, retry within the secondary if needed.

Why decorators?

Pure functional composition. Each decorator wraps a function, returns a new function with the guardrail attached. You write the core call once, layer guardrails on top by chaining decorators. The same @with_retry @with_fallback @with_redaction stack ships across hundreds of call sites.

Guardrail composition

python

def with_pii_redaction(fn):
    def wrapper(query, *args, **kwargs):
        clean = redact(query)
        return fn(clean, *args, **kwargs)
    return wrapper

def with_retry(fn, max_attempts=3):
    def wrapper(*args, **kwargs):
        for attempt in range(max_attempts):
            try:
                return fn(*args, **kwargs)
            except RateLimitError:
                if attempt == max_attempts - 1:
                    raise
                time.sleep(2 ** attempt)
    return wrapper

def with_fallback(strategies):
    def wrapper(*args, **kwargs):
        for s in strategies:
            try:
                return s(*args, **kwargs)
            except Exception:
                continue
        raise RuntimeError("all strategies failed")
    return wrapper

Composition order

  Input → [PII redact] → [retry] → [fallback] → [LLM] → Output
              ↓             ↓          ↓           ↓
         OUTERMOST     middle    inner    CORE

PII redact OUTSIDE — clean input never touches anything downstream
Retry MIDDLE — same input, retried until success or cap
Fallback INNER — different strategy when retry exhausts
LLM CORE — the actual call you're guarding

Why composition, not a god-function

python

# god function — fragile, hard to test
def the_call_with_everything(query):
    clean = redact(query)
    for attempt in range(3):
        for strategy in [primary, secondary]:
            try:
                return strategy(clean)
            except RateLimitError:
                time.sleep(2 ** attempt)
            except Exception:
                continue
    raise RuntimeError("failed")

Three concerns mixed; bug in one breaks the others. Composition keeps each guardrail independent: tested separately, swapped independently, reused across call sites.

What you don't compose

HITL gate — fundamentally control-flow, not transparent wrapping. Stays explicit.
Caching — depends on the function signature, hard to make generic. Often inlined in the call site.
Rate-limit observation — observability, not guardrail. Uses logging (yesterday's lesson).

Production-grade patterns

Libraries like tenacity provide @retry decorators with exponential backoff, jitter, retry-on-specific-exception, and stop-after-N-attempts as kwargs. The composition is the same — tenacity just packages the implementation.

Day 26 · ~11 min●

Week 3 introduced PII (L15), retry (L16), fallback (L17) — three guardrails in isolation. Production wraps all of them around every call. The pattern: nest them.

python

def safe_call(query):
    clean = redact(query)             # guardrail 1: PII
    return with_retry(
        lambda: with_fallback([primary, secondary])(clean),
        max_attempts=3,
    )

Reading inside-out: the core is the LLM call, wrapped in fallback (try primary then secondary), wrapped in retry (each tier gets retried on rate-limit), and the input is redacted before any of it. Three layers of defense.

Order matters?

Yes. PII redaction is outermost on the input — you never want raw PII to reach any downstream tier, including the cache. Retry is inside fallback because retrying a primary that's permanently down wastes time; fall back to secondary first, retry within the secondary if needed.

Why decorators?

Pure functional composition. Each decorator wraps a function, returns a new function with the guardrail attached. You write the core call once, layer guardrails on top by chaining decorators. The same @with_retry @with_fallback @with_redaction stack ships across hundreds of call sites.

Guardrail composition

python

def with_pii_redaction(fn):
    def wrapper(query, *args, **kwargs):
        clean = redact(query)
        return fn(clean, *args, **kwargs)
    return wrapper

def with_retry(fn, max_attempts=3):
    def wrapper(*args, **kwargs):
        for attempt in range(max_attempts):
            try:
                return fn(*args, **kwargs)
            except RateLimitError:
                if attempt == max_attempts - 1:
                    raise
                time.sleep(2 ** attempt)
    return wrapper

def with_fallback(strategies):
    def wrapper(*args, **kwargs):
        for s in strategies:
            try:
                return s(*args, **kwargs)
            except Exception:
                continue
        raise RuntimeError("all strategies failed")
    return wrapper

Composition order

  Input → [PII redact] → [retry] → [fallback] → [LLM] → Output
              ↓             ↓          ↓           ↓
         OUTERMOST     middle    inner    CORE

PII redact OUTSIDE — clean input never touches anything downstream
Retry MIDDLE — same input, retried until success or cap
Fallback INNER — different strategy when retry exhausts
LLM CORE — the actual call you're guarding

Why composition, not a god-function

python

# god function — fragile, hard to test
def the_call_with_everything(query):
    clean = redact(query)
    for attempt in range(3):
        for strategy in [primary, secondary]:
            try:
                return strategy(clean)
            except RateLimitError:
                time.sleep(2 ** attempt)
            except Exception:
                continue
    raise RuntimeError("failed")

Three concerns mixed; bug in one breaks the others. Composition keeps each guardrail independent: tested separately, swapped independently, reused across call sites.

What you don't compose

HITL gate — fundamentally control-flow, not transparent wrapping. Stays explicit.
Caching — depends on the function signature, hard to make generic. Often inlined in the call site.
Rate-limit observation — observability, not guardrail. Uses logging (yesterday's lesson).

Production-grade patterns

Libraries like tenacity provide @retry decorators with exponential backoff, jitter, retry-on-specific-exception, and stop-after-N-attempts as kwargs. The composition is the same — tenacity just packages the implementation.

Privacy Terms

Sign up to practice

Create a free account to get started. Paid plans unlock all tracks.

or

Sign up to practice

Create a free account to get started. Paid plans unlock all tracks.

or