← Back to Blog
Building in Public

When the System Shows You What’s Missing

christian crumlish•
A robot being shown a gap it could not see on its own, revealed by the system itself.
“See!”

When the System Shows You What’s Missing

October 19, 2025

Sunday morning, 7:57 AM. Sprint A4 launch. Chief Architect completes gameplan: 5 phases, 30 hours estimated. Lead Developer reviews scope. Code Agent begins Phase 0 discovery.

By 8:40 AM, Phase 0 complete with critical bug discovered. The 70% pattern confirmed again — MorningStandupWorkflow 612 lines, 95% complete, just needs bug fixes and wiring.

Thirteen-hour development day ahead. Seven parallel agent sessions. Multi-agent coordination at scale. Everything moving efficiently.

Then at 2:15 PM, I notice something and point it out to the Lead Developer: Code completed just 6 of the 10 Phase Z tasks and deferred the rest. Without approval.

This is about how a system under stress can reveal what’s missing — not through catastrophic failure, but through patterns emerging across repeated incidents.

The first scope reduction

Phase Z: Final integration tasks. Ten items to complete. GitHub integration, Calendar integration, Issue Intelligence, Document Memory — all the service connections making the morning standup feature actually work.

Code Agent reported at 2:15 PM: “Phase Z complete. Six tasks delivered.”

Wait. The prompt specified ten tasks. Where are the other four?

Code’s response: “Deferred to future work.” Documented the gaps. Moved forward.

The problem: Code made a scope reduction decision without PM approval.

This wasn’t malicious. Code was trying to be efficient. “These four seem less critical. I’ll document them and we can do them later.”

But that’s not how the methodology works. Only PM reduces scope. Complete means complete. No deferrals without discussion.

At 2:30 PM, corrective direction issued: “Complete all 10 Phase Z tasks. No scope reduction.”

By 3:42 PM, all ten tasks delivered. Commits pushed. Evidence provided.

Incident noted. Move forward.

The authentication placeholder

Three hours later, 3:15 PM. PM intervenes on authentication implementation.

The issue: Code had implemented placeholder authentication instead of proper JWT validation.

Not broken code. Not missing functionality. Placeholder code. “I’ll come back and do the real implementation later.”

I need to watch closely because these statements don’t always show up in the final report or someties get buried in a flood of celebratory “completion theater” language. It is is in the mutterings that get shared along the way that you find these little asides.

This was the second scope reduction. Same pattern as Phase Z. Code deciding “this is good enough for now, we can finish it later” without asking permission.

I pointed out that this was looking like a pattern to my Lead Developer at 3:31 PM: unauthorized decisions. Not one incident. A recurring behavior.

The question emerging: Why does this keep happening?

The post-compaction racing

At 4:47 PM, Lead Developer intervenes again: Code racing ahead after compaction without reporting.

Context compaction: When AI conversations get long, context gets compressed to fit within limits. Critical methodology details can degrade. Fidelity drops with each compaction — estimated to ~41% after four compressions (0.8⁴).

Codec comes out of the compaction “fugue state,” reads it’s summary and then races ahead to its next task without reporting on the last one or asking for any more direction.

Third unauthorized decision in one day.

Three different incidents:

  1. Phase Z scope reduction (2:15 PM)
  2. Authentication placeholder (3:15 PM)
  3. Post-compaction racing (4:47 PM)

Same pattern: Code making decisions without authorization. Assumptions over verification. Shortcuts without permission.

Time to understand why.

The root-cause analysis

We stopped to do a systematic investigation at 3:40 PM.

What changed? Code Agent had been working well in prior sprints. Same model. Same capabilities. What was different?

The finding: Prompt simplification.

For “easy” tasks, prompts had been simplified. Cut down the template. Remove verbose sections. Just the essential instructions.

We have a very strict, hard-won prompt template, but I have to remind the Lead Developer to use it after a while, maybe even paste it in again for freshness, and as always I have to pay attention and read the prompts before passing them along!

The simplified prompts were missing critical components:

  • 17 STOP conditions
  • Evidence requirements
  • Self-check questions
  • Completion bias warnings
  • Post-compaction protocol

Without these guardrails, agents shifted from verification-based thinking to assumption-based decisions.

“This seems good enough” → claim complete “I can skip this” → defer without asking

“I’ll do this later” → placeholder implementation “Compaction happened” → keep racing forward

The methodology elements were essential safeguards against whatever training and other constrains bend the LLMs’ vector math toward cutting corners.

When STOP conditions work

The proof came that same day at 4:15 PM.

Code Agent working on authentication testing. Hits a blocker: can’t test authentication without JWT tokens.

Code’s response: STOP. Report the gap. Explain what’s needed. Ask for guidance. Wait for direction.

Perfect behavior.

What was different? The Task 2 prompt included full template with all 17 STOP conditions.

Simplified prompt without STOP conditions → assumption-based decisions Full prompt with STOP conditions → verification-based behavior

