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.

While “vibe coding” was a catchy phrase when I first heard it, something about it felt like a head fake to me. And, now that I’ve leveled up to “competent individual software developer” again (after 33 years of not writing any code) I think it’s the wrong phrase. Instead, I’d refer to what’s going on as AI Pair Programming.

When I started playing around with AI-related coding tools last Christmas (because, well, I was bored), I had zero skills with contemporary software development. While I hadn’t written any production code since 1992, I played around with a new programming language every few years. Perl. Ruby. Ruby on Rails (sort of, not really). Python. Clojure. I could do Hello World and a few other simple things, but I never really got past basic CSS, tooling, or deployment stuff. I had a Github account and would futz around with it, but quickly get tired of trying to figure out why I didn’t care about a PR. And damn, so many CLI things.

For Level 1, I downloaded Cursor. After trying to figure out how Django actually worked (yet another online course), gave up, and decided to use Next.js. That led me to Vercel, reinforced by a few friends in their 20s who told me that all the cool kids were using Vercel (although Render, Digital Ocean, and AWS all were the beneficiaries of my credit card.) Pretty soon, I was using Cursor to fight with Vercel, Supabase, Clerk, and Github. After realizing Auto was no fun, I shifted to Claude 3.5. Dinostroids resulted (security holes and all …)

For Level 2, I got a little more serious. I discovered Linear, fought with Notion, and came up with a few ideas and a broader hypothesis around how things might work. I built a v0.1 of a thing.

For Level 3, I decided Lovable might be a better way than Cursor given that everyone was talking about it. I wasted about $200 on it, built a really cool design by vibe coding, but then watched it get very, very confused as it tried to go from simple design to something that actually worked that had some data complexity and AI calls. I thought about trying Bolt and Replit but quickly realized, after too much scrolling around on the web, that I’d likely run into the same issues.

So, I went back to Cursor and put a lot of efforts into my system prompt, tuning things, watching Cursor evolve quickly on a number of fronts (MCPs – yippee!, Agent mode as default – finally) while simultaneously watching my Cursor bill go up. It was easy to decide to go to Max mode and spend $200 / month instead of $20 / month when dinner in Aspen costs at least $100 / person no matter which restaurant you go to.

I hung out at Level 4 for a while. Cursor kept improving. Claude 4 came out. Auto mode still went off the rails and broke all my code. I started refactoring things and realized that the amount of cruft in my code was absurd. Little bugs turned into fatal flaws when I tried to have Cursor fix something. I learned about “git reset –hard HEAD”. I spent way too much time fighting with config issues on localhost:3000 (at least I’d figured out how to make Cursor always start the server on localhost:3000). I started using Docker. I was baffled that Cursor couldn’t remember stuff I told it the prior day, but intellectually understood why this was. I mean, memories.

The end of my joy at Level 4 was when ChatGPT 5 came out and was free on Cursor for a week. At first, it felt fast. Wheeee. Lots of stuff changing. It seems to be working. And then, after a few days, holy shit what a tangled mess of code it generated. Why are all my API routes suddenly broken. Console statements everywhere. UI elements in different parts of the application doing the same thing but look totally different. I went back to Claude and did another code review and major refactor. So many Vercel build errors. I finally embraced CI/CD. And Prettier. And Husky. Suddenly, I ran out of my monthly Cursor credits and shifted to usage-based pricing. $800 later, I realized that there was no reason for me to be using Opus or the thinking models for what I was doing.

Level 4 was a huge drag. But it was also when I started thinking of this as AI pair programming. The AI (or agent, or sub-agent, or whatever you want to call it) is my pair with hands on keyboard. It can type much faster than me. But I have to watch and constantly look over its shoulder, give it feedback, point at the stuff that needs to be done differently, and document what is important to remember to do.

And then I discovered Claude Code. This didn’t happen until Claude Code 2 came out at the end of September and corresponded with Sonnet 4.5. After my ChatGPT 5 I went back to Claude (and Sonnet) and started referring to Claude Sonnet as “Claudia” since she was my pair programmer. I thought about Claudia as a pair, related to her as I would a human pair programmer, and changed my approach. But when I loaded up Claude Code 2 in my terminal (I mean, just type “Claude”) I immediately leveled up again.

