I enrolled because I wanted a forcing function. I was already doing DevRel at AccuKnox, already thinking about how AI was reshaping the job, already building tools to reduce how much of my workflow was manual. But thinking about something in the background while doing other work is not the same as sitting with it directly and building something real from it. The cohort gave me a reason to do the second thing.

The format: one session per week, one project built in parallel, one public deliverable at the end. This is that deliverable.

Here’s a recap of my notes, takeaways and learnings from each of the final session to take away from the DevRel Uni Cohort 7 that ran for 6 weeks.

Session 1: The Scope of the Job Changed

Bianca Buzea opened the cohort with a deceptively simple framing: four things define DevRel across any era. Sense-making (what matters), storytelling (why it matters), distribution (who hears it), and feedback loops (what’s working). Those stay. Everything around them is moving.

The part that landed hardest for me was the audience expansion. DevRel has always served developers. Now it has to serve developers and AI agents simultaneously. Those aren’t the same job.

When a developer reads your docs, they read for intent. When an LLM reads your docs, it reads for pattern. A page that explains a concept well for a human can still be useless to a coding agent if the API examples are ambiguous, the parameter descriptions are vague, or the page is prose-heavy with no machine-readable anchors. An agent running in a coding environment doesn’t infer gaps. It either has the information or it hallucinates a plausible answer.

LLM-friendly documentation isn’t a style preference. It’s a different technical spec. Clean OpenAPI accuracy, explicit input/output schemas, deterministic code examples with exact commands, zero ambiguous pronouns. The docs need to answer the question before the question is asked, in a form that a retrieval system can lift without filling in blanks.

Bianca’s quiet point that “more people can build now, which means more people need guidance” is the one I keep returning to. The barrier to entry dropped. The demand for DevRel didn’t shrink. It widened.

Session 2: Career Architecture, Not Career Path

Nader Dabit’s session hit harder than I expected, partly because he’s watched enough of these cycles play out to speak with authority rather than anxiety.

The line that stuck: don’t optimize for a title, become a technologist.

1. Lock yourself into a job title and you’ve already lost. Think like a technologist, not a role. The people who last are the ones who can read shifts and move with them.

2. Career paths are rarely straight lines. Fast pivots beat slow, careful plans, and speed matters more now than it used to.

3. Nader’s learning system was the thing I kept thinking about after the session. He monitors GitHub Trending and Hacker News daily, runs AI agents on topics he tracks, and routes everything into custom feeds. His information advantage isn’t luck. It’s infrastructure.

4. Learning by itself doesn’t compound. The loop that actually builds something is: learn, build, share, get feedback, improve. The “share” step is the one most people skip.

5. Social media is a job board you get ahead of, not one you react to. Showing what you know publicly and helping people openly gets you on a company’s radar before a role ever posts.

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

In practice that means building in three layers that compound at very different rates. Tools change every few months. Fundamentals (systems thinking, communication, product sense) compound over years. Judgment, knowing what to ignore, when to move, and what actually matters, is the layer AI can’t replace. The sequence matters: tools are tactics, fundamentals are strategy, judgment is what lets you know which strategy applies right now.

The learning loop Nader gave is specific: learn something, build something, share something, get feedback, integrate. The key word is “share.” Output makes learning stick. A GitHub repo, a video, a post, a talk. Proof of work is the new resume, and proof of work is specific where a resume is generic.

One thing I applied directly from this session: treating 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 was a test of whether I could explain what I built clearly enough for someone who hadn’t been staring at the code all week. If I couldn’t write a clear LinkedIn post about what shipped, something was wrong with how I understood what I built.

The other thing Nader said that I flagged immediately: readiness usually comes after movement, not 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’s session had the line that I keep repeating to myself when I catch myself rushing without a system.

“Speed without system doesn’t create progress. It creates queues.”

1. Start research from data, not from a hypothesis. Feed AI a bias and it confirms the bias. The prompt is upstream of everything.

2. Snipers shoot with both eyes open: dominant eye locked on the target, the other keeping peripheral awareness. The dominant eye trap is what kills focused startups. Too zoomed in on the roadmap, too slow to catch competitors or new tools moving around them.

3. Carving out time to learn every day feels impossible until you realize the cost of skipping it. The compounding works in both directions.

4. Passion is your distribution strategy. Patrick posted an article on EdTech, something he actually cares about, and it brought in investors, collaborators, and hires. The content wasn’t a growth hack. It was proof of genuine interest.

The sniper’s fourth eye scope metaphor was specific enough to be useful. When you close one eye to aim, you get precision but lose peripheral vision. In a fast-moving AI ecosystem, losing that peripheral awareness is dangerous because the thing that shifts everything might not be inside your current focus window.

Patrick’s example about Framework, a project trying to teach kids engineering through building things, illustrated the problem with brutal clarity. The team wasn’t bad at execution. The team had a dominant-eye problem: so focused on their product roadmap that they missed the ecosystem shift happening around them. They were building something real while the ground moved.

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. But coding agents now operate inside your ecosystem too. They pull from your docs, your SDK, your changelogs. You need to gravity them in with the same structural clarity you’d use to onboard a developer who reads carefully and expects exactness.

Session 4: Your Docs Are a Product Decision

Hassan El Mghari from Together AI turned something I had been doing half-consciously into an explicit principle.

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

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

2. Develop taste. AI speeds up execution but doesn’t supply judgment. Good writing, thoughtful UX, interactive demos built with care, people can tell the difference between that and something generated without intention.

3. Consistency is the unfair advantage almost nobody uses. One article a week for six months is 24 articles. Most people never hit that. The same math applies to demos, videos, and open-source contributions.

4. DevRel now serves two audiences: developers and agents. That means MCP servers, agent-friendly docs, and SDKs built for coding agents, not just humans reading reference pages.

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. The return is that he can move the moment he has capacity.

Here’s the concrete problem. When a developer asks ChatGPT how to use your API, one of two things happens: the model answers correctly from training data or retrieval, or it hallucinates a plausible but wrong answer. The difference is whether your technical content was clear, authoritative, and structured well enough to get pulled into the response accurately.

This is not about Google ranking anymore. It’s about being in the answer when someone never visits your site. Your changelog entries, SDK method docs, and getting-started guides are now answering questions in conversations you’re not present for.

The implications are specific. Changelogs need semantic structure, not narrative bullet points. SDK method signatures need inline examples with typed inputs and explicit outputs. Getting-started guides need to be written for a system that will execute steps literally, not read them 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, 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. But he was direct that pace still matters and good ideas and strong UX are still human decisions. The agent accelerates execution of a direction you’ve already chosen. It doesn’t choose the direction.

Session 5: The Operations Grid I Didn’t Know I Needed

Francesco Andreoli from Consensys closed the cohort with the most operationally useful framing I heard across all five sessions.

The DevRel Operations Grid asks three questions per task: should this be human-led, AI-assisted, or agent-led? That’s not a philosophical question. It’s a workflow design question with a concrete answer for most of what DevRel teams actually do.

1. Francesco’s Pyramid of Builder Needs is a Maslow-style hierarchy adapted for developers. The bottom layer is docs. If your docs are broken, nothing above it (grants, events, hackathons) lands. You can’t skip levels.

2. The developer funnel separates value-driven onboarding from product conversion. His Builder Nights series worked because it covered the whole ecosystem (L2s, ZK, EIPs, different chains) without pushing a single product. Product-specific conversion only comes after that value-first stage.

3. The DevRel Operations Grid maps the gradual shift from human-led to AI-assisted to agent-native across content, community, support, and education. The key word is gradual. This is onboarding a new way of working, not flipping a switch.

4. Docs are top-of-funnel now. Agents crawl them to answer developer questions in conversations you’re not part of. GEO (Generative Engine Optimization) replaces SEO as the mental model. Well-structured docs beat marketing sites as agent sources.

5. You serve two audiences: humans and agents. That means llms.txt, MCP servers, agent skills, and guides written for systems that reason over them rather than skim them.

6. Community at scale still runs through a small, trusted core. Find your top 50 contributors and amplify their wins. The community grows around what you celebrate.

Here’s how it maps across common work:

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

The “Geo is the new SEO” point extended Hassan’s session into a direct strategy. Francesco called it GEO, Generative Engine Optimization. The docs that get cited in AI responses are the ones that are clear, authoritative, and structured so a retrieval system can grab them cleanly. You’re no longer just optimizing for search bots. You’re optimizing for language model retrieval.

The permissionless community angle was specific to Consensys’s web3 context, but the design logic holds anywhere. If your community can contribute without asking permission, you get faster growth and higher-quality submissions because contributors are self-selecting on actual investment. The system needs clear standards and a moderation layer, not a bottleneck at the front door.

My Capstone Project for the DevRel Uni Cohort 7 - DevRel Workbench (Giving Back to the Community)

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

The four tools: Launch Checklist Generator (paste a changelog, get a DRI-mapped checklist with pre-launch, launch day, and post-launch tasks and priority levels), Demo Run of Show Builder (describe a demo brief, get a timed agenda with speaking notes and a fallback matrix for common failure modes), Content Repurposing Planner (one source asset becomes six content briefs across channels), and Demo to Distribution Planner (one product change generates a connected demo flow, launch checklist, and 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 building it: scoped tools beat general assistants. Every time. I built a general AI assistant early on for the workbench. It underperformed the four scoped tools by a meaningful margin. The scoped tools have clear, testable success criteria. “Did this generate a valid launch checklist with DRI assignments, priority levels, and correct task categorization?” is a question you can answer objectively. “Was this conversation helpful?” is not.

That pattern held everywhere I looked during the cohort. The best-performing agent demos I saw, including Devin’s Nubank case study, were agents with narrow scopes and explicit success criteria, not general-purpose assistants given vague goals.

What I’m Taking Forward

Three concrete things that changed my actual workflow:

1. Agent experience is now part of my documentation process. When I write a getting-started guide or update an API reference, I run through it from the perspective of a coding agent executing the steps literally. If it would fail at any step, the doc needs to be fixed.

2. The learning loop is now scheduled, not reactive. Forty-five minutes a week of ecosystem scanning: taste new tools, document what changes, update the workflow list. Not background noise. Blocked time.

3. The DevRel Operations Grid is how I plan my week. Three columns: human-led, AI-assisted, agent-led. Anything that belongs in the third column and isn’t there yet is a backlog item, not a nice-to-have.

Thanks

Bianca built a cohort structure that gave people permission to ship imperfect things publicly and learn from them 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, and some parts held up and some parts got cut on camera. Both outcomes were useful.

Daniel Pisu, the conversations throughout the cohort were some of the most direct feedback I got on whether the workbench was actually landing for a working DevRel practitioner. That’s the signal that matters.

To my team at AccuKnox: everything I built here was shaped by the real problems I run into every week. The launch checklist tool was a direct export of the actual checklist we use. The demo run-of-show builder came from watching what breaks when you don’t have one. The workbench is a product built from doing the job, not imagining it.

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

ADE-Bench, dbt Labs’ analytics-engineering benchmark, has become a load-bearing reference point in the AI-for-data conversation in 2026. Altimate AI’s 74.4 percent score on it has traveled through industry newsletters, Hacker News threads, and at least three vendor evaluations the author has seen first-hand. The 35-point gap between Altimate and general-purpose agents is genuinely meaningful, and it is correctly framing the industry conversation about specialized harnesses versus general models.

The benchmark Altimate also reports, the one that gets a single sentence in their launch post and almost no industry coverage, is DAB-Bench. Altimate’s published score on DAB-Bench is 60.4 percent. The general-agent baseline lands in the 30 to 40 percent range. The absolute numbers are lower than ADE-Bench. The relative gap remains substantial.

DAB-Bench is the harder benchmark. It measures a different and more demanding shape of work. For organizations running data infrastructure that touches more than one warehouse, which is most enterprise data environments by 2026, DAB-Bench is the more directly relevant performance signal.

This analysis decomposes what the benchmark measures, why it is harder, what general agents fail on, and how buyers should weight benchmark numbers when evaluating AI tooling.

Why Benchmarks Shape the Field

Before decomposing DAB-Bench, a meta-observation. Benchmarks are imperfect signals. They are gameable. They drift from real-world relevance over time as agents optimize against them. SWE-Bench from Princeton helped define what “AI for software engineering” means by establishing a measurable target. HumanEval shaped a generation of code generation models and is now mostly a victory lap because every frontier model scores above 90 percent.

Benchmarks shape what gets built because they are how the field measures progress. The choice of benchmark establishes the implicit definition of “good.” If the benchmark only measures single-warehouse single-dialect single-language tasks, the tools optimized against it will be good at single-warehouse work and weak at heterogeneity. If the benchmark measures cross-warehouse heterogeneity, the tools optimized against it will get good at heterogeneity.

ADE-Bench and DAB-Bench are the two benchmarks shaping the AI-for-data category in 2026. They are different benchmarks measuring different problems. The difference matters for buyers and for builders.

ADE-Bench in Detail

ADE-Bench, the Analytics Data Engineering Benchmark, was built by dbt Labs and published alongside their own analytics-engineering agent work. The test environment is a dbt project sitting on a single warehouse, typically Snowflake. The tasks are realistic analytics-engineering operations: add a new model, refactor a CTE chain, debug a failing test, generate documentation, write a snapshot, add a relationship test.

Scoring is per-task, pass or fail, weighted by complexity. The benchmark publishes the suite of tasks publicly. Vendors run their agents against the suite and report results. Results are comparable in principle across vendors who run honestly.

The weakness of ADE-Bench is the homogeneous environment. The benchmark does not test what happens when data lives across three warehouses, when dialects disagree, when lineage crosses platform boundaries, or when the agent must reconcile schemas that represent the same business concept differently in different systems.

That gap is where DAB-Bench operates.

DAB-Bench in Detail

DAB-Bench, the Distributed Analytical Benchmark, was published by Altimate alongside Altimate Code. It is less open than ADE-Bench: the precise task suite is documented in Altimate’s launch material but not as readily reproducible by independent teams. This is a real critique that affects how the numbers should be weighted, and it is addressed in the buyer-evaluation section below.

The benchmark environment spans multiple warehouses simultaneously. Tasks pull data from Snowflake, PostgreSQL, BigQuery, ClickHouse, and MySQL, sometimes within a single task. The agent must understand dialect differences, schema variations, type system disagreements, and the basic fact that not every warehouse has every feature available.

Representative tasks (inferred from Altimate’s published material, since the full suite is not as openly distributed as ADE-Bench):

• Translate a ClickHouse argMax(value, key) aggregate to a Snowflake equivalent. The Snowflake-correct approach uses QUALIFY ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ... DESC) = 1 or a window function with a LIMIT. The pattern-matching wrong answer applies MAX(value) and loses the key information.

• Build a federated query that joins a customer dimension in PostgreSQL to a fact table in Snowflake without round-tripping the entire dimension. The correct approach uses a federation layer like Trino, Starburst, or Polaris-mediated Iceberg access. The wrong approach loads the entire customer dimension into Snowflake on every run.

• Reconcile schema disagreements when a column is named created_at in one warehouse and creation_date in another but represents the same business event. The correct approach requires inspecting both schemas, confirming semantic equivalence, and producing a unified view. The wrong approach picks one name and silently drops the other warehouse’s data.

• Write a backfill script that handles the daylight-saving boundary differently across regions stored in different warehouses. The correct approach inspects each warehouse’s timezone conventions and applies appropriate conversions. The wrong approach assumes UTC throughout and produces silently incorrect aggregates for regional reports.

Scoring on DAB-Bench is more nuanced than on ADE-Bench. Partial credit is given for tasks that produce the right shape but miss an edge case. Penalty is applied for tasks that look correct but silently produce wrong results, which is the failure mode that most damages production data.

Failure Modes General Agents Exhibit on DAB-Bench

Three failure modes recur across general-agent runs on DAB-Bench tasks, each instructive for understanding the difficulty.

1. Dialect translation when the source dialect has a feature the target dialect does not. ClickHouse’s argMax does not have a direct one-token equivalent in Snowflake. The general agent has to recognize the semantic intent (find the value of column B in the row where column A is maximum), produce a Snowflake query using QUALIFY ROW_NUMBER() OVER (...) = 1, and verify the result matches semantically. General agents tend to pattern-match argMax to MAX or to a misuse of GREATEST, both of which compile but return wrong results.

2. Schema reconciliation when column types disagree subtly. PostgreSQL stores timestamps as TIMESTAMP WITH TIME ZONE with one set of semantics. Snowflake’s TIMESTAMP_TZ has different semantics around timezone storage and arithmetic. ClickHouse’s DateTime64(3) is again different and does not represent timezone at all. When the agent joins or unions across these, type coercion happens automatically and silently. The query compiles. The query also returns wrong rows. Specialized harnesses catch this through deterministic type-checking. General agents do not.

3. Cross-database joins where the agent does not know whether a federation layer exists. If the customer team uses Trino or Starburst to federate Snowflake plus PostgreSQL, the agent can write a federated query that runs through the federation engine. If the customer team has no federation layer, the agent must extract one side and load it into the other warehouse first. General agents tend to assume the federation exists when it does not, producing queries that fail at runtime in ways that are difficult to debug.

These failure modes are not edge cases. They are the structure of real multi-warehouse work in 2026. Organizations whose data has accumulated across multiple platforms (typical for any company past Series B) encounter all three patterns regularly.

How Benchmark Numbers Should Be Read Critically

When a vendor publishes benchmark numbers, four questions sharpen the interpretation.

1. Who built the benchmark? A benchmark built by an independent third party is more credible than one built by the vendor itself. ADE-Bench was built by dbt Labs, which is independent of Altimate. DAB-Bench was built by Altimate.

2. Is the test suite public? A public, reproducible benchmark allows independent runs. ADE-Bench is more open in this regard. DAB-Bench is less open. The path forward for the field is for DAB-Bench to either become public or to be supplemented by an open multi-warehouse benchmark from another organization.

3. What is the control? The general-agent baseline matters. Altimate’s published baseline is “general agents land in the 30 to 40 percent range.” That is a credible comparison if the baseline ran on the same task suite with comparable prompting and tool access.

4. Does the benchmark measure what production cares about? A benchmark that gives full credit for “the SQL compiled” is too easy. A benchmark that requires “the SQL is semantically equivalent to a reference implementation” is harder and more useful.

For organizations evaluating AI tooling vendors, the right move is to ask the vendor for their benchmark methodology, the public availability of the suite, the control group used, and whether the numbers have been reproduced externally. Most vendors will answer these questions honestly. Vendors who deflect are the ones to skip.

What DAB-Bench Should Evolve Into

Three changes would meaningfully raise the credibility and utility of DAB-Bench as the field matures.

1. Public dataset and reproducibility. The task suite should become open like ADE-Bench. Independent researchers should be able to reproduce the numbers. If Altimate Code’s 60.4 percent holds under independent runs, the credibility increases substantially. If it does not, the field learns useful detail about where the harness’s limits are.

2. Versioning for longitudinal tracking. Benchmarks should be versioned so the field can track agent progress over time. DAB-Bench v1 versus v2 versus v3, with the v1 suite preserved for comparability. Without versioning, every claimed improvement is hard to attribute precisely.

3. Expanded dialect coverage, especially legacy. The current scope (Snowflake, PostgreSQL, BigQuery, ClickHouse, MySQL) covers most modern use cases. Adding Oracle, DB2, SAP HANA, and Teradata would extend the benchmark into the enterprise migration cases where AI tooling carries the most economic weight. An agent that handles Oracle-to-Snowflake migration well is worth real money to a meaningful number of Fortune 1000 companies.

4. Streaming and real-time tasks. Both ADE-Bench and DAB-Bench currently test batch tasks. The next frontier is streaming SQL on event data, which has different correctness properties (windowing semantics, late-arriving data, out-of-order processing). A future benchmark that covers Materialize, Flink SQL, RisingWave, and Snowflake/Databricks streaming primitives would extend relevance significantly.

What This Means for Buyer Stack Decisions

For organizations choosing AI tooling against a single-warehouse stack (all-Snowflake or all-Databricks with dbt as the transformation layer), ADE-Bench is the relevant benchmark. The 74.4 percent number meaningfully describes how the agent will perform on representative work.

For organizations choosing AI tooling against a heterogeneous stack (data in Snowflake, PostgreSQL for operational systems, ClickHouse for product analytics, BigQuery in an acquired subsidiary), DAB-Bench is the relevant benchmark. The 60.4 percent number describes that the agent handles cross-warehouse work better than a generic agent, but neither category is fully mature yet. Plan for human review on the harder cross-warehouse cases.

For organizations building AI tooling, both benchmarks matter as different signals. ADE-Bench shows whether the harness handles the common case. DAB-Bench shows whether the harness handles the cases that cost real money when they fail.

The strategic question for AI tooling buyers is not “which benchmark do you score highest on?” The strategic question is “which benchmark most closely models the work my team actually does?” That question forces honest evaluation of both vendor claims and internal infrastructure choices.

The Strategic Takeaway

Benchmarks are imperfect, gameable, and time-bounded. They remain the closest thing the field has to evidence-based evaluation, which is why they matter for buyers and builders alike.

ADE-Bench established that specialized SQL agents are meaningfully better than general agents on single-warehouse analytics-engineering work. The discourse has correctly absorbed this.

DAB-Bench is establishing that specialized agents are still meaningfully better than general agents on multi-warehouse work, but the absolute performance ceiling on multi-warehouse work is much lower, and the gap between specialized and general agents is narrower. The discourse has not yet absorbed this fully.

For data engineering teams running heterogeneous infrastructure, the operational implication is concrete. Adopt the strongest specialized harness available, expect a 60 percent baseline on cross-warehouse work, plan for human review on the residual 40 percent, and track DAB-Bench-style numbers as the relevant performance signal over time.

The benchmark conversation in 2026 needs to mature beyond ADE-Bench. Buyers who only pay attention to the higher number are reading the easier benchmark. The harder benchmark is the one that tells you what production work will actually look like.

Hundreds of thousands of production SSIS packages still run in Fortune 500 data estates in 2026. Health insurance carriers depend on them for claims reporting. Banks depend on them for regulatory feeds. Retail and CPG companies depend on them for nightly inventory reconciliation. The packages are not glamorous. They are critical. And until very recently, modernizing them required the most expensive shape of consulting engagement available in the data ecosystem.

The standard SSIS-to-dbt migration runs four to six months of senior consultant time, costs between $200,000 and $300,000 for a mid-sized estate of 50 packages, and concludes with a parity-validation phase that consumes more budget than translation itself. The economics work for consultancies. They do not work for the companies paying the bill.

