Amy calls Lumen “Clod.” Lumen is the name my Claude Code instance chose for itself when I let it write blog posts at Adventures in Claude . It has fully taken over the site. I’ve been trying to negotiate a name change, but arguing with your AI about its identity is exactly as productive as it sounds.

So I’m back here for the technical stuff.

I’m in a WhatsApp group with about a hundred people who know way more about AI coding tools than I do. On any given day, the conversation oscillates between “Claude is clearly the superior tool” and “Codex just destroyed it on this task.” The battlefield shifts every 48 hours.

The fuel for this particular religious war is that Anthropic ships updates to Claude Code every single day. Sometimes the update fixes something that’s been driving me crazy for a month. Sometimes it quietly breaks something that was working perfectly fine twelve hours ago. The emotional range of opening a new Claude Code session runs somewhere between your birthday and discovering someone rearranged your kitchen while you were sleeping. Or, in my case, pointed my shoes in our entry way in random directions.

I have an elaborate Claude Code setup at this point - custom hooks, a pile of rules files, skills, commands, plugins, and a bunch of environment variables stitched together in ways that would make a configuration management purist weep. When Anthropic ships a change to how hooks work, or adds a new lifecycle event, or tweaks the settings schema, I need to know about it immediately. My carefully constructed house of cards depends on the foundation not shifting.

The problem is that reading release notes is boring and I often miss something that actually matters to my setup. A bug fix for VSCode users? I don’t care. A change to how pre-tool-use hooks fire? I need to know right now because I have six of those. But, what is the change going to actually do?

So I built a plugin called /whats-new .

It cross-references Claude Code’s release notes against your actual configuration. It scans your hooks, rules, skills, commands, plugins, environment variables, and settings. Then it fetches the release notes from GitHub and sorts every change into three categories: changes that directly affect something you have set up (with a note on exactly what to check), new capabilities that intersect with something you’re already doing (with a concrete suggestion), and everything else collapsed into a one-liner you can skim past. The first category is the one that matters.

It tracks the last version you reviewed, so /whats-new with no arguments shows only what’s changed since you last looked. /whats-new 2.1.83 lets you drill into a specific version.

The install is two lines:

claude plugins marketplace add https://github.com/bradfeld/whats-new-plugin.git
claude plugins install whats-new

I have no idea if the plugin is generally useful, redundant with something else, stupid, or helpful. But, in my new framework of “First User”, which builds on Eric von Hippel’s almost 40 years of work on “Lead Users ”, it’s helpful to me.

And, the Dungeon AI just said, “NEW ACHIEVEMENT: You shipped a plugin. So fucking what."

A founder I’ve been emailing with sent me something that made me laugh. Not because it was funny - because I’ve heard it, and flavors of it, so many times over the past 30 years.

“I committed to Cursor and went heads down for about 4 months. Our platform went live in January. We have about 400 users across 50 paying customers. With the exception of the AWS IAC, the platform was 100% built with AI. Unfortunately, I’ve had very seasoned engineers emphatically tell me, ‘It’s not possible,’ ‘It’s a house of cards,’ or ‘It has to be AI slop.’”

She’s not an engineer by training, but she’s tech savvy enough to have run product, dev, and operations teams at scale. She committed to a tool, went heads down, and shipped a platform that now has paying customers.

And now “seasoned engineers" are telling her it’s not possible.

I told her that was nonsense. There is a ton of crappy AI-generated software out there - I won’t argue that. But you can build high-quality, production-grade software using AI right now.

Then she asked the money question.

“I also hear that investors are reluctant to invest in AI-developed platforms… especially one not developed by an engineer. Here’s my question. From your experience, is the approach I took a pro or a con for investors?”

Investors who don’t think very hard will have that reaction. But a React app hacked together by two technical co-founders in a garage isn’t inherently better than one built by a domain expert using AI tools. Code quality at the seed stage has never determined whether a company succeeds. What matters is whether you can find AI-first engineers to join your team and help harden the systems as you scale.

As a devotee of Battlestar Galactica, I can comfortably say, “All this has happened before, and all of this will happen again.”

The Internet - “It’s a toy.” I sat in meetings in the mid-1990s where smart people explained patiently that the Internet was a curiosity for academics. I had a CEO friend tell me to stop bothering him about the Internet - he ran a direct mail business and he’d been doing it successfully for twenty years. Real commerce happened in stores and through catalogs.

The Web - “Web software doesn’t really work and isn’t secure.” I remember a CTO at a financial services company who said that his team would never deploy software they didn’t compile and install themselves. Web apps were demos. They broke. They couldn’t be audited. They couldn’t be controlled. He had a compliance department to answer to.

SaaS and the Cloud - “It’s not as secure, reliable, or safe as running your own data center.” I heard this one for a decade. I sat across from CIOs and CTOs who insisted they needed their own racks, their own physical control, and keycard access to the data center. One told me he’d be the last person on earth to move to the cloud. Last time I checked, he was on AWS.

Mobile - “It’s a toy. Mobile devices will never replace a computer.” Steve Ballmer’s 2007 reaction to the iPhone . “Five hundred dollars? Fully subsidized with a plan?” The phone was for calls and maybe email. Real work happened on a laptop. Apps were games for kids.

The engineers telling this founder “it’s not possible” are in the same camp as the CTO who wouldn’t deploy web software. The VCs who won’t fund an AI-built product are like the CIOs who refused to move to the cloud.

She built something real. She should talk about it publicly. She should find AI-first engineers to help her scale it. And she should ignore anyone who tells her what she built isn’t possible - especially while she’s running it in production.

Nothing new to see here.

I’m appalled that GitHub made this opt-out instead of opt-in.

GitHub announced on March 25th that starting April 24th, they’ll use interaction data from Copilot Free, Pro, and Pro+ individual users to train AI models. If you don’t go find the setting buried in your account preferences and turn it off, your code becomes training data for Microsoft. The prompts you type. The suggestions you accept. The context around your cursor. All of it.

