Skip to content
Page 2 of 2

Sprint 1: Vessel Traffic Dashboard

What You're Starting With

From Lesson 1, you have:

  • User stories with acceptance criteria: your plan for each piece of the dashboard. Quick refresher: As a [who needs this], I want [what they need] so that [why it matters]. Given [a starting situation], when [something happens], then [what should be true].
  • How AI works: it is probabilistic (makes educated guesses), stateless (forgets between conversations), and has limited memory within a conversation. You know why specificity matters and how to control variation.
  • Context files: the "house-sitter note" that gives AI persistent memory of your project across conversations
  • The Build Loop from Getting Started: describe what you want, AI edits files, you check the result in your browser. Save & Sync protects your work and shares it with your team.

The Challenge

Build a Vessel Traffic Dashboard: a working, multi-source application that gives a Coast Guard VTS watchstander an operational picture of the Houston Ship Channel.

Your development environment has real operational data pre-loaded in the data/maritime/ directory. As you build capabilities, your AI coding assistant can find and connect the data sources it needs from that directory. You do not need to find or download anything. Just tell your AI assistant what you want to build, and let it discover the data.

Who You're Building For

A Coast Guard Vessel Traffic Service watchstander at VTS Houston-Galveston. They sit on a watch floor monitoring 70+ miles of restricted waterways: the Houston Ship Channel, Galveston Channel, Texas City Channel, and Bayport Ship Channel. On a typical day, 50+ deep-draft vessels, 400+ tugs, and 600+ barges move through their area.

Their job is to know, at any moment: what vessels are in the area, what the conditions are, and whether anything needs attention. Right now, that information comes from multiple separate systems. Your dashboard starts bringing it together.

What to Build

Build the operational picture. Connect real data sources into a tool a watchstander would recognize as useful.

Tool capabilities:

  • The watchstander can see the traffic picture built from real data: what vessels are in the area, what they are doing, and how the channel looks overall. Your AI coding assistant can find vessel position data in the project and wire it in.
  • The watchstander can tell at a glance which vessels or conditions might need attention, so they can focus where it matters instead of scanning everything equally
  • The watchstander can see how different data sources connect: vessels alongside conditions, ports alongside capabilities, so that the operational picture is richer than any single source alone
  • The application has sections a watchstander can navigate: traffic, conditions, port information, or whatever organization makes sense for the job

Putting what you learned into practice:

  • Write a user story with acceptance criteria before you build each capability. Use the format from Lesson 1: As a VTS watchstander, I want [what they need] so that [why it matters]. Given [a starting situation], when [something happens], then [what should be true]. Check each acceptance criterion when the feature is done: pass or fail.
  • Create a project context file so your AI assistant knows your project, your data sources, and your design without you explaining anything. When you start a new conversation, AI should pick up right where you left off.
  • Save and sync your work every time something works. That is your safety net and your collaboration tool.

These are options for teams that want to push further. Your team can also define your own stretch goals. Your AI assistant is a capable research partner: ask it what else a VTS watchstander needs, then build toward it.

  • The watchstander can assess how weather or conditions affect the vessels currently in the channel
  • The watchstander can evaluate whether nearby ports have the depth and facilities a specific vessel needs
  • AI-generated shift-change briefing: the watchstander can get a complete operational brief from one view, enough to hand off to the next watch. This briefing is generated by AI based on the current data. (If you build this, you will use it in Sprint 2 to practice a key concept from Lesson 2.)
  • The watchstander can answer "what do I need to know right now?" without piecing it together from separate sections
  • Context file verified: start a fresh conversation and confirm that AI knows your project, your data sources, and your design without you explaining anything

Tips

  • Don't know the domain? Ask your AI assistant. Before you start building, ask: "What does a VTS watchstander need to monitor in a busy shipping channel? What situations require them to issue a traffic advisory? What makes traffic conditions concerning versus routine?" The answers will shape what you build.
  • Start with one capability. Don't try to build everything in your first prompt. Pick one thing the watchstander needs, build it, verify it works, then add the next piece.
  • Let capabilities drive data discovery. When a capability needs data (weather conditions, port information, water levels), tell your AI coding assistant what you are trying to build and let it find the right data source in the project. Try: "I want the watchstander to see current weather conditions. Is there data in this project that can power that?"
  • Quick user story template: "As a VTS watchstander, I want [what you're building] so that [why it helps]. Given [a specific condition], when [something happens], then [what the watchstander should see]."
  • Verify criterion by criterion, then be specific. Don't eyeball the whole page and say "looks good." Go through each acceptance criterion. Pass or fail. When one fails, say exactly what is wrong.
  • Save and sync often. Every time something works, tell your AI assistant: "Save my progress and sync it."

Go build. That is the brief. Spend the rest of this sprint working on your challenge with your team. Your Facilitator will let you know when it is time for the Reflection.

Our recommendation: mob until you have clear swim lanes. Think of your project like a shared document. If two people edit the same section at the same time, their changes collide. The safe way to split up is clear swim lanes, where each person works on a different part of the application. Until your team has those lanes, mob: one person drives (hands on the keyboard), everyone else navigates (watches, thinks ahead, gives feedback). Rotate the driver every few minutes. One keyboard, zero collisions.