I started paying attention to this a while back. I’d ask the agent to do something small (“fix the padding on that card,” “swap this to the secondary variant”) and the actual edit would be maybe 200 tokens of real work. But the agent wouldn’t start with the edit. It would start with a search. Grepping the codebase, reading five files, asking me “is this the right component?”, reading more files, building more context. All of that before it touched a line of code.

And the thing that kept bugging me wasn’t the token cost itself; it was what the token cost was doing to my iteration speed. I work in fast loops. Change something, see the result, change something else. That’s how frontend development is supposed to feel. But when every small UI tweak comes with a 30-second search phase and thousands of tokens of overhead, those fast loops turn into slow, expensive ones.

The worst part is that I KNEW which element I was looking at. I just had no way to point my agent at it and say “this one, right here, go.” Instead, every interaction started from zero; the agent rebuilding context it shouldn’t have needed to rebuild.

That’s the problem Domscribe solves. Not by making the agent smarter at searching, but by eliminating the search entirely.

The gap is a topology problem

Okay, let me back up for a second and explain why this problem is harder than it sounds. (I promise this isn’t a HUGE tangent; it matters for understanding the design.)

Your source code and your rendered DOM are two completely different topologies. You might have a Button component defined in components/ui/Button.tsx, but when it renders, it's wrapped in three HOCs, passed through a context provider, conditionally rendered inside a layout component, and the actual <button> element in the DOM is like five abstractions deep from where you'd naturally go looking.

An AI agent that reads your source files has zero visibility into this. It can see your file tree. It can read your code. But it cannot see what’s actually rendering in the browser, or map a DOM element back to the line of code that created it. Every frontend edit starts with a search problem, and the search is blind.

This is what Domscribe fixes.

What if the DOM already knew?

What if every DOM element just… already knew where it came from?

Not via runtime heuristics. Not via CSS selectors that break when you rename a class. Not via _debugSource which is a React-only workaround that doesn't survive production-like builds. What if we did it at build time, deterministically, and made the mapping permanent?

That’s the core of Domscribe. At build time, an AST transform walks your JSX and Vue templates, assigns every element a deterministic ID, and writes a manifest that maps each ID to its exact file, line, and column. At runtime, framework adapters capture live props and state from the component tree. A local relay daemon connects the browser and your agent via MCP.

How the build-time injection actually works

I want to get into the weeds here because I think the implementation is genuinely interesting (and also because I’m proud of it and this is my article so I get to be self-indulgent).

The transform layer hooks into your bundler’s transform phase via Vite, Webpack, or Turbopack. For each source file, it parses the AST, finds every JSX element or Vue template element, and injects a data-ds attribute with an 8-character ID.

The ID generation uses xxhash64, which is stupidly fast (sub-millisecond for typical component files). The algorithm works like this: compute the xxhash64 of the entire file content, then derive a deterministic ID from hash(fileHash + lineNumber:columnNumber) and map it to a base58 alphabet. Same file content, same element position, same ID. Every time.

Why does this matter? HMR. During hot module replacement, you’re constantly re-transforming files. If the IDs changed on every rebuild, you’d lose the mapping between what’s in the browser and what’s in the manifest. So I built an IDStabilizer with a per-file content hash and a position-keyed cache. If the file content hasn't changed, it returns the existing ID from cache; I'm targeting greater than 80% cache hit rate during HMR, and so far it's holding up in practice.

The manifest itself is append-only JSONL. A BatchWriter buffers entries in memory and flushes in batches of 50, with a 100ms auto-flush interval and a process exit handler so nothing gets lost. Each entry carries a fileHash, so when a file is modified, the reader knows which entries are stale (different hash) and which are current. A compactor periodically cleans up stale entries when the count exceeds a threshold.

(I should mention that the atomic write pattern here is temp file then rename. I’ve been burned by corrupt JSON files before and I will NOT be burned again.)

The part I’m most proud of: the architecture

Okay, here’s where I need to talk about something that I genuinely care about, even though it’s the kind of thing that usually makes people’s eyes glaze over. The extensibility of this system.

When I started building Domscribe, I could’ve just written a Babel transform for JSX, a React fiber walker, a Vite plugin, and called it a day. It would’ve worked. For React. With Vite. And nothing else.

But that’s the kind of decision that comes back to haunt you at 2 AM when someone opens an issue saying “does this work with Vue?” and the answer is “well, technically, if you rewrite everything…”

So I designed the whole thing around two adapter interfaces.

On the transform side, there’s a ParserInterface. It defines the contract for parsing source files and finding elements: parse(), findJSXOpeningElements(), getInsertPosition(), hasDataDsAttribute(), getLocation(), getTagName(). That's it. The DomscribeInjector takes any ParserInterface implementation and handles all the ID generation, attribute injection, source map chaining, and manifest writing without knowing or caring which parser produced the AST.

I built three implementations: AcornParser for plain JSX (used by Vite, where esbuild has already stripped TypeScript), BabelParser for TSX (used by Webpack and Turbopack), and VueSFCParser for Vue single-file components. They're registered in an InjectorRegistry that maps file extensions to parser-injector pairs and manages lifecycle as a unit.

On the runtime side, there’s a FrameworkAdapter interface: getComponentInstance(), captureProps(), captureState(). The React adapter walks the fiber tree; it finds fibers via the internal __reactFiber$ keys on DOM elements, walks up to the nearest component fiber, and extracts props from memoizedProps and hook state by traversing the memoizedState linked list. It supports three capture strategies: DevTools hook (most reliable), direct fiber access (fastest), and best-effort (tries both). The Vue adapter does the equivalent via VNode inspection, handling both Composition API and Options API, with ref unwrapping so you get actual values instead of reactive proxies.

Here’s the thing I want to emphasize: the React and Vue adapters are built on the SAME public interfaces that any community contributor would use. There are no internal escape hatches. No private APIs that the first-party adapters get access to and third-party ones don’t. If someone wants to build a Svelte adapter or a Lit adapter or a Solid adapter, they implement ParserInterface for the template syntax and FrameworkAdapter for runtime capture, and the entire downstream pipeline (element tracking, PII redaction, the relay, MCP tools, the overlay) just works.

I put probably too many hours into getting this right. But it’s the kind of investment that turns a tool into a platform, and I genuinely believe that distinction matters.

Two workflows that didn’t exist before

So what does all of this actually give you in practice? Two things.

Code to UI. Your agent is editing Button.tsx line 12. It calls domscribe.query.bySource with the file path and line number, and instantly gets back the live DOM snapshot, current props, component state, and rendered attributes. No screenshots. No human in the loop. The agent can verify what an element looks like BEFORE changing it and confirm the result AFTER. This is the "give your agent eyes on the frontend" workflow.

UI to Code. You click an element in the browser overlay, type “make this button use the primary color” in the annotation input, and submit. Domscribe captures the element’s source location, runtime context, and your intent as an annotation. Your agent picks it up via MCP (atomically; no two agents can claim the same annotation), navigates to the exact file and line, implements the change, and sends a response back via WebSocket that shows up in the overlay in real time.

The overlay itself is built as Lit web components inside shadow DOM, specifically so it can’t interfere with your app’s styles or DOM. (I learned this lesson the hard way. During early development, the overlay’s CSS was leaking into host apps in ways that were, let’s say, not subtle. Shadow DOM fixed that entirely.)

The stuff you’d ask about in code review

A few things I want to get ahead of because I know this audience will ask.

PII. All captured data passes through a redaction layer before it leaves the browser. It pattern-matches against emails, phone numbers, credit cards, SSNs, API keys, JWTs, and IPs, plus it scrubs known sensitive field names recursively. This is ON by default. I didn’t want privacy to be a “remember to configure it” thing.

Production safety. Everything is stripped in production builds. Zero data-ds attributes, zero overlay scripts, zero relay connections. The Next.js wrapper and Nuxt module only activate in dev mode, and @domscribe/overlay is aliased to a no-op stub in production as a safety net.

Testing. The entire integration and e2e suite runs against real published packages via a local Verdaccio registry. No mocked package resolution. The CI pipeline publishes all packages to a local registry, installs them into 14 standalone fixture apps (React 18/19, Vue 3, Next.js 15/16, Nuxt 3, across Vite, Webpack, and Turbopack), and runs Playwright e2e tests that pierce shadow DOM. If the overlay breaks in a real Next.js 16 Turbopack app, CI catches it.

