Every time I go to a bookstore, I pick up five different books. But which one will I like the most? This project will help me responsibly slow the growth of my TBR stack by estimating the rating I would give each book, using my own reading history as a data source.

NOTE: sign ups are disabled to keep my costs down ;)

Learning Goals

• Create a new project from scratch, no templates
• Lean heavily on coding assistants, in particular Every’s compound learning Claude plugin
• Create a web-accessible site to solve a real problem I have

Links

• Repo
• Site

Stack/Tooling

• ChatGPT for initial project plan
• Every’s Compound Engineering plugin
• V0 for UX design and iterations
• Claude Code VSCode plugin
• Postgres (hosted on Neon)
• Vercel for deploys and hosting
• Typescript
• Next.js for routing (front and backend)
• ngrok for local tunneling, used for local mobile testing
• OpenLibrary for most book data
• Google Books for additional book data

Main Takeaways

The compound engineering plugin is token hungry, but I’m very impressed by the thoroughness of it’s planning capabilities.

The key skill of a software developer is expressing intent.

Curiosity will increasingly become the key quality that helps engineers grow in their career.

Reflections

My primary goal for this project was to lean heavily into modern AI-driven coding workflows. As the landscape has shifted significantly since I was a full-time developer, I wanted to push these tools to their edges—identifying what works, what breaks, and where the “diminishing returns” begin. Understanding these boundaries helps me discern when to step in manually versus when to rely on an agent.

The Stack & UI Scaffolding

The power of V0 was impressive. I used Claude to build the initial scaffold and establish the API. This workflow is a bit backward for a UI-first tool like v0, but it worked well. I used Claude to meta-prompt the instructions for v0 once the skeleton app existed. I think having a skeleton built helped me get better clarity about my UI needs, which made working with V0 much more efficient. Clear API boundaries helped as well.

After some minor tweaking in v0, the initial UI was very close to what I wanted. I was able to lift the UI files directly into my codebase and then had Claude work page-by-page to integrate the backend logic. Interestingly, once a UI paradigm was established, adding new features in that style became trivial; I could iterate directly in the code with Claude without returning to v0.

Workflow Orchestration

I leaned heavily on Every’s Compound Learning plugin for Claude. While the plugin can be triggered via slash commands, I found it difficult to recall the precise sequence of the workflow. However, I discovered that if I simply instructed Claude to use the plugin, it would intelligently select the correct step, removing the cognitive load of manual invocation. One minor friction point: I still had to explicitly prompt it to record learnings; I’d prefer for that “memory” function to be more autonomous.

The Planning-First Paradigm

Putting 80% of the effort into the planning phase paid off, but it highlighted a specific risk: AI agents suffer from the same “author validation” and pliancy as LLMs. If I proposed a flawed architectural path, the agent often gladly followed me down the rabbit hole, requiring painful unwinding later.

I found the most success by outlining outcomes and constraints, then letting Claude perform the research. This reinforces my belief that the core key skill of an engineer is expressing intent whether to a compiler, an agent, or a human reader. Clearer intent invariably leads to more resilient solutions.

The Cost of Context

A planning-focused workflow is significantly more “token-hungry” than a code-focused one. This makes sense to me in retrospect: generating comprehensive documentation and architectural specs produces more output tokens than most code changes. I found myself aggressively monitoring token usage and scheduling development around Anthropic reset windows. To mitigate this, I began leveraging multiple sources: using ChatGPT to define the problem space and research best practices, before moving to Claude for the specific implementation.

The Trust Gap and “Prompt-Reviewer” Bias

Offloading so much labor to an agent introduces a dangerous level of “rubber-stamping.” It is incredibly easy to approve a PR without inspecting the logic or testing the edge cases. This is a classic resiliency issue caused by automation: the more automation leads to a decay in system knowledge by operators, ultimately making the system less safe and more difficult to operate.

We need to bring a healthy skepticism to every change. In traditional engineering, we say an author shouldn’t review their own code. We need a new corollary: you should not review a change that you prompted. In both cases, your assumptions and blind spots are already baked into the intent you expressed.

Curiosity will be a help mitigate some of these issues.

Compliance and Control

During long sessions, the required approvals becomes a bottleneck. It is tempting to grant agents greater autonomy, but the part of me that has worked with enterprise compliance shudders at the thought. This feels like the next generation of the “should developers have prod DB access?” debate. This may also be operator error, maybe there are better permission settings I could leverage. This may also be a tooling issue, I’m interested in using Ralph for a fully hands off development experience.

