Problem Statement
Slow Windows logins on a domain-joined estate are one of the most common, and most frustrating, classes of enterprise complaints. The user sees a blank screen for thirty seconds; the helpdesk sees a vague ticket; the platform team sees no obvious culprit. The actual cause could be anywhere: a misbehaving disk, a saturated NIC, a slow domain controller, a bloated roaming profile, a Group Policy that does synchronous network calls, or a logon script that hangs on a missing share. Each of those lives in a different log on a different layer of the stack, and the troubleshooting playbook usually involves a senior engineer spending an afternoon walking the chain by hand.
That afternoon, multiplied across hundreds of incidents per month in a 200,000-device estate, is real money and real lost time for end users. The diagnostic itself is not glamorous work — it's a known checklist. The leverage is in running the checklist consistently, on the affected machine, while it is still in the broken state.
The Build
TestLoginDelayReason is a PowerShell diagnostic that walks the full slow-login checklist on a target Windows machine and produces a single timestamped report with actionable recommendations. It covers eleven sections, including system information, CPU/RAM/disk metrics, DNS resolution, network connectivity to domain controllers across the seven critical ports, Group Policy processing times, security event logs, user profile sizes, and NETLOGON debug analysis. Administrators run it via a batch launcher or directly through PowerShell; running elevated unlocks additional diagnostic data.
The first working version took roughly five minutes to put together using iterative AI assistance — describing the problem, sketching the sections, having the model draft the cmdlet sequences, then refining the output format and the recommendation logic in tight loops. That five minutes replaces what would historically have been a multi-hour scripting exercise, plus the prerequisite of remembering the exact Get-WinEvent filter, the right registry path for NETLOGON debug logging, and which seven ports actually matter for AD authentication.
Why This Project Matters
This is a deliberately small project. It does not have agents, an orchestrator, or an ML pipeline. The point is the opposite of AutoPackager: it is the cheapest possible end of the AI productivity curve, and it shows that the curve starts paying off immediately.
A few things stand out from building it this way:
- Time-to-first-useful-output collapses. Five minutes from "we need a tool" to "we have a tool a junior engineer can run on a real machine" changes who is allowed to write tooling. It stops being a project and starts being a reflex.
- Tribal knowledge becomes encoded. The checklist that lived in a senior engineer's head — which event IDs matter, which ports to test, what a healthy
gpresultlooks like — is now a script anyone on the team can run, read, and improve. - Iteration is the loop, not the plan. The first version was wrong in small ways: missed a port, formatted a section poorly, didn't gracefully degrade when run unelevated. Each fix was another short prompt. The cost of a refinement pass is low enough that you stop pre-optimizing the design.
- Diagnostics are a perfect AI fit. Read-only, well-bounded, well-documented APIs (Win32, WMI, event logs), and a clear "good vs. bad" output shape. Exactly the shape of problem where an LLM is useful without being dangerous.
Outcome
The repository is public on GitHub. It is intentionally not a product — it is a single-file diagnostic that any Windows administrator can drop onto an affected machine and get a real answer from in under a minute. Saving an hour of senior-engineer time per incident, on a class of problem that recurs daily, is the kind of unglamorous, compounding win that AI-assisted tooling makes routine.
The lesson I keep coming back to: the interesting AI projects are the multi-agent ones. The valuable AI projects are often the five-minute ones.