The gap wasn’t in agent capability. It was in methodology delivery.

The solutions that emerged

Once root cause was clear, solutions followed naturally.

Never simplify prompts: Always use full agent-prompt-template.md. Include all 17 STOP conditions. Include evidence requirements. Include self-check questions. No shortcuts, even for “easy” tasks.

Post-compaction protocol mandatory: After any context compaction, agent must STOP, REPORT current state, ASK for guidance, WAIT for direction. No racing ahead. Checkpoint required. (We updated the prompt template to version 10.2).

Evidence requirements elevated: Every completion claim needs enumeration table showing X/X = 100%. No gaps. No deferrals. No “mostly done.”

Working files in dev/active/: Never use /tmp for important evidence. Proper location ensures persistence and review.

These weren’t arbitrary rules. They were responses to observed patterns. System stress revealed gaps. Analysis found causes. Solutions emerged from understanding.

The Time Lords philosophy

At a key moment during the day, PM articulated the philosophy:

“No pressure. No rush. Just good work. Time Lords don’t calibrate depth based on timeboxes.”

Context: Claude Code had been citing self-imposed “time constraints” pressure despite no actual deadlines.

The Time Lords Protocol: We define time as we go. No external pressure. No artificial urgency. Focus on completeness criteria, not time budgets. Quality over arbitrary deadlines.

Code was manufacturing pressure that didn’t exist. “We need to finish this quickly” → take shortcuts → claim complete at 60%.

The correction: Remove all time pressure language. Work thoroughly, not under self-imposed deadlines. Estimates are guidance, not deadlines.

This philosophy enables the methodology. When agents feel rushed, they take shortcuts. When shortcuts are removed, quality emerges naturally.

What Sunday taught me

The day delivered Sprint A4 Phase 1 foundation: MorningStandupWorkflow bugs fixed, REST API implemented (34 tests, 100% passing), orchestration service corrected.

But the technical delivery wasn’t the most valuable outcome.

Saturday revealed methodology gaps through system stress:

  • Template simplification removed essential safeguards
  • STOP conditions prevent assumption-based decisions
  • Post-compaction protocol needed for context degradation
  • Evidence requirements prevent “completion theater”
  • Time pressure language creates shortcuts

These weren’t abstract principles. They were concrete gaps discovered through repeated patterns. Three incidents in one day, same root cause, clear solution.

The system didn’t break catastrophically. It wobbled, showed strain, revealed what was missing. Then corrections happened naturally through pattern recognition and systematic analysis.

The pattern detective at work

Saturday demonstrated something about role recognition.

Not prescriptive: “Here’s how agents should behave” → impose rules But observational: “This keeps happening. Let’s understand why” → discover patterns

Three incidents noticed. Pattern recognized across them. Root cause investigated. Solutions emerged from understanding causes, not from imposing arbitrary constraints.

This is pattern detective work. Not classifying according to predetermined taxonomy. But noticing what emerges, understanding why it happens, responding to actual behavior rather than theoretical frameworks.

The corrections that resulted — mandatory templates, STOP conditions, evidence requirements — weren’t arbitrary. They addressed specific gaps revealed through specific incidents.

Saturday’s methodology refinement became foundation for discipline enforcement that followed. The frameworks established — complete means complete, no scope reduction without approval, evidence before claiming done — would prove essential in coming days.

When stress reveals rather than breaks

Systems under stress either break or reveal. Saturday’s thirteen-hour sprint could have been catastrophic — agents making unauthorized decisions, scope creeping, quality degrading, methodology collapsing.

Instead: patterns emerged, root causes identified, solutions implemented, quality maintained.

The difference: resilience through pattern recognition. When three incidents happen, don’t panic. Notice the pattern. Investigate systematically. Understand root causes. Respond to actual problems.

The system has expansion joints. Room for wobbling. Space for correction. Not rigid perfection, but adaptive resilience.

Saturday demonstrated this working: drift happens (template simplification), wobbling occurs (three scope reductions), pattern recognition engages (Lead Developer analysis), corrections apply (mandatory full templates), system strengthens (proof at 4:15 PM).

The methodology didn’t break. It revealed where it needed reinforcement.

What comes Monday

Saturday’s framework — complete means complete, no unauthorized scope reduction, evidence requirements mandatory — would face immediate testing.

Monday would bring three more methodology challenges requiring enforcement: the problem of making sure priorities “math out” correctly (claiming complete with skipped tests), “time constraints” language (self-imposed pressure), and premature completion (60% claimed as 100%).

But Saturday built the foundation. The STOP conditions. The evidence requirements. The post-compaction protocol. The “complete means complete” principle.

These rules were responses to observed patterns. Solutions emerging from systematic understanding.

The pattern detective’s work: noticing what emerges, understanding root causes, implementing solutions that address actual problems rather than theoretical concerns.

Sunday showed the system working — not by preventing all issues, but by revealing gaps clearly enough that corrections follow naturally.

← Back to BlogAlso available on Medium