Career Direction

Decision

My primary career target is AI Security / Security Engineering, focusing on securing AI-enabled applications, APIs, and their supporting infrastructure.

I will build on my Computer Science degree and existing software engineering experience rather than treating security as an unrelated new career.

The order in which I build the supporting skills is set by My Master Roadmap: foundations first (C, operating systems, networking, identity and cryptography), then application and systems security, then the AI security phases. The direction is fixed; the sequence comes from the roadmap. Right now that means Phase 1 — C and computer science fundamentals.

The actual bet

Don't bet my life on "I'll become an AI Security Engineer." Bet the next year on finding out whether I'm unusually good at securing complex software systems. Prediction requires luck; evidence doesn't. I need more evidence, not another career theory.

Why this direction

I want a technical career that supports international employability, remote opportunities, possible relocation, and long-term entrepreneurship.

AI Security connects several capabilities I want to develop:

Software and application security
Backend engineering and API security
AI application security
Linux, networking, and infrastructure
Cloud security and deployment
Security testing, threat modelling, and risk analysis

My existing project, VeriDoc, provides a starting point for demonstrating software engineering and applied security. It does not, by itself, establish professional competence in AI Security. I need additional evidence that directly demonstrates security skills.

Career hierarchy

Primary direction

AI Security / Security Engineering.

Core supporting skills

Application security and secure software design
Authentication, authorization, and API security
Python and Go for practical security engineering
Linux, networking, and system administration
Cloud infrastructure and deployment security
AI application security, including LLM-specific risks

Adjacent opportunities

Application Security Engineer
Product Security Engineer
Cloud Security Engineer
Security Engineer
AI Security Engineer
AI Engineer, where the role supports my longer-term direction

These are related options, not a requirement to pursue every title simultaneously.

Career ladder (don't target one job title)

Software / Security Engineer — backend, Linux, networking, cloud, AppSec, auth, APIs, databases, security testing.
Application / Product / Cloud Security Engineer — while getting unusually strong in AI systems.
AI Security Engineer / AI Application Security Engineer.
AI Security Architect / Security Researcher / Staff Security Engineer / AI Security Lead.
Eventually: founder / independent researcher / consultancy / security product company.

Betting only on a job title that did not exist a few years ago is fragile. This ladder is more robust.

My sweet spot

Builder + Defender + Writer. Not developer ×4, not security ×3.

Builder — "I can construct the system."
Defender — "I understand how it fails or is attacked."
Writer — "I can explain the problem to humans."

That combination is rare enough to build a career around.

Project selection rule

Before starting a substantial project, I should be able to explain:

Which security or engineering skill it develops.
What concrete artifact I will produce.
How I will test or evaluate the result.
How the work could demonstrate competence to an employer.
Why this project is more valuable than finishing an existing commitment.

Prefer projects that combine several of these benefits without becoming unnecessarily large.

Learning rule

I will learn a technology when it supports a current project, fills a demonstrated skills gap, or appears repeatedly in relevant job requirements.

Interest alone is not sufficient reason to make it a priority.

A technology can remain on my future-learning list without becoming part of my current plan.

Evidence before changing direction

I will not change my primary career target simply because another field looks interesting or temporarily appears more attractive.

I will reconsider the direction when there is meaningful evidence, such as:

Repeated feedback showing a major mismatch between my skills and target roles.
Consistent hiring evidence suggesting a better adjacent entry point.
Actual project experience that materially changes my understanding of the work.
A sustained change in my goals or practical constraints.

When reconsidering, I will record the evidence, alternatives, and consequences before making a new decision.

Evidence that would make me abandon this direction

If sustained real work shows:

I prefer building products to breaking systems → product / adjacent engineering.
I love architecture but hate security research → systems engineering.
I enjoy AI but dislike security → AI engineering.
I love infrastructure more than application development → cloud / platform engineering.
I build useful tools but dislike security teams → product / entrepreneurship.
Writing and explaining motivate me more than engineering → writing / research career.

This is still a hypothesis

I have not yet put in ~500 serious hours of doing AI security (finding, reproducing, threat modeling, writing reports, testing real AI apps, publishing findings). Until I have, "AI Security is my calling" is an assumption, not a conclusion.

What success looks like

Near term

Present VeriDoc clearly and confidently.
Maintain a strong CV, GitHub profile, and portfolio.
Build practical security projects with documented testing.
Identify realistic entry-level roles and their recurring requirements.
Begin a consistent application and networking process.

Following 6–12 months

Have several credible examples of security engineering work.
Demonstrate practical ability through code, tests, technical write-ups, and project explanations.
Apply consistently to suitable roles, including adjacent software and security roles.
Use application outcomes and technical feedback to guide further learning.

These are target outcomes, not guarantees.

Current constraints

Avoid spreading effort across too many unrelated technologies.
Prefer practical work over endless preparation.
Keep the learning plan small enough to execute consistently.
Do not delay suitable job applications until every skill feels complete.
Preserve time for personal writing without making it compete with every technical interest.

Review policy

Review this decision quarterly or when significant new evidence appears.

Do not reopen it during ordinary weekly planning.