Theory First, Chaos Later: Why I'm Structuring My AI Security Journey Like an Engineer
Digital Insights

Theory First, Chaos Later: Why I'm Structuring My AI Security Journey Like an Engineer

Mar 20, 2026
7 min read
Kuldeep Singh

When you decide to learn 'AI Security,' the internet immediately overwhelms you with viral exploits. But I've built enough production systems to know better. Moving fast without theory is expensive.

๐Ÿ“ Journey Navigation Prev: Day 1 โ€” The AI Security Roadmap ยท Next: Day 3 โ€” From Theory to Packets | Day 1 | Day 3 | Day 5 | Day 6 |

Status: Day 2 of 90-day AI Security journey

The Temptation

When you decide to learn "AI Security," the internet immediately overwhelms you with:

  • "Build a prompt injection tool in 5 minutes"
  • "Here's how to jailbreak ChatGPT"
  • "Watch me find a vulnerability in 30 minutes"

It's intoxicating. The action bias hits hard.

But I've built enough production systems to know better. Moving fast without theory is expensive.

So instead of chasing viral exploits, I did something that felt almost irresponsible in the "learn hacking fast" era: I spent my 2 hours of post-work study time purely on documentation and going in depth in theory.

What I Built Today

I structured a complete 90-day learning journey:

The Numbers:

  • 12 weeks (one per module)
  • 82 labs (hands-on practical exercises)
  • 60 projects (real tools I'll ship on GitHub)
  • 34 core concepts for Week 1 alone

But here's what matters more: I mapped out theory FIRST, then labs, then projects. In that order. This is the same principle I laid out in Day 1's roadmap โ€” foundations before tools.

Week 1: Networking + Linux + Threat Mindset

Instead of "learn TCP," I broke it into:

  1. What a network actually is (structure, devices, architecture)
  2. How data moves (IP, MAC, protocols)
  3. Why ports matter (and why 80/443/22 matter specifically)
  4. What can go wrong (attacks, threats)
  5. How to defend (hardening, monitoring)
  6. Why this matters for MY backend โ†’ AI Security transition

Real example: Most hackers learn DoS attacks as "cool tricks." But I'm learning them as "architectural vulnerabilities in systems I've built." Because they are.

When you send 1000 requests/second to an API you designed, suddenly you understand:

  • Why load balancers exist
  • Why rate limiting matters
  • Why you need monitoring that actually works
  • Why your infrastructure has a cost limit

Theory vs. Chaos: A Backend Engineer's Perspective

I've built APIs. Production APIs. I know:

  • Code quality matters
  • Architecture decisions haunt you
  • Scalability is a feature, not an afterthought

The same principle applies to security. And especially to AI security.

Here's why theory matters before labs:

1. Context Creates Speed

If I dive into "Prompt Injection Lab #1" without understanding tokenization, context windows, and system prompts, I'll:

  • Spend 3 days confused why my payload didn't work
  • Miss the actual vulnerability pattern
  • Remember individual tricks instead of principles

But if I understand the theory first:

  • I see why the injection works
  • I can predict where ELSE it'll work
  • I can build a tool that finds these patterns automatically

2. Attack Surface Thinking

Most security learners memorize attacks: SQLi, XSS, CSRF, etc.

But I'm learning them as architectural patterns:

  • SQLi = untrusted input + database trust
  • IDOR = missing authentication checks
  • CSRF = state-changing requests without validation
  • Rate limiting bypass = missing resource constraints

Once you see the pattern, you see it EVERYWHERE. In APIs you build. In systems you design. In AI models you deploy.

3. Defensive Intuition

Here's the secret weapon: knowing how to attack makes you naturally defensive.

When I understand SYN floods, I automatically think about:

  • Connection limits
  • Timeout configurations
  • Resource pooling

When I understand packet sniffing, I automatically want:

  • HTTPS everywhere
  • Encrypted internal communication
  • VPN for untrusted networks

When I understand IAM vulnerabilities, I think:

  • Least privilege
  • Audit logs
  • Role-based access

This isn't memorization. It's intuition born from understanding.

The 34 Concepts I'm Starting With

For Week 1 alone, I documented:

Networking Fundamentals (8):

  • Networks, IPs (public/private), MAC addresses, devices, TCP/IP model, protocols, ports, wireless

Network Security (4):

  • Firewalls, VPN, proxies, segmentation

Attacks & Threats (10):

  • Malware types, sniffing, DoS/DDoS, SYN floods, ICMP floods, IP spoofing, MITM, replay attacks, smurf attacks

Defense & Hardening (8):

  • Attack surface, hardening, patching, baseline configs, authentication/MFA, monitoring, SIEM, pen testing

Cloud Security (4):

  • VPC, security groups, IAM, encryption

Why This Matters for YOU (Backend Engineers Transitioning)

Here's my unfair advantage: I already think in systems.

I understand:

  • Microservices = network segmentation
  • APIs = ports + protocols + authentication
  • Load balancing = distribution + trust
  • Reverse proxies (NGINX) = entry points + filtering
  • Databases = restricted zones

I don't need to learn "how the internet works." I need to learn "how to break it."

And you don't learn that by memorizing CVE numbers. You learn it by understanding:

  • What assumptions the system makes
  • Where those assumptions break
  • How to exploit that breakage
  • How to defend against that exploitation

That's theory. That's the foundation.

The Plan Going Forward

Starting tomorrow:

Week 1 Hands-On:

  • Lab 1: Network Basics (wireshark + tcpdump)
  • Lab 2: Scanning (nmap fundamentals)
  • Lab 3-5: Deep dives (TCP behavior, firewall filtering)
  • Lab 6-17: Progressive difficulty up to attack chain simulation
  • Projects 1-10: Build real tools (port scanner, banner grabber, reverse shell generator, multi-tool recon)

Each lab will reference the theory. Each project will prove the concepts work.

But I'm not starting labs blind. I have the foundation.

The Real Insight

In an industry obsessed with "move fast and break things," taking a day to document theory feels radical.

But here's what I've learned from 6+ years of backend engineering:

  • Moving fast WITH a solid foundation = actually fast
  • Moving fast without foundation = expensive mistakes later
  • Theory isn't the opposite of speed, it's the prerequisite

So yeah, I spent 2 hours today learning and writing notes, and an extra 30 minutes sharing my journey, instead of jumping straight into "learning hacking."

Tomorrow, I'll be faster because of it.


Day 2 of 90 | Week 1 Theory: โœ… Complete | Week 1 Labs: Starting Tomorrow


AI SecurityCybersecurityNetworkingLinux
Continue Reading

More Engineering Insights

Browse All Technical Posts