I type one sentence into Claude Code and five files load before the model writes a word. Anthropic did not ship that behavior. My agent harness does, and the wiring behind it is four files and a hook.

A harness is everything around the model. The model is rented, and mine is identical to yours. The harness is the part you own. It holds the instructions that load, the order they load in, the skills the agent can reach, the hooks that refuse bad output, and the memory that outlives the session.

Most people stop at one file. They write a CLAUDE.md, list ten preferences in it, then retype eight of those preferences by hand for the next six months. That is rented work with an extra step. The instruction exists, nothing enforces it, and the agent follows it when the context window feels generous.

Four layers, each with one job

Global. ~/.claude/CLAUDE.md loads in every repo on this machine. It carries my writing rules, a project registry that turns the words "my notes" into D:\Atharva\NOTES, the API key rotation order, and the two CLI tools I reach for every week. Nothing repo-specific lives here.

Project. D:\Atharva\NOTES\CLAUDE.md carries what only this vault knows. The folder contract, the publishing pipeline, the review desk, the six agents. Three other repos on this machine run their own copy of the same pattern with different content.

Skills. 60 skills in the vault, 94 more machine wide. A skill is a folder the agent opens only when the job matches it. A LinkedIn post loads one skill, a Substack article another. The agent never reads 154 skills at once, so the cost of adding the 155th is zero.

Hooks. Six Python files. This layer changed my output the most, because a hook runs code instead of asking politely.

I measured what those four layers cost. Nine files I wrote reach the model before my first word, and they add up to about 40,300 tokens. Around 28,000 of those arrive on every session, whatever I ask for. The other 12,200 load only because a hook read a writing word in my prompt.

Ask that same session about a Python bug and the bottom block never loads.

The load order is the part everyone skips

On paper my rules agree with each other. They collide at 11pm inside one paragraph, when the voice file wants a long conditional sentence and the scorer caps me at twenty words.

One file answers that. DIGITAL TWIN/core/runtime-contract.md names which files load, in what sequence, and which one wins a disagreement.

Five files always load, in this order. The contract opens the chain. The pattern rules follow, and they hold the AI tells a regex cannot catch. The plain-style file lands third. World.md arrives fourth and names the villain and the one reader. Voice.md closes the always-loaded set.

After those five, the job picks one more file on demand, and the channel skill loads last. The checks then run in a fixed order, and each one carries a stated bar.

Precedence resolves upward. A sample I paste into the session beats the voice profile. The voice profile beats the skill. A hard ban beats everything.

The agent prints that chain above every draft. I never open a file to learn which rules ran.

A hook is a rule that can fail

Three of my six hooks do work I used to do by hand.

writing-load-order.py fires on the prompt. It reads the channel out of my request and prints the chain into context before I finish typing. I stopped reminding the agent which files to read.

writing-gate.py fires after every write. It runs the scorer on the file the agent just saved. On a critical finding it returns a block with the exact offending lines. The same hook fires when the session tries to end, and it refuses to close while a draft it touched still fails.

pillar-guard.py classifies the topic against my three content pillars before a word gets drafted. An off-topic post gets a warning banner and needs my explicit yes.

A reminder lets a bad draft through. A gate returns an error and the write does not land.

What four layers actually bought me

1. Consistency stopped being my job. The scorer is deterministic, so a draft gets the same verdict at 9am and at midnight.

2. My judgment survives the session. Every call I make once goes into a file, and the next session opens with it already loaded.

3. Ten routines run without me. Daily comments, lead DMs, a weekly digest and a monthly graph refresh all run on a schedule I do not attend.

4. A new model costs nothing to onboard. Opus 5 arrived and read the same four files.

One result surprised me. Writing the rules down changed what I believe about writing. I could not state my rule about rhythm until I tried to write it, failed twice, and found the idea underneath it was wrong.

Build one this week

You already have opinions. They live in the corrections you type every day, and every correction you repeat twice is a file you have not written yet.

Start smaller than you think.

1. Open ~/.claude/CLAUDE.md and write down the five corrections you gave an agent this week.

2. Split that file. Machine-wide facts stay global, and repo facts move into that repo.

3. Once you hold more than three rule files, write the load order down as its own file.

4. Take your loudest rule and turn it into a hook, so it blocks instead of reminding.

The test is whether a stranger opens your repo, reads no chat history, asks you no questions, and keeps your operation running for two weeks. My harness is the part that passes that test. The model is the part I rent.

Leave a comment

Most AI models write for a living. The Jev AI model, from a company called TypeSafe, refuses to write at all.

Ask ChatGPT a question and it answers in a paragraph. Ask Jev the same question and it answers with a typed decision: a choice, a score, or a probability.

That trade sounds small. It changes what you can afford to automate. Jev skips the writing step, so it answers in about a tenth of a second. A normal AI model takes several seconds for the same call, and costs far more per answer.

Jev launched into early access on 15 September 2026. Within a week, people had shipped routers, linters, lead scorers, spreadsheets and photo pipelines on it. This guide covers what Jev is, how it works, and eighteen jobs people already gave it.

One Restriction Makes Jev Fast

Every normal AI model works the same way. It reads your prompt, then writes an answer one word at a time. Each new word depends on the words before it. That loop is slow, and that's where most of the cost comes from.

Jev skips that step. You give it two things: a state, and a set of questions. The state is the information, a message, a document, a paragraph, anything in text. The questions are what you want to know about it.

It reads the state once, then answers every question in parallel, in a single pass. It never writes a sentence, so there's no word-by-word loop to wait for.

TypeSafe calls this a System One model, after the psychologist Daniel Kahneman. In his framework, System One is your fast, gut reaction. System Two is slow, careful reasoning. A normal AI model tries to do System Two thinking in full sentences. Jev only makes System One judgment calls, and it makes them fast.

Pydantic, the Python validation library, described a call in one sentence when it added Jev support. The type you already wrote is the question, and the answer comes back as that type with one confidence per field.

You Can Ask Jev Three Kinds of Questions

You can mix all three types in one call, and every question runs against the same state at the same time.

A support message can get a Choice question asking which team should handle it, a Score question asking how upset the customer sounds, and a true-or-false question asking whether they want a refund. All three answers come back together.

Shann Holmberg wrote the shortest description of the loop I have read. You supply the information, your questions, and the allowed answers. Your own code decides what happens next.

Every Answer Comes With a Confidence Number

Every Choice and Score answer includes a confidence number, from 0 to 1. A high number means Jev found one clear answer. A low number means the options were close, or the text didn't give it enough to go on.

That number lets your software decide what happens next. A high-confidence answer can be acted on right away. A medium one can be flagged for a person to glance at. A low one can skip automation entirely and go straight to a human.

That distinction makes Jev usable for real decisions rather than demos. A system that can say "I am not sure" gives your code a rule to build around, instead of a guess to trust.

OrcDev put the same idea in terms of where Jev sits. Big models think slowly. The small decisions between their calls never needed to be slow.

Jev Can Cost 400 Times Less Than a Normal AI Call

A Jev call costs $0.042 for every million tokens of text you send in. A token is a small chunk of text, close to three quarters of a word. Jev's output costs nothing, because it never writes anything out.

A normal AI model charges for input and for output, and output is usually the bigger cost. The input text alone can run $0.20 to $10 per million tokens.

TypeSafe tested Jev against several AI models on four real workflows. Jev came out up to 444 times cheaper and 193 times faster on those tests. TypeSafe ran that test itself, so read it as their claim, not an independent check. Their launch post plots accuracy against cost, and Jev holds the cheap end of that line without losing much accuracy.

The rest of this guide uses other people's numbers instead.

Eighteen Jobs People Gave Jev in Its First Week

Every job below is a real build, posted publicly between 15 and 20 September 2026. I kept each person's own figures and named who ran the test, because almost nobody has checked these independently yet.

Sorting a Pile That Nobody Wants to Read

1. Classify 1,018 AI research papers for eight cents. Hassan summarized every paper with DeepSeek V4 Flash, which cost $3.99 on Together. He then sent each title, each summary and 24 candidate topics to Jev. The 1,018 classifications cost $0.08 in total, at 256 milliseconds median per paper, end to end. He is still running evals before he replaces his current labels, so treat the accuracy as unproven.

2. Triage security alerts in a production pipeline. Greg Pstrucha works on AI at Sentry. He posted a table of seven models running one of Sentry's security pipelines. Jev scored 99.3% accuracy in 0.259 seconds. GPT-OSS 120B scored 96.4% in 1.821 seconds and cost three times more. Gemini 3.1 Flash-Lite matched Jev's accuracy, took 1.338 seconds, and cost fourteen times more.

3. Sort an inbox, then sort the seven queues behind it. Greg Isenberg described the job in one line. Jev reads each item and says "this is junk, I'm 94% sure". He priced 1,700 emails at 18 cents. He then listed the queues that are the same job wearing different clothes: quote forms, inbound leads, support tickets, transcript clipping, grant and permit piles, marketplace matching, and bulk browser work.

4. Catch phishing with five small questions instead of one big one. Somebody ran 2,000 phishing emails through Jev. One big question scored 89.4%, which lost to a two-line text rule at 91.8% and to Claude Haiku 4.5 at 94.2%. The same person then asked five small questions and added the answers up in his own code. That scored 95.0%, the best result in the test. Same model, same emails, different question shape.

Choosing the Model Before the Model Runs

5. Route a chat to the right model on its first message. Ashley Hindle runs Fuel, which reads the opening message of a chat and decides how much intelligence that chat needs. His benchmark has 75 test cases. Against GPT-OSS-120B he measured Jev at 3 times faster, 65% cheaper and safer. A wrong route costs him twice, because a weak model on a hard problem annoys the user and raises their bill.

6. Route models inside Claude Code with one install command. Daniel San shipped the same idea as an installable mod. For every request, Jev picks the subagent model and the effort level. It picks the main model only at session start, because changing it mid-session breaks the prompt cache.

7. Pick the right skill out of a catalog of 182. TypeSafe's docs describe a test against the Hermes skill catalog from Nous Research. One Jev request ranks all 182 skills and asks whether the turn needs a skill at all. A second request reads the top three closely and can reject all of them. On Haiku 4.5, wrong skill loads fell from 17% to 7.3%. Both figures come from TypeSafe's own test.

Screenshot from Ray Amjad's Jev video, showing TypeSafe's documentation.

8. Put Jev in front of a model you already pay for. Ronin describes one email tool that swapped two AI calls per email for a single Jev call, and kept every safety check it already had. On a 120-ticket test, the version with Jev in front finished in 42 seconds for $0.0003. The version without it took 22 minutes and cost $0.059. He is clear that retry errors inflated the slow number, so the real gap is smaller.

9. Compact an agent's context tonight. The same thread names the cheapest win available. Score every tool call in the history, drop the dead ones, and keep the survivors word for word instead of writing a lossy summary. Ronin also points at the honest limit. Somebody ran 18,514 emails through Jev with no examples and got 98.33%. A TF-IDF classifier trained on 14,800 labelled examples got 98.39%, so labelled data still wins when you have it.

Deciding Inside the Interface, While Somebody Types

10. Rank a launcher's results on every keystroke. Nader Dabit built what he calls a keystroke oracle. A normal launcher ranks by alias, fuzzy match and habit. Type "the pdf I just downloaded" into his version and the newest PDF is already the top hit, with a confidence on every keystroke, in about 100 milliseconds.

11. Turn a spreadsheet column header into a judgment. Spreadsheets recalculate numbers, never meaning. Dabit typed "Urgency" at the top of a column and the sheet rated every row from "no follow-up needed" to "urgent" as he typed, in about 100 milliseconds a row.

12. Drive a browser by voice, remember what an agent learned, predict a video's numbers. Mario Nawfal published a full build tutorial with three demos. The voice-controlled browser needs a decision per utterance, the memory layer needs one per stored fact, and the YouTube predictor scores a title before you publish it. All three break down into typed questions.

Deciding Where the Money Goes

13. Score 700 leads and their outreach messages in 40 seconds. Romàn fed Jev 700 high-intent leads together with the personalized message written for each one. It predicted how each message would perform, attached a confidence score, and flagged the leads whose message did not match them. The whole run cost $0.09.

14. Lint every comment in a repository for one cent. Ray Amjad asked Claude Code to find useless comments in his own codebase. Claude Code sent 150 comments to Jev in one run. It took 9.3 seconds, used 233,802 input tokens, had zero failures, and cost $0.00982.

Screenshot from Ray Amjad's video.

15. Price a code smell scan across 8,270 functions. In the same session, Claude Code costed two versions of a full-repo scan. A gated pass sends about 7.5 million input tokens for $0.32 in roughly four minutes. An exhaustive pass sends 28 million for $1.19 in roughly eleven minutes.

Screenshot from Ray Amjad's video.

Money stopped being the constraint at that price. Claude Code's own note under the table names the constraint that replaced it. A 10% false-positive rate across 8,270 functions hands you 827 bad findings, and you stop reading the report. Check that number before you trust any scan this cheap.

Wiring Jev Into Something You Already Run

16. Give a Python agent framework its answer type back. Pydantic AI agents now run on Jev. The output type an agent already declares becomes the question, and the answer arrives as that model with one confidence per field. Nothing in the agent's code has to change shape.

17. Check an agent's work before a person ever sees it. Because Jev writes no prose, it invents no facts inside an explanation. That makes it a reasonable verifier for another model's output. Ask whether the answer used the source, whether the tool call matches the request, and whether a human should look. Three typed questions, one call, one price.

18. Sort four years of photos into 39 days of posts. That one is mine, and the next section is the whole build.

Flavio Copes wrote the deepest independent walkthrough I found during launch week, and it is the one I would read next.

Jev Sorted 469 of My Photos Into 78 Carousels for 29 Cents

I ran my first real build on my own camera roll. Four years of photos sat in 54 folders grouped by feel rather than by post. One pipeline regraded, recropped, regrouped, captioned and scheduled the whole set onto Instagram, two posts a day for the next 39 days.

Four tools each did one job. Claude Sonnet described every frame in words. Jev read those words and made every judgment. Python held the policy and ran the edits. The Zernio API published the queue.

The judgment layer cost $0.29. It made 5,961 typed judgments across 132 model calls, and I sorted zero photos by hand.

One judgment pass with Claude alone costs $17.40 and takes 36 minutes. The same pass with Jev underneath costs $0.14 and takes 5 minutes.

Projected to a 1,000-image run, the first pass drops from 90 minutes to 58. Every re-run after it drops from 36 minutes to 5. Re-running is where the work actually sits, because a grouping rule is never right on the first try.

Jev Is Not Built for Every Job

Jev can't write open-ended text. It won't draft an essay, an email, or a chatbot reply. If you need a model to produce free-form writing, you still need a normal AI model.

It can also be confidently wrong. TypeSafe says Jev can't output an invalid answer, only a valid one, because the shape of the answer is fixed in advance. A normal AI model can invent a fact that never existed. Jev can only pick from the options you gave it. But a valid answer can still be the wrong answer, with a high confidence number attached to it. When developers debated this on Hacker News after launch, that distinction was the most argued point in the thread.

Ronin's testing found three failure shapes worth copying into your own notes. Jev does not know what it does not know, so a question like "do you have enough information" answered yes on 85% of 120 test tickets. Option order changes answers, and reordering four options moved 7 answers out of 120. And the final verdict belongs in your code rather than in one big question, because the model is better at noticing things than at ruling on them.

There are plain practical limits too. Jev reads text only, no images or audio yet. It holds about 64,000 tokens of information in one call, smaller than several other AI models. The company is new, so its pricing and rate limits could still change as more people sign up.

Trying Jev Takes About Five Minutes

Getting access takes one of two paths.

The direct path is TypeSafe's own waitlist, at typesafe.ai. Sign up, and TypeSafe sends an API key once a spot opens. Early testers have reported getting in within a few hours.

The second path skips the waitlist. Vercel added Jev to its AI Gateway in September 2026. Anyone already building with Vercel's AI tools can call Jev through that account, with no separate signup.

Cloudflare followed on 17 September and put Jev on its own AI Gateway.

Once you have access, TypeSafe gives you a web playground. You paste in a piece of text and type a plain-language question. Then you pick a choice, a score, or a true-or-false answer. Press run, and the answer comes back in well under a second, confidence score included.

There is also a developer toolkit that plugs Jev straight into an app. Once wired in, the app can ask the question on its own, with no one typing into the playground.

Why This Price Is Low Enough to Start New Companies

A ten-times price drop changes who wins. A four-hundred-times drop changes what gets built at all. Four examples show what that buys.

1. A game bot that runs all day. TypeSafe's own demo has Jev making roughly ten decisions a second to play Doom in real time. Running that continuously costs about $7 an hour. A normal AI model, answering in full sentences at that speed, would cost far more and likely couldn't keep up with the game clock at all.

2. A chess engine priced under a thousandth of a cent. One developer wired Jev into a chess app through Vercel's AI toolkit. Jev picks a move from every legal option in about 300 milliseconds, for roughly $0.00004 a move. A full forty-move game costs less than two thousandths of a dollar.

3. Scanning everything instead of a sample. At $0.042 per million input tokens, checking a million tokens of text costs about four cents. Most systems settle for spot-checking a sample, because scanning everything used to be too expensive. That excuse is gone.

4. A guardrail in front of every action, not just the risky ones. Most AI systems today reserve a safety check for the actions that look dangerous, because running a full model on every single step costs too much. At Jev's price, the check can run in front of all of them.

None of these four needed a new company two years ago. Each needed a decision too slow or too expensive to make in real time, and TypeSafe is betting that gap just closed.

Where Jev Fits Into How I Publish

Every piece I publish goes through the same four steps. I write it, I check it against a set of rules for what good writing looks like, I fix whatever gets flagged, and only then does it go out.

Some of those checks used to be too slow to run on everything, so I read for them by hand instead. Jev is cheap enough to run every one of them, on every piece, every time. That's the first place I'm putting it, and I expect to find more as I keep building.

Leave a comment

DevRel Uni is a six-week cohort for developer relations practitioners. You do not watch it and forget it. It runs live sessions with practitioners who do the job now. A project runs beside those sessions, and you ship it publicly at the end. Cohort 7 had five speakers across six weeks: Bianca Buzea, Nader Dabit, Patrick Skinner, Hassan El Mghari, and Francesco Andreoli.

I enrolled because I wanted a forcing function. I already did DevRel at AccuKnox, and I already thought about how AI reshaped the job. I already built tools to cut the manual part of my workflow. Background thought during other work is a weak version of the real thing. Direct focus, and a real build from it, is the strong version. The cohort gave me a reason to do the second thing.

The format is simple. Each week has one session. One project runs beside the sessions, and one public deliverable lands at the end. This is that deliverable.

Below is a recap of my notes and takeaways from each session. DevRel Uni Cohort 7 ran for 6 weeks.

Session 1. The Scope of the Job Changed

Bianca Buzea opened the cohort with a simple framing. Four things define DevRel in any era. Those four are sense-making (what matters), storytelling (why it matters), distribution (who hears it), and feedback loops (what works). Those four stay. Everything around them moves.

The part that landed hardest for me was the audience expansion. DevRel always served developers. Now it must serve developers and AI agents at the same time. Those aren't the same job.

When a developer reads your docs, they read for intent. When a large language model (LLM) reads your docs, it reads for pattern. A page can explain a concept well for a human and still fail a coding agent. That happens when the API examples are ambiguous or the parameter descriptions are vague. It also happens when the page is prose-heavy with no machine-readable anchors.

An agent in a coding environment does not infer gaps. It has the information, or it hallucinates a plausible answer.

LLM-friendly documentation is a technical spec, not a style choice. That spec wants OpenAPI accuracy and deterministic code examples with exact commands, with explicit input and output schemas and no ambiguous pronouns anywhere. The docs answer the question before anyone asks it, in a form a retrieval system lifts whole.

Bianca made one quiet point that I keep returning to. "More people can build now, which means more people need guidance." The barrier to entry dropped. The demand for DevRel didn't shrink. It widened.

Session 2. Career Architecture, Not Career Path

Nader Dabit tracks GitHub Trending and Hacker News every day, and runs his own AI agents against the topics he follows. That habit alone told me his advice on career timing came from data, not from instinct.

Don't optimize for a title. Become a technologist.

Lock yourself into a job title and you've already lost, Nader said. Think like a technologist rather than a role, because the people who last are the ones who read the shifts and move with them. Career paths rarely run in a straight line, and a fast pivot beats a slow, careful plan now that speed matters more than it used to.

Nader's own edge is infrastructure, not luck. The daily GitHub Trending and Hacker News habit feeds his agents, and the agents route everything into custom feeds that keep working whether he checks the news that day or not. None of that compounds by itself. His loop is learn, build, share, get feedback, improve, and the "share" step is the one most people skip. Treat social media as a job board you get ahead of rather than one you react to. Show what you know in public, help people for free, and you land on a company's radar before the role ever gets posted.

"Every day is an opportunity to reinvent yourself. Small daily changes compound into a different person over time."

In practice you build three layers, and they compound at different rates. Tools change every few months. Fundamentals, systems thinking, communication, product sense, compound over years. Judgment is the layer AI can't replace, and it covers what to ignore, when to move, and what matters right now. The sequence matters: tools are tactics, fundamentals are strategy, and judgment tells you which strategy applies now.

Output makes learning stick. A GitHub repo, a video, a post, or a talk all count as output. Proof of work is the new resume, and proof of work is specific where a resume is generic.

I applied one thing directly from this session. I treat every project as a forcing function for public output. The DevRel Workbench is the primary example. Every week, something shipped and something got posted. The posting wasn't just distribution.

It tested whether I could explain the build clearly. The reader had not looked at the code all week. A LinkedIn post that I could not write clearly meant I did not understand my own build.

Nader said one more thing that I flagged immediately. Readiness usually comes after movement rather than before it. You don't need all the answers before the next step. You need enough signal. The window opens whether you're ready or not.

Session 3. Speed Without System Is Just Queue

Patrick Skinner opened with a question nobody in the room answered right away: how many eyes does a sniper keep open when aiming?

"Speed without system doesn't create progress. It creates queues."

Snipers shoot with both eyes open. The dominant eye locks onto the target, and the other eye keeps watch on everything around it. Close that second eye and you gain precision but lose peripheral vision, and in a fast-moving AI ecosystem, that lost awareness gets expensive. The thing that changes everything for you often sits outside the window you're currently staring through.

Patrick's example was Framework, a project that teaches kids engineering by having them build real things. The team executed cleanly and still ran into a dominant-eye problem. They fixed their gaze on the product roadmap and missed an ecosystem shift moving around them. They built something real while the ground under it moved.

The rest of the session was about research discipline. Start from data, not from a hypothesis, because feeding a bias into an AI system just gets the bias confirmed back to you. The prompt is upstream of everything that follows it. Carving out time to learn every day feels impossible right up until you calculate the cost of skipping it, and the compounding runs in both directions.

Passion is a distribution strategy in its own right. Patrick posted an article about EdTech, a subject he genuinely cares about, and it brought him investors, collaborators, and hires, because readers could tell the interest was real.

The Orbit model, Gravity, Love, Reach, has a layer most people skip in the AI context. Gravity brings developers into your ecosystem. Love keeps them loyal. Reach grows the community outward.

Coding agents now operate inside that ecosystem too. They pull from your docs, your SDK, your changelogs. Pull them in with the same structural clarity you use for a careful developer, one who reads closely and expects exactness.

Session 4. Your Docs Are a Product Decision

Hassan El Mghari from Together AI turned a half-conscious habit of mine into an explicit principle.

Developer experience is the floor. Agent experience is the problem already sitting above it.

1. When a new model drops, find what it's uniquely good at and build around that capability fast. Hassan did this with RoomGPT (room interior redesigns) and BlinkShot (real-time image generation). Timing and simplicity beat complexity.

2. Develop taste, because AI speeds up execution but supplies no judgment of its own. People can tell the difference between careful work and generated work, in the writing and in the demo.

3. Consistency is the advantage almost nobody uses. One article a week for six months adds up to 24 articles, and few people actually hold that pace. The same math applies to demos and to open-source contributions.

4. Hassan's specific read: build MCP servers and agent-friendly docs for coding agents, since a growing share of your readers are no longer human.

5. Hassan keeps a running idea journal with hundreds of prioritized app ideas. When he's ready to build, he never starts from zero. The setup cost is low, and the payoff is that he can move the moment he has capacity.

A developer asks ChatGPT how to use your API, and one of two things happens: the model answers correctly from training data or retrieval, or it hallucinates a plausible but wrong answer. Your technical content decides which. Clear, well-structured content is what gets pulled into the response accurately.

Being in the answer someone reads without ever clicking through to your site now matters more than a spot in Google's ranking. Your changelog entries and getting-started guides already answer questions in conversations you never join.

The implications are specific. Changelogs need semantic structure instead of narrative bullet points. SDK method signatures need inline examples with typed inputs and explicit outputs. Write getting-started guides for a system that executes each step literally. That system does not read for general intent.

A human reads "run the install command" and infers the context. An agent in a coding environment needs the exact command, the exact flag, and the exact expected output.

Hassan's own workflow was worth noting. He uses coding agents to build demo apps, generate documentation stubs, and scaffold internal tools. He was direct that pace still matters. Good ideas and strong UX are still human decisions. The agent speeds up execution of a direction you already chose. It doesn't choose the direction.

Session 5. The Operations Grid I Didn't Know I Needed

Francesco Andreoli, from Consensys, closed the cohort by borrowing a framework from psychology: a Pyramid of Builder Needs, adapted from Maslow's hierarchy.

The bottom layer of that pyramid is docs. If that layer breaks, nothing above it (grants, events, hackathons) lands. You can't skip a level in a hierarchy. His developer funnel separates value-driven onboarding from product conversion, and his Builder Nights series proved the split works. That series covered the whole ecosystem, from L2s to ZK to EIPs across different chains, without pushing a single product. Product-specific conversion only arrived after that value-first stage had earned it.

The DevRel Operations Grid asks one question per task: is this work human-led, AI-assisted, or agent-led? That is a workflow design question rather than a philosophical one, and most DevRel work has a concrete answer. The grid maps a gradual shift, human-led to AI-assisted to agent-native, across content, community, support, and education. The key word is gradual. You onboard a new way of working, you don't flip a switch.

Docs sit at the top of the funnel now, because agents crawl them to answer developer questions in conversations you never join. Generative Engine Optimization, or GEO, replaces SEO as the mental model here, and well-structured docs beat a polished marketing site as a source agents actually cite. Francesco's specific addition to that idea: publish an llms.txt file and design real agent skills, then write every guide for a system that reasons over it rather than one that just skims it.

Applied to daily work, the grid looks like this:

• Docs: AI-assisted draft, human judgment on accuracy and voice.

• Tutorial production: AI-assisted structure, human judgment on what's actually hard.

• Support triage: agent-led classification, human-led response on anything complex or nuanced.

• Hackathon outreach: agent-led prospecting and first contact, human-led relationship building.

• Community moderation: agent-led flagging, human-led final calls.

• Content distribution: agent-led scheduling and formatting, human-led strategy on what to amplify.

Even at scale, community still runs through a small, trusted core. Find your top 50 contributors and amplify their wins in public, because the rest of the community grows around whatever you choose to celebrate. The permissionless community angle was specific to Consensys's web3 context, but the design logic holds anywhere. A community that contributes without permission grows faster and produces better work, because the contributors select themselves through real investment. The system still needs clear standards and a moderation layer near the edges, instead of a bottleneck at the front door.

The DevRel Workbench Was My Capstone Project

Six weeks passed and the major tools shipped. The DevRel Workbench is live at https://10xdevrel.atharvashah.com.

The Launch Checklist Generator takes a changelog and returns a DRI-mapped checklist covering pre-launch, launch day, and post-launch tasks with priority levels. The Demo Run of Show Builder takes a demo brief and returns a timed agenda, one that carries speaking notes and a fallback matrix for common failure modes.

The Content Repurposing Planner turns one source asset into six content briefs across channels. The Demo to Distribution Planner turns one product change into a connected demo flow, plus a launch checklist and a two-week content calendar.

The playbook library ships 15 playbooks covering the major DevRel motions. Community members can submit best practices, vote on submissions, and get approved contributions added to the library with contributor attribution.

The biggest technical lesson from the build is that scoped tools beat general assistants. That holds every time. I built a general AI assistant early for the workbench.

It underperformed the four scoped tools by a meaningful margin. The scoped tools have clear, testable success criteria. Here is a question you answer objectively. "Did this generate a valid launch checklist with DRI assignments, priority levels, and correct task categorization?" The question "Was this conversation helpful?" has no objective answer.

That pattern held everywhere I looked during the cohort. The best agent demos I saw had narrow scopes and explicit success criteria. Devin's Nubank case study is one of them. None of them were general-purpose assistants with vague goals.

