Skip to content

Sharpen, Delegate, Partner: Using AI Well as an Engineer

First PublishedByAtif Alam

Part 2 of 2 in the Using AI Well series. Part 1 covers the twelve skills behind good judgment and where AI adds the most value.

Picture this. An outage ends at 2 a.m. By morning, an AI assistant has turned the alerts, chat threads and deploy history into a clean postmortem draft.

The timeline is tidy, the writing is clear, and the root cause is stated with confidence: the deploy that went out ten minutes before the alerts fired.

It reads perfectly. It may also be wrong.

That gap, between output that looks right and judgment that is right, is what this post is about.

A quick recap

Section titled “A quick recap”

In Part 1, we looked at twelve skills behind good judgment, the ones we use to diagnose, plan, review, explain and work with people. They range from causal reasoning and pattern recognition to values, goal-setting and reading people.

The short version: people and AI are strong in different places. AI is strong at recognizing patterns, checking logic and recalling a huge range of knowledge. Humans are better at the things that depend on reality, stakes and context.

Why AI falls short: three gaps

Section titled “Why AI falls short: three gaps”

1. It can’t check the world

Section titled “1. It can’t check the world”

A model works from text, not from your production environment. It can describe causes, but it struggles to tell a real cause from something that merely happened at the same time, especially when it has to work it out from data alone.

It can also propose “what if” scenarios without any way to test them, and it is poor at catching its own mistakes unless something outside it pushes back.

2. It has no stakes

Section titled “2. It has no stakes”

A model has no goals of its own and nothing to lose.

It can plan well once you tell it what success looks like, but it can’t decide what should matter. Its value judgments can also shift with how a question is phrased.

3. It misses unwritten context

Section titled “3. It misses unwritten context”

The constraints that sink real projects are rarely written down: politics, budgets, a fragile dependency, a team that is already stretched.

A model can map a system in the abstract but misses what nobody told it. It also reads people from text alone, without tone of voice or body language.

What AI is good at: summarizing and clustering large amounts of information, checking arguments for gaps, proposing checklists and options, and fast recall across unfamiliar topics. Used for those jobs, with checks, it saves real time.

“AI” here means general-purpose language models as of 2026. These capabilities change quickly.

The playbook

Section titled “The playbook”

Sharpen (keep these human):

  • Goals. Decide what success looks like before you ask AI anything.
  • Values. Own the “should we?” question.
  • Verification. Test, measure and confirm. Reality is the final judge.
  • People. Trust, negotiation and communication remain human work.
  • Hands-on expertise. It’s what lets you spot when AI is wrong.

Delegate (let AI do the heavy lifting):

  • Summaries, first drafts and timelines
  • Checking documents and arguments for gaps
  • Generating options, checklists and scenarios
  • Quick orientation in unfamiliar territory

Partner (work together, with checks):

  • Root-cause and systems analysis: AI lists possibilities; you supply context and confirm.
  • Bias checks: ask AI to argue against your position, then ask yourself what would change your mind.
  • Hard decisions: AI widens the set of options; you choose and own the outcome.

Four examples from SRE work

Section titled “Four examples from SRE work”

Site reliability engineering is a good test case because the work has two sides.

One side is data: huge volumes of logs, metrics and traces. AI is great at this. The other side is judgment: calls about risk and people. AI is not.

1. Incident postmortems

Section titled “1. Incident postmortems”

Delegate:

  • Build a first-draft timeline from alerts, deploy logs and chat threads.
  • Search past postmortems for similar incidents.

Keep human:

  • The root cause. Confirm the mechanism with evidence: reproduce it, check the metrics, rule out alternatives.
  • The tone. How the write-up reads to the engineer who was paged at 2 a.m. matters. Blameless framing is a human call.
  • Which fixes get done. AI can list fifteen action items. Choosing the two worth this quarter’s time is yours.

Watch for: a polished story built on the wrong cause. The cleaner the draft reads, the harder you should question it.

2. Capacity planning

Section titled “2. Capacity planning”

Delegate:

  • Analyze usage trends and fit forecasts.
  • Run scenarios: traffic doubles, traffic grows fivefold, an availability zone goes down.

Keep human:

  • Business context. A product launch or a big customer onboarding won’t show up in last quarter’s metrics.
  • Hidden limits. Real systems hit step changes: IP address exhaustion, cloud quotas, control-plane limits, a dependency that breaks first.
  • How much headroom to buy. That’s a cost-versus-reliability tradeoff tied to your SLOs and budget.

Watch for: a neat linear forecast that ignores the one constraint that will actually break first.

3. On-call incident response

Section titled “3. On-call incident response”

Delegate:

  • Summarize noisy logs and explain unfamiliar stack traces.
  • Pull up relevant runbooks and list hypotheses, ranked by how easy they are to rule out.

Keep human:

  • Roll back or fix forward. It depends on blast radius, customer impact and your confidence in the fix, under time pressure.
  • Communication. Updates to stakeholders and coordinating responders are people work.
  • Knowing when you’re stuck. Notice when the team has fixated on one theory for too long.

Watch for: fixating on the AI’s first hypothesis. Treat its list as things to rule out, not answers.

4. Change review in a GitOps workflow

Section titled “4. Change review in a GitOps workflow”

Delegate:

  • Check manifests for inconsistencies: mismatched labels, missing resource limits, probes that will never pass.
  • Explain a large or unfamiliar diff in plain language.

Keep human:

  • Blast radius and timing. Is this going to every cluster at once? Is there a change freeze or a big customer event tomorrow?
  • Tribal knowledge. “The last time someone touched that setting, the whole service mesh restarted.”

Watch for: an approval that sounds thorough but only checked the YAML, not the environment it’s deploying into.

Data work vs. judgment work

Section titled “Data work vs. judgment work”

In all four examples, AI compresses the data work: reading, summarizing, drafting, recalling and checking for consistency.

Humans keep the judgment work: what caused it, what matters, what’s worth the risk and how it lands with people.

As the data work gets cheaper, the judgment work becomes the job. That’s the part worth sharpening.

Sources and further reading

Section titled “Sources and further reading”

Why AI falls short

  • Jin et al. (2023), Can Large Language Models Infer Causation from Correlation? arXiv:2306.05836
  • Kıcıman et al. (2023), Causal Reasoning and Large Language Models. arXiv:2305.00050
  • Huang et al. (2023), Large Language Models Cannot Self-Correct Reasoning Yet. arXiv:2310.01798
  • Scherrer et al. (2023), Evaluating the Moral Beliefs Encoded in LLMs. arXiv:2307.14324
  • Strachan et al. (2024), Testing theory of mind in large language models and humans. Nature Human Behaviour. doi:10.1038/s41562-024-01882-z
  • Ullman (2023), Large Language Models Fail on Trivial Alterations to Theory-of-Mind Tasks. arXiv:2302.08399
  • Mirzadeh et al. (2024), GSM-Symbolic. arXiv:2410.05229

Background

  • Judea Pearl & Dana Mackenzie, The Book of Why (2018). Author’s page
  • Hubert Dreyfus, What Computers Can’t Do (1972)
  • Michael Polanyi, The Tacit Dimension (1966)