Code-first ServiceNow
Build ServiceNow apps from Git: architecture, workstation, SDK/Fluent workflow and AI-agent guardrails.
Start with Part 1
1Part 1 of 4ServiceNow26 September 202611 min readCode-first ServiceNow: why Git, not the instance, now holds my application
Building ServiceNow apps by clicking through forms works, but it is hard to review, hard to diff and hard to hand to an AI agent safely. This is the architecture I'm using instead: Coder workspaces, Node 24, the ServiceNow SDK with Fluent, Git, pull requests, ATF and gated promotion from DEV to TEST to PROD.
2Part 2 of 4ServiceNow26 September 202611 min readBuilding a ServiceNow code-first workstation: Ubuntu 24.04, Docker, Coder and Node 24
Code-first ServiceNow development needs a workspace you can rebuild in minutes and trust with credentials. Here is how I set one up: an Ubuntu 24.04 host, Docker, a Coder workspace template, Node 24, a pinned ServiceNow SDK and instance authentication that never touches Git.
3Part 3 of 4ServiceNow26 September 202612 min readFrom .now.ts to production: the ServiceNow SDK, Fluent and Git workflow
What code-first ServiceNow development looks like day to day: a Fluent project layout, short TypeScript examples that compile with SDK 4.13.0, the build and deploy loop, branching and pull requests, CI quality gates, ATF, and a promotion path from DEV to TEST to PROD that keeps the SDK away from production.
4Part 4 of 4ServiceNow26 September 202611 min readGoverning code-first ServiceNow: environment tiers, AI-agent guardrails and when to stay native
Code-first ServiceNow only works if the guardrails are as deliberate as the tooling. This part sets out environment tiers, an AI agent access model where agents work in LAB, PDI and DEV but never touch PROD without human approval, secret handling, audit evidence, and a balanced guide to when Fluent is right and when native ServiceNow development is the better tool.