REPL-Driven Flight Tracking: Agentic Development with Contracts and Guardrails

This research explores REPL-driven development as the primary interface for agentic software systems, using multi-source flight tracking as the application substrate. The system correlates FlightAware's AeroAPI, local ADS-B receivers, and web scrapers — surfacing divergences between data paths as the primary output, not flight status.

The deliverable is two-layered: the first layer is a working flight tracking system; the second, transferable layer is a measured account of how agents safely operate against metered APIs with cost constraints, contract verification across independent sources, and schema evolution under failure injection.

The best interface between an agent and a complex system is not a CLI that returns exit codes. It is a REPL that lets the agent think out loud, inspect intermediate state, and build understanding incrementally — bounded by fixtures so it can't accidentally spend money or break things.

The system integrates three independent data sources, each with different cost profiles, latency characteristics, and failure modes:

The architectural insight is that divergence between sources is the signal. Three sources agreeing is uninteresting. Three sources disagreeing tells you where the contract boundary is.

All development defaults to AEROAPI_MODE=fixtures. In this mode:

• Every API call reads from recorded fixture files
• Zero network calls are made
• Zero API credit is consumed
• Results are deterministic

Switching to live requires explicit human opt-in: AEROAPI_MODE=live. This is not a convenience — it is a safety property that bounds the blast radius of autonomous agent exploration.

Without fixtures-first:  agent loops 200× → spends $1.00 → learns nothing new
With fixtures-first:     agent loops 200× → costs $0.00 → learns from recorded data

The fixture is the sandbox. Live is the deployment.

The contract verifier runs multiple adapters against the same flight and diffs their canonical output:

(def contract-keys [:ident :registration :status :gate_destination :estimated_in])

;; Callsign normalization: BA48 ≡ BAW48 ≡ BAW48Q
(defn normalize-ident [s]
  (cond
    (re-matches #"[A-Z]{2}\d+.*" s)
    (str ({"BA" "BAW" "AA" "AAL" "DL" "DAL"} (subs s 0 2)) (subs s 2))
    :else s))

A key finding: the AeroAPI and the FlightAware website disagree on field availability at different lifecycle stages. The gate_origin field is visible on the website before it appears in the API — a real contract divergence that naive consumers would miss.

British Airways 48, Boeing 777-300ER, KSEA → EGLL. Daily transatlantic service.

All tooling is implemented in Babashka (bb), a fast-starting Clojure scripting runtime (~10ms startup vs ~5s for JVM Clojure).

bb tasks    # 14 available tasks

Every task is idempotent, mode-aware (respects AEROAPI_MODE), and REPL-accessible — the same namespace that powers the CLI is available for interactive exploration.

Redis Streams provide Kafka-like operational patterns on FreeBSD without the JVM dependency:

All components emit structured NDJSON logs and OTLP metrics:

Script → log-event → events.ndjson → otel-tail → OTLP → Prometheus → Grafana
    │                                                              │
    └── emit-counter ──────────────────────── OTLP ────────────────┘

The agent and the human see the same dashboard. Anomaly detection is not special — it's a Prometheus alert.

1. REPL-driven = the agent explores safely with sub-second feedback
2. Fixtures-first = the agent can't overspend ($0.00 for exploration)
3. Contract verification = the agent knows when sources disagree
4. Observability = the human sees everything the agent did
5. Schema evolution = payload changes are explicit and validated
6. Jepsen-lite = correctness properties verified under failure

• Source code (GitHub)
• Babashka — fast Clojure scripting
• FlightAware AeroAPI — flight data API
• ADS-B — automatic dependent surveillance
• Redis Streams — event streaming
• Jepsen — distributed systems testing