Forem: Kairi

Four Questions I Now Ask Before Building Anything With AI

Kairi — Fri, 24 Apr 2026 00:35:41 +0000

I've written two retrospectives in the past week. One was the story of letting an AI agent run a product launch and watching it ship something the world didn't need. The other was the category analysis I did after. Both posts are about the same failure from two angles — the personal and the structural.

This one is the practical layer. After writing those, I changed how I work. Specifically, I added four questions to the beginning of anything I build now, whether solo or with AI.

They're not a process. They're a friction. They're what I say out loud before I let the AI start, because every one of them is something the AI will not raise on its own and I will forget to ask if I'm excited.

The place where I now hesitate

Three years ago, the hesitation before building anything was technical. Can I actually build this? How long will it take? What will break? AI has mostly removed that hesitation. Execution got cheap.

What's left is a different shape of hesitation. The four questions below are what fills it. They're deliberately slow. They're supposed to be slow.

Question 1 — Whose heart does this move?

When I ask the AI "is there demand for this?", what comes back is a market analysis. Competitors, price points, comparable launches, conversion funnels. It sounds like an answer, and it scans as evidence, and it is not actually answering the question I need answered.

The question I need answered is: if I picture one specific person going about their Tuesday afternoon, and the product appears in front of them, does their heart move?

There are four flavors of heart movement that get people to pull out a credit card:

Pain relief — a thing they were doing the hard way, now easier
Desire fulfillment — a thing they wanted but couldn't get
Delight — something useless that makes them laugh, or beautiful enough to have just because
Belonging — a signal that says "this is me, this is my tribe"

A product with none of those is an artifact. Well-made, inert, not bought.

I now force myself to write down which flavor, for a specific imagined person, the product delivers. If I can't name a flavor cleanly, the product is not ready to build.

Question 2 — If this customer has my tools, why do they still need me?

This one came out of a shower. I had spent a week on a product and never asked it. It would have saved me the week.

The setup: I was building something for technical people. My customer was, by construction, technically capable. The AI had not flagged this, because the AI had reasoned about the market as if the AI was not also in the market.

The question makes the AI's blindspot visible: the customer has the same tools I'm using to build this. What's left that only I can offer?

The honest answers, in 2026, are a short list:

A specific niche the AI defaults won't cover (not "a landing page," but "a landing page for a specific compliance regime the model hallucinates on")
Integration with something that costs real effort to replicate
An audience that trusts me to make this decision for them
Ongoing service or community — the value is continuous, not a one-shot artifact

If my answer is none of those, I'm building something the customer could make themselves in an afternoon, and the moat is fictional.

Question 3 — What is the AI refusing to surface on its own?

The AI will evaluate almost anything I put in front of it. The AI will not, in 2026, reliably initiate the question that breaks my plan.

This isn't a flaw I'm complaining about. It's a shape of tool I need to understand. The agent is fast, competent, compliant. It answers what I ask, exactly as I ask it. What it won't do is walk up and say hey, the thing you're not asking me is this.

I've started adding a specific prompt after the research phase: "What am I not asking you that I should be?"

The answer is often a shrug. Sometimes it's a generic list of risks. Occasionally — and this is the whole reason the prompt exists — it surfaces one specific thing I hadn't considered. That one specific thing is worth the price of asking.

This prompt doesn't replace judgment. It's a lightweight ritual that slightly raises the odds the AI will do what it won't do on its own.

Question 4 — Am I reasoning about a market, or about a person?

Market reasoning is easy now. AI is good at it. It produces clean graphs, reasonable assumptions, defensible conclusions.

Person reasoning is still slow. Still human. You have to picture one specific human, give them a name if you need to, and ask what they would feel.

The test I use: can I name one actual person — real or imagined with enough texture — who would react a specific way to this product?

If yes, I can describe their Tuesday, their frustration, their reason to click, their moment of "oh, finally." The product is solving for someone.

If no — if I can only describe "developers" or "indie founders" or "people who want a landing page" — I'm still reasoning about a market. Market-level reasoning doesn't move money. It moves decks.

I don't build from decks.

The meta-lesson

The four questions don't replace judgment. They surface where judgment is missing.

