When the vibes are high, but the guardrails are low.

The future of code development is a contested space.

My view: AI will be largely responsible for the bulk of code going forward. I'll defend that in a minute, but I should disclose something first. I'm not a software engineer. I have experience in languages like Python and SQL from classes I've taken, but fingers to keyboard coding isn't my bread and butter. My domain is security, and software engineering itself isn't my desired goal. I respect the work software engineers do and I commend their skills. That being said, I do see a shift happening.

In its current state, AI is very capable of developing code quickly, but often at the cost of security and scale. Usually an LLM will attempt to solve whatever problem it's given in the quickest route possible. And it has two specific failure modes worth naming separately, because they require different defenses.

The first is training data staleness. The model learned from implementations that were thought to be secure when training happened, but security practices change. A pattern that was fine 18 months ago might have a known CVE today. The model doesn't know that. It writes the pattern and the vulnerability gets pushed.

The second is runtime context quality. Consider the sources an agentic tool like Claude Code fetches while it's working. Is that source authoritative, like official documentation, an RFC, or a maintained reference? Or is it a random person's blog that got pulled into context? Garbage in, garbage out, and most of the time you can't see which one happened. The fact is there are holes in the workflow now. Real ones, that can cause real issues that lay dormant in code that gets shipped.

Now, while this sounds like I'm dumping on AI coding, I'm not really. If you look at the last 12 months, it's absolutely incredible the leaps and bounds agentic coding has made. Watching each new model release has been hard to keep up with. My view is that this trajectory continues, and most code will end up written by AI. Models like Anthropic's "Mythos" also tend to point towards this notion, that is once it gets released to the greater public outside of Project Glasswing.

Still though, I believe there will be edge cases where it won't be used, and honestly shouldn't be. Projects for government, defense manufacturing, public infrastructure. Things where code requirements are niche, complex, and have real physical world outcomes if implemented incorrectly. For the majority of applications though, the SaaS products, the consumer apps, the internal tools, the CRUD that runs most of the software economy, I do think AI will be fully capable of handling it.

Once context windows grow larger and models become smarter, more capable baselines appear. Models that consider secure architecture by default. Security principles like least privilege, access controls, and defense in depth, applied without being asked. Code that solves what it needs to without writing out excessive lines. The gaps close for the average use case.

Eventually I see this leading to a new wave of professions. Similar to how organizations transitioned to cloud and gave way to many cloud-specific job niches, I think there will eventually be roles tailored to AI Developers. There are already some examples of this category showing up. Recently on LinkedIn I stumbled across a couple of postings from different companies looking to hire "AI Product Builders." The role's responsibilities essentially covered owning the entire SDLC, going from idea to working product while using Gen AI.

Yeah, professional vibe coding. Regardless, there are countless solo founders and tech enthusiasts shipping products entirely written by AI right now. I'm not against it by any means, and I think it's where things are headed. But the lingering gaps with AI coding leave some real blind spots that I hope to help address for those who fall into the above categories.

Vibes are great. Guardrails are better.

What I am suggesting is adding a defensive stack to check your vibe.

Layer 1: Your own code

The risk: AI writes code that compiles and looks correct. That's not the same as being safe. Two common failure modes: (1) AI generates code that's syntactically clean but contains classic vulnerabilities like SQL injection or unsafe deserialization, and (2) AI generates placeholder credentials that get committed by accident.

Semgrep — Static analysis (SAST)

Reads your code at rest and flags dangerous patterns: SQL injection, XSS, hardcoded secrets, OWASP Top 10. The Semgrep AppSec Platform also bundles SCA (Supply Chain) and Secrets detection on the same dashboard, free for up to 10 contributors and 10 private repos.

Dashboard access: Go to semgrep.dev, sign in with GitHub, authorize the Semgrep app, and select repos. First scan runs within minutes.

Or if you don't want to leave the terminal…

Claude Code prompt:

Set up Semgrep in this repo without requiring a Semgrep Cloud account. Add a GitHub Actions workflow at .github/workflows/semgrep.yml that runs semgrep scan --config p/owasp-top-ten --config p/security-audit --error on every push and pull request. The --error flag fails the build on findings.