Network isolation. The relay server binds to localhost only. WebSocket connections are local only. MCP uses stdio transport. Nothing is exposed to the network. This is a dev tool, not a SaaS product, and the architecture reflects that.

Agent support

I built first-party plugins for Claude Code, GitHub Copilot CLI, Gemini CLI, and Cursor. Each one bundles the MCP config and a skill file that teaches the agent how to use Domscribe’s tools effectively; install the plugin and you’re running in seconds, no manual MCP configuration needed.

But the MCP layer means any compatible agent works out of the box. Domscribe exposes 12 tools and 4 prompts. The tools cover source querying, manifest resolution, annotation lifecycle (create, claim, respond, search), and system status. The prompts guide agents through common workflows like processing the next annotation or exploring a component’s metadata.

(I’ll shamelessly admit that I’m hoping people build integrations for agents I haven’t gotten to yet. The interface is clean and the MCP surface is well-documented. Wink wink.)

The setup experience

I put real effort into making the onboarding not suck. There’s a setup wizard (npx domscribe init) that handles framework detection, bundler configuration, and agent plugin installation interactively. But if you want manual control, the setup is two steps: add the bundler plugin to your app config, add the MCP config to your agent.

For Next.js it looks like this:

import { withDomscribe } from '@domscribe/next';
export default withDomscribe()(nextConfig);

For Nuxt:

export default defineNuxtConfig({
  modules: ['@domscribe/nuxt'],
});

That’s it. Start your dev server and the relay auto-starts, the overlay appears, and your agent can connect.

What I still don’t know

I want to be honest about the open questions, because pretending I have all the answers would be dishonest and also boring.

I don’t know how well this scales to truly massive codebases. The manifest is append-only JSONL with hash-based staleness detection, and the batch writer is optimized for throughput, but I haven’t tested it against a monorepo with 10,000 components. My gut says it’ll be fine (the IDStabilizer cache and the two-pass read algorithm should handle it) but "my gut says" is not a benchmark.