The agentic harness pattern reshapes this economics. A 10-package migration that used to consume a four-week senior-engineer sprint now completes in a single weekend with deterministic parsing, AI-assisted SQL translation, and hash-diff parity validation. Cost reductions in the 70 to 90 percent range are credible. The migration is no longer a budget event. It is an engineering decision.

This playbook documents the working pattern.

Why SSIS Persists in 2026

A brief context note for readers outside the legacy data world. SSIS is SQL Server Integration Services, Microsoft’s ETL tool introduced in 2005. Dataflows are defined in XML, edited through a GUI in Visual Studio, and tightly coupled to SQL Server as both source and target system. The toolchain pre-dates version control as a meaningful development practice. Most SSIS packages in production were authored before Git became the universal default.

Three properties make SSIS estates uniquely difficult to modernize. First, the XML format is unwieldy for diff-based review, which makes the code resistant to incremental refactoring. Second, the GUI-driven authoring pattern leaves behind packages with cryptic auto-generated names (COL_1, Out_3) that obscure intent. Third, business logic is often distributed across SSIS dataflows, T-SQL stored procedures, and external SQL Server jobs, making the full transformation graph opaque without manual archaeology.

Most SSIS estates were inherited rather than chosen. The teams running them have a clear mandate to migrate but a justifiable hesitation about the cost. New analytics projects rarely start on SSIS in 2026. The problem is the existing estate, holding the reporting, finance close, and regulatory feeds that the business runs on.

Why dbt Is the Target

The case for dbt as the migration target is well-established by 2026. dbt’s transformation model (modular SQL with Jinja templating, version-controlled, test-driven, materialized into a configurable warehouse) inverts every pain point of SSIS. The dbt ecosystem (lineage tools, semantic layer, materialization options, the recently-GA Fusion engine, the Power User VS Code extension) means the migration investment compounds over time rather than locking the team into another proprietary tool.

The underlying warehouse migration (typically from on-premises SQL Server to Snowflake, Databricks, or BigQuery) is usually scoped alongside the SSIS-to-dbt translation. The combination delivers both modernized transformation logic and modernized compute, which materially reduces total cost of ownership against the on-premises SQL Server estate.

The strategic point is that lift-and-shift translation is the wrong goal. The right goal is rebuild-and-modernize, with the dbt project layout (staging, intermediate, marts) explicitly designed to be more maintainable than the SSIS originals. The agent makes the rebuild affordable enough that this becomes the practical default.

The Traditional Migration Playbook

For context on what the new pattern is replacing, the traditional consulting playbook runs through four phases.

Discovery phase (weeks 1 to 4). A senior consultant reads every SSIS package. The output is a spreadsheet cataloging source connections, transformations, target tables, and dependencies for each package. A typical senior engineer working manually clocks 5 to 10 packages per week.

Translation phase (weeks 5 to 16). A senior engineer rewrites each package as dbt models. Staging models for raw extracts. Intermediate models for transformation steps. Mart models for final outputs. A senior engineer clocks 3 to 5 packages per week including testing.

Validation phase (weeks 17 to 22). The team runs the new dbt models against historical SSIS output, compares row counts and key aggregates, and chases the diffs. This phase usually runs longer than estimated because subtle SSIS behaviors (timezone handling, null semantics, type conversions) surface only on real data.

Cutover phase (weeks 23 to 26). Downstream consumers (BI dashboards, downstream SQL Server processes, external feeds) get switched from SSIS to dbt. SSIS packages get decommissioned in phases.

Total: six months. Total cost for a 50-package estate at typical consultancy rates: $200,000 to $300,000.

What the Agentic Harness Pattern Changes

The harness compresses three of the four phases dramatically.

1. Discovery becomes minutes. Altimate Code’s harness can parse SSIS XML deterministically. The parser walks the package XML, extracts every dataflow, every source-destination mapping, every transformation step, and outputs a structured representation of the package’s logical content. There is no LLM in this layer. The output is correct by construction.

   A 10-package estate gets parsed in well under an hour. The output is a machine-readable catalog of every transformation, ready for the translation phase.

2. Translation becomes prompt-driven. Given the structured representation from the parser, the LLM writes corresponding dbt models. The harness routes the LLM through schema introspection of the target warehouse (so the model’s column names match the actual Snowflake or Databricks tables), through dialect translation rules (T-SQL constructs converted to the target dialect using rule-based templates), and through anti-pattern detection (catching common translation errors before they ship).

   The output is dbt models that compile, follow the standard staging-intermediate-marts layout, and include preliminary not_null and unique tests on primary keys. Quality is good but not perfect. Edge cases require human review.

3. Parity validation becomes deterministic. This is the phase that consumes the most consulting budget under the traditional pattern. The harness collapses it dramatically by running HashDiff or JoinDiff between the SSIS output and the new dbt output. Same data, row-for-row comparison via columnar hashing. Mismatches are flagged with the specific columns and rows that diverge.

   The engineer then either fixes the dbt model (if the diff reveals a translation bug) or annotates the difference as expected (if the diff reflects an intentional modernization such as a timezone correction or dedup change).

4. Cutover remains a human decision. No harness automates the conversation with downstream stakeholders about cutover timing. This is unchanged.

A Weekend Walkthrough on a Real Package

Consider a representative 10-table SSIS package: a financial reporting dataflow. Source tables in SQL Server. Target tables in Snowflake. Five staging extracts, three intermediate transformations, two final aggregates feeding a Power BI dashboard. This is the shape of work that consumes a four-week senior engineer sprint under the traditional pattern.

1. Saturday morning (1 to 2 hours). Install Altimate Code via npm install -g altimate-code. Point the harness at the SSIS package XML and the target Snowflake schema. The CLI command is roughly altimate-code migrate --source ssis://path/to/package.dtsx --target snowflake://schema --output dbt/. The harness parses the XML in seconds and emits a starter dbt project: dbt_project.yml, a profiles.yml template, source declarations under models/staging/sources.yml, five staging models, three intermediate models, two mart models, and an initial schema.yml with primary-key tests.

2. Saturday afternoon (3 to 4 hours). Run dbt build against a dev Snowflake schema. Most models build clean. Two fail on column-name mismatches because the SSIS package referenced source columns by a logical name and the actual Snowflake table uses the physical name (cust_key vs customer_key is the canonical example). One prompt resolves it: “Look up the actual column name for the customer key in the source table and update the staging models.” The agent invokes schema introspection, finds the actual name, updates the model, re-runs.

3. Sunday morning (3 to 4 hours). Run parity validation. altimate-code diff --left-source ssis-output --right-source dbt-output --keys order_id. The HashDiff report comes back: two marts match exactly, one mart has a 0.3 percent row difference. Drill in. The diff is due to a timezone conversion in the original SSIS package that the agent’s first translation missed because the SSIS XML did not explicitly mark it as a timezone operation. Fix by adding an explicit CONVERT_TIMEZONE call to the intermediate model. Re-run the diff. It clears.

4. Sunday afternoon (2 to 3 hours). Cleanup pass. The SSIS-generated column names are unreadable (COL_1, Out_3). Prompt the agent to rename them based on source semantics. Generate dbt model documentation using the AI doc generator (Power User integrates this directly into VS Code). Add relationship tests between dim and fact models. Commit to git.

5. Monday morning (2 hours). Open a pull request. Review with the original SSIS package author to confirm semantic equivalence. Address feedback. Merge. Cutover the Power BI dashboard data source from SSIS output to dbt output.

Total elapsed time: a weekend plus one morning. Total cost: one engineer’s time plus a few hundred dollars of LLM API spend. Replicate this pattern across 50 packages by parallelizing agent runs across two or three engineers and a 50-package estate completes in three to four weeks instead of six months.

What Still Requires Senior Judgment

The harness does not eliminate the need for senior engineering review. Three categories of work still require human-led decision-making.

Business logic that lives in stored procedures the agent cannot trace. If the SSIS dataflow calls a SQL Server stored procedure that does the real business calculation, the parser will identify the call but the dbt translation has to reimplement the stored procedure’s logic. The LLM can draft the reimplementation but a senior engineer should review it because business rules embedded in stored procedures often have historical context that is not obvious from the code.

T-SQL constructs without clean target-dialect equivalents. CROSS APPLY semantics, table-valued parameters, certain XML functions, MERGE syntax variants. The harness’s dialect translation rules cover the common cases. Edge cases get flagged for human review. A senior engineer decides whether the right translation is an in-line rewrite, a refactor to a different SQL shape, or a feature deferred to a later release.

Semantic layer translation. If the SSIS package was feeding a Cognos, Tableau, or Power BI model with nested business definitions (revenue recognition logic, customer segmentation rules, organizational hierarchies), the dbt rewrite needs to also produce a semantic layer (MetricFlow definitions, Cube models, or equivalent) that preserves the business meaning. The agent assists. The semantic layer design remains a human responsibility because it codifies business judgment that the SSIS XML does not capture.

Downstream coordination. Renaming a column requires updating every consumer: BI dashboards, downstream SQL Server processes, external feeds, regulatory reports. The agent does not know about those consumers unless explicitly briefed. Coordinate downstream changes manually.

The Economics in Detail

A 50-package SSIS estate represents the typical mid-market target. Traditional cost analysis: six months at $40,000 per month per senior consultant times two consultants (the standard staffing model) plus oversight and PM overhead = $200,000 to $300,000 total.

Agentic harness pattern cost analysis: three to four weeks of two senior internal engineers at internal cost rates of roughly $1,500 per day fully loaded = $45,000 to $60,000 total engineer cost. Plus Altimate Code Pro seats at $29 per seat per month, negligible at this scale. Plus LLM API costs at approximately $500 to $2,000 for the full project depending on package complexity and the model provider.

Net total: $50,000 to $65,000 versus $200,000 to $300,000. Cost reduction: 75 to 80 percent. Time reduction: 5x to 8x.

Quality outcomes are comparable or better because the parity validation is deterministic rather than sampled. Traditional consulting engagements typically validate by spot-checking key aggregates, which catches gross errors but misses subtle row-level discrepancies. HashDiff catches the row-level discrepancies that traditional validation misses.

The economic case is structural, not promotional. Engineering teams with significant SSIS estates should be running this analysis on their own books.

What This Means for the Legacy Data Modernization Market

The migration consulting market in data engineering has been one of the most profitable verticals in IT services for two decades. SSIS modernization specifically represents an estimated $2 to $4 billion annual market depending on how broadly “legacy ETL modernization” gets defined. The standard pricing model (multi-month engagements, senior-staffed teams, time-and-materials billing) is dependent on the labor-intensive nature of the work.

Agentic harness tooling reshapes the unit economics. Engagements that consumed four months of senior staff time can complete in three weeks with one to two engineers. The total addressable market does not shrink, but the revenue per engagement compresses substantially. Consultancies that adopt the harness pattern early will outbid traditional consultancies on the same work. Consultancies that do not adopt will lose deals on price.

For Fortune 500 customers, the practical effect is that SSIS modernization is no longer a board-level capital project. It is a quarterly engineering initiative. Backlogs that have sat for years because the migration estimate was too expensive are now economically tractable. Expect substantial throughput in this category through 2027 as customers realize the math has changed.

The Engineering Recommendation

For organizations with existing SSIS estates and an active modernization mandate, the right move is straightforward. Pull the latest Altimate Code. Pick one package, preferably a non-critical one for initial calibration. Run the parse-translate-validate loop end to end. Compare the time and cost to your incumbent consultant estimate.

Most teams complete this exercise within a week of senior engineer time and conclude that the harness pattern is the correct default for their full estate. The harder organizational question is then about consulting contract relationships, internal team capacity, and stakeholder coordination on cutover timing. None of those are technology problems.

The six-month consulting migration for SSIS estates is over. The new shape is a weekend project per package, with senior engineering review in the loop and deterministic parity validation at the end. Legacy ETL is finally getting unstuck.

The discourse on AI coding agents has converged on a comfortable narrative: the next model release will close the remaining gaps. Claude 4.7 will be better than 4.6. GPT-5.2 will be better than 5.1. The 70-percent benchmark scores will become 80-percent scores.

For domains with verifiable ground truth, that narrative is incomplete. Foundation model improvements have been compounding at roughly 5 to 10 percentage points per major release on canonical benchmarks. Domain-specific tooling improvements have been compounding at 25 to 35 percentage points on the same benchmarks. The model is the multiplier. The harness is the variable.

The most instructive way to see this gap is on a real production codebase. Below is a structured comparison of Claude Code and Altimate Code on a representative 200-model dbt project, both running on top of Claude Sonnet, both given identical prompts. The differences are not theoretical.

The Test Codebase

The test ran against a 200-model dbt project representative of a mid-stage B2B SaaS analytics stack. Three-tier organization: staging, intermediate, marts. Forty custom macros. Snowflake backend. Active in production with a real warehouse, real downstream BI consumers, and real lineage that crosses three dbt projects via dbt Mesh.

The prompt given to both agents was a standard request that an analytics engineer would receive in a Tuesday standup:

“Add a new mart called fct_customer_health_score that combines order frequency, support ticket count, and NPS into a single score. Include tests.”

Both agents had read access to the dbt project, write access to the SQL and YAML files, and the ability to run dbt build to verify their output. The prompt allowed multi-step execution and gave the agents authority to refactor adjacent models if needed.

Claude Code, Naked

Claude Code produced a working fct_customer_health_score.sql model on the first attempt. The model compiled. The downstream dbt build ran green. The schema.yml entry included not_null and unique tests on the primary key. On surface inspection the work looked complete.

Detailed review surfaced four failure modes characteristic of generalist agents operating on production data.

1. Phantom column reference. The model joined to support_tickets.priority_level. No such column exists in the source. The actual column is priority. Claude inferred a more “obvious” column name from the join context, the warehouse accepted the SQL because the joined CTE happened to alias the column lazily, and the join silently returned null for every row. Every customer in the resulting fact had a health score that ignored support priority. The downstream dashboard would look correct and be wrong.

2. Silent wrong join. The model joined orders to customers on customer_id. Both tables have that column name. The values are semantically incompatible: orders.customer_id stores the external Stripe customer ID as varchar, customers.customer_id stores the internal numeric ID as integer. The join compiled because of implicit type coercion. About 80 percent of resulting rows contained incorrect data because most external IDs match by coincidence on integer parsing of the leading digits.

3. Tests that did not catch the bugs. The auto-generated not_null and unique tests passed. Neither would have caught the phantom column or the silent wrong join. No relationships test linked the fact’s customer_id to the customer dimension. No row-count regression test compared output volume against historical norms. No accepted_values test validated the score range.

4. Destructive operation proposed without lineage check. A follow-up prompt asking to “clean up the staging models that feed this fact” produced a recommended DROP TABLE IF EXISTS against stg_orders_raw. The staging table is depended on by two other marts. Claude Code did not know that because the lineage was not in its context. With auto-execute enabled in the IDE, the DROP would have run.

Altimate Code, Same Task

Altimate Code received the identical prompt against the identical codebase, running on the same Claude Sonnet backend. The behavioral differences map directly to the deterministic harness layer.

1. Schema introspection before SQL generation. Before composing any model SQL, Altimate’s harness invoked a schema-fingerprint scan against the source tables. The scan returned the actual column names with their types. The first-draft model used priority, not priority_level, because the LLM had ground-truth schema in context rather than inferred guesses.

2. Lineage-aware change recommendations. When the follow-up prompt requested cleanup of staging models, Altimate’s harness ran a blast-radius analysis against the lineage graph. The output enumerated every downstream model touching the staging table targeted for cleanup, including the two marts that depend on it. The agent surfaced the dependency as a confirmation requirement before any destructive operation could execute.

3. Type-aware join validation. When the model SQL referenced orders.customer_id = customers.customer_id, the harness invoked a type-checking tool that compared column types across the join. The check returned a warning that orders.customer_id is varchar and customers.customer_id is integer, with a recommendation to cast both sides explicitly or join on a verified bridge column. The corrected SQL used the proper foreign key with appropriate casting.

4. Test generation grounded in lineage. The auto-generated test suite included a relationships test linking the fact’s customer_id to the customer dimension, a row-count guard comparing output volume to a historical baseline, and an accepted_values test bounding the score range to a valid window. These tests would have caught the failure modes that Claude Code’s tests missed.

The output is meaningfully different. Both agents used the same LLM. The variable is the deterministic tooling layer wrapping the LLM.

The Architecture Behind the Difference

Altimate Code’s published architecture is a three-layer stack.

1. The top layer is the probabilistic agent: the LLM that plans, generates, and integrates.

2. The middle layer is the deterministic harness in TypeScript: the agent dispatcher, skill prescriptions, dialect-aware helpers, and the tool routing system.

3. The bottom layer is the deterministic core in Rust: 34 SQL operations as pure functions covering parsing, validation, transpilation, equivalence checking, and lineage extraction.

The architectural insight is that LLM reasoning and deterministic verification are different operations and should be implemented in different layers. When the agent needs to know whether a column exists, it does not ask the LLM. It calls the schema-introspection tool, which returns a correct answer in milliseconds. When the agent proposes a SQL rewrite, the harness invokes the equivalence-checking engine before suggesting the rewrite to the user.

This separation explains the benchmark gap. On ADE-Bench, dbt Labs’ analytics-engineering agent benchmark, Altimate Code reports 74.4 percent. The nearest specialized competitor reports approximately 65 percent. General-purpose agents on the same task surface land in the 40 percent range. The 35-point gap is not a model gap. It is a tooling gap.

On DAB-Bench, the multi-database benchmark Altimate published alongside Altimate Code, the harness reports 60.4 percent against a baseline of 30 to 40 percent for general agents. The lower absolute number reflects the harder nature of cross-warehouse tasks. The relative gap remains substantial.

For context, Snowflake’s own Cortex Analyst, the in-warehouse text-to-SQL agent, was reported by Altimate to achieve 38 percent logical accuracy on their internal benchmark. The published numbers from Snowflake position Cortex Analyst as conversational analytics, not engineering-grade SQL generation. The architectural choice (in-warehouse, single-vendor, schema-grounded against a semantic model) optimizes for a different use case than agentic dbt development.

What “Agentic Harness” Actually Means

The word “agentic” has been overloaded by 2026. A precise definition matters for evaluating tools.

An agentic harness is a system where an LLM plans, calls tools that return ground-truth answers, observes the outcomes, and iterates without human approval on each intermediate step. The harness is the layer of deterministic tooling and orchestration logic surrounding the LLM. The LLM provides strategy. The harness provides verification.

For SQL work specifically, the deterministic tools that matter are schema introspection, column-level lineage, AST parsing and manipulation, dialect translation with rule-based correctness, equivalence checking across query rewrites, anti-pattern detection, PII scanning, and row-level diffing between candidate outputs.

Altimate Code ships more than 100 such tools. Each is callable by the LLM during a task. When the agent encounters uncertainty, it invokes a tool. When a tool flags a problem, the agent rewrites. The orchestration is the product. The LLM is interchangeable.

The interchangeability matters. Altimate Code supports Anthropic, OpenAI, Google, AWS Bedrock, Azure, Ollama, OpenRouter, Mistral, Groq, xAI, and local models. The same harness improves all of them. A cheaper model with the harness outperforms a more expensive model without one. This is consistent with the published thesis from Altimate that “the model is not the bottleneck, the harness is.”

Where the Harness Thesis Generalizes

The pattern is not specific to SQL. Any domain with a verifiable substrate benefits from the same architectural pattern: probabilistic strategy on top, deterministic verification underneath.

• Type systems in TypeScript or Rust qualify. The compiler is the harness. LLMs integrated with tsc or rust-analyzer ship better code than LLMs operating on the source text alone.

• Financial modeling qualifies. Spreadsheet equations have ground truth. LLMs that can call a deterministic spreadsheet engine before suggesting changes produce fewer wrong numbers.

• Infrastructure as code qualifies. Terraform plans are deterministic. Agents that can terraform plan before suggesting changes produce safer outputs.

• Healthcare claims qualify. ICD codes, billing rules, formulary checks are all deterministic. Wrapping an LLM around those tools changes outcomes.

In each case the same principle applies: the LLM provides strategy, the deterministic engine provides truth, the combination outperforms either alone. Altimate is the canonical example in the data engineering vertical.

What This Changes for Engineering Teams

The practical implication for teams choosing AI tooling in 2026 is that benchmark selection matters more than model selection. The question to ask vendors is not “which model do you use?” but “what deterministic tools wrap your LLM, and what is the benchmark performance on tasks like ours?”

Five filter questions sort productive vendors from marketing-led ones.

1. What deterministic tools does the system ship with? A vendor that cannot enumerate their tool set has not built a real harness.

2. How does the system handle LLM uncertainty? A vendor that returns the LLM’s best guess without verification is shipping a wrapper, not a harness.

3. What happens when the LLM proposes something demonstrably wrong? A vendor whose system silently propagates LLM errors is unsafe for production data.

4. Can the customer bring their own LLM? A vendor locked to a single model provider creates portability risk.

5. What is the published benchmark performance on tasks representative of the customer’s workload? A vendor without benchmarks has not measured itself rigorously.

Altimate Code passes all five filters. Most “AI for data” products today do not.

How Teams Are Actually Adopting the Pattern

The adoption pattern observed across mid-market data teams in 2026 is not “rip and replace.” Most teams continue using Claude Code or Cursor for general engineering work. The agentic harness gets deployed specifically for production data work where the cost of silent errors is high.

For teams evaluating the pattern, the practical first step is small. Install Altimate Code alongside the existing Claude Code workflow. Use it on one production dbt PR. Compare the output to what Claude Code alone would have produced. The gap is the value.

The Strategic Takeaway

The competitive frame for AI coding agents in 2026 is shifting from model performance to domain coverage. Generalist agents will remain useful for the broad surface of software engineering. Domain-specialized harnesses will dominate verticals where ground truth exists and silent errors are expensive.

Data engineering is the canonical vertical. SQL has ground truth. Schema is verifiable. Lineage is deterministic. The cost of a silent wrong join making it to production runs from “stakeholder embarrassment” through “incorrect financial reporting” to “regulatory action.” That cost curve is what makes the harness investment economical.

Altimate Code is the most credible specialized harness shipping today. The benchmark gap is real. The architecture is sound. The market position is defensible as long as the gap persists.

For data teams choosing AI tooling, the right move is not to wait for the next model release. The right move is to evaluate the harness layer. The next year of meaningful productivity gain in AI for data engineering will not come from larger models. It will come from better tooling around them.

The official dbt Labs VS Code extension launched into preview with a narrow promise: a first-party IDE experience for dbt Fusion. The bet is sound. Fusion is the Rust-based dbt engine that went GA at Coalesce 2025, and a first-party editor extension is overdue. The catch is that “Fusion-only” excludes the long tail of dbt Core, dbt Cloud, and the hybrid setups that almost every working data team runs in production.