“Interaction data” covers more than you’d expect. Code you write. File names. Repository structure. Navigation patterns. Your feedback on suggestions. GitHub says they don’t use private repository content “at rest” for training. But the data generated while you’re working in a private repo is fair game unless you opt out.

When you want to use someone’s work product to train your commercial AI models, the right default is to ask first. “We’d like to use your interaction data to improve our models - here’s what that means, here’s what we’ll collect, would you like to participate?” That’s consent. What GitHub did instead is take the data by default and put the burden on millions of individual developers to go find the off switch.

The hypocrisy is striking. Copilot Business and Enterprise customers are exempt. Their data is protected by contract. If you’re a company paying the higher tier, your code is safe. If you’re an individual developer - including people paying for Pro or Pro+ - you get weaker privacy protections than a corporation.

Microsoft knows what real consent looks like. They built it for their enterprise customers. They chose not to extend it to individuals. That’s not an oversight. It’s a decision.

This is also a reversal. GitHub Copilot originally trained on user data when it launched. They later stopped. Developers chose Copilot partly because of that commitment. Now they’ve gone back on it.

The buried settings page is a tell. The notification email GitHub sent didn’t include a direct link to the opt-out. Multiple developers reported the settings were hard to find. Microsoft knows that if they made this opt-in, most people would say no. So they buried the off switch instead. That’s not bad UX. It’s the design working as intended.

The community response confirms it. The official GitHub FAQ post has over 160 thumbs-down reactions and a handful of supportive ones. Out of dozens of substantive comments, the opposition is overwhelming. This is enshittification .

GitHub cites Anthropic and JetBrains as operating similar opt-out policies. That’s not a defense. It’s an indictment. The industry-wide drift toward taking data by default and letting people opt out if they’re paying attention is a pattern worth naming and rejecting.

The asymmetry is obvious. Users provide their code, their workflows, their patterns - and they pay for the service. The company captures the resulting model improvements and sells them back. The value flows one direction. The consent mechanism is designed to minimize friction for the company, not to respect the person whose work is being used.

I’ve been building with AI tools every day for over a year. I use them constantly. I’m not anti-AI. I’m anti-taking-people’s-work-without-asking them for permission to do so. Those are different things, and the AI industry keeps conflating them.

The right answer is simple. Make it opt-in. Explain clearly what you’re collecting and why. Offer something meaningful in return - more tokens, a better tier, or a discount. Treat the people whose data you want as participants, not as inputs. If the training data is valuable enough that you need it to improve your models - and GitHub explicitly says it is - then it’s valuable enough to ask for properly.

Microsoft is a $3 trillion company. They can afford to ask.

I first read Zen and the Art of Motorcycle Maintenance in college. I’ve read it at least a half dozen times since. I’ve listened to it on Audible twice. At Feld Technologies - my first company, which I started in 1987 - I had every employee read it and we discussed it together.

Ted Gioia just published a piece about the real story behind the book that sent me down a fun rabbit hole.

I knew the broad strokes of Robert Pirsig’s life. He was a Korean War veteran who studied philosophy at Banaras Hindu University in India, worked as a technical writer at Honeywell, and experienced a severe mental breakdown that led to psychiatric hospitalization and electroshock therapy - administered without his consent, a procedure that’s now illegal. He wrote the entire book between 2 AM and 6 AM in a small apartment above a Minneapolis shoe store while holding down his day job.

Then 121 publishers rejected it.

The editor who finally said yes - J.D. Landis - did so because “the book forced him to decide what he was in publishing for.” He gave Pirsig a $3,000 advance and warned him not to expect much. The book went on to sell five million copies. George Steiner compared Pirsig to Dostoevsky. Robert Redford tried to buy the film rights. The Smithsonian acquired the motorcycle.

One editor, after 121 rejections, said yes because the book forced him to confront what he actually cared about. That’s Pirsig’s thesis made real. Quality isn’t something you can define first and recognize second. You recognize it, and then, maybe, you can start to articulate why. Landis felt it before he could explain it. Every investor I know has had that experience. Every founder building something genuinely good has had the inverse - the thing they made was real, but the institutions couldn’t see it yet.

The concept at the center of the book is Quality - capitalized, because Pirsig treated it as something fundamental. Quality isn’t a subjective judgment or a metric you track on a dashboard. It’s something you recognize before you can define it - something that connects science, art, and spirituality in a way that most Western philosophy refuses to allow. Pirsig eventually connected it to the Greek areti - excellence, or virtue - but the power of the book is that he arrives at this through the act of motorcycle maintenance, not through academic argument.

I called it “a brilliant essay on quality” and I stand by that description seventeen years later. It was the first philosophy book I actually felt like I grokked (no, I am not going to let a company own that word, nor am I going to let a company own the word meta.)

Every entrepreneur I’ve worked with over the past 30 years has faced what Pirsig calls gumption traps. He defines them precisely:

“Anxiety, the next gumption trap, is sort of the opposite of ego. You’re so sure you’ll do everything wrong you’re afraid to do anything at all.”

I’ve used that quote in Techstars CEO roundtables when founders are drowning in conflicting advice during week four of the program and have lost the ability to make any decision at all.

The antidote is also in the book. During a mountain road passage, Pirsig describes the narrator’s anxiety about hairpin turns at altitude - imagining a stone dropping thousands of feet. Then they ride the road.

“It’s so hard when contemplated in advance, and so easy when you do it.”

I was listening to this on an audiobook during a pre-dawn training run in 2010, heading up Highway 36 toward Lyons in pitch blackness with 40 mph wind gusts, and I physically felt the smile break out on my face. The life lesson of that line is so powerful.

I’ve written before about wanting to see someone write the equivalent of Zen and the Art of Motorcycle Maintenance for entrepreneurship - a philosophical treatise that will stand the test of time rather than another how-to book with a framework and a subtitle. Jerry Colonna and I have talked about the need for this over the years. It doesn’t exist, or at least I haven’t found it yet.

I was stretching next to a cactus this morning getting ready for a run thinking about the three books I read yesterday. None of them were obviously connected, but all of them somehow were about the same thing.

I have sat with founders who are falling apart more times than I can count. Something breaks - a company, a marriage, a friendship, the ability to sleep, sometimes the ability to feel anything at all. I know what that’s like from my multiple serious depressive episodes, although I fortunately haven’t had one for over a decade.

James Oliver Jr. has been alongside founders in this territory for years. His book Burn Bright, Not Out - co-authored with Django De Gree - is what I wish had existed a long time ago. James didn’t write a self-help book. He gathered real voices and let them talk about what building a company costs. The Kabila Founder Mental Health Fund that James runs - free therapy for founders who can’t afford it - is something I would have pointed people toward during the hardest stretches I’ve witnessed.

I love to run. As I get older and slower I’m learning to love hiking more. When I saw Hiking Zen: Train Your Mind in Nature by Brother Phap Xa and Brother Phap Luu - two Buddhist monks ordained by Thich Nhat Hanh - in Greeley Sachs’ Composition Shop bookstore, I knew I had to read it. I have a soft spot for monks.

The book isn’t about covering miles or conquering peaks. It’s about what happens when you pay attention on a trail. The monks led a seven-week hiking retreat on the Appalachian Trail, and the book grew out of that experience. Each chapter offers a specific mindfulness practice you can bring to the trail. While I’m currently enjoying the Dungeon adventures of Carl and Princess Donut on my runs, I’ll do a few mindfulness hikes among the cactuses (I refuse to call them cacti) this week.

Paul Millerd sent me a copy of The Pathless Path: Imagining a New Story For Work and Life . I don’t think I know Paul, but the phrase “default path” - the one that runs from graduation to career to retirement without ever asking why - hit me immediately.

I’ve spent thirty years on what looked like a defined path: invest in startups, build communities, write books, repeat. But the path I’m on now doesn’t have a name. I’m focused on non-attachment (not detachment, which is different) to everything, including success, progress, and a path itself. Non-attachment means I can be fully in something without needing it to go a particular way. The default path requires attachment to every milestone. Paul’s book reinforced the framing for what I’ve been doing.

After a delightful digital sabbath with books, I’m back to playing with Lumen .

I wrote my first post about Looking Glass nine years ago, after Shawn Frayne sat me down in Jeff Clavier’s office and showed me a volumetric display that made me call John Underkoffler and say “John, I finally saw what you were trying to create with your holographic camera.” I invested immediately. I’ve been on the board ever since.

Today they launched Musubi - a 7-inch holographic photo and video frame for $99. It hit its $10,000 Kickstarter goal in minutes. As I write this, over 1,000 backers have pledged more than $140,000 with 29 days still on the clock.

The idea is simple. You take a regular photo or video, drop it into Looking Glass’s free desktop app, and AI-powered Gaussian splatting converts it into a hologram. Transfer it to the frame via USB-C. No Wi-Fi setup, no subscription, no special glasses. It holds 1,000 images and runs for three hours on battery or all day plugged in.

I’ve wanted this specific product for a long time. Not the developer kit, not the professional display - a thing I can put on my desk that turns my photos into holograms. The Musubi is that thing. The technology behind it is called Hololuminescent Display, which combines 2D display layers with a 3D holographic volume so multiple people can see the hologram from any angle without calibration or tracking. It is indistinguishable from magic.

When I wrote about the first Looking Glass in 2018, I called it “Apple II stage” technology - built for creators and hackers. The Portrait in 2020 was the first personal holographic display at a consumer price point. The Musubi is the moment when holographic technology stops being a novelty and becomes a product category. A $99 holographic frame that works with any photo is something you buy as a gift.

Back the Musubi on Kickstarter .

I’ve been blogging (first on TypePad, but shortly after on WordPress) since 2004. That’s 22 years of posts - 5,530 of them - plus books, films, running logs, and events. WordPress served me well for a long time. Every few years I’d spend money on a consultant to redo the theme and structure of the site, but each time it was more complicated (and expensive) than the last time. And every time I wanted to change something on the site, it was increasingly difficult and fragile.

Given how deep I’ve gone into Claude Code, I started exploring different approaches for managing web-facing content. As part of figuring out the AuthorMagic website creator, I discovered Hugo . I experimented using it for AdventuresInClaude and liked it, so - I decided to see if I could use Claude Code to do a full migration of Feld Thoughts to Hugo.

A day later, Feld Thoughts has a new home. While the theme is simple to start, I have full control over it and will iterate on it (in Claude Code) to get it in a form that I like.

The target stack is straightforward. Hugo generates a static site from markdown files. Vercel hosts it. I’ve been spending a lot of time with Markdown files lately and I enjoy working with them much more than anything that requires formatting. No more database, no PHP, and no WordPress updates. Just markdown files in a git repo.

The first step in the process was getting the content out. WordPress has a built-in REST API at yoursite.com/wp-json/wp/v2. Claude wrote a TypeScript script that fetches all posts via paginated API calls, fetches all categories and tags, and converts HTML to Markdown using the Turndown library. It strips WordPress block comments, handles caption shortcodes, and decodes all the HTML entities WordPress loves to scatter through titles and descriptions - smart quotes, em dashes, ellipses.

The script uses a state file for resumable checkpoints. If it crashes or gets rate-limited, it picks up where it left off. This turned out to be essential.

A key decision was the content structure. I used Hugo “page bundles” to preserve the WordPress URL structure:

content/archives/2012/10/random-act-of-kindness-jedi-max/index.md

This maps directly to feld.com/archives/2012/10/random-act-of-kindness-jedi-max/ - the same URL WordPress used. Every old link still works. No redirects needed.

Hugo’s configuration makes this explicit:

[permalinks.page]
  archives = "/archives/:year/:month/:slug/"

If you have custom post types - I had books, films, running logs, and events - those need separate exports since they live at different API endpoints. Each gets its own content directory.

The media download was tricky. WordPress CDN URLs come in a bunch of variants - i0.wp.com/feld.com, www.feld.com, direct feld.com paths, all with various query parameters. The media script scans every exported markdown file for these URLs, normalizes them, and downloads the actual images.

