Take a public job posting for a NetSuite developer, strip out everything that identifies the employer, and classify every task in it into one of four buckets: the agent does it from a prompt today, the agent could do it as an unattended script it writes and a human deploys, the human's judgment is the core but the agent materially accelerates it, or it's structurally beyond the agent for a named reason.
On the sample posting, a junior-to-mid developer seat inside an IT delivery chain, 58% of the task content is automatable today, 81% is materially accelerated, and 19% is structurally human. The report's summary of the result: the posting hires for task execution, the tasks are what the agent does, and what survives is the judgment layer the posting treats as secondary.
That's the Role Exposure Analysis prompt, and it went into the Sonar AI Prompt Library in September. If you're new to this, Sonar AI is an AI agent that runs inside NetSuite. Every prompt in the library is a playbook that I engineered and tested against live NetSuite data, and you run it inside your own account, against your own records. Nothing leaves the account, and nothing is written to it.
The Four Classes
The report is careful about its categories, and the care is the point. "By" means the agent performs the task from a prompt, the human reviews and approves, and every mutation is dry-run previewed and logged. "Agent" means automatable as a headless script the agent writes and maintains, with deployment through the NetSuite interface always done by a human. "With" means the human's judgment or presence is the core and the agent accelerates evidence-gathering, drafting, and verification. "Human" means a named boundary: code deployment, workflow construction in the interface, being in the room with the business, control attestation, administering external systems, or owning a decision.
When a task sat between two categories, it got the more conservative one. That rule is stated up front and applied throughout.
Coverage by Area
Five responsibility areas, each with an assumed share of a typical week. Development and customization is 40% of the week and 68% automatable, because writing SuiteScript against verified field IDs, building custom records, and sweeping execution logs for errors are what the agent does in one pass. Quality, performance, and governance is 66% automatable, with monitoring as a scheduled script and documentation generated from live introspection of the account rather than from memory. Integration and data flow is 48%, because the NetSuite side is query and RESTlet work while the middleware and CRM side lives outside the account. Collaboration and improvement is 32%. Solution design and delivery is 15%, and the report says that's where the role's durable value lives.
The weights are assumptions, listed in the assumptions section, and the report says that adjusting them within reasonable ranges moves the total between roughly 50 and 65%.
Grounded in an Account
The percentages are judgment estimates, and the report says so in the first paragraph. But the claims about what the work consists of are grounded in three queries against a production account, reproduced in full. 1,165 script records across seventeen types, mostly bundle-owned, which is what "maintain customizations" means in practice. 4,078 custom fields, which is what "custom records and fields" means at scale. 2,551 execution log entries in thirty days, 250 of them errors, which no developer reads daily and a scheduled agent reads nightly.
How the Role Changes
The section I'd send to a hiring manager is the one on what happens to the seat. Run the week through the classifications and the shape of the job inverts: the posting describes someone who spends most of their time producing and a minority deciding, and with an agent producing, the same person spends most of their time specifying work precisely, reviewing agent output critically, owning the deployment gate, and doing the architecture and relationship work the posting lists almost as an afterthought.
The uncomfortable implication is stated. The low experience bar exists because the organization expects to feed this person small, well-scoped tasks, and small, well-scoped tasks are what agents absorb first. The version of the role that stays valuable is the senior version. An organization hiring at this level should either raise the judgment bar and lower the typing bar, or hire deliberately for apprenticeship, a junior who learns by reviewing agent output under supervision.
The Honesty Notes
Three things the analysis couldn't assess and one claim to hold loosely, in the report's own words. The posting names internal systems only generically, so the integration scores rest on the typical pattern rather than the employer's architecture. The posting says nothing about the team around the seat, and a lone developer scores differently from one of five. Nothing measures the employer's code-review culture, which determines what reviewing agent output really costs. And the claim held most loosely is the 40% weight on development work: if the seat is really a support role wearing a developer title, the automatable total drops several points, because investigation skews toward acceleration rather than performance.
The disclosure at the end is that the author of the document is also the developer of the agent, and that the conservative classification rule is there to compensate. The percentages measure task content, and the report says twice that they are never a statement about the value of the person in the role.
Wrapping Up
Role Exposure Analysis is in the paid tier of the library. The full sample report is online, and I covered the whole September release in a separate post.
I built the agent, so I have an interest in the answer. That's why the rule is conservative when in doubt, and why the honesty notes are mandatory.