Jean-Philippe

[Jean-Philippe @jpauclair]

The real ROI on shipping a free indie game isn't downloads. It's reviews like this:

"It's made entirely by AI. If you're getting upset about it, that's the point.

The game is... infuriating. No matter how well you do in the challenges the game throws at you, Claude could have done better. Your talent means nothing compared to an AI.

I hate it, I'm angry, I'm furious, I wish I had never let Claude even start, the choices I make trying to stop don't even matter anymore, I will still just go back to him regardless of if I say I don't want to.

And that's the point. The game should make you angry. If you are caught up on the fact that it's made by an ai, you are missing the entire meta point and story of the "dev" (Sorry, can't really call you a dev more than a storyteller)

I feel conflicted about the game, I hate it from a technical standpoint, but any good piece of media is designed to make the consumer feel emotion, and from that perspective, the game absolutely succeeds.

All in all, give it a chance. I came out of it having learned... something. Not sure what. It's an experience."

https://t.co/CEq2cQ3Fks

[Jean-Philippe @jpauclair]

@Sabrina_Ramonov The real skills are creativity and curiosity. With AI, The rest will follow

[Jean-Philippe @jpauclair]

Wow! My game distributed 5173 units in less than 24 hours!! Amazing!
You can try it on Steam: https://t.co/aOPEczkrXQ
Please share!

Think about that... 5173 x 0$ = 0,000.00$ 🤑

[Farniente Lab @FarnienteLab]

It's out. I made a free game called Meet Claude.
No budget. No team. Just unsupervised brain bubbles.
Its only goal: make you sit with the hype for a sec and see it through my eyes.
Available on Steam!
Side effects may include introspection, mild discomfort, and Googling "do I still have an original thought" at 2am. https://t.co/MbnFZKeEcR

[Jean-Philippe @jpauclair]

I made a free game called Meet Claude.
No budget. No team. Just unsupervised brain bubbles.
Its only goal: make you sit with the hype for a sec and see it through my eyes.
Side effects may include introspection, mild discomfort, humming the soundtrack for weeks, and Googling "do I still have an original thought" at 2am.
https://t.co/CEq2cQ3Fks

[Jean-Philippe @jpauclair]

And of course, close and relaunch Claude!

[Jean-Philippe @jpauclair]

Enable future unreleased features in @claudeai by Claude-Self-Patching its binary file
Here' how to enable /tag

@bcherny @trq212 When is this getting release? pretty useful stuff!

Usage: /tag <tag-name>
Tags are displayed after the branch name in /resume and can be searched with /.
So it's basically bookmarking/labeling your conversations. When you have dozens of sessions and use /resume, tags help you find them again.

To patch it, just ask Claude!

Patch Claude Code v2.1.72 to enable /tag
1. Run claude.exe --version — if not 2.1.72, STOP
2. Backup claude.exe to claude.exe.bak
3. Using Python (rb/wb), change byte 0x31 → 0x30 at these two offsets: 129259812, 225772012

[Jean-Philippe @jpauclair]

AskUserQuestion is amazing, no doubt about it. Actually, it is way more useful than people think!
When starting a feature, you don't just want the plan to ask you a few questions, you want Claude to Spam you with question until everything is clear. A few months ago, I created a small skill named /flow "whatever you are trying to make" and it changed my life, and the life of everyone I work with now.
Garbage-in -> Garbage-out.
Polished request in -> Polished results out!

Here is how I use it:
.claude/commands/flow.md
---
description: Phase-based workflow for planning and implementation with detailed requirements gathering
---

## Phase 1: Context & Requirements Gathering

If $ARGUMENTS is a file path, read it. If it's a description, use it as the starting objective.

Explore the existing codebase to understand current patterns, architecture, and conventions before asking anything.

Then interview the user using AskUserQuestion (batch 2-4 questions per call). Focus on:
- What problem this solves and for whom
- What "done" looks like in their head
- Any constraints they already know about (timeline, tech, scope)

Keep this phase to 1-2 rounds max. Get the big picture, not the details — that's Phase 2.

## Phase 2: Deep Dive Questions

Now go deeper. Ask about:
- Technical implementation: data models, APIs, state management, dependencies
- UI/UX: layout, interactions, responsive behavior, error states, empty states
- Risks: what could go wrong, what's fragile, what's hard to change later
- Tradeoffs: performance vs simplicity, flexibility vs speed, build vs buy

Rules:
- Batch 2-4 questions per AskUserQuestion call
- Don't ask obvious questions — reference what you already learned from the codebase
- Propose options where possible instead of open-ended questions ("Should we use A or B?" not "How should we do this?")
- Stop after 3-4 rounds, or when the user says to move on
- Summarize what you've learned before proceeding

## Phase 3: Specification Document

Write a spec file to `.claude/specs/{feature-name}.md` with this structure:

```
# {Feature Name} — Spec

## Objective
One sentence.

## Goals
- ...

## Non-Goals
- What this does NOT cover (important for scope control)

## Requirements
- Numbered list of concrete requirements

## Constraints & Assumptions
- Tech constraints, browser support, existing patterns to follow

## UX Behavior
- User flows, interactions, states (loading, empty, error, success)

## Technical Approach
- Architecture, data flow, key files to modify/create
- Reference existing codebase patterns

## Edge Cases
- ...

## Acceptance Criteria
- Testable checklist of what "done" means
```

After writing, show the user a summary and confirm before moving to Phase 4.

## Phase 4: Planning

Enter plan mode. Build the plan directly from the spec file — reference it explicitly.

The plan should:
- List concrete steps with file paths
- Group work into logical chunks (e.g., data layer first, then UI, then integration)
- Identify dependencies between steps
- Flag anything that needs user input during implementation

Wait for user approval before proceeding.

## Phase 5: Implementation

Execute the plan step by step. For each step:
- Mark progress (use task tracking if the plan has 4+ steps)
- Test as you go — run existing tests, write new ones if acceptance criteria require it
- If you hit an ambiguity not covered by the spec, ask the user — don't assume

Do not stop until all acceptance criteria from the spec are met.

When done, give a summary of what was built, what was tested, and any follow-up items.

[Jean-Philippe @jpauclair]

Claude Code agents have a batching problem.

You say: "split into small batches"
Claude hears: "group everything, launch concurrent agents, hit rate limits, burn tokens, lose progress"

The fix isn't complicated:
— save often
— actually split small
— design tasks to lose as little as possible when things go sideways

Task overhead is also real and unclear. A lighter, more resilient primitive would be a genuine quick win for @AnthropicAI / @bcherny

Who else is working around this?

[Jean-Philippe @jpauclair]

@akhileshutup You learn AI Skills or AI learn your skills?
either way... same here

[Jean-Philippe @jpauclair]

Less How. More Why
The hardest part of AI coding agents isn't the tooling. It's that your expertise becomes a liability the moment you use it to micromanage instead of evaluate.
Senior devs hit this wall first. And hardest.

Every time you dictate exact steps, you cap the output at your own solution. You get something technically fine but potentially architecturally worse than what it would've found with room to breathe.

But the fix isn't "hands off entirely." That's its own failure mode! Wrong direction, burned context, wasted cycles.
The actual skill is knowing when to intervene. Not reacting to every move. Not ignoring it until the end. Catching the moment the output stops fitting the goal.
Define the outcome. Let it run. React to results, not process.

You're not the coder anymore. You're the one who knows what good looks like. That's harder to learn than any framework... because it means trusting a process you didn't control, and because you're finally doing less how and more why

[Jean-Philippe @jpauclair]

I let an AI agent mass iterate autonomously for 3 days on a problem with zero documentation, multiple SDKs, and very deep technical skill requirements. 90 builds. As a developer, here's what i learned. the secret isn't the AI, it's the system around it.

three things made it actually work:

1. A tracking doc the agent reads on every pass. every build logs what changed, what broke, what to try next. Context compaction will eat your progress. This is how you survive it. No repeated dead ends, No rediscovered hypotheses.

2. A custom skill that runs the full loop autonomously. Read crash logs -> establish hypothesis -> make one change -> build -> deploy -> auto-play -> read errors -> log results -> repeat. (Each full loop takes multiple hours). One command, fully hands-off. it loops while you sleep.

3. One change per build. Sounds obvious but the agent will want to batch fixes. Don't let it. 56 builds here hit the exact same crash. each one ruled something out until only the answer remained.

The AI is fast. but without this system it just spins in circles every new session. Give it memory and structure and it becomes a different thing entirely.

[Jean-Philippe @jpauclair]

For the @claudeai fans out there.

A few months ago I was frustrated. Claude kept building the wrong thing... Not because it was bad, but because I was unclear. Garbage in, garbage out. "Plan" mode helped. But it wasn't enough.

So I built /flow : a command that interviews you before touching a single line of code.

Phase 1: understand the problem.
Phase 2: go deeper.
Phase 3: write a spec.
Phase 4: plan.
Phase 5: build.

@bcherny — the prompt is below. Try it; Steal it.

.claude/commands/flow.md
---
description: Phase-based workflow for planning and implementation with detailed requirements gathering
---

## Phase 1: Context & Requirements Gathering

If $ARGUMENTS is a file path, read it. If it's a description, use it as the starting objective.

Explore the existing codebase to understand current patterns, architecture, and conventions before asking anything.

Then interview the user using AskUserQuestion (batch 2-4 questions per call). Focus on:
- What problem this solves and for whom
- What "done" looks like in their head
- Any constraints they already know about (timeline, tech, scope)

Keep this phase to 1-2 rounds max. Get the big picture, not the details — that's Phase 2.

## Phase 2: Deep Dive Questions

Now go deeper. Ask about:
- Technical implementation: data models, APIs, state management, dependencies
- UI/UX: layout, interactions, responsive behavior, error states, empty states
- Risks: what could go wrong, what's fragile, what's hard to change later
- Tradeoffs: performance vs simplicity, flexibility vs speed, build vs buy

Rules:
- Batch 2-4 questions per AskUserQuestion call
- Don't ask obvious questions — reference what you already learned from the codebase
- Propose options where possible instead of open-ended questions ("Should we use A or B?" not "How should we do this?")
- Summarize what you've learned before proceeding

## Phase 3: Specification Document

Write a spec file to `.claude/specs/{feature-name}.md` with this structure:

```
# {Feature Name} — Spec

## Objective
One sentence.

## Goals
- ...

## Non-Goals
- What this does NOT cover (important for scope control)

## Requirements
- Numbered list of concrete requirements

## Constraints & Assumptions
- Tech constraints, browser support, existing patterns to follow

## UX Behavior
- User flows, interactions, states (loading, empty, error, success)

## Technical Approach
- Architecture, data flow, key files to modify/create
- Reference existing codebase patterns

## Edge Cases
- ...

## Acceptance Criteria
- Testable checklist of what "done" means
```

After writing, show the user a summary and confirm before moving to Phase 4.

## Phase 4: Planning

Enter plan mode. Build the plan directly from the spec file — reference it explicitly.

The plan should:
- List concrete steps with file paths
- Group work into logical chunks (e.g., data layer first, then UI, then integration)
- Identify dependencies between steps
- Flag anything that needs user input during implementation

Wait for user approval before proceeding.

## Phase 5: Implementation

Execute the plan step by step. For each step:
- Mark progress (use task tracking if the plan has 4+ steps)
- Test as you go — run existing tests, write new ones if acceptance criteria require it
- If you hit an ambiguity not covered by the spec, ask the user — don't assume

Do not stop until all acceptance criteria from the spec are met.

When done, give a summary of what was built, what was tested, and any follow-up items.

[Jean-Philippe @jpauclair]

I mass-produced dozens of personal projects and prototypes this year. Without writing a single line of code myself.
And I'm not sure if I feel more excited or terrified.

Let me explain.

More than a year since my last post. I've been deep in the AI rabbit hole. Agentic systems, Mass deleguating my ideas, and my voice. Rethinking what it even means "to code," questioning what I am as a programmer.

I took a sabbatical (or a few) from coding. But this past year? I felt like I did back when I had my blog. Hyper-Active. Doped on ambition. Feeling limitless.

The shift happened by having the tools and understanding to NOT have to code... yet spending more time building than ever. Dozens of personal projects in almost no time. My creativity, which felt dormant for a while, is now exploding. Mixed with opportunity at every corner.

And it takes energy. Way more than I expected. I went from being discouraged to even start a project, to developing multiple projects in parallel. Literally at the same time.

But if I'm being real? Part of me wants to keep pushing, ride this wave as far as it goes. The other part is wondering if I should hit the brakes before I burn out or lose myself in all of it.

I honestly don't know which voice to listen to right now.

What a time to be alive. (Can't read this without hearing @twominutepapers 🤣)

Honestly, where are you at with AI right now?

[Jean-Philippe @jpauclair]

@Ashcryptoreal "Do you know what would happen if I suddenly decided to stop going into work?
A business big enough that it could be listed on the NASDAQ goes belly up.

I am not in danger,
A guy opens his door and gets shot, and you think that of me?
No. I am the one who knocks!"

[Jean-Philippe @jpauclair]

ChatGPT is returning garbage right now.. I wonder if it is all part of other people requests mixed together....

[Jean-Philippe @jpauclair]

"Prendre la vie comme elle vient, c'est l'accepter avec tout son désordre."
— Geneviève Pelletier

[Jean-Philippe @jpauclair]

Curious about how #BerylHurricane is impacting flights? Here's what you need to know! ✈️🌪️ #TravelUpdate #FlightStatus

[Jean-Philippe @jpauclair]

@WatcherGuru Feels like an equivalent to banning transaction of more than 3000$ in cash. No? Is that a thing?

[Jean-Philippe @jpauclair]

@nayibbukele Have you considered the risks of sharing this Bitcoin public address openly? What if someone sends funds linked to illegal activities to that wallet, inadvertently mixing questionable assets with your legitimate ones? Could this pose a risk to your financial reputation?