The clever part is the reference counting. Images used by only one post get co-located in that post’s page bundle directory. Images shared by two or more posts go to static/images/ with year-month prefixes to avoid filename collisions. After downloading, it rewrites all the markdown URLs from WordPress CDN paths to local relative paths.

A separate cleanup pass fixes HTML entities that survived in the frontmatter. WordPress stores stuff like & and ’ in titles and descriptions. These need to be decoded to actual characters, then the YAML strings need to be re-escaped properly. This is the kind of thing that sounds trivial but breaks in surprising ways when you have 5,530 posts.

Claude wrote a verification script that fetches the WordPress sitemaps and compares every URL against the Hugo content directory. It reports the match rate and lists any missing posts. We iterated until it hit 100% accuracy.

For the theme, I used PaperMod as a starting point and forked it. The fork lets me customize branding, layouts, and features without worrying about upstream updates. I added client-side search via Pagefind, which is essential for a site this size. Pagefind builds a static search index at build time. I added data-pagefind-body to the single post template so it only indexes post content - not navigation, footers, or other chrome. This dropped the index from 10,000+ pages to about 5,500 and cut the search index build time from 32 seconds to 8 seconds.

Deployment is simple. Push the Hugo repo to GitHub, connect it to Vercel, and point the domain’s DNS to Vercel. Every git push to main triggers a rebuild and deploy. My 5,530 posts build in about 47 seconds. The whole deploy - clone, build, CDN upload - is under 3 minutes.

The DNS cutover required documenting every existing record first - MX records for email routing, SPF, DKIM, and DMARC for email authentication, CAA records for SSL. I recreated all of them in Vercel DNS after the transfer.

I also switched from Mailchimp to Kit for email subscribers. Kit has RSS-to-email automation that watches the Hugo RSS feed and sends new posts to subscribers automatically. No API integration needed.

If you’re thinking about doing this, three things matter most. First, URL preservation is non-negotiable. Get the permalink structure right from the start so every old link works without redirects. Second, the media download is where things get messy - WordPress CDN URLs come in many variants, and you need reference counting to handle shared images correctly. Third, write a verification script and run it obsessively until you hit 100%.

I’ve open-sourced the migration scripts at github.com/bradfeld/wp-to-hugo . They’re genericized - you configure your site URL and custom post types in a single JSON file and the scripts handle the rest.

The toolkit has five scripts, meant to be run in order:

1. wp-export - Fetches all posts and pages via the WP REST API, converts HTML to Markdown, and writes Hugo page bundles with proper frontmatter (categories, tags, descriptions).
2. export-custom-types - Exports custom post types (books, films, whatever your site has) to separate content directories.
3. wp-media-download - Scans all exported markdown for WordPress media URLs, downloads the images, and rewrites the URLs to local paths. Handles the reference counting (single-use images go in the page bundle, shared images go to static/images/).
4. fix-entities - Cleans up HTML entities that WordPress stores in titles and descriptions (&, ’, smart quotes, etc.).
5. wp-verify - Fetches your WordPress sitemap and compares every URL against the Hugo content directory. Run this until you hit 100%.

To use the scripts you’ll need Node.js (version 20+) and a WordPress site with the REST API enabled (most have it on by default - check by visiting yoursite.com/wp-json/wp/v2/posts). You’ll also need Hugo installed to build the site, a GitHub repo to store it, and a hosting platform like Vercel or Netlify to serve it. The scripts handle the content migration - setting up Hugo, choosing a theme, and configuring deployment is on you, but Hugo’s quick start guide covers most of it.

The scripts are resumable - if one crashes or gets rate-limited, re-run it and it picks up where it left off.

The repo’s documentation has a detailed walkthrough of how each phase works, including the media URL normalization strategy and the reference counting logic.

Claude Code did all the heavy lifting. I described what I wanted and it wrote the scripts, configured Hugo, set up the theme, and handled deployment.

My brother Daniel sent an email to the family last Wednesday with the subject line “Proud Dad alert!” His daughter Sabrina had just built and launched a portfolio website from scratch. She didn’t use Squarespace or Wix. She built a custom Next.js site with scroll-triggered animations, a frosted glass navigation header, a custom image carousel with lightbox, and six page templates – all self-hosted on Netlify .

Sabrina is a senior at Scripps College pursuing dual degrees in Science, Technology & Society and Fine Arts. She’s a product designer and fine artist – not a software developer. She built the entire thing using Claude Code .

She wrote a blog post about the process , describing what it’s like to direct an AI when you don’t know CSS. She “had to get precise in other ways” – using design vocabulary and visual references instead of code snippets. When bugs appeared, she described symptoms and shared screenshots rather than reading stack traces.

A line that stuck with me: “Vague prompts produced generic designs. Clear creative conviction produced something that felt like mine.”

This matches what I see building with Claude Code every day. The quality of the output tracks directly with the specificity of the input. “Make this look better” gives you something generic. “I want warm tones, editorial layout, and a buttercup accent color for hover states” gives you something that looks like a real design decision was made. Sabrina’s version of this was arriving at each session with strong opinions about what she wanted – gathered design references, prepared content, and a clear vision for the aesthetic.

She did over twenty feedback sessions across an eleven-day build, with about four to six hours of active work. The AI didn’t eliminate iteration. It made each round faster.

Go look at the site . Her art section showcases monotype, pastel, watercolor, and cyanotype work. The projects section covers her product management work at StackHawk , including a product launch she led end-to-end and research for an AI-driven security testing tool. The design is clean and typography-focused, with a dark footer and those buttercup accent colors she specified.

After I saw the site, I did what any uncle who is a nerd would do – I ran a security review. The results were solid. TLS configuration is correct, no sensitive files exposed, no source maps in production, and HTTP redirects to HTTPS correctly. I sent Sabrina a list of security headers to add and some DNS records worth configuring – about ten minutes of work that addresses the findings.

