The true state of things is that the anti-AI folks are FAR more vocal about their opposition, meanwhile, the people who like AI are busy being productive and accomplishing a truly staggering amount of work.
The 84% stack overflow "currently use AI" number from a _year_ ago almost certainly still holds true today. Just look at the absurdly long and very incomplete list of "tainted by AI" projects that the list-making activists are maintaining over on Codeberg. Software is not "divided", it is simply being occupied by angry protesters.
Hacker news skews significantly older and whiter, and the blogs and such that circulate come primarily from the "established" English-speaking old-guard "white people" software days. Opposition to AI is highly concentrated among the white, first world, left-wing, established engineers.
This group punches far their weight in terms of the volume of their activism compared to the actual percentages of humans on earth.
That's all it is. Anti-AI hatred is just a noisy echo-chamber of those who are privileged enough to not need to modernize their skills.
I'd push back a bit on the assumptions here, partly because (as I just spent a rabbit hole's worth of time describing: https://news.ycombinator.com/item?id=48427800), such perceptions are strongly conditioned by one's pre-existing feelings, but more because (to my view at least) HN obviously is divided on AI. That is, HN gets plenty of comments criticizing AI for various reasons, and plenty of comments expressing positive views too. https://news.ycombinator.com/item?id=48406174 has almost 1000 comments now, and by far most are positive.
You make a good point about the asymmetry in content: the negative ones are mostly just critical, and often denunciatory, while the positive ones are less likely to be generic, and more likely to be about specific work people are doing. That's not a new dynamic, though, and long pre-dates what today is called AI.
Right, of course it's those who had the most time to accumulate wealth in the wealthier nations and professions who are most opposed to one of the most expensive subscriptions in history taking over more and more professions.
How good do you want it to be? For a close to ChatGPT today (April, 2026), you're still looking at a system with 7xH200+chassis, which will run you $300, or a GB200 NV72, which is $2-3 million. OTOH, a Qwen3.6 quantized model can be run on $10,000 (high end Mac) or $1,000 (Mac mini) worth of hardware. Even a Pixel 10 Pro cellphone ($1,000) can run useful models locally.
Go to Open Router, ask your own in investigative prompt that meets your needs to all the top open models. See how they do. Then notice if you can run any of those locally. Repeat at least once a month.
It can be quite expensive to get the models and machines to do this.
That's what the money pays for when the Comment above mentions
'that you might have to eventually pay an AI company a large amount of money to ask ChatGPT such a question'
Putting aside that it won't be a large amount of money For any particular query , that's how the AI companies see themselves, not as providers of information, but as providers of mechanisms that provide information. It is not selling the Information of others, it isn't selling information at all. They are selling the service of running the mechanism.
I'm somewhat confused as to why this is on the front page. It doesn't go into any real detail, and the advice it gives is... not good. You should definitely not be quantizing your own gguf's using an old method like that hf script. There are lots of ways to run LLMs via podman (some even officially recommended by the project!). The chip has been out for almost a year now, and its most notable (and relevant-to-AI) feature is not mentioned in this article (it's the only x86_64 chip below workstation/server grade that has quad-channel RAM-- and inference is generally RAM constrained). I'm also quite puzzled about this bit about running pytorch via uv.
Anyway. I wouldn't recommend following the steps posted in there. Poke around google, or ask your friendly neighborhood LLM for some advice on how to set up your Strix Halo laptop/desktop for the tasks described. A good resource to start with would probably be the unsloth page for whichever model you are trying to run. (There are a few quantization groups that are competing for top-place with gguf's, and unsloth is regularly at the top-- with incredible documentation on inference, training, etc.)
Anyway, sorry to be harsh. I understand that this is just a blog for jotting down stuff you're doing, which is a great thing to do. I'm mostly just commenting on the fact that this is on the front page of hn for some reason.
Thanks for writing this comment, I think seeing someone’s “first impressions” and then seeing someone else’s response to those thoughts is more interesting and feels more connected socially than just reading a “correct” guide or similar especially when it’s something I’m curious about but wouldn’t necessarily be motivated enough to actually try out myself.
Quad-channel RAM is common on consumer desktops. Strix Halo has *8* channels, and also very fast RAM (soldered RAM can be faster than dimms because the traces are shorter.)
Quad channel memory is not common on consumer desktops, it's a strictly HEDT and above feature. The vast majority of consumer desktops have 2 channels or fewer.
One should no longer use the word "channel" because the width of a channel differs between various kinds of memories, even among those that can be used with the same CPU (e.g. between DDR and LPDDR or between DDR4 and DDR5).
For instance, now the majority of desktops with DDR5 have 4 channels, not 2 channels, but the channels are narrower, so the width of the memory interface is the same as before.
To avoid ambiguities, one should always write the width of the memory interface.
Most desktop computers and laptop computers have 128-bit memory interfaces.
The cheapest desktop computers and laptop computers, e.g. those with Intel Alder Lake N/Twin Lake CPUs, and also many smartphones and Arm-based SBCs, have 64-bit memory interfaces.
Cheaper smartphones and Arm-based SBCs have 32-bit memory interfaces.
Strix Halo and many older workstations and many cheaper servers have 256-bit memory interfaces.
High-end servers and workstations have 768-bit or 512-bit memory interfaces.
It is expected that future high-end servers will have 1024-bit memory interfaces per socket.
GPUs with private memory have usually memory interfaces between 192-bit and 1024-bit, but newer consumer GPUs have usually narrower memory interfaces than older consumer GPUs, to reduce cost. The narrower memory interface is compensated by faster memories, so the available bandwidth in consumer GPUs has been increased much slower than the increase in GDDR memory speed would have allowed.
Sadly motherboards, tech journalist, and many other places confuse the difference between a dimm and channel. The trick is the DDR4 generation they were the same, 64 bits wide. However a standard DDR5 dimm is not 1x64 bit, it's actually 2x32 bit. Thus 2 DDR5 dimms = 4 channels.
For some workloads the extra channels help, despite having the same bandwidth. This is one of the reasons that it's possible for a DDR5 system to be slightly faster than a DDR4 system, even if the memory runs at the same speed.
>However a standard DDR5 dimm is not 1x64 bit, it's actually 2x32 bit. Thus 2 DDR5 dimms = 4 channels.
Uh, surely that depends on how the motherboard is wired. Just because each DIMM has half the pins on one channel and the other half on another, doesn't mean 2 DIMM = 4 channels. It could just be that the top pins over all the DIMMs are on one channel and the bottom ones are on another.
I think there's a standard wiring for the dimm and some parts are shared. Each normal ddr5 dimm has 2 sub channels that are 32 bits each, and the new specification for the HUDIMM which will only enable 1 sub channel and only have half the bandwidth.
I don't think you can wire up DDR5 dimms willy nilly as if they were 2 separate 32 bit dimms.
Well, I don't know what to tell you. I'm not a computer engineer, but I assume Gigabyte has at least a few of those, and they're labeling the X870E boards with 4 DIMMS as "dual channel". I feel like if they were actually quad channel they'd jump at the chance to put a bigger number, so I'm compelled to trust the specs.
In computer manufacture speak dual channel = 2 x 64 bit = 128 bits wide.
So with 2 dimms or 4 you still get 128 bit wide memory. With DDR4 that means 2 channels x 64 bit each. With DDR5 that means 4 channels x 32 bit each.
Keep in mind that memory controller is in the CPU, which is where the DDR4/5 memory controller is. The motherboards job is to connect the right pins on the DIMMs to the right pins on the CPU socket. The days of a off chip memory controller/north bridge are long gone.
So if you look at an AM5 CPU it clearly states:
* Memory Type: DDR5-only (no DDR4 compatibility).
* Channels: 2 Channel (Dual-Channel).
* Memory Width: 2x32-bit sub-channels (128-bit total for 2 sticks).
Why are you quoting something that contradicts you? It clearly states it's a dual channel memory architecture with 32-bit subchannels. The fact the two words are used means they mean different things.
>In computer manufacture speak dual channel = 2 x 64 bit = 128 bits wide.
Yes, because AMD64 has 64-bit words. You can't satisfy a 64-bit load or store with just 32 bits (unless you take twice as long, of course). That you get 4 32-bit subchannels doesn't mean you can execute 4 simultaneous independent 32-bit memory operations. A 64-bit channel capable of a full operation still needs to be assembled out of multiple 32-bit subchannels. If you install a single stick you don't get any parallelism with your memory operations; i.e. the system runs in single channel mode, the single stick fulfilling only a single request at a time.
AM5 is the AMD standard, it's accurate, seems rather pedantic to differentiate between 2 sub channels per dimm and saying 4 32 bit channels for a total of 128 bit.
However the motherboard vendors get annoyingly hide that from you by claiming DDR4 is dual channel (2 x 64 bit which means two outstanding cache misses, one per channel) and just glossing over the difference by saying DDR5 dual channel (4 x 32 bit which means 4 outstanding cache misses).
> Yes, because AMD64 has 64-bit words.
It's a bit more complicate than that. First you have 3 levels of cache, the last of which triggers a cache line load, which is 64 bytes (not 64 bits). That goes to one of the 4 channels, there's a long latency for the first 64 bits. Then there's the complications of opening the row, which makes the columns available, which can speed up things if you need more than one row. But the general idea is that you get at the maximum one cache line per channel after waiting for the memory latency.
So DDR4 on a 128 bit system can have 2 cache lines in flight. So 128 bytes * memory latency. On a DDR5 system you can have 4 cache lines in flight per memory latency. Sure you need the bandwidth and 32 bit channels have half the bandwidth per clock, but the trick is the memory bus spends most of it's time waiting on memory to start a transfer. So waiting 50ns then getting 32bit @ 8000 MT/sec isn't that different than waiting 50ns and getting 64 bit @ 8000MT/sec.
Each 32 bit subchannel can handle a unique address, which is turned into a row/column, and a separate transfer when done. So a normal DDR5 system can look up 4 addresses in parallel, wait for the memory latency and return a cache line of 64 bytes.
Even better when you have something like strix halo that actually has a 256 bit wide memory system (twice any normal tablet, laptop, or desktop), but also has 16 channels x 16 bit, so it can handle 16 cache misses in flight. I suspect this is mostly to get it's aggressive iGPU fed.
Yes, but tablets, laptops, and normal (non-HEDT) desktops have 4 channels, 4x32 bit = 128 bit wide. Modern memory with DDR5 allows two 32 bit channels on a 64 bit dimm. The previous gen DDR4 would allow 1 64 bit channel on a 64 bit dimm.
So strix halo (on laptops, tablets, and desktops) allows for a 256 bit wide memory system, providing twice the memory bandwidth of any ryzen or intel i3/i5/i7/i9. The Apple pro (256 bit), max (512 bit), and ultra (1024 bit) lines of apple silicon have greater than 128 bit wide memory systems. On the AMD size it's just the Threadripper (256 bit) and Threadripper pro (512 bit), but those are typically in expensive workstations that are physically large, expensive, and need substantial cooling.
So the HALO is pretty unique (outside of Apple) for providing twice the memory bandwidth of anything else that fits in the tablet, laptop, or small desktop category.
Just another case of Apple intentionally going against established open standards to price gouge their users.
I wouldn't mind it as much if I didn't have to hear said users constantly moaning in ecstasy about just how much better "Apple's way" is.
High quality desktop Linux has been made real by KDE, and the AI-fueled FOSS development boom is accelerating this eclipse of proprietary nonsense like this.
If you're a developer, you should be using a system that isn't maintained by a company that intentionally stabs developers in the back at every turn. (Unless you're into that. U do u.)
Sometimes you can just tell something's off. No exclamation mark, double dash instead of an emdash. Human-slop on my HN? This place is becoming more and more like Reddit, I swear!
Yeah, i’ve gone to the point where I will just stop reading AI posts after a paragraph or two if there are no specifics. The “it works!” / “no it doesn’t” genre is saturated with generality. Show, don’t tell, or I will default to believing you don’t have anything to show at all.
That was very vague, but I kinda get where they're coming from.
I'm now using pi (the thing openclaw is built on) and within a few days i build a tmux plugin and semaphore plugin^1, and it has automated the way _I_ used to use Claude.
The things I disagree with OP is: The usefulness of persistent memory beyond a single line in AGENTS.md "If the user says 'next time' update your AGENTS.md", the use of long-running loops, or the idea that everything can be resolved via chat - might be true for simple projects, but any original work needs me to design the 'right' approach ~5% of the time.
That's not a lot, but AI lets you create load-bearing tech-debt within hours, at which point you're stuck with a lot of shit and you dont know how far it got smeared.
They're not coming from anywhere. It's an LLM-written article, and given how non-specific it is, I imagine the prompt wasn't much more than "write an article about how OpenClaw is changing my life".
And the fact this post has 300+ comments, just like countless LLM-generated articles we get here pretty much daily... I guess proves the point in a way?
That’s another reason there just isn't any point in looking at these articles anymore unless they take you on a trip deep in the weeds of some specific problem or example. We need deep case studies (pro and con), not bulleted lists and talking points.
My agents get auto-injected with the core spec via pi-extention.
I have an idea, agent turns it into a draft, depending on idea vagueness/complexity combination of: Looking for alternative, plan the change, look for alternative, split up into smaller drafts to drive separately, execute change (spec, code, tests), review change.
Usually its just: Draft, plan, exec, commit. The steps are flexible enough. Usually each step is a different agent, sometimes not. On complex builds or big changes, a planning agent itself might spawn subagents to avoid bloating its own context.
The progress is stored in: ./dev/{draft/<n>.md , wip/<n>/, fin/<n>/ }.
My `lead` pi has a separate AGENTS.md with how to organize the above sequence, and some notes on how to prompt, keep things small, etc. Note that its skill `tmux-coding-agrents` calls other pi instances (optionally set to codex). I've moved off the claude cli entirely.
I used to spend time telling claude not to forget updating the specs or building its tests because context bloat made them forget AGENTS.md, or to read certain files before it should execute a plan. The lead agent does this just fine now, and every time i see it make a mistake i say: "Next time do X" and it automatically updates its own or the worker agents AGENTS.md.
Because my lead agent context is all about managing this process it doesn't forget steps while its off chasing some bug.
Also, I build (but did not publish) a pi plugin that attempts to use other accounts on usage limits.
Most surprising moment I had, was my lead spawning a subagent, spawning a subagent, which spawned a tmux-bash build with very little prompting, and it was the right thing to do to prevent each agent from context bloat.
Thanks for the write up. I'm starting to consider enhancing my setup and building on pi sounds interesting. I have a similar core workflow, but I'm still tied to CC's interface and I can see how it might be nice to have something a bit more custom.
- the smaller context and default-off for thinking make it extremely fast (thinking is a dead-end bitter lesson imo)
- the source is available; and organized specifically to make it easy for agents to write and test extensions. Just launch pi in the pi-mono directory, and it will turn your idea into an extension in no time.
There is no code, there are no tools, there is no configuration, and there are no projects.
This is an AI generated post likely created by going to chatgpt.com and typing in "write a blogpost hyping up [thing] as the next technological revolution", like most tech blog content seems to be now. None of those things ever existed, the AI made them up to fulfill the request.
> There is no code, there are no tools, there is no configuration, and there are no projects.
To add to this, OpenClaw is incapable of doing anything meaningful. The context management is horrible, the bot constantly forgets basic instructions, and often misconfigures itself to the point of crashing.
There is zero evidence this is the case. You are making up baseless accusation, probably due to partisan motivations.
edit: love the downvotes. I guess HN really is Reddit now. You can make any accusation without evidence and people are supposed to just believe it. If you call it out you get downvoted.
It doesn’t work like that. The burden is on the person making the claim. If you are going to accuse someone of posting an AI-written article you need you show evidence.
It's a losing strategy in 2026 to assume by default that any questionable spam blog/comment/etc content is written by an actual human unless proven otherwise.
Besides, if there are enough red flags that make it indistinguishable from actual AI slop, then chances are it's not worth reading anyway and nothing of value was lost by a false positive.
What evidence are you expecting exactly? It's vacuous AI slop that spends 1000 words just making vague assertions about how incredible OpenClaw is without a single actual example. There's nothing here, it's not real. You are going to struggle going forward if you can't detect AI slop this obvious.
Exactly. Posts that say "I got great results" are just advertisements. Tell me what you're doing that's working good for you. What is your workflow, tooling, what kind of projects have you made.
>Over the past year, I’ve been actively using Claude Code for development. Many people believed AI could already assist with programming—seemingly replacing programmers—but I never felt it brought any revolutionary change to the way I work.
Funny, because just last month, HN was drowning in blog posts saying Claude Code is what enables them to step away from the desk, is definitely going to replace programmers, and lets people code "all through chatting on [their] phone" (being able to code from your phone while sitting on the bus seems to be the magic threshold that makes all the datacenters worth it).
Yeah… I'm using Claude Code almost all day every day, but it still 100% requires my judgment. If another AI like OpenClaw was just giving the thumbs up to whatever CC was doing, it would not end well (for my projects anyway).
Yes. Programmers might be especially susceptible precisely because our advanced understanding makes us think we cannot be easily fooled.
But we are also easier to impress: only we understand how difficult it is to one-shot code a working app.
AI psychosis sets in when AI captures enough of your perception to alter your reality. Programmers might be "smarter", but we give AI a bigger set of tools to capture our perception with.
And then there's the fact that we want to be fooled.
We are also used to prioritizing "flow states" as part of our engagement with technology, and these tools seem to be flow-state inducers. Also prone to following hype, used to typing words into computers to get results, etc...
"Flow-state inducers" is interesting, and I think you're onto something. There's something so satisfying about getting working code so easily, feeling like you're jumping from one solution to the next.
Did they even end up launching and maintaining the project? Did things break and were they able to fix it properly? The amount of front-loaded fondness for this technology without any of the practical execution and follow up really bugs me.
It's like we all fell under the spell of a terminal endlessly printing output as some kind of measurement of progress.
It makes me sad that there are so many of these heavily-upvoted posts now that are hand-wavey about AI and is itself AI-generated. It benefits everyone involved except people like me who are trying to cut through the noise.
He goes on about putting a mass driver on the moon for ultra-low-cost space launches.
His plan here clearly hinges around using robots to create a fully-automated GPU manufacturing and launch facility on the moon. Not launching any meaningful number from earth.
Raises some big questions about whether there are actually sufficient materials for GPU manufacture on the moon... But, whatever the case, the current pitch of earth-launches that the people involved with this "space datacenter" thing are making is a lie. I think it just sounds better than outright saying "we're going to build a self-replicating robot factory on the moon", and we are in the age of lying.
If any single country tried to create a whole production chain to single-handedly manufacture modern computer equipment it would be on the order of decades to see any result. Doing it on the moon is just not realistic this century, maybe the next one. Although i don't think the economics would ever work out.
The true state of things is that the anti-AI folks are FAR more vocal about their opposition, meanwhile, the people who like AI are busy being productive and accomplishing a truly staggering amount of work.
The 84% stack overflow "currently use AI" number from a _year_ ago almost certainly still holds true today. Just look at the absurdly long and very incomplete list of "tainted by AI" projects that the list-making activists are maintaining over on Codeberg. Software is not "divided", it is simply being occupied by angry protesters.
Hacker news skews significantly older and whiter, and the blogs and such that circulate come primarily from the "established" English-speaking old-guard "white people" software days. Opposition to AI is highly concentrated among the white, first world, left-wing, established engineers.
This group punches far their weight in terms of the volume of their activism compared to the actual percentages of humans on earth.
That's all it is. Anti-AI hatred is just a noisy echo-chamber of those who are privileged enough to not need to modernize their skills.
reply