Skip to content
Page 1 of 1

Sprint 2: Make It Trustworthy

Where You Are

In Sprint 1, your team built a Vessel Traffic Dashboard from real government data. Vessel positions, ports, weather alerts, tide readings: you connected multiple sources into an operational picture that a Coast Guard watchstander would recognize as useful. You wrote user stories with acceptance criteria, created a context file, and practiced the build loop.

Then in Lesson 2, the focus shifted from building to safeguarding. You learned:

  • Automated testing: your acceptance criteria (Given/When/Then) are already test specifications. Hand them to AI, and it generates automated tests that verify your features work.
  • Quality gates: a pipeline of automated checks (tests, security scans, code quality) that every change must pass before it ships. Nothing goes live unless all gates pass.
  • Human judgment: some features are safe to run on their own; others need a human reviewing every output. The question is: can you undo it if something goes wrong, and what are the consequences if it ships without review?
  • Teams in the AI era: everyone can build, but specialization, taste, and judgment matter more than ever.

The Challenge

Your dashboard shows information. Now make it smart, and make it trustworthy.

In Sprint 1, you built display: here are the vessels, here are the conditions. In Sprint 2, your dashboard starts making assessments. When water levels drop, which vessels draw too much for the current depth? When weather deteriorates, which vessels are in the affected area? When a vessel is reporting "Under way using engine" but showing zero speed, something is wrong. Those are the patterns that precede incidents, and your dashboard should surface them before the watchstander has to notice them on their own.

At the same time, you are going to apply what you learned in Lesson 2. You built features in Sprint 1. Now put automated verification behind them. You built an AI-generated briefing (or you will build one now). Decide whether it needs a human to approve every output, or whether it can run on its own with a human monitoring. Build that decision into the application.

What to Build

Add assessment capabilities and apply safeguarding practices from Lesson 2.

Tool capabilities:

  • Draft clearance assessment: the watchstander can see water levels at channel stations compared against vessel requirements, so they know when depth may be insufficient for specific vessels in the area
  • Weather-impact assessment: the watchstander can see which vessels are in areas where weather alerts are active, so they can issue advisories before conditions get worse
  • Vessel behavior detection: the dashboard flags vessels showing inconsistent or concerning data. A vessel reporting "Under way using engine" but showing zero speed. A vessel whose navigational status does not match its behavior. These are the patterns that precede incidents, and the dashboard should surface them.

Putting what you learned into practice:

  • Turn at least one acceptance criterion into an automated test. Pick a feature from Sprint 1 or a new assessment you are building now. Write the acceptance criterion in Given/When/Then format. Tell your AI assistant to generate an automated test for it. Watch the test run. If it passes, you have verified that the feature works. If it fails, you know exactly what to fix. That is the closed loop from Lesson 2.
  • Decide which features need human review. Look at the features in your dashboard. Which ones are easy to undo if something goes wrong? (Displaying vessel positions from a data file: if the display is wrong, you fix it and refresh. Low consequence.) Which ones could cause real problems if they shipped with bad output? (An AI-generated briefing that recommends closing the channel to traffic: if that recommendation is wrong and someone acts on it, the consequences are significant.) For each feature, decide: should a human approve every output, or is it safe to let it run with a human checking in periodically? If you built the AI-generated shift briefing in Sprint 1, that is a great candidate for this decision. If you did not build it yet, build it now, then decide.
  • Save and sync your work after every working feature.

These are options for teams that finish the baseline capabilities. Your team can also define your own stretch goals.

  • Hazard correlation: the watchstander can see which vessels are near active navigational hazards (wrecks, light outages, pipeline operations, restricted areas). Your project has navigational warnings and broadcast warnings data. Cross-reference those with vessel positions so the watchstander does not have to check every warning against every vessel manually.
  • Prioritized attention view: combine all flagged items (hazard proximity, behavior anomalies, weather impacts, clearance issues) into one ranked view. The watchstander sees the highest-priority situations first, not a flat list.
  • Conditions risk score: a triage rating system that gives the watchstander a quick way to see which situations are highest priority
  • Quality gates running: your quality gate pipeline runs your automated verifications, so nothing ships without passing the checks you defined
  • Deployed to a live URL: you have confidence that your quality gates are checking for the right things, and you got your software through all those gates and into production. Tell your AI coding assistant to deploy the project and get back a working URL.
  • AI-generated shift briefing (if not built in Sprint 1): the watchstander can get a complete operational brief generated by AI from current data, enough to hand off to the next watch. Then decide: does this feature need human-in-the-loop (human approves every briefing before it is shown) or human-on-the-loop (briefing runs automatically, human reviews periodically)?

Tips

  • Start with the test. Pick the feature you are most confident about from Sprint 1. Write the acceptance criterion: "Given [condition], when [action], then [expected result]." Ask your AI assistant: "Generate an automated test for this acceptance criterion." Run it. That first green test builds confidence for everything else.
  • The human judgment question is a team discussion. There is no single right answer. Talk through it: "If this feature produces wrong output and someone acts on it, what happens? Can we undo it? How quickly would we notice?" Those questions determine where the feature sits.
  • Update your context file as you build. When you add domain rules (what water levels trigger concern, what vessel behavior is suspicious), add them to the context file. Your AI assistant uses those rules when it writes code, so the software follows them automatically.
  • Ground assessments in real conditions. AI can generate logic that sounds right but uses wrong thresholds. When the dashboard flags something, trace the logic back: what data triggered it, what rule applied, and does the threshold make sense? Ask: "What is a normal water level range at Houston Ship Channel stations, and when do low levels start affecting vessel transit?"
  • Save and sync often. You know the drill.

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, everyone else navigates. Rotate every few minutes. One keyboard, zero collisions.