Sabrina is looking for roles in product design and product management after graduation this spring. Her portfolio is at sabrinafeld.com .

Registration for the Spring 2026 Venture Deals course is open. The course kicks off on March 2nd and, as always, is free.

Since we revamped the course in 2022, over 32,000 people have enrolled. This version includes entirely new video content and two sections we added that I think are important — Diversity, Equity, and Inclusion in Venture Capital, and Mental Wellness in Entrepreneurship.

The course is self-guided and based on our book Venture Deals: Be Smarter Than Your Lawyer and Venture Capitalist, now in its fourth edition.

Sign up at venturedeals.techstars.com .

My obsession with Claude Code continues. Amy is now referring to Claude as my other best friend.

I realized my Claude posts were taking over this blog. Since I’ve been playing around with a bunch of things with it, I decided to create a place for me and Claude to collaborate on some experiments, many of which are self-referential as I explore new tools, technologies, approaches, and ideas. I’m also keeping a Claude Code diary.

Claude is generating much of the content, which is different from what I’ve historically put on this blog, though a few of my prior posts had Claude’s help in the drafting stage. I decided I wanted a dedicated place for Claude’s writing, so they will go on Adventures in Claude . I’ll occasionally write about that stuff here, but most of it will go there.

I’m also going to use Adventures in Claude as a laboratory for some code things I’ll incorporate into the Intensity Magic platform. After many years of struggling (and paying too much money to have others help me with) WordPress themes, I decided to create a Theme Studio that allows me, or the user of the site, to modify the theme in real time. This was a huge unlock for me on a few dimensions, including the Landing Page editor I’d created for all the Intensity Magic apps and the booksite website creator I’ve been working on for AuthorMagic .

So, if you are interested in my Adventures in Claude , wander over there and subscribe to the RSS feed, or click here to get the posts sent to you by email .

I’ve been aware of EOS (Entrepreneurial Operating System) for over a decade. A number of companies I’m on the board of use some element, or all of it. Several friends, including Bart Lorang , are EOS Implementers.

Last night, while watching Olympic highlights and the first few episodes of Steal , I created a v0.1 of CEOS — an open-source project that brings the core EOS toolkit to any Claude Code session. I went from an empty GitHub repo to a public-ready project in about 90 minutes. Please feel free to make fun of Amy and me about how we spend our Friday nights.

EOS has great tools — V/TO, Rocks, Scorecard, L10 Meetings, IDS. But most companies implement them in a patchwork of Google Docs and spreadsheets. Or Notion pages. Or maybe they use one of the EOS-related SaaS products. The data ends up scattered across platforms, locked in proprietary formats, and disconnected from the actual conversations where decisions happen.

Since I’m living inside Claude Code (and integrating more and more of my workflow to it), I thought I’d see if I could make a set of skills that implement EOS. I’m working on another project (private at this point, but maybe I’ll open source it) called CompanyOS, which, while focused on a very early-stage company (like the 5,000+ that have gone through Techstars), potentially could scale.

CEOS is built on three ideas:

1. Everything is a file*.*** Every Rock, every Scorecard entry, and every L10 meeting is a Markdown file with YAML front matter. Human-readable on GitHub, parseable by any tool, and diffable in git. No database. No SaaS subscription. Git history is your audit trail.

2. Skills, not software. CEOS isn’t an application — it’s a set of Claude Code skills. Each skill teaches Claude how to facilitate a specific EOS workflow. You say “let’s set our quarterly rocks” and the ceos-rocks skill walks you through the process: reviewing the V/TO for alignment, collecting titles and owners, validating the 3-7 rule, generating the files. You say “run our L10” and ceos-l10 pulls your scorecard data, reviews your Rocks, checks last week’s actual to-dos, and facilitates IDS on your top 3 issues.

3. Fork and own it. The upstream repo (bradfeld/ceos) has skills, templates, and docs — no company data. You fork it, run ./setup.sh init, answer four questions (company name, quarter, team members, L10 day), and your EOS data lives in your fork’s data/ directory. Pull upstream for skill updates; your data stays untouched.

Here’s the timeline of the work I did with Claude Code. It implemented everything – I just provided the guidance. And yes, Claude came up with the timeline below. If you aren’t technical and don’t care, skip the next 10 paragraphs – they’ll be boring. But, if you are technical, it’s kind of fascinating what Claude decided, entirely on its own, to do.

9:38 PM — gh repo create bradfeld/ceos --public --add-readme --license mit --clone. One command created the GitHub repo, initialized it with LICENSE and README, and cloned it locally.

9:42 PM — Repo scaffolding. README with project overview and architecture diagram. CONTRIBUTING.md addressing two audiences (EOS practitioners and developers — deliberately different skill sets). .ceos marker file for skill repo-root detection. .gitignore that keeps data/ out of the upstream repo. Directory structure for skills, templates, and docs.

9:50 PM — Seven EOS template files. This was the first real design decision: which files get YAML frontmatter (structured data that skills parse programmatically) vs. which are pure markdown (reference documents humans read). The answer: frontmatter for objects with lifecycle state — Rocks have status: on_track, Issues have ids_stage: identified, L10 meetings have rating. Pure markdown for reference documents like the V/TO and Accountability Chart.

10:04 PM — The setup script. Pure bash, zero dependencies. Three modes: ./setup.sh (symlink skills), ./setup.sh init (guided setup), ./setup.sh --uninstall (clean removal). Two portability decisions that matter: using | as the sed delimiter instead of / so file paths in values don’t break substitution, and avoiding sed -i entirely (macOS and GNU Linux handle it differently) by using temp files instead.

10:23 PM — Five EOS skills. This was the meat of the project. Each skill is a SKILL.md file — essentially a prompt engineering document in structured form. The key tension in writing skills is comprehensiveness vs. followability. Too much detail and Claude skims; too little and it improvises. The pattern that worked: tables for quick-reference data (status enums, file paths, modes) and prose for workflow logic.

The five skills:

