When AI Writes Code, Programmers Still Need to Model the Threats

Security starts before reviewing the code

An AI assistant can produce a convincing implementation without deciding which risks a business should accept. For programmers considering their next skills, application security offers a concrete direction: understand the system, describe how it could be misused, and check whether the implementation enforces the intended boundaries. This is our editorial career assessment, not a prediction of guaranteed vacancies.

OWASP describes threat modelling as a repeatable process for understanding a system, identifying threats and deciding how to address them. It recommends beginning during design and revisiting the model as the system changes. The work includes understanding data flows, trust boundaries and interactions between components. [OWASP: Threat Modeling Cheat Sheet]

The application and the coding environment

AI-assisted development also brings questions about the development environment. OWASP's guidance covers untrusted instructions encountered by coding agents, dependency verification, excessive tool permissions and sensitive context sent to providers. It calls for reviewing the complete change and independently checking security-sensitive behaviour instead of treating generated tests as sufficient assurance. [OWASP: Secure Coding with AI Cheat Sheet]

Our suggested working routine separates those concerns. First, review what a feature permits users to do. Then inspect what the coding assistant could access while making it. A restricted application can still have an unsafe development process; a restricted coding tool does not prove that its application code is correct.

A fictional document-portal review

Consider this invented training scenario: an assistant adds document search to a portal used by several fictional customers. Search works in the happy-path demonstration. The reviewing programmer asks whether changing a document identifier could expose another customer's file, and whether cached results remain separated between accounts. These questions turn an attractive demo into explicit engineering requirements.

The engineer writes two synthetic customer accounts and a small collection of harmless documents into a local test application. They test cross-account access, removal of permissions and cached responses. They also inspect the proposed dependency changes. The deliverable is a short record connecting each risk to its control and test, including unresolved questions for a more experienced reviewer.

Build judgement alongside implementation skills

For a developer, a practical learning route is to deepen knowledge of authentication, authorisation, HTTP, databases and automated testing, then practise explaining a risk without relying on scanner output alone. Experience maintaining a real application provides useful context, but access to sensitive systems must follow the employer's training and review process.

A small portfolio exercise can show the original flaw, the corrected behaviour and a test that would catch its return. Ask a peer to challenge the assumptions. The useful evidence is your reasoning about what should be allowed, not the number of vulnerabilities an AI tool claims to have found.

Three practical first steps

• Map one local application's users, data flows and trust boundaries before changing it.
• Use fictional accounts to test one access-control rule, including a case that must fail.
• Review the complete AI-generated change and explain the remaining risks to a peer.

These are learning suggestions, not a security certification or evidence of hiring demand. Tools and reviews can miss flaws; production decisions need the organisation's security ownership and experience. Sources checked 13 October 2026.

Sources & editorial note

• OWASP: Threat Modeling Cheat Sheet
• OWASP: Secure Coding with AI Cheat Sheet

This career guide distinguishes source-backed descriptions from BELL RIVER’s editorial suggestions. Learning exercises are illustrative, not employer requirements, certifications or promises of employment. Overseas examples do not establish demand or eligibility in the UAE.