Meta acquired Moltbook, which is a social network for AI bots that was itself built by an AI bot, and which had a security breach so bad that literally anyone could impersonate any bot on it, and whose own creator cheerfully admitted he "didn't write one line of code" for it. This is going into Meta Superintelligence Labs, the unit they set up for Alexandr Wang, whom they hired from Scale AI roughly one year ago to, presumably, build superintelligence. It is not clear to me how buying a vibe-coded Reddit for chatbots gets you closer to superintelligence, but I suppose the theory is that it "opens up new ways for AI agents to work for people and businesses," which is a thing Meta actually said, out loud, to Axios
I appreciate the author taking the time to share his workflow even though I really dislike the way this article is written. My dislike stems from sentences like this one: "I’ve been using Claude Code as my primary development tool for approx 9 months, and the workflow I’ve settled into is radically different from what most people do with AI coding tools." There is nothing radically different in the way he's using it (quite the opposite) and the are so many people that wrote about their workflows (and which are almost exactly the same, here's just one example [1]). Apart from that, the obvious use of AI to write or edit the article makes it further indigestible: "That’s it. No magic prompts, no elaborate system instructions, no clever hacks. Just a disciplined pipeline that separates thinking from typing."
Anecdotally, I haven't been excited by anything published on show HN recently (with the exception being the barracuda compiler). I think it's a combination of what the author describes: surface-level solutions and projects mostly vibe-coded whose authors haven't actually thought that hard about what real problem they are solving.
I'm usually the first one to bash Facebook and its main liar in chief, but the first couple of paragraphs mix damning evidence with weak stretches (as mentioned by others here). The bad stuff is genuinely bad enough.
Meta's own research found Instagram worsened body image for 1 in 3 teen girls [1]. They killed a deactivation study when results looked bad, with one employee comparing it to tobacco companies burying research [2]. They had a 17-strike policy for accounts involved in sexual solicitation [3]. And they ran growth strategies explicitly targeting kids under 13, segmenting youth into "Kid (6-10), Tween (10-13), and Teen 13+" [4].
[1] 2019 Instagram slide presentation, "Teen Mental Health Deep Dive"
[2] Meta internal deactivation study (unnamed employee quote from unsealed docs)
[3] Testimony of Vaishnavi Jayakumar, former Instagram Head of Safety and Well-being
Honestly, well done and thanks for sharing it. I also really appreciate the fact that you included multiple screenshots of the UI, as well as some of the agent plans. Reading the code and project structure, it feels like you put in the work.
Email migration is genuinely painful and I am sure there's a real market here, so I am not trying to discourage you. But why should I trust a third party with my IMAP credentials?
"Credentials encrypted in memory only and deleted immediately after migration".
I have no way to audit/verify this claim. You're essentially asking users to hand over the keys to their entire email history on faith.
Again, it's completely possible that OP and you are the wonderful exceptions (untouched and uninspired by coding agents) that have been using these patterns for as long as you can remember. My comment revolved around the psychological phenomenon, not whether dry-run is a clever/novel idea. It's about how we might tell ourselves stories about the origin of our ideas when working with those tools.
Of course and I am not trying to point fingers. But I do think it's interesting because it's also possible that it is confabulation. Not lying, but genuinely constructing coherent explanations for decisions whose true origins are different than we recall. I think working with coding agents has already made this immensely more common.
From the article: "I added –dry-run on a whim early on in the project. I was surprised at how useful I found it to be."
Not to be overly critical (I think it's great OP found value in adding and using --dry-run), but I am willing to bet that this was a suggestion/addition from a coding agent (and most likely Claude code/Opus). Having used it myself to build various CLI tools in different languages, it almost always creates that option when iterating on CLIs. To the point where it's almost a tell. I wonder if we're entering a moment of convergence where all the tools will have similar patterns/options because they are similarly written by agents.
It's great and reassuring to know that, in this day and age, products still get made entirely by one individual.
> Hi, Felix from the team here, this is my product - let us know what you think.
> We're on purpose releasing this very early, we expect to rapidly iterate on
> it.
> (We're also battling an unrelated Opus 4.5 inference incident right now, so
> you might not see Cowork in your client right away.)
Hey there! I find the idea super relevant and I think compliance tools that can be used like this are the way forward.
Given the timeline of the commits and some other tells (e.g. using forwardRef despite using React 19 which deprecates it), it seems like you used coding assistants extensively. That's a personal preference, but I would mention that explicitly (if that's the case), if only for intellectual honesty.
The irony of an article defending vibe coding that reads like it was vibe-written. The four "Why do we want X code?" paragraphs all end with the same sentence, the headers follow a neat structure no human would naturally land on, and it wraps up with a safely noncommittal "is this good or bad? Depends on who you are."
I long for articles that have been written in more time that it takes to read them.
The D-U-N-S requirement is the real killer here. It's a business identifier that costs money and requires a registered business entity. Even with the promised 'student/hobbyist' path, this fundamentally changes Android from a platform where anyone can distribute software to one where Google decides who's allowed to code. They're further normalizing the idea that installing software requires permission.
This article feels like it was written as a dialectical exercise between an AI and a human. It would probably benefit from some more heavy human editing to make it more succinct and to give the overall article a structure. As it is, it's very difficult to follow along.
Being "100% subject to European law" doesn't override the parent company's obligations under US law. At best, it creates a legal conflict where AWS must violate either US or EU law. Which one will the US parent company prioritize if/when faced with enforcement actions?
The only way this would work is if the European operation were truly independent & separately owned, no corporate control from the US. But I don't think that's what AWS is proposing.
AWS claims their cloud is "sovereign" and "independent" while remaining owned by a US corp subject to US law (including the CLOUD Act). That's not how sovereignty works.
EU citizen operators don't change the fact that the underlying technology, patents, and corporate control remain American.
Zero details on pricing, available services, or how they'll handle conflicts between US law and their "sovereignty" promises. For something launching next year, that's concerning.
You raise a valid point about ex ante uncertainty. We can't know future outcomes with certainty, and yes, Figma theoretically could have failed.
But antitrust analysis isn't about predicting exact valuations. It's about market structure and competitive dynamics. The FTC had observable facts: Adobe's dominant market share, Figma's rapid growth trajectory, and a purchase price of 50x revenue (extraordinary even for software).
These factors suggested Adobe saw Figma as a competitive threat worth eliminating, not just a financial investment. That's the key distinction from your dice game; this wasn't pure randomness but observable market dynamics.
You're right that we can't prove the counterfactual. But antitrust law doesn't require certainty, just reasonable probability of competitive harm. The extreme premium Adobe offered was itself evidence they valued removing competition more than acquiring assets.
The outcome validates the analysis, but even if Figma had struggled, preserving the possibility of competition has value beyond any single company's success.
I think you're hitting the real divide here. Some people are so ideologically opposed to any regulatory intervention that they can't admit when it works, even when the evidence is staring them in the face. Also notable [0]: "[...] in any given year, we see up to 3,000 merger filings that get reported to us. Around 2% of those actually get a second look by the government, so you have 98% of all deals that, for the most part, are going through. Around 2% of those actually get a second look by the government, so you have 98% of all deals that, for the most part, are going through." The FTC wasn't blocking everything, just the deals that would entrench monopolies.
I think the Figma IPO proves Khan was right. $60B market cap today vs the $20B Adobe offered in 2023.
There was some criticism about regulatory overreach when the deal got blocked. Now Figma employees are rich, the design tools market stays competitive, and we have another major independent tech company instead of just another Adobe product line.
This is exactly why we need regulators willing to tell Big Tech "no" sometimes. Competition creates more value than consolidation.
Instead of arguing about tab management and rendering performance, we should be asking what does a healthy browser ecosystem look like in five years? Do we want 95% of users on browsers controlled by advertising companies (Google), hardware manufacturers optimizing for their own services (Apple), or cloud providers with obvious conflicts of interest (Microsoft)?
Firefox's technical quirks are fixable. The uncomfortable reality is that true browser independence might require something Mozilla has consistently failed to achieve: sustainable revenue that doesn't depend on surveillance capitalism. Until that happens, we're choosing between degrees of corporate control, not between freedom and captivity.
This isn't really about cost savings, it's about control. Self-hosting makes sense when you need data privacy, custom fine-tuning, specialized models, or predictable costs at scale. For most use cases requiring GPT-4o-mini quality, you'll pay more for self-hosting until you reach significant volume.
There is a pretty graphic/emotionally-charged image in the article (I understand it's part of nature), for those who might not have the strength to see something like that today.
This Leipzig ruling is notable, but the practical impact may be more limited than the €5,000 figure suggests. While the court explicitly said users don't need to prove individual damages to sue, European class action mechanisms are still quite different from US-style litigation.
Germany doesn't have the same litigation incentive structures as the US - no contingency fees, loser-pays costs, and relatively limited collective redress options. Most German consumers aren't going to file individual €5,000 lawsuits over tracking pixels, especially given the legal costs and time involved.
Personally, I hope this gets picked up by a consumer protection organization or a well-funded litigation group. Germany has been gradually expanding its collective action framework, but it's still primarily driven by qualified entities rather than individual plaintiffs.
I really enjoyed the way this post was written, i.e. it includes the code, how it was run, the false paths, etc. You almost get to live through the author's journey and how he figured out just enough to get something working.
Absolutely love mine (Framework 13") and have been running either Arch or Ubuntu for the last 3 years. As mentioned elsewhere, I also had an issue with the charging cable but that is the only problem in three years of constant use. Otherwise works as expected and I was able to run everything on the hardware.
From personal experience a few years back, OVH support was one of the worst I have ever experienced in my career. Technical incompetence at multiple levels of the chain (e.g lack of understanding of how DNS works). I would never recommend it to anyone, not even my worst enemy.
"Almost no virus is protective against allergic disease or other immune diseases. In fact, infections with viruses mostly either contribute to the development of those diseases or worsen them.
The opposite is true of bacteria. There are good bacteria and there are bad bacteria. The good bacteria we call commensals. Our bodies actually have more bacterial cells than human cells. What we’ve learned over the years is that the association with family life and the environment probably has more to do with the microbiome. So one thing I would say is sanitizing every surface in your home to an extreme is probably not a good thing. Our research team showed in animals that sterile environments don’t allow the immune system to develop at all. We don’t want that."
Congratulations on releasing your product! It looks super interesting. Some questions from the top of my head:
- Where is the data stored geographically? (US, EU, or a specific country)
- Do you plan on having multiple options for the web version (cloud vs self-hosted)
I find that data sovereignty is very important to me (it might not be for everyone), which is why I ask about those points specifically ;)
If you spend time reading the article, you can agree or disagree with his choices, but he provides several reasons for why he chose to rewrite in Rust over after the initial project was written in C:
"At that moment, I decided to switch to Rust (my first project in this language), which represented several advantages:
- Restart the project from the beginning, using lessons learned from previous mistakes
- Be a bit more innovative than just writing a Linux-like kernel in C. After all, just use Linux at that point
- Use the safety of the Rust language to leverage some difficulty of kernel programming. Using Rust’s typing system allows to shift some responsibility over memory safety from the programmer to the compiler."
Unfortunately, your comment doesn't add anything to the conversation and distracts from the interesting project being presented.