Why Frontier AI Models Aren't Enough to Build on ServiceNow

It is a fair question, and we hear it a lot: why would I bother with a specialist tool like SnowCoder when I can just use Claude or ChatGPT? Those are excellent models. Hand one a self-contained coding problem (parse a file, refactor a function, write a set of tests) and it is genuinely brilliant. We use them ourselves. So this is not a knock on frontier models. It is an argument about what ServiceNow delivery actually is.

Here is the uncomfortable truth we have learned building on ServiceNow with AI every day: even the best frontier model on the market cannot reliably build ServiceNow from a user story on its own. And if the most capable model still cannot do it reliably, then the problem was never the model, which means a bigger, cleverer model next year will not fix it either.

Drop a story like “As an agent, I want to escalate incidents so that critical issues reach the right team faster” into Claude or ChatGPT and ask it to build. You get back exactly what you asked for: a table change, some UI, a business rule, maybe a flow. It runs. It demos. And a week later one of our senior developers is quietly unpicking it, because the story never contained the half of the job that actually mattered on that instance.

None of the frontier models are perfect. If any of them were, we would already have AGI. Perfect would mean handing a system a compressed, assumption-laden paragraph and getting back exactly the intent its author held in their head, and no model can do that. So the honest question is not “which model is smartest?” but “what has to sit around the model to make it reliable on ServiceNow?” Here is why that gap is structural, not a bug that the next release closes.

A user story describes the feature, not the operation

A story describes what the feature should do. It rarely describes how the change should be delivered, versioned, or unwound. A generic story only implies the functional work: tables, UI, scripts. The concerns that keep an instance healthy live somewhere else entirely: your update set strategy, how recently sub-production instances were cloned, the rollback plan, upgrade safety.

Those are operational concerns, and they live in your team's process, not in the story text. Unless something in the prompt signals that you care about them, the model optimises for answering what was literally asked. It is not being lazy. It is being accurate to the request.

Story:  "As an agent, I want to escalate incidents so
         that critical issues reach the right team faster."

What a capable model builds:
  - A "priority escalation" business rule on incident
  - A new choice field / state, plus a UI action
  - A notification to the assignment group

What the story never said, but your team assumes:
  - Which earlier user stories must already be in place
  - Which business rules, flows and jobs it touches or breaks
  - Which plugins it needs, and whether they are installed
  - Whether real data exists, or you must seed test data
  - The update set / scoped app strategy: scope, migration path

None of the second list is exotic. It is just invisible to anyone, human or model, who only has the story.

The model has no knowledge of your environment

Half of that guardrail list is instance-specific. Which plugins are activated. Whether you run MID Servers and where. What your scope strategy is. How stale your sub-production instances are. A model cannot verify any of it, because none of it is in the story and none of it is in its training data. It is a property of your instance on the day you deploy.

This produces a subtle and important failure mode: the model tends not to raise the questions it cannot ground. It will not ask “is this a scoped app or global?” if it has no way to check, even though for you that question is often the single most valuable thing the exercise could have surfaced. The unanswerable question is exactly the one worth asking, and it is the one an ungrounded model stays quiet on.

It learned from tutorials, and tutorials skip the caution

Almost everything written about ServiceNow online is a tutorial. Tutorials show you how to build something, then stop. They rarely cover the checks that stop that something from causing trouble later: will it slow the system down, will it clash with the features ServiceNow ships as standard, will it survive the next platform upgrade.

A model writes what it was taught, and it was taught mostly from those tutorials. So by default it builds the thing and skips the checks. A newer model knows more and reasons better than earlier ones, but it learned from the same lopsided material. Being smarter does not put back what the material left out.

Generic in, generic out

With no context, a model aims for the most broadly applicable answer: the response that would be reasonable across the largest number of instances. That is a sensible strategy when you know nothing about the target, and it is precisely why it trims the edge concerns that only matter to a mature team running a real, opinionated instance. Genericity is the correct behaviour under uncertainty, and it is also the behaviour that produces code your platform team will not accept.

“It runs” is not “it does what you meant”

This is the failure mode that costs the most, because it is the hardest to see. A model, together with the automated checks around it, can confirm that the code exists and functions. It cannot, on its own, confirm that the code actually executes the function the story described.

Those are different claims. “The escalation business rule fires without error” is a fact about execution. “The escalation business rule routes the right incidents to the right team under your real assignment logic” is a fact about intent, and intent was never fully written down. A green result against the first claim reads, to everyone glancing at the demo, like the second claim is true too. It is not. The two only coincide when the story was complete, and ServiceNow stories almost never are.

A model verifies that the code exists and functions. It does not verify that it is executing the functions the story actually described. On a mature instance those are two different things, and the gap between them is where the rework lives.

The assumption gap no model can close alone

Underneath all of this is one root cause. When a person writes a user story, they compress a large amount of unstated strategic intent into a short paragraph, trusting that a colleague on the same team will decompress it correctly, because that colleague shares the context, the conventions, and the scar tissue. A model shares none of that. It cannot fill assumptions it was never given, so it cannot recover the strategic intent the author left implicit.

That is why “just use a better model” does not solve it. Capability closes the gap between a complete specification and correct code. It does nothing for the gap between an incomplete story and the intent behind it, because that missing information was never in the model's reach. It was in your process. It is also why a generic LLM lands well below a grounded one on ServiceNow-specific work: the difference is context, not raw intelligence.

So why SnowCoder, and not just Claude or ChatGPT?

Because if the problem is missing operational context, the fix is not a bigger model, and a raw Claude or ChatGPT session gives you the model with none of the context. What actually closes the gap is two things working together: experienced ServiceNow people who carry the operational knowledge a story leaves out, and a system that feeds that context to the model and refuses to let intent stay implicit. That combination is what Kumoco delivers, and it is the design behind SnowCoder, our own AI product for ServiceNow, which runs capable frontier models as the engine rather than the whole answer.

• Ground the model in your instance. Feed real dictionary exports, scope strategy, and your conventions into the conversation, so the model can answer questions it otherwise could not ground, and raise the ones it should.
• Force intent to the surface before code exists. A structured pass across the business-analyst, architect, senior-developer, and security perspectives is built to challenge gaps rather than fill them silently, turning a lossy story into acceptance criteria that carry the operational concerns as first-class requirements.
• Separate “it runs” from “it does the job.” Test against described intent with per-story acceptance criteria, not just successful execution: the exact gap a bare model cannot see.
• Put the guardrails on rails. Route update sets, rollback, and destructive-change approval through gates by default, so the operational concerns a story omits are handled by the system and an expert reviewer, not by luck.

The takeaway is not that Claude or ChatGPT are weak; they are remarkable. It is that ServiceNow delivery is a context problem wearing a coding problem's clothes. Give the best model in the world an incomplete story and no environment, and it will faithfully build the incomplete story. Give it your instance, your conventions, expert oversight, and a process that refuses to let intent stay unwritten, and the same model becomes genuinely useful. The intelligence was never the bottleneck. The context was. And closing that gap is exactly what we do.

Related reading

• Getting Started with AI-Powered ServiceNow Development
• Flow Designer vs Business Rules: When to Use Each
• The ServiceNow Technical Debt Guide