I've been using a `/feedback ...` command with claude code where I give it either positive or negative feedback about some action it just did, and it'll look through the session to make some educated guesses about why it did some thing - notably, checking for "there was guidance for this, but I didn't follow it", or "there was no guidance for this".

the outcome is usually a new or tweaked skill file.

it doesn't always fix the problem, but it's definitely been making some great improvements.

I was already programming when I got into mindstorms (so very happy that my high school had an "Industrial Control Technologies" class), but the jump in complexity and the thrill of seeing my code power something physical was definitely a turning point

I still have my mindstorms controller + sensors, I wonder how much effort it would be to get everything up and running again

RCX series? This is from 2020, but here’s a fairly comprehensive bit of resources on the old Mindstorms kit: https://www.johnholbrook.us/RCX_guide.html

I feel like the special parts have eased off, it was pretty bad with the bionicle stuff (which ironically are apparently what saved lego from financial difficulties), but I'd say all of the recent sets I've got (I get one a year for Christmas) going back at least 5 years have been made up of relatively generic parts, with the odd little special bit for flair.

I do think that the "model" form of something recognizable (thinking mostly about the Star Wars kits here) does lend itself to kits that sit on the shelf, but no one is forcing you to keep it assembled.

With that said, one thing I remember seeing in older kits is instructions for more than one build, which could serve as a kicking off point for someone to reapproach a bundle of bricks in multiple ways.

My own guideline is that once something is built, after a little while it has to be either modified/evolved, or disassembled and put into the bucket-o-bricks for reuse (well if I'm honest, it's several very well sorted craft/hardware bins)

there are going to be quite a lot of places where getting a laptop is a considerable expense

Why does it have to be a laptop, and why does it need to be new?

There aren't that many places in 2025 where getting a phone with internet is significantly cheaper than getting some scrappy laptop or desktop.

>> There aren't that many places in 2025 where getting a phone with internet is significantly cheaper than getting some scrappy laptop or desktop.

No, but it's not a choice between a phone and a laptop. You NEED a phone. So you use what you've got. I've done work helping developers in less developed countries and you frequently find they're sending screenshots of code they've written on phones.

I think I'll take any LLM slop code over the written-on-phone-by-"developers" slop code.

and if your pre-commit runs fast (thank you, ruff), you can set this up as a post-edit hook in claude code

I would not recommend this. A hook that modifies files causes Claude to have to re-read the file before modifying it again, which can build up your context window fast

I feel like this talk by John Hughes showed that there is real value in this approach with production systems of varying levels of complexity, with two different examples of using the approach to find very low level bugs that you'd never think to test for in traditional approaches.

https://www.youtube.com/watch?v=zi0rHwfiX1Q

You could already do these things before, you just spent much more time twiddling your thumbs waiting for lock files to be resolved