TruffleHog — Secret scanning

Scans repos and git history for leaked credentials. Verifies whether detected secrets still work against the live service, so you know which findings need rotation and which are noise. Open source, free.

Claude Code prompt:

Install TruffleHog using the official install script. Set up a pre-commit hook that runs trufflehog git file://. --since-commit HEAD --results=verified --fail so commits with verified leaked credentials are blocked. Also add a GitHub Actions workflow that runs TruffleHog on push to main, scanning the full git history. Use the pre-commit framework if it's not already set up in this repo.

Anthropic security-guidance plugin — In-session review

Reviews AI-generated code inside Claude Code itself before changes ever leave your editor. Three layers: regex pattern match on every edit, a separate Claude instance reviewing the diff at end-of-turn, and an agentic commit review. Free on all Claude Code plans.

Command within terminal while running Claude Code:

/plugin list to check if it's already installed. If not: /plugin install security-guidance@claude-plugins-official

OWASP ZAP — Dynamic application security testing (DAST)

Attacks your running application from outside the way a real attacker would. Catches what static analysis can't: auth bypasses, IDOR, missing security headers, runtime injection, CORS misconfigurations. Free.

Claude Code prompt:

Set up OWASP ZAP to run a baseline security scan against my staging environment at [YOUR_STAGING_URL]. Before doing anything else, confirm with me that I own this domain or have written authorization to test it. If I can't confirm ownership or authorization, stop and explain why we can't proceed. Otherwise, use the official ZAP GitHub Action (zaproxy/action-baseline@v0.15.0). Add a workflow that runs the scan on every push to main. The action will automatically attach the report as a build artifact. Important: only scan staging, never production.

Important consideration — OWASP ZAP is a real attack tool. Running it against an application you don't own can be illegal under laws like the CFAA in the US and the Computer Misuse Act in the UK. Use it only on your own staging environment, your own home lab, or a target you have written authorization to test.

Layer 2: Your dependencies

The risk: Modern software is mostly other people's code. The last 12 months made that fact dangerous in a new way: the Axios compromise in March, TeamPCP, Shai-Hulud, Chalk and Debug. AI tools recommend packages from training data; training data has a cutoff; new vulnerabilities don't.

Snyk — Software composition analysis (SCA)

Scans your dependency tree against vulnerability databases on every PR. Reachability analysis tells you whether the vulnerable function is actually called in your code. Free for public repos (unlimited tests). For private repos, the free tier covers 200 Open Source tests per month, which works for individual projects but exhausts quickly with active CI.

Dashboard path: Go to snyk.io, sign in with GitHub, install the Snyk GitHub App, and select repos. Findings appear on the Snyk dashboard and as GitHub PR checks.

Claude Code prompt:

Install the Snyk CLI in this repo. Add a GitHub Actions workflow that runs snyk test on every pull request, using the SNYK_TOKEN secret I'll add to the repo. Fail the build on high-severity findings. Walk me through getting the token from snyk.io and adding it as a repo secret.

Dependabot — Automated upgrade PRs

GitHub-native dependency monitoring. Two related features: Dependabot alerts (detect vulnerable dependencies) and Dependabot security updates (open PRs to fix them automatically).

Dashboard path: Go to repo Settings → Code security. Enable both "Dependabot alerts" and "Dependabot security updates."

Create an npm SBOM (Software Bill of Materials)— Incident response readiness

Built into npm 10+. Generates a Software Bill of Materials, a complete list of every package and version in your project (direct and transitive). When the next supply chain attack hits the news, grep the file to see if you too were compromised.

Claude Code prompt:

Add an npm script called sbom that runs npm sbom --sbom-format=cyclonedx --sbom-type=application and writes the output to sbom.json. Then add a GitHub Actions step that runs this command on every release and uploads sbom.json as a build artifact, so we always have a record of exactly what shipped.

Layer 3: Your install pipeline

The risk: Installing a package isn't just downloading code. It runs code on your machine before you've imported anything. Most npm attacks fire here, through lifecycle scripts that execute the moment a package lands.

Four configuration habits make this surface safer.

