|
Key takeaways • AI agents can now write code faster than most teams can review it, which makes review the actual bottleneck in agent-assisted development. • Treating that as a tech-lead problem, scoping the task and reviewing the plan before any code exists, cuts the review burden that follows. • A plan that a colleague could sanity-check in five minutes is usually enough to catch the decisions that matter. • On ServiceNow, a deliberate human pass on the data model, security and ACLs, and form behavior still pays for itself, regardless of how good the plan was. • The entry-level ServiceNow developer role is shifting toward a junior-architect model: smaller scoped ownership and judgment-building starting earlier in a career. |
If you're combing through every line an AI agent wrote before you feel comfortable shipping it, you might be solving the right problem at the wrong stage.
AI can write code fast enough now that reviewing all of it carefully has become its own bottleneck. Some teams are spending as much time checking generated code as they used to spend writing it. The instinct that follows is to get better and faster at review. That instinct is aimed at the wrong stage of the work. Working well with AI takes tech-lead skills: setting a clear goal, delegating intelligently, reviewing critically. Those are different muscles from the ones solo coding builds, and the fix is catching problems earlier, before there's any code to review at all.
It starts before the code
An AI coding agent behaves a lot like a capable developer dropped into a project cold. Hand any capable developer a vague task with no scope, no stated goal, and nothing to fall back on for decisions, and they'll guess. And you'll end up reviewing everything they built line by line, because you have no other way to know if it's right. Give the same person a clear plan, explicit goals, and the constraints the solution has to respect, and the review burden drops enormously. You still haven't trusted the output blindly. You reviewed the thing that actually mattered, earlier, while it was still cheap to change.
Here's an analogy worth keeping. Programming languages have always moved up a level of abstraction: assembly, then C, then JavaScript. Each move meant developers stopped needing to scrutinize the layer below to trust it. The prompt is becoming the new top layer, the thing you actually craft and review carefully. The code an agent produces from it is closer to what a compiler emits: technically inspectable, and rarely where a competent person spends their attention.
That's the shape a chunk of daily coding work has actually taken over the past six to twelve months. Plan first, in enough detail that someone could sanity-check it in five minutes. Let the agent execute. Check whether it reports deviating from the plan. If it didn't, there usually isn't much left to review, because the review already happened.
So if you're still asking "did I check this code closely enough," that's the question one step too late. The one that actually predicts whether the output is any good is "did I write a plan someone else could have followed."
Why that isn't the whole answer on the platform
Even once you've internalized that, a chunk of the ServiceNow surface still deserves a direct human look, independent of how good the model gets or how good your plan was. Current models are already strong (sometimes genuinely impressive) at proposing a data model. There are still areas where the output needs closer eyes. Form design is one example today, where ATFs cover a lot of ground but not everything a form actually does, so a form that passes tests can still miss a real user interaction. The specific weak spots will shift as models improve, so keep a mental list of where your current toolchain needs your review, and update it as things change.
Security and ACLs are similar. Any competent ServiceNow team will test what they ship, so the question isn't whether you'll notice a missing ACL, it's whether you'll notice a subtly wrong one, the kind that lets the wrong role read the wrong record in a scenario your test suite didn't imagine. On a platform where what you ship is a live business system, keeping a deliberate human pass on the data model, security, ACLs, and form behavior is still cheap insurance.
While you're doing that pass, treat the agent as a collaborator you can interrogate. Ask it to justify its choices on the data model, walk you through its ACL logic, or explain why it structured a form the way it did. That conversation tends to surface two useful things: assumptions the model made that might not hold up, and reasoning patterns worth stealing for next time.
So the honest answer to the question in the title is: mostly, yes, developers working well with AI already operate a lot like tech leads. On this platform there's still a specific set of things where a second human look pays for itself.
Where the next generation of judgment comes from
The tech-lead framing assumes you already have the skills to review a plan well, or can get them. ServiceNow developers often have a real head start here, because the role often pulls you into client conversations, BA reviews, and cross-team scoping that a typical solo coder rarely sees. That exposure is a lot of what makes reviewing a plan well possible in the first place. If your current role doesn't put you in those rooms yet, treat that as the next thing to work on: ask to sit in on scoping calls, offer to co-run a requirements workshop, get closer to the people whose problems you're solving. The skill compounds quickly once you start.
There's a harder version of the same question worth sitting with. Reviewing a plan well takes judgment that's traditionally been built by implementing things for years. If the junior-level implementation work that built that judgment keeps shrinking, where does the next generation of judgment come from?
One framing we found genuinely useful: the entry-level job may start looking a lot like a junior architect. It sounds contradictory at first, and it isn't. If the mechanics of writing code get faster, the entry point can shift up the stack. New developers start architecting from day one, on small, well-scoped pieces of work, with a lot of scaffolding around them, and grow the scope gradually as their judgment does. Less time on CRUD boilerplate, more time thinking about what the CRUD is for. That's arguably a better trajectory than the one most of us actually had.
What to actually do about it
Review on ServiceNow has always meant more than reading pure code: data models, ACLs, form behavior, flow logic, integrations, business context. Keep all of that. What changes is where you put your sharpest attention. Before an agent touches a task, write down what it should accomplish and what it should not do. A few sentences is enough. If you can't write them, that's the gap to close first.
On this platform specifically, keep the deliberate human pass on the data model, security, ACLs, and form behavior regardless of how good the plan was. Those are the places where a plausible result and a correct one diverge, and where the cost of being wrong lands on a live business system.
And while you're reviewing, push back on the model. Ask it to defend its choices in plain language. Sometimes you'll learn something worth carrying into the next project. Sometimes you'll surface an assumption that turns out to be wrong. Both outcomes are worth the two minutes it takes to ask.
Over to you
If you're doing agent-assisted work on ServiceNow, where does your review time actually go these days? Are you catching things in code review that a better plan would have caught earlier? And on the junior architect trajectory: does it sound right from where you're sitting, or off? Drop your take in the comments; we read them. 👇
This post was drawn from a discussion between the ServiceNow Developer Advocate team on the topic. A couple of the sources that shaped our thinking:
