At ZAR we’ve been building MCP integrations in Ruby and kept hitting the same problems: HTTP libraries dropping connections that MCP servers expect to stay alive, bolted-on auth, and clients that assume you’re using a specific LLM framework. We also wanted all the latest and greatest features of the MCP spec.

So we released our own Ruby client, extracted from production code!

GitHub - zarpay/manceps: Ruby client for the Model Context Protocol (MCP). Latin: one who takes in hand.

Persistent connections. MCP servers bind sessions to TCP connections. Manceps uses httpx to keep them alive across requests.

Two transports. Streamable HTTP for remote servers, stdio for local ones (spawns a subprocess, talks JSON over stdin/stdout). Auto-detects from the URL.

Auth built in. Bearer tokens, API key headers, and experimental OAuth 2.1 with discovery, PKCE, and automatic refresh.

Full spec coverage. Protocol version negotiation (2025–11–25 down to 2025–03–26), elicitation, notifications, structured tool output, tasks, pagination, exponential backoff with session recovery.

No LLM coupling. Pure protocol client. No to_openai_tools(), no framework dependencies. Use it with anything.

Manceps::Client.open("https://mcp.example.com/mcp", auth: Manceps::Auth::Bearer.new(token)) do |client|
  client.tools.each { |t| puts t.name }
  result = client.call_tool("search", query: "hello")
  puts result.text
end

Introducing Manceps was originally published in ZAR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

I built dot-test to kill this problem dead. It gives every Rails project in your projects directory a clean .test domain that just works. http://nexus.test instead of http://localhost:3001. http://empirium.test instead of whatever port that you can't remember.

How It Works

dot-test does three things:

1. Discovers your Rails projects automatically by scanning your projects folder (e.g. ~/projects) for apps with config/application.rb
2. Assigns stable port numbers and updates each project’s .env file so bin/dev picks up the right port
3. Runs a tiny DNS server and HTTP reverse proxy so *.test domains resolve to the correct backend
4. The entire thing is a single Go binary with zero external dependencies.

Getting Started

This is my first Go project and first thing I’ve ever published on homebrew! Thanks Claude Code!

brew tap zarpay/tap
brew install dot-test
dot-test setup        # one-time macOS DNS config (needs sudo)
dot-test sync         # discover projects, assign ports
brew services start dot-test

That’s it. Now http://yourapp.test routes to the right place.

Running dot-test sync gives you a clear picture of your local environment:

3 projects:
​
  http://zarcto.test -> localhost:3000
  http://nexus.test  -> localhost:3001
  http://praxis.test -> localhost:3002
​
Updating .env files...
  3 updated

Why I Built It

At ZAR, we run multiple Rails apps in development — our main platform, a slew of internal tools, and other supporting services. Remembering which port maps to which app was a minor but constant friction. Tools like Puma-dev exist, but I wanted something simpler and more predictable.

dot-test takes the opposite approach from most dev proxy tools. Instead of intercepting process management or requiring you to change how you start your apps, it stays out of the way. You still run bin/dev like normal. dot-test just handles the boring parts: port assignment, DNS, and routing.

Smart Port Detection

One detail we’re particularly happy with: dot-test doesn’t blindly assign ports. It scans your project configs first — bin/dev, Procfile.dev, docker-compose.yml, even TOML manifests — to find hardcoded port assignments. If your app already has a port it expects, dot-test respects that and builds around it.

Over time, I’ll happily add additional kinds of apps and frameworks so that it works with more than just Rails apps. The goal is that you can introduce dot-test into an existing multi-app setup without breaking anything.

Under the Hood

The implementation is deliberately minimal:

• DNS server: A from-scratch UDP DNS responder that handles *.test queries. No DNS libraries — just raw packet parsing with RFC-compliant label compression. It responds with 127.0.0.1 for any .test domain and NXDOMAIN for everything else.
• HTTP proxy: Go’s stdlib httputil.ReverseProxy strips the .test suffix, looks up the port, and forwards the request. If the backend isn't running, you get a helpful message:

dot-test: nexus.test is not running
Start it with: cd ~/projects/nexus && bin/dev

• Port persistence: Mappings are stored in a simple app=port dotfile. Your projects get the same ports every time, so bookmarks and configs stay valid.

The whole thing compiles to a ~9MB binary that runs as a background daemon.

Commands

dot-test sync     # discover projects and assign ports
dot-test list     # show current mappings
dot-test up       # start the daemon
dot-test down     # stop the daemon
dot-test setup    # configure macOS DNS resolver
dot-test clean    # remove everything

Open Source

dot-test is MIT licensed and available at github.com/zarpay/dot-test. It’s Go 1.22, zero dependencies, and works on macOS today with Linux support in progress.

If you’re tired of memorizing port numbers, give it a try. I’ve been running it in my daily workflow at ZAR and it’s one of those small tools that, once you have it, you wonder why you didn’t think of it sooner.

Stop Memorizing Port Numbers: Introducing dot-test was originally published in ZAR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Empirium is an experiment-tracking system I built for ZAR, my company. It replaces Linear. Teams use it to manage assumptions, run experiments, record what they learn, track metrics. This is the kind of app that would normally normally be drowning in text-entry forms. Multi-step wizards for creating experiments. Nested evidence fields for updating assumption confidence levels. Comment dialogs. Learning capture modals.

I built none of that. I mean, my first version had that stuff. But along the way I figured out that the time I was spending on those parts of the app were pointless.

So in a fit of ebullient audacity, I deleted all the new and edit templates and replaced every “Create” and “Edit” button with a small prompt popup. You click it and it gives you a short prompt that you can paste into Claude Code to get you started adding or modifying whatever it is that you want to change. Claude calls the right MCP tool, the database gets updated, and then since this is a modern Ruby on Rails application, Turbo Streams update the web page in real time.

In other words, my web interface is now almost purely a read layer. Dashboards and detail pages and evidence timelines. The only interactive things left are navigation, filtering, and some status toggles. The search feature. Updating your profile and settings. Every other write operation goes through MCP.

Really?

Yeah. Everyone at ZAR uses Claude Code. Literally, all day, every day, for everything they work on. That’s the crux of why this works. I like to say that we’re living in 2028. The rest of you will get there eventually. Probably.

Laziness, Impatience, and Hubris

Complex webapps are expensive to build and get right. Lots of design time, good judment and taste. And iteration. Linear is like the pinnacle of the form, don’t you think? Must have taken tens of thousands of hours of effort to build the user experience for that beast.

But giving an agent harness like Claude Code MCP access to your API is easy and it handles complicated structured input perfectly. Master-detail evidence records, nested learnings, conditional fields, whatever. Several of the forms I was contemplating designing for Empirium were going to be a multi-section beast with radio groups, conditional visibility, and validation UX that takes a long time to get right.

But won’t my users get frustrated by not being able to enter data directly. What hubris!

Lazy, impatient, and hubristic. That’s what makes me a great programmer.

The prompt bubble

What makes the UX intuitive is the MCP PROMPT bubble. It renders a small icon that opens a native element with a pre-composed command. One click copies it to clipboard.

The icons follow a convention: plus for create, pencil for edit, terminal for general MCP actions, chat for comments, arrow-right for status transitions.

The prompts themselves are imperative with just enough context. Entity IDs, natural keys, names, URLs (if appropriate). Enough that Claude Code can always find the right resource without asking follow-up questions. The user copies the prompt then finishes it in their console. And if they don’t supply required attributes, Claude helps them figure that out. The conversation is a vital part of the user experience.

But what does it mean?

I’ve been building web apps for nearly 30 years. Forms with inputs, selects, radio buttons, checkboxes, and textareas were always the answer to “how does data get into the system.” You render forms, the user fills them in, you submit. It’s so ingrained that I must admit questioning that modus operandi felt kinda weird.

But when it comes down to it, a form is really just a translation layer between what the user wants and what the database needs. And my users already have a better translation layer open in their terminal. One that they converse with in plain English. So now the form is the slow path. The redundant path.

Caveats, since people will ask

This is not a pattern for consumer apps. It’s for teams where everyone runs Claude Code or something like it.

The prompt bubbles are kind of silly, and they won’t get used very much once users understand the modality, but I think their presence matters more than you’d might think. Without them, new users would be really confused. With them, it’s like immediately, “Oh, okay I see what you did there.”

You still need some forms for onboarding and for ceremony-type interactions where the clicking-through is the experience. I also left normal forms in for profile and settings.

Be kind, give them an MCP Setup page

Ideally you want instructions on how this newfangled user experience works very easy to spot in your main navigation. The setup page should have clear instructions and not make them go elsewhere to grab an API key.

Definitely make your views update in realtime

Turbo Streams are what make the read-only UI feel alive. Without broadcasts from model callbacks, you’d be telling people to refresh their browser, which would kill the whole thing.

Final thoughts

One of my favorite aspects of these interesting times we’re living in is just how innovative/brazenly cocky you can be with design decisions like the one I just described. Because the cost is minimal!

The entire transformation I just described was five commits on a low-key Friday night. The big rewrite, then prompt bubble polish, then z-index fixes (always z-index), then cleaning up dead form code. Testing. Deployed.

What a time to be alive!

It might be time to say goodbye to HTML inputs was originally published in ZAR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Empirium, our in-house experiment-tracking platform at ZAR, exposes 42 MCP tools. Every time Claude Code connects, all 42 tool definitions would get loaded into its context window. That’s about 18,000 tokens of JSON schema — 427 tokens per tool — burned before the model does a single useful thing.

Cloudflare faced the same problem at a much larger scale — 2,500 API endpoints, over 2 million tokens of tool definitions. Their solution was elegant: replace all those tools with just two. One to search, one to execute. They called it “Code Mode.”

I implemented it for Empirium last night, using Rails and ActionMCP. Opus 4.6 mostly one-shotted the change after being pointed at the Cloudflare blog post, and getting some tips from me on how to approach the problem in Ruby.

So without further ado, here’s how my implementation of Code Mode works, and why every MCP server with more than a handful of tools should consider it.

The Problem with Many Tools

MCP (Model Context Protocol) is straightforward. You define tools with JSON Schema, the AI model reads those schemas, and calls the tools by name with arguments. It works beautifully when you have five tools. It works okay with fifteen. At forty-five, you’re paying a serious tax. At hundreds or thousands of tools, it just doesn’t work.

Every MCP tool definition includes its name, description, and full input schema with property types, descriptions, and required fields. The model has to parse and retain all of this context to decide which tool to call. Most of it is wasted — a given interaction might use three or four tools at most, if any at all.

Two Tools to Rule Them All

The pattern is dead simple. You expose two meta-tools:

code_search — accepts a Ruby code string, executes it in a read-only sandbox that exposes a tools method returning the full tool catalog. The AI writes Ruby to filter, search, and explore.

code_execute — accepts a Ruby code string, executes it in a sandbox that can invoke any MCP tool via call_tool(name, **args). The AI writes Ruby to chain calls, transform results, and build workflows.

The key insight is that LLMs are very good at writing code. Better, in fact, than they are at navigating large JSON schemas to pick the right tool and assemble the right arguments. Give them a programming environment and they figure it out.

The Implementation

The Sandbox

The foundation is a BasicObject clean room. BasicObject in Ruby gives you almost nothing — no Kernel, no Object methods, no file access, no shell access. You build up only what you need:

module CodeMode
  class Sandbox < BasicObject
    FORBIDDEN_PATTERNS = [
      /\bsystem\b/, /\bexec\b/, /\b`/, /\bFile\b/, /\bDir\b/,
      /\brequire\b/, /\beval\b/, /\bProcess\b/, /\bKernel\b/,
      /\bsend\b/, /\bconst_get\b/, /\bObjectSpace\b/, /\bENV\b/
    ].freeze
​
    TIMEOUT_SECONDS = 5
​
    def evaluate(code)
      if (violation = check_forbidden(code))
        return { error: "Forbidden pattern detected: #{violation}" }
      end
​
      result = ::Timeout.timeout(TIMEOUT_SECONDS) { _eval(code) }
      { result: result }
    rescue ::Timeout::Error
      { error: "Code execution timed out after #{TIMEOUT_SECONDS} seconds" }
    rescue ::StandardError => e
      { error: "#{e.class}: #{e.message}" }
    end
  end
end

Regex guards catch obvious escape attempts before evaluation. Timeout catches infinite loops. BasicObject blocks access to the rest of Ruby’s standard library. It’s not a Turing-complete security boundary — it’s a practical one. Empirium is for internal use only. Your mileage may vary. (But keep reading to learn about an additional layer of security using “LLM as judge”.)

The Search Sandbox

The search sandbox inherits from Sandbox and exposes the tool catalog:

class SearchSandbox < Sandbox
  def tools
    ::ActionMCP::ToolsRegistry.non_abstract.map do |item|
      item.klass.to_h
    end
  end
end

The ToolsRegistry is picking up the 42 tool definitions that I mentioned earlier.

Using the SearchSandbox the AI can now write things like:

tools.select { |t| t[:name].include?("experiment") }.map { |t| t[:name] }

And get back a filtered view of just the tools it needs, without loading all 42 definitions.

The Execute Sandbox

The execute sandbox adds the ability to call tools with user context:

class ExecuteSandbox < Sandbox
  def initialize(user)
    @user = user
  end
​
  def call_tool(name, **args)
    ::ActionMCP::Current.set(gateway: ::OpenStruct.new(user: @user)) do
      response = ::ActionMCP::ToolsRegistry.tool_call(name, args.stringify_keys)
      parse_response(response)
    end
  end
end

The user context flows through exactly as it would with a normal MCP tool call. Authentication, audit trails, everything works. The AI can now write:

teams = call_tool("teams_list")
alpha = teams["teams"].find { |t| t["slug"] == "alpha" }
exps = call_tool("experiments_list", team_slug: alpha["slug"])
{ team: alpha["name"], total: exps["count"],
  running: exps["experiments"].count { |e| e["status"] == "running" } }

Three MCP tool calls, chained together with data transformation, in a single round trip. Without code mode, that’s three separate tool invocations with three LLM reasoning steps in between.

The LLM Pre-Scan

Before executing code, I run a quick safety check through Google’s Gemini 3 Flash (using my own Raix gem and OpenRouter). This approach is cheap, fast, and adds a semantic layer on top of the regex guards:

class CodeScanner
  include Raix::ChatCompletion

  SYSTEM_PROMPT = <<~PROMPT
    You are a code safety scanner for an MCP (Model Context Protocol) sandbox environment.
    The sandbox allows Ruby code that calls `tools` (to list available MCP tools) and
    `call_tool(name, **args)` (to invoke them).

    Your job: determine if the submitted code is SAFE or UNSAFE.

    SAFE code:
    - Calls `tools` to discover available MCP tools
    - Calls `call_tool` to invoke MCP tools with arguments
    - Uses basic Ruby (arrays, hashes, strings, iteration, filtering)
    - Chains multiple `call_tool` invocations together

    UNSAFE code:
    - Attempts to access the filesystem, network, or shell
    - Tries to break out of the sandbox (eval, send, const_get, ObjectSpace, etc.)
    - Accesses environment variables or credentials
    - Does anything unrelated to Empirium data operations

    Respond with exactly one word: SAFE or UNSAFE
  PROMPT
​
  def initialize(code)
    @code = code
    self.model = "google/gemini-3-flash-preview"
  end
​
  def safe?
    transcript << { system: SYSTEM_PROMPT }
    transcript << { user: @code }
    response = chat_completion
    response.to_s.strip.upcase.start_with?("SAFE")
  rescue StandardError
    true # Fail open — scanner unavailable means skip
  end
end

For us the scanner is a nice-to-have, not a gate. It fails open, so the code runs even if the scanner fails with just the regex guards and BasicObject sandbox. Your use case might want to do the opposite, especially if your MCP tools are open to consumers outside of your company walls.

Profile-Based Routing

I left the original 42 tools on /mcp untouched, probably for no good reason other than I would have had to come up with a different way of documenting and implementing my API if I had gotten rid of them.

Code mode lives at /mcp_cm as a separate concurrent endpoint. A Rack middleware switches ActionMCP's thread-local profile:

class CodeModeProfile
  def initialize(app)
    @app = app
  end
​
  def call(env)
    if env["PATH_INFO"]&.start_with?("/mcp_cm")
      ActionMCP.with_profile(:code_mode) { @app.call(env) }
    else
      @app.call(env)
    end
  end
end

The code_mode profile in config/mcp.yml exposes only the two tools:

profiles:
  primary:
    tools: [all]
  code_mode:
    tools: [code_search, code_execute]

Both endpoints share the same authentication, the same tool implementations, the same database. The only difference is what the AI client sees when it connects.

What It Looks Like in Practice

Here’s a real interaction. I asked Claude Code to add a random emoji to every assumption title in Empirium using the code mode endpoint. One tool call:

emojis = %w[🚀 🔥 💡 🎯 ⚡ 🌟 🎲 🧪 🔬 🏆 💎 🌈]
​
all = call_tool("assumptions_list")
assumptions = all["assumptions"]
​
results = assumptions.map do |a|
  emoji = emojis.sample
  new_statement = "#{emoji} #{a['statement']}"
  call_tool("assumptions_update", id: a["id"], statement: new_statement)
  { id: a["id"], emoji: emoji }
end
​
{ updated: results.size, details: results }

Twenty assumptions updated in a single round trip. I watched the web page update in realtime as it worked. Blazing fast, like mind-blowingly so.

Without code mode, that would have been 21 separate tool calls (1 list + 20 updates), each requiring the model to reason about the next step. With code mode, the model writes the loop once and the server executes it.

Undoing it was equally trivial:

all = call_tool("assumptions_list")
all["assumptions"].map do |a|
  clean = a["statement"].sub(/\A\p{So}\s*/, "")
  call_tool("assumptions_update", id: a["id"], statement: clean)
end

The savings you gain with Code Mode compound.

Every conversation turn that would have listed all 42 tools now lists two. Every multi-step workflow that would have required multiple tool calls and LLM reasoning steps collapses into a single code execution.

Should You Do This?

If your MCP server has fewer than ten tools, maybe not? The overhead isn’t worth the complexity. But if you’re north of twenty tools —or if your users routinely chain multiple tools together — code mode pays for itself immediately.

The implementation is small. My entire code mode implementation is under 200 lines of Ruby across four files, plus a middleware and some config. It took me about an hour, including testing. The sandbox pattern is reusable. The profile-based routing means I can offer both endpoints simultaneously and let clients choose.

The deeper principle here is one that keeps showing up in AI application development: don’t make the model navigate complexity when you can give it tools to manage that complexity itself. LLMs write code better than they do almost anything else. Set them free.

Code Mode MCP was originally published in ZAR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

How I use AI as an executive assistant to manage 10 engineers, ship code, and operate at the C-level simultaneously.

Three weeks ago, I started my new role as full-time CTO at ZAR. The first thing I did was to create a new folder on my laptop, fire up Claude Code , and give it a fairly simple prompt:

Create me a markdown-based system where I can regularly run you,
Claude Code, that lets me be the best world-class CTO possible. 
I'm planning to use you as my personal executive assistant and
CTO expert coad. Document everything in a series of folders as
you see fit. We're in plan mode, feel free to interview me if you
have any questions about this job.

I didn’t design a folder structure, ahead of time. I didn’t search for prompts or templates for this sort of thing. I just trusted the very capable Opus 4.5 model to figure it out. This post documents what I’ve learned so far, for anyone who wants to build something similar.

Practical results after three weeks

First let me communicate why you might want to try this:

• Meeting preparation: I’m prepared for every meeting. Every day. Full context on attendees, relevant history, suggested talking points.
• Clarity on priorities: At any moment, no matter how distracted or stressed I might be, I can trust Claude to help me get centered and figure out what to focus on next.
• Decision history: When someone eventually asks about a previous decision, I will have the full context. Not a vague memory. The actual alternatives considered, why I chose what I did, and who was involved.
• Execution without context switching: Posting to Slack, updating calendars, drafting blog post ideas, tracking action items… All handled through natural conversation.

I’ve had executive assistants in the past. Good ones. This system is better. It never forgets anything, never needs to be brought up to speed, and operates at the speed of conversation. Did I mention it’s always available?

How I use it to manage my day to day

I keep at least one Claude Code session open in this directory at all times. During parallel workstreams (preparing for multiple meetings, researching candidates, writing documents) I’ll open additional tabs with concurrent sessions. I just checked and at the moment I have 9 concurrent Claude Code sessions open in separate tabs within one terminal window dedicated to just my assistant.

Even though I am a very fast touch typer, I am trying as much as possible to force myself to use voice input (Wispr Flow) for anything longer than a sentence. Stream of consciousness works great.

Short prompts don’t even need to be full thoughts. “Morning sync”, “Next 1:1”, “Post summary of this to Slack”. Claude is pretty good at figuring out what I mean from context.

Morning routine

One of the first benefits was to begin my work day by saying “good morning,” to which Claude responds with the following steps:

1. Reads my weekly focus document
2. Checks pending action items
3. Fetches my actual calendar items for the day
4. Figures out what needs my immediate attention.

Takes about 30 seconds to figure exactly what my day looks like.

Eventually, I wondered what Claude would come up with if I standardized my morning routine as a skill.

This is the prompt it wrote, triggerable with a slash command as /morning:

# Morning Briefing

Run the morning sync workflow:

1. Read the weekly focus from `priorities/weekly-focus.md`
2. Check `meetings/actions/` for any pending action items
3. Check today's calendar using Google Calendar MCP tools (GOOGLECALENDAR_EVENTS_LIST with today's timeMin/timeMax in UTC)
4. Summarize:
   - What's the focus today based on weekly priorities
   - What meetings are scheduled for today
   - Any pending action items that need attention
   - Any blockers or items requiring immediate attention

Keep the briefing concise and actionable.

Processing meeting transcripts

At work we use Gemini to transcribe almost all meetings. At first I was copying the transcripts into the console. Eventually, I got MCP integration to my Google Suite working (see below how) and I was able to automate the process.

Multiple times a day I invoke a custom skill called /meetsync and Claude automatically:

• Creates meeting notes in the appropriate folder
• Extracts action items with owners
• Updates team roster with anything new learned about people
• Updates any other relevant context files

I don’t think about where transcripts go. It handles the filing and organization itself. Of course, I didn’t write the custom skill either, it was written by Claude itself:

# Meeting Sync Command

Sync unprocessed meeting transcripts from Google Calendar/Gemini
into the zarcto knowledge system.

## Instructions

Execute the following workflow:

### Step 1: Get Recent Meetings from Google Calendar

Use the Rube MCP to query Google Calendar for meetings from the 
last 48 hours that have Gemini notes attachments:

1. Call `RUBE_SEARCH_TOOLS` with use_case "list calendar events with
   attachments"
2. Call `GOOGLECALENDAR_EVENTS_LIST` for the primary calendar with:
   - timeMin: 48 hours ago (RFC3339 format)
   - timeMax: now (RFC3339 format)
   - singleEvents: true
   - orderBy: startTime
   - timeZone: Europe/Amsterdam

3. Filter results to only meetings that have:
   - `attachments` array containing items with `title` containing "Gemini"
      or "Notes by Gemini"
   - `eventType` of "default" (exclude working locations, etc.)

### Step 2: Find Unprocessed Meetings

1. Read the list of existing files in `meetings/notes/` directory
2. For each calendar meeting with Gemini notes:
   - Extract the date (YYYY-MM-DD) and generate expected filename pattern
   - Check if a corresponding note already exists
   - If no note exists, add to "unprocessed" list

### Step 3: Fetch Transcript Content

For each unprocessed meeting:

1. Extract the Google Doc ID from the attachment fileUrl or fileId
2. Use `GOOGLEDOCS_GET_DOCUMENT_BY_ID` to fetch the document
3. Extract plain text from the document body using the standard
   extraction pattern:
   ```
   body.content → paragraph.elements → textRun.content
   ```

### Step 4: Process Each Transcript

For each fetched transcript, follow the standard "Process Meeting
Transcript" workflow from CLAUDE.md:

1. **Create meeting note** in `meetings/notes/YYYY-MM-DD-topic.md`:
   - Use the meeting summary/title to derive the topic slug
   - Include key discussion points, decisions, and context
   - Format similar to existing notes (see examples in the directory)

2. **Create action items** in `meetings/actions/YYYY-MM-DD-topic.md`:
   - Extract actionable items from the transcript
   - Group by person responsible
   - Use checkbox format: `- [ ] Action item`

3. **Update team roster** (`team/roster.md`):
   - Add any new information learned about team members
   - Update skills, interests, or context if relevant

4. **Update recruiting pipeline** (`recruiting/pipeline.md`):
   - Only if meeting involved candidate discussions

5. **Update other context files** as appropriate:
   - `context/architecture.md` for technical decisions
   - `priorities/weekly-focus.md` if priorities discussed
   - `decisions/` if significant decisions made

### Step 5: Present Summary

After processing all meetings, present a summary:

```
## Meeting Sync Complete

**Processed**: X meetings
**Skipped** (already processed): Y meetings
**Failed** (permission denied, etc.): Z meetings

### Newly Processed:
1. YYYY-MM-DD Topic Name
   - Created: meetings/notes/YYYY-MM-DD-topic.md
   - Actions: X items for Y people
   - Updates: [list any other files updated]

2. ...

### Action Items Created:
- Person A: X items
- Person B: Y items

### Notable Updates:
- [Any significant context file changes]
```

## Error Handling

- If Google Calendar or Docs connection fails, prompt user to reconnect via Rube
- If a specific document has permission issues, note it and continue with others
- If no unprocessed meetings found, report "All meetings already synced"

## Notes

- Default lookback is 48 hours; user can specify different range with argument
- Only processes meetings where Obie is an attendee
- Skips external meetings without Gemini notes

1:1 preparation

Here’s my /prepcommand for generating one-on-one meeting notes. Again, this was written by Claude, not myself. I’m only reproducing these skills here for illustrative purposes, not so that you can copy them.

# 1:1 Preparation

Prepare for a 1:1 meeting with $ARGUMENTS.

## Instructions

1. **Read team member info** from `team/roster.md`
   - Extract their current context, recent work, concerns, goals

2. **Read recent 1:1 notes** from `team/one-on-ones/[name].md`
   - Review last 2-3 conversations
   - Note any follow-up items from previous meetings

3. **Check pending action items** in `meetings/actions/`
   - Find any action items assigned to them or involving them
   - Note status of items from previous 1:1s

4. **Suggest topics to cover**:
   - Follow-up on previous action items
   - Current blockers or challenges
   - Career development and growth
   - Feedback (both directions)
   - Team dynamics or concerns
   - Any patterns noticed from recent work

5. **Format the output**:
   ```
   # 1:1 Prep: [Name]

   ## Context
   [Brief summary of their role, current focus, recent wins/challenges]

   ## Last 1:1 Highlights
   [Key points from most recent conversation]

   ## Pending Items
   - [ ] Item 1 from previous 1:1
   - [ ] Item 2 related to them

   ## Suggested Topics
   1. Topic 1 (with context)
   2. Topic 2 (with context)
   3. Topic 3 (with context)

   ## Notes to Remember
   [Anything specific to bring up or be mindful of]
   ```

Keep it concise and actionable. Focus on what matters most right now.

Using this command, I begin every one-on-one meeting with full context on our previous conversations and any outstanding items.

Logging Decisions

When I make a decision, I say “log decision about X” or invoke /decide. Claude discusses context and options with me, creates a structured decision record, and links to relevant context.

Three months later when someone asks “why did we switch from X to Y?”, I will have the full rationale documented. Not just the decision, but the alternatives considered and why we rejected them.

# Log Decision

Capture the following important decision with context, alternatives, 
and rationale:

$ARGUMENTS

## Instructions

1. **Understand the decision context**
   - Ask clarifying questions if the decision topic is vague
   - Understand what problem this decision solves
   - Identify who was involved in making this decision

2. **Explore alternatives**
   - What other options were considered?
   - Why were they rejected?
   - What tradeoffs were evaluated?

3. **Read the decision template** from `decisions/_template.md`

4. **Check for related decisions** in `decisions/`
   - Search for similar past decisions
   - Note if this reverses or builds on previous decisions
   - Link to relevant prior decisions

5. **Create the decision record**:
   - Use filename format: `decisions/YYYY-MM-DD-slug.md`
   - Follow the template structure
   - Include:
     - Date and context
     - Problem/need
     - Decision made
     - Alternatives considered
     - Rationale and tradeoffs
     - Consequences (expected)
     - People involved
     - Related decisions or context files

6. **Link to relevant context**:
   - Reference architecture docs if technical
   - Reference project briefs if project-specific
   - Reference team discussions if relevant

7. **Confirm with Obie** before writing the file
   - Show him the draft
   - Get approval on completeness
   - Then write the file

Keep it concise but complete. Future you (or future team members)
should be able to understand why this decision was made without 
additional context.

Posting to Slack and other tools

I need to update the engineering channel about a significant PR or decision. I say “post this to #engineering on Slack” and provide the message. It posts it. Done.

I’ve had it communicate with all my direct reports via Slack, asking them to set up recurring 1:1s with my scheduling link. Same with Twitter. Same with calendar invites. Same with any service I’ve connected via the Rube MCP integration.

As mentioned above, the Rube MCP integration is awesome for this kind of stuff, without bloating your context.

The Technical Setup

Directory Structure

Here’s what Claude created, just to show you that it’s comprehensive. I never go in here and purposely did not try to design it myself.

context/           # Company, team, architecture docs
decisions/         # Decision records with rationale
drafts/            # Work in progress documents
journal/           # Weekly reflections
meetings/
  actions/         # Action items with owners
  notes/           # Meeting transcripts and summaries
playbooks/         # Recurring process documentation
priorities/        # Weekly focus, 90-day plans
projects/          # Project briefs and status
recruiting/        # Pipeline, candidates
reference/         # Mental models, frameworks
team/
  one-on-ones/     # Individual 1:1 histories
  roster.md        # Team member details

I genuinely don’t think about this structure, ever. Claude knows where things go. I just talk to it. The day the contents start getting too big or seem to be bogging down, I’ll ask Claude to optimize it. Until then we’re good.

MCP Integration

The Rube MCP integration is essential. It gives Claude access to:

• Google Calendar (reading and creating events)
• Slack (posting messages, reading channels)
• Twitter/X (posting updates)
• Linear (project and issue management)
• Gmail and other services

This means I can say “what’s on my calendar tomorrow?” or “post this to Slack” without context switching. The integration is what turns this from a note-taking system into an actual executive assistant.

Version Control

Everything is in a private Git repo. Hooks handle syncing automatically. This gives me:

• Full history of all changes
• Backup without thinking about it
• Ability to reference anything from any point in time

Everyone at ZAR is in the process of setting up and using this system. I’ve advised the non-technical folks to run this in a personal Google Drive instead of trying to learn Github and repos.

Real Examples

Hiring: I paste a candidate’s resume or LinkedIn profile. Claude updates the recruiting pipeline, suggests interview questions based on gaps in our team, and preps me for the screening call.

Performance tracking: If I need to review an engineer’s history, I can say “walk me through the history with [name]”. Claude pulls up 1:1 notes, shows patterns across conversations, references any documented concerns or wins.

Planning: “What are the top three things blocking productivity right now?” Claude reads recent meeting notes, checks pending action items, reviews Linear status, and surfaces actual bottlenecks.

Communication: “Post an update about Stephen accepting our offer to #leadership on Slack.” Done. No context switch.

The Numbers After Three Weeks

I didn’t know these numbers until asking Claude to calculate them for this blog post. Pretty impressive stats, if I do say so myself.

• 82 meeting notes processed and filed
• 47 meetings in January (2+ per day)
• 18 documented 1:1s with full context and follow-up
• 35 action item tracking files with owners and status
• 23 team members tracked with 264 lines of detailed context
• 9 context documents maintained
• 11,579 total lines of institutional knowledge captured

While also shipping code. While also operating at the C-level with the CEO and CPO.

Why This Works Better Than Other Systems

Most knowledge management systems fail because maintaining them is a second job. You have to remember to update things. You have to organize things. You have to think about the system instead of thinking about your actual work.

This system works because I never think about the system. I think about my work, and the system captures it as a side effect of natural conversation.

Compare to Notion where you’re constantly deciding “should this be a page or a database?” or “which workspace does this belong in?” or reorganizing because the taxonomy you picked six months ago doesn’t fit anymore.

With this approach, the implementation is invisible. I just talk to Claude and it handles everything.

How to get started

1. Start simple: Open Claude Code in a fresh directory. Tell it what you need. Let it figure out the structure. Use my prompt shared above, something like: “Build a markdown-based operating system that makes me operate like a world-class [your role].”
2. Use it for a week: See what works and what doesn’t. Claude will adapt.
3. Put it in version control: A private Git repo if you’re technical. Otherwise, put it in a folder that syncs (Google Drive, iCloud, Dropbox).
4. Connect your tools: Set up MCP integrations for your calendar, communication tools, and project management. This is what turns it from note-taking into an actual assistant.
5. Run multiple sessions: One session is good. Three concurrent sessions for parallel work is when you feel the leverage.
6. Once you find yourself doing the same thing a few times, ask Claude to write a skill. This is how you get compounding productivity.

The system gets smarter over time. Every conversation adds context. Every decision creates a reference point. Every team update builds a richer picture.

What’s Next

Right now I’m constrained to a terminal window. Voice input via Wispr Flow already makes it feel more natural. The trajectory is toward continuous conversation throughout the day, not “using a tool.”

I would like to give Claude a way of popping up its results on my desktop in rich text. Basically because if I have it generate something like 1:1 meeting notes, I need that to pop up and stay available instead of scrolling out of the current terminal context. This would minimize my need to keep opening new sessions.

I would also really like to be able to communicate with my assistant via text messaging and voice chats, when I’m not at my computer. I’m experimenting with Clawdbot to learn more about how to tackle that particular challenge. It’s very possible that I will eventually port this whole system over to a Clawdbot instance!

Bottom line, I’m sure that the models will continue to improve with better reasoning, better memory, and better tool use. So the system that I have now will only get more capable. I’ll post updates here as I develop new techniques and breakthroughs.

The first post from ZAR’s engineering team

Over the Christmas break, while most CTOs were reviewing strategy decks, I was building. From scratch. A complex knowledge graph system called Nexus that my team now uses every day.

Nobody asked me to build it. I had just started as full-time CTO at ZAR. By any traditional playbook, I should have been doing stakeholder interviews and organizational assessments.

But here’s the thing: I fucking love building software.

That’s why I’m here. That’s why I’m writing this. And that’s why we’re launching this engineering blog — to show you what we’re actually doing, not just talk about what we believe.

What We’re Building

ZAR helps people in emerging markets like Pakistan save, spend, and send US dollars. We’re backed by a16z crypto and Dragonfly and the founders of Solana, amongst other top-notch investors.

The technical challenges are genuine:

• Blockchain infrastructure on Solana with US dollar-backed stablecoins.
• Merchant networks spanning countries where “going to the bank” isn’t an option
• Mobile-first UX for users on low-end devices with unreliable data

We’re a Rails 8 shop. Ten engineers. Small enough that your work matters, big enough that we’re solving real problems at scale.

How We’re Building ZAR

This is where it gets interesting.

We’re going all-in on AI-assisted everything, not just software development. Not as a gimmick — as a fundamental rethinking of how startups and their software engineers operate. Everyone at ZAR is using Claude Code as their day-to-day executive assistant, not just the engineers.

That knowledge graph I built over Christmas? It captures decisions, context, and learnings from every engineering session. Every pull request. Every Linear ticket. Every significant conversation on Slack. When someone (either human or autonomous AI agent) joins a project here, they don’t start from zero. They have the full history of why things are the way they are.

The engineers I know who are paying attention to agentic AI understand what’s happening. Teams that reimagine how they work using agents are going to accomplish amazing things with impossibly-small sounding numbers of people. We intend to be one of those teams.

What Kind of Place This Is

I’ve been building software professionally for 30 years. I’ve led a lot of teams, including at successful venture-backed startups. I know what works and what doesn’t.

Here’s what I promise as your CTO and engineering leader:

I will listen. If you tell me I’m wrong and show me why, I’m going to celebrate you for having the guts to challenge me. I’ve left companies that didn’t have that culture. I won’t build one.

I will teach you everything I know. I have no ego about hoarding knowledge. The techniques and mental models we figure out together should compound for you long after you’ve moved on to whatever’s next.

I will give you real ownership. We only have two kinds of full-stack engineers: Product and Platform. Both serve actual customers with real business outcomes at stake. That means actual ownership over critical business initiatives. The chance to say “I’m making myself responsible for this” and then have the latitude to do it. No bullshit metrics. Real accountability.

I will be humble. I’ll be the first to admit when I’ve failed. When my ideas don’t work. When someone else’s approach was better.

In return, I expect a lot. I’ll push you. I’m not a professional manager — I’m an engineer leading an engineering team.

Who Thrives Here

You’re a full-stack Product Engineer who wants to be building at the frontier of what’s possible, not maintaining legacy systems while the world changes around you.

You see AI-assisted development as a superpower, not a threat. You understand that investing in your own productivity is how you deliver compounding returns.

You want to be surrounded by other world-class talent operating at your level. Iron sharpens iron — that’s how you grow faster than you thought possible.

You care deeply about the craft of software. You stay close to the work because the work is what makes you come alive.

What’s Next

This blog is going to be a window into how we work. Technical deep dives. Architecture decisions. Experiments that failed. Lessons learned.

We’re not going to polish everything for public consumption. We’re going to show you the actual work.

If that sounds like the kind of team you want to be part of, reach out. We’re hiring full-stack engineers who are genuinely excited about this moment in our industry.

And if you’re not ready yet — that’s fine too. Follow along. See if we deliver on what we’re promising. The work will speak for itself.

Obie Fernandez is the CTO at ZAR. He’s been building software professionally since 1995 and still thinks it’s the best job in the world. Reach out at obiefernandez@zarpay.app or find him on Twitter/X.

We’re Building Something Different. Want In? was originally published in ZAR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Look, I’ve been slinging code professionally for 30 years now. I’ve also built succesful startups, written bestselling books, consulted for Fortune 500s, and watched countless technology waves come and go. Catching some of those waves at just the right moment are what propelled my career to where it is now. I’ve also witnessed “paradigm shifts” that weren’t and “revolutions” that fizzled. So believe me when I tell you that what I’m living through this week is genuinely different from any change I’ve ever seen before.

It started this past week (between Christmas and New Year’s) a weird liminal period where in ordinary years I would just relax and take it easy. Instead I was reflecting on how much time my team at ZAR and I spend in Claude Code sessions. Hours and hours of deep technical work, decisions being made, architecture being discussed, bugs being solved. And then… poof. The transcript disappears. The next session starts fresh.

Of course it’s not just Claude Code. The same challenge faces our Slack conversations. Linear comments. GitHub PR discussions. All this priceless institutional knowledge, constantly evaporating.

Also, the following tweet was very much on my mind.

The problem isn’t unique to AI-assisted development, but AI makes it worse. Traditional development leaves artifacts: design documents, ADRs, wiki pages, commented code. When you’re pair-programming with Claude Code, the artifact is the conversation itself. The decisions live in the dialogue. And unless you’re meticulously copying things into documentation (face it, you’re not), then that knowledge disappears the moment you close the terminal.

I started thinking about the scale of it. My team runs hundreds of Claude Code sessions per week. Each one contains decisions, learnings, architectural discussions, debugging insights. Multiply that by the dozens of Slack threads, the Linear comments on tickets, the GitHub PR review conversations. We’re generating reams of institutional knowledge and retaining none of it in a methodical fashion that can be leveraged by the advanced/autonomous AI agents I want to build in 2026.

But what if we could capture it all? What if there was a system that passively ingested every transcript, every thread, every discussion and distilled it into queryable organizational memory? Not just storing raw text, but actually understanding it. Extracting the decisions. The learnings. The conflicts. Building a semantic graph that a coding assistant could traverse. Believe it or not, that’s been a pet topic of mine since 2005!

RAG you say? Sure, I guess I could buy a solution or use something open-source. There’s probably a few dozen startups working on exactly what I’m about to show you. There’s also a slew of more traditional enterprise knowledge management platforms that would cost at least six figures before you factor in the integration costs, the consultants, the months of implementation. Fuck that.

I built it in four days.

Not a proof of concept. Not a demo. The first cut of Nexus, a production-ready system with authentication, semantic search, an MCP server for agent access, webhook integrations for our primary SaaS platforms, comprehensive test coverage, deployed, integrated and ready for full-scale adoption at my company this coming Monday. Nearly 13,000 lines of code. By the time I let this blog post marinate awhile and hit publish, I’ll probably have written another few thousand just with the issues I have queued up.

And here’s the funny thing: building Nexus wasn’t even my primary focus all week. I’m the new CTO of ZAR, and other than New Year’s Eve and New Year’s Day (when I had the luxury of uninterrupted time), I was building Nexus while juggling otherwise normal life and work responsibilities. Meetings. Slack threads. Writing production code. Code reviews. Planning. Recruiting. The usual shit. Nexus happened in the gaps, in the afternoons, in the bursts of flow state I could carve out between other obligations.

#zar #fintech #crypto #stablecoins #payments #rubyonrails #solana #engineeringleadership #ai #agents #amsterdam | Obie Fernandez | 31 comments

Why I’m writing this (instead of open-sourcing)

Before diving in, let me address something. My career was built on open source. I’ve contributed to Rails since the early days. I’ve authored gems that have been downloaded millions of times. I literally wrote “The Rails Way” franchise, which across its eight editions has helped codify best practices for generations of Rails developers. I’ve evangelized sharing code freely for two decades.

So why am I blogging about Nexus instead of just publishing it on GitHub?

Because of an uncomfortable realization: in an era where killer software can be developed this fast, by the right people with the right tools, and maintaining that software is practically free thanks to agentic help… open-sourcing doesn’t make the same kind of sense it used to. Not for this project.

Nexus represents a genuine competitive advantage for my company. It’s the kind of infrastructure that could differentiate us in the market. In the old days, building something like this was so expensive and time-consuming that you’d never just build it in-house. (Unless you’re Shopify, I guess.) If you were crazy/stupid enough to try anyway, then open-sourcing it made strategic sense. You’d gain community contributions, bug fixes, and reputation, all while knowing your competitors would need their own multi-month effort to catch up. The barrier to replication was high enough that sharing made sense.

Now? Fuck, no…. If I open-source Nexus today, pretty much anyone with Claude Code could fork it, customize it, and deploy it by tomorrow afternoon. My competitive advantage would evaporate in hours. That’s not an exaggeration. I’ve used Claude Code to take complex codebases and modify them substantially in single sessions. To rewrite Python libraries in Ruby in one sitting. The replication barrier has collapsed.

Before you go into fits of despair, don’t worry. I don’t think Claude Code is the death knell for open source. Foundational libraries, protocols, and tools still benefit enormously from open collaboration. The Ruby ecosystem, the JavaScript ecosystem, infrastructure tools like PostgreSQL and Redis… all will continue to benefit from shared development. But for custom built in-house applications that represent strategic advantage? The calculus has shifted dramatically.

Another reason I’m writing this because I keep seeing skeptics online asking: “Okay, if AI-assisted development is so revolutionary, where are the projects? Where’s the evidence?” The implication is that people like me are just hype-mongering, that “vibe coding” produces nothing of substance. That we’re exaggerating our productivity gains or building toy projects and calling them production systems.

Well, here you go. Here’s the evidence. Here’s a real project, with real commits, real timestamps, and real production deployment. Follow along. I’ll show you what was built, when it was built, and how long it actually took.

What Nexus Actually Does

Let me be concrete about what got built. Abstract descriptions of “knowledge management” don’t convey the scope. Let me walk you through the actual system.

Nexus is an organizational knowledge distillation service. The core workflow:

1. Transcripts come in from any source: Claude Code hooks that fire automatically when sessions end, Slack threads via Events API, GitHub webhooks for PR discussions, Linear webhooks for issue comments, or manual submission through the API.
2. LLM distillation analyzes each transcript and extracts structured knowledge: decisions made, lessons learned, people involved, topics discussed.
3. RDF storage persists everything as semantic triples in Oxigraph, a high-performance graph database with full SPARQL support. Our source of truth is the graph, not Postgres.
4. Vector embeddings (via pgvector) enable semantic similarity search across the entire knowledge base.
5. MCP server exposes the graph to AI agents, so Claude can query your organizational memory directly during coding sessions.
6. Web UI lets humans browse sessions, explore the ontology, search semantically, and manage conflicts.

The technology stack deserves explanation because the choices matter:

Ruby 4.0 and Rails 8 (edge): I’m running the brand new version of Ruby and the main branch of Rails, not a released version. (Why, see the screenshot below for an example of Claude being witty.)

One of my favorite things about Rails 8 is that ships with the Solid* gems that eliminate Redis as a dependency. SolidQueue for background jobs, SolidCache for caching, SolidCable for websockets. One less piece of infrastructure to manage.

PostgreSQL with pgvector: The primary relational database, but also the vector store for semantic search. The pgvector extension lets you store 768-dimensional embeddings alongside your regular data and query them with similarity operators. No need for a separate Pinecone or Weaviate instance.

Oxigraph: Oxigraph is a Rust-based RDF triple store with SPARQL support. It’s what makes the knowledge graph actually work. Every piece of distilled knowledge becomes semantic triples that you can query with the full power of SPARQL. “Find all decisions related to authentication made by Sarah” is a single query.

Raix: My own gem for LLM orchestration via OpenRouter. It handles the prompt construction, response parsing, and error handling for the distillation pipeline.

GitHub OAuth: Authentication for the web UI and API. Everyone has a GitHub account, so there’s no signup friction.

Now let me take you through how this thing came together, day by day.

Day 1: December 29th — The Initial Checkpoint

Time: Late morning to evening
Commits: 1 major checkpoint
Lines added: ~6,000

The first real checkpoint landed at 5:47 PM Central time. I’d been working since late morning, but I didn’t checkpoint it until I had something coherent and working.

136 files. Six thousand lines. That’s not a typo.

It’s hard to properly explain the power of Claude Code to people who haven’t experienced AI-assisted development at this level. I wasn’t typing 6,000 lines. I was directing 6,000 lines. Describing what I wanted, reviewing what Claude proposed, course-correcting, integrating, testing. The actual character input from my keyboard was maybe 10% of that. But the design decisions? The architecture? That was all me, refined through rapid dialogue with an AI that could actually implement what I was describing.

Here’s what made this sustainable rather than chaotic: TDD. Test-driven development. For most of the features, I insisted that Claude Code follow the red-green-refactor cycle with me. Write a failing test first. Make it pass with the simplest implementation. Then refactor while keeping tests green.

This wasn’t just methodology purism. TDD served a critical function in AI-assisted development: it kept me in the loop. When you’re directing thousands of lines of code generation, you need a forcing function that makes you actually understand what’s being built. Tests are that forcing function. You can’t write a meaningful test for something you don’t understand. And you can’t verify that a test correctly captures intent without understanding the intent yourself.

I’ve written about this more extensively in Ruby Was Ready From the Start, but the short version is: TDD is the only development process I know of that continually validates intent. When machines can generate endless variations of working-looking code, the only reliable way to know that software does what you intend is to encode that intent in tests and keep those tests running all the time.

Let me break down what that initial checkpoint actually contained:

The Distillation Pipeline

The core of Nexus is the DistillTranscript service. It takes raw transcript text and produces structured knowledge. Here's what it does:

1. Session identification: Generate a deterministic ID from the transcript content so we can detect duplicates and updates
2. LLM extraction: Send the transcript to an LLM with a carefully crafted prompt that extracts decisions, learnings, participants, and topics
3. Response processing: The LLM returns JSON
4. Deduplication: Check if we’ve already processed this session, and if so, only process new content
5. RDF transformation: Convert the structured JSON into semantic triples
6. Storage: Write the triples to Oxigraph

The prompt engineering was critical, but didn’t take a lot of time. The LLM needs to understand what counts as a “decision” versus a “learning,” how to identify participants, and how to extract meaningful topics without being too granular or too vague. Claude one-shotted it.

The RDF Schema

Claude designed a custom ontology for organizational knowledge:

@prefix nx: <https://nexus.zar.app/ontology#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .  # SKOS vocabulary

nx:Session a rdfs:Class ;
    rdfs:label "Session" ;
    rdfs:comment "A conversation or transcript session from any source" .

nx:Decision a rdfs:Class ;
    rdfs:label "Decision" ;
    rdfs:comment "An architectural, strategic, or implementation decision" .

nx:Learning a rdfs:Class ;
    rdfs:label "Learning" ;
    rdfs:comment "An insight, lesson learned, or piece of knowledge discovered" .

Every session, decision, and learning becomes a node in the graph with typed relationships. A decision nx:madeIn a session. A session nx:hasTopic concepts. A person nx:proposedDecision a decision. The graph structure enables queries that would be impossible with traditional relational storage.

The Claude Code Hooks

One of the most useful features landed on Day 1 and let me dogfood from that moment on: automatic transcript capture. Claude Code supports hooks that fire at various lifecycle points. I built a Stop hook that:

1. Captures the full conversation transcript from the session
2. POSTs it to a Nexus API endpoint
3. Handles authentication automatically (more on this later)

The hook is a simple shell script:

#!/bin/bash
# Capture Claude Code session transcript and send to Nexus

TRANSCRIPT=$(cat "$CLAUDE_TRANSCRIPT_FILE")
SESSION_ID="$CLAUDE_SESSION_ID"

curl -X POST "$NEXUS_URL/transcripts/ingest" \
  -H "Authorization: Bearer $NEXUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"content\": $(echo "$TRANSCRIPT" | jq -Rs .),
    \"source\": \"claude_code\",
    \"session_id\": \"$SESSION_ID\",
    \"project\": \"$CLAUDE_PROJECT_DIR\"
  }"

Every Claude Code session now automatically becomes organizational memory. No manual effort required. The transcript gets distilled, decisions and learnings get extracted, and everything becomes queryable.

Conversational Knowledge Queries

This one was fun. Instead of requiring users to write SPARQL (which, let’s be honest, nobody wants to do), I built a conversational interface. You ask a question in plain English, and an LLM translates it into SPARQL, executes the query, and explains the results.

The KnowledgeQueryAssistant service orchestrates this:

1. Question analysis: Understand what the user is asking for
2. Schema awareness: Know what entity types and properties exist in the graph
3. SPARQL generation: Translate the natural language question into a valid query
4. Execution: Run the query against Oxigraph
5. Result explanation: Present the results in human-readable form

It’s genuinely useful. “What decisions did we make about authentication?” becomes:

PREFIX nx: <https://nexus.zar.app/ontology#>
SELECT ?decision ?title ?description ?rationale WHERE {
  ?decision a nx:Decision ;
            nx:title ?title ;
            nx:description ?description .
  OPTIONAL { ?decision nx:rationale ?rationale }
  FILTER(CONTAINS(LCASE(?title), "authentication") ||
         CONTAINS(LCASE(?description), "authentication"))
}

The query returns matching triples, and the assistant presents them conversationally: “I found 3 decisions related to authentication. The most recent was ‘Use GitHub OAuth for user authentication,’ made yesterday…”

The Web UI

Even on Day 1, I wanted a browsable interface. The initial UI was already pretty full featured:

• Sessions list: See all ingested transcripts with their generated titles and summaries
• Decisions view: Browse all extracted decisions with their rationale
• Learnings view: Browse all extracted learnings
• Inquiries: For demonstration purposes and to validate functionality

That first day established the core architecture. Transcript in, LLM distillation, RDF storage, queryable knowledge. The foundation was solid. Everything after was iteration and enhancement.

Day 2: December 30th — Refinements and the Delta Problem

Commits: 5
Theme: Making it actually work in production

Day two was about confronting reality. The initial system worked beautifully for short transcripts. But Claude Code sessions can run for hours. Transcripts grow to thousands of lines. And the way I’d built the system, every time a transcript was submitted, it re-processed the entire thing.

That’s fine for demos. It’s not fine when you’re paying for LLM tokens and waiting for responses.

Enter delta distillation.

The insight was simple: track how much of each transcript we’ve already processed, and only distill the new content. But implementing it required rethinking the entire pipeline.

The Delta Algorithm

The new approach:

1. Content offset tracking: Store the character offset of how much we’ve processed for each session
2. Delta extraction: When a transcript update arrives, extract only the content after the last offset
3. Incremental distillation: Send only the new content to the LLM
4. Append-only storage: New decisions and learnings get added to the existing session, not replaced
5. Metadata preservation: Session title and summary come from the first distillation only

Here’s the commit that captured this change:

This is the kind of architectural decision that separates production software from demos. It required extracting new service objects (KnowledgeDeduplicator, KnowledgeQuery), rethinking how sessions were identified, and ensuring idempotent behavior when the same transcript got submitted multiple times with different lengths.

The TDD discipline proved essential here. Refactoring from full-transcript processing to delta-based processing could have introduced subtle bugs at every seam. But because we had comprehensive specs for the original behavior, I could refactor confidently. Change the internals, run the specs, verify everything still works. Then add new specs for the delta-specific behavior. The red-green-refactor cycle made a potentially dangerous architectural change feel safe.

This is exactly the pattern I’d internalized from decades of extreme programming practice: tests dissolve fear. When I encounter new code or need to make substantial changes, I don’t tiptoe around it worrying about breaking things. I know I can move in small steps, keep the system passing its tests at almost all times, try a refactoring and back it out if it doesn’t feel right. That safety net isn’t just technical. It changes how willing you are to explore.

By the way, introducing the delta algorithm and the entire refactoring I described above took about 30 minutes.

Killing the Action Items Feature

I also learned something important about my own system on Day 2: Action Items were noise.

The initial design extracted three types of knowledge: decisions, learnings, and action items. It seemed logical. Surely transcripts contain action items that people need to track?

The LLM was dutifully extracting them. “Need to update the database schema.” “Should add tests for the authentication flow.” “Remember to update the documentation.” Dozens of action items from each session.

The problem? They were almost always stale by the time anyone saw them. Claude Code sessions involve immediate implementation. By the time Nexus distilled “need to update the database schema,” the database schema was already updated. The action item was historical noise, not useful information.

Decisions and learnings persist; action items expire. I ripped out the entire feature: 11 files changed, 8 insertions(+), 132 deletions(-)

More lines deleted than added. A good sign. The willingness to remove features that don’t work is important. It’s easy to keep accumulating functionality. It’s harder to admit something isn’t useful and cut it.

Minor Fixes

The other commits were bug fixes and refinements:

• User tracking: Properly associate sessions with the API user who submitted them
• URI domain corrections: Claude has hallucinated zar.com into my ontology instead of zar.app in several places. Easy fix, including some rake tasks to fix existing data.
• Session deduplication edge cases: Handling discovered cases where two sessions have identical content but different metadata, stuff like that.

In other words, normal software development stuff, just happening at 50x speed.

Day 3: December 31st — The Explosion

Commits: 18
Lines added: ~3,000+
Theme: Production-ready features

New Year’s Eve. Most people are planning their parties or getting drunk. I’m in the zone. My first all-hands company meeting as CTO was tomorrow and I wanted to demo my work, so it’s go time.

This day was absolutely packed. Eighteen commits. Multiple major features. Let me break it down by capability.

RESTful Knowledge API

First up: proper REST endpoints for everything. The initial system had basic views, but nothing approaching a real API. Day 3 changed that.

Sessions, decisions, and learnings all got their own controllers with full RESTful endpoints:

GET  /sessions          # List all sessions
GET  /sessions/:id      # Show session details
GET  /decisions         # List all decisions
GET  /decisions/:id     # Show decision details
GET  /learnings         # List all learnings
GET  /learnings/:id     # Show learning details

Each endpoint supports multiple formats:

• HTML: For human browsing
• JSON: For API consumers
• TXT: For LLM consumption

The text format endpoints deserve special mention. When an AI agent requests /decisions.txt, it gets a clean, token-efficient representation:

# Decision: Use PostgreSQL with pgvector for semantic search
Rationale: Keeps vector storage in the same database as other data, simplifying the stack.
Session: 9cafca33-cb1c-49c4-8696-d8be97871356
Date: 2026-01-01

# Decision: Implement delta distillation
Rationale: Full re-processing is too expensive for long transcripts.
Session: bf6dd8f-1f2b-4f8c-8c81-c3551f2fb368
Date: 2025-12-30

No HTML cruft. No JavaScript. No navigation chrome. Just the knowledge, formatted for machine consumption. This is the kind of thing that matters when you’re building for a world where agents consume APIs.

GitHub OAuth + API Key System

This system will have precious knowledge stored. I can’t deploy it without authentication, so that was next. I went with GitHub OAuth because literally everyone at my company has a GitHub account. No signup friction, no password management, no email verification flows.

The most challenging part was the device authorization flow for CLI tools.

Claude Code hooks need to authenticate somehow, but they run in a terminal with no browser. I couldn’t find a way to share authentication state with an installed MCP server. Solution: a streamlined device flow that automatically opens your browser.

The flow works like this:

1. Hook calls POST /device/authorize
2. Server returns a device code and verification URL
3. Hook automatically opens your browser to the verification page (using open on macOS or xdg-open on Linux)
4. You see the Nexus authorization page and click to verify
5. If not already logged in, you’re redirected to GitHub OAuth
6. Meanwhile, the hook polls /device/token in the background
7. Once you authorize, the server returns an API token
8. Hook saves the token to ~/.config/nexus/api_key.<hostname> with secure permissions

The UX is seamless: on first run, your browser pops open, you click authorize, and you’re done. Future sessions authenticate automatically using the cached token.

Deployment Infrastructure

I wanted this running in production ASAP, not just localhost. I picked Render as my target platform since I know it inside and out, but Claude says that I took an unconventional approach: a single Docker container that bundles everything.

The container includes:

• PostgreSQL 17 with pgvector: Embedded database, not a managed service
• Oxigraph: The RDF triple store, also embedded
• Rails + Puma: The web application
• SolidQueue worker: Background job processing

All four processes are managed by Overmind, a Procfile-based process manager. One container, one persistent disk mount at /data, everything self-contained:

postgres: su postgres -c '/usr/lib/postgresql/*/bin/postgres -D /data/postgresql'
oxigraph: oxigraph serve --location /data/oxigraph --bind 127.0.0.1:7878
web: bundle exec puma -p 3000 -b tcp://0.0.0.0
worker: bundle exec rake solid_queue:start

Why bundle everything? Simplicity. No coordinating multiple services. No managed database pricing. No network latency between app and database. For a side project that might scale to a small team, this is perfect. If it needs to scale beyond that, breaking out the database is straightforward.

Is a single container deployment really unconventional? I don’t think it should be.

The commit also added:

• GitHub Actions workflow: Automated deployment on push to main
• CI pipeline: RSpec tests running before deploy, blocking bad commits

name: Deploy to Render
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: bundle exec rspec
  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Render
        uses: johnbeynon/render-deploy-action@v0.0.8
        with:
          service-id: ${{ secrets.RENDER_SERVICE_ID }}
          api-key: ${{ secrets.RENDER_API_KEY }}

By end of day, commits to main were automatically tested, built into Docker images, and deployed to production. From idea to deployed feature in minutes, not days.

The needs: test line is critical. No deployment happens unless the test suite passes. And because we'd been doing TDD from the start, that test suite was substantial.

By Day 3, we had specs covering:

• The full distillation pipeline with various transcript formats
• RDF transformation and SPARQL query execution
• Deduplication logic and delta processing
• Authentication flows for both web and API
• The conversational query assistant
• Edge cases for identity resolution

The TDD discipline was paying dividends in letting me practice continuous deployment with confidence.

Day 4: January 1st — New Year’s Day, New Capabilities

Commits: 29
PRs Merged: 12
Theme: Making it intelligent

Happy New Year! While normal people were recovering from celebrations, I was building an MCP server. Looking back at the commit log for January 1st, I honestly don’t know how I fit it all in.

The Ontology Browser

RDF is powerful because it’s self-describing. The schema itself is data. You can query the ontology just like you query the instances.

I wanted that exposed through the UI, so users (and agents) could explore what types of entities exist, what properties they have, and how to query them.

PR #19 delivered the ontology browser:

Visual grid of entity types: Session, Decision, Learning, Conflict, Person, Agent, Project, Concept, User, ExternalResource. Each card shows the type name, description, property count, and instance count.

Detail views: Click on any type to see its full property list, relationships to other types, and example SPARQL queries.

Downloadable Turtle format: Export the full ontology definition for use in other tools.

JSON API endpoints: So agents can programmatically explore the schema before querying.

This might sound minor, but it’s important for discoverability. When you land on a new knowledge system, you need to understand its shape. What kinds of things are stored? How are they related? What can you query for? The ontology browser provides that.

Identity Resolution

One of the big PRs of the day tackled a fundamental problem: who is involved in these sessions?

When a transcript mentions “Sarah made the decision to use PostgreSQL,” the system should understand that Sarah is a real person. It should link her to other sessions she’s participated in. It should enable queries like “What decisions has Sarah been involved in?”

This required multiple components:

New RDF entity types: nx:Person for humans, nx:Agent for AI assistants. They're both participants, but they need different handling. You want to track what decisions Sarah has made. You probably don't need to track what decisions Claude has "made" (though it's interesting for analysis).

IdentityResolver service: Takes a name or email from a transcript and resolves it to a canonical Person record. Handles variations: “Sarah,” “Sarah Chen,” “sarah@company.com” should all resolve to the same person. Uses fuzzy matching and email-based identification.

Attribution tracking: The distillation prompt now extracts not just “participants” but specific attributions: who proposed this decision, who discovered this learning, who contributed to the discussion.

People UI: A /people endpoint to browse and merge identities. Sometimes the system creates duplicate Person records that need manual consolidation.

The identity resolver is smart about AI names too. “Claude,” “Claude Code,” “Assistant,” “GPT-4,” “Copilot” all get correctly classified as agents, not people. This prevents accidentally creating Person records for AI assistants.

Around this time I started realizing that a lot of my entities were going to look similar. Maybe I could try to feed the context of the knowledge distillation worker with similar entities right off the bat? Or do some post-processing later? Either way I would need embeddings.

Semantic Search with pgvector

SPARQL is powerful but exact. You query for specific predicates and values. You get back things that match precisely.

What if you want conceptual similarity? “Find knowledge related to authentication” should surface:

• Decisions about OAuth
• Discussions about API keys
• Learnings about session management
• Security-related conflicts

Even if none of them literally contain the word “authentication.”

PR #21 added vector similarity search:

pgvector extension: PostgreSQL with the pgvector extension can store and query high-dimensional vectors. No separate vector database needed.

Embedding generation: Using Gemini’s embedding model (via OpenRouter), each decision and learning gets converted to a 768-dimensional vector that captures its semantic meaning.

RdfEntity model: A PostgreSQL table that mirrors entities from the RDF store and adds vector embeddings. When knowledge gets distilled, each entity is queued for embedding generation.

SemanticSearch service: Takes a natural language query, embeds it, and finds the closest matches in vector space.

class SemanticSearch
  def search(query, limit: 10)
    query_embedding = EmbeddingService.embed(query)

    RdfEntity
      .nearest_neighbors(:embedding, query_embedding, distance: "cosine")
      .limit(limit)
      .map { |entity| enrich_with_rdf_data(entity) }
  end
end

When knowledge gets distilled, each decision and learning is automatically queued for embedding generation. The graph stays in sync with the vector index.

Conflict Detection

Knowledge systems accumulate contradictions. This is inevitable. Two sessions might record opposing decisions:

• Session A: “Decided to use REST APIs for the mobile client”
• Session B: “Decided to use GraphQL for the mobile client”

Or learnings that directly contradict each other:

• Learning 1: “Caching improved performance by 40%”
• Learning 2: “Caching caused consistency issues and was removed”

Rather than silently harboring inconsistency, Nexus now surfaces these explicitly.

PR #22 added the Conflict entity type:

Async conflict detection: After each distillation, a background job scans for potential conflicts. It uses embeddings to find semantically similar items, then prompts an LLM to assess whether they actually conflict.

Status tracking: Conflicts can be: open, investigating, resolved. Each status change gets tracked with timestamps.

Priority levels: Not all conflicts are equal. A contradiction between architectural decisions is more important than conflicting preferences about code style.

Entity Browser

The ontology browser shows the schema. But what about the actual data? You need to be able to browse and search the instances themselves.

PR #25 and #27 added entity browsing:

/entities endpoint: Browse all entities with type filtering. Show me all Decisions. Show me all Learnings. Show me all Conflicts.

Search: Both exact text search and semantic similarity search. Find entities that mention “authentication” literally, or find entities conceptually related to authentication.

Individual entity views: Click through to see all properties and relationships for any entity.

Counts in ontology view: The ontology browser now shows how many instances of each type exist.

The MCP Server

MCP (Model Context Protocol) is Anthropic’s standard for exposing tools to AI agents. By embedding an MCP server in Nexus, any AI agent can directly query the organizational knowledge base.

Think about what this enables. Before starting to implement a feature, Claude Claude can be configured to check Nexus: “Has this team made any decisions about authentication patterns?” Before proposing an architectural change, it can query: “What learnings do we have about caching in this codebase?”

PR #30 implemented the MCP server with five tools:

nexus_ontology: Get the full schema with types, properties, and example queries. This is the starting point for exploration.

nexus_type: Get detailed information about a specific entity type. “Tell me about Decision entities.”

nexus_recent: Fetch recent sessions, decisions, learnings, or conflicts. “What were the last 10 decisions?”

nexus_query: Execute arbitrary SPARQL queries. For agents that know what they’re looking for.

nexus_search: Semantic vector similarity search. “Find knowledge related to database performance.”

The tools follow HATEOAS-style progressive discovery. Each response includes hints about what to query next. An agent can start with nexus_ontology, understand the schema, then drill into specific types, then query for specific instances.

Agent: nexus_ontology()
→ Returns: all types with descriptions and example queries
  Hint: "Use nexus_type('Decision') for detailed Decision properties"

Agent: nexus_type(type_name: "Decision")
→ Returns: properties, relationships, example query
  Hint: "Use nexus_recent(type: 'Decision') to see recent decisions"

Agent: nexus_recent(type: "Decision", limit: 5)
→ Returns: 5 most recent decisions with full details
  Hint: "Use nexus_query() with SPARQL for more specific queries"

The MCP server gives them read access to everything Nexus knows. The organizational memory is no longer just for humans browsing a web UI; it’s infrastructure that agents consume, which was the goal from the start.

Twenty-nine commits. Twelve merged PRs. On January 1st. I still can’t quite believe it.

Days 5–6: January 2nd-3rd — Opening the Floodgates

Commits: ~10
Theme: Universal ingestion

I successfully demoed the system at our Friday all-hands company meeting. People are psyched. I’m psyched. The system was powerful, but it only captured Claude Code sessions. What about all those other knowledge sources I mentioned at the start? GitHub PR discussions. Slack threads. Linear issues. What about non-engineers. The vision was passive ingestion from everywhere, right? Time for some magic.

Universal Webhook Processor

PR #33 was the key unlock. Instead of building bespoke integrations for every SaaS platform, I built a universal webhook endpoint that uses AI to understand and transform any JSON payload:

POST /webhooks/:source

Point GitHub webhooks here. Linear webhooks here. Slack event subscriptions here. Notion webhooks here. Any service that can POST JSON can become a knowledge source.

The WebhookProcessor service:

1. Receives the raw JSON payload: No assumptions about structure
2. LLM analysis: Uses Gemini 3 Flash to understand what kind of webhook this is and extract meaningful content
3. Transcript transformation: Converts the webhook into a “transcript” format that the existing distillation pipeline can process as if it was coming from Claude Code.
4. Job queuing: Enqueues a distillation job for background processing

The beautiful part is graceful degradation:

• Slack: Gets optimized handling with a specific extractor that knows where to find the relevant content. (See next section.)
• Everything else: The LLM analyzes the JSON structure and makes its best effort to extract meaningful content

Some random internal tool sends webhooks? As long as there’s meaningful text content somewhere in the payload, Nexus will try to distill knowledge from it.

Slack Integration

Slack deserved deeper integration than just webhooks. It’s where so much organizational discussion happens.

PR #34 added:

Slack Events API handler: Real-time event processing for messages, reactions, and thread updates.

SlackThreadCollector: Fetches and formats entire threads with full context. When a thread gets distilled, we capture the whole conversation, not just the triggering message.

Threshold filtering: Not every Slack message is worth preserving. The defaults require at least 3 replies or 2 participants before auto-ingestion. ∑e also filter out many casual “sounds good” (ok, lol, etc) while capturing substantive discussions.

ID resolution: Slack uses internal IDs like U09RS4298TY for users and C01234ABCDE for channels. The LLM now has a tool to resolve these to human-readable names. "U09RS4298TY said..." becomes "Obie Fernandez said..."

The threshold filtering is important. Slack generates enormous amounts of content. Without filtering, you’d be paying to distill “sounds good” and “thanks!” a thousand times a day.

Metadata as RDF Properties

The final architectural piece: when sessions originate from webhooks, their metadata becomes queryable.

PR #44 added new RDF properties for webhook-originated sessions:

nx:sourceUrl: A link back to the original resource. For a GitHub PR discussion, this links to the PR. For a Slack thread, it links to the thread in Slack.

nx:resourceType: What kind of external resource this came from: pull_request, issue, slack_thread, linear_issue, etc.

nx:eventType: What triggered the session: pr_opened, pr_reviewed, issue_commented, message_posted.

nx:significance: Impact categorization: low, medium, high. Webhook processors can assess significance based on factors like number of participants, length of discussion, or explicit markers.

Now you can query:

PREFIX nx: <https://nexus.zar.app/ontology#>
SELECT ?session ?title ?url WHERE {
  ?session a nx:Session ;
           nx:resourceType "pull_request" ;
           nx:significance "high" ;
           nx:title ?title ;
           nx:sourceUrl ?url .
}

“Show me all high-significance decisions from GitHub PRs in the last month.” The RDF graph knows where knowledge came from, not just what it contains.

The Numbers

Despite the detail in this now very long blog post, I still feel like I’m only scraping the surface of the work that was involved.

Code

• ~12,800 lines of code across app, lib, and spec directories
• 20+ controllers handling various endpoints
• 10+ models including Person, RdfEntity, Inquiry, DeviceAuthorization
• 15+ services for distillation, transformation, search, conflict detection, identity resolution
• A full-featured first draft of a Nexus ontology with 10 unique types and 23 properties
• Comprehensive test coverage with RSpec (247 examples)
• Working integration with Claude Code, Github, Slack, and Linear

Infrastructure

• Full deployment infrastructure on Render with CI/CD
• Production-ready authentication with GitHub OAuth and API keys
• MCP server for agent integration
• Universal webhook ingestion for any SaaS platform

Timeline

December 29th to January 3rd. Call it four working days. Here’s a full list of the PRs.

What This Means

I’ve built a lot of software in my career. I’ve owned and run substantial software delivery consulting organizations. I know how long projects typically take and I know what they cost. I know the difference between “working demo” and “production system.”

What Claude Code enabled me to do this week is not incremental improvement. It’s categorical change.

A system like Nexus, built by a solo developer in the “old” way, would take months. Each of the following bullet points would take at least a week or two, assuming a motivated engineer with little in the way of distractions.

• Research and spike the RDF/SPARQL approach
• Design the schema and ontology
• Build the ingestion pipeline
• Implement distillation with prompt engineering
• Add authentication and authorization
• Build the web UI
• Set up deployment infrastructure
• Add semantic search with vector embeddings
• Build the MCP server
• Test everything thoroughly
• Handle the hundred edge cases that emerge

That’s at least 13 weeks of focused development. Call it 4–5 months. And that’s with an experienced developer who knows the technologies involved. This would not be a viable side project for a typical engineer that has other deliverable feature work. For a busy CTO? Yeah, right.

Yet I did it in the time between Christmas and New Year’s, and still had time for regular work, walking my dog, and holiday activities. The leverage is absurd. (Admittedly some of the work was done on Claude Code on my phone at the barber shop.)

It’s not about replacing experienced developers. My architectural judgment, domain knowledge, and product intuition were essential every step of the way. Claude Code couldn’t have built Nexus alone. It’s very likely that you, dear reader cannot build Nexus in a few days if you tried, even with Claude Code’s help. An AI coding agent doesn’t automatically understand my company’s needs, our existing infrastructure, our preferences for certain patterns. But I couldn’t have built it this fast alone either.

Never. Would. Have. Happened.

The Development Experience

Productivity measures don’t capture the qualitative difference involved in working this way. Traditional development has a certain rhythm. You think about what you want to build. You start typing. You hit issues, debug them, refer to documentation, search Stack Overflow. You write tests. You refactor. Each step takes time, and there’s cognitive overhead in context-switching between “thinking about the problem” and “mechanically implementing the solution.”

AI-assisted development collapses that overhead. I stay in “thinking about the problem” mode almost the entire time. When I need something implemented, I describe it. When I need documentation, I ask. When I hit an issue, I describe the symptoms and get debugging suggestions.

Actually, if I happen to think of something new that’s outside of the current workstream, you know what I do? I used to log an issue. Now I use the & prefix in Claude Code to just fire up a remote instance and have it start working on whatever I thought of.

I’ve been reflecting on this shift in What Happens When the Coding Becomes the Least Interesting Part of the Work, which recently went mega viral. For someone at my experience level, the actual typing of code has long since stopped being the thing that teaches me anything. The intellectual work happens before the first line is written: understanding the problem space, recognizing patterns from decades of experience, making judgment calls about abstraction levels, assessing blast radius of changes, feeling out whether something should be general or specific.

That’s the “senior thinking” that AI doesn’t replace. What AI does replace is the mechanical translation of those decisions into working code. And honestly? That translation was always the boring part.

The experience is closer to pair programming with a very capable, very fast colleague who never gets tired and knows every API by heart. I’m still making all the decisions. I’m still responsible for the architecture. But the mechanical parts happen at conversation speed instead of typing speed.

Conclusion

Enterprise software vendors charge six and seven figures for knowledge management systems. They’re built by teams of dozens over years. They require consultants to implement and months to configure.

I built equivalent functionality in four days. While doing my day job as a CTO. Yes, I’m exceptional, but so what? I can only do it today because the tools have changed so dramatically.

If you’re a developer who hasn’t tried Claude Code yet, you’re working with one hand tied behind your back. The productivity multiplier is real. The creative leverage is real. The ability to turn ideas into working systems in days instead of months is real.

But bring your discipline with you. Bring your tests. Bring your judgment. The AI provides velocity. You provide direction. Together, you build things that neither could build alone.

Live in EMEA and want to work on Nexus and AI agents with me? I’m currently hiring senior product engineering talent with Ruby on Rails expertise at ZAR, where we’re building the future of global stablecoin adoption.

Better living through chemistry

I’ve spent most of my life operating at the intersection of high-performance engineering, entrepreneurship, and electronic music. My schedule swings between deep technical work, long creative sessions, international travel, and occasional late-night shows. That lifestyle demands a cognitive and physical baseline that doesn’t happen by accident. Besides regular exercise and an increasingly consistent sleep schedule, I’ve also built a supplement stack that keeps me sharp, stable, and resilient, and for 2026 I’ve refined it into something that feels complete.

This is my version of better living through chemistry at age 51.

What follows is a full breakdown of what I take, why I take it, and how the pieces fit together. For what it’s worth, this is also the first time I’m documenting this information in public. Thanks to @bryan_johnson and the popularity of peptides it seems like the Overton window for this kind of supplementation has shifted quite a bit in the last 12 months. I’m still a freak, but I’m in good company now.

Nothing in this post is medical advice. A lot of this involves prescription medication and experimental compounds; work with a real doctor if you decide to go anywhere near this territory. Also yes, this shit gets expensive fast and your mileage definitely will vary. Don’t say I didn’t warn you.

Core Cognitive Stack

The foundation of my productivity revolves around a simple principle: support focus without degrading long-term neurological health. I do that with a combination of modafinil, phenylpiracetam, and targeted precursors that has entirely cut my use of traditional amphetamine-based ADD medicines.

Modafinil This is my primary focus tool. It gives me reliable mental clarity and stamina during long engineering or creative sessions, and it smooths out jet lag when I’m bouncing between continents. I dose conservatively and take structured breaks to keep it effective.

Phenylpiracetam Every few days I rotate modafinil out and replace it with phenylpiracetam. The effect profile is different — more dopaminergic, more immersive — and it helps prevent tolerance buildup. It’s perfect for deep, locked-in work where I want both speed and enjoyment.

Choline + Dopamine Precursors

Modafinil can drain choline levels, which is why I pair the stack with daily CDP-Choline. It prevents headaches and keeps mental clarity crisp. I also use L-Tyrosine everyday to ensure sustained dopaminergic output, especially on heavy performance days.

Stress, Focus & Mood Modulation

Some days demand raw horsepower, but most days require controlled, quiet consistency. This part of my stack keeps my internal environment steady under the pressure of work, deadlines, and travel.

L-Theanine This is the unsung hero of my daily routine. It keeps cortisol smooth, helps me avoid stimulant edginess, and improves sleep quality later in the day. It’s subtle, reliable, and essential.

NAC Long-term stimulant use, travel fatigue, and intense schedules create oxidative stress. NAC keeps glutathione topped up and helps maintain clean neurotransmitter cycling. It also pairs well with dopamine-modulating compounds.

Peptide-Based Enhancement

Peptides are where modern neurochemistry gets genuinely interesting. They modulate plasticity and focus in ways traditional supplements can’t match.

Semax Provides clean, upward-tilting cognitive profile: slightly more plasticity, slightly more drive, noticeably better retention during reading or learning sessions. It pairs extremely well with coding.

Selank Where Semax nudges productivity upward, Selank smooths emotional load downward. Travel and deadlines are easier to navigate on Selank. It provides calm clarity without dullness.

Looking for a reliable peptides supplier? Try Peptaura and use code OBIE for 20% discount at checkout.

Longevity, Cellular Energy & Metabolic Control

Vitamin D3 + K2

A foundational combo for immunity, mood stability, hormone balance, and calcium regulation.

How it works (plain language):

• D3 boosts mood, immune function, and metabolic health.
• K2 ensures calcium goes to bones instead of arteries.
• Together they support long-term cardiovascular and cognitive health.

Magnesium (Glycinate & L-Threonate)

I use glycinate for muscle recovery and calm, and L-threonate for deep sleep and cognitive restoration.

How it works:

• Glycinate is highly bioavailable and relaxes the nervous system.
• L-threonate crosses the blood–brain barrier and improves synaptic density.

Probiotics (Lactobacillus Reuteri)

This specific strain has unique effects on mood, immune resilience, and even social behavior.

How it works:

• Increases oxytocin signaling.
• Improves skin, gut lining integrity, and overall immune modulation.
• Promotes a calmer, more connected mental state.

Triphala

My go‑to for gentle digestive resilience everyday, taken at night along with probiotics on empty stomach for maximum effectiveness. Along with a glass of high-quality psyllium husk fiber everyday, this makes sure that the GLP-1 doesn’t prevent me from pooping regularly.

How it works:

• A blend of three Ayurvedic fruits that improve gut motility and reduce inflammation.
• Supports nutrient absorption and reduces digestive stress.

Beetroot Extract

Taken before training for vascular support and stamina.

How it works:

• Provides nitrates that convert into nitric oxide.
• Improves blood flow, workout capacity, and cognitive oxygenation.
• Supports strong sexual performance!

Collagen Peptides

Part of my long-term joint, skin, and connective tissue maintenance. I know it works because people always assume I’m in my 30s, in no small part due to my healthy skin complexion.

How it works:

• Provides amino acids for collagen synthesis.
• Supports joint health and faster recovery.

Creatine Monohydrate

One of the most-researched performance supplements and part of my daily baseline.

How it works:

• Enhances ATP regeneration in both muscles and neurons.
• Improves strength, recovery, and cognitive clarity.

A glass of creatine in the morning also works really well to shake the mental fog when I get less than 7 hours sleep.

Pterostilbene

A more bioavailable analog of resveratrol derived from blueberries.

How it works:

• Supports mitochondrial function.
• Provides antioxidant and anti-inflammatory benefits.
• May improve lipid profiles and longevity markers.
• Noted for benefits to young and healthy looking skin.

NAC

Previously listed in the stress/mood section, but it also belongs here.

How it works:

• Replenishes glutathione, the body’s master antioxidant.
• Protects the liver and reduces oxidative stress from stimulants or travel.

Red Yeast Rice + CoQ10

My cholesterol levels are somewhat high due to genetic factors. So I take Red Yeast Rice every night for lipid management instead of prescription statins.

How it works:

• Red yeast rice contains monacolin K, which works like a mild statin.
• CoQ10 prevents the mitochondrial depletion that statins can cause.

Pygeum + Saw Palmetto

For hormonal balance and prostate support.

How it works:

• Both reduce DHT conversion.
• Smooth out urinary flow, reduce inflammation, and support long-term male endocrine health.

DIM (Diindolylmethane)

DIM has been a quiet but reliable part of my hormonal health toolkit, especially for estrogen metabolism.

How it works (plain language):

• Helps the body convert estrogen into its beneficial metabolites rather than the problematic ones.
• Supports hormonal balance, mood stability, and clearer skin.
• Useful during cycles of high stress, travel, or disrupted sleep when estrogen pathways tend to get messy.

It’s subtle, but over time it keeps things smooth in a way you definitely notice when you stop taking it.

Taurine

A multi-functional amino acid with wide-ranging benefits.

How it works:

• Supports GABAergic calming.
• Improves cardiovascular function.
• Enhances mitochondrial performance and electrolyte balance.

Lysine

One of the oldest staples in my supplement routine (going on 20 years) and still indispensable.

How it works (plain language):

• Lysine is essential for collagen formation, immune resilience, and tissue repair.
• Helps prevent HSV flare-ups — the original reason many people begin supplementing it.
• Supports calm and mood stability by influencing serotonin receptors.
• Useful during heavy travel, stress cycles, or when sleep is inconsistent.

It’s simple, inexpensive, and consistently effective — which is why it never left my stack.

Serrapeptase

An enzyme with systemic anti-inflammatory and fibrinolytic effects.

How it works:

• Breaks down excess fibrin, scar tissue, and inflammatory byproducts.
• Supports cardiovascular health and reduces swelling.

Fish Oil (Omega-3 EPA/DHA)

Fish oil has been part of my baseline for years because it supports cardiovascular health, reduces inflammation, and improves cognitive performance.

How it works (plain language):

• EPA reduces systemic inflammation.
• DHA is a structural component of neuronal membranes and improves signaling efficiency.
• Together they support mood stability, brain health, and long-term heart protection.

Black Seed Oil (Nigella Sativa)

A broad-spectrum anti-inflammatory and metabolic support compound I’ve used intermittently.

How it works (plain language):

• Contains thymoquinone, which reduces inflammatory markers and oxidative stress.
• Supports metabolic health and may improve insulin sensitivity.
• Provides mild antihistamine and bronchodilation effects — helpful during travel or allergy cycles.

Saffron Extract

Saffron is one of the few natural mood-enhancing supplements with strong clinical backing.

How it works (plain language):

• Boosts serotonin through mild reuptake modulation.
• Reduces anxiety and improves mood without sedation.
• Has comparable effects to low-dose SSRIs in several trials, but with a cleaner side-effect profile.

Taking care of my dopamine levels

Agmatine

Plays a stabilizing role in my stack. By modulating NMDA receptors and supporting nitric oxide pathways, it helps smooth out the sharper edges of stimulants, improves training performance, and slows tolerance buildup across dopaminergic compounds.

How it works (plain language):

• It acts like a “volume knob” on excitatory neurotransmission, preventing overstimulation.
• It improves blood flow through nitric oxide pathways, which supports both cognition and physical training.
• It interacts with the same receptors involved in opioid tolerance, which is why it can help prevent tolerance creep from dopaminergic compounds too.

It’s one of the simplest additions with the broadest synergistic effects.

Mucuna Pruriens

My natural dopamine reset. Because it contains L-DOPA, it provides gentle dopaminergic replenishment on the days following heavier modafinil, phenylpiracetam, or peptide cycles. Used sparingly, it prevents the motivational dip that can follow high-output periods and supports a smooth return to baseline.

How it works (plain language):

• Mucuna contains L-DOPA, the direct precursor your brain uses to make dopamine.
• Instead of forcing a dopamine spike, it restores raw material so your brain can rebuild its supply naturally.
• This makes it ideal for days after hard mental output, when neurotransmitter stores may be temporarily depleted.

How it compares to synthetic dopamine agonists:

• Mucuna (L-DOPA): Provides dopamine building blocks. Your brain stays in control of how much is converted and released. The result is smoother, more physiologic support.
• Synthetic agonists (e.g., pramipexole, ropinirole): Directly stimulate dopamine receptors, bypassing normal regulation. This produces much stronger effects but also increases risks like receptor downregulation, compulsive behaviors, and harsh withdrawal.
• Why I prefer Mucuna: Natural replenishment avoids the “yo-yo” pattern that comes with synthetic agonists. It lifts motivation without hijacking dopamine pathways or creating dependency patterns.

Used correctly, it feels like sharpening the motivational edge without overstimulation.

Sustainable Performance & Energy

Performance only matters if it’s sustainable. This section of my stack focuses on metabolism, mitochondrial efficiency, cardiovascular health, and fat loss.

Methylene Blue A low dose supports mitochondrial electron transport and consistently sharpens my thinking. I use it deliberately, not daily, when I want maximum clarity.

Lactoferrin Initially I added this for immune support, but it has a meaningful fat-loss effect when used consistently. It’s also excellent during travel and high-stress cycles.

Nattokinase Cardiovascular resilience matters when traveling constantly and occasionally using stimulants. Nattokinase supports fibrin breakdown and blood flow.

Sleep Optimization & Recovery

Everything falls apart without sleep, especially in a lifestyle that often includes late-night shows and early-morning flights. I keep this part simple.

Magnesium L-Threonate This form crosses the blood-brain barrier and reliably deepens my sleep. It helps me wake up clear instead of groggy, especially after stressful days.

Theanine (Night Protocol) If I take theanine during the day, I use a second dose in the evening to ease the transition into sleep. It stacks well with magnesium for a non-drug, non-groggy wind-down.

I’ve drawn major inspiration from Bryan Johnson’s Blueprint protocol in the last year, prioritizing consistency and environmental tweaks to combat the chaos of irregular schedules. I aim for a fixed bedtime every night, winding down with a physical book in hand about 10 minutes before lights out, and keep the room pitch-black and cool around 65–68°F during the night. Lately I’ve been trying to not drink any liquids before bedtime to avoid waking up to pee. Finishing my last meal four hours before bed prevents digestive interference, letting me recover deeply.

Lately I’ve also been making it a point to get bright morning light exposure right upon waking to reset my circadian rhythm. Since shifting my wake time to before sunrise, it’s not possible to get this naturally so I’m planning to buy one of those high LUX lamps.

Microdosing GLP-1s

This is one of the biggest structural changes I’m making to my 2025 stack: switching to very low-dose GLP-1 receptor agonists as a background metabolic governor instead of going full “Wegovy dosage” mode.

I’m using “microdosing” here in the biohacker sense: doses substantially lower than the standard obesity/diabetes protocols, tuned to blunt appetite and clean up food noise without the full GI side-effect package or drastic, rapid weight loss.

What GLP-1s Actually Do

GLP-1 receptor agonists like semaglutide and liraglutide work through a few big levers:

• Appetite and satiety centers in the brain
• Gastric emptying and gut signaling
• Reward and food motivation circuitry
• Glycemic and cardiometabolic effects

Large randomized trials (STEP, SELECT, SCALE) show significant weight loss and cardiovascular improvements at full therapeutic doses. I took advantage of that in 2025 to drop almost 20 pounds and increase my motivation at the gym, and am now feeling healthier than ever.

My use case in 2026 will be different: leveraging the same mechanisms at much lower intensities.

Why Microdosing Might Still Work

GLP-1 drugs are very expensive and dose-responsive. Lower exposures will not be felt as strongly, but should still:

• Reduce hunger and food chatter
• Flatten reward response to hyperpalatable foods
• Improve post-meal glycemic stability

Therefore I treat GLP-1s as a long-horizon metabolic nudge, not a crash diet.

Experimental & Research Compounds

I often test compounds that sit on the frontier of nootropics and have done so for nearly 30 years, since the first time I got my hands on some Piracetam. These aren’t daily tools but part of my ongoing exploration.

• Seltorexant
• Mirodenafil
• AMPAkine-adjacent or receptor-specific modulators

These remain in the R&D bucket — interesting, sometimes powerful, but not part of my baseline stack.

α-MSH (Melanotan-Related Compounds)

I’ve recently started experimenting with α-MSH analogs for their unique interactions with melanocortin receptors that influence appetite, inflammation, and mood. In low, infrequent doses they are supposed to provide a subtle but noticeable lift in drive, energy, and overall resilience.

How it works (plain language):

• Your body naturally produces α-MSH as part of the system that regulates appetite, energy expenditure, and inflammation.
• When stimulated, melanocortin receptors essentially send the signal: “Boost energy, reduce appetite, stay alert.”
• The effect feels like a mild rise in motivation and metabolic tone, not a stimulant high.

They aren’t part of my daily routine, but they sit in the category of highly targeted tools I deploy when the benefits align with the demands of my schedule.

Dopamine-Targeted Research Compounds

I’ve been experimenting with a rotating set of modern, targeted molecules that support motivation, mood, and cognitive drive without the crash profile of classic stimulants. The rabbit hole for these kinds of compounds is super deep. They include:

• Bromantane
• Usmarapride
• ACD-856
• TAK-653
• GB-115
• Pinealon

I don’t treat these as daily staples. They’re tools, not crutches — useful when I need to amplify creativity, stabilize mood during intense work cycles, or get past bottlenecks in motivation.

How the Stack Fits Together

The value of this stack isn’t in the individual items — it’s in the architecture.

Morning

• Light dopamine precursors
• Modafinil or phenylpiracetam
• Theanine for smoothing
• NAC and metabolic support
• Low-dose GLP-1 as a passive appetite/reward governor

Afternoon

• Peptides during learning or coding sessions
• Optional dopamine-targeted compounds
• Hydration + electrolytes

Evening

• Magnesium L-Threonate
• Theanine
• No stimulants after the cutoff
• Lactoferrin and nattokinase depending on travel and workload

Weekly Cadence

• Rotate stimulants
• Avoid tolerance buildup
• Maintain stable sleep
• Keep GLP-1 dosing modest and consistent
• Track energy, focus, appetite, and mood without chasing novelty

What’s New for 2026

A few shifts define this year’s stack:

• Greater focus on metabolic health and cardiovascular longevity
• Strategic use of micro-dosed GLP-1s
• More precision with dopamine modulation
• Peptides as an established productivity tool
• Targeted, mechanism-driven supplementation instead of broad-spectrum blends
• Smarter cycling and recovery

The result is a stack that supports both sides of my life: the engineer and the artist.

Looking for a reliable peptides supplier? Try Peptaura and use code OBIE for 20% discount at checkout.

Por qué la IA se siente como trampa para algunas personas

La reacción contra la IA en la era de los modelos de lenguaje suele presentarse como un debate sobre la verdad, la seguridad, la creatividad o el empleo. Ese encuadre pasa por alto el conflicto real. Lo que está bajo ataque no es el trabajo, ni el arte, ni siquiera las relaciones humanas. Es una forma particular de mantener un sentido del yo.

La verdadera división se da entre dos modelos de subjetividad. Llamémoslos monádico y poliádico.

El yo monádico es indivisible. Experimenta el significado a través del aislamiento, el esfuerzo y la lucha visible. El trabajo solo es real si puedes verte a ti mismo haciéndolo. El resultado importa menos que el esfuerzo que lo precede. Este es el modelo de Sísifo. Empujo la piedra, luego existo, interminablemente.

El yo poliádico funciona de otra manera. Mantiene su coherencia a través de la coordinación. El pensamiento se externaliza por defecto. Las ideas rebotan entre personas, cuadernos, herramientas y sistemas. El yo no se ve amenazado por la delegación porque la autoría vive en la dirección, no en la ejecución. Este es el modelo del director de orquesta. Orquesto, luego existo.

Ninguno de estos modelos es particularmente nuevo y ambos han coexistido durante mucho tiempo. Lo nuevo es que los LLM reducen el costo de la cognición externalizada casi a cero. Ese colapso desestabiliza la identidad monádica de una forma que se siente escandalosamente existencial, incluso cuando los argumentos en la superficie suenan técnicos o morales.

Esto se ve con claridad en lo que parece ser un pánico viral en torno a la Generación Z usando ChatGPT para analizar conversaciones de citas y redactar respuestas.

Las objeciones al uso de ChatGPT de esta manera suelen ser ruidosas y mayormente negativas. Distópico. Sin alma. Inauténtico. Manipulador. Como si algo sagrado hubiera sido profanado.

Pero en realidad no está pasando nada nuevo.

Las personas siempre han externalizado la incertidumbre romántica con sus amigos y confidentes más cercanos. Muestran mensajes privados. Ensayan conversaciones, especialmente las difíciles. Preguntan qué quiso decir alguien. En la era de las redes sociales, incluso a veces externalizan el consejo amoroso a una audiencia más amplia. La diferencia ahora es que la capa de coordinación para esa externalización es mucho más rápida, más silenciosa y, creo que de forma beneficiosa, más coherente. La lucha ritualizada ha sido eliminada.

Pero para un yo monádico, la lucha es el punto. La incertidumbre romántica funciona como la piedra de Sísifo. Si no sufriste la confusión ni arriesgaste la vergüenza, entonces la conexión resultante se siente inmerecida. La optimización parece trampa porque evita la prueba que produce significado, incluso si esa prueba puede arruinar cualquier posibilidad de un resultado positivo.

¿Usar ChatGPT para guiar el comportamiento en una relación es realmente distinto de seguir el consejo de un terapeuta que cita la investigación de Gottman? Si ambos caminos conducen a una modificación deliberada del comportamiento, ¿por qué uno se siente mal y el otro aceptable?

Funcionalmente, no hay diferencia. El consejo puede ser idéntico. El comportamiento puede ser idéntico. Los resultados pueden ser idénticos.

La diferencia es el ritual. Por eso las mismas personas que rechazan los mensajes asistidos por IA no tienen problema en pagar por libros de autoayuda o terapia.

Un terapeuta preserva la jerarquía. Controla el acceso al conocimiento. Cobra dinero, mucho dinero. Exige agendas, presencia y exposición social. El consejo llega envuelto en un esfuerzo sancionado por la sociedad. El yo monádico sobrevive intacto a ese tipo de externalización porque el sufrimiento, el permiso y la legitimidad siguen formando parte del proceso.

Un LLM colapsa todo eso en un instante. Sin jerarquía. Sin guardianes. Sin costo social. Sin trabajo visible. Solo coordinación.

Ese colapso es lo que se siente distópico para mucha gente.

En otro momento político, esto habría provocado una reacción conservadora en toda regla. No la versión actual de guerra cultural, sino el impulso más antiguo de defender la jerarquía, la fricción y la autoridad ganada. Si el trumpismo no hubiera vaciado al conservadurismo estadounidense y lo hubiera reemplazado por agravio y espectáculo, creo que la oposición a la IA sería mucho más ideológica y mucho más organizada.

Los LLM aplanan estructuras de estatus que antes se sentían naturales. Cortocircuitan profesiones basadas en el control de acceso. Disuelven el vínculo entre esfuerzo y legitimidad. Ese es exactamente el tipo de cosas que el conservadurismo tradicional solía existir para resistir.

He visto la misma división desarrollarse en el software durante el último año, y yo vivo firmemente en uno de esos lados.

Existe una versión del programador cuya identidad está atada a las pulsaciones del teclado. El código es real si está escrito a mano. Pensar se equipara con escribir. La asistencia se siente como contaminación. El significado proviene de la manipulación directa de símbolos, línea por línea, en soledad. Seguramente hay una correlación con los programadores que juran por VIM.

En contraste, está el programador que trata el desarrollo de software como un sistema complejo, no como una actuación. El trabajo no es teclear. El trabajo es especificar intención, restricciones y criterio, y luego guiar el sistema hacia un resultado. Intuyo aquí una conexión con quienes idealizamos enfoques como Behavior-Driven Development (BDD, desarrollo guiado por comportamiento), que ya insinuaban un futuro donde la implementación quedaba subordinada a la especificación.

Cuando la gente dice que las interacciones mediadas por IA no tienen alma, no está haciendo una afirmación metafísica. Está describiendo la ausencia de un ritual que valida la autenticidad para ellos.

Hoy uso herramientas agenticas como Claude Code para generar, refactorizar, probar y explorar. No solo el código, sino todo el proyecto, incluyendo el trabajo de otras personas. Solo intervengo donde el juicio importa. Esto no me hace sentir menos programador. Me hace sentir más responsable del resultado, porque puedo hacerme cargo de una parte mayor de él.

El tema de la música generada con IA hace este conflicto aún más evidente.

El artista monádico ubica la autenticidad en el esfuerzo. El sufrimiento es la prueba. El trabajo manual es la señal. Las herramientas se vuelven sospechosas cuando cruzan una línea invisible entre asistencia y autoría.

Yo también hago música de manera profesional, y este año me he apoyado fuertemente en la generación asistida por IA con Suno, especialmente para materializar mi composición original. No porque no pueda escribir o producir sin ella, sino porque me importan más los resultados que ejecutar los rituales tradicionales por mí mismo.

Este enfoque no es nuevo para mí. Tengo problemas auditivos bastante significativos por décadas de ambientes ruidosos, lo que significa que no puedo hacer una mezcla final decente ni de broma. Así que trabajo con un excelente ingeniero de grabación para terminar mis temas, y no hay ninguna vergüenza en eso.

En cuanto a Suno, si pudiera permitirme contratar regularmente a compositores y cantautores de clase mundial para colaborar como vocalistas y pulir mis letras, lo haría sin ningún pudor.

Como muchos productores modernos, trato el sonido como un material maleable. Uso presets de sintetizadores y sampling sin reparos. Compongo a través de dirección, selección e iteración, a menudo en colaboración con artistas más talentosos que yo. No confundo mi inversión de tiempo manual con el significado. Tal vez confundo el significado con el significado.

Ya hemos visto esta película antes. El sampling. Las cajas de ritmos. La música electrónica. El autotune. Cada uno provocó pánico sobre el alma y la autenticidad. Cada vez, el arte sobrevivió. La jerarquía existente no.

En programación, en música y ahora en las relaciones, el conflicto es el mismo. Las herramientas que reducen drásticamente los costos de coordinación amenazan identidades construidas alrededor del aislamiento, la lucha y el sufrimiento.

Cuando la gente dice que las interacciones mediadas por IA no tienen alma, no está haciendo una afirmación metafísica. Está describiendo la ausencia de un ritual que valida la autenticidad para ellos. El alma, en este contexto, significa espontaneidad bajo incertidumbre. Significa actuar sin red. Significa no saber qué hacer y hacerlo de todos modos. Para mí, entre otras cosas, significa estar divorciado dos veces a los 51 años.

Quita eso, y para algunos seres humanos la experiencia se siente vacía, incluso si funciona mejor.

Este mismo pánico ya ocurrió antes.

La imprenta desencadenó el mismo tipo de miedo. Información peligrosa. Pérdida de habilidades. Degradación estética. Voces no autorizadas que de pronto sonaban competentes. Las quejas no eran incorrectas en un sentido estrecho. Copiar a mano sí disminuyó. Proliferaron libros malos. La desinformación se propagó más rápido.

Pero el miedo más profundo no era sobre la calidad. Era sobre la legitimidad.

Si cualquiera podía imprimir, ¿cómo sabías quién merecía autoridad? Si la alfabetización se expandía, ¿cómo preservabas el vínculo entre esfuerzo y valor? Si el conocimiento podía adquirirse sin aprendizaje formal, ¿qué pasaba con las identidades construidas alrededor del dominio logrado mediante el sufrimiento?

Ahora imagina un mundo donde esa oposición hubiera ganado. Imprentas fuertemente reguladas. Libros caros y escasos. Alfabetización reservada a una élite. Copiar preservado como un oficio venerado. Cultura protegida del “slop”.

La innovación se desacelera. El poder se concentra. Los guardianes prosperan. La estética del esfuerzo sobrevive. Los beneficios de la coordinación nunca llegan.

Los LLM ocupan el mismo lugar histórico. No son una ruptura. Son la herramienta de coordinación más reciente en una larga cadena. Las lanzas extendieron el alcance. El fuego extendió la digestión. Las bicicletas extendieron la locomoción. Las calculadoras extendieron la aritmética. Los motores de búsqueda extendieron la memoria.

Cada vez, la unidad del valor humano cambió. De la fuerza al objetivo. De la memoria al juicio. De la ejecución a la dirección.

Lo completamente nuevo es que los LLM empujan ese cambio hacia la cognición misma. Pero como padre de hijos de la Generación Z, entiendo por qué no se inmutan. Ya son poliádicos por defecto. Para bien o para mal, crecieron con un iPad en las manos. Su identidad se construyó en red desde el inicio. Su pensamiento se externaliza a través de mensajes de texto con sus amigos. La coordinación no amenaza su coherencia. Al contrario, es cómo la mantienen. Para ellos, usar la mejor herramienta disponible para reducir la ambigüedad no es hacer trampa. Es competencia.

Así que, al final del día, la indignación contra la IA proviene sobre todo de personas cuyo sentido del yo depende de la fricción. Eso no las hace estar equivocadas. Solo hace que este conflicto vaya más allá de cuestiones de política o ética. Porque no vas a convencer a alguien de abandonar una estrategia de mantenimiento identitario citando ganancias de eficiencia.

Lo que sí puedes hacer es nombrar el intercambio con honestidad, y eso fue lo que me inspiró a escribir este ensayo.

Los LLM no eliminan el elemento humano. Eliminan el sufrimiento sancionado por la sociedad. A veces eliminan la necesidad de pedir permiso. Eliminan el trabajo visible en el que algunas personas se apoyan para sentirse reales.

Por otro lado, lo que dejan intacto es la autoría. Espera, escúchame. Incluso usando IA, los humanos siguen eligiendo sus objetivos. Siguen decidiendo qué importa. Siguen aceptando o rechazando el consejo que reciben. Y, lo más importante, siguen cargando con las consecuencias.

Pase lo que pase, el director de orquesta sigue en el podio.

La pregunta abierta no es si la asistencia de la IA funciona. Claramente funciona, en muchos ámbitos. La pregunta es si la humanidad está dispuesta a dejar atrás identidades que requieren confusión, esfuerzo y aislamiento para experimentar significado, sin pensar que eso nos hace menos humanos.

La historia sugiere que sí, eventualmente. No porque las nuevas herramientas sean moralmente superiores, sino porque la coordinación compone y la lucha ritualizada no.

Sísifo puede ser convincente. Pero, al final, el director de orquesta gana.

Why AI feels like cheating to some people

The backlash against AI in the age of large language models is usually framed as a debate about truth, safety, creativity, or jobs. That framing misses the real conflict. What is under attack is not work, or art, or even human relationships. It is a particular way of maintaining a sense of self.

The real divide runs between two models of selfhood. Call them monadic and polyadic.

The monadic self is indivisible. It experiences meaning through isolation, effort, and visible struggle. Work is only real if you can watch yourself doing it. Output matters less than the labor that precedes it. This is the Sisyphus model. I push the stone, therefore I am, endlessly.

The polyadic self works differently. It maintains coherence through coordination. Thinking is externalized by default. Ideas bounce off people, notebooks, tools, systems. The self is not threatened by delegation because authorship lives in direction, not execution. This is the conductor model. I orchestrate, therefore I am.

Neither model is particularly new and have coexisted for a long time. What is new is that LLMs collapse the cost of externalized cognition to near zero. That collapse destabilizes monadic identity in a way that feels outrageously existential, even when the surface arguments sound technical or moral.

You can see this clearly in what seems to be a viral panic about Gen Z using ChatGPT to analyze dating conversations and craft replies.

Objections to the use of ChatGPT in this way tend to be loud and mostly negative. Dystopian. Soulless. Inauthentic. Manipulative. As if something sacred had been violated.

But nothing new is actually happening.

People have always externalized romantic uncertainty with their closest friends and confidantes. They reveal private text messages. They roleplay conversations, especially disagreements. They ask what something meant. In the social media era, they even sometimes crowdsource romantic advice. The difference now is that the coordination layer for externalization is far faster, quieter, and (beneficially, I think) more coherent. The ritualized struggle has been removed.

But for a monadic self, struggle is the point! Romantic uncertainty functions like the Sysyphus stone. If you did not suffer through confusion and risk embarrassment, then the resulting connection feels unearned. Optimization looks like cheating because it bypasses the ordeal that produces meaning. Even if the ordeal could sink all chances of a positive outcome!

Is using ChatGPT to guide relationship behavior any different from following advice from a therapist citing Gottman’s research? If both routes lead to deliberate behavioral modification, why does one feel wrong and the other acceptable?

Functionally, there is no difference. The advice can be identical. The behavior can be identical. The outcomes can be identical.

The difference is ritual. Which is why the same people who recoil at AI-assisted texting think nothing of paying for self-help books or therapy.

A therapist preserves hierarchy. They gatekeep knowledge. They charge money. (A lot of money!) They require scheduling, presence, and social exposure. The advice arrives wrapped in sanctioned-by-society effort. The monadic self survives that kind of externalization intact because suffering, permission, and legitimacy remain part of the process.

An LLM collapses all of that in an instant. No hierarchy. No gatekeeper. No social cost. No visible labor. Just coordination.

That collapse is what feels dystopian to a lot of people.

In a different political moment, this would have triggered a full-blown conservative backlash. Not the culture-war version we have now, but the older instinct to defend hierarchy, friction, and earned authority. If Trumpism had not hollowed out American conservatism and replaced it with grievance and spectacle, I think opposition to AI would look much more ideological and much more organized.

LLMs flatten status structures that used to feel natural. They short-circuit gatekeeping professions. They dissolve the link between effort and legitimacy. That is exactly the kind of thing traditional conservatism once existed to resist.

I’ve been seeing the same split play out in software for the last year, and I live firmly on one side of it.

There is a version of the programmer whose identity is bound up in keystrokes. Code is real if it is typed. Thinking is equated with writing. Assistance feels like contamination. Meaning comes from direct manipulation of symbols, line by line, alone. There must be a correlation with programmers who swear by VIM!

In contrast then there is the programmer who treats development of software as more of a complex system, not just a performance. The work is not the typing. The work is specifying intent, constraints, and taste, then steering the system toward a result. I sense some connection here to those of us that really idealized behavior-driven development approaches, which hinted at a future where the implementation of a system was subordinate to its specification.

When people say AI-mediated interactions lack soul, they are not making a metaphysical claim. They are describing the absence of a ritual that validates authenticity for them.

These days I use agentic tools like Claude Code to generate, refactor, test, and explore. Not just the codebase, but everything on my project including what other people are working on. I only intervene in its work where judgment matters. This does not make me feel less like a programmer. It does make me feel more responsible for the outcome, because I can own more of it.

The topic of AI music makes the same conflict even clearer.

The monadic artist locates authenticity in effort. Suffering is proof. Labor is the signal. Tools become suspect once they cross an invisible line from assistance into authorship.

I make music professionally too, and I’ve leaned hard into AI-assisted generation with Suno this year, especially to manifest my original songwriting. Not because I cannot write or produce without it, but because I care more about results than performing the traditional rituals myself.

This approach is nothing new for me. I have somewhat significant issues with my hearing from decades of loud environments, which means I can’t do a proper mixdown to save my life. So I work with a fine recording engineer to finish my tracks, and there’s no shame in that.

When it comes to Suno, if I could afford to regularly hire world-class singer-songwriters to collaborate with as vocalists and workshop my lyrics with, then of course I would do so with no shame, either.

Like many other modern producers, I treat sound as a malleable material. I use synth presets and sampling liberally. I compose through direction, selection, and iteration, often in conjunction with other more talented artists. I do not confuse my own manual time investment with meaning. Maybe I confuse meaning with meaning.

We have seen this movie before. Sampling. Drum machines. Electronic music. Autotune. Each triggered panic about soul and authenticity. Each time, the art survived. The existing hierarchy loses.

In programming, in music, and now in relationships, the conflict is the same. Tools that collapse coordination costs threaten identities built around isolation, struggle and suffering.

When people say AI-mediated interactions lack soul, they are not making a metaphysical claim. They are describing the absence of a ritual that validates authenticity for them. Soul, in this context, means spontaneity under uncertainty. It means acting without a net. It means not knowing what to do and doing it anyway. For me, amongst other things, it means being twice-divorced at 51 years of age.

Remove that, and for some humans the experience feels hollow even if it works better.

This exact panic has played out before.

The printing press triggered the same shape of fear. Dangerous information. Loss of skill. Aesthetic degradation. Unauthorized voices suddenly sounding competent. The complaints were not wrong in the narrow sense. Copying by hand did decline. Bad books proliferated. Misinformation spread faster.

But the deeper fear was not about quality. It was about legitimacy.

If anyone could print, how would you know who deserved authority. If literacy spread, how would you preserve the link between effort and worth. If knowledge could be accessed without apprenticeship, what happened to the identities built around mastery through suffering.

But imagine a world where that opposition won. Printing tightly licensed. Books expensive and rare. Literacy elite-coded. Copying preserved as a revered craft. Culture protected from slop!

Innovation slows. Power concentrates. Gatekeepers thrive. The aesthetic of effort survives. The benefits of coordination never arrive.

LLMs sit in the same historical slot. They are not a rupture. They are the latest coordination tool in a long line of them. Spears extended reach. Fire extended digestion. Bicycles extended locomotion. Calculators extended arithmetic. Search engines extended memory.

Each time, the unit of human value shifted. From strength to aim. From recall to judgment. From execution to direction.

What’s completely new is that LLMs push that shift into cognition itself. But as a parent to Gen Z kids, I understand why they don’t flinch about it. They are already polyadic by default. For better or worse, they were raised with an iPad in their grubby little hands. Their identity has been networked on the socials from the start. Their thinking is externalized via text messages to their friends. Coordination does not threaten their coherence. On the contrary, it’s how they maintain their coherence. To them, using the best available tool to reduce ambiguity is not cheating. It is competence.

So when it comes down to it, the outrage against AI comes mostly from people whose sense of self depends on friction. Which does not make them wrong. It just makes this conflict run deeper than questions of policy or ethics. Because you ain’t gonna argue someone out of an identity maintenance strategy by citing efficiency gains.

You can however name the tradeoff honestly, which is what inspired me to write this essay.

LLMs do not remove the human element. They remove society-sanctioned suffering. Sometimes they remove the need to ask for permission. They remove the visible labor that some people rely on to feel real.

On the other hand, what they leave untouched is authorship. No wait, hear me out! Even using AI, humans are still choosing their goals. They’re still deciding what matters. They still accept or reject the advice they’re given. And most importanly, they still bear the consequences.

No matter what, the conductor is still on the podium.

The open question is not whether AI assistance works. It clearly does, in many domains. The question is whether humanity is willing to let go of identities that require confusion, effort, and isolation in order to experience meaning. Without thinking it makes us less human.

History suggests that we will, eventually. Not because the new tools are morally superior, but because coordination compounds and ritualized struggle does not.

Sisyphus can be compelling. But ultimately the conductor wins.