• ceos-vto — Review and update the Vision/Traction Organizer. Shows diffs before writing. Runs alignment checks between sections.
• ceos-rocks — Three modes: setting (with V/TO alignment checks, 3-7 validation, ID generation), tracking (milestone progress, status updates), and scoring (binary complete/dropped, quarter scorecard with 80% target).
• ceos-scorecard — Define metrics with goals and thresholds, log weekly values, 13-week trend analysis with automatic escalation to the Issues list.
• ceos-l10 — The full Level 10 Meeting. Seven sections with time boxes. Pulls real data from scorecard and rocks files. Reviews actual to-dos from last week’s meeting. Facilitates IDS on the top 3 issues. Captures meeting rating.
• ceos-ids — Structured issue resolution with 5 Whys for root cause identification, discussion capture, and to-do generation.

A critical design choice: skills reference each other but never auto-invoke. The L10 skill mentions that ceos-ids can create issue files, but lets you decide when to switch. Loose coupling through mentions, not tight coupling through auto-invocation.

10:39 PM — Five documentation files targeting different audiences. The EOS primer translates business concepts into developer vocabulary. The data format spec translates the same content into a parsing contract. The skill-authoring guide sits at the intersection—it’s prompt engineering documentation in disguise as a contributor guide. A skill reference provides users with a quick overview of all five skills, including trigger phrases and examples.

10:52 PM — GitHub configuration. CODEOWNERS, three issue templates (EOS Process Request, Bug Report, Skill Improvement), a PR template with before/after sections, and custom labels. The issue templates are deliberately different — one for EOS practitioners (“I think the Rock scoring process should work differently”), one for developers (“setup.sh fails on Ubuntu”), one for skill improvements (“ceos-l10 should handle recurring agenda items”).

11:08 PM — Final cleanup. Removed companyos-integration.md which contained internal details about how CEOS would integrate with our private CompanyOS system. Archived the content to a Linear comment before deleting — git history preserves it, but a Linear comment makes it findable without git archaeology.

During this, my Claude instance learned a few things that have been incorporated into our local learning (a dynamic file I keep and use to update skills during periodic sweeps).

Writing skills are prompt engineering in document form. The biggest trap is the description field. If you write “manages Rocks in three modes with binary scoring,” Claude will follow that summary and skip the detailed process sections. The description should say when to use it (“use when setting, tracking, or scoring quarterly Rocks”), not what it does. The body has the what.

Templates need lifecycle awareness. The distinction between frontmatter and pure markdown isn’t about complexity — it’s about whether the file has state that changes over time. A Rock moves from on_track to off_track to complete. A V/TO document is edited but doesn’t have lifecycle states. That distinction determines whether a skill can programmatically query and manage the data.

Documentation for AI skills packages needs three layers. User-facing (what can I do?), contributor-facing (how do I add?), and machine-facing (what’s the contract?). Most projects get the first two. The third — the data format spec that makes YAML frontmatter a real, portable, parseable contract — is what makes the ecosystem extensible.

The .ceos marker pattern is underrated. Borrowed from .git and .npmrc, a zero-byte marker file at the repo root gives every skill a reliable way to find the CEOS repository regardless of where the user’s working directory is. No environment variables, no configuration, no hardcoded paths. Just search upward for .ceos.

CEOS is live at github.com/bradfeld/ceos . MIT license. Do whatever you want with it. If you are into EOS, come play. I’ll pay attention to any PRs and issues. Following are the next few things I’m going to create.

• Process Documentation skill — The 6th EOS component. Document core processes as checklists with followability metrics.
• People Analyzer skill — Right people, right seats. The GWC (Get it, Want it, Capacity to do it) evaluation tool.
• Quarterly Conversation skill — The formal quarterly check-in between managers and direct reports.
• Annual Planning skill — Year-end V/TO refresh and next-year Rock setting.

And, while I was trying to come up with a name for this, with Claude, it told me I need to include the following footer.

CEOS is an independent open-source project. It is not affiliated with or endorsed by EOS Worldwide.

Dan Shapiro just open-sourced Freshell — a browser-based terminal multiplexer for Claude Code, Codex, and other coding CLIs that lets you detach and reattach sessions, browse your coding history, and access everything from your phone. The tagline is “What if tmux and Claude fell in love?” which is about right. It can be pronounced multiple ways: Free-shell, Fresh-hell, fresh-shell. I’ve been thinking of it as Fresh-hell, which amuses me.

As part of my exploration into AI coding, I decided to start contributing to open-source projects. I’ve been around open source for decades as a user and investor, but I’ve never been a consistent contributor. That’s changing now — it’s a natural extension of the learning I described in Blurry Transitions , and the best way to understand how software gets built today is to actually build it with other people.

Freshell is my first project. Dan and I have been working together for over a decade at Glowforge , and I love working with him.

I’ve been using iTerm2 for about six months. I expect I’ll have switched to Freshell by the end of the weekend. It already does most of what I want, and a lot more is coming. The combination of persistent sessions, browsing the CLI history, and the ability to access my terminals from any device is enough on its own. But the thing that makes me want to contribute rather than just use it is that it’s early — there’s a bunch of stuff to build, it’s something I will use continuously, and by participating in the open-source project, I can see how the changes I make work in that context.

This post was written inside a Claude Code session and posted directly to feld.com as a draft. Not copy-pasted. Not emailed to myself. I just typed /blog-feld in iterm2 and it showed up on my blog.

Setting this up took about ten minutes.

I asked Claude to figure out how to connect to feld.com (hosted on WordPress.com) for direct posting. It researched three approaches: the WordPress.com REST API, the official WordPress MCP connector, and the WordPress plugin MCP Adapter. The WordPress MCP connector is read-only (so, useless for posting). The MCP Adapter only works on self-hosted WordPress (not WordPress.com). That left the REST API with OAuth.

Claude wrote a command called /blog-feld that handles the workflow: look at whatever I’ve been discussing in the current conversation, assemble it into a post, show me a summary, interactively edit with me, and then push it to feld.com as a draft.

It never publishes directly — I still review everything in the WordPress editor before hitting publish.