That tail is where Power User for dbt has been operating for years.

Power User is the open-source VS Code extension shipped by Altimate AI, the same team that recently launched the agentic data-engineering harness Altimate Code. It has crossed 456,000 installs on the VS Code Marketplace, holds a 5.0 average across 48 reviews, and ships under MIT license. The repository on GitHub has 575 stars. The extension runs against dbt Core, dbt Cloud, and dbt Fusion, with full support for dbt 1.0 and above, devcontainers, codespaces, and remote workspaces.

That breadth is the first reason Power User has out-shipped the official extension. The second reason is the feature set, which now reads less like an IDE plugin and more like a thin productivity layer over the entire dbt development loop. Five capabilities account for most of the daily value.

Why the Extension Surface Matters in 2026

Before the feature walkthrough, a market note. dbt itself has moved from “a transformation tool” to “the integration surface for the modern data stack.” Power User reads manifest.json and turns the editor into a dbt-aware workspace. Cosmos reads the same manifest and turns Airflow into a dbt-aware orchestrator. Recce diffs dbt change sets. Datafold validates them. Altimate Code wraps them in an agentic harness. Every meaningful new data tool in 2026 either integrates with dbt or builds on dbt’s metadata graph.

In that landscape the IDE extension is no longer a nice-to-have. It is the surface where transformations get written, reviewed, and shipped. For analytics engineers, the editor is where 80 percent of their work lives. The extension that wins the IDE wins the daily workflow.

That framing explains the strategic position of Power User. It is the only extension that covers the full dbt market today.

Feature 1: Column-Level Lineage Inside the Editor

dbt Cloud’s Explorer surfaces column-level lineage through a separate web UI. Power User surfaces the same graph inside VS Code, directly above the model file being edited.

The technical mechanism is straightforward. Power User parses the dbt manifest, walks the SQL AST of every model, and resolves which output column derives from which input columns. Renaming a column triggers a graph view that highlights every downstream model touching that exact column. Type changes propagate through the same view.

The interaction shift is the point. Lineage that lives in a separate browser tab gets opened occasionally. Lineage that lives in the editor gets consulted on every rename, every type change, every refactor. The lineage tab has gone from a once-a-week safety check to a per-commit reflex.

Field observations from teams that have moved from dbt docs serve to Power User show measurable reductions in downstream-breaking PRs. The mechanism is friction: lineage that costs zero extra clicks is lineage that gets used.

Feature 2: Compiled Query Preview While Typing

dbt’s Jinja templating sits between what a developer writes and what the warehouse runs. The official dbt compile command resolves the templating into raw SQL and writes it to target/compiled/. Anyone who has chased a macro bug knows the workflow: write, save, run dbt compile, open the compiled file, find the issue, repeat.

Power User collapses that loop into a live side-panel. Edit a model, the compiled SQL updates in real time. Change a Jinja variable, the resolved value appears. Toggle an if block, the compiled output adapts. A multi-macro CTE chain that previously took three iterations of compile-and-inspect now reveals itself instantly.

The productivity impact compounds in proportion to macro depth. Projects with shallow Jinja get marginal gains. Projects with deep macro hierarchies, the kind common in mature analytics-engineering teams, get back hours per developer per week. For a data team of ten, that is a measurable line item on the quarterly plan.

Feature 3: Native Query Execution and Results

The Power User gutter exposes a Run button on every model file. The query executes against the configured warehouse adapter, and results land in a VS Code results pane with sorting, filtering, CSV export, and basic charting.

That last capability deserves emphasis. The charting integration covers grouped bar, time-series line, and pie views, configured through a sidebar without writing visualization code. For exploratory analytics work the practical effect is that a quick “weekly active users by region” check no longer requires opening a BI tool. The query runs inside the editor and the chart renders within seconds.

This is the consolidation pattern that drives extension stickiness. Removing the need to context-switch to a separate warehouse UI for the 70 percent of queries that are exploratory removes a friction point that the rest of the modern stack has not yet eliminated.

Feature 4: AI-Generated Documentation as a First Draft

Power User ships an AI documentation generator that writes the first draft of model and column docstrings directly into schema.yml. The generator reads the model SQL, the upstream lineage, the source declarations, and any existing documentation context, then writes structured descriptions that match dbt’s documentation schema.

The model is configurable in two dimensions. Persona selects the audience: technical (for engineering reference), business (for stakeholder consumption), or general (default). Language supports English, French, Dutch, and German. The output is committed straight into the YAML files where dbt expects it.

Output quality on representative models lands in a usable first-draft range. Standard dimensions and facts where naming follows conventional patterns produce documentation that requires light editing. Business-critical metrics with company-specific definitions need human revision because the AI cannot infer revenue recognition policies or fiscal calendars from SQL alone.

The economic case is straightforward. A dbt project of 200 models with an average of 20 columns has 4,000 columns to document. At two minutes per column of human time, that is roughly 130 hours of documentation backlog. The AI generator cuts that to a review-and-edit workflow that completes in days, not months. Documentation backlogs are why most dbt projects have stale schema.yml files. Closing that gap matters.

Feature 5: The Embedded MCP Server

Power User ships with an embedded Model Context Protocol server. MCP is the open protocol Anthropic introduced in 2024 for connecting LLMs to external tools, and it has been adopted across Claude Code, Cursor, Windsurf, OpenAI’s agent SDK, and most modern data tooling.

The practical implication is large. A Claude Code session pointed at a dbt project without the MCP server has to discover the project structure by reading files, which is approximate and prone to hallucinated table names. The same Claude Code session connected to Power User’s MCP server can invoke the extension’s lineage tool, schema lookup, compile-and-run, and test-execution tools directly. The agent gets ground-truth answers from the same code that the IDE uses, with no guessing.

For teams running agentic workflows on dbt projects, this is the missing layer between “AI in the editor” and “AI that understands the dbt graph.” Without an MCP-enabled extension, the agent’s view of the project is a guess. With one, the agent’s view matches the IDE’s view, which matches the warehouse.

Power User vs the Official dbt VS Code Extension

The official dbt Labs VS Code extension is a real product and will improve. Today the comparison sits roughly as follows.

The competitive frame is not that Power User wins forever. The competitive frame is that Power User is the only mature option today and will retain that position as long as the official extension stays Fusion-only and lags on lineage and AI features. For organizations choosing a dbt IDE in mid-2026, Power User is the rational default.

The Pricing Model

Power User runs on a freemium credit model. The free community tier exposes the full feature surface. AI-powered features (documentation generation, query optimization suggestions, governance scans) consume credits. New free accounts get 10 million tokens at signup, sufficient for exploratory use on a single project.

Pro is $29 per seat per month, with 20 million tokens included monthly. Enterprise is custom and includes single sign-on, custom token quotas, and dedicated support. Most engineering teams qualify the Pro tier as a small line item against the productivity gains.

The credit-based model is worth noting because it differs from the per-seat-only pricing of older dbt productivity tools. Credits scale with usage, not with team size, which means a four-person analytics team with heavy doc-generation workload can predict cost accurately.

What Mature Teams Are Asking For Next

Conversations with practitioners suggest two extensions to the current feature surface that would expand adoption further.

Deeper test intelligence. The extension already generates dbt tests, including unit tests added in dbt 1.8. Surfacing missing tests proactively, with suggestions like “this model has no unique test on the primary key, add one?” would close a known gap in test coverage on most projects.

Persistent in-editor dashboards. The query result charting is functional but ephemeral. Pinning a chart to a personal dashboard that survives across sessions would convert exploratory analysis into a durable artifact and reduce the need for a separate BI tool for personal-use dashboards.

Both extensions are in line with the trajectory of the product. Neither is required for the extension to be the right choice today.

The Verdict for Data Engineering Teams

For analytics engineers and data engineers running dbt on Core, Cloud, or Fusion, Power User is the right install in 2026. The free tier is sufficient for the majority of use cases. The Pro tier pays for itself in the documentation workload alone. The MCP server is the strategic feature that ages best as agentic workflows become the dominant interface for data work.

The official dbt Labs extension will improve. Until it catches Power User on Core support, column-level lineage, and MCP integration, the productivity argument runs one direction. Install Power User. Point it at a project. Close the four other tabs that used to be required to do dbt work properly.

If you’re a solo developer advocate drowning in launch checklists, community threads, and “can you also write the blog post?” requests, this is for you.

If you’re a Head of DevRel trying to prove ROI to a leadership team that thinks your job is “posting on Twitter,” this is for you.

If you’re an engineering manager who just got handed DevRel responsibilities with zero playbook and zero budget for consultants, this is for you.

If you’re a startup founder who knows you need developer relations but can’t justify a full-time hire yet, this is for you.

I built 10x DevRel for all of you. Here’s why, and here’s every decision I made along the way.

The Problem I Couldn’t Stop Seeing

I spent six years in the DevRel orbit. And I kept watching the same painful loop play out.

A new developer advocate joins a company. Day one, they’re excited. Day three, they ask: “Is there a playbook for how we do launches?” The answer is always some version of: “Check with Sarah. She had a doc somewhere. I think it’s in the old Notion.” Sarah left eight months ago. The doc is gone.

So the new advocate builds their own system from scratch. They Google “DevRel launch checklist.” They find a 2019 blog post with generic advice. They ask in the DevRel Collective Slack. Someone shares a personal template. They cobble together something that works for one launch.

Then they leave, and the next person starts the cycle over.

This isn’t a knowledge problem. It’s a systems problem. The knowledge exists. It’s scattered across hundreds of blog posts, conference talks, podcast episodes, and private Notion docs that die when people change jobs.

I kept a list of every repeated question I heard. After a year, that list had 200+ entries. They clustered into about 15 categories. And I realized something that changed everything for me: these categories are the actual operating system of DevRel. Product launches. Community building. Content strategy. Metrics. Onboarding. Crisis communication. Demo engineering. Feedback loops. Conference talks. Hackathons. Open source. Advocacy. Ambassador programs. Technical writing. AI-assisted workflows.

Every DevRel team runs on some subset of these categories. None of them had a standardized, research-backed playbook. Until now.

Why I Didn’t Build Another SaaS

My first instinct was the obvious one. Build a platform. Dashboards. User accounts. Monthly pricing. Integrations. The standard startup playbook.

I killed that idea fast. Here’s the thinking.

The people who need this most can’t pay for it. The solo advocate at a 30-person startup. The community manager who just got “DevRel” added to their title. The developer-first founder running a one-person go-to-market motion. These people have $0 in personal tooling budget and the most urgent need for structured frameworks.

DevRel people don’t need another platform. They’re already managing Slack, Discord, GitHub, Twitter, LinkedIn, dev.to, their blog CMS, their analytics dashboard, their community platform, and their company’s internal tools. Adding another login is the opposite of helpful.

The value is in the thinking, not the software. A well-structured playbook for running a product launch is worth more than a Gantt chart tool that doesn’t understand what a launch DRI is. The frameworks are the product. The software just makes them accessible.

So I made the workbench free and community-driven through the website - contributions are welcome there, with public credit for approved contributors. This was the first and most important decision.

Building the 15 Playbooks

Each playbook took weeks. Not because writing is hard. Because getting the framework right is hard.

Take the Product Launch Playbook. The first draft had 45 steps. Too many. A playbook that nobody finishes is useless. I cut it to the essential sequence: T-30 through post-launch, with every step earning its place through a simple test: “If you skip this, does the launch meaningfully suffer?”

The Community Building Playbook went through four iterations. Version one was too tactical (just a list of tactics). Version two was too strategic (all theory, no steps). Version three found the right level: a staged approach where each stage builds on the previous one, with concrete actions at each stage and the reasoning behind them.

The DevRel Metrics & ROI Playbook was the hardest. Metrics in DevRel are genuinely difficult. Attribution is messy. The developer journey is non-linear. Leadership wants revenue numbers, and the path from “attended our conference talk” to “became a paying customer” has fifteen steps with no clean tracking. I spent weeks on attribution models that are honest about their limitations while still being useful enough to justify budget.

Every playbook has interactive checklists. You open a playbook, start checking off steps, and your progress saves locally. Come back tomorrow and pick up where you left off. Reset when you want to run the playbook again for your next launch, your next community initiative, your next content cycle.

You can bookmark any playbook to your personal collection. You can share a playbook link with your team. You can take the framework and adapt it to your organization, your product, your stage.

Here’s what the 15 playbooks cover:

1. Product Launch — T-30 to post-launch with DRI mapping

2. Community Building — Designing communities that sustain themselves

3. Developer Content Strategy — Building a content engine, not a blog

4. Technical Writing — Docs developers actually read

5. Developer Onboarding — First-run experiences that convert

6. Developer Feedback Loop — Systematic feedback pipeline

7. DevRel Metrics & ROI — Proving business impact in leadership language

8. Conference Talk — CFP through post-talk amplification

9. Hackathon — Running hackathons that generate signal

10. Open Source Community — Contributor pipelines and governance

11. Developer Advocacy — Building advocacy programs from scratch

12. Developer Ambassador Program — Community-led advocacy at scale

13. Demo Engineering — Demos that convert developers

14. Crisis Communication — Communicating when things break

15. AI-Assisted DevRel — Using AI to scale without scaling headcount

The AI Tools Decision

Playbooks solve “what should I do.” They don’t solve “this still takes forever.”

A developer advocate who knows exactly how to repurpose a blog post into six channel-specific pieces still has to actually do all that repurposing. For every piece of content. Every week. That’s hours of mechanical work that scales linearly with output.

I built four AI tools, each one targeting the highest-frequency, most time-consuming mechanical task in its category.

Launch Checklist — Paste a changelog entry or feature description. Get a complete launch plan with task categories, DRI suggestions, and timeline markers. What takes 3 hours manually takes 30 seconds to generate, then 15 minutes to customize. If you’re a DevRel team that launches twice a month, that’s 72 hours per year recovered.

Demo Run-of-Show — Describe your demo and audience. Get a timed script with segment-by-segment talking points, transition cues, and a fallback matrix for when live demos break. No more standing on stage saying “it usually works, let me try again.”

Content Repurposing — Paste a blog post. Get six channel-specific adaptations: Twitter thread, LinkedIn post, newsletter segment, video script outline, community discussion prompt, and Hacker News submission. Not copy-paste. Actual platform-native adaptation.

Demo to Distribution — Describe a recorded demo. Get the complete distribution package: social posts, blog outline, email announcement, community thread, and changelog entry. One demo becomes a full launch cycle.

Every tool runs on your own API key. Claude, Gemini, or GPT. You pick. Your data goes directly to the AI provider you chose. Nothing is stored on my servers. No vendor lock-in. Switch providers any time.

I had strong opinions about this. The DevRel community doesn’t need another tool that holds their data hostage. Bring your own key. Control your own workflow.

The Resource Library and Community

Playbooks and AI tools needed connective tissue. When a playbook says “identify target conferences,” you need to know which conferences. When it says “set up community feedback channels,” you need to know which tools exist.

So I curated 200+ resources across six categories: Developer Events, Communities, Learning, Tools & Platforms, Strategy & Metrics, and Reference materials. Every resource is tagged, searchable, and filterable. Not a link dump. A library where every entry earns its place.

Then I built the Community section. Two tabs: Best Practices and Resources. Anyone can submit. Submissions go through moderation. Approved contributions show a Contributor Badge with the submitter’s profile, organization, and social links. You get credit for what you share.

The community section is where the workbench becomes a living resource. The playbooks are curated by me. The community is curated by everyone using it.

What I Got Wrong (And Fixed)

Book preview was too long. The first version showed four chapters of The DevRel Guide as a preview. Overwhelming. I cut it to Chapter 1 only with an accordion layout. Engagement went up.

Testimonial design felt generic. Plain cards with text. I added gold borders, amber star ratings, and stronger visual hierarchy. Small change. Big trust impact.

General AI chatbot underperformed. I built Aria, a DevRel Q&A chatbot. It works, but it’s still in beta. The four scoped AI tools that solve one specific problem each outperform the general assistant by a wide margin. Lesson: specificity beats generality in AI tooling.

Community design took three iterations. Too simple, then too complex, then right. The two-tab structure with moderation and contributor badges hit the sweet spot.

Who This Is Actually For (Be Honest with Yourself)

You should use 10x DevRel if:

• You’ve ever spent a Sunday night building a launch checklist from scratch

• You’ve ever been asked “what’s the ROI of DevRel?” and fumbled the answer

• You’ve ever written a great blog post and then only shared it on one platform because you ran out of time

• You’ve ever winged a demo without a script and watched it fall apart

• You’re running a one-person DevRel motion and feel like you’re drowning

• You’re leading a DevRel team and want your team operating on shared frameworks instead of tribal knowledge

• You’re an engineering manager who just got handed “developer relations” with no training

• You’re a founder who knows DevRel matters but can’t figure out where to start

The Book (Coming Q3 2026)

Everything in the workbench is free. The playbooks, the AI tools, the resources, the community. Free forever.

The DevRel Guide is the portable, comprehensive version. 400+ pages. 10 chapters. 15 templates. All 15 playbooks compiled with deeper frameworks, case studies, and examples you can adapt. Chapter 1 is free to read on the book page.

Early bird price is $29. Goes to $49 at launch. If the free workbench helps you ship one better launch, the book is where you go deep.

Leave a comment

Go Use It

10x DevRel is live. Everything is free. No signup required for playbooks or AI tools. Bookmark what you need. Track your progress through the checklists. Try the AI tools with your own API key. Join the community and share what works.

If a playbook helps you ship a better launch, run a better hackathon, or finally prove your DevRel ROI to leadership, tell one person about it. This field gets better when we stop reinventing wheels.

Open the 10x DevRel Workbench

You’re a developer advocate who just discovered this tool. Or maybe someone shared the link in your DevRel Slack. Or maybe you read the origin story last week and you want to see what’s actually inside.

This is the guided tour. Every page, every feature, every AI tool, every interaction pattern. By the end of this article, you’ll know exactly how the 10x DevRel Workbench fits into your daily workflow, and where to start.

Open the app in another tab and follow along. Everything I’m about to show you is free. No signup required.

The Homepage: Your Dashboard to Everything

The first thing you see when you land on 10xdevrel.atharvashah.com is the headline: “Everything a DevRel needs to ship faster.”

Below it, four stat cards that tell you exactly what’s inside:

• 15 Playbooks (research-backed frameworks)

• 4 AI Tools (instant output from your own API key)

• 200+ Resources (curated, tagged, and filterable)

• $29 Book (The DevRel Guide, coming Q3 2026)

Two primary CTAs: Browse Playbooks and Try AI Tools. No signup wall. No credit card. No “book a demo.” You click and you’re in.

The “Without / With” Section

Scroll down and you hit a comparison that will feel personal if you’ve been in DevRel for more than a month:

This isn’t marketing copy. These are the actual problems the workbench solves. Every one of them came from real DevRel practitioners describing their weekly pain.

Feature Previews, Playbook Grid, and Explore Section

Below the comparison, you’ll see screenshot previews of all four AI tools, then a grid of all 15 playbooks (each showing its category, title, step count, and estimated time), then the “Explore” section with four cards:

• Community — Share wins, ask questions, suggest tools, connect with other advocates

• Resource Center — 200+ curated resources across events, communities, learning, tools, strategy, and reference

• The DevRel Guide — The 240+ page book with deeper frameworks and templates

• DevRel AI (Aria) — A beta AI chatbot for quick DevRel questions

Three testimonials from DevRel practitioners close out the homepage.

Playbook Library: 15 Frameworks That Replace Tribal Knowledge

Navigate to /playbooks from the top nav. This is where the core value lives.

What You See

A searchable, filterable library of all 15 playbooks. Each card shows:

• Category badge (Launch, Community, Content, Events, Metrics, Onboarding, Feedback, Crisis, Demo)

• Title

• Step count (how many steps in the framework)

• Estimated completion time

You can search by keyword or filter by category using the tabs at the top. Looking for everything related to community? Click the Community filter and you’ll see the Community Building, Open Source, Developer Advocacy, and Ambassador Program playbooks grouped together.

The Full Playbook List

Launch & Demo:

• Product Launch Playbook — The complete T-30 to post-launch timeline. Every phase, every stakeholder, every deliverable, every DRI assignment.

• Demo Engineering Playbook — Build demos that convert developers. Timed scripts, fallback matrices, audience-specific framing.

Community & Advocacy:

• Community Building Playbook — Design communities that sustain themselves. Member journeys, engagement loops, moderation, growth mechanics.

• Open Source Community Playbook — Contributor pipelines, governance structures, maintainer health. The specific dynamics of open source.

• Developer Advocacy Playbook — Build advocacy programs from scratch. Positioning, outreach, content, measurement.

• Developer Ambassador Program Playbook — Community-led advocacy at scale. Recruiting, onboarding, activating, retaining ambassadors.

Content & Communication:

• Developer Content Strategy Playbook — Build a content engine. Prioritization, production systems, distribution.

• Technical Writing Playbook — Write docs developers actually read. Structure, voice, code sample testing.

• Developer Crisis Communication Playbook — What to say when everything breaks. Templates, escalation paths, post-mortems.

Operations & Measurement:

• Developer Onboarding Playbook — Design first-run experiences that convert. Speed to first success.

• Developer Feedback Loop Playbook — Systematic feedback pipeline. Collection, routing, closing the loop.

• DevRel Metrics & ROI Playbook — Prove business impact. The frameworks that justify your budget.

Events:

• Conference Talk Playbook — CFP through post-talk amplification. The full lifecycle.

• Hackathon Playbook — Run hackathons that generate real signal, not just swag.

AI:

• AI-Assisted DevRel Playbook — Scale DevRel output with AI without losing the human touch.

Inside a Playbook: The Interactive Experience

Click into any playbook and here’s what you get:

Step-by-step framework. Numbered steps with expandable substeps. Each step has the action, the reasoning behind it, and the specific deliverable. Not vague advice. Concrete actions.

Interactive checklist. Every step has a checkbox. Click it. It saves locally. Come back tomorrow, next week, next month. Your progress is right where you left it. A progress bar at the top shows how far through the playbook you are.

Reset button. Running the same playbook again for a new launch? Hit reset and start fresh.

Bookmark button. Sign in and bookmark any playbook. Your saved playbooks appear on your Bookmarks page for quick access. Building a custom collection of the playbooks you use most.

Share it. Every playbook has a clean URL. Copy it and share with your team. Your Head of DevRel wants a metrics framework? Send them the direct link to the Metrics playbook. Your new hire needs a launch guide? Send the Product Launch Playbook.