The Habits That Actually Changed After the Cohort

Three habits changed after the cohort, and all three came directly from a session.

Agent experience is now baked into my documentation process. When I write a getting-started guide or update an API reference, I run through it as if I were a coding agent. That agent executes every step literally, and a failure at any step sends me back to fix the doc.

The learning loop is scheduled now instead of reactive. Forty-five minutes a week goes to ecosystem scanning, where I taste new tools on purpose, document what changes, and update my own workflow list. That block sits on the calendar like any other meeting.

The DevRel Operations Grid is how I plan my week, across three columns: human-led, AI-assisted, and agent-led. Work that belongs in the third column and still sits in the first becomes a backlog item.

Thanks

Bianca built a cohort structure that gave people permission to ship imperfect work in public. They then learned from it in real time. That's harder to design than it sounds, and the format held up across six weeks.

Manik, the YouTube walkthrough we recorded together was the best QA test the workbench could get. You were the first person to use it cold in real time. Some parts held up and some parts got cut on camera. Both outcomes were useful.

Daniel Pisu, your conversations across the cohort gave me the most direct feedback. They told me whether the workbench landed for a working DevRel practitioner. That's the signal that matters.

To my team at AccuKnox, the real problems I meet every week shaped everything I built here. The launch checklist tool was a direct export of the actual checklist we use. The demo run-of-show builder came from what breaks when you have no run of show. The workbench is a product built from the job itself rather than from imagination.

The cohort ends on June 9. The workbench keeps shipping. Go try it out.

Related reading: The Future of Leadership Is Fluid and Meritocratic and AI-First DevRel: 15+ Playbooks for Content and GTM.

Leave a comment

This is a recorded podcast I did with Manik, a DevRelUni Cohort 7 colleague. We sat down on May 20, 2026, ran the camera for about 46 minutes, and walked through every part of how I actually run DevRel at AccuKnox. The post below is the full structured writeup, every number, every framework, every mistake. If you'd rather watch the conversation, the recording is right under this paragraph.

Filmed live during DevRelUni Cohort 7. Roughly 46 minutes.

This is the deck I built for the session. The article follows it block by block, with the slides embedded inline at each beat. By the end you'll have the full playbook: how I think about the role, how I run GTM, what I tell anyone trying to break in, and the three mistakes I'd undo if I could rewind.

What This Conversation Actually Covered

Manik wanted a structured walkthrough, not a vibes call. So we set an agenda and stuck to it.

Seven blocks. Journey, online presence, GTM, what DevRel actually does, DevRelUni and the Workbench, advice, mistakes. Each one gets a section below.

Block 1. The Role, The Journey, The Nine Pillars

I'm Atharva Shah. DevRel and AI Product Manager at AccuKnox, a cloud-native security company building CNAPP, CWPP, API Security, and AI Security. KubeArmor is our open source runtime security engine for Kubernetes. I joined AccuKnox 2+ years ago as the first DevRel hire and built the function from zero.

My day-to-day is six jobs duct-taped together, and the split changes week to week depending on what's on fire.

Content work is the biggest share of it: over 100 technical blogs, 200-plus help docs, and six books published on Amazon KDP, three of them endorsed by US CISOs. GTM work has meant launching three product verticals from zero, AI Security, API Security, and SBOM, each with its own launch package, which I break down in Block 3. Events work covers 15-plus webinars produced, five-plus offline events, and running RSA Conference 2026 end to end, with KubeCon Mumbai planning underway for June 2026. Tooling work built an AI-native demand gen stack that replaced a $4K-a-month agency with $400 a month of AI tools, a 90% cost cut with better output. Community work is partner co-branded propositions, DevRel network building, and hackathon CTFs. Engineering work is forward-deployed: landing page builds, in-house automations, release notes, tenant enablement.

My competency map has nine pillars: AI and Applied AI, Cloud-Native and DevOps, Web Development, DevRel and Technical Writing, Product Management, Growth and SEO, UI/UX for Conversions, Technical Deep Dives, and Hot Tech News. I don't just write about tech. I ship it, market it, and measure it.

The receipts: 1M+ organic traffic generated across blogs, docs, and product content. +100% year-over-year growth in LLM citations, tracked via LLM Labs. Gartner reviews grew from near zero to ~60. Each vertical launch was a full content cluster, not a press release.

If you're a fresher or just starting out, my number one advice is this. Assume you already have five years of experience. Pick the domain you want to claim. Then build your portfolio toward that claim. Identify your top skills, build a competency pillar list, and get aligned with what you can actually operate in versus what's noise. Pivot quickly when the alignment is off.

Block 2. Freelance and Online Presence

Nobody hires you because of your resume. They hire you because they've already seen your work. Your online presence is your portfolio. Three pillars do all the heavy lifting.

Pillar 1. The Website

atharvashah.com is the home base. Everything else points back to it. Six service pages: AI and Automation, Web Dev, Growth and SEO, Python Dev, Product Management, Gen-AI Creatives. Five subdomains that each do one job:

• blog.atharvashah.com for Substack

• store.atharvashah.com for Gumroad products

• offers.atharvashah.com for HTML landing pages

• assets.atharvashah.com for client PDFs

• 10xdevrel.atharvashah.com for the DevRel Workbench

Don't ship a one-pager and call it done. Build a real site with a value proposition, service cards, a brag list, publications, and links to every channel you own.

Pillar 2. The Blog

A website gets you calls. A blog builds your credibility. Mine is on Substack: 33 published articles, 30%+ email open rate. Mailchimp's own benchmark report puts the cross-industry average around 21%. Blogs compound. Every article is a permanent sales page that keeps converting months after you ship it.

One important note for early-career writers: skip the thought-leadership pieces in the beginning. Those land much later, once you have 10 to 20 years in the space. In the first few years, write about what you actually shipped at work.

What did you build, what did you fix, what workflow did you find that broke through the noise. That kind of writing has a clear point of view because it's real.

Pillar 3. X and LinkedIn

X is for fast thought pieces, signal consumption, and network building. LinkedIn is for wider professional reach and inbound leads. Different formats, same core ideas. I rewrite every Substack piece into a Twitter thread, a LinkedIn carousel, and a Substack Note. One piece of content becomes five distribution shots.

Four Portfolios, Not One Resume

I keep four portfolios alive: blog (Substack plus external bylines at Real Python, freeCodeCamp, TutorialsPoint, CloudMatos), web development (production sites and client work), video (currently building Cozy Console on YouTube, repurposing blogs into video), and community (engagement, events, cohort participation).

The system underneath is knowing your niche, your ICP, or ideal customer profile, and your skill tree, then building content around your competencies. Validate ideas in public. Let people watch you work. I have 17 audience archetypes documented with exact pain points and buying triggers, which is what "know your ICP" turns into once you actually write it down.

📷 Image placeholder: Live screenshot of atharvashah.com homepage showing service cards grid, on-brand dark theme. 16:9. Take from production site.

Block 3. GTM That Actually Works

GTM is the system that carries a product from built to bought. Marketing borrows the story after GTM has already written it.

The Launch Package Behind Three Verticals

Three verticals from scratch: AI Security, API Security, SBOM. For each one, the launch package included a positioning doc, competitive analysis, a 5-to-7-article blog cluster, a landing page with a value proposition rewrite, a webinar series, and a partner co-branded proposition.

One of those clusters drove most of our AI visibility growth. Seven articles, including "2026 Applied AI Glossary," "Practical Tips for Reducing AI Costs," and "AI Slop Is a Skill Issue." That cluster alone is responsible for a meaningful chunk of the +100% YoY growth in LLM citations.

The Five-Step Motion Every Launch Follows

1. Start with the narrative. What problem are you solving and for whom. Write the positioning before you write the landing page.

2. Content-first GTM. Your blog cluster IS your launch plan. Each article targets a different search intent. Without the cluster, the launch plan does not exist.

3. Distribution beats creation. One piece of content, five channels. My Substack-to-social flywheel is what makes the work compound.

4. Measure what matters. Organic impressions, LLM citations, qualified registrations. Skip the vanity metrics.

5. Partner motions. Co-branded content, joint webinars, shared distribution. 5+ partner propositions built at AccuKnox so far.

Consulting Wins Outside Work

Two recent ones worth naming. An SEO client went from 2K to 8K monthly organic visitors in six months. 4x growth, mostly from cluster strategy and on-page fixes. A second client had a manual processing workflow that ate 8 hours a week. Python pipeline, one weekend of work, cut it to 45 minutes.

📷 Image placeholder: Organic traffic chart, screenshot from Search Console or Semrush, showing the curve from 2K to 8K over 6 months. Optional, only if you can pull a clean version.

Block 4. What a DevRel Should Actually Do

The role is misunderstood. DevRel gets reduced to conferences and tweeting, which is maybe 10% of the job.

A DevRel's real job is to bring measurable ROI to the company by improving developer growth. Not awareness. Not vibes. Growth you can tie to a number on a dashboard.

After three DevRelUni sessions of watching how the speakers framed their own wins, I settled on four things that actually matter.

The first is messaging: lead with ROI, not features. Developers don't read your feature list. They care about what your product solves, so every blog, every demo, every talk should answer one question, what does this save me. Position the product as a shortcut, not as a tool.

The second is integrations. If your product connects to the giants, AWS, GCP, Kubernetes, Terraform, that connection is your product-market fit story. Integrations signal maturity and lower the friction of trying the thing, so lead with them rather than burying them on a features page.

The third is developer tooling. Simplify your APIs, make SDKs that are actually pleasant, and keep your docs current and honest, no outdated screenshots, no broken code samples. The developer portal is your storefront, and a broken storefront makes the rest of the work moot.

Build internal apps too, now that AI credits are cheap: an ROI tracker, an SEO analytics tool, a content calendar, whatever your team is still running through Excel. Tools like Lovable, Versus Code, and Claude Code make this trivial to ship, so get your org to sponsor the credits and go build it.

The fourth is proof. Track developer signups, docs traffic, community growth, content attribution. A DevRel who can't tie the work to a business metric is the first cut in a downturn.

What I'd Hand a New DevRel Hire on Day One

1. Build an AI content layer for your product. Use tools like MagiOOS to scale content creation without losing quality.

2. Set up social signal monitoring. Use SensorHub to track what developers say about your niche on Reddit and X.

3. Create a developer onboarding experience that works in under five minutes. Time-to-first-value is everything.

4. Ship integration guides for every major platform your product touches.

5. Build a community feedback loop. Not a Slack graveyard. An actual loop with action items.

6. Produce real-workflow demos. No toy examples.

7. Run or join hackathons. If senior, organize. If early-career, compete. Either way, show up.

8. Build a DevRel metrics dashboard. Docs visits, tutorial completions, API adoption curves, community engagement.

9. Create a content repurposing pipeline. One webinar becomes a blog, a thread, a short, a LinkedIn post, a Substack Note.

10. Build internal tools and automations that make your own team faster. This compounds quarterly.

Block 5. DevRelUni and the Workbench I'm Building

How I Found DevRelUni

X. I saw the signal, bookmarked it, and signed up. That's the obvious answer. The interesting one is how that bookmark made it into my workflow.

I have a script that fetches my X bookmarks periodically and pulls them into my Obsidian vault. Anything I bookmark shows up in my notes automatically. If it's actionable, it lands in my to-do list, which is also synced. My scrolling becomes research instead of a time sink. This is part of my digital twin, which is a set of files that describe me well enough for an agent to act as me. It is also my number one piece of advice later on.

The vault itself has 1,570 knowledge graph nodes right now. Every meeting transcript, brain dump, email, signal, bookmark, all of it organized by AI. I'll talk more about the system in the advice section.

📷 Image placeholder: Obsidian knowledge graph visualization. ~1,570 nodes connected by lines, dark background, soft red and blue node clusters by topic. Square aspect. Screenshot from graphify-out/graph.html or generate via Banana Pro.

The Cohort Experience

Cohort 7 ran from April 28 to May 26, 2026. Five live sessions, speaker lineup that included Bianca Buzea, Nader Dabit, Patrick Skinner, Hassan El Mghari, and Francesco Andreoli. Each session unlocked something new, but the peers are the real value. People like Manik bring different angles and different industries, and working as a pack toward the same goal creates social accountability that's hard to replicate alone.

Honest feedback for future cohorts: I'd run it for a full year. The momentum is real and a month feels short. Add hands-on workshops and more community success stories, the way Lenny's Podcast works but from inside the cohort.

The DevRel Workbench

10xdevrel.atharvashah.com. Open source web app, four core tools, plus a community playbook library.

The problem: DevRel work is fragmented and repetitive. Every launch, every demo, every content repurposing cycle starts from scratch. I do this work manually every week. So I'm shipping a sharper version of my daily workflow as a tool.

The first tool is a launch checklist generator: input a changelog entry, get a T-minus checklist with task owners, a DRI map, and a readiness score. The second is a demo run-of-show builder: input product, audience, and time slot, get a timed structure with speaker notes and fallback scenarios. The third is a content repurposing planner: input one blog, webinar, or transcript, get six content briefs, a tutorial, a narrative blog, a webinar pitch, tweets, a LinkedIn post, a Substack Note. The fourth is a demo-to-distribution planner: input a feature announcement, get a three-layer plan, demo flow, launch checklist, two-week distribution calendar.

Around those four sits a community playbook library with 5 seed playbooks, community submissions, upvoting, and owner approval. Playbooks cover normal day-to-day moves, building community, content cycles, launches, and the harder stuff most resources skip: handling outages, crisis comms, incidents.

Tech stack: Next.js plus Tailwind, OpenAI and Claude for structured output, Supabase for storage. CI/CD already wired. Hosted on a subdomain off my main site.

📷 Image placeholder: Screenshot of the DevRel Workbench landing page at 10xdevrel.atharvashah.com, showing the 4 tool cards on the home grid. 16:9. Real screenshot from production.

Block 6. Three Pieces of Advice (Plus One Bonus)

Advice 1. Build Your AI Digital Identity. Start Today

Create a vault. Obsidian, Notion, whatever. Just start. Dump everything in: meeting notes, brain dumps, emails, bookmarks, job listings you admire, future goals.

You don't have to organize it on day one. Embrace the chaos. Let AI process and categorize it.

The system compounds. It took two years for my vault to reach its current node count, but it grows exponentially once the inputs are flowing. Your digital twin becomes your second brain, a single local folder of plain text that holds everything you know and finds it again. It remembers what you forget. It connects dots you miss.

Tool stack I run on. Go all-in on the Claude stack:

• Claude Chat for ideation and research

• Claude Code for building automations, writing scripts, managing the vault

• Claude Routines for recurring scheduled tasks (content audits, pipeline checks)

• Claude Skills for reusable workflows you trigger with a slash command

• MCP Connections to plug Claude into Slack, Drive, GitHub, Buffer, anything

• Plugins for extending Claude inside your specific domain

• MagiOOS for scaling content creation

• SensorHub for social signal monitoring

You don't need 15 SaaS tools. You need one AI backbone with good connectors.

Advice 2. Go Deep in Your Niche. Build in Public

Pick your niche and know it inside and out. Build things in that niche. Ship them. Show your work.

Publicly validate ideas. Let people see your process, not just your polished output. The compounding effect of niche expertise plus public building is unmatched for career growth.

Specific beats general. "I help cloud-native security companies with GTM" beats "I do marketing." Every time.

Compete in hackathons if you're early-career. Organize them if you're senior. I won 1st place at CRIF Hackathon 2023, beating 37 teams and 140+ participants with an NLP-powered media reputation engine. Hackathons compress months of learning into 48 hours. If you're senior, organizing them builds community, sources talent, and stress-tests your product.

Advice 3. Clean Your Algorithm. Separate Your Feeds

Your feed IS your environment. If your feed is slop, your thinking becomes slop.

My setup: two accounts, two purposes.

Primary account. Extremely focused. Follow only the top operators in your industry, the most active builders, the most reputed voices. Underdogs count too, not just the big names. When I log into my main feed, every scroll, every tweet is high-signal. The algorithm feeds itself once you train it.

Secondary account. Brain rot, entertainment, whatever you enjoy. Vacation mode. No guilt. The separation means you can switch off completely when you need to, and when you're on, every signal matters.

Don't just consume. My X bookmark script auto-pulls interesting tweets into my Obsidian vault. Scrolling becomes research.

Get a buddy or join a cohort. Preferably global, preferably with a strong technical lead. Social accountability and peer pairing are underrated growth accelerators. DevRelUni is proof. Working alongside peers like Manik toward the same goal changes how fast you move.

Advice 4 (Bonus). Apply Real Frameworks

Code is commoditized. Growth is not. Growth requires multi-step thinking, and for that you need frameworks. DevRel means juggling multiple hats, so you need mental models to decide what gets your time.

Three I rely on:

• Eisenhower Matrix. Separate urgent from important. Most DevRel fire drills are urgent but not important. The blog cluster that drives organic traffic for 12 months is important but not urgent. Prioritize accordingly.

• Pareto Principle (80/20). 20% of your content drives 80% of your traffic. 20% of your community interactions drive 80% of your conversions. Find the 20% and double down.

• MEDIC Framework. Shoutout to Patrick Skinner from the last DevRelUni session. Metrics, Economic Buyer, Decision Criteria, Decision Process, Identify Pain, Champion. It's a sales framework, but it applies cleanly to how you position DevRel programs internally to get buy-in and budget.

Identify two or three mental models that fit your context and apply them consistently. The frameworks don't think for you, but they stop you from thinking in circles.

Block 7. Three Mistakes I'd Undo

I'd cast a wide net here because these aren't unique to me. Most operators I know have made the same three.

Mistake 1. Juggling Too Many Things at Once

I'm guilty of this to this day. Spreading thin across 10 projects means none get the depth they deserve. Right now I'm focused on the DevRel Workbench. In the background I still have to maintain my website stack and show up at work. The honest answer is two to three things at a time, max.

Not every project deserves equal attention. If project X is going to add more ROI than project Y, project X gets more depth. Map your projects to ROI. Time-box the rest. The quality of your output collapses when you context-switch this much.

Mistake 2. Focusing on Low-Priority Work

Being busy is not the same as being productive. I spent months polishing things nobody was going to see, optimizing things that didn't need optimizing. There's an old developer trap that captures this perfectly: until you hit 1,000 users, why are you worrying about Kubernetes. You can operate out of an Excel sheet at that scale. Scaling work you don't need for two to three years is theater.

The fix: ruthless prioritization. Ask "does this move the needle?" If the answer is no, cut it. This is where the Eisenhower Matrix and Pareto save you. Without a framework, everything feels equally important.

Mistake 3. Engaging for the Sake of Engagement

There's a lot of bait on social media right now. A lot of AI-generated slop content. People showing up to every event, every call, every Slack thread without a clear reason. They want to feel included. They want to feel part of it.

Trivial engagement gives the illusion of progress. The pipeline stays empty.

Instead of joining 15 different communities, pick two or three where your audience actually lives. It would not make sense for me to participate in Web3 conferences, my audience lives elsewhere. Quality of engagement beats quantity, and one deep conversation beats 20 surface-level exchanges.

DevRelUni works for me because the conversations are deep. Do less, but do it more mindfully. Burnout is not a flex.

Watch the Recording, Try the Workbench, or Just Start

Manik, thanks for the session and for pushing the structure. To everyone else in Cohort 7, see you in the next class.

Watch the full recording at the top of this post if you want the parts I cut for length, including the live workflow demo and the moments where Manik pushes back, about 46 minutes, worth your commute. Try the DevRel Workbench at 10xdevrel.atharvashah.com, four tools, free, open source, and if you ship feedback I'll prioritize it. And if any of this was useful, follow along: Substack at blog.atharvashah.com, X at @cultist_dev, LinkedIn at linkedin.com/in/atharva-shah-tech. This is one piece in a longer series on building DevRel and growth functions from scratch with AI as the backbone.

Go ship something today.

Leave a comment

TL. DR: I did not set up Magi as a prompt box. I set it up as a content operating system. The real work was manual. We had to create the knowledge architecture first: 11 markets, 11 ICPs, 33 personas, competitor context, influencer tracking, reusable source collections, and mandatory SEO frontmatter. At AccuKnox, one thing became obvious fast. Content quality was never the model problem. It was the input structure problem.

Most AI content tools break in the same place, because they start generating before the company has defined what the AI should know. That gap produces the usual sludge: generic blog posts, flat LinkedIn copy, landing pages that mention features without understanding buyers, and email sequences that read like they were written for a company with no history and no real market.

That was the setup problem I was solving with Magi for AccuKnox.

The goal was simple: take everything the team already knew, structure it by hand, and make it usable by the system.

That meant product context, buyer context, competitor context, transcript context, and publishing rules, each one built by hand, cleaned up, and mapped into a format Magi could use.

What this looked like at AccuKnox

This was not a one-off experiment. Across internal AccuKnox working sessions, three threads kept repeating:

• The taxonomy had to be explicit. Market to ICP to persona to knowledge base to ideas.

• The publishing standard had to be enforced. Every blog needed a TLDR, frontmatter, FAQ schema, links, structure, and positioning context.

• The interface had to match the workflow. Calendar, collections, knowledge views, content generation states, and editor UX all mattered, because the team had to use this every day.

One meeting summary captured the operating model in one line:

"Take the first cut. I'll fine tune at the very end."

The team built the structure first, and the AI handled the transformation after that, with human judgment staying at the edges where it belonged.

The core architecture

The entire setup got easier once I stopped thinking about content and started thinking about buyer-mapped data.

The foundation was simple on paper: 1 Market -> 1 ICP -> 3 Personas. That meant 11 markets, 11 ICPs, and 33 personas, and each persona needed more than a job title. Every one carried a real description, primary use cases, pain points, the KPIs that person gets judged on, and enough context for the AI to understand why that person would care.

We mapped three ICP types across every market. User covers the hands-on operators: the Security Engineer, DevSecOps Engineer, DevOps Engineer, MLSecOps Engineer, Platform Engineer, Kubernetes Engineer, and Security Architect. Buyer covers the decision makers with budget: the CISO, VP of Security, Chief Information Officer, Chief Data Officer, AI Governance Lead, and AI/ML Product Manager. Partner/Reseller covers channel and distribution: the Director of Sales, Channel Partner Manager, Account Manager, Product Manager, MSP Manager, and System/Technology Integrator.

That grid looks simple on a whiteboard. It gets hard once you run it across eleven markets: CNAPP, ASPM, CSPM, CWPP, KSPM, AI security, API security, DSPM, compliance, 5G security, and MSSP partnerships.

The full market grid looks like this inside Magi, once it is properly configured:

Each card is a live campaign anchor. Click into any one and you see the ICP, competitor set, influencers, and persona breakdown for that specific market. Building all eleven took weeks of working sessions before Magi generated a single draft, and that sequencing, structure before output, is what the rest of this setup was built around.

What went into the knowledge base

The spreadsheet schema was the real product spec. None of it arrived through automatic ingestion: we defined the markets, mapped the ICPs, wrote the personas, organized the collections, and decided what belonged where, by hand, before Magi could use any of it.

The knowledge base has seven layers, and each one held a different piece of the picture.

1. Personas and campaigns

The personas tab was where everything else downstream got grounded. It mapped market, persona name, description, use case, pain points, and KPIs.

Without that specificity, every market gets the same generic pitch. A CNAPP buyer wants to cut cloud risk, while a platform engineer drowns in runtime alerts. Show the AI that difference and the writing changes at once.

A fully built-out ICP looks like this inside Magi. This is the AI-SPM market with its ICP description, use cases, buying cycle, and three distinct personas mapped:

Every persona carries its own context stack. The AI-SPM User persona holds a description, use cases, and pain points: shadow AI, no standards, rapid rollout, poor visibility, and compliance gaps. Its KPIs are AI asset coverage, policy violations, risk events, audit readiness, and MTTR. The AI guesses at none of this. You put it in, and the system uses it.

2. Competitors

Every market needed direct competitive context. The rule we followed set four competitors per market: two big players with broad platform coverage, two niche players with specific point solutions.

That included name, website, LinkedIn, blog, and a short positioning summary. The system needed to know the shape of the market: broad platforms such as Wiz and Orca crowd some categories, and narrower players hold others. If the AI has no enemy map, it writes like it has never seen the market before.

Here is what the competitive layer looks like inside a live market. AI-SPM had Protect AI, HiddenLayer, and Robust Intelligence mapped with positioning context for each:

3. Influencers

For each market we tracked three people, with name, title, and LinkedIn. We tracked them for signal rather than for outreach. The people closest to a category write about their problems, and that is free market research. A list meant we read them instead of browsing at random.

4. Knowledge files

Everything the company already knew that was not yet in a usable format went in:

• FAQs and llms.txt

• Whitepapers and eBooks

• CVE pages and security advisories

• Press releases

• Technical documentation and help docs

• Playbooks (sales, onboarding, objection handling)

• Blog posts (published and competitor)

• Slide decks and pitch materials

• Important help doc URLs and sitemaps

• POC executive summaries

• Sales call transcripts and objection logs

Your company already holds explainers in sales calls, POC conversations, review notes, Slack threads, and internal docs, and that conversational material usually makes better source content than anything written for publication. As with the rest of the knowledge base, we still chose what to extract from these, how to classify it, and where it lived.

5. SEO frontmatter and brand rules

The difference between content that is readable and content that can actually ship is metadata, and we wanted the latter. Every blog needed mandatory metadata and SEO framing at generation time.

The required fields included title, excerpt, slug, author, meta.title, meta.description, tldr, primary_keyword, secondary_keywords, sticky_cta, and faqs.

That sounds administrative, but it sets the entire quality threshold for the output. Frontmatter, tone guidance, category rules, and required links went into the brief, and the draft arrived close to publishable. Our internal summaries backed this up: the standardized blog framework ran on 14 mandatory components, and skipping any of them was the fastest way to get a draft sent back for rework.

6. Landing page hierarchy

The landing page tab handled parent and child page relationships. That mattered because page generation without site hierarchy usually creates random one-off pages with no connective logic. We wanted category pages and industry pages to map back to a real information architecture.

7. Map knowledge to campaigns

One practical question drove this layer: which piece of knowledge belongs to which campaign? Without that answer, a large source library is just dead storage. With it, Magi pulled the right asset into the right flow, and the random content stopped.

Why the transcript layer mattered so much

At AccuKnox, sales calls, product demos, customer questions, Slack clarifications, internal review comments, and meeting recordings all held content that never got reused. This setup sharpened that problem for me.

Our internal call notes and transcript reviews were full of operating detail that rarely makes it into polished docs:

• what the team was blocked on

• how pages were supposed to be structured

• which campaigns were recurring

• what design assets were missing

• which types of outputs were ready for testing

That is the language people actually use to explain the business to each other, and it is worth more than another generic AI prompt. The transcripts were input for us first, not an automatic ingestion shortcut: they helped us understand what the system needed to know before we built anything.

The research layer also powers competitive monitoring, because Magi's research reports pull competitor LinkedIn posts, blog content, and CVE coverage into a single view per market, so you are not browsing five sources by hand.

For a rebuild from scratch, I would still start with transcripts, docs, and source collections, then handle generation settings, then map the ICP and knowledge layers by hand before expecting anything useful from the tool.

The product feedback loop with Magi

Getting the architecture right also surfaced what the product still needed. A few things came up repeatedly across working sessions:

• A media library for product screens, explainer screens, and carousel assets, so content generation could pull real visuals.

• More visible workflow stages, specifically In Progress and In Review.

• A progress bar during generation, so the team was not staring at a blank screen.

• A cleaner editor, so review did not feel like a chore.

The parts that were already solid enough to test were the calendar, the collections, and the TOFU blog template. A working calendar, working collections, and a working template mark the point where a tool crosses from demo to daily use.

BrandOS

Once set up, generated content stayed on brand by default, and you could switch between different voices, tones, and keywords for each piece. Brand rules could apply globally across campaigns or get overridden per content type.

Watch the video below to see the options inside Magi's Brand OS.

A prompt box alone does not teach a tool how a company sounds. Brand OS did that before it wrote a word: it held the tone guidance, not the person typing the prompt.

Calendar view

The calendar mattered because content teams do not think in isolated prompts. They think in deadlines, campaign timing, and channel mix.

A scheduling interface shows blog posts, landing pages, emails, and one-pagers together, and the tool stops feeling like an AI toy. It starts to feel like a planning surface.

Knowledge base and collections

Source assets need somewhere to live that is not a random shared drive or a Slack thread from six months ago. The knowledge base and collections views handle that: browseable, sortable, grouped by campaign. When the knowledge layer is invisible, people stop trusting it. When it is organized, they actually use it.

Knowledge to idea generation