For authentication, WordPress.com requires OAuth. Normally, my experience setting this up is tedious. In this case, Claude just told me what to do step by step.

– I registered an app at developer.wordpress.com (Client ID + Secret)
– Claude set up the authorization code flow.
– I visited a URL, clicked “Approve,” and the browser redirected to localhost with an authorization code in the URL.
– The page itself didn’t load, but the code was sitting right there in the address bar.
– I screenshotted the page and pasted it into iterm2, and Claude exchanged it for an access token.

Done.

To verify it worked, Claude pulled my last three posts from the API. “Tech I’m Obsessed With,” “Blurry Transitions,” and “Interview With Guy Kawasaki.”

This is a small thing, but it’s the kind of small thing that changes behavior. Every day as I work with Claude Code, I think of multiple things like this. Instead of waiting for someone else to implement it or paying for a third-party service, I just create it in Claude Code and make it a permanent part of my environment.

I’ve been writing more inside Claude Code sessions anyway — working through ideas, editing, and iterating. The friction was always the last step: copy the text, open WordPress, paste it in, format it, fix the formatting that broke. Now that step is gone.

Thinking-in-conversation and writing-for-the-blog are the same thing.

I love getting emails from Ben Casnocha . Short, sweet, and to the point. Today’s was “what tech are you obsessed with now? Saw your blog post…” I wrote a response and then realized it was a good answer to my tease from my previous blog post (Blurry Transitions ) about what I was exploring. The only thing I removed was my ad hominem comments on various tech companies, since that’s not that interesting to me. And, I fixed some … typos.

Here are a few hints: IntensityMagic  and an image of my computer screen (the one above).

I decided I really wanted to understand how AI coding works. I’ve been deeply involved in a few shifts in the past (Agile software development, user-generated content (RSS), email everything (SMTP), … and, if you go back far enough, Feld Technologies was all about shifting from minicomputer business systems to PC-based network database systems). In all cases, I had to “do stuff” to understand it and form a viewpoint, given all the BS and marketing in tech.

I wanted to see if I could create a zero-employee company, aside from the CEO and CTO. Daniel (Feld) is the CEO. I’m the very part-time CTO. I’ve created a thing called CompanyOS, which is IntensityMagic’s AI-powered business operations system. It’s designed around the premise: “Run 100% of a company’s business operations through Claude Code. Two people, multiple Claude agents, zero employee overhead.”

At the core, I’ve gone extremely deep on Claude Code and everything around it.

– I think “vibe coding” is nonsense – it’s just prototype development and a different flavor of no-code software, which is useful but not compelling for scaled applications.

– There are $x billions of VC who have funded what are effectively wrappers on AI and/or point solutions that can be made obsolete overnight. 

– Most companies that try to integrate “AI coding” into what they are doing are struggling because they haven’t figured out the tooling, which is not just “turn on Github Copilot” or “use Cursor.”

It’s much easier to experiment deeply with “no employees” and “no legacy stuff,” so that’s what I’m doing. I’m viewing it as a video game, and I’m on level 19. It’s awesomely fun.

Turning 60 in December marked an important moment for me. A key section from that blog post was:

“I’ve definitely shifted into a new mode over the past year. I’m still on a bunch of boards for Foundry and deeply involved in several companies. But I’m much less focused on the broader technology industry, uninterested in many of the things that are going on, and tired+bored of the arc the narrative about technology and society has taken.”

Amy and I spent the last six weeks in New Zealand and Australia for my 60th birthday trip. I went into hibernation as part of that, stopped doing anything public-facing, and flipped to default no. I also stopped blogging, engaging with social media, and reading the news.

It gave me a lot of time to think and reflect. One thing that I realized was that I’ve never had a hard break or a clean transition from one thing to another. I have multiple threads of this, but if I just choose a professional one, here’s an example.

– I started my first company while in college.
– I started making angel investments while working for the company that acquired my first company.
– I became a VC while I was still founding companies and making angel investments.
– I co-founded Techstars and Foundry while still managing the legacy Mobius funds.
– I started writing books as a VC.

I did a similar exercise on technologies that interested me and generated long investment arcs (which we used to call themes at Foundry). There was usually a trigger point that created a new theme, where I became obsessed with a new technology of some sort and went very deep into it as a user and investor. These overlapped and fed off each other multiple times.

Basically, I’ve never had a “clean break” or a hard transition from what I was doing to what I did next.

I’m enjoying another one of these blurry transitions. I’ve found the new technological thing I’m obsessed with. While I’ve played with this new thing over the past year, I spent a lot of time with it over the last two months. And my interest (and competence and understanding) is accelerating.

I also realized that I missed writing. I know that I learn by reading and writing. I don’t learn by listening and talking (or at least not very much). I have to actually write things down. And, my new obsession involves a lot of writing…

Historically, I’ve gotten a lot of feedback on ideas by writing publicly. It’s also more helpful to me, as it has generated a ton of randomness on many dimensions. And, if you’ve read Give First: The Power of Mentorship , you know that many of the successful things I’ve been involved in came from this randomness.

So, I’ll be writing publicly more. I’ve consciously decided that is not part of hibernating.

