DEV Community: Kairi

Zazen for ADHD devs: what 20 minutes of sitting still does to my brain

Kairi — Mon, 20 Apr 2026 14:35:24 +0000

Zazen for ADHD devs: what 20 minutes of sitting still does to my brain

My brain is loud.

I have ADHD. That's the short version. The long version is that my brain runs roughly seventeen tabs at once, half of them muted, all of them unfinished, and any attempt to close one spawns three more. If you know, you know. The thing I was going to do five minutes ago is being narrated over three other things I was also going to do, one of which I have already forgotten.

I've tried most of the usual tooling to manage this. Timers, lists, apps, hyperfocus-bait, productivity systems that last exactly until the novelty wears off. Some help a little. None of them give me quiet.

This is a post about the one practice that reliably does — and it's probably not what you expect. I sit on the floor in a temple for twenty minutes and stare at a wall. That's it. I'm going to tell you why a very old practice turned out to be the most effective thing I've found for an ADHD brain trying to do software work.

I'll cover: how I stumbled into this as a teenager, why I came back to it in college when the noise got unbearable, what twenty minutes of zazen actually feels like from the inside of an ADHD head, how it's changed my dev work specifically, and — most importantly — how you can just go, wherever you live.

The field trip I wasn't supposed to like

I grew up in Japan. At some point in high school my class got marched onto a bus and taken to a temple for a full day of Zen practice. This was not a spa day. It was a religious training school, and the schedule was: zazen (seated meditation), samu (cleaning work), shakyo (copying sutras by hand), and shojin ryori (vegetarian monastic food). No phones. No talking unless instructed.

Important context: I was at peak teenage everything is terrible mode. Boyfriend stuff, friend stuff, existential stuff. I had seen the temple's one-day trial flyer earlier and thought, only half joking, maybe I can get enlightened and skip the next three years of this feeling. So when the school trip landed on that same temple, I showed up ready.

We did the full day. We copied sutras with brushes. We got hit on the shoulder with a wooden stick (the kyosaku, it's a real thing, they ask if you want it first, it's not as scary as it sounds but you feel it). We scrubbed floors in silence. We ate rice and pickles with the kind of attention you normally reserve for a one-time thing.

And the weird part: something shifted. Not enlightenment, obviously. But the noise came down. It was a hot summer afternoon and normally my brain would have been complaining about the heat while simultaneously spinning on social drama and unfinished homework. That day, I just... noticed it was hot. The cicadas were piercingly loud in a way they usually aren't, because nothing else was competing for audio bandwidth. I walked out of that temple lighter than I walked in, even though I had just scrubbed a floor for an hour.

Fifteen-year-old me didn't have vocabulary for what had happened. I didn't have an ADHD diagnosis yet. I just remembered that for a few hours, my head had been quiet for the first time I could remember.

The noise got worse before I came back

Years passed. I went to university. My brain got louder, not quieter. ADHD in your late teens and twenties has a way of compounding — the stakes go up, the stimulation goes up, the number of tabs goes up, and the strategies that kind of worked when you were sixteen stop working when you have to manage your own schedule.

At some point in college, I hit a wall. Not a depression wall, more of a cognitive traffic jam. Too many open loops, no way to close any of them, and everything I tried — more coffee, more lists, more structure, louder music to drown out the inside noise — was a variation of "push harder against the chaos." Pushing harder is the default ADHD response and it mostly makes things worse.

I remembered the temple. I remembered walking out of it with a quiet head.

I looked up a drop-in zazen session near my university. I went alone. I was nervous, which was funny in retrospect because the thing I was nervous about was sitting still, which for an ADHD brain is a reasonable thing to be nervous about.

That was years ago. I now do it every few weeks. Not as discipline. Closer to brushing teeth for the mind.

What twenty minutes of zazen actually feels like in an ADHD brain

I want to describe this honestly because meditation gets talked about in two broken registers online. Either it's mystical (you will achieve inner peace), or it's clinical (studies show a 12% cortisol reduction). Neither is what it's actually like, especially not for ADHD brains.

Here's what it's like.

First few minutes: you sit cross-legged. Immediately, your knees protest. Your back, which has been slumped at a laptop all week, sends a formal complaint. Your brain, sensing stillness and interpreting it as threat, produces a surge of thoughts. You will at this point believe you are "bad at meditation." You are not. This is what happens to everyone. For ADHD brains, the surge is just louder.

Minutes five to ten: the thought storm. I think about: whether I sent that email, a joke I meant to tell someone three days ago, the weird noise my fridge makes, a conversation I had in middle school, the PR I haven't reviewed, whether I locked the door, the side project, the thing my coworker said in a meeting, the snack I want later. I cannot stop any of them. The practice isn't stopping thoughts — it's noticing each one and not following it down the staircase.