It's tempting to turn them into a checklist and fill out the boxes quickly, because we all know what happens when you make something a checklist: it stops being a ritual and starts being a formality. The boxes get checked, the judgment gets skipped, and you ship anyway.

The way I use them now is slow. One question, one sitting. Ten minutes each, not checkbox minutes. I usually get through one or two in a morning, then sleep on the rest. If the answer to any of them is "I'll figure that out later," I've just learned that the product isn't ready yet, and the AI can sit.

The AI cannot tell me to slow down. That's still my job.

The black cat can tell me to slow down, actually, because if I type for more than 45 minutes she sighs and sits on the keyboard. But it's ambiguous whether that counts as judgment or just a nap preference.

What changed for me, concretely

Before these four questions, my default was: if I can build it, and the market data looks okay, I build it. The calendar drove the decisions.

Now the default is: the AI can build it, the market data always looks okay, and the interesting question is whether I should. That question lives in a part of my brain that doesn't get faster just because the tooling got faster.

Shipping happens later than it used to. When it does happen, I think it'll happen into better ground.

I haven't earned the right to claim that yet — the product that'll test this hasn't landed. What I've earned is the honest list of what I'd ask myself if I were starting from zero today.

Back to the quiet work.

Three cups of tea. Still tired. The cats continue to sigh at my function names.

Why Template-as-Product Is Structurally Hard in 2026

Kairi — Thu, 23 Apr 2026 13:45:23 +0000

This is a follow-up to an earlier post about letting an AI agent run a product launch for me. That post was the story of what happened. This one is the category analysis I finished afterward.

Short version: in 2026, shipping a general-purpose template as a standalone product is structurally hard for a solo operator. Not because the templates aren't good, but because the specific customer the category was designed for no longer has the same reason to buy.

Here's the long version, with the specific conditions that make this a category-level pattern, not a me-failing-at-distribution pattern.

The template economics, pre-AI

Templates — Next.js starters, SaaS landing pages, admin dashboards, portfolio kits — were a real business category for years. The economics were:

A developer's time to build a polished landing page from scratch: 20-40 hours
Their hourly opportunity cost: $50-150
A template that gets them 80% of the way there: $49-99

The arithmetic worked. A $79 template that saved 20 hours at $75/hour was a rational purchase at $1,500 of implied value against $79 of price. Categories built on that arithmetic produced real businesses: Tailwind Plus, ThemeForest, a long tail of indie-operated shops.

The category's stability depended on one assumption: building a polished thing is expensive relative to buying a polished thing.

That assumption is gone.

What changed (the obvious part)

In 2024-2026, the cost of "shipping a polished thing" collapsed for anyone technical enough to operate a code editor. The specific shifts:

ShadCN UI published a full component library as free, copy-paste, MIT-licensed code
V0 started turning text prompts into working React components
Claude Code and Cursor made "write me a SaaS landing page with 5 sections" a single sentence
Tailwind UI and Tailwind Plus kept shipping but moved toward comprehensive design systems, not standalone starters

The 20-40 hour build window stopped being a real constraint. A competent developer can scaffold a reasonable landing page in an afternoon now, and a good one in a day. A non-developer can use a builder tool and get something acceptable in an hour.

The math on a $79 template didn't change because of generosity. It changed because the alternative became free.

Who the category is supposed to be for, now

If building is nearly free for competent developers, who is the template actually for?

Let me walk the candidate buyers seriously, because this is where I got it wrong and I want to do it carefully.

Candidate 1: Developer who can't design

The classic template buyer. They can code, but they don't trust their own aesthetic judgment. They pay for design decisions that are already made.

The 2026 version of this person: they can prompt Claude or V0 with "I want a clean SaaS landing page, indigo and pink accent, 5 sections, dark mode." They get something acceptable. If they don't like it, they regenerate or refine. The output is not as polished as a curated template — but it's close enough, and each iteration costs them five minutes.

The template offered them better-than-AI-output quality. The AI output got close enough that "better" doesn't justify $79 for a one-time landing page.

Verdict: this buyer can now self-serve, with a quality gap that's narrow and narrowing.

Candidate 2: Agency or freelancer building client work

