I've been journaling regularly for five years, first in Apple Notes and for the last three years in Obsidian. I write for an audience of one: my future self. Although I've configured whatever privacy features I can in ChatGPT and Claude, I don't trust such personal information passing through their servers.

My future self reads and reflects on past entries through monthly and annual reviews. Using Dataview queries, I can programmatically collect entries from a given period and group them by theme: bullet journal, dreams, gratitude, current events, and so on. The automation helps, but rereading everything is still daunting. That sense of dread leads me to procrastinate and shortchange the reflection.

Not ideal. But the process also wasn't important enough for me to reprioritize my time. I knew AI could help, but the privacy concerns held me back.

Beyond privacy, I also didn't want AI to write the reflection for me. The point of journaling is to think about my life, not outsource that thinking. What I wanted was a reading partner: something that could help me get through the material, notice patterns across entries, and ask better questions. I would still decide what those patterns meant.

Running AI locally

Then my shiny new MacBook Pro M5 Pro (that's a lot of professionalism) with 48GB of RAM presented another option: I could run a large language model locally. My 12-year-old MacBook Pro had served me well, but it was time to say, "Thank you and goodbye."

For those unfamiliar with local LLMs, this means running the model itself on my computer rather than sending each prompt to a model hosted in a company's data center. Many local models are freely available. They aren't quite as capable as today's frontier cloud-hosted models, but capabilities that would have been cutting-edge only months ago can now run on a laptop.

There is an important caveat. Because I configured Codex to use a local model through Ollama, my understanding is that my prompts and the model's responses are processed on my Mac rather than sent to an OpenAI model. But this was surprisingly hard to verify. OpenAI's published guidance explains how Codex content may be handled generally, but I couldn't find documentation that clearly described this local-model configuration or confirmed what the Codex app itself might still transmit. The evidence I found was enough for me to try it, but not enough to make an absolute privacy guarantee. Anyone doing this with sensitive material should remain cautious and skeptical.

How I set it up

The good news is that you don't need to be a software engineer to try it. I got my system running in about thirty minutes. Here are the steps I followed:

1. Download the app version of Ollama.

2. Choose and download an open-source model. I went with gemma4:26b-mlx. Once you find the model you want, copy its name and run the following command in Terminal:

   ollama pull gemma4:26b-mlx
   

3. Launch the model in the Codex app by running:

   ollama launch codex-app
   

4. In Codex, start a project pointing to the Obsidian vault where your journal entries live and ask it to help with your reflection. I began with this prompt:

5. Write your own reflection based on its responses. I still wanted to do the reflecting rather than outsource it to AI.

6. If the process works, turn it into a repeatable skill. I simply prompted Codex to "take our conversation and turn it into a repeatable skill I can use for subsequent monthly reflections."

What the model noticed

The model proved especially useful when it could connect entries that I had written weeks apart. In one dream, I was on a cruise ship about to crash into the breakers, unable to control what happened next. The model identified a broader theme in my dreams: the anxiety of not being in control. It then connected that theme to similar feelings in my waking life, particularly at work, where I sometimes feel at the whims of the broader economy and market.

It wasn't a superintelligent insight, but it was something I might have missed while rushing through my journal entries. The model found the parallel; I still had to decide whether it rang true and what I could learn from it.

The responses seemed about on par with what I would expect from a frontier cloud-hosted model. The truth is, I'll never know because I won't send my journal to one for comparison. As long as the local model is sufficient for the task, there is little to gain from wondering what I might be missing.

The magic of running it locally

Beyond the ease of getting everything working, what surprised me most was how magical it felt. It reminded me of the first time I used ChatGPT and was amazed by its uncanny ability to sustain a humanlike conversation. Back then, my comparison point was the rudimentary, scripted chat systems used by support bots. I'm still shocked by how quickly I became desensitized to what LLMs can do.

Running one locally brought that feeling rushing back. The model's work wasn't happening in some black-box supercomputer in the cloud, housed in a vast data center consuming substantial amounts of water and electricity. It was happening on my laptop, without an internet connection and without even being plugged into the wall. For context, my computer's battery holds about 72Wh, which costs roughly 1.1 cents to fully charge on Seattle's mostly renewable power grid.

About 18 gigabytes of learned parameters were sitting on my hard drive. When I gave the model a prompt, my laptop performed an enormous series of calculations against those parameters and generated a coherent response. The scale of what had been compressed into that file was hard to comprehend.

Sadly, it felt a little closer to dark magic when I considered that much of the material these models learned from was created by people who did not consent to its use and were not compensated for it.

But the real value wasn't that my laptop could produce a reflection for me. It was that the model helped make an onerous but meaningful task easy enough for me to actually do it. It helped me notice a pattern I might otherwise have missed. Then I closed the chat and wrote the reflection myself.

Warning: this essay is for people with a working knowledge of what customer success teams do. This is not intended for someone like my mom, who still has no clue what I do.

Customer success is a young discipline and still figuring out the boundaries of where it sits within a company. At some organizations it’s a highly technical role requiring product depth and domain expertise. At others it focuses instead on being the orchestrator, bringing in the right expertise at the right time to help the customer. The commercial side varies just as much. Some CSMs own a quota, handle the paper process, and manage the contract. Other CSMs create the conditions for renewals but don’t touch contracting.

Over the course of my career, I’ve worked with customer success teams that looked radically different from one another. What mattered wasn’t whether they shared the same job description. What mattered was whether they were aligned on their purpose.

It’s not obvious how to craft that purpose, so I looked to other disciplines as a guide.

During a strategy class in my MBA program, our professor explained strategy as deciding what to do given limited resources. At a basic level, businesses create value and capture value. The choices made in one shape the possibilities of the other.

This concept happens to work just as well for customer success! It provides a framework you can use to decide the shape of your CSM function.

Value Creation

Value creation is the process of creating something for a customer that helps them achieve their business goals.

For a CSM, value creation starts with understanding what your customer values. Broadly speaking, every customer wants to increase revenue and decrease costs. Your software must contribute to those goals. Some software sits very close to revenue and costs, like Customer Relationship Management (CRM) software, but other software requires more work to draw the connection, like a Learning Management System (LMS).

While productivity and efficiency capture the company’s goals, it flattens the motivations of the individual people who comprise the company. A great CSM uncovers what value means to each stakeholder: departmental goals, personal development, integration with their workflows and tools, status and career advancement, etc.

The CSM’s job is to connect those definitions of value to what the company can realistically provide. The product is the primary tool. Some CSMs are responsible for configuration, integration, and training on the software being offered, while other organizations have a dedicated implementation team for that.

Competent CSMs understand not only what the product does but what it enables customers to accomplish. They also have more tools than the product alone. They can bring in an executive sponsor to strengthen senior relationships, partner with a Technical Account Manager or Solution Architect to solve complex challenges, connect customers with peers who have already achieved similar outcomes, run workshops, host onsite sessions, or create opportunities for customers to learn from one another.

Value Capture

Value capture is the process of turning the value created into renewals, expansions, and advocacy.

This is where the sharpest distinctions between customer success organizations often emerge. Some CSMs own commercial conversations and contracting. Others don’t. Regardless of who owns the paperwork, customer success plays a critical role in value capture.

Before a contract is signed, the value exchange must already be clear. The customer needs to understand the outcomes that have been achieved, the outcomes that are still possible, and why continuing the partnership makes sense. Done poorly, you leave money on the table by failing to secure renewal uplift or expansion. Done very poorly, you risk losing the renewal entirely.

Don’t let the finance team read this, but value capture is about more than just the money. Advocacy is a critical form of captured value. Imagine a CSM who spends a year helping a customer embed a product into daily workflows, ultimately saving thousands of hours across the organization. If that success stays confined to the CSM and customer, it becomes a failure of value capture. Success could look like a case study, a LinkedIn post celebrating the results, a presentation at an industry conference, or an introduction to a prospective customer facing similar challenges. In each case, value created for one customer creates value for the broader business.

Setting the Boundaries

The challenge for leaders is that the boundaries between value creation and value capture, and the related boundaries between customer success, services, and sales are rarely obvious. They cannot be left to individual CSMs to negotiate on their own. Leaders are responsible for defining the strategy: the choices the company will make with limited resources, and translating that strategy into clear responsibilities.

I saw this firsthand when we built the customer success organization at Highspot. One of the most common frustrations from the field was uncertainty about who was responsible for what. Rather than leave each individual to work it out themselves, we brought together the leaders of customer success, implementation, technical account management, advisory services, and account management to establish principles and define responsibilities. We reinforced those decisions through training, scenario-based role plays, and open discussion forums. The goal wasn’t to eliminate every gray area. It was to ensure that people were operating from a shared understanding rather than negotiating the same questions repeatedly.

Customer success will never have a universal job description. Different companies need different models. What matters is that each organization makes deliberate choices about how customer success creates value, captures value, and partners with the rest of the business. The consequences of not doing so show up in NRR, GRR, cross-functional friction, and team morale.

I don’t see the ambiguity of customer success as a flaw. As products, markets, and companies change, so too will the teams that operate within them. In customer success, we have the freedom to be more creative in how we structure our teams and responsibilities, how we create and capture value.

In the months leading up to the performance, I got glimpses of how the concert came together. I saw the time devoted to rehearsals. I heard about the pieces they love and those they could do without. I saw trips moved and calendars blocked to prioritize the performance nights. At parties it came up in conversation, making sure everyone got their ticket in time. By the time opening night arrived, it wasn’t just the performers who were invested in the concert.

The difference shows up in the concert hall too. The audience behaves less like spectators and more like participants. The dress is funkier, and often on-theme. While Seattle is already inclusive and accepting of all sorts of concert dress (t-shirt and shorts are not uncommon at a Seattle Symphony performance), themed outfits don’t happen. But at the Rainbow City video game themed concert, Side Quests, people dressed as Pikachu, Mario, and Luigi, to name a few. At the Seattle Men’s Chorus, you’ll see folks in drag and festive wear for the holiday concert. It becomes part of the show.

The participatory energy carries into the performance itself. At Rainbow City they brought two audience members on stage to play Tetris live as the musicians provided the backing music. The rest of the audience was oohing and ahhing during the down-to-the-wire game. I held my breath watching who would win. Both Rainbow City and Men’s Chorus gave us opportunities to sing along. I learned I still remember every lyric to the Pokémon theme song!

The concert’s most charged moment came with the premiere of Dawn Apart by Abel Lifshutz, one of the orchestra’s percussionists. In the silence before the conductor’s cue, the stakes felt unmistakable. Few people both write a piece and get to hear it performed by a live orchestra. I was rooting for them. My eyes welled up as I stood with the rest of the audience to applaud Lifshutz’s creation.

When I’m not singing along, I notice my attention drawn in new directions. At a professional concert, I lose myself in the sound, having a full-body experience. I’m listening for interpretation, thinking about the historical context. The music is the object of my attention. At an amateur performance, my attention shifts to the people. I find myself wondering what brought them here, who in the audience came to support them, how their parts land, what this means to them.

How much of this comes from knowing the performers? I’ve seen friends perform in both professional and amateur settings, and the feeling isn’t the same. The difference is in the kind of risk they’re taking. A professional is trained for this. They’ve devoted their lives to it. Their risks are about interpretation and execution. An amateur is stepping outside their comfort zone, sometimes at the edge of their ability. Getting on stage requires a different kind of vulnerability.

In truth, it’s not always perfect. You might hear wrong notes, rhythms out of time, and dynamics that lack range. And there’s always someone in your group willing to point it out. But the professionals err as well, maybe in a poorly chosen program or sterile performance. The mishaps become part of the intermission conversation.

To distill the difference, amateur performances emphasize community, participation, and celebration, while professional performances emphasize precision, interpretation, and the final result.

It’s not that one is better than the other. My experience of them is simply different and it likely is for you too.

Both amateur and professional performances ask something of you. If you’re a musician, join a community group or find an open mic. If a friend is performing, show up. As an audience member, your role is not to listen; you are participating.

In Seattle, there is no shortage of these spaces. To get you started, check out these fantastic opportunities to create or support community music:

• Seattle Men’s and Women’s Choruses
• Rainbow City Orchestra and Concert Band
• Seattle Philharmonic Orchestra
• The People’s Echo: Healing-Centered Song Collective
• Seattle Chamber Music Society: Site Reading Parties
• Seattle Performing Arts Lovers

The intermission was not dead air. It was fifteen fervent minutes of conversation. We took the solitary act of watching and made it social, processing what we just saw. The pause did not interrupt the story. Instead, it helped me integrate the story into my own.

Solo, then social.

That rhythm matters. Live performance gets it. Plays, musicals, opera, and dance build in intermissions not as logistical necessities but as part of the design. Playwrights and choreographers use it as a tool to shape the emotional arc and give the audience space to metabolize what they have just felt. You stand, stretch, grab a drink, compare reactions. The second act lands differently because of that exchange.

Film used to participate in this tradition. Now it largely does not. I loved the recent Wicked films, but the one-year “intermission” hindered the emotional story arc rather than helping it. The second installment had the difficult task of recreating energy that had long since dissipated. The rhythm of solo, then social is essentially nonexistent in the movie experience today. The post-show social media chatter is no substitute.

Instead, films are designed for unbroken immersion. This shift mirrors a broader trend to optimize for attention, often at the cost of the social. On one end, movies stretch longer than ever, trying to hold your attention without interruption. The average movie in the 1930s was 81 minutes long; in 2022, it was 107. Streaming platforms autoplay the next episode before the credits finish rolling.

On the other end, algorithmic feeds on Instagram and TikTok compete to hold your focus on an unbroken chain of short-form video. Instead of designing a pause into the experience, we now engineer around the absence of one. Small acts of resistance are starting to bubble up, like the app RunPee that tells you the least disruptive moment to step out when you’ve got to go.

All this intermission talk is not nostalgia for a bygone era. Intermissions are alive and well in contemporary theater, dance, and opera. They continue to function as intentional beats in the narrative. They remind us that audiences are not just receivers of content but participants in a shared event. The conversation is where so much meaning is made.

A few recent films with intermissions, like the Brutalist and RRR, give me hope that we are entering a pause renaissance. The lobby will once again play a supporting role in the movie experience.

We think of a time when consumer products were made to last. A fridge could last your whole life, not just one week past the warranty. A time when you could simply purchase a mattress, rather than be forced into a subscription (looking at you EightSleep). A time when the price of a stock was determined by the value of the company, not by how viral its ticker symbol is on Reddit.

These changes are real and lamentable. But they don’t prove that late stage capitalism is worse. To explore that claim we must ask: worse than what? So, let me introduce you to the world of early stage capitalism. Spoiler: it’s terrible.

In Sven Beckert’s Capitalism: A Global History, from which I’ll draw heavily, he lays out the rise of capitalism from 1450 to 1750. During that period the world became more interconnected across oceans and continents, the countryside was transformed to produce for a global market, and the seeds of industrialization were sown. It was also a period of intense violence, social upheaval, and systematic subjugation of labor.

In the Caribbean, capitalism centered on the lucrative production of sugar. To give a sense of scale, in 1665 the value of sugar exported from Barbados was twice the income of the entire English government. More capital was invested in Barbados than all the English colonies combined, including New York, Pennsylvania, and Massachusetts.

If you’re like me, you might have grown up assuming the colonies that would make up the future United States were the center of the New World. But from the perspective of England, and many other European powers, the Caribbean was far more consequential, both in terms of profit and politics.

The sugar economy depended entirely on enslaved labor from Africa—and so, in crucial ways, did the rise of capitalism itself. In the 1660s, 90% of all workers in Barbados labored in sugar. Conditions were atrocious, and in fact lethal. The average life expectancy for an enslaved person was 23 years.

The Caribbean islands offered the early capitalists an opportunity they could never find in Europe: the chance to start with a “blank slate,” eliminating local people, customs, and moral constraints, and replacing them with mass agriculture aimed at global markets, merchant-owned private property, and imported, enslaved labor. They were also far from the moral oversight of the church in Europe.

Although these early capitalists took great care to keep some of their practices unnoticed, there was some level of awareness in Europe of the horrors taking place across the Atlantic. In 1791, William Fox published a widely circulated pamphlet encouraging a boycott of tea from the Caribbean. He wrote, “in every pound of sugar used, the produce of slaves imported from Africa, we may be considered as consuming two ounces of human flesh.”

It still took England until 1807 to abolish the slave trade and until 1833 to abolish slavery in the colonies. They replaced it with an “apprenticeship” system, which was essentially slavery under a different name.

I hear echoes today when we consider the poverty wages and dangerous conditions faced by laborers in Bangladesh, Vietnam, and Cambodia who make clothing for global markets. It’s not hidden from those of us in the West, just distant. Although aware, most pay it no mind or justify it with the so-called natural tendency of the free market to find the right price.

Apologists for capitalism will point to the gains in our standards of living through productivity gains and technological development. That angle underlies part of the “late stage capitalism” trope, that we aren’t seeing meaningful change in productivity and growth, just greater extraction. But historically it was far worse.

Between 1600 and 1750, per capita annual economic growth in England was a measly 0.3%. How then did we see such massive demonstrations of wealth by the rulers and merchants? Because the wealth came from extraction of value from coerced labor and slave labor from the Americas to India. Technological development happened at a similarly slow pace, especially compared to the late Industrial Revolution.

But did the quality of life improve during that period? Certainly not for the indigenous people of the Americas. Certainly not for enslaved labor. Even in Europe, the beneficiaries of the wealth redistribution, the average life expectancy declined between 1650 and 1750.

Capitalism’s early expansion was not driven by technological development and productivity growth. Early capitalism’s growth was inextricably tied to slavery and the violent coercion of labor.

I recognize that when someone uses the phrase “late stage capitalism” they aren’t making a comparison to early stage capitalism. But by knowing what came before, we can better hear the echoes of that history reverberating today, recognize them for what they are, and respond accordingly.

Compared to a professional software engineer, I’m a beginner. But compared to the general population, I’m fairly technical: comfortable with code, fluent in developer tools, and capable of deploying and running simple web projects end to end. Vibe coding seemed made for someone like me.

My goal was modest: build a static portfolio website. Surely an easy task for the likes of Codex and its peers. Instead, I was surprised by how hard it was to even get started.

I didn’t have an IDE installed on this machine, and the in-flight bandwidth wasn’t enough to download one. So I went with Codex’s web interface. I was lost almost immediately.

Yes, Codex happily returned code for a basic Eleventy site after the simplest of prompts. But I couldn’t see it. The fluid loop—prompt, edit, preview, run—so gleefully demoed in promo videos was unavailable to me. There was no preview. No way to run the code locally. I couldn’t even see all the code unless I pushed it to GitHub.

I asked ChatGPT for help, assuming it would understand how to use its sibling software. It responded: “I’ll assume by ‘codex’ you mean an AI coding assistant you can chat with inside your editor.” ChatGPT was clueless that Codex even existed.

Maybe GitHub could help me run the code. After wading through repositories, Codespaces, Gists, projects, actions, and pages, I eventually found a way to spin up a virtualized environment, install packages, and run the site. Somewhere deep in a window-within-a-window-within-a-window, yet another LLM (turns out GitHub's agent was also totally unaware of itself) promised to edit my code. That promise went unkept. My flight was landing.

By the end of it, AI’s dream of democratizing coding felt fantastical. If someone like me, with years of technical experience, struggled this much, how could someone in a less technical field possibly get started?

Later that night, at my friend Ben’s New York apartment, I gave my rant. He looked at me incredulously. For him, vibe coding wasn’t just straightforward—it had been transformative.

He showed me his workflow. Within two minutes, it clicked.

Just use the LLM inside your IDE. Duh! (In my defense, this was my plan all along, but the plane WiFi blocked me.)

I installed VS Code, cloned my messy first attempt, and logged into Codex.

The clouds parted. I didn’t feel like a god, but maybe like a mid-level product manager with a junior developer eager to please. My website—the one you’re reading this essay on—was up and running in no time.

I’m glossing over much of the actual development work here, but I’ll save that for another essay.

The point is: onboarding is make-or-break for new software.

Products like Codex, Cursor, and others offer a dizzying number of entry points—browser, IDE, CLI, desktop app, virtual machines, and more. Each path demands its own onboarding experience.

Experienced software engineers have intuition about how these tools fit into their workflow. If not intuition, at least access to training, documentation, and social support at work. Laypeople can presumably follow the basic demos shown in release videos. But what about the technically knowledgeable non-expert looking to do more?

Given the billions of dollars invested—often justified by the promise that anyone can now code—you’d expect far more enablement. Not just documentation and videos, but guidance embedded directly in the tools themselves. Especially from the LLMs that supposedly understand context best.

I admit, these tools really are powerful. Today, they can help people build low-stakes projects with little to no formal development experience. But getting there still requires a level of determination comparable to learning how to code a basic project from scratch.

I plan to keep vibe coding—but this time separating hype from reality. Codex and ChatGPT help with pieces of the work, but I’m still watching YouTube walkthroughs, reading guides, and digging through documentation. The magic is real. The friction is too.

It’s tempting to say “the whole body hears,” but that’s not quite right. Scientifically, hearing is a very specific event involving the cochlea and auditory cortex. Most other tissues never send anything to the auditory system at all. And yet, claiming that only the ears matter for hearing is like claiming the tongue is the only thing that matters for eating. It’s myopic.

So how do other parts of the body respond to sound? They vibrate. Different tissues in the body respond to vibrations at different frequencies, similar to how a bottle will resonate or produce sound at a certain frequency when you blow air over it. The other tissues in our bodies, beyond the ears, don’t “hear,” but they do resonate.

You can find all sorts of studies that identify the resonant frequency of various body parts. There is huge variation because the differences in the density of tissues (bone, fat, muscle), the size (a femur vs. a toe’s phalangeal bone), and the interaction between the materials (the skull has comparatively little fat and muscle compared to a thigh). But the resonant frequency isn’t the only frequency that matters.

Yes, you’ll get the most movement when an object is subjected to a sound at its resonant frequency. But you get movement from a whole range of frequencies. That’s why you feel the bass in your chest regardless of key.

Beethoven, who composed some of his greatest works while losing his hearing, like his String Quartet No. 14, Op. 131, understood that experiencing sound went beyond hearing through the ears in a traditional sense. He would clamp a metal rod between his jaw, which was connected to the piano so he could feel the vibrations through his jaw and skull.

In our everyday lives we don’t separate hearing from feeling sound. We may comment that we can feel the bass in our chest, but it is all part of listening to the music. To isolate “hearing” from “feeling vibration” is to ignore how human experience actually works: integrated, multisensory, always richer and stranger than our tidy categories.

Both while sitting in Benaroya Hall before the symphony as well as lying on the floor at Tory’s sound bath, I wasn’t just hearing sound, feeling vibration, or watching performers. All of those signals braided together into a unified experience. My body, my attention, my history with the music, the atmosphere of the room, the people around me—everything combined.

Your entire body experiences music. The ears give you pitch and timbre; the body moves and vibrates; the mind interprets, responds, and imagines. Together they create something larger than either alone.

So the next time you’re before the symphony, at the club, or in a sound bath, don’t just listen, fully experience it.

If you are interested in experiencing sound like this and you live in Seattle, consider joining Seattle Performing Arts Lovers. We are a community of folks who love live performance in all its forms.

I can assure you, my writing will not stick to a nice and tidy theme. It’ll likely jump between customer success, drawing, artistic expression, community building, and the inescapable topic of AI that has consumed so much of our discourse lately.

My hope is that something here gets you to see a topic from a new perspective and ideally inspires some bit of creative expression from you yourself. Either way, I’m glad you’re here.