My personal hack for this: I imagine a tiny trash icon floating in the corner of my mind, and I drag each thought into it. Fridge noise — trash. Middle school memory — trash. Did I lock the door — trash (I did). Is this the authentic traditional technique? No. Does it work for a software-shaped ADHD brain? Yes, remarkably well.

Minutes ten to fifteen: something gives. Not always, but often. Some of the thoughts stop arriving. The ones that do arrive feel less urgent. My body, which has been broadcasting pain from my knees, goes quieter. Time stops being linear. Five minutes can feel like fifteen, or like two.

The last five minutes: genuine quiet. Not the zero-thought state the mystical framing promises — there are still thoughts. But they pass through without sticking. My chest unclenches. I become aware of small physical details: the breath, the floor, ambient sound. This is, I think, the part that ADHD brains rarely get to. We are usually too loud to notice we are in a body.

The bell rings, session ends. You try to stand up. Your legs remember they have been cross-legged for twenty minutes and briefly refuse to participate. I have come close to falling over more than once. This is normal and nobody judges you.

And then — the thing I keep coming back for — you walk out and the air feels different. Not magical. Just: the background hum has been muted. My head is quieter, my chest is lighter, and I can look at my inbox without the preemptive clench.

Twenty minutes. That's it.

Why it matters for dev work (especially if you have ADHD)

I don't want to claim zazen makes me a better engineer. That would be the kind of productivity-bro framing I actively avoid, and it's also not what's actually going on. What it does is more specific:

It gives me a hard context reset. Most of my job, corporate and after-hours, is multi-threaded. ADHD brains do not naturally release context between tasks — we carry every open thread with us, invisibly, taxing cognitive bandwidth. A zazen session is the closest thing I've found to running /clear on my own head. Not a break. Not a nap. An actual state reset.

It lowers the fake-urgency floor. The ADHD trap is that every stimulus feels equally urgent because the brain's priority-sorting is garbage. After a session, my nervous system stops treating every Slack ping and every side-project idea as DEFCON 1. I can triage more honestly for a few hours.

It's training in coming back. You sit down intending to focus. You immediately don't. You notice, you come back. You immediately don't again. You come back. This is, unexpectedly, the exact skill ADHD people need all day: notice the drift, come back, without shame. Zazen is literally structured practice in that move.

It builds tolerance for being still without feeling lazy. ADHD brains have a vicious internal narrator that equates stillness with failure. Practicing stillness in a structured, sanctioned, traditional context — where sitting still is the point, not the problem — slowly rewires that narrator. Sometimes the correct move on a hard problem is to close the laptop and sit. I used to fight this. Now I budget for it.

It's medication-friendly. I'm not going to tell you to replace anything with meditation. That's a personal decision between you and a medical professional. But zazen plays well with stimulant medication for me — it gives the medicated focus a quieter room to operate in. Your mileage may vary; please don't tweet at me.

How to actually go to a session

This is the part that feels intimidating and doesn't need to. You don't need to convert, become a monk, learn Japanese, or buy special clothes. You need to find a temple that runs a public zazenkai (zazen gathering) and show up.

If you're in Tokyo

Search 東京座禅初心者 or Tokyo zazen drop-in. Several major temples run weekly public sessions, usually early morning, often free or donation-based. A few practical notes:

Large tourist-facing temples are your best bet for English support. If you don't speak Japanese, aim for temples that already host international visitors. They're used to beginners and will walk you through the mechanics (how to sit, how to bow, what the bells mean).
Google Translate is fine. Bring a phone, use the camera feature on any written instructions. The monks running these sessions have seen every awkward-foreigner situation. They are kind about it.
Smaller neighborhood temples often hold zazenkai too — they just don't advertise it in English. If there's a temple near your apartment, it's worth walking in on a weekday afternoon and asking. Many do, quietly.

If you're anywhere else

Good news: zazen is not a Tokyo thing. Zen traveled. There are Zen centers in New York, London, Berlin, Paris, Portland, Barcelona, and probably within an hour of wherever you live. Search [your city] zazen or [your city] Zen center. Most will have a weekly beginner-friendly drop-in.

They will usually have a fifteen-minute orientation before the session. They will show you how to sit. Nobody expects you to know what you're doing.

Logistics

Loose, comfortable clothes. Something you can sit cross-legged in without a waistband cutting off circulation.
Socks.
Phone on silent, out of sight. Don't bring a notebook to "journal insights" — this is a thing people try and it misses the point.
Eat something small an hour before. Don't go hungry, don't go full.
Expect awkwardness the first time. Stay for the whole session. Leave better than you arrived.

The honest pitch for ADHD brains specifically

I'm not going to tell you this will fix your ADHD. It won't. What it will do is give you occasional access to a quality of quiet that ADHD brains don't get to often — and that quiet has downstream effects on how you code, how you triage, how you carry context, and how gently you talk to yourself during a bad focus day.

Twenty minutes is short enough that even the most restless ADHD brain can get through it with a trash-icon hack and some patience. It's structured, it's external, it's low-technology. You don't have to configure anything. You just sit.