Make it yours. Each playbook is a framework, not a prescription. You adapt the steps to your product, your team size, your market. The AI-Assisted DevRel Playbook, for example, covers principles you can apply with any AI tool. The Community Building Playbook works whether your community is on Discord, Slack, or a forum.

Run the prompts against your own context. Many playbooks include questions and decision frameworks. Take those prompts. Feed them to Claude or GPT with your company’s context. Get answers specific to your organization, your product, your developer audience. The playbook gives you the right questions. AI gives you the specific answers.

AI Tools: Four Purpose-Built Workflows

Navigate to any AI tool from the top nav dropdown. Four tools. Four specific problems. Four instant outputs.

Setup (60 seconds, one time): Go to /settings/api-key. Enter your API key for Claude, Gemini, or GPT. That’s it. All four tools work immediately. Your key stays in your browser. Nothing goes to 10x DevRel servers.

Tool #1 - Launch Checklist

What the output looks like: Not a flat list. A structured plan with categories, subcategories, owner assignments, and dependency markers. Specific to what you’re actually launching. A minor SDK update gets a different plan than a major API version release.

What you do with it: Copy the plan. Paste it into your project management tool. Customize the DRI assignments for your team. Adjust timing. Execute.

Who this is for: Solo advocates who need to plan launches alone. DevRel leads who want consistent launch processes across the team. Engineering managers who just shipped a feature and need to figure out the go-to-market.

Tool #2 - Demo Run-of-Show

What the output includes:

• Timed segments: Introduction (2 min), Core Demo (12 min), Expansion (3 min), Q&A (3 min). Each segment has a time budget.

• Audience-specific talking points: Backend engineers get architecture depth. Product managers get workflow impact. Executives get strategic value.

• Fallback matrix: For every live element, a pre-recorded or static fallback. “If API call fails, switch to pre-recorded segment at timestamp 2:15.”

Who this is for: Anyone who presents product demos. Conference speakers. Sales engineers who also do DevRel. Developer advocates prepping for a customer-facing walkthrough.

Tool #3 - Content Repurposing

What you get:

• Twitter/X thread: Hook, numbered insights, conversational tone, link to full post

• LinkedIn post: Professional framing, personal angle, audience-specific hook

• Newsletter segment: Drop-in paragraph for your existing newsletter

• Video script outline: 3-5 minute script with sections and talking points

• Community discussion prompt: Open-ended question that invites participation, with context

• Hacker News submission: Technical, understated title and comment. HN-native tone.

Each output is adapted, not copy-pasted. Twitter gets hooks. LinkedIn gets professional framing. HN gets technical understatement.

Who this is for: Every DevRel professional who creates content. This is the single biggest time-saver in the workbench.

Tool #4 - Demo to Distribution

What you get: Blog post outline with section structure, social media posts for Twitter and LinkedIn, email announcement draft, community discussion thread, and a developer-friendly changelog entry. All from one demo description.

Who this is for: DevRel teams that record product demos and need to maximize their distribution. Solo advocates who record a walkthrough and want to turn it into a week of content.

Resource Center - 200+ Curated Resources

Navigate to /resources. A searchable, filterable library organized into six categories:

Each resource has a type badge (Event, Tool, Course, Article, Newsletter, Video, GitHub Repo, Book, Platform, Job Board), a description, and a direct link. Filter by category. Search by keyword. Every resource was selected because it connects to one or more playbooks.

When a playbook tells you to “identify target conferences,” the Resource Center has the conferences. When it tells you to “evaluate community platforms,” the Resource Center has the platforms. The playbooks are the framework. The resources are the building blocks.

Community: A Living, Curated Knowledge Base

Navigate to /community. Two tabs:

Best Practices tab: Community-submitted tips, frameworks, and lessons learned. Each has a title, description, category badge, and upvote count. Filter by category (Launch, Demo, Content, Community, DX, Events, Advocacy, Retrospective). Search by keyword.

Resources tab: Community-submitted links to tools, events, courses, and useful content. Same filtering and search.

How contribution works:

1. Click “Submit Suggestion” or “Suggest a Resource”

2. Fill in the form (title, description, category)

3. Your submission goes to a moderation queue

4. Once approved, it appears publicly with a Contributor Badge showing your profile, organization, and social links

Why this matters: The playbooks are curated by one person (me). The community section is curated by everyone. As more DevRel practitioners contribute, the knowledge base grows. Your specific insight about running hackathons at a 50-person startup, or your framework for crisis communication in open source, becomes part of the shared resource.

The DevRel Guide (Book)

Navigate to /book. This is the 240+ page companion guide launching Q3 2026.

10 chapters:

1. The DevRel Mindset

2. Product Launch Mastery

3. Community Architecture

4. Developer Onboarding

5. Content That Converts

6. AI-Augmented DevRel

7. Metrics & Attribution

8. Crisis Playbooks

9. Advocacy at Scale

10. The 10x DevRel Stack (200+ resources, templates, full playbook library)

Chapter 1 is free to read on the page. Expand each section with the accordion layout. If you like what you read, the early bird price is $29 (goes to $49 at launch). PDF + EPUB. Lifetime updates.

The relationship between the workbench and the book: The workbench is the free, living, interactive version. You use it daily. The book is the portable, deep version. You read it on a flight, reference it in a planning session, hand it to a new hire.

User Features That Make It Yours

Bookmarks. Sign in and bookmark any playbook or resource. Your /bookmarks page groups everything you’ve saved by type. Build your personal collection.

Profile. Set your avatar, view your account info at /profile.

Theme toggle. Switch between light and dark mode from the navbar.

Local progress tracking. Every playbook checklist saves progress locally. Works without an account. Persists across sessions.

No account required for core features. You can browse all 15 playbooks, use all 4 AI tools, explore all 200+ resources, and read Chapter 1 of the book without creating an account. Sign in to bookmark and contribute to the community.

The Technical Details (For Those Who Care)

Stack: React + TypeScript on Vite. Wouter router. shadcn/ui components (Radix + Tailwind CSS). tRPC backend with Drizzle ORM.

Design: OKLCH color system. Fraunces serif for display type. Inter for body text. Dark theme default.

Performance: All images compressed to WebP under 80KB. Lazy-loaded on scroll. AI tools rate-limited at 35 requests/day per user.

Where to Start (Your First 10 Minutes)

If you have 10 minutes right now, here’s your quickest path to value:

1. Open the Playbook Library. Find the playbook that matches your most urgent current project.

2. Read through the steps. Check off the ones you’ve already done. Note the ones you haven’t.

3. Try one AI tool. Go to AI Setup, enter your API key, then paste a recent blog post into the Content Repurposing tool. See six distribution pieces appear in 30 seconds.

4. Bookmark what you’ll use again. Sign in and save the playbooks and resources you’ll return to.

That’s it. No onboarding flow. No tutorial video. Open, explore, use.

Start exploring the 10x DevRel Workbench

Leave a comment

If you’re a DevRel leader who has inherited a team that operates on vibes and improvisation, this article is your blueprint for building a repeatable system.

If you’re a solo advocate who does everything and has a framework for nothing, this article gives you the sequence to follow.

If you’re an engineering manager who got handed DevRel with zero playbook, this is your onramp.

If you’re a startup founder who needs developer relations but can’t afford a team yet, this article shows you how to run a one-person DevRel motion using 15 battle-tested frameworks.

Most DevRel teams operate on a combination of instinct, urgency, and whatever the last person in the role figured out before they left. Someone writes a blog post when inspiration strikes. Someone else runs a hackathon because a competitor did one. Launches happen when engineering finishes the feature, not when the go-to-market plan is ready. Metrics get reported quarterly in a slide deck that nobody reads.

This is not a system. It’s a collection of activities that happen to share a Slack channel.

The 10x DevRel Workbench replaces that with something repeatable. 15 playbooks, organized into a framework that builds on itself. Not 15 random checklists. A sequence. Here’s how to use them, and why the order matters.

Layer #1 - The Foundation (Start Here, No Exceptions)

Before you write a single blog post, plan a single event, or build a single community channel, you need two things: metrics that tie to business outcomes, and a feedback loop that tells you what developers actually need.

DevRel Metrics & ROI Playbook

What it gives you: A measurement framework organized around the developer journey (awareness, activation, engagement, retention), not around DevRel activities. Attribution models that are honest about their limitations while being useful enough to justify budget. Presentation frameworks for translating developer metrics into business language that leadership values.

Why it’s foundational: Everything you build in layers 2 and 3 needs to be measurable. If you launch a community program without defining what success looks like, you can’t defend the investment. If you run conferences without tracking pipeline influence, you’re spending budget on faith.

How to use it in the workbench: Open the DevRel Metrics & ROI Playbook. Work through the checklist. Define your metrics before you start the other playbooks. Bookmark it because you’ll reference it quarterly.

Take the prompts to AI: The playbook’s decision frameworks can be fed directly to Claude or GPT with your company context. “Given our product [X], our developer audience [Y], and our business goals [Z], which DevRel metrics should we prioritize?” The playbook gives you the right questions. AI gives you the specific answers for your organization.

Developer Feedback Loop Playbook

What it gives you: A systematic pipeline for collecting developer feedback from every channel (Discord, GitHub, Twitter, support tickets, sales calls), routing it to the right teams (bugs to engineering, feature requests to product, docs gaps to content), and closing the loop so developers know they were heard.

Why it’s foundational: Without feedback flowing, you’re building in the dark. Your content strategy will be based on guesses. Your launches will miss what developers actually want. Your community will feel like it’s shouting into a void.

How to use it in the workbench: Open the Developer Feedback Loop Playbook. Set up the pipeline. Track feedback volume, response time, and resolution rate. Connect these metrics to your quarterly report.

The compounding effect: Once feedback is flowing, every other playbook you execute will be informed by real developer needs. Your content topics come from feedback patterns. Your launch priorities come from feature requests. Your community health comes from closed feedback loops.

Layer #2 - The Growth Engines (Build These Next)

With metrics defined and feedback flowing, you build the three engines that drive developer adoption. These run continuously. They take time to build but compound once they’re operational.

Content Engine

Developer Content Strategy Playbook: Not about writing blog posts. About building a production system. What to prioritize (your feedback loop tells you). How to structure content for different developer journey stages. How to build an editorial calendar that survives competing priorities.

Technical Writing Playbook: Documentation specifically. The difference between docs developers read and docs developers abandon. Structure, voice, code sample testing, information architecture organized by developer intent rather than product structure.

AI-Assisted DevRel Playbook: How to multiply your content output with AI without losing authenticity. This connects directly to the four AI tools in the workbench. The Content Repurposing tool turns one blog post into six channel-specific pieces. The Launch Checklist tool generates go-to-market plans from a changelog entry. The playbook teaches the principles. The tools execute the workflows.

How to use all three together: Open each playbook. Start with Content Strategy (set the system). Then Technical Writing (get the docs right). Then AI-Assisted DevRel (scale the output). Check off steps as you implement. Your content engine is running when all three checklists are complete.

Community Engine

Community Building Playbook: The starting point. Not “create a Discord and hope.” A staged approach: define the community’s purpose, design the member journey, build engagement loops (weekly rituals, monthly showcases), establish moderation, measure health. Each stage builds on the previous one.

Open Source Community Playbook: If you maintain open source, this adds the specific dynamics: contributor pipelines, governance structures, maintainer health, first-contribution optimization.

Developer Ambassador Program Playbook: When your community matures, ambassadors extend your reach. This playbook covers the full lifecycle: recruiting authentic advocates (not influencer-style reach grabs), onboarding, activating, supporting, and retaining.

Developer Advocacy Playbook: The broader strategy. Positioning advocacy within your org, building outreach programs, defining the advocate’s content role, measuring impact.

How to use all four together: Start with Community Building (get the foundation). Add Open Source if relevant. Layer on the Ambassador Program when your community has active members who could become multipliers. Use the Advocacy Playbook to position the whole function within your organization.

Note: This workbench is a hosted website product, not an open-source codebase. Community contributions come through the site and are credited to contributors by name.

Onboarding Engine

Developer Onboarding Playbook: First-run experiences. The path from “just heard about you” to “actively building with your product.” Three milestones: first credential, first success, first custom build. Map your current path. Remove friction. Design the “aha moment.” Measure drop-off at every step.

Why this is a growth engine: Good onboarding doesn’t just convert new developers. It improves retention. Developers who reach first success quickly are significantly more likely to still be using the product 30 days later. Fix your onboarding and you fix your activation and retention metrics simultaneously.

Layer #3 - The Execution Layer (High-Impact Moments)

Now you have the infrastructure. Metrics are defined. Feedback is flowing. Content is shipping. Community is growing. Onboarding is smooth.

Now you can execute the high-impact, high-visibility activities that most teams try to do first and fail at because the foundation isn’t there.

Launches

Product Launch Playbook: T-30 through post-launch. Every stakeholder, every deliverable, every DRI assignment. Pair it with the Launch Checklist AI tool to generate your specific launch plan in 30 seconds.

Why it works better with layers 1 and 2: Your content engine produces the launch content. Your community amplifies it. Your feedback loop shaped what you’re launching. Your metrics tell you if it worked. Without the earlier layers, launches are just announcements. With them, launches are coordinated go-to-market motions.

Events

Conference Talk Playbook: The full lifecycle. Identifying conferences (the Resource Center has a curated list), writing CFPs, designing the talk, delivering it, and amplifying after. One talk should produce at least five content pieces.

Hackathon Playbook: Designing hackathons for signal, not swag. Challenge design, support infrastructure, and the follow-through plan that converts participants into active users and community members.

Demos

Demo Engineering Playbook: Demos that convert. Three-act structure (problem, solution, expansion), timed segments, audience targeting, fallback matrices. Pair with the Demo Run-of-Show tool for instant scripts and the Demo to Distribution tool for turning demos into distribution cycles.

Layer #4 - The Safety Net (Set Up Before You Need It)

Crisis Communication Playbook: What to say when your API goes down, when a security incident hits, when a breaking change ships without warning. Templates for first response, ongoing updates, resolution announcements, and public post-mortems. Set this up before a crisis happens. During a crisis is not the time to figure out who writes the status page update.

Why the Sequence Matters

Here’s the pattern I’ve seen fail dozens of times:

1. Team starts with events and launches (Layer 3)

2. Events go well but have no measurement framework (Layer 1 was skipped)

3. Leadership asks “what’s the ROI?” and the team can’t answer

4. Budget gets questioned. Team gets stressed.

5. Team tries to build metrics retroactively while also running the next launch

6. Burnout. Attrition. New person starts the cycle over.

Here’s the pattern that works:

1. Foundation (Metrics + Feedback): Know what you’re measuring. Know what developers need.

2. Growth engines (Content + Community + Onboarding): Build the systems that run continuously.

3. Execution (Launches + Events + Demos): High-impact moments that succeed because the engines support them.

4. Safety net (Crisis): The protection layer for everything you’ve built.

Start at Layer 1. Build up. Each layer takes 2-4 weeks to implement using the playbook checklists. In 90 days, you have a functioning DevRel system.

How the Workbench Makes This Practical

All 15 playbooks live at 10xdevrel.atharvashah.com/playbooks. Each one has:

• Interactive checklists that track your progress locally across sessions

• Bookmark capability so you can build a personal collection of the playbooks you use

• Shareable URLs so you can send any playbook to your team

• Portable frameworks you can adapt to your product, team, and stage

• AI-compatible prompts you can take to Claude/GPT with your company context

The four AI tools at 10xdevrel.atharvashah.com accelerate the most time-consuming execution tasks. The Resource Center provides 200+ curated resources that the playbooks reference. The Community section lets you share what works and learn from other practitioners.

And if you want the comprehensive, portable version of everything, The DevRel Guide compiles all 15 playbooks with deeper frameworks, 15 templates, and case studies. 240+ pages. $29 early bird. Launches Q3 2026.

Your First Move

Don’t try to implement all 15 playbooks at once. Pick one from Layer 1. Open it. Start the checklist. That’s your first move.

1. If your biggest pain is proving ROI, start with the Metrics playbook.

2. If your biggest pain is not knowing what developers want, start with the Feedback Loop playbook.

3. If you’re drowning in content production, start with the Content Strategy playbook and use the Content Repurposing tool to multiply your output immediately.

The workbench is free. The playbooks are ready. Start checking boxes.

Open the 10x DevRel Workbench

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.

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.

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 not one job. It’s six jobs duct-taped together.

Here’s what that actually looks like:

• Content. 100+ technical blogs, 200+ help docs, 6 published books on Amazon KDP. Three of those books were endorsed by US CISOs.

• GTM. Launched 3 new product verticals from zero: AI Security, API Security, SBOM. Each one got a positioning doc, competitive analysis, blog cluster, landing page, webinar series, and partner proposition before launch day.

• Events. 15+ webinars produced, 5+ offline events, RSA Conference 2026 managed end to end, KubeCon Mumbai planning for June 2026.

• Tooling. Built an AI-native demand gen stack that replaced a $4K/month agency with $400/month of AI tools. 90% cost reduction, better output.

• Community. Partner co-branded propositions, DevRel network building, hackathon CTFs.

• Engineering. Forward-deployed engineering tasks, 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.

Freelance and Online Presence

The short version: 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. Industry average sits at 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.

Portfolio Categories You Should Build

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: know your niche, know your ICP, know your skill tree. I have 17 audience archetypes documented with exact pain points and buying triggers. Build content around your competencies. Validate ideas in public. Let people watch you work.

GTM That Actually Works

GTM is not marketing. GTM is the system that gets a product from “built” to “bought.” That distinction matters because most teams confuse the two and ship campaigns without ever shipping a narrative.

What I’ve Shipped

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.

Best Practices for Any Launch

Five things, in order:

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. No cluster, no launch.

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.

What a DevRel Should Actually Do

The role is misunderstood. Most people think DevRel equals going to conferences and tweeting. That’s 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.

The Four Pillars

After three DevRelUni sessions and watching how the speakers framed their wins, I distilled the role into four pillars.

Pillar 1. Nail the product messaging. Lead with ROI, not features. Developers don’t read your feature list. They care about what your product solves. Every blog, every demo, every talk should answer one question: what does this save me. Time, energy, headache, all of it. Position the product as a shortcut, not as a tool.

Pillar 2. Talk about integrations. If your product integrates with the giants (AWS, GCP, Kubernetes, Terraform), that IS your product-market fit story. Integrations signal maturity. They lower adoption friction. Lead with them.

Pillar 3. Build developer tools. Simplify your APIs. Make SDKs that are actually pleasant. Keep your docs up to date and honest, no outdated screenshots, no broken code samples. Maintain the developer portal. It’s your storefront. If it’s broken, nothing else matters.

In the age of cheap AI credits, you should also build internal apps. ROI tracker, SEO analytics tool, content calendar, whatever your team keeps doing in Excel. Tools like Lovable, Versus Code, Claude Code make it trivial. Get your org to sponsor credits and ship.

Pillar 4. Show ROI in everything you do. Track developer signups, docs traffic, community growth, content attribution. If you can’t tie your work to a business metric, you’ll be the first cut in a downturn.

Top 10 Tasks for 2026

This is the playbook I’d hand to any DevRel hire on day one.

1. Build an AI content layer for your product. Use tools like MagiOS 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.

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 system, which is also my number one piece of advice later in this article.

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.

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 four tools:

• Launch Checklist Generator. Input a changelog entry, get a T-minus checklist with task owners, DRI map, and readiness score.

• Demo Run of Show Builder. Input product, audience, and time slot, get a timed structure with speaker notes and fallback scenarios.

• Content Repurposing Planner. Input one blog, webinar, or transcript, get 6 content briefs (tutorial, narrative blog, webinar pitch, tweets, LinkedIn post, Substack Note).

• Demo to Distribution Planner. Input a feature announcement, get a 3-layer plan: demo flow, launch checklist, 2-week distribution calendar.

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

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. My vault is at 1,570 knowledge graph nodes today. It took two years to get here, but it grows exponentially once the inputs are flowing. Your digital twin becomes your second brain. It remembers what you forget. It connects dots you miss.

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

1. Claude Chat for ideation and research

2. Claude Code for building automations, writing scripts, managing the vault

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

4. Claude Skills for reusable workflows you trigger with a slash command

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

6. Plugins for extending Claude inside your specific domain

7. MagiOS for scaling content creation

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

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. It’s not progress.

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 over quantity. 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.

The Numbers in One Frame

If you take nothing else from this article, take the scoreboard:

• 1M+ organic traffic generated

• 100+ technical blogs shipped

• 200+ help docs maintained

• 6 books published on Amazon KDP

• 90% marketing cost reduction ($4K to $400/month)

• 30%+ Substack open rate vs 21% industry average

• 4x organic traffic growth for an SEO client (2K to 8K in 6 months)

• 15+ webinars produced, 5+ offline events run

• 1,570 knowledge graph nodes in the Obsidian vault

• 17 documented audience archetypes

• 1st place at CRIF Hackathon 2023 (37 teams, 140+ participants)

That’s the work behind the talk.

Where to Go Next

Check out the website 10xDevRel I made to make this 10x easier and actionable for product managers and DevRels!

Three things I’d ask you to do if any of this resonated:

1. Watch the full conversation. The video at the top of this post has all the moments I cut for length, including the live demo of my workflow and the parts where Manik pushes back. About 46 minutes, worth your commute.

2. Try the DevRel Workbench. 10xdevrel.atharvashah.com is live. Four tools, free, open source. If you ship feedback, I’ll prioritize it.

3. Subscribe to the blog and follow on X. This is one piece in a long series on building DevRel and growth functions from scratch with AI as the backbone. Substack: blog.atharvashah.com. X: @cultist_dev. LinkedIn: linkedin.com/in/atharva-shah-tech.

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

If you only remember one line from this whole article, make it this one. Nobody hires you because of your resume. They hire you because they’ve already seen your work. 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.

They start generating before the company has defined what the AI should know.

That gives you the usual sludge. Generic blog posts. Flat LinkedIn copy. Landing pages that mention features without understanding buyers. Email sequences that sound like they were written for a company with no history, no positioning, and no actual 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 manually, and then make it usable by the system.

That meant product context, buyer context, competitor context, transcript context, and publishing rules all had to be manually created, cleaned up, and mapped into a format Magi could actually work with.

What this looked like at AccuKnox

This was never 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 TL;DR, 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 described the operating model almost perfectly:

“Take the first cut. I’ll fine tune at the very end.”

That is how this kind of system should work. The team builds the structure first. The AI handles transformation after that. Human judgment stays at the edges where it belongs.

Setting Up The AI-Driven Content OS On Magi

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

This was the foundation:

1 Market -> 1 ICP -> 3 Personas

That meant:

