You’ve got an idea. Maybe it’s a new automation script, a draft post, or a refactor for your monitoring stack. You open the AI tool. Type a prompt. Hit enter. Get back… something. Not quite what you need. Again.
I’ve been there. For years. As a sysadmin who’s automated everything from log rotation to incident triage, I’ve tested every “AI workflow” out there. Most are garbage. They assume you’re a genius with infinite time to tweak prompts, or that AI is a magic button that spits out production-ready work.
It’s not. But it is useful—if you stop treating it like a co-pilot and start treating it like a very specific, slightly unreliable intern.
Here’s how I actually get ideas from my head to something that works, ships, and survives Monday morning.
—
Start with the Output, Not the Prompt
AI tools don’t care about your idea. They care about the pattern of text you feed them. If you ask for “a cool script,” you’ll get a script that looks cool but fails in production because it ignores edge cases, permissions, or your actual environment.
Do this instead:
- Define the exact output format you need: JSON, YAML, shell script, markdown, etc.
- Specify constraints upfront: “No external dependencies,” “Must run on Python 3.9,” “No API calls outside the company network.”
- Include one concrete example of the input and output you expect.
Example: Instead of: “Write a script to rotate logs.” Do this: > “Write a Bash script to rotate /var/log/app/*.log files older than 7 days. Compress with gzip. Keep 30 rotated files. If a file is being written to, skip it (use lsof to check). Output a JSON summary of rotated files and sizes. No external dependencies. Here’s an example input: > ` > app.log (size: 102400, mtime: 2026-04-01) > app.log.1 (size: 98000, mtime: 2026-03-31) > ` > Output: > `json > {"rotated": ["app.log.1"], "skipped": [], "total_bytes": 98000} > ` > Assume lsof is installed.”
This isn’t extra work. It’s how you prevent the 2 a.m. page when the script fails because it didn’t handle symlinks or special characters in filenames.
—
Break the Workflow into Stages—Not Prompts
I see people try to do everything in one go: “Write the blog post, then add YAML front matter, then format it for Markdown, then suggest images.” Nope. That’s how you get a Frankenstein of a draft that needs more editing than writing it yourself.
Treat AI like a tool for one thing at a time. Here’s my standard 4-stage pipeline:
- Scaffold
Generate the basic structure—outline, function stubs, YAML skeleton, or boilerplate. No polish. Just scaffolding.
- Refine
Feed the scaffold back in and ask for specific improvements: “Add error handling for network timeouts in fetch_data()” or “Rewrite this paragraph to sound less corporate.”
- Validate
Ask AI to critique its own work. “What are 3 failure modes for this script?” or “Where could this markdown break in a static site build?” AI is surprisingly good at spotting its own gaps—if you ask the right question.
- Integrate
Manually plug the result into your actual workflow. Don’t trust it to “just work.” Test it. Run it locally. Commit it. Let CI catch what AI missed.
Real example: I used this to build a new internal alert dashboard. Stage 1: AI wrote the HTML/CSS structure. Stage 2: I fed it our Prometheus query format and asked for the JS to fetch and render. Stage 3: I asked it to list 5 ways this could break in production (e.g., CORS, auth tokens expiring, slow queries). Stage 4: I rewrote the auth part to use our SSO library—AI didn’t know our stack.
—
The “Human-in-the-Loop” Is Not Optional
AI doesn’t know your stack. It doesn’t know your team’s conventions. It doesn’t know why rm -rf /tmp is a bad idea in your environment.
I’ve had AI suggest sudo in scripts that ran as non-root. I’ve had it use deprecated APIs that got shut down last year. I’ve had it generate YAML with tabs (which breaks every YAML parser I use).
You must build in a loop:
- ✅ Generate → Test → Fix → Refine
- Never Generate → Deploy
- Never Generate → Ship
I keep a “AI Output Log” in a markdown file. Each entry has:
- Date
- Prompt used
- Output summary (good or bad)
- What I had to fix manually
- Lessons learned
After 6 months, that log tells me which AI tools to trust for which tasks—and which to avoid entirely. It’s my personal “what not to do” database.
—
Failure Modes: What Breaks (And Why)
Let’s talk about the stuff no one mentions. AI isn’t “wrong.” It’s incomplete. And in ops, incompleteness breaks things.
Common failure modes I’ve seen:
- Assumed context: AI assumes your environment is like its training data. It will use
systemctlon a container, orapton RHEL, orcurlwithout--fail.
Fix: Explicitly state OS, package manager, network restrictions.
- Version drift: AI generates code for Python 3.12, but your servers run 3.9. Or it uses
jqflags that were added in 1.7, but your apt repo has 1.6.
Fix: Pin versions. Ask AI to “assume Python 3.9 and jq 1.6.”
- Silent failures: AI loves
try/exceptblocks that justpass. In production, that means you won’t know when things break.
Fix: Ask for logging, exit codes, and failure modes. “What happens if the config file is missing? Log and exit 1.”
- The “It Works on My Machine” Trap: AI will generate a script that works in the prompt’s example—but not with real-world data (e.g., filenames with spaces, UTF-8, newlines in fields).
Fix: Ask for edge cases. “What if the log filename has spaces? What if a log line has a quote?”
I once had AI generate a log parser. It worked fine—until a user logged a stack trace with newlines. The script split on \n, broke the JSON, and crashed the collector. Took 10 minutes to fix once I knew what to look for. Would’ve taken 5 minutes to write the parser myself. But the scaffold saved time.
—
What I Would Do First
You don’t need a new workflow. You need a tighter one.
Here’s my 15-minute test run—try it today:
- Pick one small task
Something you do weekly: rotate a log, draft a status update, refactor a function.
- Write the prompt like a spec
Include:
- Input format
- Output format (with example)
- Constraints (no internet, Python 3.8, must handle edge X)
- Failure handling (exit codes, logging)
- Run it once. Don’t edit the prompt yet.
- Ask AI to critique its own output
“List 3 ways this could fail in production.”
- Manually fix the top 1 issue. Test it. Commit it.
Do that once. Then do it again next week with a different task. In a month, you’ll have a workflow that works for you—not for a demo, but for real work.
No magic. No hustle. Just less time spent debugging, and more time building.
—
Next Steps
If you want to try this:
- Audit your last 5 AI outputs
How many shipped? How many got rewritten? Why? Add them to your log.
- Pick one task to automate
Start small. A 10-line script. A single paragraph draft. Something you can test in <10 minutes.
- Add one constraint
“Must handle empty input.” “Must log to stderr.” “No eval.”
- Run it. Test it. Break it. Fix it.
The goal isn’t to get AI to write your work. It’s to get AI to reduce your friction—so you can spend more time on what matters: keeping things running, shipping features, and sleeping through the night.
That’s the real automation. Not the AI. The workflow.