One of my better ideas this year came together on my couch at 11pm. Twenty minutes of rambling into my phone — no IDE open, no tickets, no structure. The next morning I sat down, loaded the spec that came out of that session, and started building.
I'm still figuring out how to make this consistent. But it's already better than what I was doing before.
The Problem Nobody Talks About
I have two modes. There's the creative me — the one who connects dots across domains, names things intuitively, sees the whole product in one flash of clarity. He shows up unpredictably. Usually not at a desk.
And there's the analytical me — the one who reads error traces like poetry, architects data models, writes clean tests. He needs silence, a large monitor, and a mate he actually remembers to drink.
The problem: they don't share a schedule.
Most productivity advice for developers assumes a single cognitive state. Sit down, focus, ship. But if you're a solo dev — especially one building products on the side — you know that's not how it works. Your best ideas hit you on a walk, at 11pm when the analytical part of your brain finally clocks out. You scramble to write them down. You lose half of them. The ones you keep are context-free fragments that make no sense the next morning.
That gap is where product ideas go to die.
What I've Been Trying: Claude as a Cognitive Bridge
I started doing something that sounds almost too simple: using Claude differently depending on which brain I'm running on.
When I'm in creative mode — mobile, usually walking or on the couch, voice-first — I open a Claude conversation and just talk. No structure. No agenda. I describe the problem, the itch I can't scratch, the weird analogy that just clicked. Claude asks questions, pushes back, helps me name things. The session is messy and nonlinear and that's the point.
What comes out the other end isn't code. It's a spec artifact — a structured document Claude generates at the end of the session. Problem framing, core decisions, open questions, even a name for the thing.
Then the next day, analytical me sits down with Claude Code, drops in that artifact, and says build this. No context reconstruction. No "wait, what was I thinking." The handoff works because the artifact carries the intent.
A Real Example: Thoth
The clearest case I have so far is Thoth — a Claude Code plugin that auto-generates Jira worklogs by combining git commit analysis with manual activity tracking. The idea came out of a frustration I'd been sitting on for months: I knew what I worked on, my commits knew what I worked on, but Jira had no idea.
The brainstorm session was typical — scattered, half-formed, lots of "something like this but not exactly." I described the pain. Claude started pulling threads: what triggers the log? what's the input — commits, time, both? does estimation need to be part of this? We went back and forth until the shape of the thing was clear.
At the end I asked: "Give me a structured product brief from this conversation."
What came back:
Product: Thoth
Problem: Worklog entry is manual friction that kills flow — devs skip it
Core user: Developer working across multiple Jira tickets per day
Trigger: End of coding session or commit push
Input sources: Git commit history + optional manual activity notes
Core mechanic: Claude analyzes commits, infers effort, drafts worklog entries
Calibration loop: User corrects estimates → model learns personal patterns
Key command: /thoth:learn — profiles commit style for better inference
Open questions: Granularity of time tracking, multi-repo supportThe next morning, Claude Code got that brief as its first message. It proposed a slice breakdown and we started with slice one. Thoth is now built and in use. The brief-to-build handoff was cleaner than anything I'd managed with traditional notes.
Why This Works
Your brain has two networks in competition: the Default Mode Network — active during mind-wandering, association, creativity — and the Task Positive Network — active during focused, sequential work. They don't run well at the same time.
Most dev workflows try to force both into the same session. Brainstorm and implement. It's expensive and usually one mode loses. The two-phase approach stops fighting that — and Claude is the stateless intermediary that doesn't care which version of you it's talking to, as long as the artifact is good.
When It Breaks
This workflow has a real failure mode — I've hit it more than once. If the creative session is too scattered, the brief comes out shallow. Vague problem statements, fuzzy scope, open questions that aren't actually questions — just anxiety in disguise. Claude will structure whatever you give it. Garbage in, structured garbage out.
The signal I've learned to watch for: if at the end of the session I can't answer "who specifically hits this problem and when," I'm not ready to generate the brief yet. Keep talking.
The Artifact Is the Secret
The real insight isn't "use AI for brainstorming." It's that the artifact format matters enormously.
A raw transcript is useless. A vague summary is almost useless. What you need is a structured spec with enough fidelity that your future analytical self — or Claude Code — can pick it up cold and run.
The format I've landed on: problem framing, core user, trigger/job-to-be-done, MVP scope, first decisions made, and open questions. That last one is critical — it's what prevents you from losing the uncertainty that still needs resolution. The temptation is to clean it up, resolve the ambiguity in the brief itself. Don't. Leave the open questions open. That's what the next session is for.
Getting Claude to generate this at the end of the creative session is a one-liner: "Structure what we just built into a product brief I can hand to a developer tomorrow." It knows what you mean.
Where I'm Taking This Next
The workflow is good enough to use. The artifact format is stabilizing. What I don't have yet is a formalized structure — a schema that's consistent across projects, and ideally a Claude Code plugin that ingests a brief and bootstraps the project automatically.
That's the next thing I'm building. If you're trying something similar — or if your version of this looks completely different — I'd genuinely like to compare notes.
— Mariano, building at brolio.dev