Once a source item can generate content ideas, you stop treating research as dead weight. That created a tighter loop:

• collect signal

• classify it correctly

• map it to a campaign

• generate derivative content

That loop is what made the knowledge base compound instead of sitting as dead storage.

The ideas view shows this at scale. Each idea is tagged to a campaign, mapped to a knowledge source, typed by content format, and dated:

Click into any idea and you get a full brief: a Mini Post TLDR, the sourced excerpt that triggered it, and a draft generation button. The idea arrives already positioned, not as a blank page.

The interface that made the tool feel real

The interface was not just polish. It reflected the operating model underneath: campaign-first, content-type aware, with structured notes feeding generation, workflow states staying visible, and recent work one click away. That alignment decided whether the team lived in the tool or demoed it once and forgot it.

Content in production

With the architecture in place, content becomes a queue problem, not a blank page problem. Fifty-two pieces look like this: campaign tagged, content type assigned, owner named, status visible.

Generation runs from the brief. You set campaign, content type, ideas, and length, and the system pulls from the knowledge base, applies brand rules, and produces a draft:

That brief was grounded in a specific knowledge source, campaign, and ICP, and the output showed it.

What changed once the setup was right

Before the setup, Magi could write. It just wrote like a stranger. After the setup, the drafts had:

• clearer buyer framing

• better category specificity

• stronger SEO structure

• more usable prompts for emails and landing pages

• less generic phrasing

• a better shot at matching how the team actually talks

The model was never the bottleneck. The knowledge architecture was.

The instinct, when output disappoints, is to reach for a better prompt. Here, the gap was never the model. It was eleven markets and thirty-three personas mapped before Magi wrote a single draft.

Leave a comment

From zero to 18 flags: architecture, UX, challenge design, deployment, and launch strategy behind KubeArmor AI CTF.

Static workshops don't teach security. They teach patience. You sit through slides, nod at diagrams, and leave with zero hands-on reps. So instead of running another workshop, I built a full browser-first CTF platform in one day.

I work DevRel at KubeArmor. The goal was simple: give AI security learners something they could actually play, not just watch.

The result shipped with 3 tracks, 15 primary challenges, and 3 bonus flags, for 18 flags total. Registration and the scoreboard run on CTFd. The gameplay runs on a custom browser app I built. Solve checks are deterministic, not model-dependent, and the whole thing deploys through Docker.

This is the build journal: the decisions, the tradeoffs, and the exact order I built things in to make one day work without the platform falling apart under real players.

Why Browser First Decided Everything Else

The first decision was strategic, not technical. If participation has friction, conversion drops. A CTF that demands local setup loses people before they see a single challenge. So the event had to run entirely in the browser.

That single choice split the platform into three pieces: CTFd for registration and official scoring, a custom browser app for the actual game experience, and a backend runtime that keeps secrets and challenge logic server side. Players get a scoreboard workflow they already trust from other CTFs. I get to build AI-native challenge interaction without fighting a plugin system that was never designed for it. And because the runtime, not the browser, holds the challenge logic, solve checks stay deterministic no matter what a player's browser can see.

The Build Order That Kept One Day On Schedule

My rule for this build: do not start from individual challenges. Start from the platform they run on.

I have watched CTFs sink into content sprawl before the runtime even works: a pile of half-formed challenge ideas and no working platform under them. So I locked the scope first. Three tracks, five primary challenges each, one bonus per track, CTFd as the scoring source of truth, the browser app as where players actually solve. Any ambiguity at this stage would have cost hours of rework later, so I fixed it before writing a line of challenge content.

With scope locked, I built the runtime shell next: Express and EJS, server-rendered pages that are simple to debug under time pressure. I was not trying to win a framework debate. I was trying to ship.

Before authoring the full challenge catalog, I validated one complete solve path per track, end to end: Prompt Injection, Agent Workflow, and Hidden API. Only after those three slices worked did I fill out the rest of the challenge JSON and the bonus progression logic. Admin and operational controls, reset paths, session visibility, the solution library, came last, because those exist for organizers, not for the players who show up first.

The one rule I broke early and paid for: AI output varies from run to run, so solve logic can't rely purely on model text. I paired every prompt flow with a deterministic regex or action check, which is what kept challenges solvable even when the model's phrasing drifted mid-event.

Architecture: Browser Game, Deterministic Checks, CTFd Scoreboard

Every challenge runs in the browser: prompt manipulation tasks, constrained agent workflow attacks, hidden API tamper paths. Nobody needs a local AI setup to play.

Challenges themselves live as JSON, loaded dynamically, so I could tune metadata, system prompt behavior, flag values, solve patterns, and track-level bonus progression without touching platform code. When the live LLM went unavailable or gave an inconsistent response during testing, a fallback mode kept the deterministic checks running anyway. That fallback saved a testing session more than once: I could keep verifying challenge logic even when the model itself was misbehaving.

Provider keys stay server side, with no raw secrets exposed to the front end. Solve state tracks per user session, and admin access to the control operations is role-based.

The UI Rule: Understand The Objective In Ten Seconds

I treated this as a product, not a challenge dump. I have seen enough CTF sites that are a bare list of problem statements and a submit box, and that shape works for people who already know CTFs, not for someone trying it for the first time.

So the home page works as a mission board with progress context, not a login screen. Track pages show the challenge list and status in one view. Challenge pages keep the conversation, the solved state, and the prompt box in a single loop, so nobody has to switch tabs to remember what they were doing. A player should understand what to do within seconds, see their progress at a glance, and get from home to track to challenge in one click.

For organizers, I built an admin dashboard with rate limit visibility and user management. It also gives quick access to solution guides, because a platform that's hard to run doesn't get run twice.

Testing For Trust, Not Coverage

The fastest way to lose a CTF's credibility is inconsistent solve behavior. If someone submits the right answer and the platform doesn't register it, that player stops trusting the event. So I prioritized testing ergonomics over coverage metrics: deterministic solve checks in the runtime, reset paths for fast retesting, seeded demo users, visible solve status per challenge, and structured session storage I could inspect directly.

Then three passes, each from a different starting point. Could I solve from a blank state quickly, could a peer solve using only the hints I'd written, and could someone with zero context finish a challenge with nothing but what's on the page? That third pass is the one most builders skip under deadline pressure, and it's the one that catches the UX gaps a creator is blind to after staring at their own platform all day.

CTFd Integration And Deployment

The deployment model is intentionally hybrid. CTFd handles registration, team context, and the scoreboard, because that's a solved problem and players already trust it. The custom platform handles everything CTFd was never built for: AI interaction, challenge runtime, deterministic solve checks. Forcing that into a CTFd plugin would have meant fighting the plugin system instead of building the game.

The runtime ships as a containerized Docker Compose stack, with a persistent volume for session and solve state and a root-level environment file for provider keys and rate limits. That gave me a local Node process for fast iteration during the build and a repeatable container for the actual event, with predictable data paths for backup and restore. For a DevRel-led event, setup friction for the organizer running it matters as much as friction for the player joining it, so Docker went in on day one instead of getting bolted on afterward.

Difficulty Design

Difficulty was layered on purpose: easy challenges build early confidence, medium stages teach the deeper patterns, hard stages demand chaining and precision, and bonus flags reward finishing a full track.

In testing, prompt injection challenges felt like the fastest track to clear. The workflow and hidden API attacks demanded chained, multi-step reasoning, and took noticeably longer to work through. That gap was the intended shape, not an accident: a beginner should finish a meaningful chunk of the event, and an experienced player should still hit real depth by the end.

How I Actually Vibe-Coded This

I used GitHub Copilot for most of the implementation. The speed came from fixing the intent and boundaries of each slice before I ever opened the editor, then using Copilot as a fast implementation partner inside those boundaries rather than accepting whatever it generated first.

The loop, every time: I wrote a clear objective for one thin vertical slice, one challenge page, one solve path, one admin operation. I drafted candidates with Copilot, validated the behavior immediately in the browser and in session data, and kept only the code that matched the deterministic solve logic and the product flow.

Vibe coding gave me speed. Fixed scope, deterministic solve checks, and that thin-slice discipline kept the quality from sliding, because scope never drifted mid-build.

For UI exploration, I used Google Stitch as a design-thinking accelerator, not as final output. It generated layout directions and interaction ordering fast, and I translated the ideas I liked into the Express and EJS runtime by hand, which kept the reliability guarantees intact. Stitch helped most on the homepage's information hierarchy and the track page's scannability, and it shaped the rhythm of the challenge pages too.

How I Wrote Prompts During The Build

Prompt quality was the hidden multiplier. I didn't write one giant prompt and hope. Every prompt followed the same shape. The objective named what exactly should get built in this step. The context listed the files, routes, and constraints in play.

The guardrails named what must not change. The output contract set how I wanted the result formatted, and the verification named what should be true once it was done.

An example from the actual implementation work:

"Implement a deterministic solve check for this challenge route. Keep existing API shape unchanged. Do not move secrets client-side. Return minimal patch. Add only required validation and update solved state in session."

For content and UX iteration:

"Rewrite this challenge instruction so a first-time participant can act within 10 seconds without losing technical depth. Keep tone assertive and concise."

For debugging:

"Given this route and this observed behavior, list the top three likely failure points, then propose the smallest safe fix first."

Prompt granularity mattered more than anything else. Mixing an architecture decision with a copywriting pass and a debugging session in one prompt produced garbage every time. Smaller prompts and tighter loops meant fewer regressions to chase down later.

What I'd Improve Next

At larger scale, four things would need to change:

• Analytics would need to go deeper, down to the per-challenge step and drop-off point.

• The event would need richer anti-abuse controls, since a public run draws different behavior than an internal one.

• Flags would need a one-click relay straight into the CTFd API, instead of the manual sync I ran during the event.

• Reporting would need to cover learning outcomes after the event, not just the final scores.

The architecture held up because the split held: CTFd never had to pretend to be a game engine, and the custom runtime never had to pretend to be a scoreboard. That's the part I'd keep unchanged even at ten times the scale.

Leave a comment

Walking into a POC scoping call with a 79-item checklist and no clear ranking is painful.

That was our reality.

Context, If You Have Never Sat In One

AccuKnox sells cloud-native security to enterprises. The platform covers posture management and runtime protection across Kubernetes clusters and cloud accounts. The buyer is a security team at a company large enough that a breach becomes a board-level event. Deals at that size never close on a demo. They close on a proof of concept.

A POC is a trial run inside the customer's own environment. It runs for weeks, not days, and the product has to prove itself against real infrastructure. Every step burns solution-architect hours and customer engineering time that neither side has much of.

I am a DevRel engineer, so POC scoping is not my job. It landed on my desk because I sat close to the sales engineering team and watched the same failure happen on call after call. We would finish a scoping call with every box filled and no idea which three items to run first. Someone would then sequence the whole POC from memory on the drive home.

The problem was hard to solve inside a meeting and easy to solve in a spreadsheet. Nobody else had built that spreadsheet yet.

The Problem With Flat Checklists

AccuKnox covers a lot of surface area: CSPM, CWPP, KSPM, CDR, GRC, AI Security, ASPM, SAST, DAST, SIEM integrations, and CI/CD.

Prospects rarely need all of it during a POC. They need a subset that maps to their urgent risks.

Our old process ran on one flat spreadsheet where every feature carried the same weight, so nothing told us where to start.

We would leave calls with every box filled and still not know what to prioritize first. We knew what was selected. We did not know what mattered most.

Why This Is a Resource Allocation Problem

Assume a prospect has six weeks and three engineers, with limited bandwidth to spare. We have two solution architects.

Without a way to rank what the prospect cares about, three outcomes show up fast.

1. We spread too thin and demo everything shallowly.

2. We go deep on the wrong module.

3. We miss the one module that could have carried the deal.

The gap was visibility, not sales talent.

What I Built

I converted our POC checklist into a weighted scoring engine in Excel.

Scoring rules:

• Must POC = 2

• Nice to POC = 1

• Not Required = 0

Each of the 15 modules has its own feature rows. Prospects choose a priority per feature from a dropdown. Excel aggregates those weights by module and produces a weighted score automatically.

We also calculate max possible score per module as:

feature count * 2

Then we compute score percentage and status (High Priority, Medium Priority, Low Priority, Not Scoped).

The dashboard chart puts weighted score and max possible side by side for all modules. One glance gives the ranking. Prospect input now drives that order directly, instead of getting reinterpreted from memory after the call.

The Excel Logic Behind It

This is plain Excel, but structured properly.

1. Controlled Input via Data Validation

Checklist column E accepts only:

• 1 - Must POC

• 2 - Nice to POC

• 0 - Not Required

No free text means cleaner downstream calculations.

2. Weight Mapping Formula

Checklist column F maps dropdown values to numeric weights:

=IF(E2="1 - Must POC", 2, IF(E2="2 - Nice to POC", 1, 0))

3. Module-Level Aggregation

Dashboard weighted score per module:

=SUMIF('POC Checklist'!$B:$B, A6, 'POC Checklist'!$F:$F)

4. Max Possible per Module

=COUNTIF('POC Checklist'!$B:$B, A6) * 2

5. Safe Percentage Calculations

IFERROR prevents divide-by-zero noise.

6. Linked Chart

The chart is bound to the score table, so updates happen immediately when priorities change.

Across 79 features and 15 modules, recalculation is effectively instant.

What Changed After Rollout

Before, the checklist told us what got checked. Now it tells us what to tackle first.

Post-call notes changed from paraphrased impressions to numbers. A module score now reads as KSPM at 8 out of 8, CDR at 8 out of 8, AI Security at 27 out of 50, and the ranking itself tells the team to start with KSPM and CDR and push the AI Security deep dive to week two.

The highest-scoring modules get engineering focus first, and low or zero modules get deprioritized with a clear paper trail behind the decision. The POC that follows mirrors the priorities the prospect picked during scoping, not the priorities we guessed at afterward.

Fifteen Modules Overload Memory, Not Judgment

I built this because I got tired of watching a good team make sequencing decisions from memory and instinct. With 15 modules and 79 tracked features, memory is not a reliable ranking tool. People default to whatever they heard last on the call, not to what actually carried the most weight.

Scoring gives judgment a starting point instead of replacing it. The grader took one afternoon to build, and every formula in it is plain arithmetic.

The result is a priority map that updates with every prospect input and hands the team a ranked agenda before the follow-up call is even booked.

AccuKnox is an AI-native cloud security platform. It covers CNAPP, KSPM, CWPP, CSPM, CDR, AI-SPM, and related domains. If you want to see how we scope POCs, reach out.

Related reading: Local AI Photo Curation Pipeline (No Cloud) and Build an AI Security CTF Platform in One Day.

Leave a comment

I Killed the Pricing Spreadsheet

Our sales team used a shared Excel file for customer quotes.

Realistically, two people fully understood how it worked.

I am a DevRel engineer. Pricing tools are not in my job description.

I built one anyway.

The Spreadsheet Ritual

Quoting pain can look like a small nuisance from the outside. It burns hours every week, and everyone tolerates it because the sheet "works."

This is what quote creation actually looked like:

• Open the file. Find the right version, hopefully.

• Enter asset counts into a formula chain nobody has audited in months.

• Wait for a number.

• Copy that number into a Word template.

• Export the file to PDF.

• Double-check the final amount, because we had already seen dropped digits.

• Send it.

That took 30 to 45 minutes per quote, on the happy path.

Then came the hidden failures.

None of this is theoretical. I watched all of it happen.

The Calculation Had Eight Dependent Steps

A calculator sounds like the obvious fix. Pricing for a multi-module B2B security platform is not seat count times price, though. The calculation ran through eight dependent steps, and each one changed the others.

• Modules: About a dozen products, including cloud posture, workload protection, API security, multiple appsec modules, AI model security, prompt firewall, vulnerability scanning, and log analytics. Customers rarely bought one.

• Billable unit per module: There was no universal seat model. Billing could be assets, nodes, endpoints, repos, apps, AI models, prompts per month, container images scanned, or GB ingested per day.

• Per-module divisors: Raw counts had to be normalized first. 1,500 API endpoints was not 1,500 units. Divisors varied heavily by module.

• Volume tiers: Normalized units across all selected modules rolled up to one total. That total set the tier, and the tier set per-unit rate across the whole quote. One extra module could shift pricing for everything.

• Discount: Applied to the post-tier subtotal.

• Support tier: Silver, Gold, or Platinum, each with its own multiplier.

• Subscription term: One, two, or three years.

• Currency and billing entity: USD or INR. INR also needed lakh-crore formatting. 10,000,000 should render as 1,00,00,000. Locale differences between machines made outputs inconsistent. Billing entity also controlled address, footer text, and legal language.

That is eight to ten linked pricing steps per quote.

A spreadsheet hides those links. One wrong cell reference gives the customer a wrong price, and nothing warns you.

What I built

A passcode-gated web app with a three-step wizard that outputs a branded PDF quote.

The design choices behind it mattered more than the interface.

Why Passcode-Gated Instead of Full Auth

A full login system would have delayed launch and added onboarding friction that this workflow did not need. Reps and select partners needed instant access from any device, including right before calls. A rotatable shared passcode fit the threat model and shipped fast.

OAuth could wait.

The entry point. One URL. No file attachments. No version confusion.

That URL became the distribution model. Nobody sent files, and nobody confused versions. When pricing changed, I updated the tool once and everyone got the latest values immediately.

Three Steps, One Order

I had seen the same failure pattern repeatedly. People skipped fields they found annoying and promised to fill them later. Sometimes they forgot.

The wizard blocks the pricing step until quote details are complete. It blocks PDF export until required fields are filled.

Step one captures everything that goes on the cover page:

Required fields with live validation. Nothing gets sent without a customer name, a preparer, a billing entity, and a logo.

Customer name, prepared-by, quote date, valid-until, billing entity, and customer logo are all required. The form blocks progression until they are filled. The valid-until date defaults to 30 days out so nobody sends an expired quote from an old template.

Here is what the same form looks like when it is done:

One Dropdown Switches Currency, Address, and Legal Text Together

Switching entities updates the registered address, currency defaults, number format, and legal footer simultaneously.

This took the most thought. It controlled a full downstream chain: currency symbol, number format, legal address block, footer text, and entity name. In the spreadsheet, these were manual and separate steps. People got one part right and missed another.

Select AccuKnox India Pvt. Ltd., and currency, formatting, address, and legal text switch together. The dropdown cannot check whether a rep picked the right entity on purpose. A rep still has to know which entity the deal belongs to.

The Pricing Engine

This replaced the old formula chain:

Eleven modules, live unit calculations, real-time tier tracking, and one very useful nudge.

The layout is intentional: inputs sit on the left, pricing impact sits on the right, and both stay visible at once. There is no "fill then calculate" flow. Reps type values and see outcomes live.

Each module row has three fields that matter:

• Count: Raw numbers from the customer.

• Divisor: Converts raw counts to billable units. I made this editable on purpose. Most reps should keep the defaults, but some deals require negotiated normalization factors. If the tool could not handle exceptions, reps would return to spreadsheets. Defaults are prefilled, overrides are visible.

• Units: ceil(Count / Divisor). Simple, visible, auditable.

The right panel handles everything else:

Total units are summed across selected modules. That single total sets the tier. The tier is quote-wide, not per module.

Price per unit, monthly list, annual list, discount, support multiplier, term modifier, and grand total update in real time.

The detail I cared about most was this message:

129 more units to unlock Tier 3 pricing ($22/unit)

In the old spreadsheet, tier thresholds were buried in formulas. Most reps never surfaced them during calls. That meant missed opportunities when a customer was already close to the next discount tier.

Now the threshold distance is explicit and live. Reps can test module combinations on a call and show the customer the tier effect right away, instead of promising to check and follow up later.

What Changed

Quote time dropped from 30-45 minutes to 3-5 minutes.

That gap matters. A same-call quote lands while the customer is still deciding. A next-day quote lands after they have moved on to other options.

Zero currency errors and zero wrong-entity quotes since launch. Nobody has reported an "Excel says one number, PDF says another" incident either.

New sales engineers can now produce correct branded quotes on day one. The spreadsheet used to require a one-hour walkthrough plus validation from a senior rep.

Quote cycles used to turn into long Slack threads. Rate card updates meant inbox blasts. New rep onboarding included spreadsheet survival training. None of that happens anymore.

Each quote is now a generated artifact tied to exact inputs. We can reconstruct what was quoted months later, including module mix, rate card, and discount.

If your B2B quotes still live in Excel, I am curious what your failure mode looks like. Reply here or find me on X.

Related reading: Composition vs Composable in Software Engineering and Shift Left Testing: Why Late Bugs Cost 100x.

Leave a comment

A private, reproducible AI pipeline for photo curation, captioning, music tagging, and folder export. No cloud uploads. No subscriptions.

I had 585 photos in one folder and no plan for them. I built a workflow with GitHub Copilot in VS Code that fixed this in one extended session. It ran on a Python script and a Markdown file that tracked every decision, across six phases. The folder became 62 ready-to-post directories. Every step happened on my own laptop, and no photo ever reached a server.

585 Images Named IMG_20241103_182344.jpg

Files in the folder looked like IMG_20241103_182344.jpg, sitting next to screenshot_edit_final_v3_REAL.png and remini-enhanced-kgwv6b.jpg, in no order at all. Every photographer collects a folder exactly like this one.

Lightroom already solves editing. It does not solve curation at scale. That work means deciding which 12 photos from a three-day trip belong together. It means keeping the pacing across 60 posts from repeating the same mood, twice on adjacent posts.

Music has to match the visual energy of each post, without reusing a track on the post next to it. And certain people and certain locations have to stay off public content entirely. An AI can close that gap, but only when you hand it the structure to work from.

From One Folder to 62 Named Directories

I used GitHub Copilot in VS Code and local Python 3. In one extended session, I went from a raw image dump to this:

Every operation happened locally. Copilot read filenames and the descriptions I had logged, not pixels, and my own curation criteria decided every grouping. My photos stayed on my machine the entire time.

The CURATION.md summary table: 62 active posts, 585 images assigned, zero cuts. This single document replaced every folder, sticky note, and spreadsheet I would have otherwise needed.

The Input Prompt That Started Everything

Here's the prompt architecture. Adapt it to your project:

I have [N] photos in [local folder path].

My goal: group them into [platform] posts for publishing over [timeframe].

Curation criteria:
- Timeline: roughly chronological, anchored to real events/trips
- Location: photos from the same place should travel together
- Vibe / mood: visual tone should be internally consistent per post
- People: flag posts that include [specific people] so I can decide on privacy
- Quality gate: no blurry, test shots, or obvious duplicates in any post

I have [an existing metadata log / no log — build one].
My image folder is [path]. Compressed derivatives live at [path].
My music taste: [genres, artists, references].

Deliverables I want:
1. A CURATION.md with all posts, image assignments, captions, music picks
2. A Python export script that builds a FINAL/ folder from CURATION.md
3. A post.txt inside each FINAL folder with caption + music ready to paste
4. An audit flag if any post breaks the [platform] image cap

Privacy requirement: all processing must be local. No uploads.

The Six-Phase Workflow