1. Pin exact versions in package.json

Remove ^ and ~ symbols. Change "axios": "^1.14.0" to "axios": "1.14.0". The little symbols allow drift to newer versions; without them, your project locks to exactly what you've tested.

Claude Code prompt:

Update my package.json to use exact versions for all dependencies and devDependencies. Remove every ^ and ~ so each entry is pinned to a specific version. Don't change any versions; just remove the range operators.

2. Use npm ci in deployment

npm install is allowed to grab newer versions than your lockfile specifies. npm ci refuses to deviate and fails the build instead.

Claude Code prompt:

Audit my deployment workflows in .github/workflows/ and any deploy scripts in the repo. Anywhere npm install is being used for production builds or deployment, replace it with npm ci.

3. Disable install scripts by default

Add ignore-scripts=true to your .npmrc. This blocks all preinstall, install, and postinstall scripts. Allowlist the few packages that legitimately need them (esbuild, sharp, swc).

Claude Code prompt:

Create or update .npmrc in this repo to include ignore-scripts=true. Then audit the dependencies in package.json and tell me which packages legitimately need install scripts to function (build tools, native modules). Show me how to allowlist those specific packages while keeping the global block on everything else.

4. Set a minimum package age

As of npm 11.10.0 (released May 2026), npm has native support for this. Add a single line to your .npmrc and npm will refuse to install any package version published less than your threshold. Most malicious npm versions get caught and unpublished within 24-72 hours; a 7-day floor means the community catches the malware before you do.

The Axios attack was live for three hours. A 7-day floor would have prevented every developer in the world from pulling the malicious version.

Claude Code prompt:

Update my .npmrc to set a minimum release age of 7 days using minimum-release-age=10080. Confirm I'm running npm 11.10.0 or newer first, since this feature requires that version. If I'm on an older version, walk me through upgrading.

That's the stack. None of it is anything special and none of it requires a security team. What it requires is the willingness to actually run it, and the recognition that the tools, however good they get, aren't a substitute for the practice.

Which is worth saying directly, because we're in an unusual moment. We're in the part of AI's growth where the costs haven't caught up with the capability yet. Models are largely subsidized. Tooling is free or close to it. The bar to ship something real with AI in the loop has never been lower, and it probably won't stay this low forever. This feels a lot like the early internet to me. The people who treated that moment as a chance to play, build, and learn ended up understanding it in ways that took everyone else a decade to catch up to. The people who waited for it to feel official missed the part where the rules were still being written.

My honest take, if you've made it this far, is this: now is the time to learn. Not someday. Not when the tools are perfect. Now, while they're cheap enough to experiment with and capable enough to actually build with. Treating AI as a curiosity costs you the practice that's about to become standard. Treating it as a threat costs you the chance to shape how it gets used. The honest middle path is to learn it, build with it, and govern it.

Governance is the part I'd urge people not to skip. The defensive stack I cover in this article is the entry point. The next level is making those guardrails repeatable so you don't have to rebuild them every time. I'm working on something called TGF, a governance framework I run on top of my own AI coding workflow. It's amazing what you can accomplish with custom skill.md files, hooks, and a bit of trial and error.

Worth flagging too — what I cover here doesn't touch database security on the back-end, DNS security, WAFs, excessive user privileges, or the many other considerations you'll need once you're taking your project to scale. The defensive stack above is the entry point, not the ceiling. Building the habit of governing your AI workflow is what I'd urge anyone serious about this to develop in some form.

The point is that the guardrails aren't optional anymore.

Vibes are great. Guardrails are better. Thanks for giving this a read. I hope this provided you with something of value!

PS…

If you're shipping projects, writing about what you're learning, or adding certifications, that work has compounding value. Don't forget to document it. I've been developing a platform called LabList exactly to serve this friction point. LabList is a portfolio platform designed to hold all of your work in one place. Project write-ups, CTFs solved, and commits on dev work are all designed to live within a user's portfolio to provide the proof that backs up the work you've done — in one central place. It's currently in beta testing, but if that fits what you're doing feel free to join the waitlist so you know when it launches. Take a look here at lablist.io!