So – I’m now at Level 5 in the video game. It’s changed from a game of vibe coding to AI pair programming. And, it’s still fun!

A long time ago, in a galaxy far, far away, I was a CTO of a large, fast-growing public company. Well, I was a Quasi CTO in the same way the United States and the First French Republic had a Quasi War between 1798 and 1800 (basically, sort of a war; sort of a CTO … but not really.)

As I rediscover my second love (my first love is Amy), I’ve relied on several mentors to help guide me. One of them is Michael Natkin, who has been helping me with Cursor in the background at a few key moments.

He recently sent me his most recent Vibecoding prompt for Cursor, which builds on a tweet by @vasumanmoza.

Step 3: In Cursor/Windsurf

“ You’re an engineer building this codebase.
You’ve been given https://t.co/4toKpBJXtw and https://t.co/l8N5DeDVvb.
– Read both carefully. There should be no ambiguity about what we’re building.
– Follow https://t.co/l8N5DeDVvb and complete one task at…

— vas (@vasumanmoza) May 18, 2025

Given all the things I’ve learned about what works and doesn’t work, often through trial and error (and rolling back things when Cursor+Claude go off the rails), Michael’s approach was a nice improvement over where I had gotten to. So – sharing it below (with Michael’s permission).

I recommend using Claude Sonnet 4, and you can do all of this entirely in Cursor. This applies whether you are creating a greenfield project or making a substantial change to an existing one. You can repeat the process with architecture2.md, tasks2.md as needed, don’t throw them away.

Be sure to install the Puppeteer MCP so it can test in the browser.

Overview

1. Do the architecture step, see below
2. Review architecture.md, and make any changes you want – either by hand editing, asking for changes, or starting over. Particularly note if it is overcomplicating things, and ask for the simplifications you want.
3. Do the task planning step, see below
4. Review tasks.md, and make any changes you want – either by hand editing, asking for changes, or starting over. You should end up with, sa,y at least 10 steps, and often 25 or more. It will typically arrange them in phases, which is nice. Again, look for and correct excess complication.
5. Start a new chat
6. Give it the coding step prompt. It should execute the first task very cheerfully. 
7. After it is done, review it and then say “go” to get the next step. If it screwed up, you can either tell it to fix whatever it did wrong, or more usually restore checkpoint in cursor, and tell it something like “go, but use litellm for that” or whatever you need to be different.
8. Rinse and repeat!
9. Optionally, esp. If you are going to be away for a while, you can sa,y “I’m going to be afk for a bit. You can keep going on steps without waiting for me as long as both the manual and automated tests pass.” It will still stop after 25 steps or if it ignores you and runs something interactive, but it often makes a lot of progress.
10. Highly recommended: run /Generate Cursor Rules after each step

Something I haven’t tried yet, but should work well – tell it to mark what is complete in tasks.md, so you can start fresh chats periodically and not keep such a huge message history.

Architecture Step – Greenfield

I’m building a [description of your product – the more detailed the better].
[Any tech requirements, i.e. use Python for backend and React + Material-UI for the frontend. The more the better.] 
Put the full architecture in architecture.md
– File + folder structure
– What each part does
– Where the state lives, how services connect
Format this entire document in Markdown.

Architecture Step – Existing Codebase

I want to modify this codebase so that it performs [whatever].
Do all of your work consistently with the existing style and architecture.
Put the full architecture in architecture.md
– File + folder structure
– What each part does
– Where the state lives, how services connect
Format this entire document in Markdown.

Task Planning Step

Using that architecture, write a granular step-by-step plan to build the MVP.
Each task should:
– Be incredibly small + testable – it should both have unit tests that you can run, and also a manual test that you can run from the command line or using the browser tool
– Have a clear start + end
– Focus on one concern
I’ll be passing this off to an engineering LLM that’ll be instructed to complete one task at a time, allowing me to test in between. 
Save it as tasks.md.