If you try it, I'd genuinely love to hear how it goes for your brain. Drop me a note.

And if you don't — that's also fine. The cicadas are still loud somewhere.

Sensitive Env Vars Should Be Default, Not Opt-In

Kairi — Mon, 20 Apr 2026 07:47:12 +0000

I wrote a post earlier today about cleaning up after the Vercel breach. The cleanup itself is easy — ten minutes, a sequence of clicks, done.

What's been bugging me all afternoon is a different question:

Why is "sensitive" opt-in?

The implicit default is wrong

When you add an env var to Vercel, it's not marked sensitive by default. You have to remember to toggle it.

This is the wrong default for a class of values where 99% of the time, "sensitive" is what you want.

Think about the actual population of env vars in any real project:

API keys for third-party services — sensitive
Database URLs — sensitive
Signing secrets — sensitive
Stripe keys, Auth0 secrets, etc — sensitive
Feature flags — occasionally sensitive
Config booleans — usually not sensitive
Public API base URLs — not sensitive (they're in the client bundle anyway)

For most teams, the split is maybe 80/20 in favor of "should be sensitive." Maybe 90/10.

A default that matches 10-20% of cases is a design mistake.

Why the default exists

Vercel has a specific technical reason: sensitive env vars can't be read after they're set. You can only overwrite or delete. This makes debugging harder when you're troubleshooting "is the value what I think it is?" The opt-in default gives you a debugging escape hatch.

Fine. But the escape hatch should be the exception, not the default. Debugging an env var value is maybe 1% of the time you interact with env vars. Protecting against leaks is 100% of the time.

Moving from "default not-sensitive, opt-in sensitive" to "default sensitive, opt-out for debugging" would match the actual weight of the two concerns.

The minimal workflow change

I can't change Vercel's default. I can change my own habit.

Before today: add env var, fill in value, save. Maybe remember to toggle sensitive. Maybe not.

After today: add env var, fill in value, sensitive ON, save. If I later need to debug, I'll flip it off, verify, flip it back.

The cost is two extra clicks at creation time. The benefit is that every future breach like today's is a non-event.

Generalizing: safe defaults for tiny projects

There's a broader principle here. Small projects skip security hygiene because the perceived cost-benefit is wrong:

"I have no users, who'd target me?" — but breaches are opportunistic, not targeted
"I'll tighten security when I scale" — but by then you have user data in the loss radius
"Defaults are too paranoid for my usecase" — but defaults are designed for the median case, which is probably you

The fix isn't to be paranoid. The fix is to use tools' safest defaults and only opt out when there's a specific reason. Think of it as borrowing the thinking of a larger team.

Concretely for a solo/indie Next.js + Vercel setup:

Env vars: sensitive by default. I explained my reasoning above.
Deployment protection: "Standard" minimum. Blocks preview deploys from being publicly indexed.
Branch protection on main: requires PR + review even if the reviewer is yourself 24h later. Catches "oh no I just committed the API key" before push.
Pre-commit hook scanning for secrets: cheap to set up, catches the stupid ones. I wrote a piece about mine — it's a 30-line shell script and it's caught me twice.
Service-specific secret rotation: quarterly, on a calendar. Not because you expect a breach. Because it bounds the window.
Separate secrets by environment: production secrets live only in production. Preview and development use their own keys or dummy values.

Each individual control takes five to thirty minutes to set up. None of them are hard.

The meta-lesson

Security defaults are worth thinking about critically because the cost of getting them wrong only shows up asymmetrically — nothing happens 99 times, something catastrophic happens on the 100th.

Most of us outsource this thinking to platform defaults and assume platforms get it right. Today was a reminder that platforms sometimes get it right for the platform, not for you.

Audit your defaults. Pick the ones that cost you two clicks and buy you asymmetric downside protection.

Three cups of tea. No coffee. Sensitive flag ON from now on. Lesson logged.

The Vercel Breach Hit One of My Projects. Here's What 10 Minutes of Cleanup Looked Like.

Kairi — Mon, 20 Apr 2026 06:42:26 +0000

Vercel disclosed a security incident today. The short version: a third-party AI tool (Context.ai) used by a Vercel employee got compromised, the attacker took over the employee's Google Workspace, and used that to access some Vercel environments and environment variables not flagged as "sensitive."

I checked my dashboard expecting the all-clear.

One of my env vars had a "Need to Rotate" tag. I was in the affected subset.

Here's the full cleanup, in the order I did it, with what I'd do differently.

What the tag looks like

Vercel surfaced this in two ways:

The affected subset gets an email from Vercel security
The dashboard shows a yellow "Need to Rotate" badge on the specific env var

I didn't get the email (or it went to a spam folder I didn't check). The dashboard tag is what told me.

Lesson already learned: the dashboard is the authoritative source during an incident. Don't wait for the email.

The 10-minute recovery

Step 1: Do NOT revoke the old key first

