Operations Phase — Living With What You Built

Build and Test is approved. The Class Library Loan Tracker works, and it's been tested. But right now, it's just sitting on a computer somewhere — nobody is actually using it yet.

Phase 3 of 3: Operations Goal: put it in front of real users, watch it, fix it, and learn from it.

A note on where the tooling is today: in the current open-source AI-DLC methodology, Operations is officially still a placeholder for future expansion — the real build-and-test work happens inside Construction, as we just saw. What's below is the direction AI-DLC is heading and the mental model real teams already use once they take a Construction hand-off live themselves. The idea — deploy it, watch it, learn from it, loop back — doesn't need the tooling to catch up to be true; it's just not fully automated yet.

The Treehouse Is Built — Now What?

Finishing the treehouse isn't the end of the story — it's the point where kids actually start climbing up and playing in it. Now you have new jobs: check the ladder doesn't wobble after a week of use, watch for a splinter on the railing, and listen when someone says "it would be even better with a flag on top."

That's Operations: using the real thing, watching how it holds up, fixing what breaks, and collecting good ideas.

What Actually Happens in Operations

1. Deploy — Put It Where Real Users Can Reach It

The app moves from "on a developer's laptop" to somewhere Ms. Sharma and her students can actually open and use it — the same way a treehouse goes from "pieces in the garage" to "bolted to the tree in the backyard, ready to climb."

2. Monitor — Watch How It's Actually Behaving

Think of this like the app keeping its own diary of everything it does: every loan recorded, every return, every time something goes wrong. If a student later says "the app said I had 3 books, but that's wrong!", this diary is how you figure out what actually happened, instead of guessing.

   App's diary (a "log"), in plain words:
   ─────────────────────────────────────
   09:03  Ms. Sharma recorded a loan: "Charlotte's Web" → Alice
   09:04  Attempted loan blocked: book already on loan to Alice
   09:15  Ms. Sharma recorded a return: "Charlotte's Web"
   09:16  Loan recorded: "Charlotte's Web" → Bob

3. Support — When Something Breaks or Confuses Someone

If Ms. Sharma runs into a bug, or something is confusing, that gets written down as an issue — just like the review notes in Inception, except this time the app already exists in the real world.

4. Feedback — Collect Ideas From Real Use

Once real people use the thing for a while, they notice things a plan never could have predicted. A week in, Ms. Sharma says:

Ms. Sharma: "This is working great! One thing though — I keep forgetting to check the overdue list. Could it just remind me the day before a book is due?"

That's a brand new idea. It wasn't in the original Inception document — and that's completely fine. It's not a flaw in the plan; it's exactly what's supposed to happen once real people use real software.

The Loop Back to Inception

Here's the part that makes AI-DLC a genuine cycle rather than a one-time checklist: that new idea doesn't get bolted onto the code directly. It becomes its own small, focused Inception — a mini version of what we did in Lesson 2 — and goes through the same journey: plan it, review it, build it, ship it.

flowchart LR
    I["Inception\n'Add due-date reminders'"] --> C["Construction\nbuild + test the reminder"]
    C --> O["Operations\nship it, watch it work"]
    O -.-> I2["Next Inception..."]

    classDef phase fill:#e1bee7,stroke:#7b1fa2,stroke-width:2px;
    class I,C,O,I2 phase;

The dotted arrow is Ms. Sharma's next idea, flowing straight back into a new Inception. This is why AI-DLC is drawn as a loop, not a straight line: Operations is where you learn the most about what to build next, because it's the first time real people are actually using the real thing.

Simple Operational Artifacts

Just like Inception and Construction produced lightweight documents, it's worth keeping a few of your own for Operations too — nothing fancy, just enough to remember what happened. Since the tooling doesn't generate these automatically yet, a plain file living next to aidlc-docs/ works fine:

# Operations Notes: Class Library Loan Tracker

## Deployed
- v1 shipped 2026-08-10. In use by Ms. Sharma's class.

## Incidents / Bugs
- 2026-08-14: A returned book briefly still showed as
  "on loan" — cache refresh issue. Fixed same day.

## Feedback Received
- 2026-08-17 (Ms. Sharma): Wants a reminder the day before
  a book is due. → Logged as a new feature idea, feeding
  into the next Inception.

What's Next

We've now walked through all three phases end to end: Inception planned it, Construction built it, Operations is living with it and feeding new ideas back in. One question is still open, and it's an important one: after a feature ships, what happens to the Inception document, the Construction log, and these Operations notes? Do we clean them up and delete them?

Continue to: What Happens to the Documents? (Do We Delete Them?)