Look at the landing site for the book. The article and book are vibe-written. This is alarming for material meant to market a book.

Count the number of times it brags about a specific quantity.

Count the number of false insights, sentences made to elevate the obvious into the profound.

Count the number of em dashes. Count the number of times an inanimate object or verb is used as a noun. Observe the textbook Claude design, full of glows and embodying all the worst aspects of web 2.0 landing page culture.

https://open-and-async.com/

> Fun isn’t a distraction—it’s a retention strategy. Self-care isn’t weakness; it’s operational discipline

> The book in one page / The playbook, start to finish / Ten parts, each building on the last. Here’s the path.

The most alarming part is it appears Ben either did not bother to review and edit the content, or was not adept enough to recognize it as deficient. That didn't prevent them from posting it directly to hacker news via their own account without even a Show HN. They consider this material to be ready for an audience and that's concerning to me.

Yours instantly! 576 pages!

It's so very clear why he thought it was a good idea to have a regex validator to check that he doesn't imply he still works at Github.

"i dont work at github"

"Yes, you're absolutely right. I apologize for the mistake and have edited the document accordingly.

reads War and Peace system prompt

Here is how we can programmatically and scientifically avoid this problem in the future:

1. Add to the regex validator library: We can add to the regex validator library an additional entry to catch any future instances of this mistake. This is a low-cost, high-yield approach---regex runs with deterministic and repeatable results, with the added benefit that its big-O runtime scales at most linearly with the size of the text for most use cases (Hartmann, 2018).

*Three other braindead ideas*

Which future-proofing strategy shall we take?"

"sure 1"