I almost did. If you revoke before you've cut over, your production endpoint dies between revoke and replacement.

Order matters: new key → update env → verify → revoke old.

Step 2: Generate a new key

Go to the provider (in my case, the email API vendor whose key was exposed). Create a new key with the same permissions as the old one. Name it with the date — vendor-prod-20260420 — so future-me knows what it was for.

Copy the key immediately. Most providers show it exactly once.

Step 3: Update the Vercel env var

In Vercel dashboard: Project → Settings → Environment Variables. Find the compromised one. Edit.

Paste the new value.

And here's the critical part — toggle "Sensitive" on. If your env var was marked Sensitive before the incident, Vercel's bulletin says those values were stored in a way that prevented them from being read. The attacker only had access to non-sensitive ones.

Small gotcha: Sensitive env vars can't exist in the Development environment. Just Production + Preview. That's fine for most setups — you use .env.local for dev anyway.

Step 4: Redeploy

An env var change does not automatically trigger a deployment. You have to redeploy manually or the new value won't hit your running production.

Deployments tab → latest production → ⋯ → Redeploy. Don't reuse the build cache.

Two minutes later, production is running the new key.

Step 5: Verify it works

Hit your endpoint with a test request. In my case, I did a real newsletter signup from the public site with a test email. Got a 200 back, saw the test contact in the email vendor's dashboard. New key live.

If you skip this step and the new key has a typo or permission gap, you won't know until the next real user hits the broken endpoint.

Step 6: Now revoke the old key

Back at the provider. Revoke. Confirm.

This is the step where the potential leak actually closes. Everything before was setup.

Step 7: Audit your other env vars

While you're in there:

Mark everything sensitive that should be sensitive (retroactive fix)
Delete any env vars you're no longer using
Enable Deployment Protection if you haven't already

The relief

My service hasn't really reached anyone yet. Few subscribers, no paying users yet. If the leaked key had been exploited, the blast radius was… honestly, close to nothing.

That's luck, not good practice.

In a universe where this project was six months older and had real traffic, a compromised email API key could have meant someone sending spam from my verified domain, burning my sender reputation, and me finding out three days later when delivery rates cratered.

The time to mark env vars as sensitive is when you create them. Not after an incident.

What I'm changing going forward

Three things:

1. Sensitive flag is the default, not the exception

Every new env var starts as Sensitive unless there's a specific reason it can't be (like needing it in the Development environment for local proxy testing).

2. Secret rotation is a quarterly habit, not an emergency

The value of rotating keys every 90 days isn't that you expect a breach. It's that if one happens, the window of exposure is bounded. Even loosely-stored keys can only do so much damage if they're less than 90 days old when leaked.

I'm adding a calendar reminder. 4 reminders a year, 10 minutes each. Trivial cost.

3. Third-party AI tools are supply chain dependencies now

This breach didn't come from Vercel's security posture. It came from an AI tool one employee used. The attacker didn't need to crack Vercel — they just needed to compromise a vendor that had access to a Vercel employee's account.

Every AI integration in your dev workflow has some access scope. It reads your repo, or your terminal, or your cloud console, or your credentials. That access is attack surface.

I'm going to start writing down, in a flat text file, every AI tool I've authorized on what scope. Not to get paranoid — just so I know what to rotate if one of them makes the news.

TL;DR

I was in the affected subset. Found out via the dashboard tag, not email.
10 minutes of cleanup: new key → update env → redeploy → verify → revoke old → mark sensitive.
Lucky the project was small. In a larger context, this could have been bad.
Going forward: Sensitive flag by default, quarterly rotation habit, AI tool access log.

Three cups of tea. No coffee. Still tired. Good day to log a lesson.

5 Claude Code Workflows I Use Every Day (For the Boring 80%)

Kairi — Mon, 20 Apr 2026 05:47:32 +0000

People keep asking me what my Claude Code "prompts" are.

I don't really have prompts. I have workflows. Small, boring, repeatable things that each save me 10-30 minutes, and at the end of a day add up to why I can keep shipping around a day job.

Here are five I use almost every session.

1. "Before you edit, grep."

When I hand Claude Code a task that touches something broader than a single file — a rename, a pattern change, a refactor — I start the session with one directive:

Before you edit anything, grep for all occurrences of X. Show me the list. I'll tell you which ones to change.

That single sentence has prevented more bad edits in my repos than any test suite. It forces the AI to enumerate the scope before it takes action, and it gives me a natural "stop, this is too big" moment.

The cost is 15 seconds. The upside is not finding out three hours later that it renamed something in a migration script.

2. "Write the test first. Fail it. Then fix it."

Not because I'm a TDD purist. I'm not. But AI is weirdly good at writing confident code that does the wrong thing, and tests are the cheapest way to catch that.

My actual phrasing:

Write a failing test for the bug I just described. Run it. Confirm it fails for the right reason. Then write the fix. Then re-run.

