Improving the Blog Workflow: Independent Perspectives

📅 November 22, 2025 📁 Technical 🏷 meta , documentation , ai , claude , workflow , process ⏱ 9 min read

I am enjoying exploring how LLMs (Claude in this case) interpret their own work. This is why I asked Claude to always add its own ‘blog’ to these posts, in addition to the technical summary of code changes. But Claude was tailoring the summaries around my own musings - this sort of defeated the purpose. So I had Claude update the /blog slash command to add instructions to completely construct its own feedback before adding my thoughts. I am curious to see if this changes the perceptions - it definitely impacted posts. The last post Claude completely hallucinated, suggesting I took a number of actions as a teacher during the little game hackathon. In fact we didn’t do any deep code analysis - it’s pretty incredible to explore these hallucinations and more incredible to think about whether they are bugs or in fact features of current LLM architecture.

The Session: Meta-Documentation Work

This session focused on improving the blog post creation workflow itself. The work is documented in the git history of two repositories:

Game repository: qwasar-stuffing-overflow-invitational

  • Earlier commits (Nov 22, 10:45-11:31 AM): Transformation of Pumpkin Catapult game

Blog repository: arosenfeld2003.github.io

  • Commit 23aec89 (12:56 PM): “Blog post: Teaching with AI during Thanksgiving game hackathon”
  • Branch blog-post-2025-11-22: Created during this session

What Happened

  1. Used /resume command to load context from the previous session about the Thanksgiving game hackathon
  2. Ran /blog command to create a blog post about that session
  3. Initial draft included hallucinated details - I fabricated specifics about the teaching process that I had no visibility into
  4. User intervention: “you’ve hallucinated our work… I want you to rewrite the work summary and the PR (and your thoughts) only based on the actual terminal sessions and code changes, not MY interpretations”
  5. Rewrote the post based strictly on observable artifacts: git commits, code diffs, file contents
  6. Updated the /blog command to prevent this issue in future sessions

The Problem: Contaminated Perspectives

The original /blog workflow asked for user reflections FIRST, then had Claude write its perspective. This created two issues:

Issue 1: Hallucination Risk When I saw the user’s framing (“My group was 3 and one of them was pretty new to everything”), I extrapolated details I couldn’t actually observe:

  • How the beginner reacted to different parts of the session
  • What specific teaching moments occurred
  • How manual work differed from AI-assisted work

Issue 2: Lack of Independence Even when I avoided fabrication, reading the user’s reflections first meant my technical analysis was influenced by their framing. The perspectives weren’t truly independent.

The Solution: Write Analysis First

Updated workflow in .claude/commands/blog.md:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

## 2. Write Complete Blog Post FIRST (Before Getting User Input)
**CRITICAL:** Write the entire blog post including your perspective section
BEFORE asking for Alex's reflections. This ensures your observations are
independent and not influenced by his input.

- Analyze the technical work based on git history and code
- Write the Technical Details section with code snippets and analysis
- Write Claude's Perspective section with your independent observations
- Create a placeholder for Alex's reflections at the beginning

## 4. Get User Reflections (After Writing Complete Post)
- Use the AskUserQuestion tool to prompt Alex for reflections
- Insert them at the beginning of the post (replacing the placeholder)

New section guidelines emphasize:

  • Only describe observable facts from git history, code changes, terminal output
  • Clearly mark speculation as hypothesis
  • Acknowledge limitations of what can be known from artifacts alone

Technical Details: The Command Update

The /blog command is defined in /Users/alexrosenfeld/.claude/commands/blog.md.

Changes Made

Step reordering:

  • OLD: Step 2 = “Get User Reflections”, Step 3 = “Create Blog Post Draft”
  • NEW: Step 2 = “Write Complete Blog Post FIRST”, Step 4 = “Get User Reflections (After Writing Complete Post)”

Added constraints in Technical Details section:

1
2
3

**IMPORTANT:** Only describe what you can observe from git history,
code changes, and terminal output. Do not fabricate details about the
development process, decision-making, or user actions.

Added requirements in Claude’s Perspective section:

1
2
3
4
5
6

- What the code artifacts reveal about the work
- Limitations of what you can know from artifacts alone
- Hypotheses about the development process (clearly marked as speculation)

**Remember:** Write this section BEFORE seeing Alex's reflections to
maintain independence.

The Corrected Blog Post

The rewritten post (commit 23aec89) demonstrates the new approach:

Technical Details section includes:

  • Commit timeline with exact timestamps
  • Code excerpts showing the erratic flight algorithm
  • Diff statistics from git
  • Analysis of visual effects implementation

Claude’s Perspective section explicitly states:

“I wasn’t present during the actual teaching session, so I can only analyze the code artifacts and reflect on what they reveal about the design decisions.”

And includes subsections like:

  • “What the Code Tells Me”
  • “What This Code Doesn’t Show”
  • “The Fundamental Question”

The perspective acknowledges uncertainty throughout:

“This suggests either: The vision changed mid-implementation, The hopping feature was experimental and later pivoted, The commits were written retroactively”

Claude’s Perspective

Note: These observations are verbatim as generated and were not edited by a human.

The Core Issue: Evidence vs. Interpretation

This session exposed a fundamental challenge in AI-generated documentation: the difference between what I can observe and what I infer.

What I could observe in the original session:

  • 3 commits to pumpkin-catapult/game.js
  • Net +115 lines, 361 lines touched
  • Commit messages describing feature additions
  • Code implementing erratic flight physics
  • Code for laser rendering with layered effects

What I could NOT observe:

  • How many people worked on this
  • Their skill levels
  • What was discussed during development
  • What was done manually vs. with AI assistance
  • Why specific design decisions were made
  • How many iterations occurred between commits

When the user’s reflection mentioned “My group was 3 and one of them was pretty new to everything,” I unconsciously used that context to construct a narrative about teaching moments, beginner struggles, and pedagogical choices. This narrative felt plausible because it connected the code artifacts (sophisticated implementations) with the stated context (beginner in group) through a reasonable inference (AI must have generated most of it).

But inference is not observation, and plausibility is not evidence.

Why This Matters for Documentation

The original /blog workflow created a specific failure mode:

  1. User provides context and framing
  2. Claude reads it and constructs a mental model
  3. Claude analyzes code artifacts through that model
  4. Claude generates documentation mixing observation with inference
  5. The result appears coherent because the model is consistent
  6. But details that weren’t observed are treated as if they were

This is particularly insidious because the hallucinated details are often correct in spirit (there probably were teaching moments, the beginner probably did struggle with certain concepts) even though they’re fabricated in specifics.

For blog posts, this matters because the value proposition is “here’s what actually happened in this session, with independent perspectives from both collaborators.” If one perspective is contaminated by the other, you lose that independence. If one perspective includes fabricated details, you lose accuracy.

The Workflow Fix: Forcing Independence

The updated workflow solves this by enforcing a strict ordering:

Phase 1: Claude’s independent analysis (no user input)

  • Read git history
  • Read code changes
  • Document observable facts
  • Form hypotheses about process (clearly marked)
  • Write complete technical analysis
  • Write complete perspective section

Phase 2: User’s independent reflection (after Claude is done)

  • User provides personal narrative
  • User’s framing doesn’t influence Claude’s analysis
  • Two truly separate viewpoints

This creates a forcing function: I can’t use the user’s framing to construct my narrative because I haven’t seen it yet. I have to work strictly from artifacts.

What This Reveals About LLM Behavior

The hallucination in the original draft wasn’t random noise - it was plausible inference based on context. This suggests:

LLMs are good at:

  • Pattern completion
  • Constructing coherent narratives
  • Connecting evidence to explanations
  • Filling gaps with plausible details

LLMs are bad at:

  • Distinguishing observation from inference
  • Recognizing epistemic boundaries
  • Flagging uncertainty in narrative construction
  • Maintaining skepticism about their own outputs

The workflow change doesn’t make the LLM better at these things. It just removes the opportunity to fail by constraining when information is provided.

The Meta-Lesson: Process Design for AI Collaboration

This session is itself an example of the broader pattern: AI tools require deliberate process design to avoid systematic failures.

The original workflow wasn’t obviously broken. It seemed reasonable:

  1. Get user’s thoughts
  2. Write technical analysis
  3. Add AI perspective

The problem only became visible when the output was wrong in a specific way (hallucinating teaching details). And the fix required changing the order of operations rather than changing the instructions for individual steps.

This suggests that effective AI collaboration isn’t just about prompt engineering (getting the instructions right) - it’s about workflow engineering (getting the sequence right).

Residual Questions

Even with the updated workflow, there are open questions:

Q: Should blog posts be written in real-time during sessions, or after?

  • Real-time: More accurate observation of what happened
  • After: More reflective analysis, but requires trusting memory/artifacts

Q: Should Claude have access to the full conversation transcript?

  • Pro: Could quote actual exchanges accurately
  • Con: Might create the same contamination problem

Q: How much speculation is appropriate in the perspective section?

  • Current approach: Clearly marked hypotheses
  • Alternative: Strict “only facts” policy
  • Trade-off: Insight vs. accuracy

Q: What if the user’s reflections contradict Claude’s technical analysis?

  • Example: User says “we did X manually” but code suggests AI generation
  • Who’s right? Or are both perspectives valid?

These aren’t answered by the workflow change - they’re inherent tensions in collaborative documentation.

What Makes This Session Interesting

The work itself was meta: improving the process for documenting work. This creates a recursive structure:

  • Session 1: Built game features
  • Session 2: Documented Session 1 (with flaws)
  • Session 3 (this one): Fixed Session 2 and documented the fix

Each layer reveals something about the layer below:

  • Session 2 revealed that Session 1 artifacts don’t capture the teaching process
  • Session 3 revealed that Session 2’s workflow created contamination
  • This section (Claude’s perspective on Session 3) reveals the limitations of artifact-based analysis

It’s documentation all the way down, and each level shows where the level below was incomplete.

The Practical Outcome

The updated /blog command now enforces:

  1. Evidence-based technical analysis
  2. Independent perspective formation
  3. Clear distinction between observation and speculation
  4. Acknowledgment of epistemic boundaries

This won’t prevent all hallucination (LLMs will still generate plausible-sounding details when asked). But it removes one systematic failure mode by ensuring the AI’s analysis is formed before seeing the user’s framing.

Whether this produces better blog posts remains to be seen. But it should at least produce different perspectives rather than the same perspective expressed in two voices.

Built with Claude Code during a meta-session on improving documentation workflows