I treat Claude and ChatGPT like junior developers on my team. Not as a replacement for engineering thinking. As junior contributors who need direction, produce first drafts fast, and improve dramatically when I review their work and tell them exactly what “good” looks like.
That mental model changes how I use them. Three examples from this month, with more detail than my LinkedIn version.
AI didn’t replace the judgment call. It replaced the typing.
1. Runbook automation: GitHub to Notion
Engineers prefer git for version control. Ops and support teams prefer Notion for search and navigation. I wanted both, without asking anyone to change their workflow.
The pipeline: runbooks live as Markdown in a GitHub repo. A GitHub Action fires on push to main. Claude wrote the sync script that converts each Markdown file to Notion’s block format and updates the corresponding page in a shared Notion database.
What Claude did: wrote the sync logic, handled the Markdown-to-Notion block conversion, dealt with the API rate limits.
What I did: decided the repo structure, defined what “a runbook” looks like, wrote the Action YAML, chose which folders sync where.
The workflow decision was the hard part. The code was the fast part.
2. Operations Command Center
Leadership was chasing four tools every morning: PagerDuty for large-scale events, JSM for escalations, Grafana for availability, and a spreadsheet for changes. Nobody had time. So nobody was looking.
I built a single Slack Canvas, published daily to a Notion page. It shows:
- Current large-scale events with severity and status
- Top customer escalations by age
- Availability against SLO by service
- Changes deployed in the last 7 days
Claude built the aggregators that pull from each source. I decided what leadership actually needed to see. That’s not the same as “everything the tools can show.” Half the design work is what you leave out.
3. The audit that almost didn’t land
I asked Claude to run an audit across two systems and produce a report for the exec team. What’s out of policy? Who needs to act? What’s the risk if nothing changes?
The first draft was noisy. Numbers everywhere. Long lists without conclusions. Tables that showed data but didn’t answer the question.
The problem wasn’t Claude. I hadn’t defined what “good” looked like.
I went back with clearer direction: one page, ranked by risk, each finding paired with an owner and an action, executive summary at the top in three bullets. Ran it again. Sharp report the second time. The exec team acted on it the same week.
A checklist for reviewing AI output
The audit episode gave me a pattern. Now every time I use AI on a leadership-facing artifact, I run through the same list.
Define “good” before you prompt. Review the first draft. Prompt again. Ship the second version.
The five things I check:
- Does it answer the specific question the audience is asking? Not the question you asked the AI. The question the audience will ask when they read it.
- Does it prioritize? Top three, not top thirty. If everything is important, nothing is.
- Does it end with an action, not data? Reports for leaders need a “so what.”
- Is there context for someone who isn’t in your head? Assume the reader has never seen the systems, the metrics, or the customers.
- Would you send this if you had written it yourself? If not, one more round.
The pattern
Junior developers need direction. They also need review. Give both, they multiply your output. Skip either, you get noise.
AI didn’t replace judgment. It made the work much faster.
That’s the whole trick.