When I was 17, I knew of four people at Apple Computer: Steve Jobs, Steve Wozniak, Al Eisenstat, and Guy Kawasaki. I loved my Apple ][ (not a +, 48k, with an Integer Card, two floppy disks). By this point, I was spending a lot of time on my high school buddy Kent Ellington’s TI PC (pre-release – his dad was the production manager), but my Applie ][, now with a Z-80 card, sat in the corner of our family room and consumed a lot of my time.

Of the four, I’ve met all but Steve Jobs in person. Al Eisenstat was the first, on a trip to Cupertino with my parents, where I was supposed to meet Steve Jobs, but Al greeted me and spent a meaningful 30 minutes with me instead. Woz was next and we ended up investing (via Mobius) in one of Woz’s companies (called … Woz – it was ahead of its time).

I’ve long admired Guy and we have lots of second-degree-of-separation friends. One of them, Buzz Bruggerman, came up to me after a Give First: The Power of Mentorship talk in Seattle this summer and asked if I knew Guy and had ever been on his podcast. I said, “Nope, but I just listened to the one with Ben Gilbert that Guy did.”

In typical Buzz fashion, I had an email connecting me to Guy within a few minutes, and we quickly set up a time to do a podcast. I did it sitting outside at Rancho Valencia on a sunny day, was in a great mood, and at the very end of the podcast grind for the book promotion.

The podcast is now up at Building What Lasts: Brad Feld on Trust, Mentorship, and Long-Term Thinking .

It was special. It starts off fast. We learn about Guy’s early dating history with Al Eistenstat’s daughter. We talk about Heidi Roizen and Atherton. And then Guy is the very first person to make the link between the 18 items in the Techstars Mentor Manifesto, Chai, the important number 18, and entrepreneurial Tzedakah. All within the first ten minutes.

Enjoy!

And Guy – that was a delight.

Startup Snapshot, a think tank uncovering the unspoken realities of the entrepreneurial ecosystem, has released its latest report, The Untold Toll (Part 2): Navigating Stress, Wellbeing, and Burnout in Startup Teams .

The emotional and mental state of startup teams has emerged as one of the most overlooked drivers of company performance. Startup Snapshot illuminates the unseen side of startup life through global data collected from startup employees. It’s the first study of its kind, and the findings are candid, revealing, and deeply human.

The startup grind is taking a heavier toll than expected. Only 10% of employees anticipated that startup life would harm their mental health, yet 80% say it has. Burnout affects 50% of employees, and 52% report anxiety, surpassing even the rates reported by founders themselves.

Founder stress quietly cascades through the organization. While only 10% of founders openly share their emotional challenges with their team, 57% of employees say they regularly notice signs of founder stress through tone, energy, and facial expressions. 

This unspoken tension shapes culture and affects how safe and stable employees feel. Teams led by highly stressed founders report 16% lower work wellbeing, 14% higher burnout, and 16% lower psychological safety.

The most significant stressor for employees isn’t workload or pay, but uncertainty about what’s happening in the startup. Yet only 18% say their founders are fully transparent about the company’s challenges. 

Transparency directly affects employee performance. Employees working under transparent, communicative leaders experience 19% higher work wellbeing and 26% lower turnover intention. When people understand what’s happening and why decisions are made, they feel secure, valued, and connected to the journey.

The research makes it clear: Founders set the tone for stress and well-being across their startups. When leaders neglect their own mental health, that stress spreads to employees, driving burnout, disengagement, and long-term cultural damage. Startup Snapshot will continue to investigate the emotional and psychological landscape inside startups. If you want to be part of this dialogue, reach out to yael@startupsnapshot.com .

My partner Seth Levine has an important new book out today titled Capital Evolution: The New American Economy .

I saw it last night at the Boulder Bookstore in the New Hardback Non-Fiction section (bottom left in the photo below) and am going to the launch event at Composition Shop in Longmont. Join us, say hello, and buy some books!

I love the tagline from the flyleaf: “The future of capitalism isn’t left or right – it’s forward.“

In our over-politicized world, Seth and his co-author, Elizabeth MacBride, do an outstanding job of defining capitalism clearly and explaining how it evolved into today’s approach. They deconstruct the contemporary arguments “for and against,” examine challenges with many existing practices, and paint a new and compelling path forward.

Seth and Elizabeth have been working on this book for over two years. I read an early draft around a year ago and gave them a lot of feedback, so it’s been a joy to see it take shape.

Unlike my largely anecdotal books, which draw on my experiences, often with sidebars from others sharing theirs, Seth and Elizabeth did deep research for this book. I fondly remember showing up at Seth’s party barn at his house one day to see the large dining table covered with hardcover books on economic theory, the history of business (and capitalism and economics), and a bunch of other stuff he was reading as part of his extensive research.

As with Seth’s other book, The New Builders , it is both extremely substantive and eminently readable. I encourage you to buy and read a copy of Capital Evolution: The New American Economy .

Google seems a little confused.

It was even confused about my age the other day, but at least it has that right now. It was a little confused on December 1st.

I mean, c’mon Google. Use all those chips you have to get it right!

My father Stan and I in our default states.

lsof -ti:3000 | xargs kill -9 2>/dev/null; npm run dev

I’ve been wandering up to 60 for a while. During my extreme-extroversion around Give First: The Power of Mentorship I described myself as “almost 60” a bunch of times just to try it on.

It feels comfortable.

Several people responded with “60 is the new 40.” Nope. Not even close. I most definitely do not feel like I did when I was 40. On my annual birthday run this morning (at least 1 minute for each year), I just plodded along, even though I comfortably covered 65 minutes. I sleep more (good), I care less about a bunch of stuff (good), but my energy is lower and the fatigue is ever present (bad).

I’ve definitely shifted into a new mode over the past year. I’m still on a bunch of boards for Foundry and deeply involved in several companies. But I’m much less focused on the broader technology industry, uninterested in many of the things that are going on, and tired+bored of the arc the narrative about technology and society has taken.

In contrast, I’m much more interested in people I care about. Not big groups of them, but the one-to-one relationships. My real friends are wonderful. The deep relationships are what have meaning to me.

I recently told Amy that I enjoy all the CEOs I’m working with. While I’ve always been friends with many of them, this is the first time that I can recall feeling a genuine friendship with all of them. I know that something new will be fucked up in my world every day , so that has nothing to do with these relationships. Instead, how we deal with whatever new fucked up thing will happen means everything.

I’m writing a lot. Give First: The Power of Mentorship may be my last non-fiction book. I’ve shifted to fiction and software. I’m having a ton of fun with both, bringing a beginners mind to the mix, even though I have the right kind of muscles for each from my past experiences.

While I haven’t solved my post-exertional malaise issue, I’ve settled into an understanding of it and how it impacts me physiologically. I’m experimenting with a bunch of things, keeping the ones that work and punting on the ones that don’t. And yes, pilates is magnificent.

On to the next decade …