Context Engineering

A small request

"Add a createdAt timestamp to the new entity."

The agent writes:

this.artifact.setCreatedAt(LocalDateTime.now());

Nothing is wrong with that line

Except in this repository.

• Project Pulse's dev profile runs on a frozen clock: August 20, 2023, 23:30, America/Chicago
• Seeded weeks line up so a weekly activity report lands in the week the test expects
• LocalDateTime.now() bypasses all of it, silently

The only thing standing in the way

From backend/CLAUDE.md:

All time-dependent code must inject the Clock bean and use LocalDateTime.now(clock), never LocalDateTime.now().

February 2024

Air Canada's defence

The chatbot is a separate legal entity, responsible for its own actions.

The tribunal called this "a remarkable submission":

While a chatbot has an interactive component, it is still just a part of Air Canada's website.

Two lessons, and the second is ours

• You are accountable for what your agent says. Week 1 settled this.
• It was not a model failure. The right answer existed, in writing, in the same system. Nobody put it where the agent would read it.

Where we are

Week 2 ended on this

Connecting Slack gives your agent more text, not better context.

The same is true of your repository.

The window is a budget

Everything competes for the same fixed space:

• your specification
• the code it has read
• the conversation so far
• the output it is generating

How big is the budget?

As of September 2026. These move constantly.

So two things follow

Your session fills up

Claude Code compacts on its own as the window nears its limit. Copilot CLI starts at about 80%.

Two judgments, not two commands

• Compaction is lossy. A summary of your session is not your session, and it chose what to drop.
• Finished a task? /clear. Do not carry a summary of unrelated work into the next one.
• Anything that must survive does not belong in the session at all.

Agentic search

Claude Code builds no index. It runs the tools you would:

• glob to find files by pattern
• grep to find content
• read to open what looks relevant
• then repeats, because what it learned changed what it looks for

But search for what?

Watch it work

"Why does a student with no evaluations show 0.0?"

Now ask it slightly differently

The worst case is an abbreviation

Project Pulse's requirements module is the package ram/.

Ask about "requirements authoring" and the agent greps requirementsAuthoring. 0 hits.

What repairs it, one line in the root charter:

a Requirements Authoring & Management (RAM) module

Which gives you the cheapest tip in the course

Naming the file skips the search.

The alternative: it guesses a grep pattern, reads three wrong files, and arrives at the right one with your window part full and your credits part spent.

But know which situation you are in

The inversion

Context splits by lifespan

A build-context

Everything the agent needs for one unit of work, gathered in one place.

In this course: the place is the issue, the unit is one use case.

The rule

Why copying is a defect

• Paste the use case into the issue, and you now have two use cases
• One gets edited Thursday. The other does not.
• Nothing tells you which one the agent read.

Project Pulse does this to itself

From the root charter, pointing at the architecture document rather than restating it:

When the architecture changes, update that doc; the summary below is just orientation for working in the code.

What the agent actually reads

flowchart LR
    CH["Agent charter<br/>durable, read every session"] --> S(("Agent<br/>session"))
    ISS["Issue<br/>the build-context"] --> S
    ISS -. cites by ID and path .-> UC
    ISS -. names .-> CODE["Files it will touch"]
    subgraph SPEC["The specification, cited and never copied"]
        direction TB
        UC["UC-AREA-slug"]
        BR["BR-slug"]
        SRS["Quality attributes"]
    end
    UC -. Business Rules .-> BR
    UC -. Associated Information .-> SRS
    SPEC --> S
    CODE --> S

So what does the issue say in its own words?

Only the residue:

• the decision from this week's client meeting that has not reached the spec yet
• why this use case is being built before that one
• the file you already know it will have to touch

Napkin round 1: seat alerts

The Registrar wants to text students when a seat opens in a full course section they are waiting on. Last spring about 4,000 students watched at least one full section, most of them for a handful of popular MWF morning sections. The registration system is a vendor product the university cannot modify; it offers a read-only seat-count feed that can be queried at most once a minute per section. Students sign up for alerts on a new page, and whoever registers first after the text gets the seat. It has to be live for spring registration in November, and the Provost has said it will "end the refresh-button problem."

What the agent said

The agent's napkin on this brief is pasted here before class.

