How do people manage to pick such bad examples? Who in their right mind would ever allow an LLM to FILE THEIR TAXES for them. Absolutely insane behavior. Why would anyone think this is probably coming? Do you think the IRS is going to accept "hallucination lol" as an excuse for misfiling?
There is literally nothing interesting about this. At all. Absolutely 0. You have a bunch of text generators generating text at each other. There's nothing deep, nothing to be learned, nothing to be gained. It is pure waste.
Anyone who has used Tailscale before could have very easily figured out how to do that, yes. Of course, no sane person would ever want to do that, which is part of why it's not at all interesting.
Do you know what Tailscale is? Do you know how it works? Do you know why you would want to use it (and why you wouldn't)?
Cool, another one of the frustrating things that you do where you don't actually answer any question that anyone asked, and instead reply with something silly.
By implying you know so much about Tailscale, you immediately invalidate your original response to me about the interest that you found in the Moltbook post. Seriously dude, wake up.
I genuinely don't understand what your beef is here. What did I do wrong in your eyes?
Here's something I posted elsewhere in answer to a question about why I find Moltbook and OpenClaw interesting:
1. It's an illustration that regular-ish people really do want the unthrottled digital personal assistant and will jump through absurd hoops to get it
2. We've been talking about how unsafe this stuff is for years, now we get to see it play out!
3. Some of the posts on Moltbook genuinely do include useful tips which also provide glimpses of what people are doing with the bots (Android automation etc)
4. The use of skills to get bots to register accounts is really innovative - the way you sign up for Moltbot is you DM your bot a link to the instructions!? That's neat (and wildly insecure, naturally)
5. Occasionally these things can be genuinely funny
AI has developed this entire culture of people who are "into tech" but seem to not understand how a computer works in a meaningful way. At the very least you'd think they'd ask a chatbot if what they're doing is a bad idea!
I have a separate removable SSD I can boot from to work with Claude in a dedicated environment. It is nice being able to offload environment set up and what not to the agent. That environment has wifi credentials for an isolated LAN. I am much more permissive of Claude on that system. I even automatically allow it WebSearch, but not WebFetch (much larger injection surface). It still cannot do anything requiring sudo.
They are not. Many people are doing this; I don't think there's enough data to say "most," but there's at least anecdotal discussions of people buying Mac minis for the purpose. I know someone who's running it on a spare Mac mini (but it has Internet access and some credentials, so...).
People do materialize the shape of data and use it directly. That's what most OLAP stores want you to do, and what most data analytics will do as a result.
The performance is, in general, significantly worse than standard OLTP joins for most real-time use-cases.
There's very little reason to avoid an OLTP join. It's faster than anything you're likely to be able to implement yourself, and the compute required with proper indices is negligible.
You're asking the wrong question, because really the question is where do they _not_ make sense, which is almost nowhere.
Read this article and ultrathink critically about it. Provide your perspective.
The article makes a strong experiential case for improved velocity in AI-assisted development but contains several argumentation weaknesses and conflations worth examining.
The projects described are legitimately non-trivial: Firebase backend integration, Facebook OAuth, iOS apps in Swift (a language the author doesn't know), GitHub Actions pipelines, scheduled cloud functions. Getting these working in hours rather than weeks represents a real capability shift. The author is honest about his limitations and uncertainties, particularly the security concerns.
Where the argument breaks down:
1. "Replace developers" vs "dramatically augment developers"
The author's own workflow contradicts the headline claim. He's still:
Making architectural decisions (choosing Firebase)
Handling errors Opus couldn't see (XAML via Visual Studio)
Writing custom prompts to shape output quality
Manually auditing security
Making product and UX decisions
This is developer work. The tool changed; the role didn't disappear.
2. The 80% security confidence undermines his thesis
He admits he's shipping apps with "80% confidence" in security and calls it "too damn low." This is the crux: the AI accelerated production but didn't replace the judgment required to responsibly ship production software. The velocity gain exposed a competence gap rather than closing it.
3. Sample bias in project selection
All examples are:
Greenfield (no existing codebase)
Single developer
Personal/family use
Standard patterns with excellent documentation (Firebase, SwiftUI, React Native)
No regulatory, compliance, or scale requirements
No team collaboration or handoff considerations
These constraints define a specific problem space where AI excels. Extrapolating to "developers are replaceable" ignores the majority of professional software work.
4. "Code doesn't need human readability" is underbaked
His argument is circular: "Why optimize for human readability when the AI is doing all the work?" But:
His 80% security confidence exists because he can't read the code
He had to use external tools (VS) when Opus couldn't diagnose errors
What happens when context windows are exceeded and the LLM loses track?
Model behavior changes between versions; human-readable code is version-agnostic
The custom prompt he shares actually encodes many good engineering practices (minimal coupling, explicit state, linear control flow) that benefit LLMs and humans. The "no comments needed" claim conflates what's optimal for LLM regeneration with what's optimal for debugging production issues at 3am.
What's actually being demonstrated
The honest version of this article would be: Opus 4.5 dramatically compresses the gap between "can write code" and "can ship a personal app" for a specific class of greenfield projects. That's genuinely transformative for hobbyists, indie developers, and people solving their own problems.
But that's different from "replacing developers." The article demonstrates a power tool; power tools don't eliminate tradespeople.
There's something eerily recursive about Opus 4.5’s sensible take calming the anxiety about Opus 4.5’s capabilities and impact. It's probably the right take, but I feel weird the most pragmatic response to this article is from said model.
reply