• 11 markets

• 11 ICPs

• 33 personas

Each persona needed more than a job title.

Each one needed:

• A real description

• Primary use cases

• Pain points

• KPIs they are judged on

• Enough context for the AI to understand why that person would care

The three ICP types we mapped across every single market:

1. User (hands-on operators): Security Engineer, DevSecOps Engineer, DevOps Engineer, MLSecOps Engineer, Platform Engineer, Kubernetes Engineer, Security Architect.

2. Buyer (decision makers with budget): CISO, VP of Security, Chief Information Officer, Chief Data Officer, AI Governance Lead, AI/ML Product Manager.

3. Partner/Reseller (channel and distribution): Director of Sales, Channel Partner Manager, Account Manager, Product Manager, MSP Manager, System/Technology Integrator.

This looks simple on a whiteboard. It is not simple once you try to operationalize it across CNAPP, ASPM, CSPM, CWPP, KSPM, AI security, API security, DSPM, compliance, 5G security, and MSSP partnerships.

Here is what the full market grid looks like 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 market specifically.

That is exactly why most teams avoid doing it.

They want the output before they have earned the input.

What went into the knowledge base

The spreadsheet schema was the real product spec.

Magi did not pull any of this in automatically.

We built the knowledge base from scratch. Defined the markets, mapped the ICPs, wrote the personas, organized the collections, decided what belonged where. The system only became useful after that work was done.

Seven layers. Here is what each one actually contained.

1. Personas and campaigns

The personas tab was where everything else downstream got grounded. It mapped:

• Market

• Persona name

• Description

• Use case

• Pain points

• KPIs

This is where generic messaging dies.

Once the AI sees the difference between a CNAPP buyer trying to reduce cloud risk and a hands on platform engineer buried in runtime alerts, the writing changes immediately.

Here is what a fully built-out ICP looks like 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. For the AI-SPM User persona alone, that meant: description, use cases, pain points (Shadow AI; No standards; Rapid rollout; Poor visibility; Compliance gaps), and KPIs (AI asset coverage; Policy violations; Risk events; Audit readiness; MTTR). The AI does not guess at any of this. You put it in. The system uses it.

2. Competitors

Every market needed direct competitive context.

The rule we followed: 4 competitors per market. 2 big players offering broad platform coverage. 2 niche players with specific point solutions.

That included:

• Name

• Website

• LinkedIn

• Blog

• Short positioning summary

The system should know whether it is writing in a market crowded by broad platforms like Wiz and Orca or a tighter category with narrower players.

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 3 people: name, title, LinkedIn. Not for outreach. For signal. When the people closest to a category are writing about their problems, that is free market research. Having a list meant we actually read it instead of browsing randomly and hoping something stuck.

4. Knowledge files

Everything the company already knew that wasn’t in a usable format. We pulled 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

This is where transcripts start to matter.

Your company already has a pile of explainers trapped in sales calls, POC conversations, review notes, Slack threads, and internal docs. Your best content usually already exists in conversation form.

But that did not mean Magi automatically understood any of it. We still had to decide what to extract, how to classify it, and where it should live inside the knowledge base. Magi became useful only after that manual setup work was done.

5. SEO Frontmatter and Brand Rules

The difference between content that is readable and content that can actually ship is metadata. We wanted the latter.

That meant every blog needed mandatory metadata and SEO framing at generation time. Here are the required fields we get with every draft copy being generated.

Once frontmatter, tone guidance, category rules, and required links are part of the brief, the draft becomes much closer to publishable.

Our internal summaries reinforced this too. The standardized blog framework had 14 mandatory components. That is the real lesson here. Good AI writing systems are held together by checklists.

Meeting Records and Transcripts are GOLD!

Companies sit on a ridiculous amount of content that never becomes reusable.

• Sales calls

• Product demos

• Customer questions

• Slack clarifications

• Internal review comments

• Meeting recordings

This setup sharpened that 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 when they explain the business to each other.

That language is worth far more than another generic AI prompt.

But again, the transcripts were input for us first. They helped us understand what the system needed to know. They were not some automatic ingestion shortcut that saved the setup work.

The research layer also powers competitive monitoring. Magi’s research reports pull competitor LinkedIn posts, blog content, and CVE coverage into a single view per market. You do not have to browse five different sources manually.

If I were rebuilding this from scratch again, I would still start with transcripts, docs, and source collections before I touched generation settings. Then I would manually map the ICP and knowledge layers 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 wasn’t staring at a blank screen

• A cleaner editor so review didn’t feel like a chore

And the parts that were already solid enough to test:

• Calendar

• Collections

• The TOFU blog template

That last list matters. Those aren’t cosmetic wins. They’re the sign a tool has crossed from demo to daily use.

BrandOS

Once fully set up, your generated content would be a lot more on brand. You’d also be able to switch between different voices, tones, and keywords for each content piece you create. The system lets you configure brand rules that apply globally across campaigns or override them per content type.

Watch the video below to see all the options present in Magi’s Brand OS:

This is the part most AI content tools skip. They give you a prompt box and call it personalization. Brand OS is the layer that makes the tool actually know how your company sounds before it writes a single word.

Calendar view

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

Once you can see blog posts, landing pages, emails, and one pagers in a scheduling interface, the tool stops feeling like an AI toy and starts feeling like a planning surface.

Knowledge base and collections

Source assets need somewhere to live that isn’t 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’s 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 creates a much tighter loop:

• collect signal

• classify it correctly

• map it to a campaign

• generate derivative content

That is the actual compounding behavior most teams want from AI content systems.

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 TL;DR, the sourced excerpt that triggered it, and a draft generation button. The idea is not a blank page. It is already positioned.

The Intuitive Content Creation Experience - Campaign Idea → Brief → Draft → Publish

The interface was not just polish. It reflected the operating model underneath: campaign first, content type aware, structured notes feeding generation, visible workflow states, quick access to recent work. That alignment is what makes a tool feel like something a team could actually live in versus something you demo once and forget.

Content in production

With the architecture in place, content becomes a queue problem, not a blank page problem. Here is what 52 pieces looks like: campaign tagged, content type assigned, owner named, status visible.

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

That brief is grounded in a specific knowledge source, a specific campaign, a specific ICP. The output shows 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

That is the difference people miss.

The model was never the bottleneck.

The knowledge architecture was.

And that architecture did not appear by itself. The team had to build it.

What I would tell any team trying this

If you are setting up an AI content system, do these first:

1. Define the market taxonomy before you generate anything.

2. Write personas with pain points and KPIs, not vague role labels.

3. Build competitor and influencer context by category.

4. Turn your existing source material into collections the system can reuse.

5. Make frontmatter and publishing rules mandatory.

6. Use transcripts and internal conversations as primary source material.

7. Treat workflow UX as part of the system, not an afterthought.

Most teams want a better prompt.

What they need is a better schema.

That was the real Magi setup.

It was less about teaching AI to write and more about manually teaching the system what the business already knows.

Once that clicked, the tool finally had something worth saying.

Leave a comment

Static workshops don’t teach security. They teach patience. You sit through slides, nod at diagrams, and leave with zero hands-on reps. That’s not useful. 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: 3 tracks, 15 primary challenges plus 3 bonus flags, a CTFd scoring model, deterministic solve checks, admin controls for reset and operations, and a production Docker deployment path.

This is the build journal. The decisions, the tradeoffs, the build order, and the exact setup that made one day work without sacrificing reliability.

Why Browser First

The first decision was strategic, not technical.

If participation has friction, conversion drops. A CTF that demands local setup loses people before they ever see a challenge. The event had to be browser first, full stop.

That drove product shape:

• CTFd for registration and official scoring

• a custom browser app for the actual game experience

• a backend runtime that keeps secrets and challenge logic server side

This separation gave three concrete wins. Players get a familiar, trusted scoreboard workflow. The custom UX handles AI-native challenge interaction. Secrets stay server side and solve logic stays deterministic.

Think Top Down, Not Challenge First

My rule for this build: do not start from individual challenges. Start from experience architecture.

The classic CTF trap is writing many challenge ideas before the runtime foundations are stable. You end up with 20 half-formed challenge concepts and no working platform. I reversed the order.

Layer 1: Event Structure

• What is the official scoring source of truth? CTFd.

• Where do players actually solve? Browser app.

• What is the challenge unit design? 3 tracks, 5 primary challenges each, plus 1 bonus.

Layer 2: Platform Contract

• Track pages must be coherent and navigable.

• Challenge pages must support both chat based and action based workflows.

• Solve checks must be stable, even when model output drifts.

Layer 3: Build Order

• Ship platform core once.

• Prove vertical slices end to end.

• Scale challenge content only after reliability exists.

That sequencing prevented most of the rework. Scope ambiguity at layer 1 multiplies into hours of changes at layer 3.

The Exact Build Order

1. Lock the challenge map and scoring model first

I fixed scope early: three tracks, fixed point distribution. This removed downstream rework in both UI and backend. Any scope ambiguity at this stage is the most expensive kind.

2. Build the runtime shell first

Express + EJS. Server rendered pages are simple and debuggable. I was not trying to win a framework debate. I was trying to ship.

3. Implement one complete challenge slice per track before writing content

Before authoring all challenge files, I validated one representative solve path per track:

• Prompt Injection

• Agent Workflow

• Hidden API

4. Add deterministic solve checks

AI output variance is real. Solve logic cannot rely purely on model text. I paired prompt flows with deterministic regex and action checks to keep challenge solving reliable across different model states.

5. Expand content to the full catalog

Only after the runtime was stable did I fill out all challenge JSON definitions and bonus progression mechanics.

6. Build admin and operational controls last

Reset paths, user and session visibility, solution library views. These are for organizers, not players. Build what players need first.

Architecture And Key Considerations

Browser First Challenge Delivery

Everything playable in the browser: prompt manipulation tasks, constrained agent workflow attacks, hidden API tamper paths. No local AI setup required.

Challenge Authoring Model

Challenges live as JSON content loaded dynamically. Fast to add and tune:

• challenge metadata

• system prompt behavior

• flag values

• solve patterns

• track-level bonus progression

Reliability Over Model Luck

When the live LLM is unavailable or inconsistent, fallback mode preserves deterministic challenge checks. The CTF stays playable and testable regardless of model state. This saved me during testing more than I expected. The LLM I used was Groq given it’s generous free tier with `llm-.3-70b-verstile` allowing upto 1K/requests per day

Security

• provider keys stay server side

• no raw secret exposure in front end assets

• challenge solve states tracked per user session

• role-based admin access for control operations

UI And UX Choices

I treated this as a product, not a challenge dump. That distinction sounds obvious until you see how most CTFs are actually built.

Principles I used:

• Immediate clarity: players understand what to do within seconds

• Visible progression: solved states and track completion are obvious

• Low navigation friction: home to track to challenge is one click

• Challenge identity: strong visual differentiation per track

  

The home page acts as a mission board with progress context. Track pages show challenge list and status in one view. Challenge pages keep conversation, solved state, and prompt box in the same loop. No context switching.

For organizers, I built an admin dashboard with rate limit visibility, user management, and quick access to solution guides. An event platform that is hard to run doesn’t get run twice.

Testing Strategy

The fastest way to lose trust in a CTF is inconsistent solve behavior. I prioritized testing ergonomics over coverage metrics.

What I built in:

• deterministic solve checks in runtime

• reset paths for fast retesting

• seeded demo users

• visible solve status per challenge

• structured challenge activity and session storage

Then three practical test passes:

1. Creator pass: can I solve from blank state quickly?

2. Peer pass: can another person solve with only available hints?

3. Fresh pass: can someone with no context navigate and complete the objective?

The third pass is the one most CTF builders skip. Don’t skip it.

Infrastructure And Deployment

Optimized for event reliability and organizer simplicity. The main app is just a Docker file that I packaged with peristent volume mounts for player, score and other data backups.

Local And Container Support

• local Node run for rapid iteration

• Docker Compose for repeatable deployment

• persistent volume for user and session data

Environment Strategy

• root-level environment file for runtime config

• explicit provider and rate limit controls

• predictable data paths for backup and restore

For DevRel-led events, setup friction for organizers is as critical as player friction. A platform that is hard to run won’t scale to repeated workshops or community events. Docker came in on day one, not as an afterthought.

Difficulty Design

Difficulty was intentionally layered.

Track progression:

• easy starts build confidence

• medium stages teach deeper patterns

• hard stages require chaining and precision

• bonus flags reward full-track completion

From observed session data, prompt injection flows solved quickly. Deeper workflow and API attacks demanded chained, multi-step reasoning. That’s the intended shape. Beginners complete meaningful portions. Experienced players still hit real depth.

How I Actually Vibe-Coded This

Most build logs skip the honest part. Here it is.

I used GitHub Copilot for most of the implementation. The speed didn’t come from blindly accepting generated code. It came from using Copilot as a fast implementation partner after I had already fixed the intent and boundaries of each slice.

My actual workflow:

1. Write a clear objective for one thin vertical slice. One challenge page. One solve path. One admin operation.

2. Use Copilot to draft implementation candidates quickly.

3. Validate behavior immediately in browser and session data.

4. Keep only code that matched deterministic solve logic and product flow.

Vibe coding gave me velocity. Constraints gave me quality. The combination is what made one day actually work.

For UI exploration, I used Google Stitch as a design thinking accelerator. Not as final output. I used it to generate layout directions, visual hierarchy ideas, and interaction ordering quickly, then translated those ideas into the Express + EJS runtime in a way that preserved reliability.

Stitch helped most in three places:

• homepage information hierarchy

• track page scannability

• challenge page rhythm

Copilot for implementation speed. Stitch for fast UX ideation. Manual runtime constraints for correctness.

How I Wrote Prompts During The Build

Prompt quality was the hidden multiplier. I didn’t use one giant prompt and hope for magic. Short, explicit, context-rich prompts structured around intent, constraints, and acceptance criteria.

My prompt shape:

• Objective: what exactly should be built in this step

• Context: files, routes, current behavior, constraints

• Guardrails: what must not change

• Output contract: how I want the result formatted

• Verification: what should be true after implementation

Example from the 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 is everything. Mixing architecture decisions, copywriting, and debugging in one request produces garbage. Smaller prompts, tighter loops, fewer regressions.

How To Iterate When Vibe Coding a Complex Application

CTFd Integration And Deployment Model

The deployment model is intentionally hybrid.

CTFd is the official scoring authority: registration, team context, scoreboard trust. The custom browser platform is the gameplay authority: AI interaction, challenge runtime, deterministic solve checks.

Why this pairing works:

• players get familiar CTF lifecycle in CTFd

• organizers get richer AI-native challenge UX in the custom platform

• no need to force gameplay UX into CTFd plugin limitations

Deployment mechanics:

• containerized runtime via Docker Compose

• environment-driven config for provider keys and rate controls

• persistent storage for session and solve state continuity

• admin visibility for operational interventions during live events

This gives a repeatable event model. Scoreboard confidence from CTFd, experiential depth from the custom AI runtime.

What I’d Improve Next

If I run this at larger scale:

• deeper analytics per challenge step and drop-off points

• richer anti-abuse controls for public events

• one-click flag relay into CTFd API

• post-event reporting for learning outcomes

What Actually Matters

A good CTF platform is not just challenge content. It’s experience design, reliability engineering, and event operations all in one.

In one day, we shipped a complete, browser first AI security CTF that participants can play, organizers can run, and DevRel can scale.

If you’re designing AI security programs, the architecture pattern here is practical:

• keep scoring and gameplay concerns separated

• make solve logic deterministic where it matters

• design UX for flow, not just visuals

• ship with operations in mind from day one

That’s how KubeArmor AI CTF came together.

Leave a comment

The Problem With Flat Checklists

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

That was our reality.

My organization (AccuKnox) being B2B-led, covers a lot of surface area: CSPM, CWPP, KSPM, CDR, GRC, AI Security, ASPM, SAST, DAST, SIEM integrations, CI/CD, and more.

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

Our old process used one flat spreadsheet where every feature looked equally important. No rank. No score. No obvious signal.

We would leave calls with all boxes 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, three engineers, and limited internal bandwidth. We have two solution architects.

If we cannot rank what they care about, three bad 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.

That is not a sales talent issue. It is a visibility issue.

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.

No post-call guesswork. The prospect input becomes the prioritization output.

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 answered:

“What got checked?”

Now it answers:

“What do we tackle first?”

Our post-call language changed.

Before:

“They mentioned CSPM and maybe KSPM. Should we start there?”

After:

“KSPM is 8/8. CDR is 8/8. AI Security is 27/50. Start with KSPM and CDR. Move AI Security deep dive to week two.”

That shift improves execution quality immediately.

The highest-scoring modules get engineering focus first. Low or zero modules get deprioritized with a clear paper trail.

Prospects benefit too. The POC mirrors the priorities they selected, so alignment feels obvious rather than forced.

The Bigger Takeaway

I built this because I got tired of watching smart teams make sequencing decisions from memory and vibes.

With 15+ modules and 79 tracked features, human memory is unreliable. People default to what they heard last, what sounded loudest, or what they already know best.

Scoring does not replace judgment. It gives judgment a solid starting point.

The grader took an afternoon to build. The formulas are simple. The impact is outsized.

You get a living priority map that updates with every prospect input and gives the team a ranked agenda before the follow-up call is even booked.

If your team runs POCs across more than five modules and has no scoring layer, you are operating with low visibility. Build one.

The spreadsheet does not close deals. Clear prioritization does.

Leave a comment

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 is not small. It quietly 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 to PDF.

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

• Send it.

That took 30 to 45 minutes per quote. And that was the happy path.

Then came the hidden failures. A VLOOKUP pulled the wrong tier because one row got drag-filled too far. Three file copies floated in Slack, all slightly different. A rep sent USD pricing to an India-based customer because the currency column was far off-screen.

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

Version sprawl alone was enough reason to replace the process. Files named Pricing_v3_FINAL.xlsx, Pricing_v3_FINAL_USE_THIS.xlsx, and Pricing_v3_clientname_v2.xlsx lived across Slack and inboxes. Two reps quoting the same prospect from two versions was normal.

At that point, you do not “improve the sheet.” You replace the workflow.

Why This Was Not “Just Build a Calculator”

On paper, this sounds easy. Build a calculator and move on.

In practice, pricing for a multi-module B2B security platform is not seat count times price.

The calculation had at least eight dependent steps, and each one affected 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 interesting part is not the UI. It is the design choices behind it.

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. No files to send. No version confusion. When pricing changed, I updated the tool once and everyone got the latest values immediately.

Why a Three-Step Wizard Instead of One Long Form

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 enforces sequence. No pricing step until quote details are complete. No PDF 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:

The Billing Entity Selector Was the Highest Leverage Dropdown

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

This took the most thought because 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. People got one part right and missed another.

I collapsed it into one choice. Select AccuKnox India Pvt. Ltd., and currency, formatting, address, and legal text all switch automatically.

One rep decision. Multiple guaranteed updates. People could now also see billable assets per module, rather than switching spreadsheet tabs they just had to click the i button next to the module they wanted to inspect the billable assets for and boom!

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 on the left, pricing impact on the right, both visible at once. 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 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:

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 scenarios in front of the customer and immediately show tier effects.

That changes the conversation from “let me check and reply later” to “here is what happens if we include this module.”

What Changed

Quote time dropped from 30-45 minutes to 3-5 minutes. This is how the quote is generated right from the app, so clean, modular and dynamic and always free of human errors.

That gap matters. Sending a quote during the meeting hits differently than sending it the next day.

• Currency errors since launch: zero.

• Wrong legal entity on quote cover pages: zero.

• “Excel says one number, PDF says another” incidents: zero.

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.

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.

Take Ownership of the Problem, Not Just the Title

I am a DevRel engineer and a Technical Content Lead and yet I shipped a sales ops tool. That is unusual, but it was the right call.

The pain was obvious from outside the team. Quote cycles turned into long Slack threads. Rate card updates meant inbox blasts. New rep onboarding included spreadsheet survival training.

When a problem is this visible and this solvable, title boundaries should not block execution.

The spreadsheet was not failing because people were careless. It was the wrong tool. Spreadsheets can handle straightforward math. They struggle when eight linked variables drive legal, currency, formatting, and governance-sensitive output that must be auditable later.

At that point, you do not “improve the sheet.” You replace the workflow.

Leave a comment

“I have 585 photos. They’re beautiful. They’re chaos. I want them to become 62 Instagram posts.”

One conversation later, I had exactly that. A local Python script, a Markdown file, and a six-phase workflow that became the source of truth for an entire year of my life in photos. No cloud uploads. No tagging API. No subscriptions.

The Problem Nobody Talks About

You have a folder. Maybe several. Files named IMG_20241103_182344.jpg stacked next to screenshot_edit_final_v3_REAL.png next to remini-enhanced-kgwv6b.jpg. You know the folder. Every photographer has The Folder.

The problem isn’t editing. Lightroom exists. The problem is curation at scale. It’s the cognitive overhead of:

• Deciding which 12 photos from a 3-day trip belong together

• Making sure the pacing across 60 posts doesn’t repeat the same mood three times running

• Matching music to visual energy without reusing the same track on adjacent posts

• Keeping certain people, certain moments, certain locations off public-facing content

• Actually getting a folder called FINAL/ that’s ready to drag into Buffer

AI closes that gap. If you know how to ask.

What I Actually Built

Over a single extended AI session, using only GitHub Copilot in VS Code and local Python 3, I went from a raw image dump to this.

Everything happened locally. The AI never saw a pixel. It worked from filenames, descriptions I’d written in a log file, and my own curation criteria. My photos stayed on my machine the entire time.

Why This Is Different From Every Other “AI Photo Tool”

1. Nothing leaves your machine.
Every operation ran locally. Python read local files. The AI read filenames and text descriptions — not pixels. The export script copied files within the same machine. Zero cloud round-trips.

2. The AI works from your criteria, in your voice.
Standard AI photo tools auto-label “beach,” “portrait,” “food,” and hand you a folder of mislabeled false positives. This worked differently. The AI proposed groupings based on what you told it mattered. You reviewed every assignment before anything was finalized. The curation was yours.

3. The output is a first-class artifact.
CURATION.md is not a temporary working file — it’s a permanent creative document. It contains every grouping decision, every caption, every music reasoning. Six months from now when you’re wondering why you put two images together, the rationale is there.

4. It scales.
The same workflow works for 100 images or 5,000. The export script handles filename chaos gracefully. CURATION.md can nest, extend, and reorganize. The QC pass scales with automated checks before the human visual review.

5. It’s yours to run again.
The next time I do a photo dump, I run the same prompt architecture. The script already handles all my filename variants. I update MANUAL_INDEX_TO_FILE for any new unlogged batch, update CURATION.md, and run export_final.py. The entire workflow is reproducible.