What the diff just showed you

Four questions the code cannot answer

• How do I run it, and what is true about this environment?
• What must I not do?
• Which precedent do I copy, when the code disagrees with itself?
• What does this word mean here, and who may do what?

1. Environment

The Clock rule from the start of the hour.

Also: the three services and their start order, the dev credentials, and the fact that dev recreates the schema on every restart while production runs Flyway migrations.

2. What must I not do

From backend/CLAUDE.md:

Extend these packages, don't fork the architecture for RAM.

3. Which precedent?

An agent imitates what it sees. Two conventions in one codebase, and it copies the nearest one, confidently.

From frontend/CLAUDE.md:

Use entity-first, PascalCase, multi-word names. NOTE: some existing pages use verb-first naming (e.g. AddActivityForm.vue, EditStudentForm.vue), these should be refactored to entity-first in the future.

4. Vocabulary and policy

The glossary fixes what a word means. The business rules fix who may do what.

Both are cited, never restated. Which is why weeks 3 and 4 insisted on them.

The question this course keeps asking

The bad answer

How thorough the prompt felt.

How long the issue is.

How confident you were.

Test 1: the questions test

Disambiguate it: ask for its assumptions before it writes any code.

Assumptions you did not supply and did not intend are your gap list.

Tell it to push back

From Project Pulse's root charter:

The spec is authoritative but not infallible. When a step is ambiguous, an assumption breaks against the existing code, or requirements contradict, ask a clarifying question or challenge the spec; don't silently comply or silently invent.

Your tool has a mode for this

Shift+Tab in Claude Code until the status bar reads plan mode on, or type /plan.

Plan mode works out what it intends to do, and shows you, before it touches a file.

Live: plan mode on Project Pulse

Copy last week's activities into this week Students retype the same activities every week. Add a button on My Activities that copies last week's activities into the current week so they only have to update the hours.

Read the plan for the right thing

When to use it: multi-step work, context you are unsure of, changes that are expensive to unpick.

When to skip it: a one-line fix, where reading the plan costs more than reading the diff.

Test 2: the diff test

Compare what it built against what you wrote. Every difference is one of two things:

Test 3: the count

A written rule leaves a trace in what gets built. So audit it.

You can be wrong in two directions

Under-specified

Plausible, and wrong.

• Wrong premise in, and the wrong thing arrives complete, tested, and expensive to reverse
• The tell: review finds nothing, because it is good code
• It answers a question you did not ask

Over-specified

• The issue dictates class names, method signatures, the order of the statements
• That is a design document, and you wrote it
• You did the expensive half and delegated the cheap half
• Nothing is left to review, because you already know what it says

The line between them

Context is earned

Week 2 told you to write the charter thin, and said it would grow.

This is how it grows.

Every rule in it is a scar

Project Pulse's backend charter, in its own margins:

It had drifted. PATCH /users/{userId} was bound to a manager that recognised only /students/, /instructors/ and /evaluations/evaluators/, so it denied every request from the day it was written.

Every cross-team defect found in September 2026 was one of the two missing: the glossary routes had neither; the document-section GET had a scoped query but no rule; the artifact and use-case lookups had a rule but no scoping.

And then it converts the lesson

Not a principle the agent can agree with. Something it can act on:

The smell to grep for: a service method that accepts Integer teamId and never mentions it in the body.

Assembled the same thing three times?

Then the assembly is worth packaging: a skill, a file that carries the steps.

Week 7, where the design and implementation gates give one something to do.

Friday studio

• Check your own week 4 work tonight; your TA already has
• Pick your riskiest use case before class; your TA reviews it with you
• The rest of the hour: finish the specification Checkpoint 1 reviews on Oct 2
• Your team's first build-context comes in week 8, just before you build. Assignment 2 is your practice run

Details: Studio, week 5

Assignment 2: Spec a feature

That is the feature

Project Pulse emails every student in the section. Nothing checks whether you already submitted.

• Nobody can see who has not submitted
• Nobody can nudge only those students
• The scheduled reminder does not skip the finished

Due Friday, October 2, moved from Sep 25. Fork tcu-cosc-40943/spec-a-feature.

Graded on your decisions and your edge cases. Not on whether anything ran.