> My ASUS ROG Swift PG42UQ monitor was actually where I started, because I got annoyed at the pop-up overlay that comes up every once in a while that tells me to run “pixel cleaning”. I have never intentionally run pixel cleaning on this monitor and I never will, I don’t care, and I would like for that overlay to go away forever. Maybe there’s a debug menu or something that can turn it off, or worst case we patch a branch in the firmware?
Note that this is an OLED monitor, so the "pixel cleaning" thing is probably some sort of anti-burn in feature. You could probably ask the AI to look at the firmware and describe what it does.
Yeah, you actually want to do this with monitors of that generation to make them last.
You could argue that there should be an option to disable it for people who don’t care.
Refusing to take 1 minute out of your day to learn the reason for the alert is a strange self-defeating protest next to the explanation that it was a pretty expensive monitor.
I understand what it does, I think the alert is annoying. It takes at least five minutes and automatically runs when the monitor is off. I’ve had it for a few years and have no burn in issues despite not doing this every eight hours on command.
Eh I think the monitors should just handle this automatically - mine do. I basically have no idea that they do any cleaning cycles except when I check their “advanced” menu and it says it’s run 1200 times or whatever
That is just crap UX. Sonys OLED tv-s for example do this automatically while in standby mode. On the other hand Phillips OLED tv-s also ask the user if they want to do a panel refresh.
I looked it up, his monitor does do it automatically after it's been powered off for a few minutes. He's getting the nag message because the monitor has been on and displaying a picture for over 8 hours.
Perhaps you didn't read the text you just copied and pasted, but here it is for you:
"I have never intentionally run pixel cleaning on this monitor and I never will, I don’t care, and I would like for that overlay to go away forever."
No need for ackshually, the guy is clear with what he desires. That is, by the way, the point of TFA. I want my devices to do what I want, not what a product manager wants or what a dude on hacker news wants.
The author even dropped a comment here doubling down on his intent. That is the main problem, when the smaht guys think they know better, to a pathological extent where they tell other people what they ought to do with their things .
>...the smaht guys think they know better, to a pathological extent where they tell other people what they ought to do with their things .
Not just tell, actually nag, coerce and force, often in the teeth of their own total idiocy.
"Your password needs to be between 8 and 15 characters and include an upper case letter, a symbol and a number. (And an actually good, strong password will be rejected).
See that all the time, still, in 2026. So very smaht.
>I had Claude write a tool to patch out the table entry for camera activity, fix up the integrity hash, and flash it to the camera. A quick test showed that the green LED that normally illuminates while recording no longer turned on. Horrifying!
Oof. Apple claims this is not possible for macbook cameras because the LED can't be controlled from software. Wish more manufacturers would do the same.
> I haven’t actually been brave enough to write a modified firmware to the thing yet - it’s a pretty expensive monitor - but I’ll get there at some point.
Honestly if you don't have working patches, it's really not owned.
I would love to get a better understanding of how to safely iteratively patch firmware. I bricked a router last week trying to add a TFTP boot path to the boot partition. It just sucks that it's so risky.
Relatedly, we also need good glitching tools, as some firmware even for cheap devices are not available unencrypted, and flash read is disabled...
We are NOT there yet but I hope we get there soon.
If you're prepared to get out a soldering iron and/or chip-clip, you can usually back up and restore whatever IC stores the firmware you're modifying, giving you a recovery path.
> we also need good glitching tools
There are a lot already, what do you feel is missing?
How should I learn more about how to do it, what to buy, etc ? I haven't found ChatGPT to be a good teacher about this topic, and in particular re glitching, AI will refuse to discuss specifics
I have enough basic soldering to get UART attached, but not sure what to try after that.
Equipment-wise, I currently just have a few ESP32-C3s and electronics basics kit and some basic soldering stuff.
I just reverse engineered the Supernote note file format with an agent a few weeks ago. For years the community had been asking for a document on the format. And in a few hours the agent, with 20 something file format example fixtures and 30 something prompts, was able to reverse out the format.
It would have been completely not worth the effort to do this by hand for a niche device. Now, in a few hours of effort there is working code and a doc.
While it’s impressive work from the LLM and a TS implementation is novel, there’s at least a couple of pre-existing Python REs eg. https://github.com/jya-dev/supernote-tool :)
I personally own a Supernote, but I'm not a heavy user of it. For the sake of my own curiosity, what benefits will you get out of having reverse engineered the Supernote note file format? It would be super rad to be able to move my notes between other devices, which is one big plus that comes to my mind.
> And the existence of WebUSB, WebHID, and WebBluetooth mean that for some devices, depending on the specifics of which classes are used, a moment of user indiscretion in accepting a permissions prompt could permanently backdoor one of their attached devices.
> Operating systems aren’t really equipped to work with the user to ensure that a microphone stays a microphone, and doesn’t spontaneously turn into a keyboard that hits Win+R and drops a payload to steal all your data when the room is quiet enough that it can assume you aren’t watching.
In a world of USB-C everything we no longer have power supplies that are physically bound to power delivery, HDMI or DP display connections that have constrained data channels, or analogue mics, headphones, and speakers. Any device can dynamically change what it senses, does, or emits.
This is why most of the browsers rejected these specs. They are super useful, but the security risks are incredible. Most USB devices were not designed to hold up to being exposed to the internet.
I kinda remember that the counterargument Google used is that only devices with a special attribute would ever be available through WebHID, ensuring that such older devices would never be exposed.
Cue my surprise when it turns out you can use WebHID to program a Minidisc / Net-MD device [1], so.. they never did implement that filter, apparently. I mean, certainly it is useful, but ... What The F., Google?
The user has to first specifically pick the device from the list and grant the website access. If a user is confused by a permissions prompt and has no idea what is going on, the default path is to reject the permission.
In the real world the default action for a user when presented with a permissions popup is to accept it because they get asked 20 times a day, have no idea what the implications of it are and just want to get on with their day.
So software designers need to avoid asking the users to approve potentially highly dangerous things.
You realize that most of the time that you are giving access to an older HID device, you are giving the website permission to convert that device into a persistent backdoor forever? No matter if you later close the browser or revoke the permission -- the damage has already been done? Most devices predating WebHID and the like have almost no protection (why would they?), and you can corrupt or even entirely replace the firmware quite easily. heck, NetMD is one example (the browser can overwrite its firmware with no trouble!), as are the devices listed in TFA .
It is basically the same reason most desktops do not give the logged in user access to /dev/hidraw*, even though it makes a shitton of sense and would simplify many things greatly.
This is one of the few areas where I think Mozilla did the right thing without question.
WebUSB has been live in Chrome for 9 years and nothing happened. Compare to all the features that result in people getting hacked every day. Your threat model is ridiculous.
The key takeaway for me was he bought a $300 microphone and is acting indignant that he has full access to his own hardware via — gasp — a command shell.
Do we live in a bizarro world now where we expect — no, demand — our hardware be locked down?
It's worth mentioning all USB mics are toys anyway. Analog interfaces have gone away — artificially so — now they cram them into the device.
We were already there. For most people, we are still there. For most devices (especially popular ones, with enough manufacturing volume) there's just enough hardening, downgrade prevention, encrypted or signed firmware blobs, on top of already rare reverse engineering skills and patience, to make it infeasible for most people to give it a crack. Using an LLM for that also isn't a mainstream idea either (plus you're unlikely to have a Claude subscription if you're not a software developer in the first place).
Open systems are great and all in the idea, but the facts are that for profit companies do the research and produce most of the things.
I think that this is not true -- the achievements mentioned here are hardly ground breaking and mostly build on work that was already done years before LLMs were a thing.
There are things that the "open source movement" dreams about, and one just has to search around... E.g. like codecs, Qualcomm's aptX lossless, adaptative, and other more recent variations.
It's not new capabilities, it's new levels of access. Reverse engineering this stuff used to be a very tedious process which required a lot of specialised skill. Which is why most devices haven't been reverse engineered or hacked despite being full of low hanging fruit.
There's a difference between the people sitting at the table and the mice scurrying around catching the crumbs. Freedom is sitting at the table. The OP, sadly, is catching the crumbs.
"only ever" feels like a stretch. Libratbag, QMK, OpenWRT, Nouveau and Asahi all took up the task without much or any AI help. They're not all just dreamers.
Using LLMs for RE and bug hunting is a lot of fun. Today I reported an absolute doozy of a bug to Google's VRP. The vuln was in an HTTP API endpoint I don't have the source for, only RE'd client logic.
The idea behind the bug was mine, it was of the "surely they weren't stupid enough to forget to do xyz" variety. Writing the code to probe for the vulnerability by hand would've taken a few hours of grunt work, including reconstructing protobuf schemas etc. In the past I just wouldn't have bothered, because in my view the odds of success were too low to be worth it. But it was a one-sentence prompt so why the hell not. And it worked!
I initially thought, but why would you want a "webcam whose activity LED I can switch off while it records"? But then I think I got the point: why would one want a webcam which _could be hacked_ so that its activity LED didn't go on.
I am certain if it can be “tricked” into using it with the LED off, there is certainly a feature being sold to “enterprises” where it happens on purpose.
I had used codex to reverse engineer an electric skateboard to unbrick it. It was a bit more involved because it required soldering wires directly to the UART headers in a very awkward location.
Took about 10 hours and it now works fine. Without codex, this would have taken me significantly more weekends having little experience with skateboard firmware.
This is giving me the confidence to RE my cat feeder. The company (Petlibro) has an outage and now my chilled wet feeder that should be a dumb, offline feeder is basically bricked now.
The device reports fine wifi but the backing services are totally busted.
I have one of their dry food ones and no longer need it. Sad story, but it happens.
My cat scarfed and barfed periodically, and I always wanted the Petlibro (the simple one) to slow feed by incrementally turning the auger, just to see if it helped. I might dig it out and try my hand at this.
Ah, I remember when reversing hardware took weeks / months, an oscilloscope, logic analyzer, Ghidra/IDA, Wireshark, breakout boards, wireless sniffers... back in the olden days of... 2019.
I'm hopeful that in the future we can end planned obsolescence from devices that require companion apps which eventually get shut down. Just vibe reverse engineering replacements.
The pixel cleaning warning turns out to have no native way to disable it, and it’ll always show up after 8 hours of runtime.
Come on, does anyone dog food their own products anymore? How could a single person developing the monitor actually believe consumers want to be bothered with this every day? If the hardware is really so terrible this must happen, find some way to incrementally do it silently or off hours. Anything else.
So is an actionable lesson here to favor devices that aren't USB/wifi connected if they don't have to be? Or perhaps just choose low-tech versions that don't attempt fancy features?
I have been tinkering with various firmwares of devices around the house lately as well. I have an agent hooked up to various GPIO pinouts and play lab monkey for it. Honestly they are getting better and better at exploratory research and self-supervision for these kinds of tasks and it's fun to watch. I don't often have to interject, though sometimes I do.
I watched an agent identify and find the correct firmware for a device by taking photos of its circuit boards and comparing them to those found online in internal documentation, patents, parts sheets, etc.
It's pretty fun! If you have your HAM license you can do some fun stuff letting an agemt control an SDR, too. Still a lot of fun to be had even in passive mode.
It will be interesting watching what kind of tinkerer/hacker/enthusiast cultures arises from these new paradigms. Wait til people start suping up their vehicles with natural language agents that have access to subsystems. Imagine entire automated labs hooked up to agents.
> My ASUS ROG Swift PG42UQ monitor was actually where I started, because I got annoyed at the pop-up overlay that comes up every once in a while that tells me to run “pixel cleaning”. I have never intentionally run pixel cleaning on this monitor and I never will, I don’t care, and I would like for that overlay to go away forever. Maybe there’s a debug menu or something that can turn it off, or worst case we patch a branch in the firmware?
Note that this is an OLED monitor, so the "pixel cleaning" thing is probably some sort of anti-burn in feature. You could probably ask the AI to look at the firmware and describe what it does.
Yeah, you actually want to do this with monitors of that generation to make them last.
You could argue that there should be an option to disable it for people who don’t care.
Refusing to take 1 minute out of your day to learn the reason for the alert is a strange self-defeating protest next to the explanation that it was a pretty expensive monitor.
I understand what it does, I think the alert is annoying. It takes at least five minutes and automatically runs when the monitor is off. I’ve had it for a few years and have no burn in issues despite not doing this every eight hours on command.
Eh I think the monitors should just handle this automatically - mine do. I basically have no idea that they do any cleaning cycles except when I check their “advanced” menu and it says it’s run 1200 times or whatever
They can.... which everyone bitched about: they would do their cleaning cycle, no matter if you were busy or not.
I don't think learning more about what it does is going to make them change their mind here.
That is just crap UX. Sonys OLED tv-s for example do this automatically while in standby mode. On the other hand Phillips OLED tv-s also ask the user if they want to do a panel refresh.
> You could probably ask the AI to look at the firmware and describe what it does.
Or ask for a patch so it runs after the monitor has been powered off for a while...
I use an LG OLED 42inch TV as a monitor and it has a setting to do just this.
I looked it up, his monitor does do it automatically after it's been powered off for a few minutes. He's getting the nag message because the monitor has been on and displaying a picture for over 8 hours.
Every 8 hours is insane, though
Perhaps you didn't read the text you just copied and pasted, but here it is for you:
"I have never intentionally run pixel cleaning on this monitor and I never will, I don’t care, and I would like for that overlay to go away forever."
No need for ackshually, the guy is clear with what he desires. That is, by the way, the point of TFA. I want my devices to do what I want, not what a product manager wants or what a dude on hacker news wants.
The author even dropped a comment here doubling down on his intent. That is the main problem, when the smaht guys think they know better, to a pathological extent where they tell other people what they ought to do with their things .
>...the smaht guys think they know better, to a pathological extent where they tell other people what they ought to do with their things .
Not just tell, actually nag, coerce and force, often in the teeth of their own total idiocy.
"Your password needs to be between 8 and 15 characters and include an upper case letter, a symbol and a number. (And an actually good, strong password will be rejected).
See that all the time, still, in 2026. So very smaht.
>I had Claude write a tool to patch out the table entry for camera activity, fix up the integrity hash, and flash it to the camera. A quick test showed that the green LED that normally illuminates while recording no longer turned on. Horrifying!
Oof. Apple claims this is not possible for macbook cameras because the LED can't be controlled from software. Wish more manufacturers would do the same.
> I haven’t actually been brave enough to write a modified firmware to the thing yet - it’s a pretty expensive monitor - but I’ll get there at some point.
Honestly if you don't have working patches, it's really not owned.
I would love to get a better understanding of how to safely iteratively patch firmware. I bricked a router last week trying to add a TFTP boot path to the boot partition. It just sucks that it's so risky.
Relatedly, we also need good glitching tools, as some firmware even for cheap devices are not available unencrypted, and flash read is disabled...
We are NOT there yet but I hope we get there soon.
If you're prepared to get out a soldering iron and/or chip-clip, you can usually back up and restore whatever IC stores the firmware you're modifying, giving you a recovery path.
> we also need good glitching tools
There are a lot already, what do you feel is missing?
How should I learn more about how to do it, what to buy, etc ? I haven't found ChatGPT to be a good teacher about this topic, and in particular re glitching, AI will refuse to discuss specifics
I have enough basic soldering to get UART attached, but not sure what to try after that.
Equipment-wise, I currently just have a few ESP32-C3s and electronics basics kit and some basic soldering stuff.
There are plenty of pre-2023 resources out there, especially conference talks. But, Claude has no issues discussing glitching if you have CVP.
In my experience, claude will be more than happy to help your reversing if you seed the conversation in that direction.
I just reverse engineered the Supernote note file format with an agent a few weeks ago. For years the community had been asking for a document on the format. And in a few hours the agent, with 20 something file format example fixtures and 30 something prompts, was able to reverse out the format.
It would have been completely not worth the effort to do this by hand for a niche device. Now, in a few hours of effort there is working code and a doc.
https://github.com/philips/supernote-typescript/blob/main/pl...
https://philips.github.io/supernote-typescript/
While it’s impressive work from the LLM and a TS implementation is novel, there’s at least a couple of pre-existing Python REs eg. https://github.com/jya-dev/supernote-tool :)
I personally own a Supernote, but I'm not a heavy user of it. For the sake of my own curiosity, what benefits will you get out of having reverse engineered the Supernote note file format? It would be super rad to be able to move my notes between other devices, which is one big plus that comes to my mind.
Key takeaway:
> And the existence of WebUSB, WebHID, and WebBluetooth mean that for some devices, depending on the specifics of which classes are used, a moment of user indiscretion in accepting a permissions prompt could permanently backdoor one of their attached devices.
The preceding sentence is equally prescient:
> Operating systems aren’t really equipped to work with the user to ensure that a microphone stays a microphone, and doesn’t spontaneously turn into a keyboard that hits Win+R and drops a payload to steal all your data when the room is quiet enough that it can assume you aren’t watching.
In a world of USB-C everything we no longer have power supplies that are physically bound to power delivery, HDMI or DP display connections that have constrained data channels, or analogue mics, headphones, and speakers. Any device can dynamically change what it senses, does, or emits.
This is why most of the browsers rejected these specs. They are super useful, but the security risks are incredible. Most USB devices were not designed to hold up to being exposed to the internet.
I kinda remember that the counterargument Google used is that only devices with a special attribute would ever be available through WebHID, ensuring that such older devices would never be exposed.
Cue my surprise when it turns out you can use WebHID to program a Minidisc / Net-MD device [1], so.. they never did implement that filter, apparently. I mean, certainly it is useful, but ... What The F., Google?
[1] https://web.minidisc.wiki/
The user has to first specifically pick the device from the list and grant the website access. If a user is confused by a permissions prompt and has no idea what is going on, the default path is to reject the permission.
In the real world the default action for a user when presented with a permissions popup is to accept it because they get asked 20 times a day, have no idea what the implications of it are and just want to get on with their day.
So software designers need to avoid asking the users to approve potentially highly dangerous things.
You realize that most of the time that you are giving access to an older HID device, you are giving the website permission to convert that device into a persistent backdoor forever? No matter if you later close the browser or revoke the permission -- the damage has already been done? Most devices predating WebHID and the like have almost no protection (why would they?), and you can corrupt or even entirely replace the firmware quite easily. heck, NetMD is one example (the browser can overwrite its firmware with no trouble!), as are the devices listed in TFA .
It is basically the same reason most desktops do not give the logged in user access to /dev/hidraw*, even though it makes a shitton of sense and would simplify many things greatly.
This is one of the few areas where I think Mozilla did the right thing without question.
WebUSB has been live in Chrome for 9 years and nothing happened. Compare to all the features that result in people getting hacked every day. Your threat model is ridiculous.
The key takeaway for me was he bought a $300 microphone and is acting indignant that he has full access to his own hardware via — gasp — a command shell.
Do we live in a bizarro world now where we expect — no, demand — our hardware be locked down?
It's worth mentioning all USB mics are toys anyway. Analog interfaces have gone away — artificially so — now they cram them into the device.
All mics are analog.
It's amazing to see LLMs give us software and hardware freedoms that the open source movement has only ever dreamed about.
The flip side is that this might become a thing of the past for future hardware/firmware, if AI hardening becomes standard practice.
There’s no substitute for having open systems that aren’t cryptographically locked down by the manufacturer.
We were already there. For most people, we are still there. For most devices (especially popular ones, with enough manufacturing volume) there's just enough hardening, downgrade prevention, encrypted or signed firmware blobs, on top of already rare reverse engineering skills and patience, to make it infeasible for most people to give it a crack. Using an LLM for that also isn't a mainstream idea either (plus you're unlikely to have a Claude subscription if you're not a software developer in the first place).
Open systems are great and all in the idea, but the facts are that for profit companies do the research and produce most of the things.
I think that this is not true -- the achievements mentioned here are hardly ground breaking and mostly build on work that was already done years before LLMs were a thing.
There are things that the "open source movement" dreams about, and one just has to search around... E.g. like codecs, Qualcomm's aptX lossless, adaptative, and other more recent variations.
It's not new capabilities, it's new levels of access. Reverse engineering this stuff used to be a very tedious process which required a lot of specialised skill. Which is why most devices haven't been reverse engineered or hacked despite being full of low hanging fruit.
Brings me a lot of joy to see these articles. They've inspired me to reverse engineer my laptop again.
There's a difference between the people sitting at the table and the mice scurrying around catching the crumbs. Freedom is sitting at the table. The OP, sadly, is catching the crumbs.
"only ever" feels like a stretch. Libratbag, QMK, OpenWRT, Nouveau and Asahi all took up the task without much or any AI help. They're not all just dreamers.
Using LLMs for RE and bug hunting is a lot of fun. Today I reported an absolute doozy of a bug to Google's VRP. The vuln was in an HTTP API endpoint I don't have the source for, only RE'd client logic.
The idea behind the bug was mine, it was of the "surely they weren't stupid enough to forget to do xyz" variety. Writing the code to probe for the vulnerability by hand would've taken a few hours of grunt work, including reconstructing protobuf schemas etc. In the past I just wouldn't have bothered, because in my view the odds of success were too low to be worth it. But it was a one-sentence prompt so why the hell not. And it worked!
I initially thought, but why would you want a "webcam whose activity LED I can switch off while it records"? But then I think I got the point: why would one want a webcam which _could be hacked_ so that its activity LED didn't go on.
I am certain if it can be “tricked” into using it with the LED off, there is certainly a feature being sold to “enterprises” where it happens on purpose.
I had used codex to reverse engineer an electric skateboard to unbrick it. It was a bit more involved because it required soldering wires directly to the UART headers in a very awkward location.
Took about 10 hours and it now works fine. Without codex, this would have taken me significantly more weekends having little experience with skateboard firmware.
This is giving me the confidence to RE my cat feeder. The company (Petlibro) has an outage and now my chilled wet feeder that should be a dumb, offline feeder is basically bricked now.
The device reports fine wifi but the backing services are totally busted.
Why do you have a cat when you can't be bothered to feed it yourself?
I have one of their dry food ones and no longer need it. Sad story, but it happens.
My cat scarfed and barfed periodically, and I always wanted the Petlibro (the simple one) to slow feed by incrementally turning the auger, just to see if it helped. I might dig it out and try my hand at this.
I am wondering if there is a list of “things you should learn to do with your LLM” (But not the rubbish ads youtube keeps showing me)
Reverse engineering seems a good one (ev en if his RE nix sandbox looks fairly usable, it seems like a weekend to get this working.
Ah, I remember when reversing hardware took weeks / months, an oscilloscope, logic analyzer, Ghidra/IDA, Wireshark, breakout boards, wireless sniffers... back in the olden days of... 2019.
if an AI could do it without an oscilloscope, probably a human could too.
Sidenote to the technical discussion. The article read like a Martha Wells murderbot novel to me. Fascinating.
I'm hopeful that in the future we can end planned obsolescence from devices that require companion apps which eventually get shut down. Just vibe reverse engineering replacements.
A replacement app could just send the vendor-signed image and leave the signature check to the device. Plenty useful once the official app disappears.
I remember that name from NCSSM! Cool to see you on the front page of HN.
This a fascinating security write up. I had no idea the models were this capable for reverse engineering.
I heard CISA is getting defunded. I wonder if it'll become a common assumption for Americans that all their devices are just perpetually compromised.
I'm not sure CISA ever did anything material about this problem, or was likely to in the future.
we haven't even seen the peak yet, as the author says
> Network-connected devices seem near universally fucked at this point?
The i2c over USB with no auth is just way way too common; I've also seen that on a device.
I have an LG TV with a similar problem. I think it’s supposed to pixel clean when you turn it off, and I do every night.
Yet for some reason I can’t escape these annoying pixel cleaning interruptions. Seems like a bug in the firmware.
That feels like it should only require a single person working on the product to experience and demand an immediate fix.
So is an actionable lesson here to favor devices that aren't USB/wifi connected if they don't have to be? Or perhaps just choose low-tech versions that don't attempt fancy features?
All this ownage will get shut down when manufacturers start whining to politicians and the AI companies will ask how high to jump.
The best models for reverse engineering right now are the Chinese ones. You can download them and run them unrestricted right now.
Open hardware being reverse engineered with LLM is cool.
I’d say John Deer will be among first ones requesting a halt.
It was similar with Napster vs recording companies… and then Spotify bulldozed everything with its attitude.
With LLM it could be much faster.
What's that? A law that all manufacturers need to have had a security review from one of the major AI player's AI models?
I have been tinkering with various firmwares of devices around the house lately as well. I have an agent hooked up to various GPIO pinouts and play lab monkey for it. Honestly they are getting better and better at exploratory research and self-supervision for these kinds of tasks and it's fun to watch. I don't often have to interject, though sometimes I do.
I watched an agent identify and find the correct firmware for a device by taking photos of its circuit boards and comparing them to those found online in internal documentation, patents, parts sheets, etc.
It's pretty fun! If you have your HAM license you can do some fun stuff letting an agemt control an SDR, too. Still a lot of fun to be had even in passive mode.
It will be interesting watching what kind of tinkerer/hacker/enthusiast cultures arises from these new paradigms. Wait til people start suping up their vehicles with natural language agents that have access to subsystems. Imagine entire automated labs hooked up to agents.
The larpcoding epidemic needs to be stopped
Why? Does it bother you to see people using their own devices in the ways that they want?
Technically this is Schlarpcoding.
That’s what they said when ASM was created. It’s what they said when C was created. Java. SQL. Powershell.
Programming has always been about putting more power into the tools.
Sadly, there doesn’t seem to be as much need for hardcore engineers.
holy crap how ! i'd love to jailbreak my old quest 2. its such a good device too bad about all the facebook spyware!