"Intune admin" won't be a job title in 3 years

I've spent twenty-five years in endpoint management, so I know exactly how that sentence sounds. I'm not scared of it — I'm betting my career on it.

Be honest about the job

Strip the title back and look at what fills most days in a modern endpoint role:

• Clicking the same blades — navigating the portal to do what you did last week.
• Rebuilding policy #40 — another near-identical Conditional Access or compliance policy.
• Hand-writing detection rules — the Win32 app logic you've written a hundred times.
• Chasing one stuck device — why won't this thing enroll? Again.

Deterministic. Documented. Patterned. That is the exact layer AI automates first — not because it's smart, but because we made the work machine-shaped decades ago and kept doing it by hand.

What's actually happening

Portal clicks → Graph API → intent. When "enforce this baseline on the pilot ring" can write, test, and stage itself, knowing which blade to click is worth almost nothing. The clicking was never the value. It was just the only interface we had.

The job doesn't die — it moves up a layer

Split the role in two. The operator executes configuration: clicks the policy, knows where the buttons are. The architect defines policy-as-code, owns blast radius and rollback, and encodes the intent automation must obey.

AI eats the operator. It makes the architect scarce — because now every automated change needs someone who decided, in advance, what safe looks like.

How to be early instead of replaced

• Treat Intune as infrastructure. Graph API and policy-as-code. Version it. Stop living in the portal.
• Own the "why." Security intent, risk tolerance, blast radius — the judgment AI can't source.
• Build the guardrails. Staging rings, detection, rollback — what makes automation safe enough to trust.
• Change your sentence. From "I configure devices" to "I design how devices are governed."

AI won't replace endpoint engineers. It'll replace the part of the job that was never really engineering.

← back to all notes

I let an LLM write my PSADT packaging script

It got me 80% there in 30 seconds. The other 20% could have broken 150,000 machines. Both halves of that sentence matter.

What it nailed

Modern models are genuinely great at the boilerplate that eats a packaging afternoon: the Deploy-Application skeleton with Install/Uninstall/Repair wired correctly, Show-InstallationWelcome prompts with close-apps and deferral logic, consistent logging, and Execute-MSI calls with sensible parameters. If your baseline is "blank file," this is a real accelerant.

Dangerous mistake #1: it blended toolkit versions

PSADT v4 renamed the toolkit's commands. The model mixed v3 and v4 syntax in one script — Show-InstallationWelcome next to Start-ADTProcess — so it called functions that don't exist together. It fails the moment it runs. The tell: an LLM can't know which toolkit version your environment actually runs. It will guess, fluently.

Dangerous mistake #2: it invented the silent switch

It confidently gave a vendor EXE /S when the installer actually needs /qn plus a transform. Confident, wrong, and invisible until deployed. At fleet scale, a guessed switch isn't a bug — it's 150,000 installers hanging interactively at once, and a very long night.

The rule I package by now

• Exit codes. 3010 means success-with-reboot. Treat it as failure and your Intune reporting lies to you.
• Detection rules. The install half is easy. Wrong detection means the app reinstalls on every sync, forever.
• The switches. Silent flags and transforms are vendor-specific. Verify against the docs — never a guess, no matter how confident it sounds.

AI won't replace the admin who knows why the switch matters. It just makes that admin faster — and everyone else more dangerous.

← back to all notes