The AI-Augmented Team
COSC 40943 · Senior Design · Week 2
COSC 40943 · Senior Design · Week 2
You are accountable for what the agent writes.
Today: what you are signing into, and who else is on the team.
The glossary fixes vocabulary. Use the defined term in code identifiers and UI text, never a synonym.
CLAUDE.md, root of Project Pulse
Who decided this, and when?
revieweeevaluatee everywhere elseNothing fails. Tests pass. The pull request looks fine.
Six weeks later a query silently returns nothing, and the fix is a migration.
Mars Climate Orbiter fires its engine to enter orbit and is never heard from again.
Ground software produced pound-seconds. Navigation software consumed newton-seconds.
$125M of spacecraft. Each team's code was correct under its own assumption.
Trained by predicting the next token over an enormous corpus. It knows Spring Boot. It does not know your project, which was not in the training data.
And it is a function, not a process: text in, text out, then it stops. Nothing carries over.
Then why does a chat conversation seem to remember?
What looks like memory is re-reading.
Anything not in the context this turn does not exist this turn.
flowchart LR
C["context"] --> L["LLM"]
L --> A["action<br/>read, run, edit"]
A --> O["result"]
O --> C
R[("your repository")] -.-> C
Y["what you type"] -.-> CTomorrow starts empty and rebuilds from what you type and what it reads from disk.
So: does your agent know what your team decided on Wednesday?
Can
Files in the repo. The issue you point it at. Output of commands it runs.
Cannot
What was said out loud. The client's tone. Anything a teammate has not written down.
Your Slack is not documentation. It is an oral tradition with search.
The repository is the team's shared memory, and it is the only memory the agent has.
A decision that lives only in Slack is one your agent will contradict, confidently, next week.
If the repository is the only memory, the work has to live there too. Not just the code.
| Artifact | What it is | What it represents |
|---|---|---|
| Project | a board that displays issues | your state, at a glance |
| Issue | a unit of customer value, with acceptance criteria | one use case |
| Sub-issue | a unit of implementation work | one development task |
The board does not contain the work. Delete the board, lose a convenience. Delete the issues, lose the project.
flowchart TD
M["Milestone<br/><i>use-case area</i>"] --> I["Issue<br/><i>one use case</i>"]
I --> S1["Sub-issue<br/><i>task</i>"]
I --> S2["Sub-issue<br/><i>task</i>"]
S1 --> B1["branch"] --> P1["pull request"]
S2 --> B2["branch"] --> P2["pull request"]Every sub-issue has exactly one assignee: the person who signs it, not the one who typed it.
That is what acceptance criteria are for. It is the only test worth remembering.
Make Project Pulse Mobile-Friendly for Student and Instructor Workflows
Background · Summary · the exact pages in scope · Current behavior · Proposed improvement · Non-goals · Acceptance criteria · Risks · Rationale
When logging in, and the credentials are invalid/wrong, the application does not show an error on the page.
The solution should be: creating a pop-up that gives feedback to the user. e.i, "invalid credentials."
The console shows the error, but not the page.
Everything here is true. What is missing?
| Given to a person | Given to an agent | |
|---|---|---|
| What happens | They ask you a question | It picks an answer |
| You find out | Immediately, in Slack | At review, maybe |
| It looks like | An interruption | Finished work |
Under-specification used to arrive as friction. Now it arrives as a completed pull request.
A branch is not a unit of work. It is a unit of integration: one branch, one pull request, one merge.
The smallest change that leaves main green and is worth reviewing on its own.
"I'll take the front end." "I'll take login."
You saw this in week 1. It is fatal by November.
One developer owns a use case end to end: front end, back end, tests, pipeline.
Now it is the first read.
Typing was a slow, involuntary review. The author understood every line because they wrote it.
The agent wrote it. The author read the prompt and a summary. Nobody has read the diff.
Looks Generated To Me.
Issue, sub-issues, branches, review, merge.
UC-TEA-assign-students · the course admin assigns students to teams
Issue #41 · UC-TEA-assign-students · the course admin assigns students to teams
Maya owns all of it. She is a full-stack owner of one use case, not the team's backend person.
| Sub-issue | Branch | main after |
|---|---|---|
| #42 endpoint, service, rejection | feat/42-...-backend |
green, nothing calls it yet |
| #43 API function, the control | feat/43-...-ui |
green, an admin can do it |
| #44 end-to-end coverage | test/44-...-e2e |
green and verified |
Three reviewable merges beat one large one. Same person, sequential.
git switch -c feat/42-assign-student-backend off mainCloses #42, naming the criteria it satisfiesUC-RUB-view-rubric: one Vue call, one controller method, one service method, five tests.
One sub-issue. One branch. One hour.
Reaching for three sub-issues here is following a rule instead of thinking.
Issue, sub-issue, branch, pull request. Every link recorded, for free.
flowchart LR
R["use case<br/>in the spec"] --> I["Issue"] --> S["Sub-issue"] --> B["branch"] --> C["commits"] --> P["pull request"] --> M["merged code"]
Answerable without asking anyone:
| Column | What it actually means |
|---|---|
| Backlog | agreed to, not started. Ordered, not a pile |
| In progress | someone is working on it right now |
| Done | merged and satisfying its acceptance criteria |
| Iteration | the span you pull work into. Yours is one week |
It re-onboards itself every session. So put it in a file.
AGENTS.md the real charter, read by ~two dozen tools
CLAUDE.md one line: @AGENTS.md| File | What it carries |
|---|---|
CLAUDE.md (root) |
what the product is, how to start all three services, build and test commands, the workflow |
backend/CLAUDE.md |
Java and Spring conventions, the package map, how tests are organized |
frontend/CLAUDE.md |
Vue conventions, where the per-domain API modules live |
docs/CLAUDE.md |
the identifier schemes for the specification itself |
Conventions live next to the code they govern.
docs/team-contract.md, signed by all six. Each member commits their own signature line.
| Clause | Why it is there |
|---|---|
| Recurring weekly meeting time | the clause every other clause depends on |
| Channel, and expected response time | so "I did not see it" stops being an argument |
| How decisions get made | how you break a tie without a two-week standoff |
| How work gets claimed | so nothing is owned by everyone |
| Git workflow and review | branch naming, who reviews, what blocks a merge |
| AI usage guidelines | what you delegate, and who signs before merge |
| When someone does not deliver | agreed while nobody is angry |
Fix the meeting time first. It is the clause the others depend on.
Wednesday is where you find out who you are working with for the next eight months.