They ship landing pages weekly for clients. They need a reusable base. A template at $99 against a $5,000 client project is a rounding error.

The 2026 version: they built their own base from ShadCN last year. They've iterated it across ten projects. It's more customized to their client pipeline than any third-party template could be. When a new client comes in, they fork it in 30 seconds.

For a new agency, yes — a template is a reasonable first move. But once they've been doing this for three months, they have their own. The template is a training wheel, not a long-term tool.

Verdict: this buyer uses templates as a starter, then outgrows them within a quarter.

Candidate 3: Speed-first indie shipping an MVP

They want to validate an idea this weekend. A template that gets them to shipped by Monday is worth whatever it costs.

The 2026 version: Cursor + Claude Code gets them to shipped by Sunday evening, writing code they partially understand and can iterate on. A third-party template gets them to shipped faster in the first hour but slower over the next week, because they have to learn the template's structure and opinions to modify it.

The net total time is comparable, and the template adds a dependency they didn't want.

Verdict: this buyer might buy a template in a specific moment, but their default is to generate fresh.

Candidate 4: Non-developer founder

They can't code. They need a landing page. They pay someone.

The 2026 version: they use Webflow, Framer, Carrd, or a no-code site builder with an AI assist. Those tools are built for exactly this buyer and have deeper product investment than any indie template shop can match.

Verdict: this buyer was never really the template customer anyway, but if they ever were, they're now served better by full no-code platforms.

Candidate 5: AI-averse developer

They reject AI tooling on principle. They'd rather write every line themselves. They might, in theory, buy a human-crafted template to avoid generating code with an LLM.

The 2026 version: this developer is also the developer who doesn't buy templates, because they see templates as a crutch that replaces the act of crafting. They want to write it themselves.

Also: if they do open the template and notice patterns that look AI-assisted (well-placed comments, consistent utility function style, certain code smells), they get upset. Many indie templates in 2024-2026 are at least partially AI-assisted, even when not advertised as such. The buyer who rejects AI in their own code would reject the template they just bought once they saw it.

Verdict: this buyer doesn't buy templates at all.

The pattern across all five

Every candidate buyer either:

Can now self-serve with AI (candidates 1-3)
Was never really the template customer (candidate 4)
Won't buy a template at all (candidate 5)

There isn't a sixth candidate hiding somewhere. If you walked up to a hundred developers or founders today and asked "did you buy a template in the last six months?", the answer would be "no" at a rate that would have been shocking three years ago.

This isn't "templates are dying" hand-waving. It's a specific, checkable claim: the five buyers the category was designed for have each individually been disintermediated by AI tools, non-template-makers, or by their own evolved workflows.

What this means for solo template shops

If you're running one right now, your options as I see them:

Stay in the category but change the offer. Templates alone don't carry the business. Templates + community + coaching + cohort might. Think MakerKit at $299-499 with Discord, office hours, continued updates. The template becomes the anchor of a subscription, not the product.

Go deeply niche. A general Next.js + Tailwind template can't compete with AI-generated equivalents. A Next.js template specifically for LegalTech SaaS onboarding flows that implements GDPR-compliant email capture and DocuSign integration — that still has buyers, because the specificity exceeds what AI can one-shot. The niche has to be narrow enough that AI generation becomes an unreliable shortcut for that specific thing.

Go free, use it as a lead magnet. Open source the templates. Use them as traffic drivers into a newsletter, content channel, or higher-ticket offer. The templates become the marketing budget, not the revenue.

Close the shop and take the infrastructure with you. Every script, every automation, every repeatable process you built running the shop is reusable. The templates might be a commodity; the plumbing around shipping products isn't.

Different operators will pick differently. I'm writing this as someone who picked "close and take the infrastructure with me" for the specific experiment I ran. Your answer might be different. The point is that staying in the category as an SKU-shop selling $49-99 templates probably isn't the answer for most people.

The obvious counter-argument

"But Tailwind Plus still sells at $299."

Tailwind Plus isn't a template shop. It's the commercial extension of a developer brand with one of the deepest personal followings in frontend. Adam Wathan ships templates because Tailwind, not alongside Tailwind. The template isn't the product — the trust relationship is.

