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

[4] Meta Internal Evidence Exhibit 45

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.

Yep, and no ISO 27001 or SOC II, nor is the location of the country of operation disclosed, let alone any name associated with it.

I remember about 20 years ago writing a relatively simple tool in perl with IMAP::Client to migrate a Universities staff mail from Courier (I think) to Communigate Pro, and then another one to migrate from Communigate Pro to Microsoft Exchange a few years later.

I was at the beginning of my career. It was pretty easy. Went almost flawlessly, moving thousands of peoples email.

Where is the "painful" part? It's just moving blobs of text around.

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.

> Early in the development process, when testing the incomplete application, I remembered that Subversion (the version control system after CVS, before Git) had a –dry-run option.

> I remembered how helpful that was, so I decided to add it to my command as well.

He mentions the reason he added it, and it's a compelling enough story to be true.

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.

I had the equivalent of --dry-run in my kdecvs-build script from 2003 (where it was called --pretend) so it's not that spontaneous an idea that it must have been dreamed up by an AI.

Any time you have a script that needs to run for a long time or might involve destructive actions, having a way to run the script in a "tell me what you would do without actually doing it" mode is a fairly obvious user story to throw in.

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.

And my point is simply that if it were obvious enough an idea that I thought of it after initially using my tool, you probably will want to look for more realistic examples of where a person thinks they came up with an idea that was really prompted back to them in an AI chat.

This isn't something with surprising nuance like how a McDonald's milkshake serves a non-food "job to be done" during a shopper's morning commute. As evidenced by all the others in this thread pointing out other tools that do similar things, it's a fairly obvious idea to come up with after actually using a new tool.

You'd be more likely to learn about it doing product comparisons of other tools, although since there is a lot of common art for AI training to draw from, yes it is also possible to hear about it from your AI first.

Oh, to be clear, I have a team of amazing humans and Claude working with me!

Not sure what your issue is.

It's very common to say that it's my product. He also clearly stated that 'from the team '

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.

Hard disagree from me there. I don’t care what language a tool is built with, I’m neither interested in their choice of code editor, nor whether they use AI in the process or not. It’s a means to an end, not some flaw to be ashamed of and forced to disclose.

If something gets built with AI or not at all, that’s a net positive as far as I’m concerned.

I care. Plenty of people care. You are free to ignore that piece of the readme.

Point is I don’t want people to get shamed for their tools over some vague idea of intellectual purity.

Point is I do

Thanks, appreciate the thoughtful feedback.

You’re right that the commit history doesn’t fully reflect the raw development process. I did some cleanup and squashing before publishing, since this is an open-source project and I wanted the history to be readable and reviewable.

I do use coding assistants as part of my workflow, mostly for iteration speed and boilerplate, but the architectural decisions, evaluation logic, and compliance mapping are intentional and manually reasoned through.

Happy to clarify any part of the implementation or assumptions if something looks odd.

Is there a reason why you're using LLMs for comments as well?

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.

I’ve seen a lot of articles like this on the HN page recently… stuff that has one or two interesting tidbits, but is clearly just a conversation someone had with an AI and dumped into an article. Don’t make me wade through all the AI word barf to get the interesting points, that’s what old fashioned editing is for.

This is the longest article I read in its entirety this month so it can't be that bad. Maybe because I actually was interested in the details.

Did you read his conclusion?

"I wrote this entire article in the Claude Code interactive window. The TUI flash (which I've read is a problem with the underlying library that's hard to fix) is really annoying, but it's a really nice writing flow to type stream of consciousness stuff into an editor, mixing text I want in the article, and instructions to Claude, and having it fix up the typos, do the formatting, and build the UX on the fly.

Nearly every word, choice of phrase, and the overall structure is still manually written by me, a human. I'm still on the fence about whether I'm just stuck in the old way by preferring to hand-craft my words, or if models are generally not good at writing.

"

Either he's lying, or you're wrong.

Agree on the structure part. I mostly read it as a piece from someone who's having fun with the tool. Not a structured article for future generations.

very