The Week I Stopped Trusting Discipline

Seventy-seven Claude sessions. Twenty on Sunday alone. And by the end of the week, I'd built something that might sound mundane—a CLI for logging career wins—but that forced me to confront a belief I'd held for years: that good systems require good habits.

They don't. Let me explain.

---

The Discipline Trap

Most productivity advice has a dirty secret: it assumes you'll keep showing up. Keep a running log. Do a weekly review. Track your wins. All reasonable advice. All requiring sustained behavior you probably won't sustain.

Six months into a consulting engagement, I had the receipts to prove it. Dozens of decisions I'd influenced. Stakeholder quotes that would make perfect resume bullets. Coaching wins I'd completely forgotten about. The problem wasn't that I hadn't done good work. The problem was that when resume time came, I couldn't remember half of it.

The obvious solution: be more disciplined about logging things.

But I've tried that. You've tried that. It works for three weeks, maybe four if you're motivated. Then life happens, you skip a day, and the system dies from neglect.

So I asked a different question: What if the system required zero discipline?

Impact Tracking Without Willpower

The result is about 750 lines of code with no dependencies:

```bash impact decision --before "no framework" --after "process behavior charts" --basis "distinguished signal from noise" impact quote "this changes everything" --person "Stakeholder" --context "after demo" impact coaching --topic "research methods" --evidence "created interview guide" ```

That's it. Three words and some flags. Events queue to a hidden directory. Every Friday at 5pm, a background process I never have to think about rolls them into a weekly markdown log and syncs to Roam.

If I skip Monday, nothing breaks. If I forget for three days straight, the Friday aggregation catches everything anyway. The system works because it doesn't require consistency, not in spite of it.

Here's what the weekly rollup looks like:

``` WEEK 2026-W05 IMPACT SUMMARY ────────────────────────────

DECISIONS (4) ├─ Process behavior charts for metrics analysis ├─ Hybrid retrieval over pure FTS for memory search ├─ Client-side only architecture for Keyframe └─ GPT-4o over DALL-E 3 for photorealism (87% vs 62%)

QUOTES (2) ├─ "this changes everything" — Stakeholder └─ "finally, metrics I can trust" — PM ```

The insight isn't about productivity tools. It's about system design: you can't engineer discipline, but you can engineer away the friction that discipline was supposed to overcome.

---

Turning Pitch Decks into Storyboards

Meanwhile, I shipped the MVP for a side project that's been brewing for months: Keyframe.

The pitch is simple. You describe a scene in ChatGPT. It generates a photorealistic image. The app stores it in a storyboard frame. Repeat until you have a visual pitch deck—without touching Figma, Photoshop, or hiring an illustrator.

Most of this week's work was infrastructure. Getting the MCP server deployed to Railway (which required fixing the Dockerfile to include dev dependencies for TypeScript compilation). Adding support for data URIs since ChatGPT returns images as base64, not URLs. Designing a logo that combines a key with a picture frame.

But the interesting decision was architectural: client-side only.

```mermaid flowchart LR subgraph ChatGPT["ChatGPT"] A[User describes scene] B[GPT-4o generates image] end subgraph MCP["MCP Server"] C[Store frame state] D[Manage storyboard] end A --> B B --> C C --> D D -.-> A ```

ChatGPT handles image generation. The MCP server just stores state. No backend costs. No API keys for users to manage. The cognitive load stays low because I pushed all the expensive work to someone else's infrastructure.

Oh, and I ran a model evaluation: GPT-4o vs DALL-E 3 for photorealism. GPT-4o won decisively—87% vs 62% on visual coherence ratings. So that's the default now.

---

Teaching an AI to Remember

Here's a problem that sounds simple until you try to solve it: how do you search hundreds of documents for concepts, not just keywords?

My `/diary` command generates a markdown file for every Claude session. Useful for continuity. Terrible for retrieval. Full-text search worked, but it missed conceptual matches. Searching "authentication" wouldn't find a session about "login flow security."