The Data Hurdle

In the end, I built exactly what I set out to create, but the biggest hurdle remains data. Finding high-quality, free sources for book genres and themes is difficult. I eventually settled on a manual AI enrichment pipeline:

1. Export data from Goodreads.
2. Batch the data into 20-row increments.
3. Use a Custom GPT to annotate the books with “community tags.”
4. Upload the enriched data into the app.

While not a scalable solution, it was “good enough” for a hobby project. However, it has me thinking about future iterations involving more sophisticated data pipelines, perhaps exploring vector encoding and ANN (Approximate Nearest Neighbor) search capabilities.

While this workflow got me good data on an individual book level, the tags didn’t have a fixed taxonomy, which reduces the accuracy of matching. I think I’ll return to this project in the future to improve on this part of the workflow.

Screenshots

A few weeks ago, I bought some t-shirts from an online store. I would get free shipping with a third shirt, so I found a brown shirt with “Cool Dad” embroidered across the front. It seemed just dorky and ironic enough to get the appropriate eye roll from my twelve year old.

But when it arrived, I realized the actual product was just cheap vinyl letters. The shirt quickly went from quirky dorky to straight bad-taste dorky. (The other two shirts were spot on perfect, so 2 out of 3 ain’t bad.)

My wife and daughter also pointed out buying a shirt that said “Cool Dad” for myself was weird. Fair point!

At the same time, I’ve been spending time building some side projects and I realized I wanted to capture my thoughts about what I learned. This helps me stay focused and iterate quickly on what I’m learning. I also wanted to push myself to learn in public.

I needed a way to rescue the Cool Dad shirt debacle and meet these learning goals. I spun up a Github pages site and used the shirt as the basis for the styling. And so cooldad.computer was born! I don’t think this helps me recover from the awful shirt purchase, it just digs me deeper, but as a learning tool I’ve been very happy!

Learning Goals

• Capture learnings from my side projects and feed those back into future projects
• Keep track of all these projects
• Give myself a place to experiment and learn without constraints

Links

• Repo
• Site

Stack/Tooling

• Github pages for hosting
• SASS styling
• Font Awesome for icons
• Favicon.io for favicon generation
• Google Tag Manager for analytics
• ChatGPT for initial styling
• Claude Code for style guide, style, and other updates
• jekyll-theme-console for base theme

Main Takeaways

Github Pages continues to be my favorite way to spin up a static site. There may be better options, but having a chosen platform reduces barriers to starting projects.

Claude did well with my prompts that instructed it to iterate until a quality metric was hit. This was like dipping a toe into some more complex iterative workflows like Ralph.

Relevant Prompts

These were the Claude prompts used to pick a Jekyll template and generate a style guide.

Picking a theme

I am a software engineer and I have the domain cooldad.computer.
I want to host a personal portfolio site of side projects at this domain
using Github Pages. The projects I make are one off coding projects.
They are usually whimsical and are purpose built to help me learn or
to test a new technology or approach.

I need a template for this site. I'd like to use something free.

Constraints:
* The template should be free
* The tone should be whimsical, but keep with an ironic
technology/computer/nerd aesthetic.
* the site will be hosted on Github pages
* I am comfortable making basic styling changes (colors, fonts, images),
but don't want to spend a lot of time rewriting the template to make it work
* The logo I use has a primary background color of #6B4A3A, font color
of #CFEFF2, and uses the Libre Baskerville font (regular 400 normal)

You are a senior designer with 10 years experience designing websites.
I am enlisting your help with picking the initial them. 

 I want you to explain my use case, tell me how you will evaluate templates,
 and tell me how you will find them. Once you have a plan, then I want
 you to find 5 templates, evaluate them using your criteria, and sort
 them from best to worst. Provide a bulleted summary with each template
 explaining how it fared in the evaluation.

Developing a style guide

ok, after weighing all the options, I'm going to start with the first
option: "Jekyll Theme Console". This may be minimal, but it's a good
start for a lightweight afternoon project. 

Next I will need you as a Senior Designer to create a style guide for me.

First tell me how you would evaluate a style guide for a portfolio site.
Tell me what topics should exist should be covered. Then create an outline
of a style guide and ask me for feedback. Once we agree on the outline, 
I want you to populate the style guide with your proposed styling.

Next, I want you to evaluate your style guide using your criteria on a
scale of 1 to 100, with 100 being perfect and 1 being completely undesirable.
If your score is below 90, create and execute a plan to correct it.
Continue this until the style guide evaluation is above 90. 

Finally, print the final style guide in markdown format.

Some existing assets:
* I attached a jpeg that can be the basis of the style guide
* the logo background color is #6B4A3A
* the logo font color is #CFEFF2
* the font is "Libre Baskerville font (regular 400 normal)"

Reflections

I’ve spun up a few Github Pages sites, so choosing that as a platform was an easy choice. I leaned heavily on AI for creating style guides and styling the site itself. I included some of the most relevant prompts above.

I set up apex domain routing and a cname for the www subdomain. Github documents this well; it was a simple copy-paste. Setting up other project-specific subdomains is trivial and doesn’t interfere with the apex DNS settings.

I used jekyll-theme-console as the template. I decided to fork instead of installing the theme, since this gives me more control over styling and implementation. However, I have a terrible habit of accidentally creating PRs against the upstream when I just want to commit to my own repo. Given how much I’ll adapt this theme to my own needs, I don’t care about getting changes from the upstream or contributing back. So I disconnected from the fork tree. PR problem solved!

The style guide approach I took is a great pattern for apps and sites built with AI. It creates a human readable, but structured natural language definition of styling that coding agents can consume and conform to. This is a pattern I want to extend into other areas of code.

I created a Claude skill to add new pages. In the past, I’ve created bash scripts to do this, but wanted to experiment. Obviously this creates vendor lock in, though it would be easy to convert the skill to some other markdown based AI interface.

I do worry a bit about usage/token consumption with this skill approach. I think my next step will be to create a well documented bash script, that way Claude just needs to know the interface and execute the script. Properly done, that should reduce token usage a bit. After all, tokens are the new oil.

Imagine an AI chat bot that was also a world weary, grizzled dungeon guide. All you need is Princess Donut by your side and you’re ready to take down the Syndicate from the inside in the relative comfort of your heart covered boxer shorts.

Learning Goals

• Understand the current landscape of tooling in the Javascript world
• Get something up and running as fast as possible
• Create a person LLM chatbot in a custom tone and style

Links

• Repo
• Site

Stack/Tooling

• Typescript
• React
• Next.js for routing
• Postgres, hosted on Neon
• Built/deployed on Vercel
• Vercel AI Gateway as an LLM proxy
• Claude Code VS Code extension
• Gemini for image creation, prompt engineering

Main Takeaways

Modern JS tooling is very good, even the rough edges are smoother than they were.

Structured natural language is the new API. This deserves more thought and experimentation.

Reflections

I used to build a lot of Slack chatbots back in the day, so an LLM chat UI seemed like a good first project.

My goal was to get something live as fast as possible, so I used a Next.js starter project. I got this up and running on Vercel pretty quickly.

A lot of what I found reminds me of webdev from the late 2010s with better ergonomics. Typescript is fully first class, Vercel gives an mature UI experience without sacrificing the CLI, DB hosting with Neon was a breeze to set up.

I used Gemini to generate the logo. I used that logo to have Claude generate a markdown style guide for me. It took a few iterations, but once the style guide was in a good place, I could use Claude Code make the styling updates I wanted. This was a pretty easy process with a bit of back and forth. The resulting style updates were written back to the style guide for future reference. I am intrigued with structured natural language as an API. This is something I want to think more about.

Editing tone of the LLM was easy, the system prompt was stored in it’s own file. I used meta-prompting with Gemini to get the voice right. This was a process I’ve used with custom GPTs, which is essentially what this project is.

Vercel’s AI Gateway was a nice abstraction to work with. It was easy to choose the models the user has access to. An AI gateway like this seems like a great way to do quality checks across models and providers. I’m interested in LLM quality testing, so I want to come back to this.

I like that Javascript APIs and frameworks have evolved to the point that they work more seamlessly between front and backend development. Using the same framework (Next.js) and native the fetch API along with native Request and Response objects are good examples. I’m sure there rough edges I haven’t encountered yet, but this is the closest I’ve seen Javascript get to it’s promise of seamless transitioning from front and backend work.

How could I finish without mentioning the REPLs. Oh my God the REPLs! The progress on CLI tooling has been really unsung. I used to love colored output or a CLI loading bar… Claude’s full fledged TUI blew me away.

This was a good start, but I’m going to move on. I’ll see if I can build something without starting from an example project next.