I resisted AI assistants for longer than I’ll admit. Thirty years in this field will make you skeptical of anything that shows up promising to replace judgment you built the hard way: on-call at 2am, staring at a trace dump, learning exactly why you always test the rollback plan. But somewhere in the last couple of years, the tools got good enough that ignoring them stopped being caution and started being just plain inefficient.
The trick isn’t the tool. It’s the prompt. Most IT folks I talk to are still using AI like a search engine with better manners, “how do I do X,” and leaving most of the value on the table. Below are ten prompts I actually use, in the shape I actually use them, plus one bonus at the end. Steal them, tweak them, make them yours.
One ground rule before we start: Great Googly Moogly, never paste credentials, customer data, internal hostnames, or anything with compliance implications into a public AI tool. Sanitize first, or use an enterprise instance with the right data handling agreements.
That’s not paranoia, that’s just the job.
1. The “explain it like I have ten minutes” triage prompt
When something breaks and you’re staring at a wall of log output, don’t just paste the error and ask “what’s wrong.” Give the model a job:
Here’s an error/stack trace from [system]. Give me: (1) your top 3 hypotheses for root cause, ranked by likelihood, (2) the fastest way to confirm or rule out each one, (3) anything in this output that looks like a red herring. Then stop. Don’t suggest a fix until I’ve confirmed the cause.
That last sentence matters. Left alone, most models will race straight to a fix based on a guess. Forcing the diagnostic step first is what actually saves you time.
2. The “translate this for my VP” prompt
Every architect eventually has to explain a technical risk to someone who does not care about the technical part. I have to talk with tech doers at my client sites, and that feels very comfortable, but what isn’t always comfortable (at least not at first) is translating that directly to those who aren’t tech oriented.
I need to explain [technical issue/proposal] to a VP with no technical background. Explain the business risk or opportunity in plain language, keep it under 150 words, and suggest one follow-up question they’re likely to ask so I’m ready for it.
This one earns its keep in every steering committee meeting you’ll ever sit through.
3. The “poke holes in my design” second opinion
AI wants to be helpful (almost too much so at times), and we as humans like the echo chamber to confirm that “everything is awesome!”
But before you commit an architecture to a diagram everyone will reference for the next five years, make the AI argue with you.
Here’s my proposed architecture for [system/change]: [description or paste of design]. Play the skeptical reviewer. List the three failure modes you’d worry about most, what happens at 10x current load, and one simpler alternative I might be dismissing too quickly.
It won’t catch everything a seasoned peer review would. But it catches more than reviewing your own work alone does, and it’s available at 11pm the night before the design review. You can do the same for proposals, solutions, sales docs, etc., so you can see from a perspective that you may be missing.
4. The “write the runbook I keep meaning to write” prompt
Tribal knowledge is the silent risk on every team. This is how you get it out of your head and into a document without losing a weekend.
I’m going to describe how we handle [recurring task/incident type] in a rough, conversational way. Turn what I say into a structured runbook: prerequisites, step-by-step procedure, expected output at each step, and a rollback section. Ask me clarifying questions if a step is ambiguous.
Then just talk it through like you’re training a new hire. Let the model do the formatting labor.
5. The “pre-mortem this change” prompt
Before a maintenance window, not after.
I’m about to make this change: [description]. Assume it fails. Walk me through the most likely ways it fails, what the blast radius looks like for each, and what I should confirm is true before I start (backups, rollback path, dependencies) so I’m not finding out mid-change.
Cheaper than the incident. Every time.
6. The “make this script production-safe” prompt
We’ve all got a folder of scripts that work great as long as nothing unexpected happens, which is exactly the situation production guarantees you’ll eventually hit.
Here’s a script I use for [purpose]: [paste]. Harden it for production use: add error handling, logging, a dry-run mode, and idempotency where it applies. Explain each change so I understand what you added and why.
That last instruction is the one people skip, and it’s the one that keeps you from shipping code you don’t actually understand. And for the love of all that is good and holy, understand what the code/script does. “The AI said it was ok” is NOT the way you want your explanation of events to start off with. 😉
7. The “audit-ready” documentation prompt
There are a few things that I (and apparently most every other IT professional) hate doing, and that is documentation. Compliance documentation is even more so, which is exactly why it’s a good one to hand off.
Rewrite this control description so it would satisfy an external auditor: [paste rough notes]. Use precise, evidence-oriented language, avoid vague verbs like “regularly” or “as needed,” and flag anywhere I’m missing a detail an auditor would ask for.
You still own the accuracy. But the first-draft language lift is real, especially to get you past the writer’s block (procrastination) of getting the documentation started in the first place.
8. The “what am I missing” cost and capacity review
Cloud bills and utilization dashboards are full of things that are technically fine and quietly wasteful.
Here’s a summary of our [cloud spend/resource utilization] for [period]: [paste or describe]. Identify anything that looks anomalous compared to the rest, and suggest three specific, low-risk optimizations I could investigate this week.
Ask for “low-risk” specifically, or you’ll get a list that includes rearchitecting things you have no appetite to touch right now.
9. The “turn this postmortem into a lesson” prompt
Most postmortems are timelines. The good ones are lessons. AI is genuinely useful at the second part.
Here’s the incident timeline and root cause: [paste]. Identify the systemic pattern behind this incident, not just what broke, but what about our process or architecture allowed it to happen. Suggest two action items that address the pattern, not just this instance.
That distinction, instance versus pattern, is the difference between a postmortem that prevents the next ten incidents and one that just gets filed away.
10. The “help me learn what I inherited” onboarding prompt
Every architect eventually inherits a system nobody fully documented (see items #4 & #7). This will help you get up to speed a bit more efficiently.
I’ve just inherited responsibility for [system/platform] and don’t know it well yet. Give me a structured plan to get up to speed: what to read first, what questions to ask the previous owner, what I should check personally rather than take on faith, and what’s likely to bite me in the first 90 days.
It won’t know your specific environment. But it’s a genuinely good checklist generator, and a good checklist is most of the battle when you’re starting from zero.
Bonus: The “don’t walk into Monday blind” weekly review prompt
Every prompt above works with any general-purpose AI assistant, sanitized inputs and all. This one’s different: it only works if your AI is actually wired into your calendar, inbox, and files, which for a lot of us in a Microsoft shop means Copilot tied to your corporate email, Teams, and SharePoint. That access is exactly what makes it worth the fifteen minutes.
I block out time every Friday morning for this:
Review my meetings and emails from this last week as well as upcoming meetings and list any open action items that I have pending or that I need to prepare for, especially for Monday.
It’s not glamorous, but it catches the action item that got buried in a Wednesday afternoon email thread, and the meeting Monday morning you’d forgotten you agreed to co-present. Friday, with the week still fresh, is a much better time to find that out than Monday at 7:58 AM. Turn on transcription in your Teams meetings so Copilot can search for action items assigned to you that you forgot completely due to the torrent of other tasks that flooded in afterward.
This is where a connected AI genuinely earns its keep over a plain chat window: none of the other ten prompts on this list can do what this one does, because none of them have visibility into what’s actually on your plate.
None of these replace judgment. What they do is compress the distance between “I have a rough idea” and “I have a usable first draft”: of a diagnosis, a document, a design review, a plan. That compression is the actual value of AI in this job right now, not the fantasy of it doing your job for you. Use it to get to the interesting part faster, then apply the thirty years of judgment that got you into the room in the first place.
If you’re trying to decide which of these tools actually deserves a permanent spot in your toolkit, I broke down Copilot vs. ChatGPT vs. Claude in a follow-up piece.