If you manage endpoints for a living, the most important artifact in your RMM isn't a script. It's the paragraph that explains what the script is supposed to do — and how you'll know it actually worked.
That's the practical reading of a recent Register interview in which Kaseya's CTO argued that "the spec is the new code": as AI assistants write more of the actual syntax, the scarce skills become domain expertise and clear writing. Documentation, the argument goes, finally matters.
Most IT teams will nod, save the link, and change nothing. Don't. If you operate an RMM console, this shift lands directly on your script library, your automation policies, and your 2 a.m. escalation path. The teams that act on it will resolve incidents in minutes; everyone else will still be reading 80 lines of undocumented PowerShell at 2 a.m. trying to figure out what it even touches.
What "The Spec Is the New Code" Means for RMM Teams
Kaseya isn't a neutral observer here. The company sits above VSA, Datto RMM, IT Glue, and BMS — the exact stack many MSPs use to run automation, documentation, and ticketing every day. When their CTO says prose beats syntax, he's describing the workflow RMM technicians already live in:
- Someone writes (or generates) an automation.
- Someone else runs it against hundreds of endpoints.
- A third person, eventually, has to explain what it did.
In the pre-AI world, the bottleneck was writing the script. Junior techs couldn't, so seniors wrote everything, and knowledge pooled around them. In the AI world, the bottleneck moves upstream and downstream of the code. Upstream: someone has to specify precisely what outcome is required. Downstream: someone has to verify the automation produced that outcome on real endpoints. Syntax is nearly free now. Intent and verification are not.
The Problem: Your Script Library Is Code With No Spec
Be honest about what your RMM's script library looks like today:
- Fix-Printer-NEW2.ps1, saved eight months ago by a tech who has since left.
- DiskCleanup_v3_FINAL.ps1, scoped to "all servers," description field empty.
- A remediation script that exits 0 on success — and also exits 0 when it did absolutely nothing.
Now layer AI on top. Copilot-style assistants will generate a plausible-looking remediation script in seconds. A technician pastes it into the RMM, tests it on one machine, and pushes it to 400 endpoints. The failure mode isn't broken syntax — AI rarely produces broken syntax. The failure mode is wrong intent: it stops a service it should have restarted, clears a queue it shouldn't have touched, or reports success while leaving the underlying condition untouched. Without a written spec, there is nothing to review the code against.
Then comes the fragmentation tax. In most shops, one automation lives across four systems:
- The alert fires in the monitoring console.
- The tech remediates in the RMM — or worse, RDP.
- The fix gets documented, maybe, in a wiki like IT Glue or Hudu.
- The ticket closes in a helpdesk that never knew an automation ran.
Whether your stack is ConnectWise Automate plus Manage, NinjaOne plus a PSA, or a patchwork of Nagios and spreadsheet handoffs, you know the tab-switching drill. The spec, the code, the execution record, and the outcome are four artifacts in four tools. These gaps exist because the tools were never architected to share state: RMMs were built as script runners with a code blob and a target list, monitoring platforms were built around thresholds, and documentation tools evolved as separate knowledge bases joined to the rest by webhook duct tape.
The operational cost shows up in places every sysadmin recognizes. When the alert re-fires at 2 a.m., the on-call tech isn't diagnosing the server — they're doing archaeology on a script, burning 10–15 minutes per unknown automation to reconstruct intent from variable names. Silent failures create reopen tickets: the script exited cleanly, the helpdesk closed the case, and the spooler stopped again an hour later. SLA reports miss every automated action because the helpdesk never saw it happen. New MSP hires inherit a 300-script library across 40 clients and spend their first quarter reverse-engineering it instead of resolving tickets. That's how you get technician burnout — and an IT manager who can't answer a simple question like what actually happened on that server last night without opening five consoles.
How AlertMonitor Puts the Spec Next to the Code
AlertMonitor treats the RMM as part of the monitoring platform, not a separate console bolted on the side. Technicians remotely view and manage endpoints, run scripts across device groups, push software, and open remote sessions — inside the same platform where the alerts fire, the patch status lives, and the tickets are tracked.
Concretely, the difference looks like this:
Old workflow: disk alert in the monitoring tab → RDP or switch to a separate RMM → hunt for the script in a library → run it → paste output into the helpdesk → hope someone updates the wiki.
AlertMonitor workflow: the disk monitor fires with its documented threshold and intent → the technician opens the linked automation, which carries its spec (what it does, what it touches, how success is verified) → runs it against the device group from the same screen → output, exit code, and verification results land on the same timeline as the alert and the ticket.
That last part is the quiet superpower: script results feed back into the monitoring data. A script that exits 0 but doesn't actually fix the condition gets caught, because the monitor re-evaluates and the alert stays open or reopens — visibly, on the same timeline. Success stops being an exit code and becomes a measured state.
This is exactly what makes AI-assisted automation safe to run in production. Every automation carries its intent, scope, and verification criteria with it, so a senior tech can review a copilot-generated script against the spec in two minutes before it ever touches a device group. A new hire reads the spec instead of reverse-engineering the code. And because automated remediations and manual technician actions are both visible in one timeline, your SLA reporting finally includes the work your automations do at 2 a.m. when nobody is watching. Patch status sits in the same platform, so post-Patch-Tuesday verification scripts tie straight back to the compliance reports your clients actually ask for.
Practical Steps: Make the Spec a First-Class Citizen This Week
1. Inventory your script library (30 minutes). Export every automation with its last-run date and description. Anything executed in the last 90 days with an empty description is your priority list.
2. Adopt a spec template — and require it before code. Before anyone, human or AI, writes another script, make them fill this out. Store it with the automation in the RMM, not in a separate wiki tab nobody opens mid-incident.
automation:
name: remediate-stopped-spooler
intent: >-
Restart the Print Spooler on print servers when it stops,
clearing 'cannot print' tickets before users notice.
trigger: monitor:service-spooler = Stopped for 5 minutes
scope: device-group/print-servers
touches: Print Spooler service only
verification:
- Spooler status is Running
- Spooler StartType is Automatic
rollback: none required; service start is non-destructive owner: itsvc-desk@contoso.example
**3. Convert your five most-used scripts to spec-first.** The verification section of the spec isn't documentation theater — it becomes real exit logic:
```powershell
<#
.SPEC
Intent: Ensure Print Spooler is Running and set to Automatic on print servers.
Touches: Spooler service only.
Verify: Exit 0 only if Status=Running AND StartType=Automatic.
Rollback: None required.
#>
$svc = Get-Service -Name Spooler -ErrorAction SilentlyContinue
if (-not $svc) { Write-Output 'FAILED: Spooler not installed'; exit 1 }
if ($svc.StartType -ne 'Automatic') { Set-Service -Name Spooler -StartupType Automatic }
if ($svc.Status -ne 'Running') {
Start-Service -Name Spooler
$svc.WaitForStatus('Running', '00:01:00')
}
$check = Get-Service -Name Spooler
if ($check.Status -eq 'Running' -and $check.StartType -eq 'Automatic') {
Write-Output 'VERIFIED: Spooler Running, StartType=Automatic'
exit 0
}
Write-Output "FAILED: Status=$($check.Status), StartType=$($check.StartType)"
exit 1
Exit 0 only after verification — never after effort. That single convention is what lets your monitoring layer trust, or distrust, an automation's result.
4. Sweep the environment with spec'd checks, not ad-hoc commands. Disk pressure is still the most common silent failure in Windows estates. Same discipline, different target:
<#
.SPEC
Intent: Flag any fixed volume at or over 85% used across all domain servers.
Verify: Output lists only offending volumes; empty output means a compliant estate.
#>
$servers = (Get-ADComputer -Filter "OperatingSystem -like '*Server*'").Name
$threshold = 85
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter 'DriveType=3' |
Select-Object PSComputerName, DeviceID,
@{n='UsedPct';e={[math]::Round((($_.Size-$_.FreeSpace)/$_.Size)*100,1)}},
@{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}} |
Where-Object UsedPct -ge $threshold |
Sort-Object UsedPct -Descending
Run it from AlertMonitor against your Windows Server device group and the output lands in the monitoring timeline next to the disk alerts it explains — no cross-referencing between tools required.
5. Hold Linux endpoints to the same standard. Same spec structure, different shell:
#!/usr/bin/env bash
# SPEC: Verify nginx is active and enabled; one restart attempt; exit 0 only if verified.
if systemctl is-active --quiet nginx; then
echo 'VERIFIED: nginx active'
exit 0
fi
systemctl restart nginx
sleep 3
if systemctl is-active --quiet nginx && systemctl is-enabled --quiet nginx; then
echo 'VERIFIED: nginx active and enabled after restart'
exit 0
fi
echo 'FAILED: nginx not healthy after restart attempt'
exit 1
6. Review AI-generated scripts against the spec. Always. Two minutes, five questions: What does it touch? What's the blast radius — which device group is in scope? Is it idempotent, meaning safe to run twice? What counts as verified? What's the rollback? If the code can't answer those, the spec isn't done and the script doesn't ship past the pilot group.
7. Wire the spec'd automations into AlertMonitor properly. Create the automation policy, scope it to the device group, set the monitor threshold as the trigger, and test on a pilot group first. From then on, every run — triggered or manual — appears in the same timeline as the alert that caused it and the ticket it resolves. Your 2 a.m. process becomes: read the alert, check the timeline, confirm the automation ran and verified, close the ticket. Minutes, not hours.
The Bottom Line
The Kaseya CTO is right, and he's describing your job whether or not you consider yourself a coder. The syntax layer is automating away. What doesn't automate away is knowing your environment well enough to specify what fixed means — and running your automations on a platform where the spec, the execution, and the verified outcome share one timeline instead of being scattered across four tools.
That's the difference between an RMM that runs scripts and an operations platform that closes the loop from alert to resolution. Write the spec like it's production — because now, it is.
Related Resources
AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.