Weekly Article Backlog
This file is a working backlog for weekly blog posts. The goal is to keep enough ideas ready so publishing does not depend on inspiration appearing at the perfect time.
Weekly Cadence
- Week 1: Automation, process, or AI-assisted workflows.
- Week 2: Kubernetes, DevOps, platform engineering, or cloud tooling.
- Week 3: Security, reliability, observability, or incident response.
- Week 4: Career, communication, recruiting, or lessons learned.
Keep each article focused on one clear opinion. A good post should answer: what changed, why it matters, what people usually get wrong, and what a better approach looks like.
Article Ideas
- Why Automation Is Not Optional Anymore
- AI as a Junior Operator, Not a Senior Engineer
- The Difference Between Automation and Orchestration
- When Kubernetes Is Worth It, and When It Is Overkill
- What I Wish More People Understood About Infrastructure as Code
- Terraform Is Powerful, But State Is Where the Pain Lives
- Why Good Documentation Is an Engineering Tool
- Runbooks Are Not Bureaucracy
- The Hidden Cost of Tribal Knowledge
- How to Design Systems That Are Easier to Recover
- Why “It Works on My Machine” Still Exists
- The Importance of Idempotency in Automation
- CI/CD Is Not Just Deployment Automation
- GitOps: Great Idea, Often Poorly Explained
- What Argo CD Teaches You About Desired State
- Monitoring vs Observability: Why the Difference Matters
- The Alert Fatigue Problem
- How AI Can Help During Incidents
- Why Postmortems Should Not Be Blame Sessions
- Security Checks Should Be Automated Early
- The Problem With Manual Access Reviews
- Why Secrets Management Still Gets Ignored
- Backups Are Boring Until They Save You
- Disaster Recovery Plans Need Practice, Not Just Documents
- Why Small Teams Need Processes Too
- Process Is Not the Enemy of Speed
- How Bad Handoffs Break Engineering Teams
- The Difference Between Busy Work and Valuable Work
- Why Engineers Should Care About Business Context
- AI Will Not Fix a Broken Process
- The Danger of Automating Bad Workflows
- How to Decide What to Automate First
- The Human Side of Platform Engineering
- Why Internal Developer Experience Matters
- Good Tools Reduce Cognitive Load
- The Recruiter Problem From an Engineer’s Perspective
- How Candidates Can Set Better Boundaries
- What Makes a Good Technical Interview
- Lessons Learned From Working With Linux Systems
- What I Would Tell Someone Starting in DevOps Today
- Why Every Team Needs a Definition of Done
- The Difference Between Done and Deployed
- Why Rollbacks Should Be Designed Before Deployments
- The Best Automation Starts With a Boring Checklist
- How to Make Onboarding Less Dependent on Luck
- Why Every Production Change Needs a Recovery Path
- AI Coding Tools Need Constraints, Not Just Prompts
- How to Review AI-Generated Code Without Losing Trust
- The Case for Smaller Pull Requests
- Why TDD Matters Even More When Building With AI
Strong Starting Picks
- AI Will Not Fix a Broken Process
- GitOps: Great Idea, Often Poorly Explained
- The Hidden Cost of Tribal Knowledge
- How to Decide What to Automate First
- Why TDD Matters Even More When Building With AI
- AI Coding Tools Need Constraints, Not Just Prompts
Article Template
Use this shape when a topic feels too broad:
- Start with a direct opinion.
- Explain the problem in practical terms.
- Give one real technical example.
- Show the common mistake.
- Explain a better approach.
- End with a short takeaway.
AI-Assisted Writing Notes
- Give the AI context about the blog voice: practical, opinionated, technical, and direct.
- Ask for outlines before drafts when the topic is broad.
- Prefer personal examples over generic industry claims.
- Remove filler phrases like “in today’s fast-paced world” or “game changer.”
- Keep the final article specific to infrastructure, DevOps, automation, security, or engineering work.
- Ask the AI to challenge the argument before polishing it.
- Make the final editing pass manually so the article sounds like an experienced engineer, not a brochure.
AI Build Configuration Tips
These notes are for coding with AI assistants, especially when iterating on applications, automation, infrastructure code, or documentation-driven tooling.
TDD Is Mandatory With AI
When building with AI, TDD is not a nice option. It is a must.
AI-assisted development can move quickly, but speed makes regressions easier to miss. During multiple iterations, a feature can break without anyone noticing until much later. Reverting after several rounds of changes often wastes more time than starting with a structured test-first approach.
Use tests as guardrails:
- Write or update tests before asking AI to change behavior.
- Keep tests focused on the expected user-visible outcome.
- Run tests after every meaningful change.
- Treat failing tests as the next task, not as noise.
- Add regression tests whenever AI fixes a bug.
- Avoid accepting large AI changes without a test that proves the important behavior still works.
Give AI Clear Boundaries
- Define the goal and the non-goals before implementation.
- Tell the AI which files, modules, or layers it is allowed to touch.
- Ask for small, reviewable changes instead of broad rewrites.
- Require the AI to preserve existing patterns unless there is a clear reason to change them.
- Make acceptance criteria explicit before code is written.
Keep Iterations Small
- Change one behavior at a time.
- Run the test suite between iterations.
- Commit working checkpoints before major refactors.
- Avoid mixing feature work, formatting, and cleanup in one change.
- Ask for a short implementation summary after each iteration.
Review AI Output Like Untrusted Code
- Check edge cases manually.
- Look for deleted behavior, not just added behavior.
- Watch for fake abstractions that make the code harder to understand.
- Confirm that errors, empty states, and permission failures still work.
- Verify config examples, commands, and dependency versions.
Good Prompt Shape for Coding Tasks
Use this structure when asking AI to build or change something:
- Context: what the project does and where the relevant code lives.
- Goal: the exact behavior you want.
- Constraints: what must not change.
- Tests: what should prove the change works.
- Verification: commands that must pass before the task is done.
Example:
We are working in a Jekyll blog repo. Add a new post under _posts.
Do not change layouts, styles, or existing posts.
Use the existing front matter format.
After editing, check front matter parsing and run git diff --check.
Weekly Publishing Workflow
- Pick one topic from the backlog.
- Write a 5-7 bullet outline.
- Add one personal or practical example.
- Draft the article.
- Edit for clarity and remove generic wording.
- Check Markdown formatting.
- Commit and push to publish.