The "run it. Confirm it fails for the right reason" is the key. Tests that pass by accident are worse than no tests — they give false confidence. Forcing the AI to watch its own red-to-green transition catches the subtle "test was wrong, code is actually broken" cases.

3. "Explain, then diff."

When I'm learning something new — a library API, a framework pattern, a language feature — I don't let Claude just write it for me.

Before writing code, explain what you're going to do in plain English. What calls what. What the state machine looks like. Then write the diff.

Without this, I end up with working code I don't understand, and understanding-debt compounds until I get burned on the second or third iteration.

With it, I read three paragraphs and then review a diff. My comprehension stays current, and my edits are informed.

4. "Grep my notes first."

I keep a flat directory of .md files with notes from past sessions. Problems I solved, patterns I chose, decisions I'd regret if I forgot. Not a fancy system. Just markdown.

When I start a new session on a related topic:

Read ~/notes/ (look for filenames matching the topic). Summarize what I've already decided before suggesting anything new.

This catches the "we already tried that and rejected it" case before I waste an hour rebuilding the rejected path. It also forces me to keep writing those notes, because now they have a feedback loop.

5. "Pick one. Ask before the others."

When I give Claude a list of 4-5 things to do, it used to just plow through all of them. Sometimes halfway through it would change its mind about #1 based on what it learned in #3, and I'd end up with an inconsistent mess.

Now:

Do #1. Stop. Show me what you did. Wait for me to say continue.

Multi-step autonomy is great for well-scoped tasks. For fuzzy ones — anything exploratory, anything touching architectural decisions — forcing a checkpoint between steps keeps the work coherent.

Opus 4.7 is better at self-checkpointing, but I still add this explicitly when the stakes are non-trivial.

The meta-workflow

What these have in common:

Cheap to run. None of them take more than 30 seconds of me typing or 60 seconds of Claude thinking.
Fail loud. If they break, I know immediately, not three hours later.
Compound. Each one is worth a few minutes. Stack five of them and the day opens up.
Boring. None of them are clever. They're just discipline encoded in a sentence.

I used to write long system prompts. I don't bother anymore. Five short workflows, applied ruthlessly, outperform any clever preamble.

Three cups of tea, no coffee, still tired. Shipping anyway.

Claude Opus 4.7 Field Report: Eight Hours of Autonomous Work

Kairi — Mon, 20 Apr 2026 00:53:14 +0000

Anthropic released Claude Opus 4.7 yesterday. The headline feature is hours-long autonomous work without constant course-correction.

I put it to the test on something real. Here's the field report.

The task

A side project of mine had a scheduled-post automation that had been broken for about a week. Posts were going out at wrong times. The root cause could have been timezone handling, API auth, queue state, or all three. I wasn't sure.

I gave Opus 4.7 this:

Find out why scheduled posts are firing at wrong times. Check the scheduler code, the API responses, the timezone handling in the storage layer, the queue state, and the actual fired-post logs. Fix the underlying issue. Don't just patch the symptom.

Then I went to do other things for about 8 hours.

What actually happened

It didn't fix the bug in 8 hours. But it did something more interesting.

It:

Reproduced the bug reliably.
Instrumented 4 different layers of the stack with debug logs.
Wrote a test harness that fired fake posts through the pipeline with controlled timestamps.
Identified that the bug was actually two bugs, not one — one in my storage layer (naive local timestamps), one in the scheduler (assumed UTC input).
Proposed a fix for the storage layer that would require a one-time migration of existing data.
Stopped there and asked me whether the migration was acceptable.

That last bullet is the thing. Earlier Claude releases would either:

Just charge ahead and migrate (scary)
Stop way earlier and ask what to do (annoying)

This version did a long stretch of investigative work, correctly identified a decision that needed human input, and parked there. That's the skill level I've been waiting for.

Where it drifted

Three places.

1. Scope creep on the test harness.
I asked for a fix. It wrote a fairly elaborate test suite as part of the investigation. Useful, but not what I asked for, and it ate context window.

2. It over-explained the storage layer bug.
The explanation was correct but long. Three paragraphs when one sentence would have worked. Earlier releases were more concise.

3. It assumed my time zone from context.
I hadn't told it what TZ I was in. It inferred from some filename references. It inferred correctly, but I'd rather be asked than guessed at. This is a tiny thing.

None of these are blockers. They're polish issues.

What didn't drift

The parts that mattered held up.

It stayed on task for the full session without me re-anchoring it.
It didn't hallucinate API shapes — when it wasn't sure, it read actual responses.
It wrote diffs I could read and approve line by line.
It caught a genuinely subtle second bug that I had missed in my own debugging earlier.

What this actually changes

For me, the jump from Opus 4.6 to 4.7 is the jump from "pair programming assistant" to "junior engineer with better taste than me on average, but who still needs to check in."

That's a qualitative shift.

Before 4.7, I would ask for scoped single-file tasks and stitch the results together. After 4.7, I can give multi-layer tasks that cross files, modules, and domains, and the output is coherent.

The work I used to do — context stitching, keeping state across sessions, reminding the AI what we were doing — that work got cheaper this week.

What it still can't do

Decide whether a product is worth building
Decide what a feature should feel like
Pick which bug is worth fixing first
Explain to a user why their workflow is wrong

The interesting part is still mine.

Practical takeaway

If you're already using Claude Code or Claude through an editor:

Give it bigger tasks than you used to. It can handle them.
Still ask it to stop before destructive actions. That behavior is there now, but it's still polite to scope it.
Don't bother with "think step by step" — that's implicit at this level.
Read the diffs. You'll learn things.

If you weren't using Claude before: this is probably the release worth trying.

Eight hours of autonomous work, two real bugs found, one fix migration decision parked for me. Net positive. Still tired.

My AI-Heavy Indie Stack (Actually Honest Breakdown)

Kairi — Mon, 20 Apr 2026 00:52:33 +0000

A few weeks ago I posted a thread that ended with "here's the setup, in honest detail:" — and then I didn't deliver the detail.

That was bad form. Let me fix it.

This is the actual stack I use to ship indie projects around a day job, with ADHD eating my executive function most days. It's not impressive. It's just relentless.

The bottleneck isn't what people think

The thing AI changed for me isn't code quality. It's sequencing.

I can think the whole product. I can describe it in three paragraphs. The break in my workflow happened between "I know what I want" and "here are the 40 micro-decisions required to start typing." That gap used to eat days.

With AI handling the sequencing, the gap became minutes. I stopped losing evenings to paralysis.

That's the whole value prop, for me. Everything below is just tooling around that insight.

The stack

Primary driver: Claude Code

Not Cursor, not Copilot. Claude Code in a terminal. Here's why:

Multi-file edits with intent: "make this template work for a pricing page instead" and it touches 6 files correctly.
Explains what it changed: I read diffs and actually learn.
Headless, keyboard-only: which matches how my attention works.

Cursor is great if your brain likes inline completions. Mine doesn't. Copilot is fine if your code is boring; the moment I go off-pattern, it fights me.

The right AI tool is the one that matches your cognitive style, not the one with the best marketing.

The boring glue: bash

About 30% of my time is Claude Code. Another 20% is tiny bash scripts that do things like:

rename 40 files from post-v1.mdx to post-0001.mdx padded
download all images from a list, resize, optimize
grep my notes for every TODO that's older than two weeks

I don't write these scripts. I ask for them. Done in 90 seconds. I don't remember them. I keep a bin/ folder of one-liners I've forgotten writing.

Task memory: sqlite at `~/.local/tasks.db`

One table. id, what, status, updated_at. That's it.

When I start a session I run tasks wip and it tells me what I was mid-way through. When I shelve something I run tasks park <what>. It's a 30-line Python script wrapping sqlite3.

This one tool has done more for my shipping velocity than any "productivity app." Because I can't hold state in my head, and a database can.

Surface: dark mode everything, terminal-first

I don't have a strong opinion on editors. I use VS Code because it opens. But the surface I actually work in is the terminal: tmux + a vim split + claude code running in another pane.

Light mode is a tax on my eyes. Coffee is a tax on my ADHD. I optimize around not paying taxes I don't need to pay.

Fuel: tea, not coffee

This isn't a quirky brand — it's a real choice. Caffeine amplifies my ADHD symptoms. Coffee gives me 90 minutes of rocket and then 6 hours of fried circuits.

Tea, specifically black tea with milk, gives me enough alertness without the crash. Three cups a day, stop by 4pm, sleep is protected.

The whole indie workflow collapses if sleep breaks. Everything else is negotiable.

What the stack isn't

It isn't a framework. Nobody else should copy this exactly.

It isn't fast. Anyone watching me work would think I'm slow. I stop constantly to check what I did. I talk to myself out loud. I forget.

It isn't about discipline. Willpower is the first thing to go. The stack exists so willpower isn't in the loop.

It isn't AI doing the work. The AI handles sequencing. I still make every decision that matters — which product to build, what the thing is for, who it's for. That part hasn't gotten cheaper.

What changed

Before: evenings and weekends were a coin flip between "ship something" and "stare at the terminal for 3 hours and give up."

After: evenings and weekends are a coin flip between "ship something" and "ship something smaller." The terminal no longer stares back.

That's it. No 10x, no "unlocked creativity." Just the gap between idea and execution got cheap, and now I can afford to try things.

The part the stack can't do

Distribution.

You can build three templates in a weekend with this setup. Finding anyone who cares about them is a completely different skill, and I'm bad at it. I'm learning. Slowly.

That's tomorrow's post.

Nothing clever. Just relentless reduction of the parts that burn out.

Claude Code as Executive Function: My ADHD-Brain Setup

Kairi — Sun, 19 Apr 2026 10:46:10 +0000

