AI Writes Code Fast. Here's Why Security-First Thinking Matters More Than Ever.

Sun, 19 Apr 2026 00:00:00 +0000

Speed Is the Feature. Unexamined Speed Is the Liability.

One of the most impressive things about using AI to write code is how fast it moves. You describe an endpoint, a data model, a feature — and within seconds you have working code. Not a sketch. Not pseudocode. Actual, runnable implementation.

That speed is real, and it is genuinely useful. I use it every day.

But here is something I noticed the longer I worked with AI-generated code: it writes to the happy path. AI is extraordinarily good at making code that works when everything goes as expected. It is considerably less reliable at writing code that stays safe when things go wrong — when someone sends unexpected input, when a dependency is compromised, when a secret accidentally surfaces in a log, when a logged-in user tries to access someone else’s data.

This is not a criticism of AI models. It is a structural observation about how code generation works. AI learns from what code looks like, not from what happens to systems that run it. The attack surface is invisible at generation time.

Security-first thinking is the discipline that fills that gap. And building it into how you work with AI is one of the highest-leverage things you can do as a developer.

What AI Gets Wrong By Default

Before we get to principles, it helps to see the failure modes concretely. These are patterns I started noticing after reviewing AI-generated code more carefully.

Hardcoded secrets. Ask AI to write a function that connects to a database or calls an external API, and it will often produce something like this:

db = connect(host="prod-db.company.com", user="admin", password="Sup3rS3cr3t!")
client = OpenAI(api_key="sk-proj-abc123...")

The code works. It will also put your credentials in git history forever. A secret committed to a repository — even briefly, even to a private repo — must be treated as compromised. Git history is permanent. The only remediation is rotation.

Missing input validation. AI tends to write code that trusts request data. An endpoint that receives req.body.quantity will often use it directly, skipping the check for whether it is a positive integer, whether it is within expected bounds, whether it contains what the code assumes it contains.

Fetch-then-check authorization. This one is subtle. AI commonly writes authorization logic like this:

const order = await db.orders.findById(req.params.id);
if (order.userId !== req.user.id) return res.status(403).send();
return res.json(order);

That looks right. But it fetches the record first and checks ownership second. A slightly better pattern is to include the user ID in the query itself, so that non-owned records simply return null — and you return a 404, not a 403. Returning 403 confirms to an attacker that the resource exists. It is a small thing that compounds at scale.

Weak cryptography by familiarity. Ask AI to hash a password and it might reach for SHA-256. SHA-256 is a solid hash function — for data integrity. It is the wrong tool for passwords because it is fast. Fast means a GPU can test billions of candidate passwords per second against a leaked hash. bcrypt and Argon2 are deliberately slow. That slowness is the security property.

No rate limiting on authentication. AI generates login endpoints without the defensive scaffolding that should always accompany them: rate limiting per IP, account lockout after repeated failures, uniform response times to prevent user enumeration.

None of these are exotic edge cases. They are the everyday failure modes that show up in security audits and breach post-mortems, again and again.

The Mindset Shift: From Checklist to First Principles

Here is where I want to push back against the usual framing. Security is often presented as a checklist — OWASP Top 10, compliance requirements, “use HTTPS.” Checklists have their place, but they do not produce secure code. They produce code that passes the checklist.

Security-first thinking is different. It is a way of looking at code that asks one question at every boundary: who or what is being trusted here, and has that trust been earned?

Every class of vulnerability — SQL injection, XSS, CSRF, IDOR, broken authentication, insecure deserialization — reduces to a single failure: untrusted data crossing a trust boundary with the authority of trusted data.

SQL injection happens when user input is trusted to be SQL-safe before it reaches the database. XSS happens when user-generated content is trusted to be display-safe before it enters the DOM. IDOR happens when a request parameter is trusted to represent a resource the current user is allowed to access.

Once you see security through this lens — trust boundaries and their enforcement — you stop asking “did I remember the checklist item?” and start asking “where are the trust boundaries in this code, and what enforces them?” That question applies to every system, every language, every framework. It does not go stale.

This is what I mean by security-first thinking as a mindset rather than a procedure. It is not about knowing rules. It is about developing the habit of seeing trust assumptions in code.

The Eight Principles

When I worked through this with Luna recently — building a security knowledge base from 50 cybersecurity books — we distilled the trust boundary framework down to eight irreducible properties that AI-generated code must satisfy.

