| ▲ | soulofmischief a day ago | ||||||||||||||||
I agree with the premise and have also learned to apply my engineering habits to other domains that I normally struggle with. It helps a lot and allows me to churn through projects that previously would have not seemed tractable. But in this article, the TLDR and first paragraph have textbook LLMisms. The landing page for the book is clearly vibecoded both in structure and copy. This is very alarming for material that is meant to market a book, which I expect to not be vibe-written. So whose book is this, actually? What otherwise could be a very useful lesson comes off as a trojan horse for automated viral marketing slop in order to promote a book which I have to assume at this point is vibe-written. To be clear, I use AI heavily in my work today, and understand the difference between AI-assisted work and vibe-coded work. This appears to fall in the latter camp. How much editorial control did you assert over this project? Where did the ideas come from? How do I know a given snippet is a well-researched fact or the product of experience, instead of an unfounded potential-hallucination? I've also been making websites for decades, Ben, and most people I know in that camp are more interested in letting their hard-earned experience elevate their output to the top of the pile in an increasingly competitive space. If this is the direction we're going in, vibe-coded marketing campaigns and vibe-coded landing pages for books that we rationally have to assume are also vibe-coded and basically a medium for Claude, then we as authors must adopt an atmosphere of clarity and transparency towards our audience. A book like this needs more information about the process so that people like me don't immediately and rationally disregard it as slop. I can see your blog goes back to 2011 so I want to give you the benefit of the doubt and a chance to explain yourself further. | |||||||||||||||||
| ▲ | benbalter 21 hours ago | parent [-] | ||||||||||||||||
Fair. The project originally started as "turn my blog into a book", with a 1:1 mapping of blog post to chapter. I got feedback early on that that wasn't landing, but if you compare the outline on the book site to my blog archive, the original posts are still there. Chapters built on an earlier post making the same argument: - Why everything should have a URL → "Why URLs?" (2015) + "Expose process through URLs" (2014) - Speak like a human → "Write corporate blog posts as a human" (2015) - Optimize for developer happiness → "On stickers and optimizing for happiness" (2015) - The zen of open and async work → "The zen of GitHub" (2015) - Lead like an engineer → "Manage like an engineer" (2023) - Rethinking management for remote teams → "Deprecate management" (2012) + "Cathedral–bazaar management" (2023) - Retool your documents → "Word vs. Markdown" (2014) + "We've been trained to make paper" (2012) - The etiquette of issues and pull requests → "Types of pull requests" (2015) + "Pull requests are a form of documentation" (2023) - Showing colleagues they're valued → "Three easy ways to show employees you appreciate them" (2017) - Choosing the right collaboration tools → "Tools of the trade" (2020) - What I wish I knew before going remote → "Eight things I wish I knew my first week at GitHub" (2016) - Career conversations → "The brag doc" (2026) - Intro to software development for non-technical roles → "GitHub for non-technical roles" (2023) And chapters that are near-verbatim descendants of a named post: - Leaders show their work → "Leaders show their work" (2022) - Work loudly → "Work loudly" (2026) - Meetings are a point of escalation → "Meetings are a point of escalation" (2023) - The Andon principle for knowledge work → "Transparency & collaboration is the Andon of knowledge production" (2023) - Engaging with dissent → "Dissenting voices" (2024) - How to 1:1 → "One-on-one playbook" (2026) - Agentic workflows → "Agentic workflows" (2026) - Why you should work asynchronously → "Why async" (2022) | |||||||||||||||||
| |||||||||||||||||