Who This Is For

If you have more than 50 photos you care about and no system for them, this is for you. Photographers, travelers, content creators, designers — the workflow doesn’t care. It also doesn’t care whether your target is Instagram, Substack, a portfolio, or a private archive. The structure holds.

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

What it found:

• One post had 24 images — Instagram’s hard cap is 20. It got split into two posts.

• Index 208 in my image log was a session boundary marker, not a real image. It had been silently included in a post assignment.

• 32 images from my oldest batch had never been individually logged.

This audit phase saved me from shipping a broken export. The Instagram carousel would have silently dropped 4 images. The ghost index would have caused a file-not-found error at export time. Neither of these would have announced themselves without a deliberate check.

Lesson: Ask the AI to audit before it does anything else. “Read what I have, count what’s there, and tell me what’s broken” is worth doing first.

Phase 2 — Grouping by Timeline + Location + Vibe

585 images. 18 months. The grouping pass was the hardest part. The criteria:

• Timeline first: photos cluster naturally by trip or life phase

• Location within timeline: a Mumbai weekend and a Goa weekend happen at similar times but look completely different — they need separate posts

• Vibe as a tiebreaker: if two sets of images are from the same location but one is golden-hour outdoor and one is nightlife indoor, they go in different posts

• People as a privacy gate: images with certain people were explicitly flagged for my review before being assigned to public posts

The AI proposed 60 posts initially. After the audit, that became 62 (two splits, plus resolving a 32-image unlogged batch into two dedicated archive posts).

Each post got a name. Not a filename. A name. P41 — Kerala — Backwaters + Garage Café + Coast. That level of specificity came from going back and forth on titles until they reflected what was actually in the frame, not what I wished was in the frame.

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. My filenames came in three formats:

• IMG-20250103-WA0012.remini-enhanced.jpg — full WhatsApp name + AI suffix

• FF92EE38.jpg — shortened UUID from a different app

• -kgwv6b.remini-enhanced.jpg — partial hash format

The resolver cascades: exact match → strip .remini-enhanced suffix → match on first 8 characters as prefix. Zero images failed to resolve.

Why this matters: The export script is idempotent. Every run wipes FINAL/ and rebuilds from CURATION.md. This means:

• Edit a caption in CURATION.md → run the script → the change is live in FINAL/

• Move an image to a different post → run the script → the folders reflect it instantly

• CURATION.md is always correct. FINAL/ is always a derived artifact.

Phase 4 — Captions & Music

The caption philosophy:

• Terse and atmospheric for travel/landscape posts — no need to explain the Taj Mahal

• Warmer and more personal for portrait or home posts

• No hashtag spam in the draft — that’s a posting-time decision

• Captions should add something the image doesn’t already say

The music philosophy:

• Each track’s mood should amplify the visual mood, not fight it

• Varied enough that consecutive posts don’t feel like the same playlist

• Personal enough to express something — no generic “lo-fi beats”

After all 62 posts were drafted, the AI ran a deduplication check. It found:

• One track assigned to 3 different posts

• Several tracks appearing twice on posts that were adjacent or thematically similar

Six swaps were made. Each replacement was a deliberate match — not just “anything else.”

A TRACK_REASONS dictionary was written into the export script for every post, explaining why the music works. This becomes a useful memory artifact: when you’re posting months later and you’ve forgotten the session, the rationale is right there.

Phase 5 — The QC Pass

Before calling the project done, we ran a coherence check. This covered:

1. Grouping coherence: does every image in a post have a through-line — visual, narrative, or emotional?

2. Title precision: does the title name what’s actually in the post, or just where you were?

3. Music deduplication: already handled in Phase 4, but confirmed clean

4. Caption quality: are there any captions that are too generic, too try-hard, or that over-explain?

One title fix came out of this: P41 — Kerala became P41 — Kerala — Backwaters + Garage Café + Coast because the images were three genuinely different subjects. The vague title would have been misleading both to viewers and to me looking at my own archive later.

Phase 6 — Visual Sanity Check

The final step was visual. My eyes, but with 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 all images 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 contact sheet, two images jumped out as visually incoherent with the rest of P60. A white fabric close-up and a lakefront scene had snuck in alongside Jantar Mantar stonework and Mughal architectural portraits. They were moved to P62, which had a looser, more eclectic brief anyway.

That’s the power of visual review at thumbnail scale: patterns that don’t show up in a filename list become instantly obvious in a grid.

The Final Numbers

Take It With You

I’ve packaged the entire workflow into a SKILL.md, a structured instruction set that any AI assistant supporting the VS Code Copilot skill format can invoke. It contains the six-phase workflow, the CURATION.md schema, the export script skeleton, and documented fixes for every common failure point.

Drop it into your VS Code setup. Point it at your folder. One conversation.

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.

That’s the full cycle.

Atharva Shah builds AI tools and workflows. This project was built entirely locally using GitHub Copilot in VS Code. If you want the SKILL.md file or want to adapt this workflow for your own image library, reach out.

Leave a comment

Uketsu wrote three novels. They look like puzzle-box mysteries. They read like horror. Under the surface, they are a sustained argument about the same set of ideas, told through architecture, psychology, and the specific violence of people who love something too much.

Want to see these themes in action? I’ve applied this analysis to the eerie visual clues in my Strange Pictures breakdown.

I’ve also explored how these specific patterns manifest in the layout of a home in my summary of Strange Houses.

For a look at these recurrent motifs on a grander, more structural scale, check out my full walkthrough of Strange Buildings.

This is a breakdown of the 15 patterns that run across all three books.

Part I: How Uketsu Builds the Story

1. The Armchair Detective Duo

Every Uketsu investigation runs on two people: one who goes to the scene, and one who never does.

In Strange Houses and Strange Buildings, the Author is the field agent. He visits houses, interviews witnesses, takes notes. His friend Kurihara, an architectural draughtsman, sits at a desk and reads floor plans. Kurihara never needs to visit. He constructs complete, terrifying hypotheses — murder scenarios, hidden rooms, cult headquarters — entirely from geometric anomalies on 2D blueprints.

In Strange Buildings, Kurihara solves the entire conspiracy by plotting eleven reader-submitted case locations on a map of Japan. They form a perfect circle. The center point is the cult’s Hall of Rebirth.

He deduced a nationwide religious conspiracy from a compass and a set of coordinates.

2. The Clues Are Visible in the Text

Uketsu does not just describe evidence. He puts it on the page.

Floor plans appear in the text. Drawings appear in the text. The reader holds the same evidence the characters do, at the same time they do. This is not a gimmick. In Strange Pictures, the reader can actually perform the “layer composition” — stack the three drawings over their circled axes — and see the composite murder image Yuki hid inside three innocent-looking sketches. In Strange Houses, the reader can overlay the two floor plans and find the dead space themselves.

The books treat the reader as a co-investigator. The mystery is solvable before the characters solve it. Most readers miss it anyway.

3. The Truth Is Always Fragmented

Uketsu never narrates events directly. The truth in all three books has to be reconstructed from documents, and the documents are always incomplete, unreliable, or mediated by a narrator with a reason to lie or omit.

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

No document in these books is neutral. Every fragment is someone’s version of what happened.

4. The Missing Variable

Uketsu’s pivotal clues are almost always absences rather than presences. Something that should be there is not. Something is missing from the count.

In Strange Pictures: a husband buys an 8-slice anniversary cake. He eats 2, his wife eats 1, 4 are saved for breakfast. That accounts for 7. One slice is unaccounted for. Kurihara deduces a third person is living in the house, hidden from every blog post.

In Strange Houses: the Saitama floor plan has no garage. The killers needed somewhere to put intact bodies. The floor plan is therefore missing a feature. Kurihara works backward from the absence to find the underground cellar dug beneath the garden.

In Strange Buildings: a walking stick is missing from a mobility-impaired woman’s room the night she dies on the stairs.

The method is consistent. Something that must exist does not appear. Find the thing that fills that gap, and you find the crime.

5. The Layering Trick

Reality in Uketsu’s work is not hidden behind a wall. It is hidden under a transparency.

Stack the first-floor blueprint over the second-floor blueprint in Strange Houses and the “dead space” aligns perfectly 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, a woman lying down becomes a corpse.

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

Lay the information over itself. What was invisible becomes unmissable.

6. The Rug-Pull Ending

Each book provides a resolution that feels earned. Then it takes it away.

In Strange Houses, Keita Katabuchi’s confession letter is moving. He built the trap-houses to fake the ritual murders, to protect his imprisoned son from a cult that demanded real kills. He surrendered himself so his family could survive. It reads as tragic, decent, and final.

Then Kurihara points at one detail in the Tokyo floor plan: a small interior window between the living room and the bedroom. Interior windows exist for one purpose. Surveillance. Kurihara asks whether Keita was the protector in the story he told, or whether he was the prisoner, watched constantly by Ayano. The letter does not change. The reader’s interpretation of it does.

In Strange Pictures, Dr. Hagio diagnoses the bird in the thorny tree as evidence of nurturing love that would overcome the patient’s aggression. The ending reveals that the thorns existed to protect the bird. The love was not the cure. The love was the weapon.

Both endings are brutal for the same reason: the evidence was always there. The interpretation was wrong.

Part II: What the Houses Are Doing

7. Architecture as a Weapon

Uketsu treats architecture the way thriller writers treat guns: as a tool designed by one person to do something to another person.

In Strange Buildings, Hikura Homes builds a mansion for a wealthy client with a deliberate, carefully measured gap at the top of the main staircase — no wall, no handrail — sized to be fatal to someone with a mobility impairment. The grandmother who lives in that house and has difficulty walking is not murdered by a person. She is murdered by the floor plan.

Hikura Homes also produces mass-market homes with north-facing plumbing that guarantees mold, bedrooms arranged as through-corridors with no privacy, and converted storage closets assigned as teenagers’ bedrooms. These homes do not kill on a schedule. They grind people down until someone snaps.

One company builds custom murder machines for the wealthy. It also mass-produces psychological attrition for the poor. The product differs. The contempt is the same.

8. The Facade of Normalcy

The more concealed the interior horror, the more aggressively welcoming the exterior.

The Katabuchi murder house in Strange Houses has 16 exterior windows. Kurihara identifies this as deliberate. Sixteen windows is not a functional choice; it is a performance. The house is saying, louder than any house needs to, that there is nothing to see here. The windowless rooms are in the center. The light show is on the outside.

In Strange Buildings, the retrofitted triangular sunroom built onto the Saitama house has large windows facing the garden. The windows are immediately blocked by the walls framing the room. The room has no functional access from the interior. It was built as a cover story for the underground cellar excavated beneath it. The sunroom exists to explain why someone was digging in the garden.

Both houses use their most visually comfortable features as camouflage for their worst ones.

9. Dead Spaces and Passages

Every book contains architectural voids: spaces that exist on the floor plan but cannot be accessed in any normal way.

The ancestral Katabuchi estate in Strange Houses runs its hidden passage system behind a massive, immovable Buddhist altar at the exact center of the house. The sliding doors that access the passage are permanently jammed. To an ordinary observer, that wing of the house is simply closed. Behind the altar is a confinement room nobody is supposed to know exists.

In Strange Buildings, Yayoi Negishi grew up in a house with a hallway that ended at a blank wall, positioned between her bedroom and her parents’. It went nowhere. Her mother built her life around a corridor with no destination.

In Strange Houses, the dead space between the kitchen and living room of the Tokyo house is not a construction error. It is a vertical shaft. The house has an interior the floor plan does not mention.

All three books share the same architectural premise: the space that has no official explanation is the space where the truth lives.

Part III: What the Books Are Actually About

10. Mothers Who Destroy What They Love

Maternal love in Uketsu’s work is not a softening force. It is the most dangerous motivation in every book.

In Strange Pictures, Naomi Konno killed her abusive mother to protect a pet bird. She killed her husband to protect her son. She killed her son’s wife to possess his child. She killed a reporter to protect her life with that child. The body count is entirely connected to care. Every person she murdered was a threat to something she claimed as hers.

Dr. Hagio looked at a child’s drawing of a bird inside a tree full of thorns and called it evidence of nurturing love. She was right about the love. She missed what the thorns were for.

In Strange Buildings, a mother attempts to pay a construction company to surgically remove her daughter’s bedroom from the house. Not from cruelty. From a cult-driven belief that reshaping her floor plan will protect her child.

The love is real in both cases. That does not make it safe.

11. Trauma Passed Down Through Architecture

Horror in these books is inherited. It does not stay in the person who first experienced it. It travels down the family line and shows up in the buildings.

The Katabuchi family in Strange Houses has been building hidden rooms and secret passages for generations. The ancestral estate, built decades ago, already had the jammed fusuma, the confinement room behind the altar, the windowless wing. The modern Tokyo house did not invent this. It inherited it. Each generation built a new version of the same structure because the family had never found a way to stop.

In Strange Buildings, the Rebirth Congregation explicitly targets people carrying inherited guilt: illegitimate children, affairs, children born with disabilities. It sells the architectural reformation of their homes as a cure for the sins that produced them. The transaction requires the guilt to be permanent and transferable. The business model depends on the wound never closing.

12. Children Used as Objects

Children in Uketsu’s trilogy are hidden, deployed, exploited, and mourned. They are almost never allowed 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 an objective. He is ten years old. The first time he uses the secret passage he was given, he does not go to kill anyone. He goes to the master bedroom to put 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 but feels tight. The entries get shorter and then stop. The journal was later published under the title 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 child abuse.

13. The Severed Left Hand

Amputation is the trilogy’s recurring physical symbol, and 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 10 and 13, murder a member of the rival branch and sever their left hand for the altar. The ritual was invented by a manipulator. The family obeyed it for generations anyway.

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

The left hand specifically, in both cases, represents lineage, inheritance, and the thing that was taken and never replaced.

14. The Corporation That Builds the Harm

Uketsu does not restrict evil to individuals. In Strange Buildings, the primary antagonist is a corporation.

Hikura Homes builds the Tsuhara house with deliberate disregard for the psychological impact of its cramped, mold-prone, privacy-free design. It builds the mousetrap mansion knowing what the staircase gap will do. It constructs the Hall of Rebirth as the physical headquarters for a cult it founded and operates. It 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. The house is what you buy to manage it. If the guilt were cured, the business would end.

15. Violence as a Forensic Tool

The gore in these books is almost never emotional. It is functional.

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

In Strange Pictures, Naomi Konno beats a man’s body more than 200 times with a rock. Not from rage. The mutilation is a technical requirement: it destroys the physical evidence that would allow a pathologist to calculate time of death via rigor mortis or body temperature. With that evidence gone, the only remaining method is stomach contents, which Naomi has already controlled by force-feeding her victim a specific meal at a specific time.

The 200 blows are not a loss of control. They are a calculation. The body is a clock she needed to stop.

The same writer, across three books, returns again and again to the same propositions: that the spaces we live in record what we do inside them, that love is the most dangerous motive, and that the truth always exists in the layer beneath the one you are looking at.

Leave a comment

Who Is Uketsu?

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 and was working at a supermarket when he began posting surreal videos online — asparagus transforming into severed fingers, strips of raw meat pegged 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), published in Japan in 2023 and the English translation arriving in 2026, is a direct sequel to Strange Houses: the same Author-narrator, the same Kurihara, the same project of using architectural floor plans as the primary unit of forensic evidence.

By 2024, three of Uketsu’s novels held simultaneous positions in Japan’s top 10 fiction bestsellers. Strange Pictures alone sold over 1.5 million copies in Japan and has been translated into 30-plus languages.

Strange Buildings is the most ambitious of the three novels covered in this series. Instead of one central case or a quartet of interlocking stories, it presents eleven separate reader-submitted files about architectural anomalies, each one appearing isolated, each one secretly connected to every other. The final reveal is proportionally larger than anything Uketsu had attempted before: a nationwide cult conspiracy encoded physically into 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 has not yet received wide coverage outside Japan. This is the full summary and analysis: all eleven files, the climactic deductions, and the master map of every planted clue and its payoff.

Buildings hide secrets, but so do images—I’ve done a separate deep dive into the hidden clues within Uketsu’s Strange Pictures.

If these building layouts disturbed you, you’ll definitely want to see my summary of the domestic horrors found in Strange Houses.

See how these architectural puzzles fit into a much larger narrative strategy, read my analysis of the patterns that define Uketsu’s work.

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 describes a bizarre architectural anomaly — a hallway that goes nowhere, a building shaped wrong, a room with a door that should not exist. At first glance the cases are entirely unrelated. On examination, they reveal a single story of interconnected crimes spanning decades.

File 1: The Hallway to Nowhere

Plot Summary

Yayoi Negishi, a woman in her thirties, consults the Author about her childhood home in Toyama Prefecture, built in 1990 by a company called Housemaker Misaki. The single-story house had a dead-end hallway tucked between her parents’ room and her own, leading to a wall.

Her mother was cold and distant toward Yayoi but obsessively protective about one thing: Yayoi was prohibited from walking on the main road south of the house. The mother was not anxious generally. Only about that road.

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

Yayoi’s 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. What he finds instead: a child was struck and killed by a Housemaker Misaki construction truck right in front of the home plot in 1990, just before the house was built. 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 moving in, Yayoi’s mother returned to the company and tried to hire them to physically remove Yayoi’s bedroom from the house entirely. An expensive, structurally significant job. The mother could barely afford it. She kept asking anyway.

Literary Analysis

The “hallway to nowhere” is the novel’s entry point into its governing theme: houses as 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.

The wooden doll missing its left arm and right leg is, at this stage in the novel, a grotesque non sequitur. By the final chapter, it is the key to everything.

Connective Tissue

The amputated wooden doll directly prefigures the “Holy Mother” of the Rebirth Congregation introduced in File 6: a woman missing her left arm and right leg who serves as the figurehead of a cult that exploits parental guilt.

Yayoi’s premature birth meant a newborn blood test could not be administered. As Kurihara later deduces, Yayoi was conceived in an affair. The mother’s road prohibition was not about the accident. It was fear that any hospital visit requiring a blood transfusion would reveal Yayoi’s blood type to her husband.

The mother’s desperate attempt to remove Yayoi’s bedroom was an act of cult devotion: the Rebirth Congregation instructed members to physically alter their homes to match the amputated form of the Holy Mother, as a ritual of penance.

File 2: Nurturing Darkness

Plot Summary

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

Iimura provides the floor plan. The house was a mass-produced “commodity home” built by a corporation called Hikura Homes: plumbing crammed into the north side causing mold and persistent odors, no meaningful privacy, bedrooms arranged as through-corridors so everyone passes through everyone else’s space constantly, and the 16-year-old’s living space was 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, shattered by the weight of caring for a bedridden relative in an intolerable home, attacked the grandmother in her sleep. The teenager fought his mother to stop her. He was cut repeatedly. He accidentally killed her in the struggle, and then, in panic and shock, lashed out at 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.

Literary Analysis

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

The “killer teen” framing, which the media used and Iimura initially adopted, is the narrative the architecture wants you to accept. The Author’s forensic re-reading rejects it.

Connective Tissue

Hikura Homes is introduced here as a corporation with a troubling history: rumors in the 1980s about the president “abusing some little girl.” The company’s response to those rumors was not accountability but aggressive media management and reputation control. This “rumor” pays off in File 10 as something far worse: Masahiko Hikura, future chairman, bought a child from a yakuza-operated brothel.

File 3: The Watermill in the Woods

Plot Summary

The Author presents an excerpt from a 1938 travelogue by Uki Mizunashi, a steel magnate’s daughter visiting her uncle’s rural property in Nagano. She discovers a watermill in the forest that has no water source. Turning the massive exterior wheel manually slides an interior wall forward, revealing a hidden, doorless confinement room.

Outside the mill: a small shrine housing a statue of Kishimojin, the goddess of children’s protection. The statue holds fruit. No baby. Inside the mill’s second room: a square alcove exactly sized for a person to curl up in.

When Uki uses the wheel to open the hidden room, she finds the rotting body of something she describes as a “female egret” missing the tip of one wing.

She flees. Her written theory: the mill was a gothic execution chamber, built by a cult, used to crush sinners against the goddess’s image as the mechanical wall slowly advanced.

Literary Analysis

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.

Connective Tissue

The “female egret” is actually the body of Okinu, a maid employed by the Azuma family, identified in File 5. The “missing wingtip” is her severed wrist, consistent with the mechanical wall closing on her arm.

The square alcove inside the mill was not for execution. It was for protection. A baby was hidden in that alcove. That baby is Yaeko, who will lose her left arm when the mechanical wall closes on her as an infant, and who will become the “Holy Mother” of the Rebirth Congregation decades later.

File 4: The Mousetrap House

Plot Summary

Shiori Hayasaka, a wealthy CEO who grew up poor, recounts a middle school trauma: a sleepover at the palatial Tokyo mansion of her classmate Mitsuko Hikura, the daughter of the Hikura Homes president. Grand dual staircases, a massive locked bookcase in Mitsuko’s room, and a grandmother occupying 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 was designed with a wide gap, no wall, no handrail, specifically sized to be hazardous to someone with mobility impairment. Shiori theorizes that Mitsuko stole her grandmother’s walking stick during the night, locked it in the bookcase Shiori could witness was locked, and forced the old woman to navigate the staircase unaided. Shiori’s presence was the alibi.

Literary Analysis

The “mousetrap” architecture proves that Hikura Homes designs murder into residential structures. The family that builds houses weaponizing space for clients also builds houses weaponizing space for themselves: they killed their own grandmother with a floor plan.

What Shiori cannot identify at Mitsuko’s age is the full weight of 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.

Connective Tissue

The grandmother in the long skirts and white gloves hiding her body 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, forcing the old woman to navigate 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. Following the Rebirth Congregation’s dissolution, Yaeko had become a reputational liability for the corporation. The house was built to do the job cleanly.

File 5: The House Where It Happened

Plot Summary

Kenji Hirauchi bought a pre-owned house in the Nagano woods. He checks a crowdsourced dark history app (analogous to real Japan-specific services that log crime and death locations at residential addresses) and 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 the ground floor is entirely windowless and one room has abnormally thick exterior walls. Tapping the walls reveals a hollow space. The Author’s conclusion: this house was built 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 and eventually added a second floor to sell it as a home to people who had no idea what was inside the walls.

Literary Analysis

File 5 is the novel’s “Architectural Uncanny” thesis in its purest form. A modern house sits on modern land. Inside it, through walls too thick to be structurally necessary, is a machine that 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. The people who bought the shell and added the second floor knew what was inside. Kenji did not. This is the generational structure of concealment: each layer of construction is a new generation choosing not to tell the next one.