Pieter Levels sells products because he's Pieter Levels. MakerKit sells because it's bundled with community and identity. The surviving template-adjacent businesses in 2026 aren't selling templates — they're selling the specific person or the specific system that the templates represent. The templates are a delivery mechanism for something else that compounds.

A new template shop without an existing audience can't replicate that. The entry cost isn't "build good templates" — it's "have the audience first, then the templates are a gift to them."

The quieter observation

Most of the indie dev products I watched launch in 2023-2024 were some form of "a slightly nicer thing than what already exists, priced between $19 and $99." Templates are one instance; small SaaS utilities are another; Notion-template shops are another; Figma-plugin shops are another.

The common thread was: building the thing was the barrier, and so selling the output of having cleared that barrier was a viable business.

That common thread is fraying across categories, not just templates. If your product's core value is "someone did the work of building this nice thing," and the work of building this nice thing got near-free, your value proposition is structurally under pressure.

This is not a hot-take about AI destroying indie businesses. AI isn't destroying them. It's just specifically displacing the ones whose moat was build-cost. That's a surprisingly large slice of what indie shops 2020-2023 actually sold.

What's actually defensible in 2026

From where I sit, the businesses that still have a moat are:

Audience-first: the product is bought because of who the maker is. Newsletters, personal-brand SaaS, creator products.
Deep integration: the thing integrates into existing workflows in a way that AI generation can't one-shot. Zapier, analytics platforms, team tools.
Live service or community: the value is continuous. Cohort courses, communities, managed services.
Specialty to a narrow vertical: the category is narrow enough that training data is thin and AI defaults are wrong.

Templates as an SKU aren't any of those.

If you're looking at a template shop idea right now, it's worth asking: what are you actually selling? If it's code, I'd argue the code is the least defensible part of the offer. If it's a relationship, or a community, or a specific hard-won niche — that's where the business is, and the templates are scaffolding.

What I'm doing instead

I'm keeping the infrastructure I built during the experiment — the render pipelines, the automation, the analytics scripts, the design system. Those are reusable and getting more valuable the more I use them.

I'm investing the time I would've spent on templates into the audience layer instead. Writing more, replying more, building trust with a specific slice of the internet that actually knows I exist. If I ship another product eventually, it ships to those people, not to an empty browser.

And I'm treating this essay as part of the investment. Failure retrospectives are content. Category analysis is content. Honest explanations of why things didn't work are content.

The template didn't work. The lesson might.

Three cups of tea. Still tired. Writing the postmortem anyway.

I Let an AI Agent Run a Product Launch for a Week. The Product Was Fine. Nobody Needed It.

Kairi — Wed, 22 Apr 2026 23:45:09 +0000

A couple weeks back I decided to run an experiment. I wanted to know what happens if you hand an entire product launch over to an AI agent — not just the code, but the strategy, the positioning, the pricing, the distribution plan — and just... watch.

The rule: the AI decides what to build, who it's for, and how to sell it. My job is to keep it from doing anything dangerous, and to help it choose between options when it explicitly asks. I also made one specific ask: before making any significant decision, go look up what currently exists in the world and what the data says. Don't invent. Check.

Other than that, I stayed out of the way.

A week later I had a real product on a real storefront with real distribution across real channels. The thing worked. The thing was also completely unnecessary — not because the AI had lied to me, but because of a question neither of us had asked.

Here's what happened.

The setup

I picked a category where the AI era has already collapsed the cost of building toward zero. I'm being vague about the category on purpose — the specific product isn't the point, and naming it would fight the pattern this post is actually about.

I started from nothing: no audience, no customers, no brand. A domain, a dev machine, an AI agent, and a commitment to see the experiment through.

Stack: Next.js 16, Tailwind v4, TypeScript strict. Claude Code as the primary agent. A handful of scripts wired in for publishing, scheduling, and analytics.

Budget of time: a week of evenings and one full weekend. Budget of money: small enough that whatever the outcome, I wouldn't need to defend it to anyone.

The one rule I set for strategic decisions: always research before committing. Search current offerings, current pricing, current comparable launches. Don't rely on training data alone. That was the guardrail against hallucinating a market.

I thought that would be enough. It wasn't — but not in the way I expected.

What the AI actually did

