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!