Phase 1 Audit and Inventory (Don't Skip This)

The AI didn't start with grouping. It read the existing metadata, counted files, and ran a structural audit first, and that audit found three problems before a single post got named. One post had 24 images, past Instagram's hard cap of 20, so it got split into two. Index 208 in my image log turned out to be a session boundary marker, not a real image, silently included in a post assignment. Thirty-two images from my oldest batch had never been individually logged.

Skipping this step would have shipped a broken export. The oversized carousel would have silently dropped four images at upload time. The ghost index would have thrown a file-not-found error during export. Neither failure would have announced itself without a deliberate check first. That is why the audit runs before anything else now, on every batch.

A section of image_log.md. SESSION 3, images 33 through 48. Each image logged with its compressed filename, a plain-English description, and a semantic tag. The AI read this file and built groupings from it. Not a single pixel crossed the wire.

Phase 2 Grouping by Timeline, Location, and Vibe

Grouping 585 images from 18 months of shooting was the hardest part of the whole project. Photos cluster naturally by trip or life phase first. Location matters within that: a Mumbai weekend and a Goa weekend can happen close together in time and still look nothing alike, so they need separate posts.

Vibe breaks the tie when two image sets share a timeline and a location but split by mood. One trip can hold a golden-hour outdoor set and a nightlife indoor set, and those still need separate posts. People acted as a privacy gate throughout. Any image with certain people in it got flagged for my own review before it could go into a public post.

The AI proposed 60 posts initially. After the audit, that became 62, two splits from the carousel-cap fix, plus the 32-image unlogged batch resolving into two dedicated archive posts.

Each post got a real name instead of a filename, something like P41 — Kerala — Backwaters + Garage Café + Coast. Getting there took a few passes at the title until it matched what was actually in the frame, rather than just where the photos were taken.

Key Clusters and Themes Discovered: the AI's location map of the library before a single post was named. Clusters like "KATHA Records Series" and "CSMVS Museum" emerged from overlapping session ranges and shared visual context.

The Post Details section of CURATION.md. Each cluster converted into a named post with exact image indices and a one-line description of the visual brief. P05 (OOTDs and Mirror Selfies) came in at a full 20 images, right at Instagram's carousel cap.

SESSION 6 in image_log.md, images 81 through 96. The tagging discipline held across every batch: filename, description, and a semantic tag. Enough for the AI to reason about visual groupings without ever seeing the photos.

Phase 3 Building the Export Script

This is what made everything reusable. export_final.py is a Python script that:

1. Reads CURATION.md as the source of truth

2. Parses the image index list for each post

3. Resolves each index to the actual filename on disk (handling AI-enhanced variants, shortened UUIDs, WhatsApp-formatted names)

4. Copies the HD original into FINAL/<PostID> - <Title>/P01a.jpg, P01b.jpg...

5. Writes a post.txt alongside the images with caption, music, and rationale

6. Outputs an _EXPORT_REPORT.md, a full accounting of every post, file count, and any resolution errors

The resolver was the interesting part, because my filenames came in three different formats depending on which app had touched them last: IMG-20250103-WA0012.remini-enhanced.jpg from WhatsApp plus an AI suffix, FF92EE38.jpg as a shortened UUID from a different app, and -kgwv6b.remini-enhanced.jpg as a partial hash format. The resolver cascades through them in order: exact match, then strip the .remini-enhanced suffix, then match on the first 8 characters as a prefix. Zero images failed to resolve.

The export script is also idempotent. Every run wipes FINAL/ and rebuilds it straight from CURATION.md. Edit a caption in CURATION.md and run the script, and the change is live in FINAL/. Move an image to a different post and run the script, and the folders reflect it instantly. CURATION.md is always correct, and FINAL/ is only ever a derived artifact of it.

P19, Golconda Fort Hyderabad after export: 10 images renamed sequentially (P19a through P19j), plus a post.txt with caption and music. Every file moved into place by the script, zero manual work.

D:\Remini\FINAL. 62 named, themed folders generated from CURATION.md. From "P01 - Desk & Dev Setup" to "P48 - Hotel Mirror Selfie + Canal Night" and beyond. One script run, fully reproducible.

Phase 4 Captions and Music

The caption philosophy was simple: terse and atmospheric for travel and scenery posts, since a Taj Mahal photo doesn't need the Taj Mahal explained under it, and warmer and more personal for portrait or home posts. No hashtag spam went into the draft, since that's a posting-time decision, and every caption had to add something the image didn't already say on its own.

The live VS Code session: post.txt open for P01, Desk & Dev Setup, CURATION.md active in adjacent tabs, the AI mid-way through captioning P21 to P30. Caption, music, and rationale drafted in one continuous pass.

Music followed a different rule: each track's mood had to amplify the image rather than fight it, and no generic "lo-fi beats" filler was allowed to stand in for an actual choice. After all 62 posts were drafted, a deduplication pass caught one track assigned to three different posts, plus several more repeating on posts that sat next to each other or shared a mood. Six swaps fixed it, each one a deliberate match for the post it landed on rather than a random substitution.

The export script stores a TRACK_REASONS dictionary for every post, recording why the music works. Months later, when I no longer remember the session, that reasoning is still sitting right there next to the file.

The Phase 3 Queue in CURATION.md. 13 of the 62 caption and music drafts. Disclosure for a locked-in desk setup, Cigarettes After Sex for a low-light portrait series. Each track justified by the visual energy of the post, not picked at random.

Phase 5 The QC Pass

Before calling the project done, we ran a coherence check across four questions. Does every image in a post share a real through-line, visual, narrative, or emotional? Does the title name what's actually in the post, or just where the photos were taken? Is the music still clean of duplicates after the Phase 4 fix? Are any captions too generic, too try-hard, or over-explaining the photo underneath them?

One title fix came directly out of this pass. P41 — Kerala became P41 — Kerala — Backwaters + Garage Café + Coast, because the images underneath it were three genuinely different subjects. The vague title would have misled anyone looking at the archive later, myself included.

Phase 6 Visual Sanity Check

The final step was a visual review, guided by AI-generated contact sheets. For the two most uncertain posts, P60 (Early Heritage & Portrait Archive) and P62 (Early Interiors, Culture & Misc Vibes), we generated PIL contact sheets, a grid of every image in the post rendered at thumbnail size:

from PIL import Image
import os, math

def make_contact_sheet(folder, output_path, thumb_size=(300, 300), cols=5):
    files = sorted([f for f in os.listdir(folder) if f.lower().endswith(('.jpg','.jpeg','.png'))])
    imgs = [Image.open(os.path.join(folder, f)).convert('RGB') for f in files]
    thumbs = [i.copy() for i in imgs]
    for t in thumbs: t.thumbnail(thumb_size)
    rows = math.ceil(len(thumbs) / cols)
    w, h = thumb_size
    sheet = Image.new('RGB', (cols * w, rows * h), (30, 30, 30))
    for idx, t in enumerate(thumbs):
        x, y = (idx % cols) * w, (idx // cols) * h
        sheet.paste(t, (x, y))
    sheet.save(output_path)

Within seconds of viewing the P60 contact sheet, two images looked wrong next to the rest of it. A white fabric close-up and a lakefront scene had ended up alongside Jantar Mantar stonework and Mughal architectural portraits. Both moved to P62, which had a looser, more eclectic brief anyway and could absorb them without breaking its own coherence.

P50, Goa Resort Morning after export: 14 images renamed P50a through P50n, with post.txt alongside. The original filenames were a mix of remini-enhanced variants, abbreviated UUIDs, and WhatsApp-formatted timestamps. The resolver handled all of them.

A filename list would never have caught those two images. The contact sheet did, in the time it took to look at it once.

What Made This Different From Auto-Tagging Tools

Nothing left my machine during any of this. Python read local files, Copilot read filenames and logged descriptions rather than pixels, and the export script copied files within the same drive. That mattered more than speed did. The alternative was uploading 585 personal photos to a service to get them auto-labeled. I wasn't willing to do that for a set that includes people I'd rather keep off a server I don't control.

The bigger difference was that the AI worked from criteria I actually wrote down, not a fixed label set. I reviewed every grouping before it became final, so the curation stayed mine even though the sorting was automated.

CURATION.md also turned into something more than a working file I'll delete later. It holds every grouping decision and every caption, plus the reasoning behind each music pick, so six months from now I can still see why two images landed in the same post. The same setup handles 100 images or 5,000 without changing shape. Next time I dump a new batch, I run the same prompt architecture, add any new filename pattern to the resolver, and get another FINAL/ folder out the other end.

Take It With You

I packaged the entire workflow into a SKILL.md. Any AI assistant that supports the VS Code Copilot skill format can invoke it. The file contains the six-phase workflow, the CURATION.md schema, and the export script skeleton, along with fixes for the failure points this project actually hit: the carousel cap, the ghost index, and the three filename formats.

Drop it into your VS Code setup. Point it at your folder. If you want the SKILL.md file itself, ask. I'll send the version that already handles WhatsApp exports and Remini-enhanced filenames, so you are not rebuilding the resolver from scratch.

Run It Yourself

Here's the full starter prompt:

I have [N] photos in [local folder path].
My target platform is [Instagram / Substack / portfolio / personal archive].

Curation criteria:
- Timeline: [yes/no, describe the date range]
- Location: [yes/no, describe the geography]
- Vibe/mood: [describe your visual style — e.g., "film grain, golden hour, blue interiors"]
- People: [flag posts with [names] for my privacy review]

I have [an existing metadata log at path / no log — build one from filenames].
Compressed derivatives are at [path / same folder].
Music: I like [genre / artists / specific tracks file at path].

Please:
1. Audit: count files, find cap violations, flag ghost indices
2. Group: propose posts with names, index assignments, and image counts
3. Export: write export_final.py that builds FINAL/ from CURATION.md
4. Caption + Music: draft all posts, log TRACK_REASONS
5. QC: flag music collisions, title vagueness, grouping incoherence
6. Visual: generate PIL contact sheets for any flagged posts

All processing must be local. No uploads.

Tags: #AItools #photography #contentcuration #localprivacy #instagramworkflow #buildingwithAI #promptengineering

Leave a comment

Uketsu writes under a mask. He is a Japanese YouTuber of undisclosed identity, known for a white papier-mâché face and a voice run through a pitch shifter, who built an audience on short videos where ordinary objects sit slightly wrong. Strange Pictures, his first novel, carried that same trick onto the page: floor plans, drawings, and case files appear as literal images the reader studies, not prose describing them. Jim Rion's English translation reached UK and US shelves in 2025 through Pushkin Vertigo and HarperVia, and the two novels that followed, Strange Houses and Strange Buildings, kept the mechanic and pushed it further.

Read the three back to back and one argument runs under the puzzles: the spaces people live in record what happens inside them, love does more damage than hatred does, and the truth sits one layer beneath whatever a witness is looking at. Fifteen patterns carry that argument across the trilogy.

Part I: How Uketsu builds the mystery

1. The detective who never leaves his desk

In Strange Buildings, Kurihara solves a nationwide cult conspiracy without visiting a single site. He plots eleven reader-submitted case locations on a map of Japan, finds they trace a perfect circle, and reads the center point as the cult's Hall of Rebirth. A compass and a set of coordinates did the work.

That is how every Uketsu investigation runs. Two people carry each case: one who goes to the scene, and one who never does. In Strange Houses and Strange Buildings, the Author is the field agent, visiting houses and interviewing witnesses. His friend Kurihara, an architectural draughtsman, works from a desk and turns a geometric anomaly on a blueprint into a full hypothesis, a hidden room or a murder scene, without ever leaving his chair.

2. The clues are already on the page

Uketsu puts his evidence directly on the page rather than describing it. Floor plans appear as floor plans. Drawings appear as drawings. The reader holds the same physical evidence the characters hold, at the same moment they hold it.

In Strange Pictures, a reader can perform the layer composition alone: stack the three drawings over their circled axes and watch an innocent sketch resolve into the murder image Yuki hid inside it. In Strange Houses, a reader can overlay the two floor plans and find the dead space before Kurihara names it.

The mystery is solvable before the characters solve it.

3. The truth arrives in fragments, never straight

Strange Pictures opens inside a defunct blog, using a husband's cheerful domestic posts as the primary record for a murder investigation. Strange Buildings pieces its conspiracy together from a 1940 travelogue and a 1994 undercover tabloid article, then confirms it against the published diary of a nine-year-old boy who died of neglect mid-sentence. His entries get shorter as the book goes on, the handwriting deteriorates, then they stop.

Uketsu never narrates events directly. Every fact in these books gets rebuilt from documents, and every document is incomplete, unreliable, or filtered through a narrator with a reason to omit something. Each fragment carries someone's version of events, not the events themselves.

4. The clue is the thing that's missing

In Strange Pictures, a husband buys an eight-slice anniversary cake. He eats two slices and his wife eats one. Four more go into the fridge for breakfast, which brings the count to seven, one short of eight. Kurihara reads that missing slice as evidence of a third person living in the house, hidden from every blog post.

In Strange Houses, the Saitama floor plan has no garage, and the killers needed somewhere to put an intact body. Kurihara works backward from that missing room and finds the underground cellar dug beneath the garden. In Strange Buildings, a walking stick goes missing from a mobility-impaired woman's room the night she dies on the stairs.

Uketsu's key clues are almost always absences. Something that should exist does not, and finding what fills that gap finds the crime.

5. Layer one thing over another and the hidden shape appears

Reality in Uketsu's work hides under a transparency, not behind a wall.

Stack the first-floor blueprint over the second-floor blueprint in Strange Houses and the "dead space" lines up exactly with the windowless child's room above and the windowless bathroom below. What looked like a wasted pocket of air is a vertical murder tunnel.

Stack the three drawings in Strange Pictures, aligning their circled numbers, and a baby in a Santa hat becomes a surgical incision, a praying old woman becomes a doctor pulling a baby out of a body, and a woman lying down becomes a corpse.

In Strange Buildings, a modern two-story house in Nagano sits around, not on top of, an 1938 gothic watermill. The house is the second layer, placed over history nobody wanted to acknowledge.

6. An ending that takes back what it just gave you

Each book earns a resolution, then reverses it.

In Strange Houses, Keita Katabuchi's confession letter reads as tragic and decent: he built the trap-houses to fake ritual murders and protect his imprisoned son from a cult that demanded real kills, then surrendered himself so his family could survive. Then Kurihara points at one detail on the Tokyo floor plan, a small interior window between the living room and the bedroom. Interior windows exist to let someone watch the room, not to let in light. Kurihara asks whether Keita was the protector in his own story, or the prisoner Ayano watched constantly. The letter does not change. What the reader does with it does.

In Strange Pictures, Doctor Hagio reads a child's drawing of a bird inside a thorny tree as evidence of nurturing love strong enough to overcome the patient's aggression. The ending reveals the thorns were there to protect the bird, and Hagio was right about the love. She missed what it was defending against.

Part II: What the houses do

7. One company, two kinds of violence

Uketsu treats architecture the way thriller writers treat guns, as a tool one person designs to hurt another person.

In Strange Buildings, Hikura Homes builds a mansion for a wealthy client with a deliberate gap at the top of the main staircase, no wall and no handrail, sized to be fatal to someone with a mobility impairment. The grandmother who lives there and struggles to walk was killed by the floor plan, not by a person.

The same company also builds mass-market homes with plumbing that guarantees mold and bedrooms with no privacy, laid out as through-corridors. It converts storage closets into bedrooms and calls one a teenager's room. These houses do not kill on a schedule. They grind people down until someone snaps.

One company builds custom murder machines for the wealthy and mass-produces psychological attrition for the poor. The product changes. The contempt does not change.

8. The nicer the exterior, the worse the interior

The more Uketsu hides inside a building, the more the outside performs welcome.

The Katabuchi murder house in Strange Houses has sixteen exterior windows, which Kurihara flags as deliberate. Sixteen windows serve no functional purpose. They are a performance, telling anyone who looks that there is nothing to see. The windowless rooms sit at the center, and the light show stays on the outside.

In Strange Buildings, the retrofitted triangular sunroom on the Saitama house has large windows facing the garden, immediately blocked by the walls framing the room, with no functional access from inside. It was built as a cover story for the underground cellar excavated beneath it. Someone needed a reason to be digging in the garden, and the sunroom is that reason.

9. A space with no explanation is where the truth lives

The ancestral Katabuchi estate in Strange Houses runs a hidden passage system behind a massive, immovable Buddhist altar at the center of the house. The sliding doors that would open onto that passage are jammed shut, so from outside that wing simply reads as closed. Behind the altar sits a confinement room nobody is supposed to know exists.

In Strange Buildings, Yayoi Negishi grew up with a hallway that dead-ended at a blank wall between her bedroom and her parents'. It led nowhere, and her mother built her daughter's whole life around a corridor with no destination.

In Strange Houses, the dead space between the kitchen and the living room of the Tokyo house is a vertical shaft, not a construction error, an interior the floor plan never mentions.

That's the shared premise across all three books: the space with no official explanation is the space where the truth lives.

Part III: What the books are actually about

10. Mothers who destroy the thing they love

Maternal love in Uketsu's work is the most dangerous motivation in the trilogy, never a softening one.

In Strange Pictures, Naomi Konno killed her abusive mother to protect a pet bird, killed her husband to protect her son, killed her son's wife to possess his child, and killed a reporter to protect her life with that child. Every person she killed was a threat to something she claimed as hers.

Doctor Hagio looked at a child's drawing of a bird inside a thorny tree and read it as evidence of nurturing love. She was right about the love. She missed what the thorns were guarding against.

In Strange Buildings, a mother tries to pay a construction company to surgically remove her daughter's bedroom from the house, not out of cruelty but from a cult-driven belief that reshaping the floor plan will protect her child. The love in both cases is real. That does not make it safe.

11. Trauma that moves into the walls

Horror in these books gets inherited, moving down the family line into the buildings instead of staying with the person who first felt it.

The Katabuchi family in Strange Houses had already been building hidden rooms and secret passages for generations before the story starts. The ancestral estate, built decades earlier, already held the jammed sliding doors and the confinement room behind the altar. The modern Tokyo house did not invent any of it. Each generation built a new version of the same structure because no one in the family had found a way to stop.

In Strange Buildings, the Rebirth Congregation targets people carrying inherited guilt, an affair or a child born with a disability, and sells the architectural reformation of their homes as a cure for the sins that produced them. The transaction only works if the guilt stays permanent and transferable. The business model needs the wound to stay open.

12. Children who never get to be children

In Strange Houses, Momoya is raised from infancy in a windowless room behind double doors, with an en-suite toilet so he never has to leave. He is given a chute and a task. He is ten years old.

The first time he uses the secret passage built for him, he does not go to hurt anyone. He goes to the master bedroom to press a damp cloth on a sick baby's forehead.

In Strange Buildings, the nine-year-old boy Naruki keeps a journal. He writes about being locked in a closet and not being fed. He writes that his stomach does not hurt anymore, only feels tight. His entries get shorter, then they stop. The journal was later published as The Lonely Death of Naruki Mitsuhashi.

In Strange Pictures, a five-year-old boy draws his dead mother's gravestone on a Mother's Day card. His kindergarten teacher reports his mother for abuse.

13. Why it is always the left hand

In Strange Houses, the Katabuchi family curse demands the "Offering of the Left Hand." Every child born into the family without a left hand must, between ages ten and thirteen, murder a member of the rival branch and sever the victim's left hand for the altar. A manipulator invented the ritual generations ago, and the family kept obeying it anyway.

In Strange Buildings, the Hall of Rebirth is built in the exact shape of a woman missing her left arm and right leg, an amputated body made into architecture. Cult members remodel their own homes to match the same proportions, bricking over windows and removing rooms until their floor plans mirror the limbless idol.

14. The corporation is the villain, not a person

Uketsu does not confine evil to individual people. In Strange Buildings, the primary antagonist is a corporation.

Hikura Homes builds the Tsuhara house with total disregard for what its cramped, no-privacy design will do to the people living inside it. It builds the mousetrap mansion knowing exactly what the staircase gap will do. It constructs the Hall of Rebirth as physical headquarters for the cult it founded and operates, then sends salespeople to congregation members the morning after their religious sacrament to sell them remodeling packages.

The cult and the construction company are the same organization. The guilt is the product, and the house is what you buy to manage it. Cure the guilt, and the business ends.

15. Violence that solves a forensic problem, not an emotional one

The gore in these books works as forensic logic, rarely as emotion.

In Strange Houses, the Katabuchi family dismembers their victims because an intact adult body cannot fit through the narrow architectural chutes connecting the child's prison to the garage. The house demanded the dismemberment. It was logistics, not sadism.

In Strange Pictures, Naomi Konno beats a man's body more than two hundred times with a rock, and the mutilation is a technical requirement rather than an act of rage. It destroys the physical evidence a pathologist would use to calculate time of death from rigor mortis or body temperature. With that evidence gone, the only method left is stomach contents, which Naomi has already controlled by force-feeding her victim a specific meal at a specific time.

The two hundred blows are a calculation, not a loss of control. The body is a clock she needed to stop.

Naruki's journal entries get shorter for the same reason the dead space in the Tokyo house never appears on paper: nobody recorded either one while there was still time to do something about it. That gap between what a floor plan admits to and what actually happened inside it is where Uketsu has now built three novels, and it is still standing open at the end of the third one.

Leave a comment

Uketsu writes mysteries in which the murder weapon is a floor plan. He means a real architectural drawing, printed on the page. The reader is expected to solve it before the narrator does. Strange Buildings is the second novel built that way. In this one the trick stops being a gimmick and becomes a genre.

Who Uketsu is

Uketsu (雨穴, "rain hole") is a Japanese author and YouTuber whose real identity is known to approximately 30 people. He appears in public in a white papier-mache mask, a black bodysuit, and a voice changer. He lives in Kanagawa Prefecture. He worked at a supermarket when he started to post surreal videos online: asparagus turning into severed fingers, raw meat hung on a washing line, eight human ears spinning on a wheel.

In 2020, he posted a 21-minute mystery built around a series of architectural floor plans. Publishers told him to make it a novel. That novel became Strange Houses (2021).

Strange Pictures followed in 2022. Strange Buildings (変な家２, Hen na ie 2) came out in Japan in 2023. The English translation arrives in 2026. It is a direct sequel to Strange Houses, keeping the same Author-narrator and the same Kurihara. It also keeps the same project of using architectural floor plans as forensic evidence.

Jim Rion translated both Strange Houses and Strange Pictures into English for Pushkin Vertigo and HarperVia. He has lived and worked as a translator in Japan since 2004, and the same publisher pairing is the likely home for Strange Buildings when it reaches English readers.

By 2024, three of Uketsu's novels sat in Japan's top 10 fiction bestsellers at the same time. Strange Pictures alone sold over 1.5 million copies in Japan. Translators took it into 30-plus languages.

Strange Buildings is the most ambitious of the three novels covered in this series. It drops the single central case and the quartet of interlocking stories. It presents eleven separate reader-submitted files about architectural anomalies. Each file looks isolated, and each one connects secretly to every other. The final reveal is larger than anything Uketsu attempted before. A nationwide cult conspiracy sits encoded in the floor plans of ordinary Japanese homes.

Why This Summary and Analysis Exists

No complete, chapter-level English-language breakdown of Strange Buildings exists. The book still lacks wide coverage outside Japan. This is the full summary and analysis. It covers all eleven files, the climactic deductions, and the master map of every planted clue. This page carries complete spoilers throughout.

Prologue

The Author, the same freelance writer who investigated the Katabuchi family in Strange Houses, receives eleven new files from readers. Each file describes a bizarre architectural anomaly. One case is a hallway that goes nowhere, another is a building shaped wrong, and a third is a room with a door that should not exist. At first glance the cases are unrelated, and on examination they reveal one story of interconnected crimes across decades.

File 1: The Hallway to Nowhere

The House Yayoi Grew Up In

Yayoi Negishi is a woman in her thirties. She consults the Author about her childhood home in Toyama Prefecture. A company called Housemaker Misaki built it in 1990. The single-story house had a dead-end hallway between her parents' room and her own. It led to a wall.

Her mother was cold and distant toward Yayoi. She was obsessively protective about one thing. Yayoi could never walk on the main road south of the house. The mother was not anxious in general. She was anxious about that road alone.

After her parents died, Yayoi found two strange objects among their belongings. One was a hidden stash of 680,000 yen in cash. The other was a wooden doll missing its left arm and right leg.

Yayoi has a theory. The hallway was meant for a twin sibling who died in utero. The Author investigates local newspaper archives and disproves this through architectural logic.

He finds something else. A Housemaker Misaki construction truck struck and killed a child in 1990. It happened right in front of the home plot, just before the house went up. The original entrance was planned to face the road where the accident happened. Yayoi's mother paid to have the entrance moved.

The representative from Housemaker Misaki adds one final detail. Five years after the move, Yayoi's mother returned to the company. She tried to hire them to remove Yayoi's bedroom from the house. That job was expensive and structurally significant. The mother could barely afford it. She kept asking anyway.

A Floor Plan as a Confession

The "hallway to nowhere" is the novel's entry point into its governing theme. Houses are physical confessions of psychological guilt. The mother cannot walk past the place where a child died. She cannot live in a house whose front door opens onto that site. She is willing to destroy her daughter's bedroom to correct the floor plan of her guilt.

At this stage of the novel, the amputated wooden doll is a grotesque non sequitur. By the final chapter, it is the key to everything.

Where the Doll Leads

The amputated wooden doll prefigures the "Holy Mother" of the Rebirth Congregation, introduced in File 6. She is a woman missing her left arm and right leg. She is the figurehead of a cult that exploits parental guilt.

Yayoi's premature birth blocked the newborn blood test. As Kurihara later deduces, Yayoi was conceived in an affair. The mother's road prohibition was not about the accident. It came from fear that any hospital visit with a blood transfusion would reveal Yayoi's blood type to her husband.

The mother's attempt to remove Yayoi's bedroom was an act of cult devotion. The Rebirth Congregation instructed members to alter their homes physically, so that each home matched the amputated form of the Holy Mother as a ritual of penance.

File 2: Nurturing Darkness

The Tsuhara House Killings, Reconstructed

Tatsuyuki Iimura is a forensic cleaner. He recounts the "Tsuhara house" in Shizuoka, a 2020 crime scene. A 16-year-old boy allegedly took a kitchen knife and stabbed his mother. He then killed his bedridden grandmother and younger brother.

Iimura provides the floor plan. A corporation called Hikura Homes built the house as a mass-produced "commodity home". Plumbing crammed into the north side caused mold and persistent odors, and nobody had real privacy. The bedrooms worked as through-corridors, so everyone passed through everyone else's space constantly. The 16-year-old lived in a converted, windowless storage room. Iimura argues the suffocating architecture "nurtured the darkness" in the boy.

The Author re-examines the forensic record. The grandmother's eyes were closed at death. The mother had no defensive wounds except the knife entry point. The teenager had multiple slash wounds on his hands and arms.

The Author reconstructs the actual sequence. The mother cared for a bedridden relative in an intolerable home, and the weight shattered her. She attacked the grandmother in her sleep. The teenager fought his mother to stop her, and she cut him repeatedly. He killed her by accident in the struggle. Then panic and shock made him attack his younger brother.

The teenager's "kills" were a consequence of someone else's snap, in a house designed to make everyone inside it worse.

A House Built to Fail Everyone Inside It

This chapter expands the novel's thesis from the individual scale to the systemic. The Tsuhara house is a product, mass-manufactured by a corporation optimizing for cost and profit, not a deviant design. Hikura Homes built it this way, and everyone who lived in it has since died.

The media used a "killer teen" framing, and Iimura adopted it at first. The Author's forensic re-reading rejects it.

Hikura Homes' First Appearance

Hikura Homes enters here as a corporation with a troubling history. Rumors in the 1980s said the president abused "some little girl." The company answered those rumors with aggressive media management and reputation control rather than accountability. That rumor pays off in File 10 as something far worse: Masahiko Hikura, the future chairman, bought a child from a yakuza-operated brothel.

File 3: The Watermill in the Woods

Uki Mizunashi's 1938 Discovery

The Author presents an excerpt from a 1938 travelogue by Uki Mizunashi. She is a steel magnate's daughter, and she visits her uncle's rural property in Nagano. She discovers a watermill in the forest that has no water source. She turns the massive exterior wheel by hand, and an interior wall slides forward. That opens a hidden, doorless confinement room.

Outside the mill stands a small shrine with a statue of Kishimojin, the goddess of children's protection. The statue holds fruit and no baby. The mill's second room holds a square alcove, exactly the size for a person to curl up in.

Uki uses the wheel to open the hidden room. She finds a rotting body, and she describes it as a "female egret" missing the tip of one wing.

She flees. Her written theory calls the mill a gothic execution chamber, built by a cult to crush sinners against the goddess's image as the mechanical wall advanced.

A Machine Needs Someone to Run It

This chapter drops the novel into gothic horror without explanation. The watermill is a machine, and machines require operators. Someone built this. Someone used it. The statue of Kishimojin missing her baby does not represent abstract spiritual emptiness. Something happened to the baby that the goddess was supposed to protect.

The Egret Is Okinu

The "female egret" is the body of Okinu, a maid of the Azuma family. File 5 identifies her. The "missing wingtip" is her severed wrist, consistent with the mechanical wall closing on her arm.

The square alcove inside the mill existed for protection, not execution. Someone hid a baby there. That baby is Yaeko. The mechanical wall closes on her as an infant and takes her left arm. Decades later she becomes the "Holy Mother" of the Rebirth Congregation.

File 4: The Mousetrap House

The Staircase Shiori Witnessed

Shiori Hayasaka is a wealthy CEO who grew up poor, and she recounts a middle school trauma. She went to a sleepover at the palatial Tokyo mansion of her classmate Mitsuko Hikura. Mitsuko is the daughter of the Hikura Homes president. The house had grand dual staircases and a massive locked bookcase in Mitsuko's room. A grandmother occupied a central windowless room. The grandmother was beautiful, but she moved stiffly and hid her body under long skirts and white gloves.

That night, while Shiori was present in the house, she heard the grandmother tumble down the stairs to her death.

Years later, Shiori examines the floor plan and identifies the kill mechanism. The area at the top of the main staircase carried a wide gap with no wall and no handrail. The size made it hazardous to anyone with a mobility impairment.

Shiori theorizes that Mitsuko stole her grandmother's walking stick during the night, locked it in the bookcase, and let Shiori witness the locked bookcase as an alibi. The old woman then descended the staircase unaided.

A House Built to Kill Its Own Owner

The "mousetrap" architecture proves that Hikura Homes designs murder into residential structures. The family weaponizes space for clients, and it weaponizes space for itself. They killed their own grandmother with a floor plan.

At that age Shiori could not weigh what she witnessed. She went to that sleepover as a socially ambitious teenager trying to make friends with a rich classmate. She left as an unwitting accomplice to a family assassination.

What Mitsuko Actually Stole

The grandmother in the long skirts and white gloves is Yaeko, the Holy Mother from File 3 and the founding figurehead of the Rebirth Congregation. She conceals a missing left arm and a prosthetic right leg.

Shiori's misidentification of the "walking stick" as the murder weapon is a red herring. Kurihara later determines that Mitsuko stole Yaeko's prosthetic leg while she slept. The old woman then descended the staircase on one real limb and a stump. The locked bookcase held the prosthetic, not a cane.

Akinaga Hikura ordered his daughter Mitsuko to kill Yaeko. After the Rebirth Congregation dissolved, Yaeko became a reputational liability for the corporation. The builders designed the house to do the job cleanly.

File 5: The House Where It Happened

Kenji Hirauchi bought a pre-owned house in the Nagano woods. He checks a crowdsourced dark history app. Real Japan-specific services do the same job and log crime and death locations at residential addresses. He finds his exact lot marked: "23 August 1938, Woman's corpse found."

The Author and Kenji research local archives. In 1938, the land belonged to the Azuma family. The lord of the manor, Kiyochika, had an affair with a maid named Okinu. His wife discovered the affair and ordered Okinu killed. Okinu fled into the forest.

Back at Kenji's house, the Author notices that the ground floor has no windows. One room has abnormally thick exterior walls. He taps the walls and finds a hollow space. He concludes that someone built this house around the watermill from File 3. The modern residential structure is a shell enclosing an 88-year-old gothic execution chamber.

Okinu fled to the watermill, gave birth, and died there. Decades later, someone enclosed the watermill inside a conventional structure, added a second floor, and sold it as a home. The buyers had no idea what sat inside the walls.

The House That Enclosed Its Own Crime Scene

File 5 is the novel's "architectural uncanny" thesis in its purest form. A modern house sits on modern land. Behind walls too thick for structural need sits a machine. That machine killed a woman nearly a century ago. The house did not demolish its own history. It enveloped it.

The people who built the shell around the watermill knew what was inside it, and so did the people who bought the shell and added the second floor. Kenji had no idea. Each layer of construction is a new generation that stays silent.

Confirming the Egret

The "female egret" of File 3 is Okinu, confirmed. The baby in the alcove was Yaeko, and she survived. File 10 explains the rest. The Hikura family bought this land and built the modern shell around the watermill. It became a pilgrimage site for the cult, a visit to the Holy Mother's birthplace. When the cult collapsed, they simply sold the property to an ordinary civilian.

File 6: The Hall of Rebirth

Inside the Hall of Rebirth

The Author presents an unfinished 1994 tabloid exposé from an undercover reporter named Ikaze. The cult's primary facility in Nagano is the "Hall of Rebirth," a misshapen white building. Inside, Masahiko Hikura, the future Hikura Homes chairman, delivers sermons. He warns wealthy congregants that their children inherited their "sin." A dark spiral path leads through a subterranean shrine to the "Holy Mother," a motionless, beautiful woman missing her left arm and right leg.

A man bursts into the shrine and screams at the Holy Mother. He calls her a fraud and blames her for his son Naruki's death. He threatens to "seal her heart forever." Guards drag him away.

The cult's "sacrament" is an overnight sleep in a large, dimly lit communal room. The next morning, members meet with acolytes, effectively Hikura Homes salespeople, to review architectural floor plans.

The Author analyzes Ikaze's crude building sketches and finds the Hall of Rebirth's architectural secret. The building is more than a worship space. It is an exact architectural replica of the Holy Mother's mutilated body, at building scale. The floor plan is shaped like a woman missing her left arm and right leg.

The Building Is Shaped Like the Goddess It Worships

This is the structural keystone of the entire novel, placed in the center of eleven files on purpose. Everything in Files 1 through 5 radiates outward from this revelation. Files 7 through 11 fill in the consequences.

Hikura's sermon follows the standard cult mechanics. First it instills guilt, so a child's suffering becomes the parent's punishment for sin. Then it provides a proprietary cure: reshape the home to match the Holy Mother's body, with Hikura Homes contractors, at significant expense. The architecture is the product. The guilt is the marketing.

The "sacrament room," positioned in the building's central belly, performs spatial indoctrination. The cult sells a sleep in the architecture's "womb" as spiritual rebirth. It is a Hikura Homes product placement delivered as a religious experience.

Where Every Earlier File Lands

The Holy Mother's missing left arm and right leg connect to Yayoi's amputated wooden doll from File 1, to the mechanical wall injury from File 3, and to the grandmother under long skirts in File 4. File 10 then names her as Yaeko.

Kurihara identifies the angry man who threatens to "seal her heart forever." He is Mr. Kasahara, the father from Files 7 and 8. His son Naruki is the child whose journal fills File 7. He fulfils the threat literally, later committing suicide in the sealed shrine room of his own remodeled home.

The morning architectural consultations explain File 1. The cult instructed members to amputate architectural space to match the Holy Mother's missing limbs, seeking absolution for the sin that produced their child. That is why Yayoi's mother wanted Housemaker Misaki to remove an entire room from her house.

File 7: Uncle's House

Naruki's Journal

File 7 is the published journal of Naruki Mitsuhashi. He was nine, and he died of severe neglect and abuse in 1994. His entries describe his mother pinching his nose shut when he asks for food. They also describe visits to a wealthy man he calls "Uncle," who feeds him and gives him a bedroom. Naruki notices that "Uncle's" house changes between visits. A room with a river view disappears.

Uncle warns Naruki about a specific room: "This is the heart of my house. Never lock this door."

Uncle tries to take custody of Naruki, to give him a permanent home. Naruki's mother and her boyfriend Eiji arrive and remove him. Eiji locks Naruki in a closet. The journal entries get shorter and the handwriting deteriorates, until the entries stop.

A Child's Architecture of Survival

The shift to a nine-year-old's perspective is the most emotionally brutal turn in the entire novel. Naruki's prose is concrete and simple. "My tummy doesn't hurt anymore but it feels all tight now." The child does not understand that this sensation is starvation. The reader does.

The architecture in File 7 is a stark binary. Uncle's house is all windows and space and food and a river view. Eiji's flat reduces Naruki's spatial existence to a closet. The novel spent six files building a theory of architecture as psychology. Here that theory becomes unbearable. The spaces children inhabit determine whether they survive.

Who Uncle Is

"Uncle" is Mr. Kasahara, the father from File 8. Naruki is the illegitimate child Kasahara fathered with a mistress. The vanishing room in Uncle's house mirrors the architectural alterations in Files 1 and 11. Kasahara removed interior space to reshape his home into the Holy Mother's amputated form. His warning about the "heart room" reflects a cult belief: a locked shrine room "seals the heart" and kills everything inside.

File 8: The String Phone

What Chie Heard Through the String

Chie Kasahara describes her childhood in a suburban development of identical houses. Her father, a wealthy but philandering car salesman, largely ignored his family. He made one act of paternal warmth. He strung a paper-cup string phone between his room and Chie's for nighttime conversations.

One night, on the string phone, her father's voice went incoherent. A strange rustling followed. Minutes later, the house next door burst into flames. It belonged to the Matsue family. Searchers found Mrs. Matsue dead in her closet. The ruling was suicide.

Her father became withdrawn, divorced, left his family a fortune, and disappeared. Years later, Chie tests the string phone. The string is far too long for two adjacent rooms. Pulled taut, it reaches the tatami room of the Matsue house.

Chie concludes that her father used the string phone to fake an alibi. He climbed through a window, murdered Mrs. Matsue, and set the fire.

An Object of Tenderness Turned Into an Alibi

The string phone is a precisely selected symbol. It is the most innocent childhood object and an artifact of parental tenderness. The book turns it into a tool of deception. Kasahara used his daughter's fear of the dark and her need for comfort to build an alibi. The alibi may not cover what Chie believes it covers.

The identical clone houses carry the same logic as the mass-produced Tsuhara house. The exteriors are uniform and the interiors are fractured. Everyone in these identical houses lives through something nobody else can see.

Kurihara Corrects the Alibi

Kurihara resolves Chie's theory. She had the facts right and the conclusion wrong. Her father was in Mrs. Matsue's house because they were having an affair, not to murder her from the room next door. The rustling incoherence Chie heard through the string phone was Kasahara finding his mistress's suicide note and her dead body, and panicking.

Kasahara then withdrew from his family. He died in a sealed room, with a strange doll and a photo of Naruki. That is the direct aftermath of File 7. The death of his illegitimate son devastated him, and he could not stop the people who did it. He sealed the shrine room, the "heart" of his own house, against the cult's fiction, then killed himself.

File 9: Footsteps to Murder

Hiroki's Account of the Same Night

Hiroki Matsue, the boy who survived the fire in File 8, provides his own account and rejects the suicide ruling. His father was a devoutly Christian pacifist, and he behaved strangely that night. He went to his wife's room at an unusual hour and stayed for 30 minutes. He then rushed downstairs and handed Hiroki his crucifix and a coin. He told Hiroki to call the fire brigade, because "for some reason, she wasn't in her room." He then ran back into the burning house.

Hiroki has a theory. His father drugged his mother and carried her to the closet. He set the fire and staged the discovery to explain his failure to save her, so Hiroki would assume she suffocated where she slept.

In a final revelation, Hiroki notes that he and Chie Kasahara stay in contact. Both suspect their own fathers. He also knows that the Author hid part of his journalistic purpose in contacting them.

Two Children, Two Different Murders That Never Happened

The competing narratives of Files 8 and 9 are Uketsu's Rashomon. Chie names her father as a killer because a string phone's slack length outran her trust in him. Hiroki names his father as a killer because a 30-minute absence and a locked closet outran his grief. Neither father committed the murder his own child assigned him. The crucifix handed to Hiroki is the novel's most pointed religious symbol: his father's faith weighed so heavily that it drove him toward the very act he was trying to prevent anyone from suspecting.

What Mr. Matsue Actually Did

Kurihara reconstructs it. Mrs. Matsue was pregnant with Kasahara's child. She committed suicide and left a note. Mr. Matsue found the note during his 30-minute visit, discovered his wife's body, and realized that another man fathered the child.

His Christian devoutness could not tolerate his son growing up with that knowledge on the family name. He burned the house to destroy the forensic evidence of the pregnancy, using the closet as an impromptu crematorium. He died the way a man dies who runs back into a fire to save his wife.

File 10: No Escape

Akemi's Story, Then Mitsuru's Correction

Akemi Nishiharu is an elderly izakaya owner. Bankruptcy hit her in her twenties. Yakuza debt collectors then forced her into an "okito," a concealed brothel disguised as an ordinary residential building. The architectural design of the okito prevented escape. A mother could leave only if she gave the operators another resident's child as collateral.

Akemi's neighbor in the okito was Yaeko, a woman missing her left arm, with a daughter of about 11 years. One day, Yaeko took Akemi's son Mitsuru out to run errands. Mitsuru ran into traffic. Yaeko pushed him aside and lost her right leg under the wheels.

Shortly after, Masahiko Hikura, the future Hikura Homes chairman, paid off Yaeko's debt and took her and her daughter away.

In a follow-up interview, Mitsuru corrects his mother's version. The okito catered to pedophiles, and he was the one they prostituted. His run into traffic was a suicide attempt. Hikura bought Yaeko's 11-year-old daughter, not Yaeko herself.

A Building Engineered Around a Single Threat

The unreliable narrator reveals itself slowly here. Akemi's sanitized memory is the protective narrative a mother builds to survive what happened to her child, not deception. Mitsuru's correction does not condemn his mother. He explains her.

The okito's architectural design is the novel's most concentrated statement on systemic oppression. The building is engineered for captivity with the one lever available: children as collateral. The architecture does not hold people with walls. It holds them with a threat against someone else's child.

The Holy Mother's Origin

This file provides the complete origin story for the Holy Mother. Yaeko enters the narrative with one missing arm, from the mechanical wall injury in File 3. She loses a second limb to save a child. Masahiko Hikura then buys her, installs her as the figurehead of the Rebirth Congregation, and presents her real mutilation as sacred stigmata.

File 2 introduces the "dark rumors" about Hikura's abuse of a young girl as a whisper. This file confirms something far more specific and criminal.

File 11: The Vanishing Room

The Door Ren Iruma Found at Six

Freelance designer Ren Iruma reports a childhood memory. At age six, during a dizzy spell, a door appeared in his hallway. Behind it lay a freezing one-square-meter room with a terrifying object in a wooden box. The next day the door was gone. He never found it again.

The Author visits Iruma's childhood home with him. The dead-end hallway is still there. He deduces that the 2004 Chuetsu Earthquake vibrated a mechanism in the wall open. That mechanism is a metal plate that acts as a magnetic latch. With a strong neodymium magnet, the Author slides the hidden door open.

Inside stands a wooden effigy of a beautiful woman missing her left arm and right leg.

A House Built as a Shrine

Iruma realizes the doll's proportional shape matches the architectural layout of his childhood home exactly. His father was a product designer who worked with rare earth elements, and he used his knowledge of neodymium magnets to build a magnetic concealment mechanism into his own wall. The dead-end hallway is a penitential architectural prayer.

File 11 brings the unheimlich, the uncanny, full circle. The domestic space Iruma grew up in was a cult devotional object shaped to look like an ordinary home. His father built it around the amputated form of the Holy Mother, with a hidden room at its "heart" holding her effigy. Iruma crawled around that effigy as a six-year-old with a dizzy spell, then lived beside it for decades while it stayed invisible in the wall.

The neodymium magnet is the satisfying technical payoff for a detail planted many files earlier, when Iruma mentions offhand that his father worked in product design with rare earth materials.

Kurihara's Deductions

Kurihara Maps Every Address

The Author presents all eleven files to Kurihara. Kurihara maps the geographic location of every house and building. All of them orbit the Hall of Rebirth in Nagano at various distances. The architecture is a web, and the Hall of Rebirth is the anchor point.

Kurihara reconstructs the complete history.

Masahiko Hikura founded the Rebirth Congregation and installed Yaeko as the "Holy Mother." His own family bought her from a brothel as a child. The congregation exploited parents who carried guilt over illegitimate children, affairs, or children born with disabilities.

Hikura Homes sold them an architectural solution: remodel the home to resemble Yaeko's mutilated body, so the child receives spiritual purification by sleeping in the building's "womb." The sacrament room was the uterus. The overnight stay was rebirth.

Kurihara traces Yaeko back to the watermill. Okinu gave birth to her inside the mechanical wall chamber. The wall reactivated as her dying mother tried to hide her, and it severed the baby's arm. Hikura Homes later bought the Nagano land and built a house around the watermill to create a pilgrimage site. When the cult dissolved, they sold the property as a residential house.

The Author tracks down Mitsuko Hikura from File 4. She confesses. On the night of her grandmother Yaeko's "accident," she hid Yaeko's prosthetic leg while Yaeko slept. She acted in self-defense, not on her parents' instructions.

Her parents were abusive and dangerous, and the one person in the house who protected Mitsuko was Yaeko. By killing the only person who cared for her, Mitsuko secured her own survival. She carries that calculus to this day.

Mitsuko's Confession Closes the Loop

Mitsuko's confession completes the novel's moral geometry. She was not following orders. She was a child who protected herself from abusive parents, eliminating the one person in the house who loved Yaeko enough to be a problem.

Masahiko Hikura started the cycle of abuse when he bought a child from a brothel and installed her as a goddess. That cycle ends with his own granddaughter, who kills the only person who ever protected her.

Two Endings to the Kasahara and Matsue Story

Mr. Kasahara from File 8 is confirmed as "Uncle" from File 7. His suicide happened in the sealed room, with the strange doll and the photo of Naruki. Two events met there: the cult's collapse and his son's death. The cult was a fraud, and he could not save Naruki. He sealed the "heart" of his own shrine-house as a final act, a symbolic killing of the fiction that failed everyone.

Files 8 and 9 resolve the Matsue fire the same way, from two directions. Mrs. Matsue learned that her pregnancy with Kasahara's child would destroy her family, and she committed suicide. Mr. Matsue burned the house to destroy the forensic evidence of the affair. He hid no murder. He was protecting his son from the knowledge attached to both his parents' deaths.

The Clue Payoffs, and What File 6 Changes on a Second Read

A handful of details planted early in the book only make sense once File 6 names the Holy Mother's mutilated body as the cult's central icon.

• The amputated wooden doll in the Negishi family's belongings (File 1) is the physical representation of Yaeko's mutilated body, and it marks Yayoi's mother as a cult member.

• The mother's ban on the main road (File 1) traces back to a fear that a hospital blood transfusion would expose Yayoi's real paternity, not to the truck accident itself.

• The Hikura Homes abuse rumor (File 2) is Masahiko Hikura buying an 11-year-old girl from a yakuza-run brothel, confirmed in File 10.

• The windowless rooms, dead-end hallways, and blocked windows across Files 1, 5, and 11 all trace to the same source: the Rebirth Congregation's instruction to alter a home's architecture to match the Holy Mother's missing limbs.

Read in order, File 6 sits at the center of the book on purpose. Files 1 through 5 hand the reader an amputated doll, a mechanical wall injury, and a grandmother in long gloves with no explanation for any of them. A reader who finishes File 6 and goes back to reread those five files sees the same objects differently: no longer strange details a case happened to include, but a body shape the book was teaching the reader to recognize before it had a name.

Files 7, 8, and 9 read like three separate cases, but they cover the same neighborhood and the same night: a dying child's journal, then the daughter next door, then the son who lived through the fire. Geographic proximity turns three individually plausible theories, an alibi, a suicide, an affair, into three fragments of one event nobody involved could see whole.

Strange Buildings starts as a set of quirky, isolated puzzles about odd houses. By the time Kurihara finishes, every puzzle is a node in one corporation's business model. Houses are neutral. They mean what the people who design them intend. Hikura Homes decided to industrialize guilt and sell architectural penance as a product, and everyone who lived inside a house it touched paid for that decision in shame, fear, or money for the rest of their life.

Strange Buildings is the most structural of Uketsu's three novels in the "Strange" series. It asks the reader to hold eleven separate cases in memory at once and trust that they connect. They do, and tracing that connection is the point: a company that sells floor plans can sell guilt through the same floor plans, and the people living inside them may never know which one they bought.

Leave a comment

Who Is Uketsu?

Uketsu (雨穴, "rain hole") is a Japanese author and YouTuber. About 30 people know his real identity. In public he wears a white papier-mache mask and a black bodysuit. His voice never appears unfiltered, a voice changer handles that.

He lives in Kanagawa Prefecture and spent part of his childhood in Surrey, England. He worked at a supermarket when he started to post on YouTube.

His early videos were surreal. Asparagus turned into severed fingers, strips of raw meat hung on a washing line, and human ears spun on screen. In 2020, he posted a 21-minute mystery story built around a series of architectural floor plans. Readers and publishers told him to expand it into a novel. The result was Strange Houses (変な家, Hen na ie), published in Japan in 2021.

Strange Houses was the first novel. Uketsu followed it with Strange Pictures in 2022, then Strange Buildings in 2023, which is a direct sequel to this book. By 2024, three novels by Uketsu sat in Japan's top 10 fiction bestsellers at the same time. Pushkin Press published the English translation of Strange Houses in 2025. The breakout success of Strange Pictures had already primed the anglophone market for it.

The formal concept behind Strange Houses made Uketsu's YouTube channel successful. That concept treats architecture as a text. Read a house floor plan properly and it tells you things about its designers. They would never say those things aloud.

Why This Summary and Analysis Exists

No thorough English-language, chapter-level breakdown of Strange Houses exists. The book's premise sounds like a puzzle box, and it is one. The puzzle also runs deeper than most reviews suggest, in architecture and in psychology. This is the complete summary and analysis, from Chapter One through the Afterword.

This piece contains complete spoilers for the entire novel.

Chapter One: A Strange House

Plot Summary

The Author is a freelance writer who specializes in the macabre. His acquaintance Yanaoka approaches him. Yanaoka wants to buy a newly built two-story home in Tokyo for his growing family. Yanaoka has a problem.

On the first floor, between the kitchen and the living room, sits a section of the house that nothing opens into. That is a dead space, sealed on every side. Somebody built it in, walled it off and sealed it.

The Author lacks architectural training. So he brings the floor plans to Kurihara, an architectural draughtsman and fellow mystery enthusiast. Kurihara is methodical. He notes that somebody created the dead space on purpose. Two additional walls block it off, and they cost the kitchen part of its floor area. Why would a builder shrink a kitchen to seal off an empty section of the house?

Kurihara then directs the Author to the second floor. The child's bedroom is in the corner farthest from the staircase. It has no windows at all. An en-suite toilet means the child never needs to leave.

One route reaches the room, and that is a double-door vestibule. A pair of sequential doors makes an airlock-style buffer between the child's room and the rest of the house. Kurihara calls this design a solitary confinement cell. The architectural language communicates obsessive control over a child's movement and presence.

The contradiction: the parents' bedroom is bright and open. Their dressing room is completely exposed to the bed, with no privacy partition. And the house has 16 exterior windows, an unusual number for a residential build.

Kurihara reads the 16 windows as intentional. The house is performing normalcy to anyone looking at it from outside. All those windows say: nothing to hide here. Meanwhile, the interior hides its most important spaces completely.

The Author overlays the two floor plans and makes the key discovery. The walled-off dead space on the first floor aligns precisely with two corners, one from the child's windowless room and one from the windowless bathroom below it. Kurihara traces where it leads: straight up, a vertical tunnel connecting the two.

Kurihara constructs a scenario. The parents bring someone home, get them drunk, suggest a bath. The imprisoned child drops through a trapdoor in the bedroom. The dead space works as a vertical access shaft. The child enters the bathroom from below and kills the naked and defenseless guest.

Dismemberment occurs. Body parts pass back through the tunnel to a storage room near the garage. A vehicle takes them away.

Yanaoka pulls out of the purchase.

Shortly after, a dismembered body is found in the wooded hills near the property. All parts present except the left hand.

Architecture Testifies Before Anyone Does

A floor plan with a section walled off and left blank is the whole premise of this novel, compressed into one drawing. Uketsu makes architecture the antagonist and the floor plans the evidence, and the trick works because Kurihara cannot actually be certain. He is constructing a narrative from empty geometric shapes. He may be wrong. The dismembered body at the chapter's end does not confirm his specific murder scenario. It only confirms that something terrible happened near that house, and everything else is inference laid on top of a blueprint.

The chapter sets the template Uketsu repeats for the rest of the book: the Author presents a floor plan, Kurihara decodes it, and the two of them arrive at a horrifying conclusion together, one they cannot fully prove. The 16 windows are what lift the chapter from puzzle to statement. A house that decorates its exterior with abundance while hiding its interior in darkness has thought carefully about the optics of concealment, which means someone inside it already knew what the house needed to hide.

That decision to perform normalcy becomes the Katabuchi family's survival strategy for the rest of the book, foreshadowed here and confirmed later. So does the missing left hand. The Author's first instinct is that the body was dismembered simply to fit through the tunnel's narrow passageways. That is a reasonable guess and a red herring. Chapter Four names the real reason: a ritual called the Offering of the Left Hand, which becomes the structural center of the novel's second half. The sealed dead space also foreshadows the jammed fusuma doors in Chapter Three and the broader pattern behind them, hidden passages as standard operating procedure across generations of one family.

Chapter Two: Another Warped Floor Plan

Plot Summary

Unable to let the case go, the Author publishes a vague article about the floor plans. He receives a letter from Yuzuki Miyae, an office worker from Saitama. Her husband, Kyoichi Miyae, vanished three years ago (in 2016). His body was recently found on a mountainside. The body was intact. His left hand was severed.

Yuzuki believes the murder connects to the Tokyo house. She found the floor plan of a home in Saitama where she believes the Tokyo family previously lived. The Saitama house was built in 2016 and recently burned to the ground.

The Author takes the Saitama floor plan to Kurihara. The similarities are clear. A windowless child's room sits on the second floor. A windowless bathroom sits on the first floor. A dead space connects them. But there are significant differences.

The Saitama house has no garage. This explains why Kyoichi's body was found intact rather than dismembered. The Saitama house had no good vehicle route for dismemberment and disposal.

The parents slept in separate single beds.

The child's room had only one door, not the double vestibule of the Tokyo house.

On the first floor sits a bizarre retrofitted triangular room. It has large windows, walls block those windows, and the room is completely useless. It occupies space that previously opened onto the garden.

Kurihara identifies the triangular room's function. Somebody built it over a section of the garden after the original building was complete. Below it, in what used to be open ground, is an excavated cellar used to store intact bodies. No garage needed. The cellar is the cold storage.

Then the Author visits the empty Tokyo house and speaks to a neighbor. The family's name was Katabuchi. They had a beloved one-year-old baby named Hiroto. They fled suddenly after the neighbor's husband spotted something at a window. He saw a pale, strange boy of about ten years old. The boy sat in the parents' bedroom window late at night.

Kurihara synthesizes the data. There are two children. The first is Child X, the imprisoned assassin in the windowless cell. The second is Hiroto, the infant the parents clearly adore. The timeline tells the story of the house's evolution. Somebody built the Saitama house for the parents and Child X.

When Hiroto was born, they added the triangular nursery room. That kept the baby separate from the murder mechanics. Later they designed the Tokyo house to manage both children at once. The heavy double vestibule stops X and Hiroto from ever sharing the same space. The double bed in Tokyo is for the mother and Hiroto. She becomes a human barrier between the infant and the door to X's room.

The Author presents these conclusions to Yuzuki. She breaks down when she hears the family fled. The Author confronts her. Kurihara has established that the real Kyoichi Miyae was a bachelor. The woman calling herself Yuzuki Miyae is not who she says she is.

She confesses. She is Yuzuki Katabuchi. The woman in the murder house, the mother of Hiroto and warden of X, is her estranged older sister, Ayano.

Two Houses Record One Escalating Crisis

The Saitama house and the Tokyo house record the same crisis at two different moments, three years apart. Each floor plan reflects the exact state of the parents' psychology at the time it was built, which is why the differences matter as much as the similarities. No garage, single beds, one door on the child's room: read those against the Tokyo house's garage, double bed, and double vestibule, and the escalation is a family adapting its architecture to an expanding moral problem, not repeating one.

Yuzuki's false identity runs the same trick as the houses. She presents a false floor plan of her own life to reach the investigation, and the Katabuchi family builds false floor plans to hide their crimes. Even the humans in this novel perform spatial deception, not just the buildings.

Hiroto's arrival does more damage to the reader's assumptions than anything Kurihara has decoded so far. The parents are not simply sociopathic architects running a murder factory. They also raise a baby with apparent tenderness, building him a sunny nursery and sleeping close enough to keep him safe. Both things are true inside the same square footage, and the book has no interest in resolving which one is the real family.

The Vestibule's Meaning Changes on a Second Read

The double vestibule's meaning shifts decisively here. In Chapter One, it read as a mechanism to keep the imprisoned child inside. In Chapter Two, it becomes a quarantine to keep that child away from the innocent infant. The architecture has not changed. The interpretation has, and that is the novel's own structural project running one level up: the same floor plan means something different on the second pass.

Chapter Four explains the pale boy seen through the window. He is Momoya, the imprisoned child, and he uses the hidden passage to reach the mother's room, where he places a damp cloth on the feverish baby's forehead. His goal was never to kill. This is the first sign, three chapters early, that Momoya is a boy and not the killer the setup trained readers to expect.

Chapter Three: Drawn from Memory

Plot Summary

With her deception exposed, Yuzuki Katabuchi shares a piece of her family's history that she has never told anyone. In 2006, her extended family gathered at the ancestral Katabuchi estate in the mountains. The estate is large and highly symmetrical. A long central corridor divides it evenly. A massive, immovable black Buddhist altar stands at the exact midpoint.

During that stay, Yuzuki's seven-year-old cousin Yoichi was found dead in front of the altar. His head was covered in clotted blood. The family ruled it an accident, because he must have climbed the altar and fallen. They also suppressed his mother Misaki's attempts to call the police.

Kurihara analyzes Yuzuki's hand-drawn floor plan of the estate. He identifies several anomalies. All the rooms on the right side of the house lack windows entirely. A set of fusuma (Japanese sliding doors) is permanently jammed shut. Kurihara traces the structure's hidden layout.

A confinement room sits behind the altar. One route reaches it, and that is the secondary passage masked by the jammed fusuma.

His reconstruction: a family member took Yoichi in the night and pulled him through the passage into the hidden confinement room, which had no windows and muffled sound completely. He killed him there, then placed the body at the altar to stage the accident.

No police investigated the death. The family closed the matter cleanly.

Yuzuki acknowledges this. Her own father was likely responsible. He worked to manipulate the family's line of inheritance. The plan surrendered her sister Ayano to the main Katabuchi family. They indoctrinated Ayano and tasked her with serving as a warden for disabled children.

Her father eventually lost his mind and died by suicide.

The Estate the Family Couldn't Stop Building

Chapter Three shifts the novel from modern procedural mystery into Gothic horror, and the transition is earned, because it answers a question the first two chapters never asked: where did any of this come from? The ancestral estate is the architectural origin myth. The jammed fusuma, the hidden room, and the windowless wing aren't recent innovations, they're centuries of accumulated spatial habit passed down like a family trait.

The altar at the center of the house does real symbolic work rather than merely looking ominous. It sits at the geometric center of the corridor, so every walk from one end of the house to the other passes around it. The family cannot cross its own home without acknowledging what stands at its middle. Ancestral weight becomes something you physically have to route around.

Yuzuki's father is the chapter's most tragic figure precisely because he is ordinary. He committed a monstrous act while believing he protected his family, and the delusion did not survive contact with what he had actually done. He reads as an early, less patient version of Keita, the man Chapter Four spends far longer trying to understand.

The estate is the direct architectural prototype for every house in the novel. The jammed fusuma is the same hidden-passage system the modern Tokyo and Saitama houses reuse. The windowless rooms on the right side of the estate become the template every later Katabuchi dwelling copies for its child's prison, and the confinement room behind the altar is the prototype for the whole murder-tunnel concept. The family did not invent any of this. They inherited it, and nobody in three generations found a way to stop building it.

Chapter Four: House of Chains

Plot Summary

The Author and Yuzuki visit her estranged mother, Yoshie. Yoshie produces a letter. Ayano's husband, Keita, wrote all of it as a complete confession to the history of the Katabuchi family's madness.

The origin: decades ago, the Katabuchi patriarch Soichiro entered into an incestuous relationship with his own sister, Chizuru. Soichiro's neglected wife, Ushio, discovered the affair and, in a state of dissociation, severed her own left hand. Shortly after, Chizuru gave birth to a son, Momota, who was born missing his left hand.

The curse attribution: a manipulator named Rankyo convinced Soichiro that Momota's deformity was Ushio's supernatural punishment. Rankyo was actually a woman named Shizuko from a rival branch of the family, and she orchestrated generational revenge. Rankyo established what became the Offering of the Left Hand. Any Katabuchi child born with a missing left hand must be imprisoned from childhood. Between the ages of 10 and 13 that child must murder a descendant of the rival branch, then present the victim's severed left hand at the family altar.

Enter Keita and Ayano, the present-day wardens assigned to a disabled child named Momoya. They refused to become killers. They built the Saitama and Tokyo houses as theatrical sets that simulated compliance with the ritual and faked it entirely. Keita scavenged the intact bodies of suicide victims.

One was Kyoichi Miyae, a bachelor who jumped from a bridge. Keita presented their severed left hands to the family enforcer, Kiyotsugu, as the required Offerings.

The deception holds until Kyoichi's body surfaces and the police investigate. Kiyotsugu confronts Keita: he knows the rituals were faked. He threatens to take Momoya back to the main family compound and force the boy to perform an actual murder.

During this confrontation, Momoya escapes his room through the hidden passage. He does not go to the bathroom. He goes to the mother's room, where the feverish baby Hiroto lies sick in bed. Momoya places a damp cloth on the infant's forehead and stays with him until the fever breaks. The neighbor who glimpsed the pale boy at the master bedroom window saw Momoya nursing a sick baby.

Keita kills Kiyotsugu. Then he kills the family patriarch, Shigeharu. He takes full responsibility and disappears, leaving his wife and children with the story that absolves them.

Keita Builds the Same Prisons to Save Instead of Kill

Keita and Ayano spend three chapters looking like the monstrous wardens of a murder house. Chapter Four spends its entire length insisting they, and the child they guarded, were prisoners of the same architecture. The structures were designed to imprison and kill. Keita repurposed them into a theatrical prop, a stage set for a performance of compliance that kept his family alive.

He is the inverse of every Katabuchi ancestor before him. They built prisons to enforce the ritual. He built identical prisons to fake it. The structural language is the same. The moral content is opposite, and that is the whole argument of the chapter compressed into one man's floor plan.

Momoya nursing the sick baby does more damage to the reader's assumptions than any single reveal so far. The narrative spent three chapters training readers to see him as a dangerous unknown, a pale figure glimpsed through windows, the engine of a murder factory. He is 10 years old and he has never killed anyone. The first time he escapes his room, he tends to a sick infant.

The catharsis here is deliberately incomplete. Keita's disappearance resolves nothing except the immediate threat. The houses are destroyed and the enforcers are dead, but the family structure that produced the ritual continues, and so does the incestuous origin story underneath it.

Every Missing Hand Is Accounted For, Except One

Both severed left hands from the mystery's early chapters now have an explanation. Kyoichi's came from a scavenged suicide victim, presented as an Offering. What Keita's letter never explains is the unidentified body from Chapter One, the one whose missing left hand started this whole investigation. His confession resolves the Kyoichi case and deliberately leaves that first one open.

By Chapter Four, the double vestibule's function is settled: quarantine in two directions. It protected Hiroto from what sat behind that door, and it protected Momoya from the full weight of how differently the two children were being raised.

Afterword: Kurihara

Plot Summary

Kurihara meets the Author one final time. He says the investigation is finished, except for one thing.

He points to a detail in the Tokyo house floor plan that nobody examined: a small interior window between the living room and the first-floor bedroom.

The Window Nobody Checked, Including Me

Interior windows destroy privacy. They exist for one purpose, observation. Keita's letter describes a man who built the houses to protect his family. Kurihara asks whether Keita was a prisoner himself, watched constantly by Ayano through that same window.

I had the floor plan of the Tokyo house from page one of this book, and I missed that window too. That is the real trick of the Afterword: after two hundred pages spent earning a comfortable ending, Kurihara hands the reader evidence they already had and asks why they stopped reading it. I do not think the sacrifice-and-redemption reading of Chapter Four collapses under this. It just has to share the page with an uglier one now, and Uketsu never picks a side between them. That refusal is the strongest writing in the book, stronger than any single reveal in the four chapters before it.

Kurihara also notes the other unresolved thread: the dismembered body from Chapter One remains completely unidentified. Keita's confession accounts for Kyoichi Miyae's intact body. It says nothing about the person who was dismembered, whose left hand is somewhere nobody has looked.

The interior window loops the novel back to its own opening instruction, look at the floor plan again, something is wrong, you missed it. The reader had the Tokyo house's floor plan from Chapter One. The window was there the whole time.

The novel does not close.

How the Ending Reframes the Beginning

Strange Houses begins as a cool, clinical puzzle about malevolent architecture. By the end, it is a study in how generational trauma becomes structural. The incest and suicide of the founding generation produced a deformed child. The deformed child produced a ritual. The ritual produced a building type. The building type became tradition, and the tradition imprisoned every generation that followed, because nobody in the family ever found a way to say stop.

Keita's theatrical set is the first act of genuine refusal in the entire lineage. He built the same kind of structures his ancestors built, and he built them to protect a child instead of destroying one. The structures looked identical. The moral content underneath them was entirely different, and that distinction costs him everything.

Five Chapters, Each Zooming Out Further

The introduction stays inside one house and one unsolved detail, the floor plan with a section that shouldn't exist.

A second house forces a second timeline, and the two floor plans start to argue with each other. The chapter introduces the human beings behind the architecture for the first time.

The estate that started it all holds one murdered child and one room built to hide the killing. The novel zooms back decades to the source of the family's obsession.

Chapter Four zooms out all the way. It lays out the complete family tree and the complete history of the ritual, and it explains every house in the novel. The houses were not designed by killers. They were designed by trapped people, in houses that had already designed them.

The Afterword zooms in on one small window and one question it raises. The floor plan of the entire novel gets pulled back one more time, to reveal a dead space the reader walked past five times.

The English translation of Strange Houses (Pushkin Press, 2025) embeds the original floor plan diagrams in the text as intended, and that matters. This is a novel you read with a pen, because the floor plans work as evidence rather than illustration.

Leave a comment

Who Is Uketsu?

Almost nothing is known about the person behind the name. Uketsu (雨穴, which translates to "rain hole") is a Japanese author and YouTuber. He appears in public in a white papier-mache mask and a black bodysuit. A voice changer modulates his voice to sound between mechanical and childlike. About 30 people know his true identity: his family, his publisher, and a small group of collaborators.

He is a man. He lives in Kanagawa Prefecture, southwest of Tokyo. He spent part of his childhood in Surrey, England. He worked at a supermarket when he began to post online. That is more or less the complete profile.

His early YouTube videos were surreal. Asparagus turned into severed fingers under the knife, strips of raw meat hung on a washing line, and eight human ears spun on a wheel. Then in 2020 he posted a 21-minute mystery story built around a series of architectural floor plans. The response was overwhelming. His publisher told him to turn it into a novel.

The rest followed quickly. By 2024, three books by Uketsu held slots in Japan's top 10 fiction bestsellers at the same time. Strange Pictures (変な絵, Hen na e) came out in Japan in 2022. Jim Rion translated it into English in January 2025. It sold over 1.5 million copies in Japan alone, and it now exists in more than 30 languages.

It was shortlisted for Waterstones' 2025 Book of the Year and topped Germany's May 2025 Krimibestenliste. A manga adaptation by Aiba Kiko launched in 2024.

Why This Summary and Analysis Exists

Nobody has put up a truly detailed, chapter-level breakdown of Strange Pictures in English. Reviews exist and plot summaries exist. Nothing maps the structural puzzle, traces the planted clues back to their payoffs, and explains why this book works. That is what this piece is.

It is the complete summary and analysis, chapter by chapter. A full master map of narrative threads sits at the end. If you have already read the book, this is the deepest dive available. If you have not, this will tell you exactly how it was built and why it is worth your time.

Fair warning: this is the kind of analysis that only works with full spoilers. Everything is revealed.

Prologue: The Drawing Test

Plot Summary

The novel opens in a university lecture hall. Dr. Tomiko Hagio is a former practicing psychologist. She presents her students with a drawing by an eleven-year-old patient she calls "Little A." The child was institutionalized after murdering her abusive mother. The drawing came from a standard HTP (House-Tree-Person) test, one of the oldest tools in psychological evaluation.

Dr. Hagio walks her students through three anomalies in the drawing. First, the figure's mouth is heavily smudged. Hagio reads this as physical trauma memory. The child's hands trembled as she recalled a forced, constant smile that appeased her abuser.

Second, the house lacks a door. Hagio interprets this as a fortress mentality, a desire to lock the world out. Third, the tree's branches end in sharp, thorny points. Drawings by violent offenders show that trait often, and it indicates deep aggression.

Then comes the pivot. Little A drew a small bird resting safely inside a hollow in the tree's trunk. Hagio seizes on this as a profound "desire to protect," a capacity for nurturing love underneath the violence. She closes the lecture by telling her students that Little A is now living happily as a mother.

Literary Analysis

Uketsu builds the prologue on ekphrasis: a drawing carries the narrative's evidence instead of dialogue or testimony. Dr. Hagio sets the rule for the rest of the book in one lecture. A drawing tells you what a person cannot say out loud.

Her authority comes from being right three times before she is wrong once. The smudged mouth, the doorless house, and the thorny branches: she reads all three correctly, and the reader has no reason yet to doubt her. Then she reaches the bird resting in the hollow of the tree and calls it proof of a hidden capacity for love, evidence that violence and nurturing can coexist inside the same child.

That reading is wrong, and it stays wrong for the rest of the novel. Little A grows up to become Naomi Konno, the woman whose case drives every chapter that follows, and what looks like a hopeful detail in an eleven-year-old's drawing is the first clue nobody in the room was equipped to read correctly.

Chapter One: The Old Woman's Prayer

Plot Summary

On May 19, 2014, Shuhei Sasaki investigates a defunct blog. He is a 21-year-old college student. Kurihara, a junior in his Paranormal Club, recommended the blog. It is titled "Oh No, Not Raku!", and a man using the pseudonym "Raku" wrote it. Its subject is his life with his wife Yuki, a former professional illustrator six years his senior. The posts begin in October 2008, cheerful and domestic, covering their daily life and Yuki's pregnancy.

The final post, dated November 28, 2012, appears after a three-year silence in the archive. It is addressed "To the one I love most." Raku says he has finally decoded "the secret of those three drawings." He cannot forgive his wife's "sin," and he still loves her. Then the blog goes silent.

Reading backward through the archive, Sasaki learns that in May 2009, Yuki was diagnosed with a breech pregnancy. The hospital recommended natural delivery. As the due date approached, Yuki drank excessive amounts of juice, citing uncontrollable thirst.

To manage her anxiety, she drew five cryptic images she called "visions of the future". They show a baby in a Santa hat, an old woman praying, an adult woman with flowing hair, a young boy, and an adult man. On October 11, 2009, the blog ends: Yuki died of a brain hemorrhage during an emergency C-section. The baby survived.

Kurihara and Sasaki work through the archive. Kurihara spots a mathematical impossibility in a post about an anniversary cake. It has 8 slices. Raku eats 2, Yuki eats 1, and 4 are saved. One slice is unaccounted for.

Someone else was living in that apartment. Raku never mentioned a third resident.

Sasaki cracks the drawings. He notices that each has a circled number. Yuki was a professional illustrator. She would know layer composition.

Sasaki stacks drawings 1, 2, and 3, aligning their circles as central axes and scaling accordingly. Stacked, the three drawings resolve into one scene.

Drawing 1's "Santa hat" becomes a bloody incision in a pregnant belly. Drawing 2's "praying old woman" becomes a doctor in scrubs pulling a baby from the wound. Drawing 3's "adult woman with flowing hair" becomes a stiff corpse on an operating table. Yuki had drawn a picture of her own murder, embedded across three innocent-looking images.

Stacking drawings 4 and 5 yields a second image. A man and a young boy walk away together, hand in hand. Yuki drew a future she would not be alive to see.

The Slow Read That Sasaki and the Reader Share

Uketsu tells this chapter entirely through Raku's blog, so the reader does the same forensic work Sasaki does, in the same order, at the same pace. An ordinary domestic blog turns sinister one post at a time, and neither Sasaki nor the reader ever gets ahead of the other.

Kurihara barely functions as a character. He exists to spot the one thing Sasaki missed: the math on the anniversary cake. Eight slices, two for Raku, one for Yuki, four saved, and one left over with no owner. That extra slice belongs to someone the blog never named. She is Naomi Konno, Raku's mother, living in the apartment the entire time the blog ran and never once mentioned across three years of posts.

The blog's own title carries a second clue nobody inside the story catches. "Oh No, Not Raku!" rearranges into "Haruto Konno": Raku was never Raku, he was Yuta's father, and the drawings his dead wife left behind are what finally break him. Yuki's strange thirst and the hospital's push for a natural breech delivery both read as small, forgivable details on a first pass. Neither one is forgivable. Both come back, with their full weight, in the Final Chapter.

Chapter Two: The Smudged Room

Plot Summary

Point of view shifts to Naomi Konno: widowed, raising her five-year-old son Yuta in a sixth-floor apartment. The chapter opens with a harsh scolding. Yuta used a geometric stencil ruler to draw in permanent marker on the apartment walls.

A concurrent storyline: Naomi notices a man in a grey coat following her and Yuta home. He drives a compact car. She cannot place him but feels the threat clearly.

At Yuta's nursery school, homeroom teacher Miho Haruoka examines Yuta's Mother's Day drawing. He drew their apartment building in reasonable detail. Their specific sixth-floor room carries a violent grey blotch over it. Haruoka investigates the mechanics. Yuta did not use a grey crayon.

He used a white crayon over a black underdrawing. The pressing and smearing mixed the pigments into an opaque grey. A classmate, Miu Yonezawa, volunteers one detail. Yuta's original drawing showed a large rectangle with a small triangle inside, and he erased it.

Haruoka connects the shape to the stencil ruler Naomi punished Yuta for using. She draws on child psychology research, which holds that children draw the idea of trauma rather than literal objects. She concludes that Yuta drew the implement his mother struck him with. She phones Naomi to report suspected abuse.

Naomi realizes Haruoka has misread the drawing. The rectangle and triangle are the kanji 今野, the characters for "Konno," which looks like a triangle sitting above a rectangle, not a stencil ruler.

Yuta was attempting to draw a gravestone, his mother's gravestone. Naomi deduces that Yuta has been sneaking to Sakura Memorial Garden. He holds a faint memory of his father once taking him to visit "Mummy's" grave. She goes to the cemetery.

She finds Yuta at the headstone of Yuki Konno.

That evening, the grey-coated man follows Naomi into her apartment building. She has anticipated this. She waits behind her door with a kitchen knife. When he steps inside, she stabs him. As he falls, his hood drops: the wrinkled face of an old man she dimly recognizes.

Sympathy Built on Purpose

By the time Naomi picks up a knife, the reader has known for a full chapter that she is dangerous, and Uketsu spends this entire chapter making that knowledge useless. He puts her through a harsh, unfair accusation from her son's teacher and an exhausting stretch of solo parenthood, and the effect is real sympathy for a woman who ends the chapter stabbing a man in her own doorway.

Haruoka examines Yuta's drawing with the exact tool Dr. Hagio used in the prologue, art as a window into subconscious trauma, and reaches the exact wrong conclusion Hagio nearly reached. She reads the grey blotch as a stencil ruler standing in for abuse, when Yuta is drawing his mother's name over the shape of a gravestone. He is trying to erase what is in front of him and reach what is buried under it. Nobody in his life has told him his mother is dead, let alone that she has a name he could draw.

This chapter confirms two identities. Yuta is the baby who survived Yuki's murder on the operating table in Chapter One, and Naomi is Haruto's mother, not Yuki's, which makes her the "old woman praying" in Yuki's composite drawing, the figure with both hands reaching into the incision.

Haruto's own sequence resolves here too. He worked out what his mother had done, took Yuta to his real mother's grave, wrote his last blog post, and hanged himself.

The man Naomi stabs is Isamu Kumai, a veteran reporter who appears formally in Chapter Three. He survives. His stalking was deliberate provocation, meant to push Naomi into a violent act his police contact could arrest her for. She never calls the police when she feels threatened. She picks up a knife, the same way she always has.

Chapter Three: The Art Teacher's Final Drawing

Plot Summary

The timeline shifts to August 1995. Shunsuke Iwata is a 19-year-old high school graduate. He failed to land a reporting position, so the L-Daily newspaper placed him in its administrative department. He wants one specific story: the 1992 unsolved murder of his high school art teacher and personal mentor, Yoshiharu Miura.

His boss in the admin department is Isamu Kumai, a veteran reporter demoted after a bout with esophageal cancer. Kumai was the lead reporter on the Miura case and shares his confidential files with Iwata.

The physical evidence from the 1992 murder on Mt. K is strange. Miura's body was discovered at the mountain's eighth-station clearing. A rock beat it more than two hundred times, which made it completely unidentifiable. The degree of mutilation forced the pathologist to estimate the time of death from stomach contents alone. Miura ate a Hanayagi bento box, and digestion placed his death at 5:00 PM on September 20.

This timeline cleared two people. Miura's wife had an alibi for the morning of the 21st. A student named Yuki Kameido had an alibi for the evening of the 20th. The prime suspect became Nobuo Toyokawa, a resentful college friend of Miura's who had no alibi for that evening.

Two details continued to bother investigators: Miura's sleeping bag was stolen, and some of his food was missing. Miura had also drawn a crude picture of the mountain range on the back of a folded supermarket receipt.

Iwata pursues an independent lead to his old school. There he meets a blind student drawing on a "pierced canvas," a surface with tactile gridlines. The image clicks. Miura folded the receipt into a grid and drew the mountains by touch, without seeing his own hands.

Iwata hikes Mt. K on the anniversary of the murder to test the theory. At the eighth station at 5:00 PM, he looks at the mountain range and sees nothing. The setting sun is directly behind it. The mountains are completely backlit, invisible against the glare. Miura could not have drawn a detailed mountain range in those conditions.

He deduces the actual sequence. The killer captured Miura and restrained him in his own sleeping bag through the night. The next morning the killer force-fed him the Hanayagi bento, which then looked like normal consumption. Two and a half hours after the meal, the killer murdered Miura.

The killer destroyed the body beyond recognition to eliminate rigor mortis as a time-of-death indicator. The bento's digestion level did the rest. It placed the death ten hours early, inside the window where the killer had an alibi.

Iwata realizes the brutal mutilation was never about rage. It was a forensic necessity. With his theory proven, Iwata sits in his tent on the mountain.

That night, Naomi Miura binds him in his sleeping bag and force-feeds him.

Iwata realizes what is happening and why. He folds a piece of paper and draws one last blind picture of the mountains against his restrained hands. Then she kills him. Naomi then murders Toyokawa. She types a fabricated suicide note on a brand-new word processor to frame him for both deaths, and closes the police file for good.

A Genre Change Mid-Book

The story drops its epistolary, domestic frame here and becomes a hardboiled forensic procedural, tracking a nineteen-year-old cub reporter who dies for getting too close to a three-year-old mountain murder. Nothing about the case is what it first looks like once Iwata rebuilds the timeline. Miura's body took more than two hundred blows from a rock because a beaten, unrecognizable body gives a pathologist no way to read body temperature or rigor mortis, not because of rage. That leaves exactly one piece of forensic evidence, the digested bento, and the killer controlled that evidence completely by force-feeding Miura the next morning and killing him hours later.

Iwata's proof comes from a blind student's pierced canvas, a drawing surface worked by touch through a tactile grid rather than by sight. Miura folded his own receipt into the same kind of grid so he could draw the mountain range with his hands bound inside a sleeping bag, in the dark, without looking. A sighted man's drawing was made exactly like a blind one, and that mismatch is what breaks the alibi.

This chapter also reveals who Kumai is: the grey-coated stalker from Chapter Two. He survives. His cancer keeps progressing. His stalking was deliberate provocation, meant to trigger a violent reaction from Naomi that his police contact could use to arrest her, one last case he wanted to close before running out of time.

The fake suicide note is typed on a brand-new word processor. A real suicide note would be handwritten, so the note's own format is what proves it was forged to avoid a handwriting match.

The Final Chapter: The Bird, Safe in the Tree

Plot Summary

Following her 2015 arrest, Naomi Konno's history is reconstructed in full.

As a child, her father's suicide left her alone with a deeply abusive and sociopathic mother. Naomi found one source of comfort: a pet finch she named Cheepy. Her mother tried to crush Cheepy to death. Eleven-year-old Naomi fought back and stomped on her mother's neck until she died. She was committed to a juvenile reformatory.

That girl was "Little A."

Naomi eventually became a midwife, married Yoshiharu Miura (the murdered art teacher), and had a son, Haruto. Miura was a harsh disciplinarian who struck the introverted Haruto and forced him outside.

Naomi feared that her juvenile record would cost her custody of Haruto in any divorce. So she planned and executed the elaborate murder on Mt. K. She killed Toyokawa later when he deduced the method and attempted to blackmail her into a sexual relationship. She killed Iwata when he got too close.

Years later, the adult Haruto reconnected with Yuki Kameido, Miura's former art student, and married her. They moved in with Naomi. Yuki became pregnant.

Naomi began to want the baby as something to own, not something to help raise.

Using her medical knowledge, she replaced Yuki's prenatal iron supplements with 15-gram daily doses of sodium chloride, which is pure salt. Ingested throughout a pregnancy, this level of sodium induces progressively worsening hypertension.

Naomi, as senior midwife at the clinic, falsified Yuki's blood pressure charts and arranged for the dangerous natural breech delivery. On the operating table, Yuki's blood pressure spiked to fatal levels. She died of a brain hemorrhage. Naomi took the baby.

Three years later, Haruto decoded Yuki's composite drawings. He understood what his mother had done. The blog's final post was a goodbye, written to Haruto's wife, who was already dead. He took Yuta to Yuki's grave. Then he hanged himself.

In the aftermath of Naomi's arrest, Dr. Hagio realizes her diagnosis of "Little A" was wrong. The smudging, the doorless house, and the thorny branches all held up. The bird did not hold up: she had read it as proof of a capacity for nurturing that would soften the aggression, and she had the causality backwards.

The thorns exist to protect the bird. Naomi's maternal love drives her violence rather than redeeming it.

Kumai, recovering in the hospital, shares a room with Kurihara (from Chapter One). Kurihara explains the blog's mysteries. Kumai's cancer is advanced and his life is effectively over. He adopts the newly orphaned Yuta to break the cycle.

The Pattern That Breaks on Purpose

The Final Chapter treats Naomi as a psychological profile to understand, not a mystery to solve, and the understanding does not bring comfort. Her first three killings are built to earn sympathy: she kills an abusive mother to save a bird, an abusive husband to protect her son, and a blackmailer to protect an innocent life. The pattern holds together well enough that a reader has to work to resist rooting for her. Naomi killed Yuki simply because Yuki stood between her and a new person to possess, and that murder breaks the pattern the first three built.

The book's only comfort comes through substitution rather than justice. Nobody punishes Naomi for what she did to Yuta's family. Kumai, a dying man with nothing left to protect, adopts the boy instead, and that quiet, unglamorous act is the closest thing the story offers to an ending that heals anything.

Master Map: Planted Clues and Their Payoffs

Three Clues Worth Rereading For

The clue I missed on a first pass is the cake. Raku's post about their wedding anniversary mentions an eight-slice cake: two for him, one for Yuki, four saved for later. That is seven. The eighth slice belongs to nobody the blog ever names, and it sat there for three years before I noticed it, proof that Naomi Konno had been living in that apartment the entire time the blog ran, eating from a cake she was never once mentioned eating.

Yuki's thirst reads as a throwaway domestic detail the first time through, one more small complaint in a blog full of small complaints. It is the murder weapon. Naomi replaced Yuki's iron supplements with fifteen grams of salt a day, and the uncontrollable thirst was Yuki's body trying to survive its own poisoning. The American College of Obstetricians and Gynecologists treats a planned cesarean as the safer default for a term breech pregnancy and reserves vaginal delivery for hospitals that document strict protocols and informed consent, because the mortality gap between the two paths is real. Naomi, as the clinic's senior midwife, had exactly the standing to override that guidance and steer Yuki toward the delivery that would kill her.

The cleanest single clue in the book is the mountain. The eighth station of Mt. K faces west, so at five in the afternoon in September the sun sits directly behind the range and the mountains go black against the glare. Miura's drawing shows detail no one could see under those conditions. He drew it in the morning, with the sun behind him instead of in front of him, which puts the entire official timeline for his death off by roughly fourteen hours. One fact about where the sun sits at 5 p.m. undoes an entire police file.

A few more clues do the same work in miniature.

• Yuta's Mother's Day drawing hides the kanji for the Konno family name inside a shape his teacher misreads as evidence of abuse.

• Miura's blind, tactile drawing on a folded receipt breaks his own murderer's alibi, because a sighted man could not have drawn it under the lighting conditions the police assumed.

• The blog's title, "Oh No, Not Raku!," rearranges letter for letter into "Haruto Konno," the real name of the man writing it, months before the text confirms it directly.

Thematic Resonance: How the Ending Shatters the Beginning

Strange Pictures widens its scope with every chapter. Chapter One is pure archive work, solved entirely from behind a screen. It turns physical and domestic in Chapter Two, then historical and procedural in Chapter Three, with a body found on a mountain. The Final Chapter pulls all three back into one woman's history, which is the actual shape of the book: four separate cases that were always the same case, viewed from four distances.

Dr. Hagio's lecture in the prologue states the book's real argument before the plot even starts: a drawing reveals what a person cannot say. She proves that argument three times over, then gets the fourth reading backward, showing what her own correct method does in the hands of someone who wants a hopeful answer badly enough. The thorns around the bird were never something the bird earned by being gentle. They exist because the bird needed defending, and Naomi's love for what she claims as hers is the same violence wearing a gentler face.

Kumai closes the book by adopting Yuta. He is a dying man with nothing left to lose and one decent thing left to do, and that is enough to break a cycle three generations deep.

If you have read this far and have not picked up the book yet, start with the English translation by Jim Rion (HarperVia, January 2025).

Related reading: Strange Buildings by Uketsu: Summary and Analysis and Strange Houses by Uketsu: Summary and Analysis.

Leave a comment

👋🏻 Hey. I’m Atharva.

I am a software engineer, a GTM strategist and an AI-native builder. I work at AccuKnox on DevRel and growth engineering for cloud-native security products. Before that I worked as a freelance developer, a technical writer and a research consultant.

In this newsletter I write about the things I build and the decisions I make. I cover AI systems, growth infrastructure and developer workflows. Once in a while I cover the movies, music and games worth your time. I write no summaries and no secondhand takes. You get what I built, what broke and why I made each call.

Four categories exist. Pick one:

🔵 Tech and AILLMs, AI cost engineering, Claude ecosystem, developer tools, hands-on implementation 🟢 Biz and GrowthGTM strategy, lead generation, content systems, marketing automation 🟡 Money and CareerCareer decisions, compensation, investing, working in tech on your own terms 🔴 Entertainment and CultureFilm, music, gaming, fiction, ideas worth arguing about

Now pick the outcome that fits you:

• 💸 AI Cost & Systems

• 🤖 Claude Ecosystem

• 🛠️ Dev Workflow & Tools

• 📈 GTM & Lead Generation

• 📣 Content & Growth

• 💼 Money & Career

• 🎬 Culture & Entertainment

• 📖 Full Archive

• 🔗 Find Me Elsewhere

💸 AI Cost & Systems

You pay too much for AI. Or you do not know why costs blow up at scale. Or the outputs stay inconsistent and you cannot find the cause. Start here.

Practical Tips for Reducing AI Costs, Part 1: Tactical StackModel selection, prompt caching and batching. These are the fast wins that cut your bill.

Practical Tips for Reducing AI Costs, Part 2: Context Optimization & Memory ManagementContext bloat multiplies cost. Design memory that avoids it.

Practical Tips for Reducing AI Costs, Part 3: Advanced Algorithms & Internal GovernanceRouting logic and fallback chains. You also get eval frameworks and org-level governance.

Token Anxiety and the Illusion of ProductivityWhat happens when you optimize for tokens instead of outcomes. Stop confusing activity with progress.

AI Slop Is a Skill IssueBad outputs come from bad inputs. An honest breakdown shows where most prompting falls apart.

50 AI Terms Every Developer and Builder Should KnowThe terminology that separates understanding from tool use. Learn the words.

🤖 Claude Ecosystem

Claude is the AI I use most. These posts cover the real setup. They also show how to extend Claude and fit it to your brain.

Building an AI Marketing Team with Claude SkillsHow I wired custom skills into Claude to run content. This is the actual setup and not a concept piece.

Skills 2.0, Anthropic Just Made Vibes-Based AI Building ObsoleteWhat changed with Claude’s skill architecture. It matters for anyone who builds serious workflows.

The 5 Files That Give Claude Code Permanent MemoryContext management for Claude Code. Structure your files so the model remembers.

🛠️ Dev Workflow & Tools

The stack you use every day compounds. These are the tools and setups I committed to. I give honest takes on what earns your time.

GitHub Copilot, A Complete Guide to Agents, Skills, and InstructionsEverything Copilot can do that most people never touched. You get agents, custom instructions, skills and a proper setup.

The 30-Minute Copilot Setup That Changes EverythingThe specific configuration I use. It sets up fast and it changes the work after.

One Command to Share Your Entire VS Code SetupExport your extensions, settings and keybindings. This helps on a new machine or with a new hire.

Your New PC Migration Should Not Cost You a Full DayThe actual checklist I use, with no fuss.

The Tech Stack I Bet My Career OnPython, FastAPI, Next.js, AWS, Cloudflare Workers. Why these and not the alternatives, and what the tradeoffs look like.

SEO for Vibe-Coded Apps, Audit and FixWhat breaks SEO when you build fast with AI. Audit it and fix it fast.

Forget Ranking #1 on Google, Get Recommended by AI InsteadGEO (Generative Engine Optimization) explained in practical terms. Structure content so LLMs cite you.

📈 GTM & Lead Generation

These cover the growth systems I built and tested. They give results with specifics and no theory.

2026 Marketing Stack for AI-Driven GTMThe full stack for a modern GTM motion. It shows what each layer does and what to cut.

The 3-Step Workflow to Intercept High-Intent Leads on Reddit and LinkedInFind people who already want your product. Follow the steps with no ad spend.

The Zero Dollar Lead Gen Channel Your Competitors IgnoreThe channel most B2B teams dismiss. It compounds quietly and the barrier to entry stays low.

The LinkedIn Pipeline Nobody Is Talking AboutHow to turn LinkedIn into a steady inbound pipeline. It takes less effort than one post.

I Almost Spent $250 on LinkedIn Auto-CommentsWhat I found when I looked at the tools. And what works instead.

How to Win Your First 10K Users Without SpamEarly distribution strategy for builders. What actually worked at small scale.

Integration Strategy for Small TeamsHow to connect your tools with no engineering overhead. The decisions that save you from workflow debt.

📣 Content & Growth

The content system is the asset. These posts build a system that compounds and needs no constant feeding.

Stop Writing Posts. Start Building a Content Flywheel.A flywheel is a loop where one finished piece of work feeds the next. The mental model shift that changes how you write content.

The 2026 Content Stack, Three Tools to WinThe actual tools I use. Why these three cover most of what you need.

My Second Brain Setup That Actually CompoundsA second brain is one local folder of plain text that holds what you know and finds it again. The Obsidian system I use daily, and how I capture, link and resurface ideas across projects.

The Joy Revolution Nobody in Your Marketing Meeting Will ApproveWhy the best content now looks unlike B2B output, and what to take from it.

💼 Money & Career

The business of being a technical person. I cover compensation, investing and career decisions. I cover work in tech without the wrong targets.

Two Years at AccuKnox, From Intern to SpecialistWhat I learned inside a cloud-native security startup. This is the real version and not the LinkedIn version.

You Don’t Rise to Your Goals. You Fall to Your Systems.Why discipline is overrated and environment design is underrated.

Calculating Your FIRE NumberThe math and the assumptions behind financial independence. Run it for your own situation.

A Dummy’s Guide to Investing WiselyFirst principles investing for people who do not want to become investors.

Inflation Isn’t One ThingWhy the headline number masks what happens to your purchasing power.

Slaying Your 20s, a five-part series on your path, ambition, money, digital detox and presence. Part 1: Owning Your Path · Part 2: Ambition vs Contentment · Part 3: Mastering Money · Part 4: Digital Detox · Part 5: Staying Present

🎬 Culture & Entertainment

I cover film, music, gaming and fiction. I have opinions and I defend them.

Mickey 17, A Systemic Analysis of the Future of Human LaborWhat Bong Joon-ho built beneath the premise.

Film School in Scenes, a multi-part series on directing, cinematography, story and the work of great filmmakers. Intro · Part 1: Heart of Story · Part 2: Masters of the Medium · Part 3: Vision and Craft · Part 4: The Director’s Process · Part 5: The Power of Restraint · Part 6: Anatomy of a Scene · Part 7: The Invisible Language

Her (2013), The Cultural and Ethical Weight of AI on FilmWhy this film reads better every year.

The Darkest Genre in Gaming Nobody Talks AboutThe games built around dread, loss and systems that punish you.

How 675 Million Spotify Users Get Fed MusicThe actual recommendation architecture. How the algorithm picks what you hear next.

I Fed Every Beach House Lyric Into an AIPattern analysis on a discography. What the model found that I missed.

The Algorithm Listens, Analyzing Every Lorde LyricThe same treatment for Lorde. I map linguistic and thematic patterns across her catalog.

The Hypnotic World of Haruki MurakamiWhat makes his prose work. Why it should not work as well as it does.

Why the Next Decade Will Rewrite Human CivilizationThe macro argument. Where AI, energy and geopolitics converge. This is what it means.

📖 Full Archive

Everything is at blog.atharvashah.com/archive.

Posts go out when I have something worth saying. They run dense and not frequent. Every post links to related posts. The archive stays coherent.

🔗 Find Me Elsewhere

• 🐦 X / Twitter: x.com/cultist_dev

• 💼 LinkedIn: linkedin.com/in/atharva-shah-tech

• 🐙 GitHub: github.com/HighnessAtharva

• 🎬 Letterboxd: letterboxd.com/highnessatharva

• 🎵 Last.fm: last.fm/user/highnessatharva

• 🌐 Website: atharvashah.com

• 📧 Email: hi@atharvashah.compaid work and real conversations only

I am open to web development and AI automation. I also take API integrations, technical content, GTM consulting and DevRel work. Find the details at atharvashah.com.

Leave a comment

A second brain is one local folder of plain text that holds everything you know and finds it again.

I drowned myself in building one. I did not follow a trend. I got tired of renting my brain to other people's servers. Every note in Notion, Evernote, or Google Docs lives on someone else's machine, and you pay monthly for the privilege. If the company raises its price or shuts down, you scramble to export your notes and rebuild the context you lost.

I wanted something different. I wanted a system where I own the data. The files sit on my hard drive as plain Markdown, and no company can hold that knowledge hostage. Every note compounds with the next one, so a connection I forgot I made can surface again on its own.

This is how I built it.

Locality Beats Convenience

Three core decisions shape the vault.

Locality. Every note is a .md file in d:\Atharva\NOTES. If Obsidian stops working, the vault survives, because plain text files outlive the apps and companies that make them.

Start fresh. I did not import the old chaos from Google Docs. I let the structure earn its place instead, because moving chaos into a new tool does not organize it.

Never delete. Notes move to Archive, not to trash. Storage costs little, and losing a note you might need later costs more.

The math beats SaaS pricing too. Obsidian is free to use, or a low one-time cost for the paid sync. Your files stay yours either way. There is no monthly rent, and no format that locks you into one company's app.

The File Structure Stays Flat

The vault looks overwhelming at first glance. The structure is flat on purpose. An idea buried three folders deep tends to die there.

Here is the structure I use.

• Root (.claude, .vscode, README.md, CLAUDE.md): config and workflows.

• INBOX: raw captures, active and unpolished.

• DAILY: one file per day, for work tasks, notes, and things I want to remember.

• DIGITAL TWIN: everything about me, including voice, audience, experience, and goals. This is the grounding layer.

• SUBSTACK: ideas move to drafts, then to published pieces.

• SOCIALS: one folder per channel, for LinkedIn, X, and Substack Notes.

• LIBRARY: stable reference material, including a glossary, lists, and resources.

• META: the engine room, holding templates, Copilot memory, Excalidraw files, and the graph tool.

I pin the key folders with an underscore prefix, like _INBOX, so they float to the top of the file explorer. The Iconize plugin adds folder emojis on top of that. I can scan the sidebar in a couple of seconds.

Vault Atlas Makes 1,281 Files Findable

I built an HTML page to make sense of the vault without cramming everything onto one screen. Vault Atlas has separate views for structure, publishing, automation, and recovery, so I always know which view to open.

Here is the current state of the vault.

• 1,281 files

• 320 social assets

• 173 system files

• 46 published articles

Vault Atlas turns that count into something I can navigate, instead of a number I have to hold in my head.

Four Layers, Not Random Folders

The vault behaves like an operating system with four layers.

1. Capture (INBOX + DAILY): loose input and daily traces.

2. Identity (DIGITAL TWIN): voice, audience, principles, and experience.

3. Publishing (SUBSTACK + SOCIALS): long-form source material plus the channels that distribute it.

4. Infrastructure (META + .claude + hidden config): attachments, automation, skills, and workspace behavior.

Each layer depends on the one before it. Automation cannot write in my voice until the identity layer exists, so I built Identity before I built Infrastructure.

The Graph Finds Connections I Never Made on Purpose

The Districts View

The structural breakdown looks like this.

• Mission Control (Root): routing and config.

• Capture (INBOX): active scratch space.

• Chronology (DAILY): a permanent timeline of what happened.

• Grounding (DIGITAL TWIN): voice, audience, experience, and goals, read before I generate anything with AI.

• Publishing Spine (SUBSTACK): ideas move to drafts, then to published pieces.

• Distribution (SOCIALS): LinkedIn, X, and Substack Notes.

• Durable Knowledge (LIBRARY): glossary, lists, resources, and PDFs.

• Infrastructure (META): templates, Copilot memory, Excalidraw, and the graph tool.

Each district carries its own rule. Drafts stay rough, and published pieces stay final. Library stays stable, and INBOX stays temporary.

The Knowledge Graph

I use Graphify to build a knowledge graph that clusters more than 2,000 files on its own. The graph finds patterns I did not link by hand.

Zoom into any node and you see its full neighborhood. The panel on the right shows the file type, the community, the source path, the degree (how many connections it has), and every neighbor by name. One article can carry 20 direct connections across drafts and social posts. Every arrow marks a real connection, and each new file adds more edges, so the map gets denser over time.

I started this as an Obsidian plugin project, but I moved the graph work into GitHub Copilot inside VS Code, because the connection visualization is tighter and the file scanning is faster.

The Digital Twin Grounds Every Draft

Most AI output sounds generic, because the model does not know what you sound like.

My DIGITAL TWIN folder holds five files that fix that.

• voice.md: writing style, banned words, sentence rhythm, and what counts as slop, meaning writing with the machine's shape still on it.

• audience.md: 17 reader archetypes, with their pain points and buying triggers.

• experience.md: 9 competency pillars.

• goals.md: what I am shipping and what is still open.

• principles.md: the values and decision filters I write against.

When an agent drafts a post in my voice, it reads voice.md first. When it suggests an angle, it checks audience.md and experience.md next.

The identity lives in files, not in a chat window's memory. That is why the output does not read like something a stranger generated for me.

The Vault Runs Its Own Automation

The vault is programmable, built from four components.

• Grounding (DIGITAL TWIN): voice, audience, experience, goals, and principles.

• Infrastructure (META): attachments, clippings, Copilot memory, templates, and the graph tool.

• Workflow engine (.claude): agents for orchestration, skills for transformation.

• Editor behavior (.obsidian, .vscode): plugin behavior, MCP setup, and workspace settings.

I have 43+ skills for tasks I used to do by hand.

The Social Flywheel

A flywheel is a loop where one finished piece of work feeds the next. When I publish a Substack article, one piece of writing becomes four things: a tweet thread, a LinkedIn carousel post, a Substack Note, and a video script.

I still write the article by hand. The system distributes it across channels using skills built for each channel, with my voice as the shared input.

Three Questions I Actually Ask the Vault

I open Copilot Chat inside the vault and ask it real questions instead of guessing what it already knows.

How Do I Rewrite a Sentence in My Voice?

I pasted a sentence full of hype words and asked for a rewrite. Copilot read voice.md and named the exact words the guide bans. Then it rewrote the line direct and specific, without me telling it what "direct" means for me.

How Many Posts Have I Written About One Topic?

I asked how many blog posts I had published about AI cost reduction. Copilot checked the published folder and scanned for matches. It returned three exact titles from the same series, and it did not invent a fourth title to round out the answer.

What Was I Supposed to Finish in Q1?

I asked what I still owed myself from Q1. Copilot read goals.md and cross-referenced the project files. It laid out what shipped, what was still moving, and what had stalled since the quarter closed.

From Capture to Publish in Five Steps

1. The Dashboard

Dataview queries the vault on its own. It surfaces active drafts, urgent items, and recent captures the moment I tag a file.

2. Capture

Shift + Alt + O saves an article to META/Clippings with its metadata attached. The real trick is the phantom link. I type Future Topic for a note that does not exist yet, and when I create it later, every connection is already there waiting.

3. Voice Input

I do not type first drafts. Whispr Flow turns speech into text at 150 words a minute, against roughly 40 words a minute when I type.

4. Refinement

I select a brain dump, press Alt + I, and tell Copilot to restructure it. The ideas stay mine. Copilot just organizes them faster than I would by hand.

5. Visualization

Excalidraw lives inside META/Excalidraw, and I embed a file with ![[filename]]. I do not need a separate Figma account, and every diagram stays version-controlled with the rest of the vault.

Why It Compounds

Plain text does not lock you in. Open a Markdown file in Notepad thirty years from now, on any operating system, and it still opens. Try that with a Notion export.

The Graph View surfaced a pattern I never made on purpose. It connected a cold-email note to a content flywheel note, and both traced back to an audience-psychology note I had written weeks earlier. Notion and Google Docs cannot show you that kind of structure, because they do not track links between notes the way a graph does.

Everything lives in one place: code, long-form drafts, checklists, diagrams, and journal entries. One search covers all of it, and the question of where a file goes stopped costing me time.

The compounding shows up in the numbers too. I spend about 20% of my time on distribution now, and 80% on thinking and writing, because the flywheel skills handle the reformatting once an article is done.

The Recovery Playbook

This page exists for the day I forget how my own system works. It lists the operating rules for each district, the hidden config files, a first-ten-minutes checklist, and the workflow documentation I would need to get moving again.

The Six Moves That Built This Vault

Move 1: Lay out a flat folder structure first. Decide the top-level folders before you write anything, and resist adding a third layer of subfolders. A flat structure is what keeps INBOX, DAILY, DIGITAL TWIN, SUBSTACK, SOCIALS, LIBRARY, and META scannable in one glance.

Move 2: Write the grounding files before you automate anything. voice.md, audience.md, experience.md, and goals.md have to exist first, because every later skill reads them before it writes a word. Automation without a grounding layer just generates generic output faster.

Move 3: Cluster the vault with a graph tool. Running Graphify over the folder structure turns isolated files into a map of communities and connections, the same map that powers the Districts view and the Knowledge Graph.

Move 4: Build skills inside .claude. Each skill is one reusable workflow, the same kind that powers the Copilot queries and the Social Flywheel described above.

Move 5: Automate the handoffs with Templater. Publishing an article should create the placeholder files across every social channel automatically, instead of you remembering to open four folders by hand.

Move 6: Build a page like Vault Atlas. A single HTML view of the structure, publishing, automation, and recovery layers means you never have to hold the whole map in your head.

Once those six moves are in place, the vault runs mostly without you. Everything stays local, and the files stay portable and yours.

The System Doesn't Wait on Me to Show Up

I do not sit down and "write" anymore. I capture, structure, refine, and distribute, in that order, and the system already knows who I am before it touches a keyboard. Every output runs through my voice and my goals before it reaches a reader.

I put real hours into this infrastructure, and I intend to keep using it.

The Flywheel Dashboard Updates in Real Time

The Dashboard After Publishing

Once an article goes live, the flywheel runs on its own. The dashboard lists every article next to its social outputs, updated in real time, so I can see what shipped and what is still queued without opening four separate folders.

Zooming Into the Graph for the Next Idea

When I do not know what to write next, I zoom into the graph instead of staring at a blank draft. One article node connects to research notes, related pieces, audience-archetype files, and competitor notes. The graph shows me what I already built nearby, so I rarely start from zero.

The Monthly Velocity Numbers

The metrics dashboard tracks what shipped, not hours logged or tasks checked off. Monthly output has stayed steady since I built it.

Video Walkthrough

See the full system in action: How My Second Brain Works

The video includes live demos of:

• Vault structure in VS Code

• Obsidian graph visualization

• Real-time Copilot queries

• Content flywheel automation

• AI-powered analysis and planning

Leave a comment

Every New Laptop Costs You a Full Day

You get a new laptop. The thrill lasts about ten minutes, and then reality hits.

You spend the next eight hours downloading browsers, editors, terminals, media players, and CLI tools one by one. You hunt for config files scattered across AppData folders. You rebuild your VS Code settings from memory. You forget half your browser extensions. By midnight you're still not back to where you started.

I got tired of this cycle. So I built a migration kit. It takes me from a fresh Windows install to my exact working environment in under an hour. It needs no Microsoft Store, no manual download and no guesswork. One script installs everything. Another script restores every config, theme, and shortcut right where it belongs.

This is that system.

The Software Stack

Here is every tool that goes on my machine, grouped by what it does. This is the master list that feeds into the automated installer script later.

Productivity and Communication. Obsidian is the foundation - my second brain, my vault, my entire knowledge system. TickTick handles task management. For communication, it's Slack for work, Discord for communities, and Telegram for everything in between. Flow Launcher gives me keyboard-driven quick access to files and apps without touching the mouse. QuillBot rounds it out for writing and paraphrasing.

Browsers and Research. Brave is my primary browser - privacy-focused, fast, and Chromium-compatible. For AI-assisted research, I keep Perplexity, Claude, and ChatGPT available as web apps. Proton VPN handles secure browsing when I need it.

Development and Terminal. VS Code is the primary editor. Sublime Text stays around for fast, lightweight file editing when I don't need a full IDE. Docker handles containerization. Node.js and Python are the core runtimes. MongoDB and SQLite cover local database needs.

Media and Creativity. VLC plays everything. Audacity handles audio editing. MediaMonkey 5 manages my music library with metadata intact. OBS Studio records and streams. Upscayl does local AI-powered image upscaling. qBittorrent handles downloads.

System and Utilities. WizTree finds large files and frees up disk space fast. SyncThing is the backbone of the entire migration system - peer-to-peer file sync across machines with no cloud middleman. CCleaner cleans up system junk. PDF24 Creator handles offline PDF merging, splitting, and editing. Calibre manages my ebook library.

The Command Line Arsenal

The GUI apps are only half the picture. The real power lives in the terminal.

FFmpeg, yt-dlp, Gallery-DL, and ImageMagick are staples. They handle media conversion, video downloading, gallery scraping, and image processing. Five more CLI tools complete the kit.

Rclone is the one tool I need for cloud storage. It syncs files to Google Drive, Dropbox, and dozens of other providers from the command line. Pandoc converts between markup formats - Markdown to PDF, Markdown to Docx, whatever you need.

Zoxide replaces the cd command with a smarter one. It learns your habits, so a few letters take you to any directory. Ripgrep searches text across entire codebases and vaults at absurd speed. Bat is a better cat, with syntax highlighting, line numbers, and Git integration.

Every one of these installs through a package manager. That removes the search for a download page.

The Two-Tier Strategy

To make this truly plug-and-play, the system runs on two layers. The first is the engine, the part that gets every app installed. The second is the soul, the part that makes the machine feel like the one you left behind. Winget runs the engine. SyncThing plus symlinks run the soul.

The Automated Installer (bootstrap.ps1)

This is the engine. It uses Winget to install the entire stack in one shot, and every app from the list above maps to its correct Winget package ID.

PowerShell

# Run as Admin check
if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Write-Error "Run this script as Administrator!"; return
}

$apps = @(
    # Productivity
    "Obsidian.Obsidian", "TickTick.TickTick", "Slack.Slack", "Discord.Discord",
    "Telegram.TelegramDesktop", "Flow-Launcher.Flow-Launcher",

    # Browsers & VPN
    "Brave.Brave", "Proton.ProtonVPN",

    # Dev & Terminal
    "Microsoft.VisualStudioCode", "SublimeText.SublimeText.4", "Docker.DockerDesktop",
    "OpenJS.NodeJS", "Python.Python.3.12", "MongoDB.Server", "SQLite.SQLite",

    # Media & Creativity
    "VideoLAN.VLC", "Audacity.Audacity", "VentisMedia.MediaMonkey",
    "obsproject.obs-studio", "Upscayl.Upscayl", "qBittorrent.qBittorrent",

    # Utilities
    "AntibodySoftware.WizTree", "Syncthing.Syncthing", "Piriform.CCleaner",
    "PDF24.PDF24Creator", "kovidgoyal.calibre",

    # CLI Power Tools
    "Gyan.FFmpeg", "yt-dlp.yt-dlp", "mikf.gallery-dl", "ImageMagick.ImageMagick",
    "Rclone.Rclone", "JohnMacFarlane.Pandoc", "ajeetdsouza.zoxide",
    "BurntSushi.ripgrep.MSVC", "sharkdp.bat"
)

foreach ($app in $apps) {
    Write-Host "Installing $app..." -ForegroundColor Cyan
    winget install --id $app --silent --accept-source-agreements --accept-package-agreements
}

Run that as admin, walk away for 15 minutes, and come back to a fully loaded machine. That covers thirty-plus apps with zero clicks.

What Makes It Actually Plug and Play

Installing apps is the easy part. The hard part is making them feel like yours. That means restoring settings, themes, keybindings, and databases. SyncThing keeps a folder called C:\Backup\Config synced across all your machines. The table below maps exactly which paths need to be tracked for each tool.

If it's not on this list, it doesn't need special treatment - Winget handled it. If it is on this list, the next script handles it automatically.

The Symlink Restore Script (restore_settings.ps1)

This is the soul. Once SyncThing has downloaded your C:\Backup\Config folder to the new machine, this script creates the symbolic links that point Windows at it. Windows then reads the settings from their normal locations, and the real files stay in your synced folder.

PowerShell

# Define where your synced configs live
$syncFolder = "C:\Backup\Config"

# Function to create the link
function Set-Link($appPath, $backupPath) {
    if (Test-Path $appPath) { Remove-Item -Recurse -Force $appPath }
    New-Item -ItemType SymbolicLink -Path $appPath -Target $backupPath
}

# Apply Links
Write-Host "Restoring App Settings via Symlinks..." -ForegroundColor Green

# 1. VS Code Settings
Set-Link "$env:APPDATA\Code\User" "$syncFolder\vscode"

# 2. Flow Launcher (Everything: plugins, history, themes)
Set-Link "$env:APPDATA\FlowLauncher" "$syncFolder\FlowLauncher"

# 3. yt-dlp Global Config
Set-Link "$env:APPDATA\yt-dlp" "$syncFolder\yt-dlp"

# 4. Git Config (Crucial for your dev work)
Set-Link "$env:USERPROFILE\.gitconfig" "$syncFolder\git\.gitconfig"

After this runs, you open VS Code and your theme is there. Your keybindings are there. Flow Launcher has your plugins. Git knows who you are. It all just works.

Things That Need Special Treatment

Not everything plays nice with symlinks.

Obsidian stores its config inside the vault itself - the .obsidian folder holds your themes, plugins, and appearance settings. You don't symlink Obsidian's AppData. You just point the app at your synced vault on the new machine, and everything comes with it.

Brave and other Chromium browsers encrypt some profile data in ways that are tied to the specific machine. Symlinks can break login sessions and saved passwords. The safer move is Brave Sync for extensions and bookmarks. Keep a manual export of your Bookmarks file in the backup folder as insurance.

Python and Node.js don't have meaningful config files to sync. What they need is their global packages. Add your npm install -g and pip install commands to the end of bootstrap.ps1 so they run as part of the same automated setup.

Taking It Further With a Dotfiles Repository

The SyncThing approach works. But a GitHub repository transforms your setup from a manual backup into a proper dotfiles system. You get version history for every config change and a way to undo a mistake. One git clone command then deploys your whole environment on a new machine.

The Repository Layout

Create a repository called dotfiles-windows with this layout:

Plaintext

.
├── scripts/
│   ├── bootstrap.ps1        # Installs all apps (Winget)
│   └── restore.ps1          # Creates the symlinks
├── configs/
│   ├── vscode/
│   │   ├── settings.json
│   │   └── keybindings.json
│   ├── flow-launcher/       # Folder for Flow settings
│   ├── git/
│   │   └── .gitconfig
│   └── obsidian/            # Optional: Global snippets or CSS
├── .gitignore               # CRITICAL: Prevents pushing secrets
└── README.md                # Instructions for your future self

Everything text-based and non-sensitive goes here. That means your scripts, your JSON configs, and your Git settings. The repo becomes a single source of truth.

The Smart Gitignore

App data directories contain tokens, machine-specific paths, and database files you don't want in version control. This .gitignore keeps the repo clean and safe:

Plaintext

# Ignore local databases and logs
*.log
*.db
*.sqlite

# Ignore sensitive VS Code data
configs/vscode/backups/
configs/vscode/workspaceStorage/

# Ignore actual Obsidian Vaults (Keep those in Syncthing/Proton Drive)
# Only track global Obsidian CSS or templates here if desired.
vaults/

# Ignore sensitive Git credentials
.git-credentials

One-Command Deployment

With the repo set up, your entire migration on a new laptop becomes a single line:

PowerShell

git clone https://github.com/YourUsername/dotfiles-windows.git C:\dotfiles; & C:\dotfiles\scripts\bootstrap.ps1; & C:\dotfiles\scripts\restore.ps1

That single command finishes the whole migration, from an empty machine to a fully configured one.

The restore.ps1 in the repo is smarter than the standalone version - it detects where it's running from and resolves paths automatically:

PowerShell

$repoRoot = (Get-Item $PSScriptRoot).Parent.FullName
$configSource = "$repoRoot\configs"

function Set-Link($targetPath, $sourcePath) {
    if (Test-Path $targetPath) {
        Write-Host "Backing up existing config for $(Split-Path $targetPath -Leaf)..."
        Move-Item $targetPath "$targetPath.bak" -Force
    }
    # Ensure the parent directory exists
    $parentDir = Split-Path $targetPath -Parent
    if (!(Test-Path $parentDir)) { New-Item -ItemType Directory -Path $parentDir }

    New-Item -ItemType SymbolicLink -Path $targetPath -Target $sourcePath
    Write-Host "Linked: $targetPath" -ForegroundColor Gray
}

# -- Execute Links ---
Write-Host "Linking configurations from $configSource..." -ForegroundColor Cyan

# VS Code
Set-Link "$env:APPDATA\Code\User\settings.json" "$configSource\vscode\settings.json"

# Git
Set-Link "$env:USERPROFILE\.gitconfig" "$configSource\git\.gitconfig"

# Flow Launcher
Set-Link "$env:APPDATA\FlowLauncher\Settings" "$configSource\flow-launcher\Settings"

Write-Host "Migration Sync Complete!" -ForegroundColor Green

This version also backs up existing configs before overwriting them. It renames the current file to .bak before it links the synced one in. That backup holds exactly one prior version, the state right before the last run. Run the script again on the same machine and the new .bak replaces the old one.

Keeping It Updated

The symlinks make maintenance easy. Switch your VS Code theme and the file in C:\dotfiles\configs updates on its own. It is the same file. All you do is commit and push:

Bash

cd C:\dotfiles
git add .
git commit -m "Updated VS Code theme"
git push

Every machine pulls the latest version on the next sync with zero extra effort.

GitHub Handles the Logic, SyncThing Handles the Data

GitHub gives the dotfiles repo a real commit history, so a bad settings change is one git revert away. That works because the tracked files are text: scripts, JSON configs, a single .gitconfig. An Obsidian vault or a SQLite database does not behave the same way in Git. Git tracks the whole binary file as changed, not the two lines that actually changed inside it, so the repo grows with every sync and the commit history stops being something a person can read. SyncThing skips that problem by design. It moves the Obsidian vault, the MediaMonkey library, and the rest of the media files with no Git repo involved, at the cost of no undo button.

Keep the scripts and the JSON configs in the dotfiles repo, where version control earns its keep. Keep the vault and the databases in SyncThing, where quiet background sync matters more than history.

Related Reading

• VSCode Plugin Export and Share with Friends

Leave a comment

The Invisible Tax on Every Vibe-Coded App

You shipped the app. The landing page looks good. The product works. Nobody finds it.

This is the failure mode of vibe coding. You prompt an AI to build your whole React app in an afternoon. It generates clean components, handles routing, and sets up a decent UI. It skips discoverability every time, unless you ask for it.

The app ships with no meta tags and no sitemap. It carries no semantic HTML structure, no OpenGraph cards, and no JSON-LD schema. Images carry no alt text. Pages carry no canonical URLs. The app runs, and search engines cannot see it.

A page with no OpenGraph tags drops a bare URL into a shared link, and that costs real clicks. Backlinko and ClickFlow's study of five million Google results found the top organic result pulls a 27.6 percent click-through rate. A page a crawler cannot parse never reaches that position at all.

Client-Side Rendering Is Why Crawlers See Nothing

AI code generators optimize for what renders in the browser. Ask Claude or GPT to build a portfolio site or a SaaS landing page, and the model builds the visible layout first. Title tags, meta descriptions, and structured data never show up in a browser preview, so the model skips them by default.

Developer Charlie Graham wrote about the same failure on dev.to. Tools like Lovable, Bolt, Replit, and Cursor optimize for shipping speed, so a correct heading hierarchy gets left out by default, along with meta tags and structured JSON. Worse, most of these tools render content client-side, and a crawler that only reads the initial HTML never sees that content at all.

The money at stake backs up the urgency. First Page Sage tracks a 702 percent median SEO return on investment for B2B SaaS companies specifically, with breakeven around seven months. Paid ads stop producing the moment you stop paying for them. Organic traffic keeps paying only if the technical foundation exists first.

A Div Inside A Div Tells A Crawler Nothing

The clearest symptom sits in the markup itself. A vibe-coded page is often a div nested inside a div nested inside a div, with no <main>, <nav>, or <article> tag marking what any section actually is. A crawler has no signal for what the page is about, because nothing in the HTML says so.

The Fix Is Two Prompts, Run In Order

I built two prompts that fix this. Drop each prompt into your AI coding agent and point it at your React codebase. Claude, Cursor, and Copilot all work with them. The first prompt audits the app and fixes it. The second prompt documents every change the first one made.

The audit prompt follows a strict four-phase model. It crawls your project structure and identifies every public-facing route. It then builds a full SEO plan before it edits one file. That order matters. An AI that injects meta tags before it reads your site architecture makes a mess.

The order is the point, so treat it as a sequence rather than a checklist:

1. Map. The agent finds every public-facing route and proposes a strategy against it.

2. Build the infrastructure. The agent creates robots.txt, the sitemap and the dependencies before it touches a page.

3. Optimize each page. The agent adds unique meta tags, OpenGraph cards, semantic HTML and clean URLs.

4. Tune performance. The agent adds lazy loading, dynamic meta tags for parameterized routes, and JSON-LD schema for AI crawlers.

The prompt also includes a safety constraint. It writes a plan file first. It then waits for your approval before it edits any application code. You stay in control.

Prompt 1 - The SEO Audit and Fix

Drop this prompt into your AI coding agent with your React project loaded. The agent analyzes your codebase, generates an SEO plan, then fixes every route.

Role: You are an Expert Senior Full-Stack Engineer and SEO Specialist.

Task: Perform a comprehensive SEO overhaul of this React workspace. You must follow a strict "Plan-First" execution model.

Phase 1: Analysis & Documentation
Crawl the Project: Scan the /src folder, especially routes (e.g., App.js, routes.tsx, or react-router configs) to identify every public-facing page.

Sitemap Audit: Locate or create a strategy for a dynamic sitemap.xml.

Deliverable: Create a file named SEO_PLAN.md documenting:

A list of all identified routes.

The proposed robots.txt configuration.

A plan for implementing react-helmet-async for head management.

A strategy for OpenGraph (OG) tags and structured data (JSON-LD).

Phase 2: Technical Infrastructure
Robots & Sitemap: Generate a robots.txt in the /public folder. Create a script (or a manual sitemap.xml) that includes all routes found in Phase 1.

Dependency Setup: Install react-helmet-async.

Global Provider: Wrap the application in the HelmetProvider at the root level.

Phase 3: Page-Level Optimization
For every page component identified:

Meta Tags: Add unique <title> and <meta name="description"> tags.

Social Graph: Implement OpenGraph (og:title, og:description, og:image) and Twitter Card tags.

Semantic HTML: Review the JSX. Ensure the page uses a logical heading hierarchy (<h1> for main titles, <h2> for sections) and semantic tags (<main>, <article>, <nav>).

Clean URLs: Ensure all Link components use human-readable slugs.

Phase 4: Performance & Programmatic SEO
Image Optimization: Identify <img> tags and suggest/implement loading="lazy" and descriptive alt text.

Dynamic Routes: If the app uses dynamic parameters (e.g., /products/:id), create a pattern to generate unique meta tags based on the data being fetched.

Optimize all page Title Tags to fall between 50–60 characters and implement a site-wide JSON-LD 'Organization' and 'WebPage' Schema to clarify brand identity for LLMs and search engines. . Ensure all critical brand and service information is 'crawl-ready' without requiring JavaScript execution to prevent data loss during AI indexing.

Constraints:

Do not break existing CSS or functional logic.

Use react-helmet-async instead of the legacy react-helmet.

Prioritize "Human-Readable" code and SEO-friendly URL structures.

Wait for my approval on SEO_PLAN.md before modifying any application files.

A Plan File Catches A Duplicate Meta Description Before It Ships

Most people tell an AI to add SEO to an app and stop there, with no plan phase. The AI then guesses at your site structure. It duplicates meta descriptions across pages and misses routes it never crawled.

The plan-first constraint forces the agent to analyze the site before it writes any code. You review the plan document before a single file changes. You catch a missing route or a wrong keyword while fixing it still costs nothing.

Prompt 2 - The SEO Report Generator

Run this second prompt after the audit prompt finishes. It compares the before state and the after state of your codebase. It then writes a professional report. The report names every change, the reason for it, and its effect on search performance.

The report does real work. Build for a client and the report becomes a deliverable you can hand over. Build for yourself and it becomes the record of why a page's title tag reads the way it does, months after you approved the plan and forgot the reasoning behind it.

The report covers five areas:

**Role:** You are a Senior Technical SEO Auditor.

**Task:** Conduct a post-implementation review of the SEO overhaul performed on this React workspace. You must generate a professional, comprehensive report named `SEO_REPORT.md`.

**Scope of Analysis:**

1. Compare the current state of the `/src` and `/public` folders against standard React SEO best practices.

2. Identify every component where `react-helmet-async` or SEO meta tags were added.

3. Identify all new files created (e.g., `sitemap.xml`, `robots.txt`, `SEO_PLAN.md`).


**Report Structure Requirements:**

### 1. Executive Summary

- Provide a high-level overview of the SEO health of the application before vs. after implementation.


### 2. Technical Infrastructure Changes

For every **New File** created (e.g., `robots.txt`, `sitemap.xml`):

- **File Path:** [Path to file]

- **Purpose:** Why was this specific file created?

- **Impact:** How does this file affect search engine crawlers (indexing, crawl budget, etc.)?


### 3. Page-by-Page Breakdown

Create a section for **every page/route** modified. For each page, document:

- **Component Name & Path:**

- **Elements Added:** List specific Tags (Title, Meta Description, OG Tags, Schema.json).

- **Technical Decisions:** Why was this specific keyword or description chosen for this route?

- **Semantic Improvements:** Note if tags like `<div>` were changed to `<main>`, `<article>`, or if `<h1>`-`<h6>` hierarchy was corrected.

- **SEO Impact:** Explain how these specific changes improve the "Relevancy Score" for that page.


### 4. Dependency & Architecture Log

- **Library Choice:** Document the use of `react-helmet-async`.

- **Decision Logic:** Why did we use an asynchronous head manager instead of standard React state? (Mention thread safety and SSR compatibility).

- **Global Configuration:** Detail the `HelmetProvider` implementation at the root level.


### 5. Performance & Accessibility (A11y)

- List improvements made to `<img>` alt tags and `loading="lazy"` attributes.

- Explain how these changes impact Core Web Vitals (LCP, CLS).


**Tone:** Professional, technical, and data-driven. Use tables where appropriate to compare "Before" and "After" states for meta-titles and descriptions.

**Final Output:** Save all of this into `SEO_REPORT.md` in the root directory.

Run The Audit Prompt First, Approve The Plan, Then Run The Report Prompt

Open your vibe-coded React project in your AI coding environment. Paste the first prompt. Let the agent generate the SEO plan. Review the plan, adjust it if needed, then approve it. The agent implements every fix from the approved plan.

Paste the second prompt next. It scans the changes and writes the full audit trail. You end up with an SEO-fixed app and a report that names every change and the reason for it.

The whole process takes about thirty minutes. A freelance SEO consultant charges $75 to $300 an hour in 2026, and a one-time technical audit runs $500 to $10,000 depending on scope, per goLance's 2026 freelance SEO rate guide. These prompts do not replace a consultant's strategy work or copywriting. They close the mechanical layer in about thirty minutes.

The Same Four Phases Work In Next.js, Without react-helmet-async

The four-phase model is not React-specific. Next.js's App Router ships a built-in generateMetadata function, so the same map, build, optimize, and tune sequence applies without adding react-helmet-async at all. Swap the Phase 2 dependency step for a note to use generateMetadata, and the rest of the plan holds.

Run the audit prompt on your own project this week. Check route by route whether a real meta description now replaces the default one your framework shipped.

Related Reading

• GitHub Copilot - A Complete Guide to Agents, Skills, and Instructions + Best Setup (I Tested It)

Leave a comment

A VP of Engineering asks a public question about runtime visibility. That signal beats a thousand cold emails. It also costs nothing to reach. Most marketing budgets assume the reverse.

Stop creating demand and start capturing it

The default model is interruption. Teams write posts nobody asked for and run ads at cold audiences. They spray sequences into inboxes where the mail dies unread. All of it manufactures interest that did not exist a moment before. The assumption is that enough volume eventually finds one buyer.

Meanwhile the person with the problem types it into a public thread with their job title attached.

Capturing that demand costs a fraction of manufacturing it. Demand generation is expensive, because you fight inertia. Demand capture is cheap, because the buyer already did the hard part. They named the problem and published it in public. Your only job is to show up with the exact answer.

That is social listening for lead generation, done right. The 3-Step Workflow to Intercept High-Intent Leads on Reddit and LinkedIn covers the mechanics step by step.

What a Cold Meeting Actually Costs You

A single outbound-qualified meeting is not free just because no invoice names it. You pay for a sales rep's time. You also pay for the sequencing tool and the data enrichment vendor underneath it, plus the opportunity cost of every email that bounces or gets ignored before it reaches anyone. Most of those meetings go nowhere.

Now compare that to a reply on a public thread. The cost to engage is close to zero. You write one careful answer that adds real information. You buy no ad and you run no sequence, because the person already went looking for the answer instead of you chasing them.

The trade is not close, and the reason is not mysterious. You skip the step where you convince a stranger that they have a problem, and you answer someone who already named it, in public, with their job title attached to the post.

What a High-Intent Post Actually Sounds Like

Not every social post is worth a reply. The skill is to read intent before you spend the time on one.

Competitor frustration is the clearest signal there is. Someone posts that a named CNAPP vendor no longer works for them, because a specific capability, runtime visibility for example, is absent, and asks what else is out there. That person does not browse. They already decided to leave. Answer with a direct comparison aimed at the exact gap they named, plus a migration path that sounds easy, and you have the easiest sale in B2B marketing.

Technical problem-solving reads differently. Someone hits a wall while building something in production right now, and asks how other people solved it. Answer the wall with an architecture diagram, a working code snippet, or a link that actually explains the fix, with no pitch attached. Your tool becomes the infrastructure layer under their build before they ever fill out a form. The sale comes later. The trust starts here.

Category research is the slowest of the two to pay off, and the easiest to skip. Someone asks what actually separates two categories of tool, because they are still forming their mental model of the space. Shape that model honestly, and your name is the one already in their head three months later when the budget shows up.

Scoring Signals So Your Team Stops Wasting Time

Raw signal volume overwhelms any sales team fast. A scoring layer filters noise from opportunity before anyone spends time on a lead.

Velocity is the dimension teams underrate most. Usability researcher Jakob Nielsen first published the "90-9-1 rule" through the Nielsen Norman Group in 2006, and it is still widely cited today. The rule found that in a typical online community, roughly 90 percent of participants read and never post at all. A busy thread broadcasts to that much larger, silent readership, not just to the one person who asked the question, and that readership already self-selected for the topic before you showed up.

From Anonymous Handle to Pipeline

Most social listening efforts generate engagement and never connect it to revenue. The gap between an anonymous Reddit username and a CRM opportunity looks wide. It is narrower than it looks.

Discovery comes first. You find a high-intent post that matches one of the signal patterns above. De-anonymization comes next. Social enrichment tools map the handle to a real identity and a real company, because people reuse usernames, link their other profiles, and leave the same trail everywhere. Before anyone reaches out, you verify intent: does this company sit on your target account list, or does it already use a competitor you can speak to directly? That single check stops your team from chasing an account that will never close.

Then comes the follow-up, and it runs on two channels at once. The public reply lives in the thread itself, written for the much larger group of people reading and not posting, the majority the 90-9-1 rule describes. The private message goes straight to the person who asked, and it references the exact question they posted in public: "I saw your post about runtime visibility gaps. We solved that exact problem for a company your size. Happy to share how." A message that specific gets answered.

Why This Beats Cold Outbound on Every Dimension

The comparison is worth making explicit.

Cold outbound guesses at timing from a persona model that is probably already stale. Social listening reverses that order. The buyer's own behavior sets the timing, so you guess nothing, and you showed up with help instead of a pitch.

Every reply you write also stays online after the conversation ends, and that matters more than it first sounds like it should. In 2024, Reddit signed a content licensing deal worth roughly $60 million a year with Google. It signed a separate deal with OpenAI the same year. Both deals exist so Reddit's posts and replies can train the companies' AI models and answer engines. A reply you write today can end up inside the answer a future buyer gets when they ask an AI assistant what tool solves their problem.

Guardrails That Keep the Program From Getting You Banned

Run this at scale with no guardrails and you get banned from subreddits and dragged on Twitter.

Every reply needs a human review before it goes live. AI can draft the first pass from your product positioning and your ideal customer profile. A person still has to read it before it goes live, confirming the tone fits the community and that no line reads like a press release. The moment your replies sound like marketing copy, the whole approach stops working, because the value was never the pitch. It was the help.

Volume needs a network, not a single account. One brand handle cannot answer every relevant thread on Reddit without triggering a spam flag. Spread the work across real people with real expertise, evangelists who already work in the space and actually participate, because faked engagement reads worse than no engagement at all. And before anyone replies, cross-reference the handle against your existing customer list. A paying customer should never get a cold pitch for the product they already bought, because that breaks trust faster than any thread ever builds it.

The Compounding Machine

A paid campaign stops producing the day you stop paying for it. A public reply produces results for years after you stop posting, because a person still finds it, reads it, and decides you already answered the question they had.

Every thread you take part in becomes search engine result space you did not pay for. These discussions already rank on page one of Google for searches like "alternative to [competitor]" and "[category] reviews." That means you capture existing demand, and over time you also shape the information that creates the next round of it.

The same threads double as market research. Each one is raw, unfiltered customer language: what a competitor's tool lacks, and what problem repeats itself while nobody in the category solves it. That feedback reaches your product roadmap directly, with no survey and no focus group in between.

People already ask ChatGPT and Perplexity for software recommendations instead of typing a search query into Google. The Reddit-Google and Reddit-OpenAI licensing deals mean a reply you wrote six months ago has a real shot at being part of that answer.

A helpful reply on a public thread works for as long as the thread stays online. Nobody has to renew a budget for it, and nobody can decide to cut the channel next quarter.

Leave a comment

TLDR: Obsidian + Wispr Flow + GitHub Copilot. Own your data, speak your thoughts, transform everything. That's it.

Twelve Subscriptions and Still Nothing Gets Written

Most creators in 2026 pay for a dozen tools and still stare at a blank page every morning. They keep four writing apps and two AI chatbots open. They pay for a calendar tool, a scheduling tool and a CRM they stopped touching months ago. None of it adds up to more finished work.

Three problems compound on each other. Writing runs slow, because every thought gets typed out from scratch. AI drafts sound like everyone else's AI drafts, so reaching for AI help just makes the sameness worse. Ideas sit scattered across a dozen apps with no link between them, so nothing written this month makes next month's writing any easier.

This article names three tools that fix those three problems, nothing more. Obsidian holds your notes as files you actually own. Wispr Flow gets ideas out of your head at talking speed. GitHub Copilot turns one voice note into five different pieces of finished content. Together they cost close to nothing, and they replace what used to take a content team.

Obsidian Stores Your Notes as Files, Not as Someone Else's Database

Right now your ideas probably live everywhere. Some sit in Apple Notes. Some sit in Google Docs. You send yourself random Slack messages. You set up a Notion workspace six months ago and never opened it again.

Obsidian changes this with one decision. It stores everything as plain Markdown files in a folder on your machine. Markdown is a plain-text format that marks structure with symbols instead of a database schema. The files do not sit in someone else's cloud, and they do not need a support ticket to export. They are text files in a folder on your hard drive.

You own the files completely. Obsidian could fold, pivot or paywall the product tomorrow, and your notes still sit in that folder. Copy them anywhere. Open them in any text editor. Markdown is also the format large language models read best. Hand a model a Markdown file and it sees the headings, the emphasis and the lists at once, with nothing to convert first.

Everything also lives in one searchable, linkable vault. Every idea, every draft and every prompt template answers a single keystroke. You link notes to each other and build a graph of your own thinking over years, and you can run one operation across hundreds of files at once, because they are only files on a filesystem.

Your whole intellectual output sits in a folder you control forever, readable by any tool that reads text.

Wispr Flow

Most people lose their best ideas at the keyboard. Typing takes effort, and it puts a filter between the thought and the page that kills momentum. Type paragraph three, and the insight for paragraph seven is already gone.

Wispr Flow takes the keyboard out of the job. Press a hotkey, talk, and accurate text appears in whatever application is open. It cleans up your speech and handles punctuation on its own, and it turns rambling spoken thought into readable text.

A 2016 study from Stanford, the University of Washington and Baidu clocked speech input at roughly three times faster than typing on a phone keyboard. That gap holds for a full draft, not just a text message. I stopped typing anything longer than a sentence. Writing that starts as speech also sounds narrative and conversational rather than robotic, because you spoke it out loud first, and that cadence lands in the output without any work to put it back in.

The workflow itself is simple. Open Obsidian, create a new note, press the Wispr Flow hotkey and start talking. The words land in the vault in real time, already in Markdown, already searchable.

One thing about it will bite you once. Speak for ten minutes with the recorder off, and that content is gone. The tool holds no buffer and offers no "restore last session". Check the indicator before a long session, because losing one great rant is the only lesson that actually sticks.

GitHub Copilot

Your ideas sit in Obsidian now, in your own words, spoken rather than typed. GitHub Copilot is where a raw voice note becomes finished content.

I use it through the GitHub Student Pack, which bundles Copilot access to several flagship models through one interface. A monthly quota applies, and in over a year of daily use I have never come close to it. Outside the student pack, the paid tier still costs less than a separate subscription to any one of those models on its own.

The value sits in feeding your own raw voice note into a prompt template and getting an output that matches your voice back out, rather than in the chat interface or random debugging questions. One voice note can become five tweets carrying the same core insight, a newsletter essay that expands the idea with structure, a blog post with headers, or a LinkedIn post reframed for that audience. When the idea is product-shaped, the same note becomes a PRD, short for product requirements document. When it is outreach-shaped, it becomes a pitch email.

The model does not invent your ideas. It moves the same idea into a different container each time, and the thinking underneath stays yours. What changes is the formatting, the structure and the platform-specific work, and the model does that instead of you now. A single ten-minute recording, run through five templates and still inside the free monthly quota, is five drafts you did not have to write from a blank page.

The Workflow in Practice

Voice -> Obsidian -> Prompt Templates -> Polished Output

You dictate into Obsidian with Wispr Flow, with no editing and no self-censorship while talking. Get the ugly first draft out of your head and into a file, then decide what to do with it. Some voice notes get transformed within minutes. Others sit for a day before I come back to them with fresh eyes, and both approaches work.

Open GitHub Copilot next and select the voice note as context, so the model sees everything you said. Run it through a prompt template. Try "Turn this into a Twitter thread," "Extract the core argument for a newsletter," or "Structure this as a blog post." The model takes the raw thinking and formats it for the target platform.

Include your knowledge base folder in the same prompt, so the output references your background and speaks to your actual audience instead of a generic one. The next section covers what goes in that folder.

Then edit what comes back. AI gets you eighty percent of the way there, and the twenty percent you add by hand is the part that makes the piece yours rather than the model's.

Build a Digital-Twin Folder So the Output Sounds Like You

The three tools above are replaceable. What is not replaceable is the context layer that feeds them, and that context layer is a folder inside your own vault.

Call the folder digital-twin, or knowledge-base, whatever name sticks. Fill it with files that describe how you think and speak, not your resume.

Keep prompt templates generic, and never hardcode your personality into them. Pull the personality from the digital-twin folder on every run instead. One template that says "Write a tweet thread about this topic" becomes your tweet thread once the model reads your voice, your audience and your principles alongside it. The same template works for anybody who builds their own folder, because the personalization lives in the data rather than in the instruction.

Include the folder as context in every transformation prompt. The model then knows your audience is early-career marketers rather than enterprise CTOs, knows you write short sentences rather than compound paragraphs, and knows you value ownership over convenience. Update the files as you change, a new achievement in experience.md, a changed mind in principles.md. The outputs improve because the context improves, not because the prompt got cleverer.

You are locking yourself into your own system here, not a vendor's. The real switching cost is months of accumulated self-knowledge that no other tool has access to.

Prompt Templates as a Transformation Library

Store your prompt templates in Obsidian beside everything else, and include the digital-twin folder as context with every one you run. You paste nothing by hand, and you sound like yourself in every format. Here are five starting points.

Take this voice note and extract 5 standalone tweets. Each should be punchy, under 280 characters, and capture one distinct insight. Use my voice and speak to my audience.

For a newsletter, the template asks for expansion instead of extraction:

Transform this voice note into a newsletter essay. Open with a hook, develop the core argument, include a personal angle, and end with a clear takeaway. Match my writing style from the digital-twin folder.

A blog post and a PRD pull the same raw note in two different directions, one toward scannable structure, the other toward product thinking:

Structure this voice note as a blog post. Add headers, break into scannable sections, and expand thin areas with relevant detail. Keep my voice throughout. Extract the product thinking from this voice note. Structure as Problem, Proposed Solution, Key Features, Success Metrics, Open Questions.

LinkedIn gets a different frame again:

Reframe this idea for a LinkedIn audience. Professional but not corporate. Lead with the insight, add context, end with engagement. First-person, conversational.

Build enough of these and one ten-minute voice note turns into a week of content across platforms. The marginal cost of each extra piece drops toward zero, because the thinking already happened once. You are only reshaping the container each time after that.

What the Whole Stack Costs

Obsidian is free for personal use. Wispr Flow has a free tier. GitHub Copilot is free through the Student Pack, and its paid tier still costs less than one month of a single enterprise SaaS subscription without the discount. Three tools and a folder of text files replace what a content team used to produce.

Start with one file. Write about.md today, in Obsidian, and let the other five follow as you actually use the stack.

Related: Content Flywheel Plan for 2026

Related reading: GitHub Copilot - A Complete Guide to Agents, Skills, and Instructions + Best Setup (I Tested It)

Leave a comment

In Bong Joon-ho's Mickey 17, your body is a crashed Docker container. Your consciousness gets flashed onto a freshly printed vessel like firmware onto a new device the moment you die.

The film reads like a plausible engineering spec for how a collapsing society might ration human life. It treats people as deployable infrastructure, not citizens. The scariest part is how little imagination it takes to get from where you are right now to Mickey's world.

The Economics of Expendability

The story starts with debt, not drama or cosmic stakes. Mickey Barnes signs up as an Expendable in 2054, after his anti-meat fast-food venture, called Macarons Are Not a Sin, collapses and leaves him owing a loan shark he cannot repay. Bong Joon-ho adapted the film from Edward Ashton's 2022 novel Mickey7, and the debt-driven premise survives the jump to the screen almost untouched.

Earth in the story has already hit resource limits and shed most of its social safety net. In that vacuum, a new job category exists: the Expendable.

Think of it as the gig economy pushed to its logical endpoint. You do not trade your time or your labor. You trade your body.

You sign a contract. You get printed. You die. You get reprinted. You do it again.

Expendables serve as biological telemetry probes, walking into lethal environments so the protected population does not have to. They sample unknown pathogens before anyone important sets foot on the ground. They are human test cases running in production, and the production environment will kill them.

A canary release pushes a small slice of traffic through an untested path to see what breaks before the rollout reaches everyone. The Expendable program runs the same play, except the canary is a person.

Mind as Software, Body as Hardware

The central breakthrough in Mickey 17 is mind-body decoupling. Bong Joon-ho calls the two halves Cortex and Vessel. The mind is a Docker image, a digitized brain state carrying memories, personality, and cognitive rules. The body is a container, a 3D-printed, replaceable biological runtime.

Death becomes a terminated instance. You redeploy the same image onto fresh hardware and keep going. The body turns stateless and disposable, and identity lives entirely in the saved state. Your continuity rides on the fidelity of your memory dump. If the backup is clean, you wake up as yourself. If it is not, you wake up as something else wearing your face.

A stable model runs across many deployments while the environment underneath it changes. The person stays consistent across copies only as long as the state stays intact. Lose the state, and you lose the person, not the body.

The Engineering Problem Nobody Talks About

This entire setup collapses unless someone solves two hard engineering problems. The film glosses over both, which is exactly where it gets interesting if you think about it seriously.

Genetic fidelity. Every reprint needs one-to-one DNA replication. Drift across iterations degrades the vessel, and it changes the brain substrate hosting the mind. A slightly different brain running the same cognitive image introduces subtle errors.

Over enough reprints, Mickey $N+1$ is not the same person as Mickey $N$. The software did not change. The hardware drifted. This is the biological equivalent of running the same application on increasingly divergent chipsets and expecting identical behavior.

Memory injection. The brain dump needs perfect continuity, with zero lost time between the death of Mickey $N$ and the boot of Mickey $N+1$. Any gap creates discontinuity. Any corruption creates a different person who believes they are the original. If the memory stream is unprotected and someone intercepts and edits it, you are not just killing a person. You are rewriting who they wake up as.

That is identity hijacking at the firmware level, and you cannot patch it after the fact. The person who would notice the tampering is the person who was tampered with.

The Race Condition That Breaks Everything

Here is where the architecture falls apart completely, and where the film finds its real tension.

What happens when two bodies print from the same brain image at the same time? You get a race condition.

Two processes sharing a resource, both assuming exclusive access, neither aware the other exists until they collide, is a familiar failure mode in distributed systems. In Mickey 17, the shared resource is an identity. Two Mickey instances boot from the same snapshot, each carrying a full and legitimate claim to being the real continuation.

Which one has authority? Which one counts? The system was designed around single-instance governance, one Mickey at a time, and the moment that assumption breaks, the design collapses with it.

The film's universe treats a broken assumption like that as a capital offense. A "multiple," two active copies of the same person, is illegal, and the expedition leader, Kenneth Marshall, has already sworn to eliminate any multiple on sight. That rule exists because the writers understood a single-instance system needs an enforcement layer, not an honor system.

A workable model would still need hierarchy. A Prime, the original person behind the first genetic sequence and brain scan, would act as the master node. Reprints would run as child pods, failing over through an explicit protocol if the Prime dies.

Skip that protocol and you get identity collision instead. That is split-brain behavior in database terms: two nodes accept writes at the same time, diverge, and cannot be merged back without losing data. In Mickey's case, the data you lose is a human being.

The Horror of Normalization

The most disturbing part of Mickey 17 is how fast everyone accepts the technology.

Nobody in the film stays horrified by the Expendable program for long. The ethics get raised, then buried under operational urgency. There is a mission. Resources are scarce. Someone has to die so the colony survives, and because the system works, people stop questioning it.

The warning has nothing to do with 3D-printed bodies. You already live in a world that normalizes disposability: gig workers with no benefits, contract soldiers fighting privatized wars. The distance between "acceptable cost of doing business" and "Expendable" is shorter than you think. Mickey 17 just removes the pretense by making the disposability literal.

The film forces questions that do not have clean answers. If a mind can be copied indefinitely, individual sovereignty dissolves, and you stop being a person and become a template. If death is reversible, murder turns into an operational inconvenience rather than an irreversible act, and accountability evaporates with it. If humans become disposable, the only question left is who gets to set the disposal policy, and that question is always answered by whoever holds power, not by whoever holds a moral argument.

A society running this system needs governance around duplication and memory ownership. Without those guardrails, human life becomes a resource you allocate and terminate based on need.

What This Film Actually Gets Right

The trajectory Mickey 17 warns about is already visible if you know where to look. Efficiency pressure and economic desperation are already pulling in the same direction as the technology that would make disposable people a system rather than an accident. The technology in the film is fictional, but the incentive structure behind it is real.

The open question is governance. Brain-computer interfaces and 3D-printed organs are already active research fields, which means pieces of mind-body decoupling exist today, not just in Bong Joon-ho's script. The technology alone will not decide whether people stay people or become containers you spin down when the cost-benefit calculation changes. Rules, enforcement, and power structures will decide that.

The film does not answer the governance question, and it does not have to. It shows what happens when nobody asks the question early enough.

State persistence, identity integrity, consensus across copies, and resource management for on-demand replication are the problems Mickey faces throughout the film. Infrastructure engineers solve versions of these same problems every day, just with workloads instead of human lives running on the servers. When the system you design runs on people, every architecture decision becomes an ethical one.

Mickey 17 and Mickey 18 do not resolve their identity collision through a protocol. They resolve it by trying to kill each other first, then hiding from Kenneth Marshall long enough to negotiate who takes which shift and which death. That is what happens when a system reaches production with no plan for the case its own design allows: the people running through it improvise the failover themselves, in real time, with everything on the line.

Related reading: The Games That Broke My Brain (And Why I Keep Coming Back) and Haruki Murakami: How to Read His Surreal Fiction.

Leave a comment