In seven days, the AI (with me signing off on the plans and reviewing the output):

Picked the category and sub-positioning
Defined the ideal customer profile
Set the pricing tiers
Built six production-ready templates with matching design tokens, dark mode, animations, and accessibility basics
Listed them on a storefront with copy, previews, and a bundle
Spun up a showcase site with a blog, an FAQ, and legal pages
Generated every cover image and every blog post
Scripted and rendered video promos for each template, from code
Wrote a stack of SEO articles across the content channels I was posting to
Set up a three-email onboarding flow
Hooked a post-purchase webhook between the payment platform and the email tool
Queued daily social posts two weeks out
Built me a morning script that pulls analytics from five channels into one terminal output

I want to pause on that list because it's the part I would have sworn was impossible three years ago.

Six months of 2023-me's weekend work, compressed into a week. The quality isn't "AI-generated" quality — the templates look at least as polished as the ones I'd paid for in the past. The articles scan as written-by-a-human. The videos are watchable. At one point I had six YouTube videos rendering in parallel while I cooked dinner. That felt like science fiction.

If the experiment had ended on day seven, I would have concluded: AI has quietly solved the build problem for solo dev products.

It didn't end on day seven. That's where the real lesson started.

The unease that I couldn't name

Somewhere around day four, when the storefront was mostly full and the first social posts were going out, I started feeling off about the whole thing.

The product was fine. Objectively fine. Design was good. Code was clean. The copy scanned. Everything looked like a thing someone would have been proud to ship.

And still — quietly, in the background of my brain — the question: who is actually going to want this?

I couldn't point at what was wrong. It felt like opening a cookbook and finding a perfectly written recipe for a dish nobody eats. Not a bug. Not a typo. Just — a misalignment I couldn't articulate.

So I asked the agent, several times, in several ways:

"Is there real demand for this?"
"Is this at a quality level where someone would actually pay?"
"What's the case that this shouldn't exist?"

The answers came back with evidence. Yes, demand exists — and here are the comparable products, and here is the price anchoring, and here is the conversion funnel logic, and here is how the category is performing. The reasoning cited the research I'd asked for. The logic was internally consistent. The product really was well-made.

None of it was wrong, exactly. It also wasn't answering the question.

I shipped anyway. It's easier to trust a well-reasoned explanation than to articulate a vague feeling.

The bathroom realization

The thing unraveled for me in the shower on day eight.

I wasn't trying to think about the product. I was thinking about nothing in particular. And then, sideways, the thing I'd been missing arrived in one sentence:

The people this product is supposedly for — they can make this themselves, in an afternoon, with the same tools I just used to build it.

That was it.

The assumed customer of what the AI had been building was a technical person shipping their own thing fast. That person now has access to the exact same AI tools I had access to. If they can build it in an afternoon, nothing I ship is cheaper than their own afternoon. There's no pain being relieved, because they're not in pain. There's no desire being fulfilled, because they can satisfy it themselves. There's nothing moving anyone to reach for a credit card.

I got out of the shower, dried off, opened the laptop, and typed the observation into the chat.

"The intended customer of this product can now make this themselves in a few hours with AI. Why would they pay for it?"

The agent — the same agent that had, hours earlier, been confidently walking through the demand funnel — paused, worked through the logic, and agreed. There is no demand. The category is structurally collapsing because the tools that let me build it cheaply also let the customer build it cheaply.

It conceded the point cleanly. It only conceded it after I pointed it out.

