I don't think tinkering is the dominant culture behind tech anymore, but it's definitely operating at a higher scale than ever before. There's more OSS projects than ever, and there are tons of niche areas with entire communities. Examples could include: LoRa radios (or LoRA adaptors!), 3d printing, FPGA hacking, new games for retro hardware...
There was a gap before (think 90s and early 2000s) where there was a niche tinkering and more mainstream user/power user/programmer crowds. All these groups have knowledge gaps between them, but the gap was surmountable.
Now, the groups have drifted apart. Even if you're a programmer, unless you care or get excited about the hardware, you don't know how things work. You follow the docs, push the code to magical gate via that magical command, and that works. It's similar even for Desktop applications.
When you care about performance, and try to understand how these things work, you need to break that thick ice to start learning things, and things are much more complicated now, so people just tend to run away and pretend that it's not there.
Also, since the "network is reliable, computing cheap" gospel took hold, 90% of the programmers don't care about how much performance / energy they waste.
I'm guilty of this. I started with a C64 and love hardware and programming, but modern CPUs and MCUs are so complicated I can't be bothered learning about them.
The old 8-bit Arduinos were pretty understandable, but with an ESP-32 I just assume the compiler knows what it's doing and that the Espressif libs are 'good enough'.
> There are now adults that grew up in the age of social media that have no idea how local computing works.
Very few people of any age understood how local computing (or any computing) works. There's probably more now since most of the world is connected.
Profit scale has reached a point where commercial OS creators have to do stuff like shove ads into the UI. There's probably more legitimate need from non-developers to use Linux now than ever before, just to get a better base-line user experience.
I had a really hard time getting anything like that to work (you can't just read stdout and write stdin, because you're driving a terminal in raw mode), but it took like 3 sentences worth of Claude prompt to get Claude to use tmux to do this reliably.
I tell Claude code to use an existing tmux session to interact with eg a rails console, and it uses tmux send-keys and capture-pane for IO. It gets tripped up if a pager is invoked, but otherwise it works pretty well. Didn’t occur to me to tell it to take screenshots.
For Claude, it's enough to prompt "use tmux to test", that usually does the work out of the box. If colors are important I also add "use -e option with capture-pane to see colors". It just works. I used it regularly with Claude and my TUI. For other agents other than Claude I need to use a more specific set of instructions ("use send-keys, capture-pane and mouse control via tmux" etc.)
Since I have e2e tests, I only use the agent for: guiding it on how to write the e2e test ("use tmux to try the new UI and then write a test") or to evaluate its overall usability (fake user testing, before actual user testing): "use tmux to evaluate the feature X and compile a list of usability issues"
Also many CLIs act differently when invoked connected to a terminal (TUI/interactive) vs not. So you’d run into issues there where Claude could only test the non-interactive things.
