I've been working on a fairly complicated real-time app [0] for playing dungeons and dragons on a TV. It has to do a lot of complicated "Figma-like" things to keep the real-time nature and multi-editor possibilities in check. Oh, and the battlemap is a Three JS canvas with lots of effects and clipping going on.
I'm VERY impressed with Claude 5. I had long ago given up hope that my real-time systems would work without a lot of hacky time-windows and throttle checks. On a lark to try things out, I decided to try out the new model and talk in the output I wanted for a rewrite [1], not the solution. I just listed my problems and places I've had keeping track of my code. It went off and rewrote everything in a much more elegant solution where the state followed a very clear pipeline. It had to navigate YJS, Partykit, Svelte, Three JS, R2 hosting, and a Turso DB I was running in an embedded state for speed.
I watched it hit the wall a few times, and then sudden say... fuck it, i'm making something easier to reproduce over in /tmp to try and solve this (with a more minimal setup). I'm utterly bewildered with how well it did and how much better my app runs. The /usage would have cost me $230 bucks based on how many tokens it consumed if I wasn't already on a max plan. I'm going to miss not having it when the time-window runs out later this month, and will likely occasionally dip in for big projects and just pay my way out of some problems.
I'll also say I like it's MOOD much better now. It's a lot less congratulatory, and talks through it's reasoning in a much better way. Look, it's not a real coder, and I'm sure there is some flaws, but it took my crappy ideas and said... hey, i understand what you want to do, here's a way to do it better. Also, I removed 2x the amount of code that it added. Really impressive.
I mostly share Josh's opinion, but I think a lot of these posts that talk about Senior vs. Junior experience when working with AIs is kind of rubbish. Sure, you get better results as a Senior working with AI tooling and struggle more as a Junior. Nothing has changed in that equation except the amplification.
What folks seem to avoid is that a Junior (in ANY subject) has the ability to LEARN so much faster with an AI research assistant, and that becoming an expert has accelerated for those with the personal stamina to dig deep (this as a requirement hasn't changed). I spend just as much time with my AI tooling asking questions as I do asking it to "build" or "fix" things. "How does this work?". "Can you suggest other tools?".
I think some people always think about AI as an input / output relationship, when a lot of the time, the fiddling in between, with or without AI was always the important part. Yes people will suck in the beginning, against they always did. I think the good folks though will suck for a MUCH shorter time than I did getting into things.
A lot of people will drop out and get discouraged. That happened before too. Learning things requires persistence. I think the only real case to be made is that AI's sense of immediate pleasure can neuter people away from running into friction. AI natives likely won't understand friction and question it.
My wife used to work at Acoustic Guitar magazine. She said the most common sales line to sell a guitar at Guitar Center was "it looks good on you". The sound of guitars might not be aesthetics, but in regards to sales, it most certainly is. Everyone plays the same guitars because they grew up seeing their idols play those guitars.
Counter Slayer uses the same UI library I hand built for Table Slayer[0], so it was a little easier for me to get that one going. I used to run design for Elastic, and built their React design library (with some great coworkers) so I'm used to heavy visualization work (having redesigned Kibana years ago). It's just fun for me to take all that experience and build weird little projects as far as I can take them!
I built Counter Slayer specifically for 3D board game inserts, and that's really all I use it for. It sits on the shoulder of Svelte and Threlte (Three.js) for most of the hard stuff.
Being a user of your own product is everything. Every designer I've ever hired were good, not so much because they were a great designer, but because they understood the product and could sit in the user's seat.
This is why I'm so thankful I went with Lucia early. They sort of sunset their library and replaced it with documentation (and some small utilities) for how to manage and host authentication for yourself. It's always presented as some big, scary thing you can't manage yourself, but I found that taking the week to learn how security and basic salting works, I was able to feel more confident about how everything worked.
Stores are now putting QR codes for pricing, not listing the prices out on stickers/paper. You check on your phone, and often times walk through "scan and go" making direct payment on your phone.
This is often done in stores where they say that prices can change daily, and that these tools help them keep prices up to date. The darker pattern is what this law prevents, and that even with this sort of labeling, they can't charge you different from what they charge me in the same store.
I find this essay from Roger Ebert pretty wild in context of the times. I always think about it whenever I listen to the latest advances in AI voice technology.
Hey, I'm the OP. I originally started with FreeCAD. There's not much to "hook up" to Claude. It can natively write for FreeCAD. You don't need to use the FreeCAD editor and can point to an external, local file with an import. At that point there's not much more than pointing your LLM to that file. You'll need to tell the FreeCAD desktop app to update on changes.
Eventually I moved to JSCAD for the application mentioned in my blog post because I realized I wanted a more complex UI (which meant a web app) than what FreeCAD provided natively. If you're looking for something simple with some var statements though, FreeCAD might be enough.
In my experience, the MCP isn't really needed. Claude at least already can write the code pretty well. The problems are more with getting it to understand the output, which the blog post covers.
Over the last year I've been hacking on Table Slayer [0] a web tool for projecting DnD maps on purpose built TV-in-table setups. Right now I'm working on making hardware that supports large format touch displays.
Since I also play boardgames, this past month I threw together Counter Slayer [1], which helps you generate STLs for box game inserts.
Both projects are open source and available on GitHub. I've had fun building software for hobbies that are mostly tactile.
I have 2012 Sonos hardware. You can still get the original Sonos S1 controller, which works with old stuff. It's pretty annoying that all the new stuff is S2 (and that app is better supported), but it's not as hard as you're describing it. You can get it off Google Play and just use it.
The quality of the software, and the fact that it isn't really updated, is another thing, but the actual software availability is there.
One place where "TVs" still remain fairly expensive is in large format touch screens. Outside of using IR frames, getting a large (40 inch) touch capacitive display still requires quite a lot of legwork. I've been trying to find them for my DnD map system Table Slayer [0] and I had to contact factories in China directly. It's still many hundreds of dollars per device even for raw hardware.
I worked on (and very briefly ran) MP3.com after the CNET acquisition of the domain (CNET only bought the domain, which I think was for $1 million). It had nothing to do with the original site mentioned here (good on them for archiving it).
The initial idea of the CNET version of the site was that in 2004 we assumed you would need a directory of which music was on which service. At the time there were quite a few (itunes, recently legal Napster, Rhapsody, eMusic...etc) and the thought was that the labels would sign deals separately on each, splitting where legal MP3s could be bought. Rhapsody was the only one where you paid a monthly fee for access, the rest were pay per song or album. The directory was similar to something like justwatch.com now, and it was really hard to build the data catalog from the early Internet spiderweb of music content from these services. Believe it or not, we got most of the data from FTP drops from each service. The site also would review all the different MP3 players of the time (there were a lot of them!).
The iPod and iTunes devoured the industry to a degree that no one needed such a directory. Everyone was happy to pay 99 cents per song, or get it illegally. Rhapsody, which was way ahead of its time, was too niche, and pre iPhone, no one could "stream" on anything buy a computer.
Everyone of course hated our new site. It didn't carry the spirit or the catalog of the indie bands from the original version (we didn't own any of the rights to keep the content), and all of those artists were rightfully very angry about losing a pay stream (which again, was a nod to what was coming later with YouTube partners). It got so bad that we had to remove the message boards completely because it was pure vitriol. We later added independent artist uploads, but by 2005 it was too late and the site mostly made money converting "eyeballs" (search any artist + mp3) into money through ads.
Despite all this, I had a lot of fun working on it, and as a young 24 year old who just moved to San Francisco it was a great way to learn about online communities and how they could turn on a dime. Other, later sites of mine took the lessons learned from MP3.com and became successful, but I'll always have a soft spot for MP3.com.
I read a really interesting post in The NY Times (having trouble finding it) that really broke down how crazy sports betting has gotten in the last couple years. The gist is that states love betting, because they can tax them at high rates with little pushback from citizens who are marketed that the money goes to schools. The sportsbooks have to eat the new tax, and change the odds so that they can make a profit. This forces more losers in the state, and causes possible indirect costs from people losing so much. It’s an ugly cycle where no one wins.
I'm building Table Slayer[0]. It provides tooling to display battlemaps on TV-based tabletops for games like Dungeons and Dragons. The source is open[1] and it's built with Svelte, Partykit, Turso and Three JS.
I'm currently building a prototype hardware component (essentially a large format touch screen) that people can purchase alongside.