I want to walk through each one because they are not independent rules. They are facets of the same underlying principle.

1. Input is untrusted by default. Every value arriving from outside your process — HTTP body, query parameters, headers, cookies, file uploads — is hostile until validated. Client-side validation is UX. Server-side validation is security. They cannot substitute for each other.

2. Output is encoded for its context. A string displayed in HTML needs HTML encoding. A value interpolated into SQL needs parameterization. A value passed to a shell command needs to go through an argument array, not string concatenation. The encoding is not about the string itself — it is about the context it will be interpreted in.

3. Secrets never live in code. Passwords, API keys, tokens, certificates — these belong in environment variables or a secrets manager, never in source files. This is absolute. Git history is permanent.

4. Authentication is verified, not assumed. Every protected route, every protected function, checks identity on that request. Being logged in at some prior point does not carry forward.

5. Authorization is checked at the data layer. Being authenticated is not the same as being authorized to access a specific resource. Ownership checks belong in the query itself, not as a post-fetch condition.

6. Least privilege is the default. Database connections, service accounts, IAM roles, file operations — each gets only the access its specific function requires. Nothing more. A compromised least-privilege component fails safely. A compromised over-privileged one does not.

7. Cryptography is never homegrown. Cipher and hash choices go to battle-tested libraries: bcrypt or Argon2 for passwords, AES-GCM for encryption, HMAC-SHA256 for message authentication. The failure modes of hand-rolled crypto are subtle and catastrophic.

8. Dependencies are trust extensions. Every package you add is code you are trusting. Its transitive dependencies are code you are trusting. Supply chain attacks are real. Lock files, audits, and version pinning are not paranoia — they are basic hygiene.

These eight properties are not a checklist to run through at the end. They are filters to apply while generating code. The question during every code-writing session is: which of these are relevant to what I am building right now?

Baking It Into Your AI Workflow

Knowing principles is not the same as applying them consistently. The reason I started building infrastructure around this is that consistency requires more than intention — it requires systems.

Here is what I built, and it came directly from the work of turning 50 cybersecurity books into a searchable knowledge base.

Tier 1 topic files. Each of the eight principles above now lives in a concise reference file — 8 to 12KB each — distilled from the source material. input-validation.md, secrets-management.md, authentication.md, authorization.md, cryptography.md, and the others. Each file is dense but scannable: concrete patterns, code examples, anti-patterns, quick checklists.

Engineer PREFERENCES. I wired those topic files into the Engineer agent through a PREFERENCES file. The trigger table maps code categories to topic files: anything involving SQL gets xss-injection-prevention.md loaded. Anything involving authentication loads authentication.md. Anything involving secrets loads secrets-management.md. The agent loads the relevant files silently before writing code and runs the associated checklist before declaring work done.

The result is that security context is present in every relevant code-generation session without me having to ask for it. The principles are not something I have to remember to invoke. They are part of the workflow infrastructure.

This is what I keep coming back to with PAI: the value is not in any single AI interaction. It is in building infrastructure that makes the right thing the default thing. Security-first code used to require conscious effort and specialized knowledge in the moment. Now it is loaded context — always present, reliably applied.

Security and AI Are Not in Tension

I want to end on this because it is easy to come away from a security conversation feeling like the message is “AI is dangerous, slow down, be careful.” That is not the message.

AI writing code fast is a genuine capability improvement. Being able to go from specification to working implementation in minutes changes what is possible for a small team or a solo developer. That is real.

Security-first thinking is not a constraint on that capability. It is the thing that makes the output of that capability trustworthy. Code that moves fast and ships vulnerable systems is not actually faster in any meaningful sense — it is accumulating debt that will be paid with interest.

The combination is the point. AI that knows how to think about trust boundaries, that loads security context automatically, that applies principles rather than just patterns — that is a force multiplier, not a liability. You get the speed and you get the rigor.

Building toward that combination is one of the more interesting engineering problems I have worked on. The knowledge base, the topic files, the wiring into the workflow — it is all aimed at the same thing: making security-first thinking something that happens automatically, not something that requires a specialist in the room.

The specialist knowledge exists. We built it into 77KB of reference material drawn from 50 books. Now it is always in the room.

Part of the PAI series on building infrastructure that makes AI more useful, more reliable, and more trustworthy. The security knowledge base and topic files referenced in this post were built using Claude Code, PostgreSQL, pgvector, and source material from O’Reilly’s security catalog.