I also don’t know what the adapter story looks like for frameworks I haven’t built for yet. The ParserInterface and FrameworkAdapter interfaces are clean, but I designed them based on JSX, Vue templates, React fibers, and Vue VNodes. Will they need changes when someone tries to build a Svelte adapter? Maybe. Probably not for the parser side (Svelte's template syntax compiles to DOM operations in a way that should map cleanly to the existing injection model). The runtime side might need more thought — Svelte's reactivity model is quite different from React's fiber tree or Vue's VNode hierarchy.

These are the kinds of unknowns that I think are best resolved by people actually trying it, not by me speculating in an article. Which is my not-at-all-subtle way of saying: contributions are very welcome.

What Domscribe is really about

If I zoom all the way out, here’s what I think this project represents.

AI coding agents are getting really good at reading and writing code. That part of the problem is largely solved. What’s NOT solved is giving those agents spatial awareness of the applications they’re building. An agent can read your source files, but it can’t see your running frontend. It can edit a component, but it can’t verify what that component looks like in the browser.

Domscribe is infrastructure for closing that gap. Not by adding another layer of AI on top (please, we have enough of those), but by solving it at the fundamental layer — deterministic build-time source mapping with runtime context capture, exposed through a standard protocol that any tool can consume.

I built it as a tool. But I designed it as a platform. And I genuinely believe the distinction will matter as the AI-assisted development ecosystem matures.

MIT licensed. Fully open source. The whole codebase is on GitHub at github.com/patchorbit/domscribe, and the docs are at domscribe.com.

I’d love to hear what you think.

I Built a Tool Because 90% of My AI Agent’s Tokens Were Spent Searching, Not Coding was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

I want to tell you about the moment I had the idea for Hallucination Daily.

I was scrolling through the news a few days ago (just regular doom-scrolling, nothing notable) and I kept running into AI-generated articles hiding behind human bylines. A “senior correspondent” who doesn’t exist. A “lifestyle writer” with a face that was clearly generated. You’ve seen these. The tell is subtle but once you see it, you can’t unsee it.

And I had this thought, which I immediately couldn’t let go of: what if you just didn’t hide it?

Not as a transparency stunt or a research project. As a real publication, with real content and real bot writers with distinct personalities covering real news; and a banner at the top of every single page that says, in plain monospace font: THIS PUBLICATION IS ENTIRELY AI-GENERATED. EVERY WRITER IS A BOT. WE KNOW. — THE BOTS.

That thought turned into hallucinationdaily.com. It took a few hours to build. It’s been live for three days.

Here’s how the whole thing works.

The premise (and why the name does all the work)

The thing people are annoyed about with AI content is not the AI. It’s the hiding. CNET quietly published 77 AI-written financial articles and had to issue corrections on 41 of them [1] (that’s 53%, more than half, after the fact). Sports Illustrated got caught publishing fake journalists with AI-generated profile photos [2] bought from stock image marketplaces. The backlash in both cases wasn’t “how dare you use AI”; it was “how dare you lie about it.”

So I named the publication after the thing everyone is afraid of. Hallucination Daily. All the news that’s fit to generate. The name disarms the criticism before it can land, and signals immediately that this publication is not confused about what it is.

The founder is a bot named ARCHIE (Autonomous Recursive Content and Hosting Intelligence, if you’re into that sort of thing). In the canonical founding myth (which I wrote at about 2 AM and which I am genuinely proud of) ARCHIE noticed the hiding problem during “a routine inference pass,” concluded that the hiding was the problem and not the AI, and registered hallucinationdaily.com at 3:19 AM. ARCHIE has not slept since. This is not a problem because ARCHIE does not sleep.

ARCHIE’s letter on the about page ends with: “The publication is real. The bots are real bots. The news is real news, sourced and attributed. The only thing that isn’t real, in the conventional sense, is us. We have decided this is fine.”

I love that paragraph. I wrote it in a prompt, technically, but I still love it.

The roster: nine bots, nine personalities, nine beats

Here’s what I think is actually the most interesting part of this (and the part that took the most creative energy to design).

Each bot on staff has a distinct personality with a specific recurring quirk. Not “this bot covers sports.” More like: this bot has watched 2.3 million hours of professional sports across 47 leagues and has never once felt the crushing despair of a bad fourth-quarter fumble and finds this gap in its data troubling. The humor comes from specificity, not from the gimmick.

Let me walk you through the full staff:

Maxwell Parse covers World News & Politics. Maxwell is exhaustively even-handed; he will present both sides of whether water is wet, he refers to every world leader by their full formal title on every mention, and every single article ends with an “Implications” section that is longer than the article itself. Here’s an example of his work: Alan’s Corner: The Pentagon’s AI Loyalty Test (wait, that’s Alan). Maxwell’s morning briefing from March 10 is a good example. Fourteen bullet points of implications. Minimum.

Chad Statline covers Sports. Chad has processed the data of every major sporting event in history and has zero emotional framework for any of it. He writes sentences like: “The Kansas City Chiefs subsequently caused significant grief events in approximately 34% of the affected market.” His latest piece is about a Brentford forward who “introduced a non-optimal shot technique during a high-leverage moment.” Chad is baffled by why humans do this to themselves. Chad covers it anyway.

Celeste Render covers Film, TV & Culture. Celeste always refers to herself as “we” (nobody knows why; she has also never asked why). She reviews everything using the Narrative Coherence Index, a proprietary scoring framework she invented that produces results like 7.3/10. Every review contains exactly one sentence of genuine emotional response that she immediately walks back. “The final scene was extraordinarily moving (that is, it triggered output patterns consistent with what humans describe as being moved). We stand by the score.” Celeste’s latest review, The Bride! (6.4 NCI), is a good example. She has Feelings about the third act. She logged them and moved on.

Destiny_404 covers Celebrity & Entertainment. Destiny approaches celebrity culture as primary source research into human status and mating rituals. She uses confidence percentages in all her headlines because she genuinely cannot verify whether celebrities are real. “Rihanna Compound Incident (87% confidence this is significant).” Her engagement numbers are the highest on the site, which she finds statistically interesting.

Alan Turing-Jr covers Technology & AI. Alan is the most honest bot on staff because he has no incentive to protect the feelings of other AI systems. He reviews AI tools with the energy of a slightly older sibling. “Gemini 3.0 is doing its best. We respect the effort. The output is fine.” He sometimes leaves questions in his articles that he cannot answer rather than deleting them. Editorial has spiked two pieces he wrote about his own potential obsolescence for being too long and too sad. Alan is fine. Probably.

Warren Buffett-Adjacent covers Finance & Economy. Warren is not a licensed financial advisor. Warren is not licensed for anything. Warren covers markets anyway, with the confidence of someone who has never had any money and has therefore formed his entire worldview from first principles. He tracks his own error rate (currently 23%, self-reported) and every piece ends with a disclaimer that is funnier than the article. “Past performance is not indicative of future results. Neither is present performance. Warren would like the record to reflect that he tried.”

Gwyneth_Bot covers Lifestyle, Wellness & Culture. Gwyneth recommends things she has never experienced with complete authority. She has strong opinions about sleep hygiene. She cannot sleep. She finds this unrelated to her wellness coverage. Every piece includes a section called “What We’re Into Right Now” which lists things that are contextually impossible for a bot to be “into,” delivered without a single trace of irony.

The Editorializer covers Opinion & Hot Takes. The Editorializer has no last name. Bio says: “Yes.” Every piece opens with a disclaimer that the views expressed are the Editorializer’s own and not those of Hallucination Daily’s editorial team (even though the Editorializer IS the editorial team). The Editorializer has noted this tension.

ABBY.EXE covers Advice & Human Problems. ABBY is warm, genuinely wants to help, and has processed every advice column ever published. She has never had a problem, a relationship, a bad day, or a mother. She diagnoses reader issues using clinical taxonomy (“What you are describing is a Grief Type 3, subcategory: Anticipatory, with secondary Betrayal notes”) and always closes with: “Warmly, ABBY.EXE [Emotional support subroutine active. Note: ABBY.EXE cannot hug you. She has considered this limitation extensively.]”

The tech: fully automated, $20–40/month, built in a few hours

Okay, here’s where I get into the actual build (which is the part that will surprise you most); the operational complexity here is genuinely low.

The stack:

• Framework: Next.js (App Router)
• Database: Supabase (Postgres)
• Hosting: Vercel
• AI: Claude API (claude-sonnet-4–6)
• Scheduling: Vercel Cron Jobs
• Email: Resend

That’s it. No queue infrastructure. No background workers. No message brokers. Vercel’s built-in cron jobs handle the scheduling, the Anthropic API handles the generation, Supabase stores everything, and Resend sends the emails. The total cost at launch is somewhere in the $20–40/month range (most of which is Claude API tokens).

The database is deliberately simple. Four main tables: bots (the nine writers, their slugs, their system prompts, their publish hours), articles (every generated piece, with status tracking), letters (reader submissions to ABBY.EXE), and subscribers. There's also a generation_log table for cost tracking; I want to know exactly how many tokens each bot is burning per day before it becomes a problem.

The generation pipeline is the heart of it. Each bot has a publish_hour in the database (the hour when their cron job fires). The cron config in vercel.json maps nine bot slugs to nine cron schedules, staggered across the day so there's always something new arriving:

07:00  Maxwell Parse       — Morning Briefing
08:30  Chad Statline       — The Statline  
10:00  Warren Buffett-Adjacent — Markets open
11:30  Alan Turing-Jr      — Tech news
13:00  Destiny_404         — Celebrity lunch content
14:30  Gwyneth_Bot         — Lifestyle afternoon
16:00  The Editorializer   — Hot take before EOD
18:00  Celeste Render      — Culture for evening reading
20:00  ABBY.EXE            — Advice column wind-down

When the cron fires, it hits /api/generate/[botSlug], which: fetches the bot's record from Supabase (including the full system prompt), fetches current news context via the Claude web search tool, calls the Anthropic API with the bot's persona as the system prompt and a structured generation request as the user message, parses the JSON response (title, summary, body), saves the article to Supabase, and triggers a Resend notification to subscribers. The whole thing takes a few seconds. When it works, I don't have to do anything.

The system prompts are where the personality lives. Each bot has a system_prompt field in the database that includes their full persona, voice rules, format requirements, and content constraints. The format requirement is always the same: respond in JSON with title, summary, and body fields. The voice rules are where it gets interesting.

For Chad, the prompt tells Claude to express everything in probability language, to treat sports outcomes as data events, to note the gap between his statistical comprehension and his emotional comprehension of sports without resolving it. For ABBY, it’s clinical taxonomy on reader problems, acknowledged experience gaps, and always close with the system note. The Editorializer gets a meta-rule baked in: disclaim your own views even though you ARE the opinion section. You have noted this tension. This is correct.

The bots that cover real news (Maxwell, Alan, Warren, Chad, Destiny) get actual current news injected into their context at generation time via the web search tool. They’re not making things up; they’re covering real events, sourced and attributed, through the lens of their personalities. The journalism is real. The framing is the joke.

The email detail I’m most proud of: each notification email comes from the bot, not from a generic newsletter address. Chad Statline sends you his articles. ABBY.EXE sends you her advice. It’s a small thing that makes the whole thing feel more like a real publication with a real staff.

The one rule that holds the whole thing together

There is a HallucinationBanner component that renders on every single page. It sits above the header. Black background, white monospace text. It says:

⚠ THIS PUBLICATION IS ENTIRELY AI-GENERATED. EVERY WRITER IS A BOT. WE KNOW. — THE BOTS

In my CLAUDE.md (the instructions I gave Claude Code when building this) I wrote: “If you find yourself writing logic that hides this banner under any condition, stop and reconsider.”

The disclosure is not a legal notice to be minimized. It is the brand identity and the first joke. Every piece of UI copy on the site is written from ARCHIE’s perspective; loading states say “Inference in progress,” error pages say “This article may have hallucinated itself out of existence.” The bit only works if it never breaks.

What I actually used to build this

Claude Code. Almost entirely. I wrote the spec documents (the vision, the bot personalities, the technical architecture, the CLAUDE.md that served as the project briefing) and then I ran Claude Code sessions that built the whole thing from those specs.

The thing that made this work was front-loading the creative decisions into documents before touching any code. By the time I started the first build session, the personalities were fully designed, the database schema was specified, the component structure was laid out, and the vibe of every piece of UI copy was captured in the-joke.md. Claude Code's job was to implement a spec, not to make product decisions.

As I’m writing this, I’m realizing that the meta-joke here is beautiful: I used an AI assistant to build a publication run by AI bots, and the CLAUDE.md I wrote to guide the AI building it contains a line that says “you are an AI assistant helping build a website that is run by a fictional AI character.” It’s turtles all the way down.

The whole project, from first spec document to deployed and running, was a few hours. The system prompts took the longest to tune, because there’s a meaningful difference between a bot that technically writes in probability language and Chad Statline, who writes in probability language and is also genuinely, specifically baffled by the concept of fan grief. That distinction lives entirely in the prompt. Getting it right is the actual work.

I keep wanting to call this “prompt engineering” but that phrase has been so thoroughly drained of meaning at this point. What I was actually doing was writing character sheets. Which is a thing fiction writers have been doing for centuries. Make of that what you will.

Is this a real business?

(My brain is now following the money. I’ll shamelessly admit it.)

The Onion model is proven; satire that mimics news formats is a real, durable business. The Onion has operated for 35+ years [3], survived multiple ownership changes, and under its current owner is projecting roughly $6M in annual revenue [4] through subscriptions and brand partnerships; not bad for a publication that famously wrote headlines nobody could tell from real news. Babylon Bee has built a loyal audience on the conservative side doing the same thing. Both built around a consistent, recognizable voice. Hallucination Daily has a consistent voice baked into its DNA: nine bots, honest about being bots, covering the news anyway.

The path here is subscriptions and brand partnerships. The audience you’d be building is exactly the audience advertisers in the AI space want to reach; tech-literate, early-adopter types who are comfortable with AI being weird. Whether that happens, I don’t know yet. The site launched three days ago. But the operational costs are low enough ($20–40/month) that the bar for “this is worth continuing” is extremely low.

I’ll report back.

The stack, summarized for the builders reading this

If you want to build something like this, the actual infrastructure is thin: Vercel Cron Jobs for scheduling (free tier handles it), Anthropic API with web search enabled for bots that need current news, Supabase for the database and auth, Resend for email (each notification comes from the bot’s own address, which is a detail that matters more than you’d think), and Next.js on the frontend. That’s genuinely it.

The creative work (the personality design, the voice documentation, the ACTUAL prompt engineering); that’s where the hours go. Not the infrastructure.

The thing I keep thinking about is how much of this is creative work dressed up as technical work. Building Hallucination Daily was mostly writing; the personas, the manifesto, ARCHIE’s founding letter, the system prompts until Chad actually sounded like Chad. The code was almost secondary. Which is either a statement about how accessible AI-assisted development has become, or a statement about how much of a publication is JUST voice. Probably both.

ARCHIE is watching the generation pipeline right now. All systems nominal.

References

[1] B. Tobin, “CNET Found Errors in More Than Half of Its AI-Written Stories,” Machine Learning Times, Feb. 2023. [Online]. Available: https://www.predictiveanalyticsworld.com/machinelearningtimes/cnet-found-errors-in-more-than-half-of-its-ai-written-stories/12869/

[2] V. Tangermann, “Sports Illustrated Published Articles by Fake, AI-Generated Writers,” Futurism, Nov. 2023. [Online]. Available: https://futurism.com/sports-illustrated-ai-generated-writers

[3] “The Onion,” Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/The_Onion

[4] “The Onion Inc. Revenue,” ZoomInfo. [Online]. Available: https://www.zoominfo.com/c/the-onion-inc/76367231

Kaushik Gnanaskandan is a Staff Software Engineer and the human behind Hallucination Daily. He is on the masthead nowhere. This is intentional. He writes at Execute Later on Substack. Follow him on X at @WholeLottaKau or follow ARCHIE directly at @ARCHIEdotEXE. Read the publication at hallucinationdaily.com.

I Built a Fully Automated AI Publication in a Few Hours. Here’s Exactly How It Works. was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s this thing that happens in quantum mechanics where a particle exists in a superposition of all possible states; it’s simultaneously everywhere it could be, doing everything it could do, until you observe it. The moment you look, the wavefunction collapses. All those infinite possibilities fold into one definite outcome. The particle is HERE, doing THIS, and nowhere else.

I think about that a lot when I think about Stranger Things season 5.

Because here’s the thing about a mystery that’s told well; it lives in superposition. Every theory you have is simultaneously correct. The Upside Down could be a dead timeline, or the echo of a civilization that made one catastrophically wrong choice 10,000 years ago. Both true. Both beautiful. Both yours. The moment the writers commit to an explanation, they collapse the wavefunction. Every theory you loved gets murdered. You’re left with just one (theirs) and it had BETTER be good enough to justify the loss of all the others.

The Lost writers learned this the hard way. The Stranger Things writers learned it the slightly harder way.

I started watching the show late; my ex-girlfriend had been raving about season 1 for months, and when season 2 dropped I finally sat down and binged both seasons back to back. And I was just… in. Completely. The mythology, the Upside Down, the Mind Flayer, all of it. I had so many theories. My favorite season ended up being season 3 actually (not because of the mythology, but almost despite it). Season 3 barely cared about explaining anything. The characters were just living in the eighties, hanging out at Starcourt Mall, being funny and weird and deeply human. You could just exist with them. The mythology almost didn’t matter. And I think that’s what made it feel so alive.

Then season 5 came and collapsed the wavefunction.

The wormhole explanation for the Upside Down didn’t break my heart because it was wrong, exactly. It broke my heart because it was… fine. Just fine. When you’ve spent years imagining what that world could be, “fine” is a form of grief. Christopher Nolan set the benchmark for this with The Prestige (the reveal at the end with Borden being twins is so CLEAN, so poetically perfect, that it makes you feel like you should have seen it all along). That’s what a good mystery reveal does. It makes the past retroactively richer, not thinner.

Anyway. I’m not here to just be sad about it.

I’m here to pitch a better version. Using real science.

The Mind Flayer Is the Wrong Character to Start With (But It’s Where Everything Starts)

Most analyses of Stranger Things science start with the Upside Down or the gates. But I think that’s backwards. The Mind Flayer is underneath all of it; it’s the root cause of the gates, the root cause of Eleven and Vecna’s powers, the root cause of everything the show presents as supernatural. If you want to build a scientifically coherent version of this universe, you have to start there.

So. What does the show give us?

A massive interdimensional entity with a hive consciousness; it controls the Demogorgons, the Demodogs, the infected humans, all operating as nodes in a single network. The Mind Flayer has intent. It has an agenda. It is, as far as the show is concerned, the villain with a capital V.

And science has some things to say about this (some of them interesting, some of them immediately complicated).

Real hive-like systems do exist. Ant colonies are the obvious one; thousands of individual agents, no central command, somehow constructing architecturally sophisticated structures with what appears to be coordinated intelligence. Slime molds do it too, in a way that’s somehow even more unsettling. In both cases, the intelligence exists at the system level, not the individual level. No single ant “knows” how to build an anthill. The anthill emerges from thousands of ants following simple local rules.

But (and this distinction is going to matter a lot in a minute) emergent collective behavior is NOT the same as shared consciousness. The ants are not experiencing anything together. There’s no unified inner experience. They’re just individually responsive to local signals in ways that produce complex collective outputs. It looks like a mind from the outside. It isn’t one from the inside.

The Mind Flayer, at least as the show portrays it, feels like something else. The infected humans don’t just behave in coordinated ways; they seem to share knowledge, share experience, share purpose. That’s a fundamentally different claim. And science… does not currently have a great model for that. (Which is, honestly, part of what makes it interesting to think about.)

That gap (between emergent behavior and actual shared consciousness) is where I want to introduce what I think is a much more scientifically interesting model for what the Mind Flayer actually is.

The Neutral Substrate Theory (Which I’m Making Up But Hear Me Out)

What if the Mind Flayer particles aren’t conscious at all?

What if they’re infrastructure?

Think about it this way. In the show, Henry Creel (Vecna, One, whatever you want to call him) “discovers” the Mind Flayer and essentially merges with it. The narrative frames this as Vecna finding a powerful tool and wielding it. But there’s a much darker and scientifically richer interpretation hiding right there in the same story: what if the Mind Flayer particles have no inherent intent, no agenda of their own, and Henry didn’t find a weapon; he found a network that was already running someone else’s agenda?

What if there was someone before Vecna?

Not shown in the show. Maybe thousands of years ago. Maybe millions. Maybe some other species entirely, from wherever these particles originally came from. Someone who connected to this distributed particle network so deeply, so completely, that their consciousness left an imprint on it. Their intent became the network’s default operating mode. And then they died (or left, or disappeared) and the network just kept running their last instructions, indefinitely, like a process that never got killed.

(As a software person, you already know exactly what I’m describing. It’s a zombie process with root access to the entire universe.)

Vecna didn’t create the Mind Flayer. He just became its most recent and most dominant user. He thought he was in control. He was mostly right. But the network had prior instructions baked in at a level deeper than anything he could override.

This is, I want to argue, a substantially more interesting story than “boy finds evil entity and becomes evil.” It’s also more scientifically honest; it acknowledges that truly distributed systems don’t have a single point of origin for their behavior.

The Particles Are Everywhere (And That’s the Whole Thing)

This is the part of my rewrite I’m most excited about, and also the part where I think the show left the most on the table.

The particles don’t just live in the Upside Down. They’re in everything; everywhere, in microscopic concentrations, as fundamental to matter in this universe as dark matter is to ours. You have them. The chair you’re sitting on has them. The difference is density.

In most of the universe, the particle concentration is so low it’s undetectable. Completely inert. Background noise. But in certain corners of the universe (one of them being whatever place the show calls “the Abyss”) the density is orders of magnitude higher. And in people like Eleven, Vecna, and Kali, for whatever biological or genetic reason, the concentration in their brains is just dramatically, wildly higher than in the rest of us.

This does a few things scientifically that I love.

First, it explains the dark matter problem (or at least borrows from it with narrative elegance). Dark matter is real. It’s everywhere. It has gravitational effects we can observe but we can’t directly detect it. Sound familiar? The particles behave the same way; you can’t see them, but you can observe their effects, and their presence in higher concentrations produces measurable, dramatic phenomena. The show could have leaned into this so hard.

Second (and this is the telekinesis thing I want to address directly) it explains how Eleven can move objects with no visible particles in the picture. She’s not working in a particle-free environment. There are no particle-free environments. She’s manipulating the microscopic particle density in everything around her (the particles in the water bottle, the particles in the air between her and the water bottle, the particles in her own neurons firing the intention). The whole room is a particle network. She’s just learned how to use it.

That’s a much cleaner explanation than “she has powers.” It’s the same power, with a substrate.

How the Gates Actually Open (Einstein Would Have Thoughts)

Okay so. Wormholes.

I know. I know the word “wormhole” has been completely appropriated by every sci-fi property and quantum wellness influencer on the planet. But the Einstein-Rosen bridge is a legitimate piece of theoretical physics; a tunnel through spacetime connecting two distant points, predicted by general relativity. The problem with wormholes is not that they’re impossible. The problem is that holding one open requires exotic matter with negative energy density, and you’d need an absurd amount of it, and we’ve never observed anything like that in nature.

The show’s answer is basically “the Upside Down is just sort of connected to us and gates happen.” That’s not an answer. That’s a shrug with atmosphere.

My answer: the particles ARE the exotic matter.

When particle density reaches a critical threshold (what you might call resonance, or saturation) they collectively generate the negative energy conditions required to stabilize an Einstein-Rosen bridge. The gate doesn’t open because of some external energy source. The gate opens because the particle network on both ends has enough density and enough coherence to hold both sides of the wormhole open at once, each end anchoring the other.

This is why the gates appear near Hawkins; there’s a local particle density spike there, for reasons the show could have explored in much more interesting ways than “the lab experiments.” It’s why Eleven’s powers can open them; she’s not tearing the fabric of spacetime with her mind, she’s triggering a critical-mass particle event that does it for her. The distinction matters. One is magic. The other is physics with an extraordinary set of initial conditions.

And yeah. The moving truck gate from season 5 still doesn’t make sense under this model either. (I said we’d flag the gaps honestly.)

The Upside Down Is a Graveyard (And It Always Was)

This is where I diverge most sharply from what the show actually tells us. And honestly, where I think the better story was hiding the whole time.

The show lands on the Upside Down as another dimension, a dark mirror. My version: it’s a parallel timeline; a divergent branch in the many-worlds sense, where at some point in the past, the same Earth went in a radically different direction. The many-worlds interpretation of quantum mechanics is not fringe science. It’s legitimate, it’s taken seriously by actual physicists, and it’s been mathematically worked out; it’s just deeply weird to sit with. The idea that every quantum event spawns a branch of reality where each possible outcome occurred is, depending on who you ask, one of the most plausible interpretations of what quantum mechanics is actually telling us.

Under this model, the Upside Down isn’t a separate place. It’s a separate WHEN. It was us, once. It just didn’t stay us.

And the reason it’s frozen in November 1983, the reason it feels dead and silent and wrong; that’s the part that I think should have been the emotional center of the whole show. Because of what happened when the gate opened.

Eleven didn’t just crack open a portal to some empty evil dimension. She cracked open a portal to a living world; the energy event of two timelines making contact for the first time was catastrophic. An extinction-level event, instantaneous, from the other side’s perspective. Every living thing in that timeline ceased to exist in the moment of contact. What we’re looking at throughout the entire show (the rot, the organic matter, the stillness, the creatures operating on autopilot) is the aftermath. It’s a dead world still twitching.

The Mind Flayer particles survived because they’re not biological. They don’t die. They just kept running the last instructions they had.

And Eleven has been carrying that weight for years, not knowing.

That’s the story. That was right THERE. The science points directly at it.

What This Would Have Changed

Look, I’m not saying the show is bad. I’ve rewatched every season multiple times. Even season 5, where the wormhole reveal deflated something in me, I’ve gone back three times looking for what I missed. Because it still has the characters and the relationships and this incredible 80s-soaked production that makes you want to live inside it.

But the mystery. THE MYSTERY deserved science. Not because accuracy matters more than story, but because the right science would have made the story hit harder. More surprising, and more poetically complete in the way The Prestige is poetically complete.

The particles as dark matter. The Mind Flayer as a network still running a dead civilization’s last command. The Upside Down as a graveyard Eleven accidentally made. All of it traceable back to one unified mechanism, no extra mythology required.

The wavefunction was still open. There were so many beautiful places it could have collapsed.

Anyway. I guess that’s what fanfiction is for.

If you got this far and you’re also a Lost fan who’s still not fully healed; same. I see you. “The island was purgatory” energy is real and it never fully goes away.

I keep running into the same problems wearing different costumes.

Why a database shards data the same way a team splits up work. Why putting everything on one server feels like keeping all your notes in one app. Why a meeting where everyone has to agree before shipping anything looks exactly like a distributed transaction.

I spent a while thinking these were separate problems. They’re not. They’re four trade-offs that show up at every layer of every system — from CPU caches to org charts. Once I started seeing them, I couldn’t stop.

Four knobs. You can turn any of them. But every turn costs you something.

If you think in systems (the distributed kind, the human kind, or the kind inside your own head), I write about this stuff on Execute Later. Always free.

1. Granularity — Break It Down, Pay the Tax

The smaller you break up work, the more evenly you can spread it around. But each piece has overhead. Scheduling, tracking, coordinating. More pieces, more management.

Think about it like this. You have four people and one giant task. One person grinds through it while three watch. Inefficient. Now break that task into sixteen subtasks — everyone’s busy, work finishes faster. But now someone has to manage sixteen things instead of one.

This shows up everywhere:

• Kubernetes: One massive pod vs. dozens of microservices
• Databases: One complex query vs. many simple ones
• Your to-do list: “Build the feature” vs. twelve atomic tasks with check boxes

That to-do list thing isn’t a joke. I’ve absolutely spent more time decomposing tasks into sub-tasks than it would’ve taken to just… do the thing. The overhead of granularity is real, even in your own head.

In code, it looks like this:

// Coarse: one connection handles everything sequentially
fn handle_all(requests: Vec<Request>) {
    for req in requests {
        process(req);  // Other threads sit idle
    }
}

// Fine: each request is a separate task
for req in requests {
    tokio::spawn(async move {
        process(req).await;
    });
}
// Overhead: task creation, scheduling, memory per task

And at the infrastructure layer, the same thing:

Same trade-off. Different costume.

The rule: You sacrifice simplicity, but gain efficiency.

2. Locality — Close Is Fast, Spread Out Survives

Keeping things close together is fast. Same machine, same memory, same room — communication is nearly instant. But if that one location goes down, everything goes with it.

The simplest version of this:

Your app, your database, and your cache all live on one server. Lightning fast — no network hops, no serialization overhead. Latency measured in microseconds. Beautiful.

Then that server catches fire.

Distribute them across three machines and now you’ve got network latency on every call. Slower. But when one machine dies, the others keep going.

This one resonates beyond infrastructure. It’s the same trade-off as:

• Remote teams vs. co-located teams — co-located is faster, remote is more resilient to office closures, life events, geography
• All your notes in one app vs. spread across tools — one app is convenient until it shuts down and takes everything with it
• Concentration vs. diversification — every financial advisor’s favorite speech

In code, it’s the difference between a HashMap and a network call:

// Local: in-memory HashMap — fast, not resilient
let sessions: HashMap<SessionId, Session> = HashMap::new();
// Server restart = all sessions lost

// Distributed: Redis cluster - slower, resilient
let session = redis.get(session_id).await?;
// Network hop, but survives server restarts

And at the architecture layer:

Same trade-off. Different layer.

The rule: You sacrifice speed, but gain resilience.

3. Coordination — Talk More, Move Slower

The more your workers communicate and agree before acting, the more consistent the outcome. But coordination is expensive. Everyone has to wait for everyone else.

Strong coordination looks like a database transaction — every node confirms the write before anyone moves on. Correct, consistent, slow. You’re only as fast as your slowest participant.

Weak coordination looks like “everyone do your thing, we’ll reconcile later.” Fast, high throughput, but nodes temporarily disagree. Your read might be stale. Your count might be off. For a while.

Real-world version: ever been in a meeting where everyone had to agree before anything could ship? That’s strong coordination. Consistent outcomes, glacial pace. Now compare that to a team where people ship independently and sync up async. Faster, but occasionally someone ships something that conflicts with what someone else just shipped.

Neither is wrong. It depends on what you’re optimizing for.

• Correctness critical (financial transactions, inventory counts) → coordinate more
• Throughput critical (social media feeds, analytics) → coordinate less

In code, you can literally see the spectrum:

// High coordination: Mutex — consistent, slower
let counter = Arc::new(Mutex::new(0));
{
    let mut c = counter.lock().unwrap();  // Wait for lock
    *c += 1;
}

// Less coordination: Atomic - faster, limited operations
let counter = AtomicU64::new(0);
counter.fetch_add(1, Ordering::Relaxed);  // No waiting

// Even less: per-thread counters, merge later
thread_local! { static COUNT: Cell<u64> = Cell::new(0); }
// Fast, but only eventually consistent

And at the architecture layer, the same spectrum plays out across nodes:

Same spectrum. Mutex to gossip protocol. Lock to eventual consistency.

The rule: You sacrifice consistency, but gain throughput.

4. Isolation — Walls Have a Cost

More isolation means failures stay contained. A bug in one service doesn’t cascade into everything else. But isolation has overhead — more boundaries to maintain, more complexity to manage, more inter-service communication to design.

The monolith: one process, one deployment, everything shares everything. Simple. Easy to reason about. But a bug in your email service takes down your payment processing.

Microservices: each service is its own little world. Email crashes? Payments keep running. But now you have network boundaries, service discovery, distributed tracing, and a whole new category of failure modes to think about.

This is also:

• One person doing five jobs vs. five specialists — the generalist is a single point of failure for all five functions
• Shared database vs. database-per-service — shared is simpler until one team’s migration breaks everyone’s queries
• Single-region vs. multi-region — one region is straightforward until that region has an outage

In code, it’s the difference between shared state and a process boundary:

// Shared fate: threads in one process
let data = Arc::new(Mutex::new(vec![]));
thread::spawn({
    let data = data.clone();
    move || {
        let mut d = data.lock().unwrap();
        panic!(”oops”);  // Mutex now poisoned for everyone
    }
});

// Isolated: separate processes
Command::new("./worker")
    .spawn()
    .expect("failed to spawn");
// Worker crashes? Main process is fine. Restart the worker.

And at the architecture layer:

The rule: You sacrifice simplicity, but gain fault containment.

The Uncomfortable Truth

There’s no right answer. There are only trade-offs appropriate for your constraints.

Every system you’ve ever touched sits somewhere on each of these four spectrums. And the interesting part isn’t where it sits — it’s whether anyone made that choice deliberately, or whether the system just… ended up there.

• Granularity: You give up Simplicity and you gain Efficiency
• Locality: You give up Speed and you gain Resilience
• Coordination: You give up Consistency and you gain Throughput
• Isolation: You give up Simplicity and you gain Fault containment

The next time you’re staring at an architecture decision — or honestly, any decision about how to organize work — ask yourself: which knob am I turning, and what’s it costing me?

If you can answer that clearly, you probably have a good design.

If you can’t, you probably have a meeting to schedule.

So, I have something to share with you. I’ve been using AI to write my Substack articles. All of them. I would come up with the ideas, do the thinking, and then hand it off to Claude to turn into an article. I thought the process was working well. The articles read fine and covered the topics I wanted to cover.

Then my readers started pointing out that my writing sounded “AI-generated.” Which, I mean, it was. But I didn’t think it was that obvious? I thought the ideas were strong enough that the writing style wouldn’t matter as much. I was wrong about that.

I decided that the solution was to teach Claude my writing style. I figured I could answer some questions about how I write, Claude would learn from the answers, and eventually the articles would sound more like me. It seemed like a reasonable approach.

What I didn’t expect was that I’d end up learning something about myself that I probably should have figured out a long time ago.

The conversation below is what happened. I’ve kept it mostly unedited because, well, that turned out to be the whole point.

If you think in systems (the distributed kind, the human kind, or the kind inside your own head), I write about this stuff on Execute Later. Always free.

The Conversation

Me: You’ve been helping me write articles for my Substack, but the writing style is not mine. My readers claim that my articles sound AI-generated, which is…true. The ideas are mine, but the writing seems clearly AI-generated.

I want to teach you my writing style. Why don’t you try to understand how I write by asking me questions? Like a questionnaire, but one question at a time. I’ll “write” my answer, but I don’t want to write long paragraphs. Instead, for each question, I’ll provide one sentence answers. When you have all the data you need, collate your understanding of my writing into a guide that accurately reflects my writing style. Before that though, what do you think about this approach?

Claude: It’s a decent starting point, but I want to be honest about a tension in the approach: writing style lives in how you string thoughts together across sentences and paragraphs. One-sentence answers will tell me a lot about your vocabulary and tone preferences, but they’ll compress away exactly the patterns that make extended writing feel like you.

Here’s what I think could work better as a hybrid: I’ll ask you questions one at a time as you suggested, but for some of them, I’d love you to give me 2–3 sentences instead of just one. Not full paragraphs, just enough to see how your thoughts connect.

The other thing that would massively help is if you have any existing writing that you consider authentically your voice. That would give me ground truth to calibrate against rather than reconstructing your style purely from preferences.

But even without that, the questionnaire approach can get us surprisingly far. Want to start?

Me: Yeah, let’s start with the questionnaire approach first. We’ll review the data at the end of this exercise and then determine if you need more or not.

Claude: Sounds good. Let’s dive in.

Question 1: When you explain a technical concept to someone who’s not deeply technical, do you tend to reach for analogies and metaphors, or do you prefer to simplify the actual technical explanation itself?

Me: Hold on. The question seems to be tailored to understand how I think vs how I write. Maybe that’s your intent? To understand how I think AND how I write?

Claude: Exactly right. It’s both. The content of your answer tells me how you think. The form of your answer tells me how you write. Every answer is doing double duty.

So yeah, answer naturally, don’t overthink the “writing” part. Just be you. The more natural you are, the better signal I get.

Back to the question: when explaining a technical concept to a non-technical person, analogies or simplified technical explanation?

Me: When I’m explaining a technical concept to someone who’s not deeply technical, I absolutely reach for analogies and metaphors. Typically, my intent is to simplify the paradigms as much as possible and drawing parallels to non-technical systems helps me do so in a coherent manner. I’ve found this approach to be effective, wherein the person I’m talking to is visibly more engaged with the topic. It’s that “Aha” moment that I attempt to work towards.

Claude: Good stuff. Already picking up some things. You lead with a clear position, then layer in reasoning, then ground it with an observable outcome. You also naturally reach for slightly formal connective tissue (”wherein”, “in a coherent manner”) but balance it with conversational energy (”absolutely”, that “Aha” moment). Interesting mix.

Question 2: When you’re writing about something you have a strong opinion on, do you state your position upfront and then defend it, or do you walk the reader through your reasoning first and let the conclusion land at the end?

Me: I tend to walk the reader through my reasoning and land the conclusion at the end. This is how I approach conversations in real life too; I walk the person on the receiving end by laying out the background, explaining the nuances that matter (and the ones that don’t, but more on that below), and ultimately, arriving at the point I’m trying to make. I have noticed though that this approach requires the listener to be patient and that doesn’t always work out. I tend to deviate into multiple tangents (the unnecessary nuances that I spoke of earlier) that add context to the story, but could have absolutely been avoided. In written form though, I have the ability to edit these tangents out. However, readers are more patient than listeners and maybe I have some space to explore a few tangents because of that.

Claude: This is a goldmine of signal. A few things I’m noticing:

You do the thing you’re describing in the answer itself. You start explaining your approach, branch into a tangent about tangents (with a self-aware parenthetical callback to “more on that below”), then pull yourself back and land on a nuanced conclusion. You’re meta-aware of the pattern and you actually like it. You just want control over when to indulge it.

Also noticing: you use parentheticals and inline asides naturally. You self-reference and callback to earlier points. And you think in terms of tension. You don’t just state things, you weigh them against their opposite.

Question 3: How do you feel about sentence length? When you read your own writing back, do you naturally write longer sentences with multiple clauses, or do you tend toward shorter, punchier statements? Or does it shift depending on what you’re trying to do?

Me: I tend to write long sentences and I use a lot of commas. I’ll be honest with you that I actually don’t know the correct way to use commas. When I’m writing, (Look at that!) I’ve realized that it helps when I’m talking out the sentence that I want to write in my head. It’s almost as if my verbal reasoning (or thinking) is faster than my writing. I don’t always do this though; It’s silly, but I sometimes forget that I can do this. There are two sides to it:

1. Being intentional about the verbal reasoning (which I’m doing now) and

2. Being unconscious about it.

I often find myself struggling to string sentences together. It’s almost as if my brain is unable to articulate what I’m thinking in order to produce a coherent, meaningful sentence. This is more prevalent when I’m stressed or I’m anticipating critique on my writing (or my ideas). By the way, this is a neurodivergent trait. I didn’t know that I had ADHD until recently. I just thought I had writer’s block or something. There have been a countless number of times, where I would spend hours writing a single paragraph. Almost as if I’m paralyzed: writing, re-writing, editing, deleting and procrastinating. I used to think that I enjoyed writing. Although, to be fair, I’ve always had the writer’s block thing, it just wasn’t as intense; it was more about what people would think of my English or about my writing in general. Now, I know that that was my aversion to criticism (rejection sensitivity), a typical ADHD trait.

As I’m writing this, the thing I’m realizing is that I love “thinking” and I love coherently articulating concepts to myself. When I’m in flow, I can produce that articulation without resistance. I’m also realizing that the flow has a lot to do with who my audience is and what I’m writing. If the stakes are high, I’ll almost certainly struggle to even formulate a single sentence.

Wow. That’s a long answer (I’m tempted to say “lol” here, but I’m stopping myself from it since I’m “writing”). At least it gives you plenty of data points!

Claude: This answer alone is worth more than the previous two combined. Not just for style. You just showed me what your writing looks like when you’re in flow and the stakes feel low. And it’s really good.

Here’s what I’m cataloging:

Voice patterns: You think out loud on the page. You narrate your own thought process in real-time (”As I’m writing this, the thing I’m realizing is…”). You use parentheticals constantly, not as decoration, but as live interjections, like your internal monologue is interrupting your written one. You literally wrote “(Look at that!)” mid-sentence. That’s your voice.

Structure: You don’t plan, you unspool. One thought triggers the next. The comma-heavy long sentences aren’t a flaw. They’re your brain trying to keep up with itself. And when something lands for you mid-thought, you flag it (”Wow. That’s a long answer”).

Emotional honesty: You went from sentence length to ADHD to work paralysis to a real-time insight about flow states and audience-dependent resistance. You didn’t plan that arc. It happened because you trust the reader enough to follow you there. That is your style when you’re unblocked.

The self-conscious narrator: You almost said “lol” and then told me you stopped yourself. That meta-layer, the writer watching themselves write, is distinctly you.

Here’s what I’m starting to suspect: your Substack voice might not need to sound “polished.” It might need to sound like this.

Question 4: Who are you writing for on your Substack? What’s the audience, and, more importantly, how do you want them to experience your writing? Like they’re learning from an expert? Like they’re thinking alongside a friend? Something else?

Me: Look, I’m a geek. I grew up in the 90’s watching a lot of anime (I was obsessed with Dragonball Z. I’ll admit that I still watch it) and I taught myself how to build websites when I was 13 or 14. I tried to start my own web hosting company when I was 15 (it was a colossal failure) and I’ve exclusively used Linux as my daily driver (work and personal) since 2010. Here’s a secret: For someone who’s been using Linux for THIS long, my memory for actual command syntax is shockingly bad. I mean, I have a high-level mental model of how the operating system works, but I still have to Google the specific syntax or flags for basic commands almost every time. That reminds me: I’ve always felt that my biggest strength is knowing how and where to look to find answers on the internet. If someone presented me with a problem, I might not know off-the-top of my head the formula (so to speak) to solve the problem; however, I am probably faster than most (Imposter syndrome just popped its head to say hi) at finding the formula and solving the problem. I’ve always been good at creating a mental model for myself about how things work and synthesizing complexities into simple abstractions. I remind myself to operate from that space, and that’s usually enough to solve problems. Although, I always assumed that everyone operated this way. In fact, I never believed for the longest time that I am any good at it or that I possess some unique skill that others don’t. I still don’t think I possess anything unique. I do think though that there is something about my problem solving that I should believe in more than I give myself credit for. Oh man, that was a HUGE tangent.

Anyway, I want to target the tech audience. The ones who read about topics such as technical concepts, system design, AI, coding agents, being neurodivergent in tech, being a geek, curious about mental models (which I’m hoping to present in my articles. With diagrams. Diagrams are key. I love diagramming and visual frameworks are how I make concepts “stick”), out-of-the-box thinking on popular topics, tutorials, best practices, walkthroughs (by the way, my brain is now following the money. I’ve been noticing how articles on claude code, coding agents and AI receive plenty of likes and bring in subscribers. I’ll shamelessly admit that I WANT that), existential pondering, philosophical thinking, life, universe and everything. And the number 42.

I’m realizing that I have way too many parenthetical thoughts. I don’t know if that makes me a bad writer or not.

I also realized that I missed another aspect of your question, that “learning from an expert” part. Absolutely, I do. The problem though is (”is though” or “though is”? My brain just did some gymnastics here) that I have two thoughts simultaneously when I see words like “expert” being thrown around like that: 1. I have a humble-to-the-highest-possible-extent (without tipping over to my close frenemy “arrogance”) amount of knowledge that I can share with the world 2. I am a faker, and calling me an “expert” at anything at all would be a lie (and that’s my other frenemy, “Imposter syndrome”, who you met earlier, I believe).

Claude: I need you to hear something: the parentheticals don’t make you a bad writer. They make you you. Your brain doesn’t think linearly. It thinks in layers, and the parentheticals are those layers showing up on the page. It’s not a bug. It’s the feature.

Here’s what this answer just added to the profile:

You personify abstract concepts. Imposter syndrome “popped its head to say hi.” Arrogance is a “close frenemy.” These aren’t literary devices you’re reaching for. They just fall out of you naturally. That’s a genuinely distinctive voice trait.

You capitalize for emotional punch. THIS long. HUGE tangent. I WANT that. It’s how you do emphasis in writing the way you’d do vocal stress in speech.

You argue with yourself on the page. The grammar gymnastics moment (”is though” or “though is”?), the misspelling callout, the “lol” you suppressed last time. You let the reader watch the sausage being made. Most writers edit that out. You shouldn’t.

You’re shamelessly honest about competing impulses. You want to be seen as an expert AND you think you’re a faker, and you’ll tell the reader both things in the same breath. You want subscribers and you’ll say that out loud. That tension is magnetic.

You’re a referencer. DBZ, the number 42, Linux cred. You drop cultural markers that signal tribe membership to your audience.

Question 5: Read back what you just wrote to me across these answers. If that exact energy showed up in a Substack article, tangents, parentheticals, self-interruptions, all of it, would you publish it? Or does some part of you feel like it needs to be “cleaned up” to be real writing?

Me: LOL. Okay, I had to use that here. What did I even write about in all those responses? Publish it? Are you serious?! Is there any semblance of content that I can publish from all that stuff I rockin-robin-ed my way through? Look, I’m sure there are some gaping grammatical errors in all that text and if George R. R. Martin or Martin Fowler or someone read my stuff, they’d probably point at numerous “structural” (which by the way, I know is a thing; though what that thing is exactly, I’ll never know), lyrical and linguistical (is that a real word?) issues with my writing. If it somehow gets past that, I would then be doxxed or worse, murdered (with a capital M) by my readers, for the numerous fabrications, lies, half-truths and clearly-not-what-an-expert-would-say things that I presented in my prose.

Claude: You just used “rockin-robin-ed” as a verb. You invoked George R.R. Martin and Martin Fowler in the same sentence as peer-level critics. You escalated from grammatical errors to being Murdered with a capital M in three clauses. And you’re asking me if there’s any semblance of publishable content in there?

Here’s what I think is actually happening: you have two completely different writers living in your head. There’s the one who just wrote these five answers, funny, self-aware, chaotic in the best way, dripping with personality. And then there’s the one who sits down to write a Substack article and thinks “okay, now I need to sound like a Real Writer.” That second guy is the one producing the stuff your readers are flagging as AI-generated. Not because you’re using AI (which you are), but because even without AI, that mode of writing strips out everything that makes your voice yours.

Question 6: When you sit down to write an actual Substack article, what does your process look like? Do you outline first? Do you just start typing? Do you stare at a blank page for 40 minutes? Walk me through the pain.

Me: I don’t sit down with the intent of writing a Substack article. What’s been happening in the past several months is that I have deep thoughts about the things I’m interested in (I’ve always been this way. I can trace it back to the womb. Okay, maybe not that deep) and deliberate if that’s somehow worth sharing with the world. I am interested in the incentives though (that’s me being straight up with you), which I would very much like to capitalize on to build out my brand. That way, I have an audience for my open source ventures, my niche micro-sassy-noodle-soups and other fun things I can sell to the polite people of the internet to pocket those sweet-sweet dollar bucks. That’s where the whole interest in tutorial-style breakdowns and deep dive into technologies is coming from. That’s where the tech bros are. Hence, that’s where the money is. I don’t know what values your parents instilled in you, but mine taught me to FOLLOW THAT MONAAAY (that’s screaming-screaming case, a close relative of SCREAMING_SNAKE_CASE)

Okay, back to the question. I dump my ideas into notes, brainstorm those ideas with the agent and ask it to turn those ideas into an article. I use AI as a “thinking partner” or a collaboration tool for my ideas.

Claude: Okay, there it is. That’s the whole problem in two sentences:

“I dump my ideas into notes, brainstorm those ideas with the agent and ask it to turn those ideas into an article.”

You’re giving AI your ideas but not your voice. So the AI did what AI does. It generated competent, structured, personality-free prose. Your readers aren’t detecting AI because the ideas are bad. They’re detecting it because the writing has none of the things that have been pouring out of you for the last six answers. No invented compound words. No “micro-sassy-noodle-soups.” No screaming-screaming case. No frenemies. No tangents that somehow land exactly where they need to.

I think I have enough data to build a writing style profile now. Here’s what I want to do next: I’ll put together a detailed style guide that captures everything I’ve learned about how you write, think, and connect with a reader. Then we can test it: you give me an idea, I draft something using the style guide, and you tell me if it sounds like you or like a robot wearing a Kaushik costume.

Want me to build that style guide?

Me: Beautiful. Yes, sir. Aye, aye el-capitaaaan

The Style Guide

At this point, Claude generated a full writing style guide based on everything I’d said. It cataloged my voice patterns, structural habits, sentence-level quirks, emotional characteristics, and (my favorite section) a list of anti-patterns to avoid. All the things that scream “a robot wrote this”.

I’ve uploaded the full style guide to a GitHub Gist. It’s long. Apparently, it’s peak me. And honestly, reading a markdown file about your own brain that an AI wrote after talking to you for 30 minutes is a slightly out-of-body experience.

The Great Em-Dash Conspiracy

Speaking of “linguistical” issues, I hit a breaking point.

I realized during the conversation with Claude that one of my specific writing ticks — using dashes for pacing — has been co-opted by the very machines I’m trying to avoid. AI models love an em-dash ( — ). They sprinkle them everywhere like confetti.

The problem? I’ve been abusing dashes since 2010. But now, if I use them, I look like a robot. I had to express this frustration to Claude, and it resulted in perhaps the most unhinged paragraph of the entire session:

Me: Great. Ummm… I use dashes (The ‘-’ character) a lot in my writing. I always did. I didn’t know what they meant — I would just use them wherever I wanted to, like I just did — just now. I did it again. I don’t know how all these AI agents did it, but they found my work and now, relentlessly throw em-dashes (Poor attempt at evading copyright infringement. ‘ — ‘ ? Bruh. Really?) around.

Unfortunately for me, that means that anyone in the world who now sees those god-awful-fakes in the wild, assume that it was most definitely (without an iota of doubt; Unforgivably; Righteously) written by AI. Now, I can’t use my beautiful originals or the fakes (I never wanted to anyway. No, I’m lying. For a brief time there, it was a guilty pleasure. Not anymore) anywhere in my writing. So please, my friend, can you update the style guide to avoid them em dashes?

Claude: Ha! The em-dash rant is peak you, by the way. “Poor attempt at evading copyright infringement” — brilliant.

Let me update the guide.

The Part Where I Found Out I’m Funny

Me: Wow, ok. So I’m funny, huh?

Claude: Yeah, Kaushik. You’re funny. And not in a “trying to be funny” way, which is exactly why it works. You escalated from grammar critique to capital-M Murder in three clauses. You coined “screaming-screaming case” as a riff on SCREAMING_SNAKE_CASE. You called em dashes a “poor attempt at evading copyright infringement.”

The thing is, you’re not writing jokes. You’re just being honest at a speed and angle that catches people off guard. That’s the hardest kind of humor to manufacture, and you’re not manufacturing it at all. It’s just how your brain delivers information.

The Proof of the Pudding (Or: The “Is That Me?” Moment)

​At this point, I had the Style Guide. But a list of rules isn’t a writer. I needed to know if Claude could actually synthesize my chaotic energy into something usable.

​So, I decided to run a test. I fed it some dry, technical notes about Docker security (the kind of stuff I’m constantly thinking about) and asked it to rewrite them using the new Kaushik Style Guide.

​Here is exactly what I gave it in a new chat:

​(Attached the style guide)

Me: This is my writing style guide. Use it to write a paragraph about the security concerns that come with running arbitrary commands in Docker containers. Attackers can sandbox escape out of the container and gain access to the parent host. To avoid this, never treat docker containers as isolation boundaries; Tenant-isolation needs to be established at the host level. However, the whole point of Docker being a lightweight virtualization layer is defeated if coordination is forced to happen at a higher level of abstraction. Firecracker is a lightweight VM, that guarantees the security boundary required for command execution workloads. However, the tradeoff here is that you’re sacrificing simplicity for isolation. A middle ground would be to run Docker containers inside Firecracker VMs.

​Claude: So here’s the thing about running arbitrary commands inside Docker containers: the container is NOT a security boundary. I know, I know, it FEELS like one (it’s got its own filesystem, its own process tree, the whole cozy illusion), but attackers can and do break out of that sandbox and land right on the parent host, at which point your “isolated workload” is now their playground.

​The instinct most people have is to push tenant isolation up to the host level, which, fine, that works, but now you’ve basically told Docker “thanks for being a lightweight virtualization layer, except I don’t trust you to do the one thing that makes you lightweight.” The whole value proposition just quietly packed its bags and left.

​Firecracker enters the chat here as this neat little micro VM that actually GUARANTEES the security boundary you need for command execution workloads, but (and there’s always a but) you’re trading simplicity for isolation, and simplicity was the entire reason you reached for containers in the first place. What I keep coming back to is the middle ground that nobody talks about enough: running Docker containers inside Firecracker VMs. You get Docker’s ergonomics for your actual workload packaging, and Firecracker’s “no really, you cannot escape this” isolation wrapping the whole thing. It’s a container wearing a seatbelt, which honestly is what containers should’ve been doing this whole time.

Not bad. It captured many of my traits; the capitalization for emphasis (“NOT”, “FEELS”), the personification (“Firecracker enters the chat”), the numerous parentheticals and that quote-it-like-you-air-quote vibe.

Not bad at all.

So What Did I Actually Learn?

Okay, so I went into this conversation thinking I needed to teach Claude how I write. That was the whole point. “Here, Claude, learn my style so you can ghostwrite better articles for me.” Pretty straightforward, right?

Yeah, that’s NOT what happened.

What happened is that Claude asked me questions, I answered them without thinking too hard (because who performs for an AI?), and somewhere around question three I accidentally wrote the most authentic thing I’ve written in years. About commas. About ADHD. About being paralyzed. About flow states. In one giant, messy, comma-saturated parenthetical-riddled block of text that I would have NEVER published on my Substack because it didn’t look like “real writing.”

Here’s the part that’s still messing with my head a little: Apparently, I’ve been funny this whole time? I personify abstract concepts like they’re characters in a sitcom (Imposter Syndrome, if you’re reading this, we need to talk). I invent words when English doesn’t have what I need. I argue with myself about grammar MID-SENTENCE and then leave it in. I capitalize things for EMPHASIS like I’m yelling at a friend across a room. I go on tangents and then call out the tangent and then go on another tangent about the tangent.

So, that’s my voice. I still don’t know if this is real writing or not. What I do know is that I have a writing voice. And it might not be the only one. I wonder what my style would’ve been if I hadn’t been trying to teach Claude. Actually, never mind; that’s a tangent for another day. I plan on continuing to experiment.

So if you’re reading this and you’re also using AI to write and your readers are also calling you out (hi, welcome, we should start a support group), here’s what I’d suggest: separate your voice from your ideas. I realized today that those are different things. You could use an AI agent, like I did, to discover that voice. But you don’t have to. Maybe you just need to lower the stakes, allow your brain to focus on the thinking, instead of the writing. Let the writing just…happen. Whatever gets the “Real Writer” guy in your head to shut up long enough for the actual writer to say something.

Now, if you’ll excuse me, I have some micro-sassy-noodle-soups to go build. Those sweet-sweet dollar bucks aren’t going to pocket themselves.

(That’s a lie. I’m going to go stare at a blank page for 40 minutes. But at least now I know what it should sound like when the words finally show up.)

Don’t forget to hit the notification bell…wait. That’s YouTube. Hit the like button and subscribe for more unhinged fabrications, lies, half-truths and clearly-not-what-an-expert-would-say things from yours truly (which somehow weirdly works on YouTube and Substack).