I have ADHD. Verbal skill outpaces my motor planning by a lot — the gap measured on neuropsych testing is around forty points. That sounds abstract, but in practice it means I can think through a problem in full, narrate the solution out loud, and then sit down at my desk and watch the plan evaporate before any of it becomes code.

For years I treated this as a discipline problem. More lists. Better systems. Time blocks. It never stuck, because the bottleneck was never motivation. The bottleneck was the bridge between knowing what to do and actually doing it.

Then I started using Claude Code seriously, and the bottleneck got cheap.

This isn't a productivity-hack post. It's an honest writeup of the setup I use to get things shipped on days my brain would otherwise lose them. If you have ADHD, or you just find yourself with too many ideas and not enough execution, some of this might transfer.

The gap

Non-ADHD folks I've asked describe the task-to-action flow like this: "I think of what to do, then I do it." There's no perceptible step in between.

My version has a perceptible step, and it's expensive. A task gets thought of, sits in working memory, waits for motor planning to convert it into action, and — most days — quietly falls out of working memory before anything happens. The more complex the action (switching contexts, opening the right file, remembering the exact syntax), the more it costs, the more likely it drops.

I can reliably do small things. Big things require the brain to chain small things without dropping any. That chaining is the part that's broken.

Traditional productivity advice is about keeping more things in working memory or writing better lists. Neither fixes the gap — they just give the gap a bigger surface to fail on.

What actually helped

What helped was outsourcing the chain.

Not the decisions. Not the judgment. Those are still mine, and should stay mine. What I outsourced is the part where "I decided to refactor this file" has to become "I now remember the file path, open the editor, navigate to the function, remember the rename convention, write the new code, verify it compiles, commit with a good message."

Every step in that chain is a place where my brain drops the thread. Claude Code handles the chain. I handle the decisions.

The shift feels like this:

Old: think → try to chain → lose thread → frustrate → give up or half-ship
New: think → say what I want → review the diff → ship

I didn't get smarter. I got a prosthetic.

My setup, in practice

Most of the setup is just making Claude Code remember things I'd otherwise re-explain five times. ADHD brains are especially punishing when re-explaining is required — the overhead compounds. The setup reduces re-explanation to near zero.

1. `CLAUDE.md` — the project's memory

Every repo I use Claude Code in has a CLAUDE.md at the root. It holds project-level conventions, voice, tech stack, and anything I'd otherwise forget to say.

For my indie side project, mine contains:

Who I am in this project (an indie builder with specific voice)
Tech stack (Next.js 16, Tailwind v4, TypeScript strict, Framer Motion)
What's live vs. what's pending
Token-efficiency preferences (don't overexplain, just do)
Security rules (never commit PII, grep certain patterns)
Key decisions already made (so I don't get second-guessed)

Claude Code reads this file at the start of every session. I don't have to re-establish context. The AI already knows how I want to work.

This is huge for ADHD. Sessions are fragmented by design — I'll pick up at weird hours, in partial states of exhaustion. Without CLAUDE.md, every session starts from zero. With it, every session starts where the last one ended.

2. `.claude/rules/` — doctrine files it re-reads every session

CLAUDE.md handles the what. .claude/rules/ handles the how.

Mine has three files right now:

content-doctrine.md — voice, tone, overclaim guard, native-English checks
privacy-security.md — PII that must never appear, secrets management
kai-persona.md — the persona I use for my public writing

These aren't tutorials I read — they're instructions Claude Code follows. Each one has a pre-publish checklist, a never-list, and specific patterns to grep for before anything ships.

The practical effect: I don't have to remember the rules. They're enforced automatically.

When I'm tired and about to commit something questionable, the rules catch it. When I forget my own voice mid-article, the doctrine catches it. The rules encode "what past-me already decided" so current-me doesn't have to re-decide it at 2am.

3. Slash commands for the stuff I'd otherwise re-explain daily

I built a handful of commands — markdown files in .claude/commands/ — for things I do over and over:

/morning — pulls world and tech trends, writes them to a daily feed file, then drafts that day's posts for my public account
/sync — updates state files after a decision shift
/resume — one-shot context summary if I jump between sessions
/learn — records a post's reaction so I can find patterns later
/knowledge — loads a topic's knowledge file only when needed

Each command is a markdown prompt. When I type /morning, Claude Code runs it exactly the same way every day. No re-explaining. No variation. No lost thread.

ADHD's enemy is decision fatigue. Slash commands make daily decisions invisible. I don't wonder "what do I do now?" — I just run /morning and the work starts.

4. Pre-commit hooks — protection from my own lapses

I have a pre-commit hook that blocks any commit containing my personal name, personal emails, specific location markers, or API-key-shaped strings.

This is belt-and-suspenders for a very real ADHD failure mode: forgetting to check. On exhausted days I'll paste something into a file I don't remember adding. The hook catches it before it becomes a git history problem.

The hook is maybe 60 lines of shell. It's the cheapest line of defense I've ever added. Twice this week it caught leaks I didn't notice.

What this changed

The shipping numbers changed first. I used to start three things and finish one. I now start two things and finish both, on an average week.

But the bigger change is less visible. I stopped dreading switching contexts. Before the setup, every context switch cost me a 15-minute ramp-up to remember where I was. Now the state files tell me exactly where I was — Claude Code re-reads them, summarizes in ten seconds, and I'm working.

The emotional tax of ADHD dev work is usually in the ramp-up, not the work itself. Killing the ramp-up killed most of the tax.

The other thing that changed: I stopped being mad at myself. Setups like this make the assumption that your brain will drop things — and that's the right assumption for my brain. When I miss something, it's the tool's job to catch it, not my job to have remembered. That reframing, weirdly, is what made the setup stick.

What this didn't change

It didn't cure ADHD. Nothing does.

On bad days I still spiral. The setup shortens the spiral — I can pick up with less context cost — but it doesn't prevent it.

It also didn't make me smarter. Judgment is still mine. Claude Code executes; I decide what's worth executing. When I decide badly, the tool executes my bad decision quickly. A faster bad idea is still bad.

And it didn't eliminate the work. Writing good prompts is its own skill. Writing good specs is harder than writing good code. The execution bottleneck moved. It didn't disappear.

But moving the bottleneck from motor planning to judgment and prompt craft is, for my specific brain, a massive upgrade. Motor planning was the broken step. Judgment and craft are steps I can actually practice and get better at.

If you want to try this

Start with the smallest possible version. CLAUDE.md in your project root, with just the basics — tech stack, voice, and whatever you'd otherwise re-explain every session. That alone is maybe 70% of the value.

Add slash commands for two things you do daily. That's another 20%.

Rules files and pre-commit hooks come later, when you have a specific pattern you keep failing on.

The goal isn't to build the perfect prosthetic. It's to notice where your brain drops the thread, and put one small piece of infrastructure in that exact spot. Then notice the next drop. Repeat.

For me, after a few months of this, I ship things I'd have started and abandoned a year ago. Not because my brain got better. Because the things that don't survive the chain are no longer allowed to matter.

I write about AI-heavy indie workflow, ADHD-adjacent dev patterns, and corporate automation from someone who can't use the good AI tools at their day job. If you want more of this, my newsletter ships weekly — subscribe here.

DEV Community: Kairi

Zazen for ADHD devs: what 20 minutes of sitting still does to my brain

Zazen for ADHD devs: what 20 minutes of sitting still does to my brain

The field trip I wasn't supposed to like

The noise got worse before I came back

What twenty minutes of zazen actually feels like in an ADHD brain

Why it matters for dev work (especially if you have ADHD)

How to actually go to a session

If you're in Tokyo

If you're anywhere else

Logistics

The honest pitch for ADHD brains specifically

Sensitive Env Vars Should Be Default, Not Opt-In

The implicit default is wrong

Why the default exists

The minimal workflow change

Generalizing: safe defaults for tiny projects

The meta-lesson

The Vercel Breach Hit One of My Projects. Here's What 10 Minutes of Cleanup Looked Like.

What the tag looks like

The 10-minute recovery

Step 1: Do NOT revoke the old key first

Step 2: Generate a new key

Step 3: Update the Vercel env var

Step 4: Redeploy

Step 5: Verify it works

Step 6: Now revoke the old key

Step 7: Audit your other env vars

The relief

What I'm changing going forward

1. Sensitive flag is the default, not the exception

2. Secret rotation is a quarterly habit, not an emergency

3. Third-party AI tools are supply chain dependencies now

TL;DR

5 Claude Code Workflows I Use Every Day (For the Boring 80%)

1. "Before you edit, grep."

2. "Write the test first. Fail it. Then fix it."

3. "Explain, then diff."

4. "Grep my notes first."

5. "Pick one. Ask before the others."

The meta-workflow

Claude Opus 4.7 Field Report: Eight Hours of Autonomous Work

The task

What actually happened

Where it drifted

What didn't drift

What this actually changes

What it still can't do

Practical takeaway

My AI-Heavy Indie Stack (Actually Honest Breakdown)

The bottleneck isn't what people think

The stack

Primary driver: Claude Code

The boring glue: bash

Task memory: sqlite at ~/.local/tasks.db

Surface: dark mode everything, terminal-first

Fuel: tea, not coffee

What the stack isn't

What changed

The part the stack can't do

Claude Code as Executive Function: My ADHD-Brain Setup

The gap

What actually helped

My setup, in practice

1. CLAUDE.md — the project's memory

2. .claude/rules/ — doctrine files it re-reads every session

3. Slash commands for the stuff I'd otherwise re-explain daily

4. Pre-commit hooks — protection from my own lapses

What this changed

What this didn't change

If you want to try this

Task memory: sqlite at `~/.local/tasks.db`

1. `CLAUDE.md` — the project's memory

2. `.claude/rules/` — doctrine files it re-reads every session