AI Did Not Make Junior Developers Risky. Unreviewed Work Did.

The industry talks about junior developers using AI like the junior is the main risk.

That is too convenient.

A junior can absolutely ship bad AI-generated code.

So can a senior.

So can a staff engineer under deadline pressure.

So can a team with no tests, unclear ownership, and code review that nitpicks style while missing behavior.

The problem is not that juniors use tools.

The problem is companies letting risky work pass through weak systems, then blaming the lowest-status person when something breaks.

Computer Code GIF by HACKER.REHAB - Find & Share on GIPHY

Discover & share this Computer Code GIF by HACKER.REHAB with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Security shows the double standard

Take a basic authentication example.

A service verifies a JWT signature but forgets to validate issuer or audience:

const payload = jwt.verify(token, publicKey);
if (!payload.sub) {
  throw new Error('Invalid token');
}

The missing checks are the boring part that matters:

if (payload.iss !== config.allowedIssuer) {
  throw new Error('Unauthorized token issuer');
}

if (payload.aud !== config.expectedAudience) {
  throw new Error('Unexpected token audience');
}

That is not an "AI problem." It is an engineering-control problem.

If a junior asks AI, "What claims should a JWT validation path check?" and then uses that answer to inspect the code, that can be a good learning move.

If anyone copies generated auth code into production without tests or review, that is reckless.

The difference is verification.

The risk is real

Security concerns around AI-generated code are real.

AI can suggest outdated libraries, miss authorization boundaries, invent safe-looking checks, or generate code that passes happy-path tests while failing under real attack scenarios.

But security risk existed long before AI.

OWASP's Top 10 lists Broken Access Control as the number one 2021 web application security risk category. It also lists Identification and Authentication Failures as a major category.

Sources: OWASP Broken Access Control and OWASP Identification and Authentication Failures.

Those are not "junior used ChatGPT" categories. They are systems failing to enforce trust boundaries.

NIST's Secure Software Development Framework, SP 800-218, emphasizes secure practices across the software lifecycle, including defined roles, testing, vulnerability review, and risk response.

Security is a lifecycle responsibility. It cannot be reduced to "did the junior use AI?"

The pattern that actually breaks teams

Here is the pattern that should worry companies:

Weak system	What happens
No clear security checklist	Review depends on memory and senior availability.
No threat modeling	Teams do not know which risks matter.
No auth regression tests	Small claim-check bugs survive.
No AI usage policy	Tool use becomes hidden or selectively punished.
No safe escalation path	Juniors stop raising uncomfortable concerns.
No ownership of deferred risk	"Later" becomes "never."

That is how security bugs survive. Not because a junior asked an AI assistant to explain JWTs.

AI can teach vocabulary, not judgment

One underrated use of AI is vocabulary.

Juniors often see a problem before they know how to name it.

They might notice:

• this token accepts too much
• this endpoint trusts a client field
• this query exposes another tenant's data
• this permission check happens only in the UI
• this webhook handler is not idempotent

AI can help map those observations to terms:

• issuer validation
• audience validation
• broken access control
• authorization bypass
• tenant isolation
• idempotency
• replay risk
• least privilege

That does not make AI a security reviewer. It makes AI a learning layer.

The human process still has to verify the answer.

The data supports caution, not panic

Stack Overflow's 2025 Developer Survey says AI use is widespread, but trust is low. More developers distrust AI output accuracy than trust it: 46% versus 33%. [Stack Overflow AI survey]

Source: Stack Overflow 2025 Developer Survey.

That is the right posture for security-sensitive work:

useful, but not trusted blindly.

The research on novice programmers is also cautious. The Widening Gap found that GenAI can help novices complete tasks, but weaker learners may struggle to reject incorrect suggestions. [The Widening Gap]

A 2025 systematic review on junior developers and LLMs found both positive and negative perceptions across the literature. [Junior developers and LLMs SLR]

That is not a ban argument. It is a governance argument.

Review should follow the risk

Teams need different review standards for different code.

Changing button copy is not the same as changing authentication logic.

A risk-based review model might look like this:

Code area	AI assistance allowed?	Review expectation
UI copy	Usually low risk	Normal review.
Styling	Usually low risk	Visual check.
Business logic	Allowed with validation	Tests for behavior and edge cases.
Database migrations	High caution	Human review, rollback plan, test data.
Auth and permissions	High caution	Security review, threat model, regression tests.
Payments	High caution	Lifecycle tests, idempotency, reconciliation.
Secrets and infrastructure	High caution	Approved tooling, least privilege, audit trail.

This is stricter than yelling "no AI," and it is more useful.

Bad leadership makes people hide tool use

If leadership treats all AI use as suspicious, juniors will not stop using AI.

They will stop disclosing it.

That is worse than disclosure.

The company loses visibility into:

• what tools are being used
• what code may have been generated
• what data may have been pasted
• which developers need coaching
• which patterns keep causing confusion

A useful AI policy should make disclosure normal, not humiliating.

Something like:

AI assistance:
- used for explanation, edge-case brainstorming, or draft code

Developer responsibility:
- author owns final code
- risky code requires tests and human review
- private code may only be used with approved tools

That gives reviewers something concrete.

Seniors have to review better too

Senior engineers cannot just complain that juniors do not know enough.

They have to decide whether they are reviewers, mentors, or gatekeepers.

A useful senior review asks:

• What behavior does this code guarantee?
• What cases are not covered?
• What did the AI suggest that you rejected?
• Which docs did you verify against?
• What would break if this assumption is wrong?
• How does the test prove the security boundary?

A weak senior review says:

"This looks AI-generated."

That is not enough.

Maybe it is generated. So what?

Is it correct? Is it tested? Is it safe? Is it maintainable? Does it respect the data boundary?

Those are the questions that matter.

Example: JWT validation checklist

For security-sensitive code, teams should teach checklists.

For JWT validation, a basic review checklist might include:

Check	Why it matters
Verify signature	Confirms token integrity.
Validate issuer	Rejects tokens from unexpected authorities.
Validate audience	Ensures token is meant for this service.
Validate expiration	Prevents stale token use.
Validate tenant mapping	Prevents cross-customer access.
Test failure cases	Confirms invalid tokens are rejected.
Log safely	Helps investigation without leaking secrets.

That checklist is useful no matter who wrote the first draft.

Bottom line

AI did not make junior developers risky.

Unreviewed work is risky. Ambiguous ownership is risky. Security-sensitive code without tests is risky. Leadership that punishes disclosure is risky.

If companies want safer software, they need review systems that inspect behavior, teach risk, and make AI use governable.

Blaming juniors is easier. It is also weaker engineering.

Interested in security, AI, and engineering review culture? Explore #security on DEV.