The fix was adding QMD, a local vector search tool, with hybrid retrieval: BM25 for keywords, vector embeddings for concepts, and a reranker to merge results.

Technical details for the curious:

• PostToolUse hook triggers `qmd update` after every `/diary` run
• Local GGUF models via Bun for embeddings
• Three collections: diary entries, patterns, rules
• No cloud dependencies—everything runs locally

Now when I search for "authentication," I get sessions about login flows, security reviews, and credential management. The AI finally remembers what it talked about.

---

The Leaderboard Trick

Client work this week had a recurring theme: small experiments that punch above their weight.

Take the leaderboard prototype. The client's product had a delivery tracking table buried in an admin screen. Nobody used it. The data was there, but the context was wrong—admin screens feel like obligations, not opportunities.

So I pulled that same data and turned it into a live leaderboard. Fake competition between shipping hubs. Animated rank changes. The kind of thing that would take two sprints to ship through a normal roadmap process.

What happened next was predictable in retrospect: users started checking it. Comparing numbers. Asking about their rank. Suddenly I had tighter relationships with people who'd never looked at the admin panel.

That kind of engagement doesn't come from features on the roadmap. It comes from small, fast experiments that make work feel like a game.

The leaderboard worked for the same reason my impact tracker works: it required no behavior change from users. They didn't "decide to engage." The engagement happened because I put the data where they were already looking.

Remove friction. Don't require discipline.

---

Process Behavior Charts Changed How I Read Metrics

One more client project worth mentioning: an analytics deep dive using XmR methodology.

XmR is Donald Wheeler's approach to process behavior charts. The core idea is distinguishing signal (something actually changed) from noise (normal variation that looks alarming).

The insight that changed my approach: a 41% session error rate looked alarming in isolation. Stakeholders were worried. The natural response is to investigate, assign resources, maybe file a bug.

But when I ran the XmR analysis, it showed routine variation. Not a special cause. Not something that needed fixing. Just the system behaving normally.

Without this framework, I would have wasted cycles chasing noise. With it, I could confidently tell stakeholders: "This isn't a problem. It's just how the system works."

(Also figured out that the right Datadog field was `@action.target.name`, not `@action.name`. Small discovery. Hours of debugging.)

---

The Recipes

Unrelated to everything above: I built a workflow for turning recipe PDFs into queryable markdown files.

I subscribe to a meal kit service that sends weekly recipes as PDFs. Useful for cooking. Useless for adapting, combining, or searching.

The solution was extracting them to markdown with YAML frontmatter:

```yaml ingredients:

• item: chicken thighs amount: 2 unit: lbs prep: quick-brined components:
• braising-sauce
• side-salad ```

Created 11 recipe files this week: 5 main dishes, 6 components. Then made an Instant Pot adaptation with full mise en place for someone who hadn't done any prep.

Meal planning is now a search problem. I like search problems.

---

By the Numbers

The pattern tells a story. Sunday was the heaviest day—20 sessions of infrastructure building. Impact CLI, QMD integration, Keyframe deployment. By midweek, I'd shifted to client work and writing. Thursday and Friday were rest days.

It's the inverse of a typical work week. Front-load the building. Let momentum carry you through delivery. Rest when the creative energy runs out, not when the calendar says to.

Notable wins:

• Impact Tracking CLI: 20 minutes from spec to production
• Keyframe MCP deploy: Railway build failures → Dockerfile fixes → working deploy
• Recipe extraction: PDF → 11 structured files in one session

---

What I'm Taking Forward

The throughline this week was a single question: how do you build systems that work even when you're inconsistent?

The impact tracker answers it with zero-friction capture and automated aggregation. The leaderboard answers it by putting engagement where users already look. QMD answers it by making search work the way humans think, not the way files are named.

Discipline is overrated. Friction is underrated.

Engineer away the friction, and the discipline stops mattering.