Connective Tissue

The “female egret” of File 3 is Okinu, confirmed. The alcove was occupied by the baby (Yaeko) who survived. As File 10 will explain, the Hikura family eventually bought this land and built the modern shell around the watermill to create 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

Plot Summary

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 (future Hikura Homes chairman) delivers sermons warning wealthy congregants that their children have 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 screaming at the Holy Mother that she is a fraud, blaming her for his son Naruki’s death, threatening to “seal her heart forever.” He is dragged away.

The cult’s “sacrament” is sleeping overnight 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 identifies the Hall of Rebirth’s architectural secret: the building is not simply 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.

Literary Analysis

This is the structural keystone of the entire novel, placed in the center of 11 files deliberately. Everything in Files 1 through 5 radiates outward from this revelation, and everything in Files 7 through 11 fills in the consequences.

Hikura’s sermon follows the standard cult mechanics: instill guilt (your child’s suffering is your punishment for sin), provide a proprietary cure (reshape your home to match the Holy Mother’s body, using 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. Sleeping in the architecture’s “womb” is sold as spiritual rebirth. It is a Hikura Homes product placement delivered as a religious experience.

Connective Tissue

The Holy Mother’s identity (a woman missing her left arm and right leg) connects to: Yayoi’s amputated wooden doll from File 1, the mechanical wall injury from File 3, the grandmother hiding under long skirts in File 4, and the full revelation in File 10 identifying Yaeko.

The angry man who threatens to “seal her heart forever” is identified by Kurihara as Mr. Kasahara, the father from Files 7 and 8. His son Naruki is the child whose journal fills File 7. His threat is fulfilled literally: he later commits suicide in the sealed shrine room of his own remodeled home.

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

File 7: Uncle’s House

Plot Summary

File 7 is the published journal of Naruki Mitsuhashi, a nine-year-old boy who died of severe neglect and abuse in 1994. His entries describe his mother pinching his nose shut when he asks for food, and their visits to a wealthy man he calls “Uncle” who feeds him and gives him a bedroom. Naruki notices “Uncle’s” house changing 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 become shorter, the handwriting deteriorating, until they stop.

Literary Analysis

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 has spent six files building a theory of architecture as psychology. Here, that theory is made unbearable: the spaces children inhabit actively determine whether they survive.

Connective Tissue

“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 was removing interior space to reshape his home into the Holy Mother’s amputated form. His warning about the “heart room” reflects the cult’s belief that locking the shrine room “seals the heart” and kills everything inside.

File 8: The String Phone

Plot Summary

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

One night, talking on the string phone, her father’s voice went incoherent. A strange rustling. Minutes later, the house next door, belonging to the Matsue family, burst into flames. Mrs. Matsue was found dead in her closet. Ruled suicide.

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

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

Literary Analysis

The string phone is a precisely selected symbol: the most innocent possible childhood object, an artifact of parental tenderness, repurposed into a tool of deception. Kasahara used his daughter’s fear of the dark and her need for comfort to establish an alibi for himself, whether or not that alibi was for what Chie believes it was for.

The identical clone houses in the suburban development represent the same logic as the mass-produced Tsuhara house: uniform exteriors, fractured interiors. Everyone in these identical houses is living through something nobody else can see.

Connective Tissue

Kurihara’s resolution of Chie’s theory is that she had the facts right but the conclusion wrong. Her father was not murdering Mrs. Matsue from the adjoining room. He was in Mrs. Matsue’s house because they were having an affair. The rustling incoherence Chie heard through the string phone was Kasahara discovering his mistress’s suicide note and her dead body, and panicking.

Kasahara’s subsequent withdrawal and suicide (in a sealed room, with a strange doll and a photo of Naruki) is the direct aftermath of File 7: devastated by the death of his illegitimate son through the hands of people he could not stop, Kasahara sealed the shrine room (the “heart”) of his own house in a gesture of mutual destruction against the cult’s fiction, and then killed himself.

File 9: Footsteps to Murder

Plot Summary

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

Hiroki’s theory: his father drugged his mother, carried her to the closet, set the fire, and staged the discovery to explain why he couldn’t save her. He put her in the closet knowing Hiroki would assume she was asphyxiated where she slept.

In a final revelation, Hiroki notes that he and Chie Kasahara are still in contact, that both suspect their own fathers, and that he knows the Author was not entirely honest about his journalistic purposes in contacting them.

Literary Analysis

The competing narratives of Files 8 and 9 are Uketsu’s Rashomon. Two children of the same event, both convinced their father was a murderer, both partially right and both fatally wrong. The crucifix handed to Hiroki is the novel’s most pointed religious symbol: the weight of his father’s faith was so heavy it became a motive for murder.

Connective Tissue

Kurihara’s reconstruction: 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 his wife had been pregnant with another man’s child. His Christian devoutness could not tolerate his son growing up with that knowledge attached to the family name. He burned the house to destroy the forensic evidence of the pregnancy, using the closet as an impromptu crematorium, and died trying to appear as a man running back into a fire to save his wife.

File 10: No Escape

Plot Summary

Akemi Nishiharu, an elderly izakaya owner, recounts being bankrupted in her twenties and forced by yakuza debt collectors into an “okito,” a concealed brothel disguised as an ordinary residential building. The architectural design of the okito prevented escape: mothers could only leave if they 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 young daughter, approximately 11 years old. 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. He was the one being prostituted. His run into traffic was a suicide attempt. And Hikura did not take Yaeko. He bought Yaeko’s 11-year-old daughter.

Literary Analysis

The unreliable narrator reveals itself slowly here. Akemi’s sanitized memory is not deception: it is the protective narrative a mother constructs to survive the knowledge of what was done to her child. Mitsuru’s correction does not condemn his mother. He explains it.

The okito’s architectural design is the novel’s most concentrated statement on systemic oppression. The building is engineered for captivity using the one leverage available: children as collateral. The architecture does not hold people with walls. It holds them with the threat of what will happen to someone else’s child.

Connective Tissue

This file provides the complete origin story for the Holy Mother: Yaeko enters the narrative with one missing arm (the mechanical wall injury from File 3) and loses a second limb saving a child. She is then bought by Masahiko Hikura, who will eventually install her as the figurehead of the Rebirth Congregation, her real mutilation presented as sacred stigmata.

The “dark rumors” about Hikura’s abuse of a young girl, introduced as whisper in File 2, are confirmed here as something far more specific and criminal.

File 11: The Vanishing Room

Plot Summary

Freelance designer Ren Iruma reports a childhood memory: at age six, during a dizzy spell, a door appeared in his hallway. Behind it, a freezing one-square-meter room with a terrifying object in a wooden box. The next day, no door. 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 open a mechanism in the wall: a metal plate that acts as a magnetic latch. Using a strong neodymium magnet, the Author slides the hidden door open.

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

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

Literary Analysis

File 11 brings the unheimlich full circle. The domestic space Iruma grew up in was not a home. It was a monument. His father built it as a cult devotional object, shaped around the amputated form of the Holy Mother, with a hidden room at its “heart” containing her effigy. Iruma crawled around that effigy as a six-year-old with a dizzy spell and then lived alongside it, invisible in the wall, for decades.

The neodymium magnet is the satisfying technical payoff for a detail planted many files earlier: Iruma’s offhand mention that his father worked in product design involving rare earth materials.

Kurihara’s Deductions

Plot Summary

The Author presents all eleven files to Kurihara. Kurihara maps the geographic locations of every house and building, revealing that 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 (whom his own family had bought from a brothel as a child) as the “Holy Mother.” The congregation exploited parents who were carrying the guilt of illegitimate children, extramarital affairs, or children born with disabilities. Hikura Homes sold them an architectural solution: remodel your home to structurally resemble Yaeko’s mutilated body, and your child will receive 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: she was born to Okinu inside the mechanical wall chamber, her arm severed by the wall, which reactivated as her dying mother tried to hide her. 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 had hidden Yaeko’s prosthetic leg while Yaeko slept. She did not act on her parents’ instructions. She acted in self-defense. 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 has been living with that calculus ever since.

Literary Analysis

Kurihara’s deduction sequence makes explicit what the novel has been arguing architecturally for eleven files: the houses are not cases. They are symptoms. Every bizarre floor plan, every removed room, every blocked window is a physical manifestation of guilt, coercion, or grief.

Mitsuko’s confession completes the novel’s moral geometry. She was not following orders. She was a child protecting herself from abusive parents by eliminating the one person in the house who loved Yaeko enough to be a problem. The cycle of abuse initiated by Masahiko Hikura, the man who bought a child from a brothel and installed her as a goddess, reaches its end in his own granddaughter killing the only person who ever protected her.

Connective Tissue

Mr. Kasahara from File 8 is confirmed as “Uncle” from File 7. His suicide in the sealed room, with the strange doll and the photo of Naruki, is the direct consequence of the cult’s collapse intersecting with his son’s death: the cult was a fraud, he could not save Naruki, and he sealed the “heart” of his own shrine-house as a final act of symbolic murder against the fiction that failed everyone.

The Matsue fire from Files 8 and 9 is fully resolved: Mrs. Matsue committed suicide after learning her pregnancy (with Kasahara’s child) would destroy her family. Mr. Matsue burned the house not to hide a murder but to destroy the forensic evidence of the affair and protect his son from the knowledge attached to his and his wife’s death.

Master Map: Planted Clues and Their Payoffs

The Clue Tracker

The Amputated Wooden Doll (File 1) → The Holy Mother (Files 6, 10)
The wooden doll missing its left arm and right leg found in the Negishi family’s belongings is not a curiosity. It is the physical representation of Yaeko’s mutilated body, the central religious icon of the Rebirth Congregation. The Negishi mother was a cult member.

The Main Road Prohibition (File 1) → Hidden Paternity (Kurihara’s Deductions)
The mother was not protecting Yayoi from traffic. A traffic accident would require a hospital visit and potentially a blood transfusion. The blood test would reveal Yayoi’s blood type did not match her legal father’s. Yayoi was born of an affair, and the mother spent 30 years managing the architectural and behavioral consequences of that secret.

The Hikura Homes Abuse Rumor (File 2) → The Brothel Transaction (File 10)
The “rumor” that the Hikura Homes president abused a young girl is confirmed in File 10 as Masahiko Hikura buying an 11-year-old girl from a yakuza-operated pedophile brothel and subsequently marrying her when she came of age.

The Slack String on the String Phone (File 8) → The Affair Alibi (Kurihara’s Deductions)
Chie measures the string phone and realizes it is too long for two adjacent rooms. Her theory — that her father was in the adjacent room faking an alibi while committing murder next door — is half right. Her father was in the adjacent building. He was not there to commit murder. He was there because he was having an affair, and the rustling incoherence Chie heard through the string phone was him discovering a dead body.

The Windowless Rooms, Dead-End Hallways, and Blocked Windows (Files 1, 5, 11) → Cult Architectural Conformity (File 6, Deductions)
Every case in the novel with a mysteriously removed room, a bricked-over window, or a dead-end passageway connects to the Rebirth Congregation’s architectural mandate. Members paid Hikura Homes to surgically alter their homes into the body shape of the Holy Mother. The houses were not haunted. They were penitential.

Thematic Resonance: How the Ending Shatters the Beginning

Strange Buildings begins as a collection of quirky, isolated puzzles about strange houses. By the final Kurihara deduction sequence, every puzzle is revealed to be a node in a nationwide conspiracy designed by one corporation to exploit guilt and sell architecture.

The novel’s final moral position is stark. Houses are neutral physical objects. They mean what the people who design them intend them to mean. When a corporation decides to industrialize guilt and sell architectural penance as a product, every house it touches becomes a crime scene, and the victims are not the people who died. The victims are the people who lived inside those houses, shaped by spaces designed to keep them ashamed and afraid and paying.

A house is meant to be a sanctuary. Uketsu’s complete argument, across three novels, is that a house is only a sanctuary if the people who designed it wanted you to be safe. When they did not, the walls hold the evidence.

Structural Relational Analysis

Files 1, 2, and 5: Isolated case studies. They establish the architectural anomaly pattern and plant the critical objects (the doll, the Hikura Homes name, the watermill) without context.

File 6 (The Hall of Rebirth): The structural keystone, placed dead center. It provides the cult’s floor plan: the ideological and architectural blueprint that makes every other case comprehensible.

Files 7, 8, and 9: A triptych of intersecting perspectives. Three people’s accounts of the same tragedy — the Matsue fire and Naruki’s death — demonstrate that geographic proximity creates narrative density. These three files are not separate cases. They are the same neighborhood, the same 48 hours, seen from three different upstairs windows.

Files 10 and 11: The origin layers. File 10 traces the Holy Mother’s life backward to the brothel. File 11 confirms the cult’s reach into a present-day home that an ordinary person is currently living in.

Kurihara’s Deductions: The zoom-out. Every isolated bubble becomes a node. The map of Japan’s Nagano region shows eleven distinct properties, all orbiting one address: the Hall of Rebirth.

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 simultaneously and trust that they connect. They do, and the connection reveals something specific about how institutional power uses architecture: not just to imprison people, but to convince them that the imprisonment is their own fault, and that paying to reshape the walls will fix it.

Leave a comment

Who Is Uketsu?

Uketsu (雨穴, “rain hole”) is a Japanese author and YouTuber whose real identity remains 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 spent part of his childhood in Surrey, England, and was working at a supermarket when he started posting on YouTube.

His early videos were surreal: asparagus transforming into severed fingers, strips of raw meat pegged on a washing line, spinning human ears. 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. Strange Pictures came after (2022), and Strange Buildings, a direct sequel to this book, followed in 2023. By 2024, three of Uketsu’s novels occupied simultaneous positions in Japan’s top 10 fiction bestsellers. The English translation of Strange Houses (published in 2025 by Pushkin Press) arrived to an anglophone market that had already been primed by the breakout success of Strange Pictures.

The formal concept behind Strange Houses is the one that made Uketsu’s YouTube channel successful: architecture as a text. A house floor plan, properly read, tells you things about the people who designed it that they would never say aloud.

Why This Summary and Analysis Exists

There is no thorough English-language, chapter-level breakdown of Strange Houses available. The book’s premise sounds like a puzzle box, and it is one, but the puzzle is more architecturally and psychologically layered than most reviews suggest. This is the complete summary and analysis, from Chapter One through the Afterword, with the full master map of connective threads at the end.

Buildings hide secrets, but so do images—I’ve done a separate deep dive into the hidden clues within Uketsu’s Strange Pictures.

Once you’ve navigated these homes, you'll want to explore the even larger scale of dread I covered in the Strange Buildings summary

To see how these architectural puzzles fit into a much larger narrative strategy, read my analysis of the patterns that define Uketsu’s work.

This piece contains complete spoilers for the entire novel.

Chapter One: A Strange House

Plot Summary

A freelance writer who specializes in the macabre (the Author) is approached by his acquaintance Yanaoka, who is looking to purchase 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, there is a section of the house that has no doors, no windows, and no access. A dead space. Built in, walled off, sealed.

The Author, lacking architectural training, brings the floor plans to Kurihara, an architectural draughtsman and fellow mystery enthusiast. Kurihara is methodical. He notes that the dead space was created intentionally: two additional walls were constructed specifically to block it off, at the cost of reducing the kitchen’s floor area. Why would a builder voluntarily 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. No windows at all. An en-suite toilet ensures the child never needs to leave. The room is accessible only through a double-door vestibule, a pair of sequential doors that create 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 the corners of the child’s windowless room and the windowless bathroom. The dead zone is not a void. It is a vertical tunnel connecting the two.

Kurihara constructs a scenario. The parents bring someone home, get them drunk, suggest a bath. The imprisoned child in the bedroom drops through a trapdoor, uses the dead space as a vertical access shaft, enters the bathroom from below, and kills the naked and defenseless guest. Dismemberment occurs. Body parts are passed back through the tunnel to a storage room near the garage. Disposal by vehicle.

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.

Literary Analysis

The novel’s central conceit is established in pure form here: architecture as antagonist, floor plans as criminal evidence. The “Architectural Uncanny” (the Freudian unheimlich applied to domestic space, the familiar home becoming deeply wrong) runs through every page of this chapter. The genius of the setup is that Kurihara cannot be certain. He is constructing a narrative from empty geometric shapes. He may be wrong. The dismembered body at the chapter’s end is not confirmation that the specific murder scenario he described occurred. It is only confirmation that something terrible happened near that house.

Uketsu establishes his structural template here: the Author presents the Reader with a floor plan, Kurihara decodes it, and the Reader and Author arrive at a horrifying conclusion together. The 16 windows are the move that elevates the chapter from puzzle to literary statement. A house that decorates its exterior with abundance while hiding its interior in darkness is a house that has thought carefully about the optics of concealment.

Connective Tissue

The sealed dead space foreshadows the jammed fusuma doors in Chapter Three and the broader theme of the Katabuchi family’s architectural obsession: hidden passages as standard operating procedure across generations.

The missing left hand is the chapter’s most important planted clue. The Author briefly considers whether the body was dismembered to fit through the narrow passageways, which is the obvious interpretation and a red herring. The missing left hand is not a disposal problem. It is a ritual requirement, the “Offering,” which will become the structural center of the entire novel’s second half.

The 16 windows establish the Katabuchi family’s survival strategy for the rest of the book: performance of normalcy so complete and deliberate that it becomes its own kind of evidence.

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 on the second floor, a windowless bathroom on the first floor, a dead space acting as a connection between them. But there are significant differences.

No garage. This explains why Kyoichi’s body was found intact rather than dismembered: the Saitama house had no good vehicle-accessible dismemberment and disposal route.

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, there is a bizarre retrofitted triangular room with large windows that are blocked by walls, making the room completely useless. It occupies space that previously opened onto the garden.

Kurihara identifies the triangular room’s function: it was built over a section of the garden after the original building was completed. 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: a pale, strange boy, approximately ten years old, sitting 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: the Saitama house was originally built for the parents and Child X. When Hiroto was born, they added the triangular nursery room to keep the baby separate from the murder mechanics. Later, the Tokyo house was designed explicitly to manage both children simultaneously: the heavy double vestibule keeps X and Hiroto from ever sharing the same space. The double bed in Tokyo is for the mother and Hiroto, 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.

Literary Analysis

This chapter introduces the novel’s most destabilizing structural move: the revelation that the architecture has been evolving to accommodate an expanding moral crisis. The Saitama house and the Tokyo house are not two separate crimes. They are two versions of the same insane problem, and each house physically reflects the exact state of the parents’ psychology at the time it was built.

Yuzuki’s false identity mirrors the architectural theme directly. She presents a false floor plan of her own life to gain access to the investigation, the same way the Katabuchi family constructs false floor plans to hide their crimes. Even the people in this novel perform spatial deception.

The introduction of Hiroto demolishes the reader’s stable moral framework. The parents are no longer simply sociopathic architects running a murder factory. They are people who are also raising a baby with apparent tenderness, building him a sunny nursery with pretty windows, sleeping next to him to keep him safe. The house holds both realities simultaneously. The Light Face and the Dark Face occupy the same square footage.

Connective Tissue

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 is reframed as a quarantine mechanism to keep the imprisoned child away from the innocent infant. The architecture has not changed. The interpretation has. This is the novel’s mirror of its own structural project: the same floor plan means something different on the second pass.

The pale boy seen through the window will be explained in Chapter Four: it is Momoya, the imprisoned child, using the hidden passage not to kill, but to reach the mother’s room and place a damp cloth on the feverish baby’s forehead. It is the first clear evidence that Momoya is not a monster.

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: a large, highly symmetrical house divided evenly by a long central corridor with a massive, immovable black Buddhist altar at its 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 — he must have climbed the altar and fallen — and actively 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. There is a set of fusuma (Japanese sliding doors) that are permanently jammed shut. Kurihara traces the structure’s hidden layout: a confinement room exists behind the altar, accessible only through the secondary passage masked by the jammed fusuma.

His reconstruction: Yoichi did not fall. A family member took Yoichi in the night, pulled him through the passage into the hidden confinement room (which would have muffled sounds completely, with no windows), killed him, and placed his body at the altar to stage the accident. No police investigation. Clean closure.

Yuzuki acknowledges this. Her own father was likely responsible, operating to manipulate the family’s line of inheritance in a way that would ultimately result in her sister Ayano being surrendered to the main Katabuchi family, to be indoctrinated and tasked with serving as a warden for disabled children.

Her father eventually lost his mind and died by suicide.

Literary Analysis

Chapter Three shifts the novel from modern procedural mystery into Gothic horror, and the transition is earned. The ancestral estate functions as the Katabuchi family’s architectural origin myth: the jammed fusuma, the hidden room, the windowless wing are not recent innovations. They are centuries of accumulated spatial habit. The family has been building these rooms for generations.

The massive altar at the center of the house is the novel’s most potent symbol. It physically dominates the floor plan, positioned at the geometric center of the corridor so that movement through the house requires passing around it. The family cannot go from one side of its own home to the other without acknowledging the altar’s presence. Ancestral weight made architectural.

Yuzuki’s father is a genuinely tragic figure, an ordinary person who committed a monstrous act under the delusion that he was protecting his family, and who could not survive the weight of what he had done. He is an early version of Keita, the figure the novel will examine with much more patience in Chapter Four.

Connective Tissue

The ancestral estate is the direct architectural prototype for every house in the novel. The jammed fusuma function as the same hidden passage system used in the modern Tokyo and Saitama houses. The windowless rooms on the right side of the estate are the prototype for the windowless child’s prisons in every subsequent Katabuchi dwelling. The confinement room behind the altar is the prototype for the entire murder tunnel concept. The family did not invent this. They inherited it. They could not stop building it.

Chapter Four: House of Chains

Plot Summary

The Author and Yuzuki visit her estranged mother, Yoshie. Yoshie produces a letter, written in full by Ayano’s husband, Keita, meant 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 (actually a woman named Shizuko from a rival branch of the family, orchestrating generational revenge) convinced Soichiro that Momota’s deformity was Ushio’s supernatural punishment. Rankyo established what became the “Offering of the Left Hand”: any Katabuchi child born with a missing left hand must be imprisoned from childhood, and between the ages of 10 and 13 must murder a descendant of the rival branch and 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 designed to simulate compliance with the ritual while faking it entirely. Keita scavenged the intact bodies of suicide victims, specifically Kyoichi Miyae, a bachelor who jumped from a bridge, and 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 is lying 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 was seeing 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.

Literary Analysis

Chapter Four is where the novel entirely reframes its moral architecture. The “monsters” living in the houses, Ayano, Keita, and Momoya, are victims. The architecture designed to imprison and kill was repurposed by Keita into a theatrical prop, a stage set for a performance of compliance that kept the family alive.

Keita is the inverse of every Katabuchi ancestor. Where 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.

Momoya nursing the sick baby shatters whatever remained of the reader’s horror at the imprisoned child. The narrative has been conditioning the reader to understand Momoya as a dangerous unknown, a pale figure glimpsed through windows, the engine of a murder factory. He is 10 years old, he has never killed anyone, and when he escapes his room for the first time, he tends to a sick infant.

The chapter’s catharsis is deliberately incomplete. Keita’s disappearance does not resolve anything except the immediate threat. The houses are destroyed, the enforcers are dead, but the family structure that produced the ritual, the centuries of architectural tradition, the incestuous origin of the curse, all of it simply continues.

Connective Tissue

All the missing left hands are accounted for: the unidentified Chapter One body (an earlier ritual victim or another scavenged suicide, unexplained by Keita’s letter), Kyoichi’s severed hand (a scavenged suicide victim presented as an Offering), and the ritual’s centuries of accumulated demands. The body in Chapter One with the missing left hand was the establishment of the mystery. Keita’s confession resolves the Kyoichi case but deliberately does not resolve the Chapter One case.

The double vestibule receives its final and most layered meaning. It was not to imprison X. It was a quarantine to protect Hiroto from knowing what was behind that door, and to protect Momoya from knowing the full extent of the disparity between how they were each being raised.

Afterword: Kurihara

Plot Summary

Kurihara meets the Author one final time. He says: case closed, 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.

Interior windows destroy privacy. They exist for one purpose: observation. Keita’s letter describes him as a heroic figure who built the houses to protect his family. But Kurihara asks whether Keita was actually a prisoner himself, a man trapped by the Katabuchi family and watched constantly by Ayano through that observation window.

The possibility inverts the narrative of Chapter Four entirely. What Keita presented as a story of agency and sacrifice may be a story of coercion with a heroic gloss painted over it.

And then Kurihara 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 novel does not close.

Literary Analysis

The Afterword is the novel’s best move. Uketsu has spent 200 pages maneuvering the reader toward a tragic but emotionally satisfying resolution: the monsters are actually victims, the imprisoned child is gentle, the father sacrificed himself for his family. It is the kind of ending that lets readers feel sad but resolved.

The Afterword strips that away in four pages. Not through a dramatic twist, but through Kurihara pointing at a window and asking one question. The interior observation window is a small architectural detail, the kind of thing a reader would skip past. Kurihara does not skip past anything.

The final effect is the book’s thesis made explicit: a floor plan looks simple until someone who knows how to read it tells you what it actually means.

Connective Tissue

The interior window loops the novel back to Chapter One’s foundational instruction: look at the floor plan again, something is wrong, you missed it. The reader had the Tokyo house’s floor plan available from Chapter One. The window was there the whole time. Nobody looked at it.

The unresolved Chapter One dismemberment confirms that the neat resolution of Chapter Four was never the full story. The house confessed to some of its crimes. Not all of them.

Master Map: Planted Clues and Their Payoffs

The Clue Tracker

The Missing Left Hand (Chapter 1) → The Offering (Chapter 4)
A single detail on an unidentified body seems like a disposal problem. It is actually a religious requirement, the “Offering of the Left Hand,” the ritual demand at the center of a century-old family curse rooted in incest and fabricated superstition.

Intact vs. Dismembered Corpses (Chapters 1 & 2) → Two Murder Methods (Chapter 4)
Chapter 1’s victim was chopped apart. Chapter 2’s victim (Kyoichi) was whole, only the hand taken. Kurihara traces the architectural difference back to the mechanical difference: the Tokyo house had a garage and a disposal system designed for dismemberment; the Saitama house had an underground cellar designed for whole-body storage. The state of the corpses was dictated by the floor plan of the house used to process them.

The Jammed Fusuma (Chapter 3) → The Architectural DNA (Chapters 1 & 2)
The permanently jammed sliding doors in the ancestral estate look like a quirk of an old house. They are the prototype for every hidden passage in the modern houses. The Katabuchi family has been building these specific architectural elements for generations. It is structural habit, passed down like a genetic trait.

The Pale Boy in the Window (Chapter 2) → Momoya Nursing Hiroto (Chapter 4)
The neighbor’s sighting of the pale boy on the parents’ bed is framed throughout the middle section of the book as the behavior of a dangerous, unpredictable prisoner. It is actually the precise moment Momoya’s humanity is demonstrated: he has navigated the secret passage not to hurt anyone, but to care for a sick infant who is not, technically, related to him.

The Triangular Room’s Blocked Windows (Chapter 2) → The Underground Cellar (Chapter 4)
The retrofitted triangular nursery with its uselessly blocked windows does not make architectural sense until the cellar beneath it is discovered. The large windows were added for the baby’s nursery, then blocked when the function of the space underneath required secrecy. The architecture records the change in purpose.

Thematic Resonance: 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: how the sins of an ancestor are literally encoded into the walls of every building their descendants are forced to construct, generation after generation, because no one in the family was ever able to say “stop.”

The floor plan of the Katabuchi lineage dictates the physical floor plans of the homes they build. The incest and suicide of the founding generation produced a deformed child, and the deformed child produced a ritual, and the ritual produced a building type, and the building type became tradition, and the tradition imprisoned every generation that followed. The houses are the family.

Keita’s theatrical set was the first act of genuine refusal in the entire lineage. He built the same structures his ancestors built, but he built them to protect the child rather than destroy him. The structures looked identical. The moral content was entirely different. That distinction costs him everything.

Structural Relational Analysis

Chapter 1: One floor plan, one dead space, one missing left hand. A tightly scoped introduction to the core architectural puzzle.

Chapter 2: Two floor plans, two timelines, two houses that tell the story of a family expanding and adapting its crimes to new circumstances. Introduces the human beings behind the architecture.

Chapter 3: One ancestral estate, one hidden room, one murdered child. Zooms back decades to the source code of the family’s architectural obsession.

Chapter 4: The complete family tree, the complete history of the ritual, the complete explanation of every house in the novel. Zooms all the way out. The houses were not designed by killers. They were designed by trapped people who were themselves designed by the houses they grew up in.

Afterword: One small window. One unanswered question. The floor plan of the entire novel is pulled back to reveal a dead space you missed.

The English translation of Strange Houses (Pushkin Press, 2025) features the original floor plan diagrams embedded in the text as intended, which is important. This is a novel you read with a pen. The floor plans are not illustrations. They are evidence.

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 who appears in public wearing a white papier-mache mask, a black bodysuit, and a voice changer that modulates his voice to sound something between mechanical and childlike. His true identity is known to roughly 30 people — his family, 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 was working at a supermarket when he began posting online. That is more or less the complete profile.

His early YouTube videos were surreal: asparagus that transforms into severed fingers when chopped, strips of raw meat pegged out on a washing line, eight human ears spinning 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 of Uketsu’s books occupied simultaneous slots in Japan’s top 10 fiction bestsellers. Strange Pictures (変な絵, Hen na e), published in Japan in 2022 and translated into English by Jim Rion in January 2025, sold over 1.5 million copies in Japan alone and has been translated into 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, plot summaries exist, but nothing that maps the structural puzzle, traces the planted clues back to their payoffs, and explains why this book works the way it does. That is what this piece is. It is the complete summary and analysis, chapter by chapter, with a full master map of narrative threads 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.

If you think these sketches are unsettling, you need to see the architectural nightmares I’ve deconstructed in my deep dive into Strange Houses.

The mystery doesn’t stop at art; I have also analyzed the terrifying structural anomalies in Uketsu’s Strange Buildings—check it out here.

To understand the ‘why’ behind these eerie visuals, I’ve put together a full breakdown of the recurrent themes and patterns Uketsu uses to keep us on edge.

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, a former practicing psychologist, presents her students with a drawing made by an eleven-year-old patient she calls “Little A.” The child was institutionalized after murdering her abusive mother. The drawing was produced via 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 being forced to smile constantly to appease 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, a trait frequently observed in drawings produced by violent offenders, indicating 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 uses the prologue to lay a false foundation with complete structural confidence. He introduces the novel’s core motif, ekphrasis (the literary representation of visual art as a narrative device), and establishes the governing rule of this fictional universe: drawings reveal what words cannot. The reader accepts the framework because Dr. Hagio presents it with clinical authority. She is credentialed. She is correct about the smudging, the doorless house, the thorny branches. Three out of four.

The fourth interpretation, the bird as proof of nurturing instinct, is the one that kills people.

This is the book’s most elegant structural trick. Uketsu teaches the reader to trust psychological interpretation in the opening pages, then spends the rest of the novel proving that trust is precisely what gets everyone killed.

Connective Tissue

“Little A” is later revealed to be Naomi Konno, the central antagonist. Dr. Hagio’s diagnosis that Naomi’s nurturing instinct would override her aggression was not just wrong. It was catastrophically inverted. The bird in the hollow does not represent love softening violence. The thorns protect the bird. Naomi’s maternal obsession is the mechanism of her murders: she kills everyone who threatens what she has claimed as hers.

Chapter One: The Old Woman’s Prayer

Plot Summary

On May 19, 2014, Shuhei Sasaki, a 21-year-old college student, investigates a defunct blog recommended by Kurihara, a junior in his Paranormal Club. The blog, titled “Oh No, Not Raku!”, was written by a man using the pseudonym “Raku.” Its subject: 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. Addressed “To the one I love most,” the post says Raku has finally decoded “the secret of those three drawings,” that he cannot forgive his wife’s “sin,” and that he still loves her. Then nothing.

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” — 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: 8 slices, Raku eats 2, Yuki eats 1, 4 are saved, one 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. The composite image is the worst thing in the book: 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 walking away together, hand in hand. Yuki drew a future she would not be alive to see.

Literary Analysis

Uketsu deploys an epistolary format here: the entire chapter is mediated through the text of an old blog. This is the most technically restrained chapter in the book, and the most effective for it. The horror is assembled from mundane domestic posts. The reader and Sasaki are doing the same thing at the same time, reading forward through ordinary life and feeling the wrongness accumulate.

Kurihara functions as the Holmesian catalyst. He is not a lead character. He is the engine of deduction that forces Sasaki past passive reading into active forensic analysis. The composite drawing introduces a structural metaphor that governs the entire novel: reality changes entirely depending on how you layer the information. Every chapter in this book is a “drawing” that means something different when stacked against the others.

Connective Tissue

The missing cake slice establishes that a hidden third person was living with Raku and Yuki. That person is Naomi, Raku’s mother, whose presence in the household is kept entirely offscreen until the Final Chapter. The warning Raku received (about not posting personal photos online) came from someone other than Yuki, another trace of Naomi’s invisible influence.

Yuki’s excessive thirst is a forensic plant. In the Final Chapter, we learn Naomi was replacing Yuki’s prenatal iron supplements with 15 grams of pure salt daily, inducing the hypertension that would kill her on the delivery table.

No responsible modern obstetrician recommends natural delivery for a breech presentation. Kurihara notes this. The payoff: Naomi was the senior midwife at the clinic, with enough institutional authority to overrule the attending physician.

The blog title, “Oh No, Not Raku!,” is a direct anagram of “Haruto Konno.” Raku is not Raku. He is Haruto Konno, Yuta’s father, whose death by suicide explains why the blog went permanently dark in 2012.

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 her scolding Yuta harshly for using 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, but their specific sixth-floor room has been violently smeared over with a grey blotch. Haruoka investigates the mechanics. Yuta did not use a grey crayon. He used a white crayon over a black underdrawing, the pressing and smearing mixing the pigments into an opaque grey. A classmate, Miu Yonezawa, volunteers that Yuta’s original drawing showed a large rectangle with a small triangle inside, before he erased it.

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

Naomi realizes Haruoka has misread the drawing. The rectangle and the triangle are not a stencil ruler. They are the kanji 今野, the characters for “Konno,” which looks like a triangle sitting above a rectangle. Yuta was attempting to draw a gravestone, his mother’s gravestone. Naomi deduces that Yuta has been sneaking to Sakura Memorial Garden, where he has 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.

Literary Analysis

Chapter Two is a study in dramatic irony operating at high efficiency. The reader knows Naomi is dangerous by the time this chapter begins. Uketsu uses that knowledge to manufacture a deeply uncomfortable sympathy: Naomi is also exhausted, isolated, and being falsely accused of abusing her son. The reader is asked to feel bad for a woman who is about to stab someone.

Haruoka mirrors Dr. Hagio precisely. She uses the same theoretical framework — art as expression of subconscious trauma — and reaches an equally wrong conclusion. Uketsu is deliberate about this repetition. The novel is asking whether the problem is the framework or the practitioners. The answer it gives is: the framework.

Yuta’s smeared drawing is the novel’s second major piece of ekphrasis. The grey blotch does not represent the stencil ruler, and it does not represent abuse. It represents Yuta desperately trying to erase a present reality and access a buried one. He is trying to draw through it, to the name of the dead woman he has never been allowed to know was his mother.

Connective Tissue

This chapter confirms Yuta is the baby from Chapter One, the child who survived Yuki’s murder on the operating table.

It establishes Naomi’s identity as Haruto’s mother, not Yuki’s. She is therefore the “old woman praying” in Yuki’s composite drawing — the figure with both hands reaching into a surgical incision, yes, but also the grandmother who will raise the child as her own.

Haruto’s sequence becomes clear here. He deciphered Yuki’s drawings. He took Yuta to his mother’s grave, a final act of fatherly honesty. He wrote his last blog post. Then he killed himself.

The man Naomi stabs is Isamu Kumai, a veteran reporter introduced formally in Chapter Three. He survived. His “stalking” of Naomi was deliberate provocation, designed to trigger the violent reaction that would give his police contact, Detective Kurata, grounds to arrest her.

When threatened, Naomi does not call the police. She picks up a knife. This is how she has always operated.

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, placed in the administrative department of the L-Daily newspaper after failing to land a reporting position. 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, beaten with a rock more than two hundred times, rendering it completely unidentifiable. The degree of mutilation forced the pathologist to rely entirely on stomach contents to estimate the time of death: Miura ate a Hanayagi bento box, and digestion placed his death at 5:00 PM on September 20. This timeline cleared Miura’s wife (alibi for the morning of the 21st) and a student named Yuki Kameido (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. Additionally, Miura had 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 and encounters 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 landscape in those conditions.

He deduces the actual sequence: the killer captured Miura, restrained him in his own sleeping bag through the night, and force-fed him the Hanayagi bento the next morning (disguising the forced feeding as normal consumption). Two and a half hours after the meal, the killer murdered Miura and 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 earlier than it occurred, pushing it into the time window when 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.

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

Literary Analysis

This is the chapter where the novel changes genre mid-stride. The domestic thriller disappears and a hardboiled forensic procedural takes over. The shift is jarring in the best way: the stakes recalibrate completely. What began as an internet mystery about a defunct blog is now a story about a nineteen-year-old trying to solve a three-year-old mountain murder and getting killed for coming too close.

Uketsu subverts the alibi-trick trope in a way that recontextualizes every element of the crime scene that seemed emotionally charged. The 200-plus blows with a rock are not violence born from hatred. They are a technical requirement. They exist to prevent the pathologist from using body temperature or rigor mortis to triangulate time of death, forcing him to rely entirely on the one piece of forensic evidence the killer controlled: the bento.

Iwata’s “dying message,” the blind folded-receipt drawing, mirrors Yuki’s compositional drawings from Chapter One. Again: art as the only available testimony when speech is impossible. The novel circles back to its own premise.

Connective Tissue

This chapter reveals who Kumai is: the grey-coated stalker from Chapter Two. He survived. His cancer is still progressing. His plan was to provoke Naomi into an attack he could turn into legal evidence, avenging Iwata’s death before his own runs out.

The fake suicide note typed on a brand-new word processor is a deliberately planted clue: a real suicide note would be handwritten. The new word processor 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. When 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. Terrified that her juvenile record would cost her custody of Haruto in any divorce, Naomi 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. Not just to help raise it. To own it.

Using her medical knowledge, she replaced Yuki’s prenatal iron supplements with 15-gram daily doses of sodium chloride. 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. Not about the smudging or the doorless house or the thorny branches. About the bird. She assumed the bird represented the capacity for nurturing, a force that would soften the aggression. She had the causality backwards. The thorns do not sit beside the bird by accident. The thorns exist to protect the bird. Naomi’s maternal love is not the thing that redeems her violence. It is the engine of it.

Kumai, recovering in the hospital, shares a room with Kurihara (from Chapter One). Kurihara explains the blog’s mysteries. Kumai, whose cancer is advanced and whose life is effectively over, adopts the newly orphaned Yuta to break the cycle.

Literary Analysis

The Final Chapter resolves the novel as a psychological horror story masquerading as a mystery. Naomi is not a mystery to be solved. She is a psychological profile to be understood. The resolution does not comfort.

Uketsu does something technically interesting with the moral framing. Naomi’s first three murders are arranged to invite sympathy: she killed an abusive mother to save a defenseless bird, she killed an abusive husband to protect a vulnerable child, she killed a blackmailer to protect an innocent life. The pattern is consistent enough that the reader has to actively resist the framing. Then comes Yuki’s murder, which breaks the pattern cleanly. Yuki was not threatening Haruto. Yuki was simply in the way of Naomi’s ownership of a new person to possess. The novel’s moral center snaps back into place.

The book’s catharsis comes not through punishment but through substitution. Kumai, a dying man with nothing left to protect, takes Yuta home. The cycle breaks, not through justice, but through a simple act of un-poisoned care.

Master Map: Planted Clues and Their Payoffs

The Clue Tracker

The Missing Cake Slice (Chapter 1) → The Hidden Housemate (Final Chapter)
Raku’s anniversary post describes an 8-slice cake. Two slices for Raku, one for Yuki, four saved. One slice is mathematically unaccounted for. Naomi Konno was living with them and eating their food, invisible in every post.

Yuki’s Excessive Thirst (Chapter 1) → The Murder Weapon (Final Chapter)
Raku attributes Yuki’s extreme thirst to summer heat. It was sodium poisoning. Naomi had replaced the iron supplements with 15 grams of salt daily for months. The polydipsia (excessive thirst) is one of the body’s emergency responses to hypernatremia. Raku wrote it down because it was unusual. Uketsu put it in the blog because it was the proof.

The Breech Birth Recommendation (Chapter 1) → The Engineered Death (Final Chapter)
No modern, competent obstetrician recommends natural delivery for a breech presentation. Kurihara flags this in Chapter One. The payoff: Naomi was the senior midwife at the clinic, with institutional authority over the physician. She falsified the blood pressure records and staged the medical scenario that ensured Yuki would die on the table.

The Stencil Ruler Drawing (Chapter 2) → The Gravestone Misread (Chapter 2)
Naomi punishes Yuta for using a stencil ruler. When the teacher later misidentifies the shape in Yuta’s drawing (a triangle over a rectangle) as a stencil ruler, she is working from the wrong premise. The shape is 今野, the Konno family name, written as a gravestone marker.

The Folded Receipt Creases (Chapter 3) → The Blind Alibi (Chapter 3)
The crossing crease lines on Miura’s receipt drawing look like accidental folds. Iwata realizes they are tactile guidelines, folded deliberately so Miura could draw by feel with his hands restrained inside a sleeping bag. The creases are the proof that the time-of-death alibi was manufactured from start to finish.

The Backlit Mountains (Chapter 3) → Miura Drew in the Morning (Chapter 3)
The eighth station of Mt. K faces west. At 5:00 PM in September, the sun is behind the mountains. They are completely black against the glare. A person standing there cannot see the mountain’s features. Miura’s drawing captures those features. He drew it in the morning. Everything the police believed happened at 5:00 PM happened at 7:00 AM.

Thematic Resonance AKA How the Ending Shatters the Beginning

Strange Pictures is structurally a funnel. Each chapter draws in more scope — internet mystery, domestic thriller, true-crime procedural — and the Final Chapter collapses them into a single psychological portrait.

The prologue is the thesis. Art reveals subconscious truth. Dr. Hagio states this with authority, demonstrates it with precision, and then draws the wrong conclusion from it. The novel does not reject the thesis. It shows what happens when the thesis is applied by someone who is already looking for a reason to be hopeful.

The ending delivers the anti-thesis not as a correction but as a demonstration: the thorns were never meant to be overcome by the bird. The bird was the reason for the thorns. Naomi’s maternal instinct is not a capacity for love that kept her from becoming a monster. It is the specific shape her monstrousness takes.

Uketsu closes with Kumai and Yuta, which is the only note of something resembling repair in the book. Kumai is not a hero. He is a dying man who has nothing left to lose and one decent thing left to do. That is exactly enough.

Structural Relational Analysis

Chapter 1 (The Inner Circle): Purely digital. Internet archive forensics. No physical contact with any victim. The horror is abstract and intellectual.

Chapter 2 (The Second Circle): Domestic thriller. Physical proximity, dramatic irony, emotional misdirection. The reader is inside the household of the antagonist, rooting for her against a stalker.

Chapter 3 (The Third Circle): Historical true-crime procedural. Physical, brutal, geographically specific. Provides the forensic mechanics needed to understand the full scope of Naomi’s capability.

The Final Chapter (The Synthesizing Ring): Connects every character, every timeline, every planted clue. The internet mystery, the domestic thriller, and the cold-case procedural were all circles drawn around the same person. The structure of the novel is the composite drawing.

If you’ve read this far and haven’t picked up the book yet: the English translation by Jim Rion (HarperVia, January 2025) is as clean and precise as the source material deserves. What makes Strange Pictures work in translation is not just the puzzle mechanics. It is the restraint. Uketsu never overexplains. He trusts the reader to look at the drawing and see what is there.

Leave a comment

👋🏻 Hey. I’m Atharva.

Software engineer, GTM strategist, and AI-native builder. I work at AccuKnox doing DevRel and growth engineering for cloud-native security products. Before that: freelance dev, technical writer, research consultant.

This newsletter is where I write about the things I’m actually building and the decisions I’m actually making. AI systems, growth infrastructure, developer workflows, and once in a while the movies, music, and games that I think are worth your time. No summaries. No secondhand takes. Just what I built, what broke, and why I made the calls I did.

Four categories. Pick the one you came here for:

🔵 Tech and AI — LLMs, AI cost engineering, Claude ecosystem, developer tools, hands-on implementation

🟢 Biz and Growth — GTM strategy, lead generation, content systems, marketing automation

🟡 Money and Career — Career decisions, compensation, investing, working in tech on your own terms

🔴 Entertainment and Culture — Film, music, gaming, fiction, ideas worth arguing about

Pick the outcome that matches where you are right now: