jbdamask
Podcasts turn out to be a pretty good way to keep track of progress. At the end of a unit of work, the agent writes a script from the agent chat history (including my interjections) and generates the audio with voices from Eleven Labs.
A funny example came from an episode where I learned about the team's plan to run a large test suite. Instead of going through my Claude plan the team thought it was a good idea to use API calls. Estimated cost: $730.
I didn't get banned but you can imagine my mature, productive response when I hopped into the chat to stop the test.
I've filed this as a bug.
Per your comment about the documentation - I agree that the docs aren't great for humans. In fact, they're meant to be read by agents, not humans. But I don't make this clear anywhere.
During this build, my development agents were instructed to be verbose with documentation. I find that this improves code quality and architectural consistency across multiple agent sessions - Rocky Surf was built over hundreds of agent sessions. The trade-off is that there's too much for humans to read.
As I got closer to release, I read, edited, and pruned a considerable amount of verbiage, but stopped short of making concise docs a release requirement. But the fact that you noticed that a particular doc was 40 pages tells me that I didn't value your time as much as I should have. Duly noted.
Development and new releases will continue since I use Rocky Surf all the time. In fact, I recently found that it pairs nicely with Herdr https://x.com/jbdamask/status/2099110104037494963?s=20
Thanks again for trying it and commenting. You didn't have to give me feedback but you did, and that's really nice.
Show HN: Rocky Surf – Open-source control plane for coding-agent cloud VMs
Rocky Surf started late last year after Claude Code crashed my laptop.The alpha version was designed as a commercial product, but I ditched the idea because it would have required significant capital. Basically, the business would have been a cloud reseller with a bit of software on top.I built the core for my own projects - simple stuff like bash commands to create, stop, start, and terminate...
I find the perspective is a useful complement to standard code reviews.
I don't know what's taking Anthropic, OpenAI, Google, Microsoft, even AWS to build deployments themselves. There are only a handful of reference architectures for vibe-coded apps.
What I don't care for is the pretty-yet-verbose HTML outputs that I see from some teams. They can be way too long and it's often the case that the engineer who made it didn't read the whole thing.
Human task board for my agents
I've gotten into the habit of making Notion boards for human tasks for every project. My agents simply add a task when they need something, e.g. reauth AWS, give feedback on a UI, etc.This way, I don't have to scroll around the terminal or keep asking them to repeat themselves. It helps them, too, because they can bump me if I'm delinquent.
The fact is, there's not as much need for drag-n-drop low code tools anymore. At least I don't have much need.
I like NotebookLM's video creation abilities for certain things. To make this one, I:
1. Chatted with Claude about a particular part of my app. It read the code and docs for grounding and we iterated. 2. When happy w/ to scope and level of detail, I asked for an explainer doc. 3. Uploaded to NotebookLM. 4. Clicked 'Video Overview'.
But, uh, I have All Clad pots and pans and still like them. The bottoms warped on a couple so I replaced them with other brands.
In general they hold up well when hand-washed.
The handles are terrible though. Maybe it's a UX nudge to always use a pot holder?
Anyone else like llms.txt for architecture docs?
I'm a fan of using the llms.txt pattern of progressive disclosure for internal app documentation. Agents just produce more consistent code with these.Two things I regularly use it for are documenting decision records, under app/docs/adr, and to manage AWS learnings (https://github.com/jbdamask/aws-learnings-library).For example, in the case of ADRs, as the codebase grows bash tools aren't...
Gas Town has its own vocabulary since Steve got to name everything. There's the Mayor, Rigs, Polecats, Witnesses...zoiks. He blogged a lot about Gas Town but it's still the kind of thing you need to use in order to grasp.
To make learning Gas Town a bit easier, I wrote a post called A Random Walk Through Gas Town. Well, I didn't actually write it. I indexed the codebase then had Claude pull out interesting features and write about them from the Mayor's quirky perspective.
Several months ago I posted about my little proto-app, Now I Get It! that uses LLMs to translate scientific papers into web pages that anyone can understand. The feedback and engagement from this community was terrific and helped me turn it into a real product. It's a niche, convenience product. Not a game changer. I'm comfortable with that and went into it with eyes wide open.
Regardless of whether the product does anything, building and launching this as a solopreneur was super fun and educational. It helped me hone my agentic engineering skills and also gave me a better sense of what I could truly delegate to coding agents and where I had to be involved.
In short, my experience led me to believe that the best models, harnesses, and techniques aren't yet there to fully build a cloud-native app (AWS) that is fast, cost-efficient, robust, and secure. Not to mention modular and extensible. The number of decisions a human must make is still very high. That's not a huge surprise to me since coding is just one part of engineering.
The fun part of engineering (for me at least) is putting shape to a problem and thinking at a systems level even when decomposing into tasks. It's the constant zoom-in, zoom-out interplay that first attracted me to software engineering. Yes, I rely heavily on LLMs for development but 9/10 times I would find something wrong in a plan, a design, an implementation, or a test that would have created problems if I wasn't there.
The process I followed for this build, in-a-nutshell: 1. Every feature, bug, and improvement gets its own Issue. Descriptions are sparse so the LLM can really dig into during planning. 2. Plan every issue but override Claude Code's planning mode since it tries to implement immediately after a plan is approved. Also, it's helpful to have the LLM write a user story before writing the plan so that UX stays front-and-center. I had so many issues where Claude would be like, "Oh. You mean you don't want the user to see a 403?" 3. Read the plan. 4. Decompose into Beads (Thanks Steve). 5. Open a new Claude Code session in TMUX and say, switch to a worktree for issue xyz and build it. 6. Deploy to a test AWS environment. Use Claude for Chrome to do a first-pass check for front-end stuff then I'd follow up. 7. Devlog the work. 8. Make a PR, review, merge, deploy to prod
Three things I did early on that turned out to be very useful: 1. The app was free when I first posted and people from around the world processed a lot of papers. This gave me a TON of data I could analyze to figure out a pricing structure that maintains a sustainable margin. This is important because the app is self-funded; I don't want to have to decommission it because I miscalculated my expenses.
2. Optimized architecture for low idle cost. I don't want a bunch of infrastructure burning a hole in my bank account if I can't get enough customers to sustain the app. This app relies heavily on static html pages on S3 behind CloudFront, along with Lambda, and DynamoDB. All very cost-effective.
3. In addition to my DevLog skill, I made an app-specific skill called now-i-blog-it. This reviews my DevLog for recent updates and writes short, technical blog posts. Of course, LLMs aren't great writers so I wound up with another skill called cringelinter that can be run in a Ralph loop to scrub all the mic-drops, bro-speak, and cringe words from the blogs.
The blog has over 60 entries so far covering everything from architecture, to adding an inline HTML and KaTeX editor, to my first hacker, to launch. Some of you may find it interesting. It demonstrably shows that that reports of the death of software engineering have been greatly exaggerated.
Thanks again to this community for engaging with my original post. It's been a fun build.
One-liners to check for bad litellm and axios on your computer
Search your drive (not mounts) for compromised versions of litellm and axios.Please comment if you see anything wrong or ways these can be improved!LiteLLM: find / \( -type d -name "litellm-.dist-info" -o -name "litellm_init.pth" \) 2>/dev/null \ | while read d; do case "$d" in dist-info) v=$(echo "$d" | sed 's/.litellm-\(.\)\.dist-info/\1/') if echo "$v"...
Show HN: Claude Skill to create DDB-backed endpoints in AWS
https://github.com/jbdamask/john-claude-skills/tree/main/skills/aws-quick-endpoint
Sometimes I just need a place to put stuff that's not local. Apps exist that it make it easy to create an endpoint but I figured it was easier and cheaper to just make a skill.From the description: Create a token-secured REST API endpoint backed by AWS Lambda and DynamoDB with full CRUD and paginated list support. Deploys via CloudFormation. Use when user wants to quickly spin up an API...
Show HN: Claude Skill for temporary cost tracking
https://github.com/jbdamask/john-claude-skills/tree/main/skills/cost-tracking
Here's a Claude Skill that lets me turn cost tracking on an off for a particular unit of work.I use it in interactive Claude Code sessions. For example, if I want to add a Claude API feature to an app, I'll often hack it together first in CC. This skill lets me start and stop tracking so I get get a sense for what the API costs will be.For example:> /cost-tracking > [do stuff] > stop...
1) Modes. You can now choose between Native, Non-Technical, or Kid-Friendly mode. Here are results for the same paper Native: https://test.nowigetit.us/pages/62ef3639-02f0-472b-b0a6-79f6... Non-technical: https://test.nowigetit.us/pages/eba32173-269f-4b5c-9df1-c782... Kid-friendly: https://nowigetit.us/pages/3c413c94-d843-4e84-8805-22af16021...
2) I'm working on user accounts with private galleries
3) Getting closer to opening this up with a cost-plus pricing model. Hopefully by next week but we'll see.