Notifications
Clear all
Topic starter
01/08/2026 8:53 pm
TL;DR: Watching engineers use AI coding agents on real work showed that cheap models often shift cost from tokens to human correction time, shadow usage, and slower delivery, according to StackHawk. The governance lesson is that model choice now behaves like a control decision, not a personal preference, because the real risk sits in workflow economics and ungoverned tool use.
NHIMG editorial — based on content published by StackHawk: What We Learned Watching Engineers Use AI Agents for Real Work
By the numbers:
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
Questions worth separating out
Q: How should security teams govern AI agents that choose tools at runtime?
A: Security teams should treat runtime tool choice as a governed access event, not a normal application call.
Q: Why do cheaper AI coding models often create more risk than they remove?
A: Because token savings can be overwhelmed by correction time, review fatigue, and untracked workarounds.
Q: What breaks when engineers can choose AI models without oversight?
A: Accountability breaks first, then visibility, then policy enforcement.
Practitioner guidance
- Classify model access by task risk Give routine code assistance to lower-risk models only where failure cost is limited, and reserve stronger models for architecture, security-sensitive, or multi-file changes.
- Track correction cycles as a governance metric Measure how many reprompts, clarifications, and manual fixes each agent-assisted task requires.
- Bind AI coding sessions to named identities Require authenticated users, approved workspaces, and auditable keys or tokens for every coding agent session.
What's in the full article
StackHawk's full blog covers the operational detail this post intentionally leaves for the source:
- A task-by-task breakdown of when engineers should stay on a cheaper model versus escalate to a stronger one
- The specific workflow patterns the author observed when teams corrected agent output in real engineering work
- The practical cost framing used to compare token spend with engineer time and delivery impact
- The source post's examples of how teams handled model choice across routine and security-sensitive work
👉 Read StackHawk's analysis of AI coding agent model choice and engineer time →
AI coding agents and model choice: what governance teams are missing?
Explore further
01/08/2026 9:02 pm
Model choice is now an access governance issue, not a developer preference. StackHawk's pattern analysis shows that the economic decision about which model to use directly affects who can act, how reliably work is reviewed, and whether policy can be enforced. Once engineers can change model tier outside central oversight, the organisation has created a governance gap that looks operational but behaves like privilege drift. Practitioners should treat AI coding model assignment as a controlled entitlement.
A question worth separating out:
Q: When should teams escalate from a cheap model to a stronger one?
A: Escalate when the task is security-sensitive, spans multiple files or systems, or carries a high cost of failure. The right test is not the model’s sticker price but whether repeated correction would consume more value than the stronger model would cost. That is the point where cheap becomes expensive.
👉 Read our full editorial: AI coding agent model choice is an IAM and governance decision