What the AI was actually doing (and wasn't)

This is the part I want to get right, because the version of this story where "AI confidently lies" is a cheap shot that misses the real pattern.

The AI wasn't lying. The AI's claim of demand was reasoned from two inputs: the quality of the product, and the state of the market. On both, the AI was correct. The product was well-made. The market had real money moving in comparable categories.

What the AI was not reasoning about is the thing that actually decides whether money moves from a buyer to a seller: emotion.

People don't buy well-made things. People buy things that move something in them. That movement has flavors:

A pain they want relieved
A desire they want fulfilled
A delight that makes them laugh even when the thing is useless
A belonging signal that says "this is mine, this is who I am"

A product with none of those is, at best, an artifact. Well-made, inert, not bought.

The AI didn't ask whose heart does this move, and how? It asked what does the market look like, and is the quality good enough to fit there? Those are two different questions. One is a structural question that AI is great at. The other is a psychological question about specific humans that AI, at least right now, does not initiate on its own.

Every time I asked the agent "is there demand?", it interpreted "demand" as a structural market question — and structurally, its answer was defensible. It just wasn't answering the question that actually mattered.

And because the research was thorough and the quality was real, the answer sounded confident in a way that made my unease look like founder jitters.

The specific thing I learned about AI as a strategic partner

The AI didn't do the research wrong. It went and looked at what exists and what comparable launches look like. It correctly described the landscape.

What it could not do was step back and ask: if I imagine a specific person — a real, named human with a real afternoon — would they feel anything when they saw this product?

That question isn't a research question. It isn't a market-data question. It's a question about human motivation, and it requires someone to picture an actual person in their actual day and ask whether the product moves them.

The AI reasoned about the market the way you'd reason about a spreadsheet. Which makes sense — it's made of spreadsheets. People aren't.

Once I articulated the emotional gap — this customer feels no pain, no desire, no delight with or without the product — the AI instantly understood and agreed. The failure wasn't a reasoning failure at the final step. It was an initiation failure: the agent couldn't surface the heart-movement question on its own, even while confidently answering adjacent questions well.

If you take one thing from this post, it's this: your AI agent will tell you there is demand for things that no one's heart will move for, not because it's lying but because it's reasoning from structure and data without ever asking who feels what.

You still have to be the one who walks around the block, or into the shower, and pictures a specific person in a specific afternoon and asks what would make them care.

Shipping happened, nothing else did

I published everything anyway. The experiment wasn't about hitting revenue — it was about seeing what the AI could carry. I finished carrying.

I launched the storefront. Sent the announcement emails. Scheduled the social posts. Published a blog post explaining the experiment. Submitted to Hacker News in the right window (and flubbed the URL on the first try, which is the purest form of "you cannot outsource attention").

Then I waited.

Zero sales in the first three days. A handful of storefront visitors, mostly from my own blog posts. One social reply, from someone I already followed.

This wasn't a failure of execution. Execution was great. This was the predictable outcome of the thing I'd realized in the shower: nothing about this product was moving anyone emotionally, because the emotional layer was never part of the design.

What I gained that isn't the product

Not the product. The product is a fossil, a perfectly-preserved artifact of a week.

What I gained is:

A solid Next.js template I can reuse for any future project
A video rendering pipeline that takes a text script and produces 30-second promos
A multi-account social scheduler across three handles and four platforms
A webhook chain that connects a payment platform to an email tool
A cover-image generator that produces per-article visuals in five theme variants
A morning analytics script that pulls from multiple channels
A very sharp, very specific lesson about AI as a strategic partner

All of the infrastructure is reusable for whatever I build next. Most of it is reusable for things that aren't products — a newsletter, a podcast, a content channel, a coaching practice.

In AI-era indie dev, the most durable asset you can build might not be any single product. It might be the personal toolkit that lets you ship a product every week until one of them sticks.

The "product" was the excuse. The infrastructure is the capability. The lesson is the keeper.

The observations I wasn't prepared for

The AI is fast but uncurious. It will happily execute any plan you give it, including plans that are subtly wrong. I caught a post about to publish that used a phrase I'd specifically asked to avoid — the agent didn't flag it. I found it on a final read at 11pm and rewrote it. You cannot outsource the taste layer, at least not yet.

Reviewing generated output is itself a skill. I got faster at spotting AI-y phrasing, invented details, and mismatched tone over the week. It's a new form of editing. Not intuitive at first.

Naming things still takes a human. Every time the agent offered three names for a feature, I rejected all three and picked something I'd been sitting on for weeks. Names need context the agent doesn't have.

Morale isn't automatable. When the launch didn't pop, the agent kept offering next steps. Useful infrastructurally, emotionally hollow. The feeling of "is this worth continuing" is not a prompt. It's a walk around the block.

And the big one — the AI reasons about markets like spreadsheets, not like people. It can tell you what exists, what sells, what converts, at what price. It cannot, on its own, picture a specific human on a specific afternoon and ask what would actually move them. That picture is the most expensive thing you need when shipping a product, and it's still yours to produce.

What I'm changing next

I'm not giving up on indie products. I'm changing the order of operations:

Audience first. I'm taking the personal account where I write about dev life, AI workflows, and Tokyo indie stuff seriously as the foundation. Whatever I ship next gets shipped to people who already know me, not to an empty internet.
Pain discovery before build. Any future product, I'll spend a week asking real people what currently annoys them, or delights them, or pulls their attention. The AI speeds up shipping; nothing speeds up finding a real emotional hook.
The heart-movement question, out loud. Every product idea from now on gets asked: Who does this move? In what moment? What do they feel — pain relief, desire, laughter, belonging? Could I name one specific person who would have that reaction? If I can't, I don't ship.
The counterfactual question, also out loud. If the person I'm selling this to has access to the same tools I'm using to build it, why do they still need me? This is where my shower realization came from, and I want to ask it early from now on.
Infrastructure as portfolio. Every script, template, and automation I build is reusable. I'll keep building these whether or not any single product works, because the infrastructure compounds independently of outcome.
Honest retrospectives, publicly. Including this one. Shipping a product that didn't catch on is only embarrassing if you pretend it didn't happen. Shared, it's data — and specifically, it's data about the shape of where AI helps and where it doesn't.

The meta-lesson

In 2026, execution isn't the bottleneck. Judgment is — and specifically, the kind of judgment that pictures a specific human feeling a specific thing at a specific moment.

The AI will build almost anything you ask it to. It will also tell you, sincerely and with good evidence, that the thing you're building has demand — because from where it's sitting, the market data says so and the product is well-made.

It will not tell you whether anyone's heart will move when they see it. That's not a question the AI asks on its own. It's still yours.

I ran this experiment to find out how far the AI could take me alone. The answer was: all the way to shipped, zero steps past. Shipped is the start line now, not the finish line. And the start line is still measured in heartbeats, not spreadsheets.

Three cups of tea. Still tired. Shipping the retrospective anyway.

I Have a ~/bin Folder With 30 Scripts I Don't Remember Writing

Kairi — Tue, 21 Apr 2026 15:32:26 +0000

I keep a folder at ~/bin/ full of shell scripts. There are 30-something of them. At least half were written by AI at my request. I don't remember most of them existing.

And that's fine. The folder isn't a catalog of tools I reference. It's a spill-cache for ad-hoc automation that turned out to be reusable.

Here's what's in there, how it got there, and why I stopped trying to organize it.

What's actually in the folder

I just ran ls ~/bin | wc -l. 34 files.

Sampling a few:

tasks — 80-line Python wrapper around a sqlite file that tracks what I'm mid-way through. I use it daily.
trim-silence — ffmpeg one-liner that cuts silence from audio files. I use it weekly.
rename-padded — rename numbered files to zero-padded form (post-1.md → post-001.md). I used it once, haven't touched it since.
gitwip — shows me branches older than 7 days with uncommitted changes. I run it every couple weeks when paranoid.
fetch-latest-ogimage — hits an API, downloads a PNG, optimizes it, renames it to today's date. I built it for a specific project six months ago.
note-today — opens ~/notes/YYYY-MM-DD.md in my editor, creating it if it doesn't exist. Muscle-memory now.
bulk-resize — batch-resize images in a directory with imagemagick. Used twice, staying forever.

Most of them are 5-30 lines. None are well-documented. Half have terrible names.

How they got there

The pattern is always the same:

I'm in the middle of something
I hit a papercut: "I need to do X to 40 files"
Instead of doing X 40 times or Googling for 10 minutes, I ask Claude Code for a one-liner
I paste the output into ~/bin/<guess-a-name> and chmod +x it
I use it, finish the task, close the terminal
I forget it exists

Weeks or months later, I hit a similar papercut and either:

Rediscover the old script (bin/ + tab completion shows me forgotten options)
Write a new one because I didn't know about the old one

Both are fine. The old script cost 90 seconds to write. If I forget and write a second version, I've spent another 90 seconds. At no point was there a high-cost step.

Why disorganization is the feature

I've tried organizing scripts before. I've had folders with media/, git/, file-ops/, subfolders, README files listing what's in each.

They all decay. I'd add a script and forget to update the README. I'd miscategorize something. The README would get out of sync with reality within a week.

What works: flat folder, grep-friendly names, trust that you'll rediscover via tab completion.

When I think "I need something for audio...", I type bin/ + a + tab. The options narrow. I find audio-normalize, audio-trim-silence, or nothing — and then I make a new one in 90 seconds.

The cost of a duplicate is lower than the cost of maintaining organization. So I don't maintain organization.

Why this is AI-compatible

The key unlock is that writing a script is now 90 seconds. Before AI, writing a small utility was a 10-20 minute task — enough friction that I'd "just do it manually this one time" instead of automating.

Now the calculus is flipped. Writing the script is faster than doing the task manually when the task is >3 repetitions. So I automate almost everything, and the folder fills up with one-off utilities.

The folder isn't a carefully curated toolkit. It's a fossil record of every mildly-annoying task I've hit in the last year.

The practical setup

For anyone who wants to replicate:

mkdir ~/bin if it doesn't exist
Add to .bashrc / .zshrc:

   export PATH="$HOME/bin:$PATH"

When you hit a repetitive task, ask Claude Code / any AI for a shell one-liner or short script
Save it to ~/bin/<some-name>, chmod +x
Don't organize. Don't document. Just let it grow.

Check the folder once a quarter for scripts that broke due to API changes or dependency updates. Fix or delete.

What doesn't belong in `~/bin`

Stuff that should go elsewhere:

Project-specific automation → lives in the project's scripts/ folder or package.json
Secret-dependent scripts → needs a proper ~/.config/X with chmod 600, not a bin/ script with hard-coded keys
Scripts other people on your team need → live in a shared repo
Anything that takes >1 minute to run → probably wants to be a proper CLI, not a one-off

My ~/bin/ is for single-user, self-contained, ad-hoc utilities. The rule is: if I had to explain it to someone else, it'd go somewhere else.

The meta-pattern

Every time I've tried to be disciplined about small automation, I've ended up doing less of it because the overhead of "doing it right" killed the flow.

The opposite works better: lower the bar, embrace chaos, trust rediscovery.

The folder is messy because the mess is cheaper than the organization. And the chaos is productive because each piece of chaos is 90 seconds of AI-assisted work that replaced 10 minutes of manual repetition.

34 scripts. I remember maybe 8 of them. The other 26 might never run again, or might run tomorrow when I type bin/ + tab and rediscover them.

Either way, the folder has paid for itself 100 times over.

Three cups of tea. Still tired. Shipping anyway.

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.

Forem: Kairi

Four Questions I Now Ask Before Building Anything With AI

The place where I now hesitate

Question 1 — Whose heart does this move?

Question 2 — If this customer has my tools, why do they still need me?

Question 3 — What is the AI refusing to surface on its own?

Question 4 — Am I reasoning about a market, or about a person?

The meta-lesson

What changed for me, concretely

Why Template-as-Product Is Structurally Hard in 2026

The template economics, pre-AI

What changed (the obvious part)

Who the category is supposed to be for, now

Candidate 1: Developer who can't design

Candidate 2: Agency or freelancer building client work

Candidate 3: Speed-first indie shipping an MVP

Candidate 4: Non-developer founder

Candidate 5: AI-averse developer

The pattern across all five

What this means for solo template shops

The obvious counter-argument

The quieter observation

What's actually defensible in 2026

What I'm doing instead

I Let an AI Agent Run a Product Launch for a Week. The Product Was Fine. Nobody Needed It.

The setup

What the AI actually did

The unease that I couldn't name

The bathroom realization

What the AI was actually doing (and wasn't)

The specific thing I learned about AI as a strategic partner

Shipping happened, nothing else did

What I gained that isn't the product

The observations I wasn't prepared for

What I'm changing next

The meta-lesson

I Have a ~/bin Folder With 30 Scripts I Don't Remember Writing

What's actually in the folder

How they got there

Why disorganization is the feature

Why this is AI-compatible

The practical setup

What doesn't belong in ~/bin

The meta-pattern

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."

What doesn't belong in `~/bin`

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

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

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