# Which backend is this build? Nobody knows.

> Code complete is not shipped.

- **Format:** short video, 9 steps, ~51 seconds
- **Topic:** AI agents for DevOps, release management, monitoring and analytics — a finished Flutter app ships with its backend chosen by a code default, tester notes taken from the last commit subject and no crash reporting, and how four agents make each decision before the first release.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** AI · AI
- **Published:** 2026-08-24
- **Tags:** devops, flutter, releasemanagement, observability, aiagents, githubactions, aicoding, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/ai-ship-agents-code-complete-not-shipped/

---
## What you'll learn

- Why a build should say which backend it talks to
- Why release notes from commits read like a diff
- Why incident questions come before dashboards

## Understand it one step at a time

### 1. The build works

Signed in CI, installed by a tester. It runs.

### 2. Which backend?

AppConfig picks Backend.demo unless code says otherwise. Nothing in the APK shows it.

### 3. What changed?

With no notes typed in, testers get the last commit subject.

### 4. What broke?

No crash reporting in pubspec.yaml. A crash at start-up is silent.

### 5. DevOps: a build input

--dart-define=BACKEND, fail a release without it, show it in About.

### 6. Release: notes from intent

Notes written from requirements. A tag must match pubspec and CHANGELOG.

### 7. Monitoring: questions first

Which build? Which backend? Which screen? Since when? Written before the incident.

### 8. Shipped, and watched

Plus analytics/events.yaml: 14 events, one name per action, before any SDK.

### 9. Code complete is not shipped

Decide the build, the notes, the questions and the events before you release.

---

## The takeaway

**Code complete is not shipped.**

Four decisions nobody owned: which build, what changed, what broke, what to measure.