# Why I Stopped Writing Step-by-Step Tutorials (And What I Do Instead) Hello All, Today I want to share something a little different — not a setup guide, not a deep dive, but a realisation that changed how I'm going to write this blog from now on. ## It Started with a Performance Test I spent today building a proof-of-concept observability setup for a performance test: a legacy Java application on Windows EC2, CloudWatch agent with custom metrics at 10-second intervals, process-level Java counters, GC and server logs shipped to CloudWatch, and a dashboard organised by failure domain. The old me would have opened a doc and started capturing screenshots for the inevitable blog post. Step 1: open the AWS console. Step 2: click here. Step 3: paste this JSON... But here's the thing — I didn't build the setup that way. I described what I needed to my AI assistant, reviewed what it proposed, and approved the commands. The whole thing came together in a fraction of the usual time. No console clicking. No documentation rabbit holes. So why would I write a blog post asking *you* to do it the slow way? 🤔 ## The Way We Consume Tech Content Has Changed Be honest — when was the last time you followed a 15-step tutorial, screenshot by screenshot? These days, most of us do the same thing: take the problem, paste it into Claude or ChatGPT or whatever agent lives in our terminal, and let it drive. The step-by-step tutorial format assumes the *human* is the executor. That's no longer true — the human is the **reviewer and decision-maker**, and the LLM is the executor. And let's not forget the classic tutorial problems: * Screenshots go stale the moment a console UI changes * Steps written for one setup break on another * You learn the clicks, but not the judgment > The tutorial's job has changed. The steps are now the LLM's job. The **judgment** is still yours — and that's what a blog should teach. ## The New Format: Prerequisites, Prompt, Judgment So here's the format I'm betting on. Every "how-to" post on this blog will now be three things: 1. **Prerequisites** — what you must bring: instance IDs, permissions, access. The things no prompt can conjure for you. 2. **The prompt** — battle-tested, copy-paste ready. You hand it to your AI assistant and it does the heavy lifting. 3. **The judgment** — the gotchas, the costs, the war stories. The part an LLM genuinely cannot give you, because it comes from things breaking in production at 6 AM. That third part matters most. Today's load test is a perfect example: when the app went unresponsive under 100 users, every instinct said "the instance is too small." The metrics said otherwise — CPU at 74%, memory at 23%, heap barely a fifth used. The real culprit was 200 exhausted connector threads, blocked on an upstream service with no timeout configured. A bigger instance would have hit the exact same wall. No prompt teaches you that instinct. Experience does — and sharing experience is what blogs are still uniquely good for. ## Introducing the Prompts Series I've created a new **Prompts** series on this blog — you'll see it in the navbar. Each post is one focused, tested prompt: what it does, when to use it, the prompt itself, and the gotchas I hit so you don't have to. Two are already live: * **Prompt #1** — turn your AI agent into your Hashnode publishing assistant (yes, it published itself 🤖) * **Prompt #2** — the full CloudWatch agent setup from today's performance test The longer-form posts aren't going anywhere — architecture deep dives, comparisons, and war stories still deserve the full treatment. But for the "how do I set this up" content? Prompt-first from now on. ## Key Takeaways * The audience for step-by-step tutorials is shrinking; the audience for **prompts + judgment** is exploding * Write for the new workflow: human decides, LLM executes * Your experience — the gotchas and war stories — is the part AI can't replicate. Lead with it. Curious what you think — would you rather read 15 steps, or copy one prompt? Drop a comment. 😊 Happy prompting!