CoolWalk

Inspiration

Earlier this month, a historic heat wave killed dozens of people across the Northeast — three New Yorkers died in their own homes, from the heat alone. Every summer, millions of people walk through cities like New York with no idea that the route they take could be the difference between a safe walk and a genuine medical risk. Google Maps, Apple Maps, every mainstream navigation app — they all optimize for exactly one thing: speed. None of them know where the shade is, and none of them care.

CoolWalk exists to fix that specific gap: a walking navigation app that compares your fastest route against your coolest one, using real building shadows, real tree canopy, and live weather — not a guess, not a heuristic, an actual physically-modeled answer.

What it does

Given a start and destination in Manhattan, CoolWalk shows two routes side by side: the fastest, and the coolest. Each comes with real, comparable numbers — distance, walking time, and percent shaded — so you can see exactly what trade-off you're making, not just trust a black box.

You describe your situation in plain language — "I'm walking with my grandmother," "I'm in a rush," "I have asthma and it's a bad air quality day" — and GPT-5.6 converts that into actual routing parameters: how strongly to prefer shade, and how much extra distance is worth it. You can also choose Leave now, where live weather actively adjusts the routing (if it's heavily overcast, CoolWalk correctly recognizes there's no real shade benefit and lets the two routes honestly converge, instead of faking a difference that isn't there), or Pick a time, which routes against real sun-position data for any hour of the day. Every route also comes with real turn-by-turn directions, generated from the actual street-by-street path.

How we built it

The entire project — every line of code, every data pipeline, every bug fix — was built through Codex running GPT-5.6, prompted stage by stage with an explicit verification step after each one. The architecture:

• Sun position — suncalc, validated against real published NYC sunrise/sunset/solar-noon times before trusting anything downstream of it.
• Building shadow geometry — real height and footprint data for all 45,209 Manhattan building footprints (NYC's official Building Footprints dataset, clipped to the actual borough polygon, not a bounding rectangle), projected into shadow polygons per time-of-day using sun altitude/azimuth, with a capped shadow length to keep low-sun-angle geometry sane.
• Tree canopy — 398,279 LiDAR-derived canopy polygons, spatially indexed once and reused across every time bucket, since canopy doesn't move with the sun.
• Street network — OpenStreetMap, split into ~20m segments (190,076 of them across Manhattan), each scored shaded or unshaded per time-of-day bucket by spatial-indexed intersection against both the building-shadow and tree-canopy layers.
• Routing — a 318,002-edge citywide graph, cropped to a small local subgraph per request (a 90%+ size reduction in typical queries) before running weighted Dijkstra twice — once for pure distance, once with a shade-aware penalty — so real requests resolve in well under a second.
• Natural-language preferences — GPT-5.6 parses free text into routing weights (how much extra distance is worth how much shade), with explicit, honest fallback behavior when parsing fails rather than silently guessing.
• Weather-aware routing — live weather (National Weather Service) dynamically scales the shade preference down under heavy cloud cover, so "coolest" never pretends there's a benefit that doesn't physically exist.

One specific technical decision worth calling out: we didn't have separate OpenAI API credits, only Codex/ChatGPT usage — so instead of blocking on that, we architected the preference-parser to invoke the Codex CLI itself, non-interactively, with a JSON output schema, as the inference engine. It's genuinely running GPT-5.6, just routed through the tool we already had full access to. This also meant the parser inherits Codex's default read-only sandboxing for free — no risk of an agent editing files just to answer a routing question.

Challenges we ran into

Getting an agent to produce code that runs is the easy part. Getting a whole geospatial pipeline to be correct at real city scale was the actual challenge, and almost every hard bug looked fine at first glance:

• A bucket-time parsing bug silently mapped "2pm" to hour 2 instead of 14 (Number.parseInt("2pm") quietly succeeds), corrupting four of eight precomputed shade buckets before we caught it by checking actual UTC timestamps rather than trusting labels.
• Two separate "identical routes" bugs — one a genuine frontend rendering issue (both polylines silently referencing the same data), and later a completely different, legitimate case where fastest and coolest genuinely converge because a route is fully shaded or the weather makes shade irrelevant. Telling these apart required building dedicated diagnostic scripts rather than assuming either "it's a bug" or "it's fine."
• A turn-by-turn directions bug where consecutive segments of the same real street (split across different OSM way IDs, which is extremely common) were incorrectly treated as separate legs, producing nonsense directions. We had Codex build a raw-edge diagnostic script that printed every segment's name and assigned leg before touching any fix logic — the audit showed legs were splitting on way ID, not on actual street name changes.
• A landmark-geocoding mismatch, where selecting an ambiguous place like "Times Square" from Google's autocomplete and re-geocoding the same text server-side could resolve to two different coordinates — fixed by passing the user-selected coordinate through directly instead of re-resolving it.
• Manhattan's building count came back at 45,209 against outside estimates of 60–80k — investigated rather than assumed wrong, and resolved: Manhattan is dominated by large multi-unit towers (few footprints, many residents) while the citywide total is dominated by outer-borough single-family homes and garages (about a fifth of all NYC structures), so a lower Manhattan-specific count is exactly what the data's own definition predicts.

The recurring lesson: never trust that code "ran successfully" as proof it's correct. Every one of these bugs passed a build and produced plausible-looking output. Catching them required checking real ground truth — actual sunrise times, actual building heights, actual street names, actual weather — at every stage, not just at the end.

Accomplishments that we're proud of

A full physically-modeled shade-routing pipeline, at real city scale, that produces genuinely dramatic, honest results — a 68 percentage-point swing in shade coverage for only 15% more walking distance on a real Manhattan route — built entirely through an agentic coding workflow with a real, evidence-based debugging discipline at every stage.

What we learned

That the hardest part of building with an AI coding agent isn't getting it to write code — it's building the verification habits to catch the bugs that look fine. Diagnostics-before-fixes, checking against independent ground truth, and never accepting a summary of results without seeing the raw numbers, turned out to matter more than any single prompt.

What's next for CoolWalk

Expanding coverage beyond Manhattan to the other boroughs and other cities entirely (the pipeline is city-agnostic by design), adding forecasted weather for scheduled future departures, and surfacing cooling stations and shaded rest stops along a route — not just the route itself.

Built With

• codex
• google-cloud
• gpt5.6
• next.js