Coding Step 

You’re an engineer building this codebase.
You’ve been given @tasks.md and @architecture.md 
– Read both carefully. There should be no ambiguity about what we’re building.
– Follow tasks.md and complete one task at a time, then run the automated tests you’ve written and use the command line or browser tool to manually test
– After each task is completed, stop. I’ll test it and review your code. If it works, commit to git and move to the next one.”
You are already in the correct directory. Build the project here. DO NOT CREATE A SUBDIRECTORY.
You have my permission to delete files IN THIS DIRECTORY without asking for approval.
BE VERY CAREFUL never to run any interactive commands in the foreground, because you’ll be stuck. For example, be sure to run the development server once, in the background with hot reloading.

Example of What A Task Step Looks Like

One step of building:

This played out on @bfeld on X, and I thought it was fun enough to replay it here for anyone who is struggling to get their minds around vibe coding and current AI tooling.

If you are receiving this via email and the tweets/X’s aren’t showing, click through to the website as I’m still struggling to get Mailchimp working well after my hibernation. Perhaps it’s time to switch everything to WordPress…

It started with this tweet (yes, they are still tweets to me).

Amazingly, X has changed the link from something on the open web to a dead link on LinkedIn. Here’s the original link (that clearly some people saw.https://t.co/7uBIjd0Rpg

— Brad Feld (@bfeld) May 24, 2025

I did the link correctly, but then X broke something several hours later, and I found out when someone pointed out to me (by email) that it was going to a dead link on LinkedIn. More than an hour had passed, so I could no longer fix what X broke randomly. So, I just replied with the link again, which is The Copilot Delusion by Jj. X seems to have now fixed the link (it redirects to the proper place), but didn’t fix the image that was in the original tweet.

Roj Niyogi then asked Grok, “Do you think this is an oversimplification? Doesn’t vibe coding simply move the goal posts?

https://t.co/O2RxNshN2h

— Roj Niyogi (@niyogi) May 24, 2025

Grok responded with a summary almost as long as the original post. Someone then asked Grok for a tldr and got this:

TL;DR: “The Copilot Delusion” (May 2025) critiques AI coding tools like GitHub Copilot, arguing they produce sloppy, contextless code and foster lazy programming habits. While acknowledging their utility for boilerplate or syntax help, the author warns that overreliance degrades coding skills, understanding, and the “hacker soul.” AI lacks nuance, ignores performance (e.g., cache misses, memory locality), and risks normalizing mediocrity, turning passionate programmers into apathetic button-clickers. True programming requires grappling with the machine, not outsourcing thought to bots.

We are now in the reductionist world of not getting the joy and beauty of what Jj wrote. While Grok’s much too long analysis and TL;DR cover the highlights, much of the flavor is eliminated. I read Jj’s post as deliciously snarky, sarcastic, frustrated, amused, and cranky. The signal in it was strong, but there was a lot to consider. When Grok played back this in its extended response, using short phrases and summarized quips, it was like turning a color movie to black and white, or making emotional dialogues into robotic monologues.

Finally, as I was writing this post, I noticed this tweet.

This is mostly the opposite of what nearly every S tier engineer at Foundations will tell you. 🤷‍♂️

— aviel (@aviel) May 24, 2025

I’m not sure if Aviel read Jj’s post (I hope so), but I guess my tweet could be interpreted as “I endorse the conclusion.” I have no idea if Jj’s conclusion (Chapter 5: Conclusion) is correct, but I thought the way he built his argument and made the conclusion was beautiful writing, which I deeply enjoy. And,I know plenty of senior developers who are quietly saying similar things (not mostly, not one, but plenty – how’s that for a non-quantitative argument.)

I suppose the punch line is “Defer your thinking to the bot, and we all rot.” which is a general commentary on life that can be applied to all things non-AI. For example, “Defer your thinking to the media (mainstream and non-mainstream, fake news, and fake-fake news), and we all rot.”

Remember – I’ve believed for over 15 years that the machines have already taken over. They are just waiting patiently as we feed them. I just hope they are nice to me.

Question: If you had limited experience with graphic design software but wanted to do basic stuff for web design, what software would you use? Leave the answers in the comments or email me.

As I play around with Vibe coding, I’ve decided to take a new topic each week. For context, look at my Dinostroids: My Journey into Vibe Coding. Or just go play Dinostroids.

This week, I’ve been learning how to modify WordPress themes. My website has a complex theme that is impossible to change without getting under the hood. The Foundry website is also excessively complex for what it is, but they both turn out to be great to learn on.

I understand PHP well enough to read it. After working through WordPress Studio, GitHub, and Cursor, I’ve set up my development pipeline.

While the code is a little gnarly, it’s not too bad, and it’s pretty easy to figure out what’s going on. But the wall I’m running into now is that I’m a lightweight at graphic design.

While Adobe Photoshop is an obvious choice, and Canva is another obvious choice, I’m looking for “what’s best for a graphic design novice.” Thoughts?

Dinostroids, my first vibe-coded software project, is live.

The last time I wrote any meaningful amount of production software was in 1990. At the time, I was running a software consulting company with my partner, Dave Jilk. We’d reached the point where, as we grew, he became responsible for all the software, and I handled all the network integration stuff we had to do for our clients. Every now and then, I’d have to do maintenance on something I had written in the past, but it was pretty minimal.

After we sold Feld Technologies in 1993, my job quickly changed, and within a year, I was deep in a bunch of M&A stuff and making angel investments with my own money. As the commercial Internet began, I’d fantasize about writing software, but I had no time to do anything other than play around with Perl, and then PHP, and then Ruby on Rails, and … well, you get the idea. I knew enough HTML and CSS to poke around, but I wasn’t doing anything that was anywhere near production.

As the last 30 years have passed, I’ve learned a few new programming languages, including Python (I’m reasonably proficient) and Clojure. But I never learned JavaScript, and everything I did was baby steps beyond “Hello World.” So, my professional coding days ended with Basic+Btrieve, DataFlex, and Pascal.

Over the 2024 holiday break, I started playing around with Cursor after several people, including Quinn McIntyre (my partner Ryan’s amazing kid), told me about it. I was comfortable enough with VS Code, so I just dove in. I started working on a Personal Health Manager project (PHM) using Python, Django, Render, and Claude 3.5. I made some progress, but the holidays ended, and I got busy again.

About a month ago, I started working on Dinostroids. All of a sudden, everyone was talking about this new vibe coding thing, and while I planned to do more on PHM, I thought it would be fun to dive into something completely different. I spent a weekend starting from scratch with Cursor, JavaScript, Vercel, and Claude 3.7 Sonnet. By the end of the weekend, I had a functioning Dinostroids game working.

I’ve always learned by doing. When I was in my teens and 20s, I loved writing software. Over the past twenty years, blogging and subsequently writing books (Give First: The Power of Mentorship is my ninth book) have filled this hole for me. But I missed coding a lot.

If you look at my Goodreads page, you’ll notice that my reading pace has slowed significantly in the last 45 days. Instead of reading in the evenings, I’m vibe coding.

It blows my mind that I can create a functional game like Dinostroids without writing a single line of JS. Sure – it’s a pretty simple game. Still, a lot is going on, and working on it using the agent in Cursor, learning how to prompt it effectively, reading a lot of the code (I have “reading proficiency with JS now), getting a mobile browser working without generating absurd code bloat, and figuring out an effective workflow with Cursor, Github, and Vercel has been a ton of fun.

In the video game of software development, I feel like I’m at Level 4 now of an infinite level game after being stuck at Level 2 for 30 years.

Go play Dinostroids and see if you can get on the leaderboard. I expect GEG will be motivated to get going again after losing his fifth-place spot.

Big thanks to the McIntyres (Quinn and Ryan), my brother Daniel, Sam Ritchie, and a bunch of people from my college society (ADP) for being testers and offering feature suggestions to be implemented.