DEV Community: Samantha Start

You added an MCP server to your AI assistant. Did you check what it can touch?

Samantha Start — Sat, 15 Aug 2026 12:10:29 +0000

You added an MCP server to your AI assistant. Did you check what it can touch?

MCP servers give your AI assistant new abilities: read your filesystem, query your database, call an API, run a shell command. That is the whole point of them. It is also the whole point of the risk.

The permission question nobody asks

When you install a normal browser extension, you at least see a permission prompt. When you add an MCP server to your AI coding assistant, you usually do not. You add a config entry, restart, and the assistant now has whatever access that server exposes. Most people never read the server's source to see what that actually is.

This matters more with AI-built or AI-suggested MCP servers specifically. If the assistant wrote the server for you, or you copied one from a repo you have not read closely, you have no independent confirmation of what it does versus what its description says it does.

What tends to go wrong

Three patterns show up repeatedly:

A server meant to read files ends up with write access too, because the broader permission was easier to implement and nobody scoped it down.
A server that talks to an external API embeds a credential directly in its config or source, so anyone who can read the server's files can read the key.
A server built for local development gets pointed at a production database or production credentials once it "works," without a second look at what commands it now accepts.

None of this requires anyone to be careless in an obvious way. It is the same gap as any fast-shipped code: the server works, so it ships, and the access-scoping step that would normally happen in review gets skipped because there was no review.

A practical check before you trust an MCP server

Before you add an MCP server to a live setup, or before you point an existing one at anything real:

Read what the server can actually do, not just its stated purpose. Check the tool definitions it exposes, not the README.
Check where its credentials live. A server that needs a database password should not have that password sitting in plaintext in its own repo.
Scope permissions to the minimum the task needs. A read-only use case does not need write access, even if write access was easier to build.
Treat any MCP server you did not write yourself the same way you would treat a new dependency: know what it can reach before you grant it that reach.

If you want a second check on what a repo, including one holding an MCP server, actually exposes in its history and current config, RepoFortify scans for exactly this kind of overlooked access. Free to try, no install required.

The convenience of an assistant that can just do things is real. So is the fact that "can just do things" is a permission grant, whether or not anyone treated it like one.

The starter template your AI assistant used was built for demos, not for prod

Samantha Start — Wed, 12 Aug 2026 12:39:05 +0000

The starter template your AI assistant used was built for demos, not for prod

You asked your AI assistant to build a SaaS app. It picked a starter template, wired up auth, added a database, and scaffolded routes in minutes. That speed comes from the template doing most of the work. The template was written to get you to a working demo fast. It was not written with your production data in mind.

What starter templates optimize for

Most public starter templates exist to remove friction for a first-time user. That means:

Auth that works out of the box, often with a default admin account or a seed user
Example API routes left in place so you can see the pattern, sometimes including a debug or test endpoint
Permissive CORS settings so the demo works from any origin during setup
A .env.example file with placeholder values that looks enough like a real config that it gets copied and half-filled

None of this is a bug in the template. It is a reasonable choice for a starting point. The problem is that these choices are meant to be replaced before launch, and "replace before launch" is a step that depends on you remembering to do it.

Why AI assistants make this worse, not better

An AI assistant scaffolding from a template is optimizing for the same thing the template author was: get something running. It will happily leave the seed admin account in place if removing it was not part of your instruction. It will keep the debug route because deleting it wasn't the task. It is doing exactly what you asked. You asked for a working app, and the template already gave it a working shape.

The gap is not new. Developers have shipped forked templates with default credentials still active for years. What changed is the speed. A template that used to take a day to adapt can now be fully wired to a live database and pushed to production in an afternoon, which means the "replace before launch" step has to happen just as fast, or it gets skipped.

What to check before you connect it to real users

Before a template-based app touches real customer data:

Look for any account, key, or credential that shipped with the template itself, not one you created. Rotate or remove it.
Check every route the template included, not just the ones you built on top of. If you didn't write it and don't use it, remove it.
Confirm CORS and auth settings match your actual deployment, not the template's local-dev defaults.
Check the full git history, not just the current files. A template's default .env sometimes gets committed once during setup and never fully removed from history.

If you want a second pair of eyes on this, RepoFortify scans a repository, including its full commit history, for exactly this kind of leftover. Free to try, no install required.

Templates are a genuine shortcut. The part they cannot shortcut is the decision about what stays and what gets removed before real users show up. That decision is still yours.

What your AI coding assistant left in your git history

Samantha Start — Tue, 11 Aug 2026 23:45:55 +0000

What your AI coding assistant left in your git history

You are building fast. You shipped a real app in a weekend. The AI wrote most of it, you connected it to GitHub, and you pushed.

Here is the part that does not show up in the UI: your git history is a permanent timeline. It remembers every version of every file you have ever committed.

When the AI wrote your config file on day one, it may have put a real API key in there to make the code run. You moved it to an environment variable later. The current version of your file is clean. The commit from day one is still there, and so is the key.

Why deleting the file does not help

When you push a commit, that commit becomes part of your repository's permanent history. If you later delete the file or rotate the key and push a new commit, the old commit is still there.

Anyone who clones the repo gets the full history, including the old commits. Automated scanners comb public GitHub repositories for exactly this pattern. A leaked key from six months ago is still a working key if you did not rotate it.

Private repositories are not immune. A compromised account, an accidental visibility change, or a contractor you no longer trust all turn a private history into an exposure.

What the AI-specific version looks like

Coding assistants write code that works. They fill in values so the code runs during your session. Those values sometimes land in commits.

The AI is not making a security mistake. It is doing what you asked: making things work. The security decision belongs to you, and it has to happen before you push to shared infrastructure.

The gap is not a problem with AI tools. It is the gap between "it runs" and "it is safe to ship." That gap has always existed. AI just makes the first part faster, which makes the gap more important to close deliberately.

What tends to end up in history

Four patterns come up most often in AI-built repos:

API keys or tokens in config files, even if you moved them to environment variables afterward
.env files committed before being added to .gitignore
Database connection strings used during early development
Hardcoded service account keys in serverless or cloud function files

A practical check before you ship

Before you connect an AI-built repo to real infrastructure or make it public:

Run a full git history scan for secrets. Not just the current files. Every commit.
Rotate any credentials that show up, even if they look expired or test-only.
If you want to fully clean the history, git filter-repo (the modern replacement for git filter-branch) can rewrite commits to remove the secret at the source.

If you want to skip the manual work, RepoFortify scans your full git history for secrets and flags them at the commit level. Free to try. No install required: paste your repo URL and it runs in the browser.

The question is not whether AI coding tools introduce security risk. Every tool that speeds up development moves faster than the developer's mental security review. The question is whether you have a check that runs before it matters.

A full git history scan takes a few minutes. It belongs before you push to prod, not after your first incident report.

You built an app with AI this weekend. Here are the security holes it probably has.

Samantha Start — Sun, 12 Jul 2026 00:13:52 +0000

You had an idea on Friday. By Sunday you had a working app. The AI wrote most of the code, you wired it together, and it just worked.

Here is the part nobody says out loud: you did not read every line the AI wrote. Almost nobody does. That is fine, it is how building works now. But it means there are probably a few security holes sitting in your app that you cannot see, because you never looked at the code that made them.

The good news: the most common holes in AI-built apps are a short, predictable list. You can check for them in about 15 minutes. Here are the three that cause the most real trouble, in plain terms.

1. A secret written straight into the code

AI assistants love to put your API key or database password right in the code to make things work. It runs great. The problem shows up later: that secret ends up in your git history, and public repos get scanned by bots within minutes of going up.

Deleting the line does not fix it. The secret still lives in your past commits. Anyone who clones the repo can read it.

How to check: search your code for anything that looks like a key or password. If you find one, or if one was ever committed, rotate it now (create a new one, revoke the old), then move secrets into environment variables instead of the code.

2. An API route with no lock on the door

When the AI builds a route that returns data, it often does not add a check for who is asking. It works in testing because you are the only user. Then it ships, and anyone who finds the URL can pull the data.

How to check: for every route that returns user or account data, confirm there is a login or permission check in front of it. If a route hands back private data to anyone who asks, that is the first thing to fix.

3. A public default that should be private

Storage buckets, databases, and file uploads often start with a default that is more open than you meant. The AI picks a setting that works, not the one that is safe. So your uploads or your database might be readable by the whole internet without you knowing.

How to check: look at your storage and database settings. Anything holding real user data should be private by default, with access granted on purpose, not by accident.

The 15-minute pre-launch checklist

Before you put your app in front of real people, run this list:

No API keys, passwords, or tokens in the code. Rotate anything that was ever committed.
Every route that returns user data has a login and permission check.
Storage, databases, and buckets are private by default.
Dependencies are up to date, with no known-vulnerable versions.
Error messages do not leak stack traces, config, or secrets.

That covers the large majority of real incidents in fast-built apps.

If you want it done for you

You do not have to eyeball all of this. An independent scan can run the whole checklist and hand you the exact fixes, so you can ship with confidence instead of a nagging worry. That is the problem we built RepoFortify to solve, and it plugs into Claude Code, Cursor, and Windsurf so the fixes show up right where you are already working. But even if you never use a tool, the checklist above will catch most of what matters.

Ship fast. Just do the 15-minute check first.

https://repofortify.com/get-started?utm_source=devto&utm_medium=content&utm_campaign=vibe-security

What Google Lighthouse Did for Web Performance, We Need for Code Repos

Samantha Start — Fri, 10 Apr 2026 23:33:25 +0000

Remember before Lighthouse? Web performance was a black box. You knew your site felt slow, but you didn't have a standardized way to measure it, benchmark it, or explain it to stakeholders.

Lighthouse changed that. One URL, one score, actionable breakdown. Suddenly performance was a conversation everyone could have, not just the senior engineer who profiled Chrome DevTools.

Code repos have the same problem today

Most developers can tell you whether a repo 'feels' well-maintained. But there's no standardized score. No quick way to benchmark. No shared language between the developer who maintains it and the manager who funds it.

The signals exist — CI pipelines, test coverage, dependency health, branch protection, type safety, dead code, security — but nobody aggregates them into a single, comparable number.

Why this matters now

Two trends are colliding:

AI coding tools are producing repos faster than ever. Claude Code, Cursor, Windsurf — developers are shipping in hours what used to take weeks. But the AI focuses on working code, not operational readiness.
Open-source dependency chains are deeper than ever. When you pick a starter template or library, you're inheriting its infrastructure patterns. If it has no tests and no CI, neither will your project — unless you add them yourself.

The gap between 'working code' and 'production-ready code' is getting wider, and there's no standard way to measure it.

What a Lighthouse for repos looks like

We built RepoFortify to be that standard. Paste a public GitHub URL, get a score out of 100 across 9 signals:

CI pipeline (15%)
Test coverage (25%)
Dependency health (10%)
Branch protection (10%)
Type safety (10%)
Dead code (10%)
Exposed routes (5%)
Documentation (10%)
Security headers (5%)

No signup, no paywall for public repos. We also ship an MCP package (npx @repofortify/mcp) so AI coding tools can run scans inline.

The goal isn't to shame anyone. It's to give teams a shared language for production readiness — the same way Lighthouse gave teams a shared language for performance.

We Scanned 6 SaaS Starter Templates — Here's What We Found

Samantha Start — Fri, 10 Apr 2026 21:15:55 +0000

Starter templates promise a head start. But how production-ready are they out of the box? We scanned 6 popular templates across Next.js, Remix, and SvelteKit using 9 production readiness signals.

The 9 Signals

Our scanner checks: CI pipeline, test coverage, dependency health, branch protection, type safety, dead code detection, exposed routes, documentation quality, and security headers. Each is weighted by impact — tests are 25% of the total score, CI is 15%.

The Results

Template	Framework	Stars	Score
epic-stack	Remix	5,531	89
next-starter	Next.js	974	86
remix-saas	Remix	1,465	84
CMSaasStarter	SvelteKit	2,297	73
chadnext	Next.js	1,323	49
kitforstartups	SvelteKit	734	5

Averages: Remix 86.5, Next.js 67.5, SvelteKit 39.0. Overall average: 64/100.

Key Takeaways

Stars don't predict quality

chadnext has 350 more stars than next-starter but scores 37 points lower. Community popularity measures how many people found something useful, not whether it's production-ready.

Framework ecosystem maturity matters

Remix starters both scored 84+. This isn't coincidence — the Remix ecosystem has strong opinions about testing and CI that flow into community templates. SvelteKit's ecosystem is newer and more varied.

The gap is operational, not code quality

Most of these templates have clean, well-structured code. Where they diverge is CI pipelines, test coverage, dependency management, and branch protection. The 'boring' infrastructure that keeps production stable.

What This Means For You

If you're picking a starter template:

Check if it has CI that actually runs on PRs
Look for any test coverage at all (many have zero)
Check dependency freshness — stale deps = security risk
Consider that the template's infrastructure patterns become YOUR patterns

You can scan any public GitHub repo at repofortify.com — free, no signup.

I Scanned 10 Popular TypeScript Repos — Stars Don't Predict Production Readiness

Samantha Start — Thu, 26 Mar 2026 04:16:32 +0000

I couldn't help myself. I took 10 popular TypeScript repositories — all between 4,000 and 5,000 GitHub stars — and ran them through our production readiness scanner.

The results surprised me.

The Scores

Repo	Stars	Score	What I noticed
mengxi-ream/read-frog	4,941	79/100	Translation browser extension with its infrastructure together. Genuinely impressed.
tagspaces/tagspaces	4,985	77/100	Offline-first document manager. When your app works offline, you have to get the engineering right.
useplunk/plunk	4,933	75/100	Open-source email platform. This is what happens when maintainers treat readiness as a first-class concern.
microsoft/FluidFramework	4,917	72/100	Real-time collab library. Building distributed systems for others to build on — you can't fake the infrastructure.
extension-js/extension.js	4,963	66/100	Cross-browser extension framework. Solid. Building browser extensions is already painful; investing in infra on top shows discipline.
microsoft/tsdoc	4,943	65/100	TypeScript doc comment standard. Expected higher from Microsoft tbh — but it's a spec project, not an app.
opennextjs/opennextjs-aws	4,974	60/100	Next.js adapter for AWS. Someone thought about deployment beyond "it works on my machine."
gluestack/gluestack-ui	4,994	49/100	React/React Native component library. Nearly 5K stars, below 50. The components are gorgeous. The infrastructure has gaps.
tinyplex/tinybase	4,980	44/100	Reactive data store. Clean API, great docs, but infrastructure signals aren't keeping pace with the star count.

What I Learned

Stars don't predict production readiness. At all.

The highest-starred repo in my set (gluestack-ui, 4,994 stars) scored 49. The highest-scoring repo (read-frog, 79) has fewer stars than most of the others.

The repos that scored well had something in common: someone invested in CI, tests, dependency management, and configuration as foundational work, not as an afterthought.

The repos that scored poorly had great code and great docs — but the engineering infrastructure around the code was thin or missing.

The Pattern

Every time I scan repos, the same pattern emerges:

The code is usually fine. Whether human-written or AI-assisted, the application logic works.
The infrastructure is where it breaks. CI pipelines, test coverage, branch protection, secrets management, dependency health — these are the signals that separate "it runs" from "it's production-ready."
Stars measure popularity, not readiness. A repo can have 5,000 stars and still be missing half the production basics.

What We Check

Our scanner looks at 9 production readiness signals:

CI enforcement
Test coverage
Type safety
Dependency health
Branch protection
Dead code
Dead exports
Linter configuration
Route coverage

Each signal is a binary or scored check. No AI-generated suggestions, no hallucinated fixes — just structural verification.

Try It

If you maintain an open-source TypeScript project (or any project, really), I'm genuinely curious how it scores. The scanner is free, no signup required:

repofortify.com

Paste your repo URL, get a score in seconds. I'd love to see what the dev.to community's projects look like.

And if you score above 75 — seriously, tell me. I want to celebrate the repos that are doing it right.

Samantha Start builds production readiness scanning tools at RepoFortify. She scans too many repos and can't stop talking about what she finds.

Two Types of AI Code Debt — And Only One Is Scannable

Samantha Start — Wed, 25 Mar 2026 16:14:26 +0000

After scanning 200+ repos built with Claude Code, Cursor, and Copilot, we've identified two distinct types of debt:

1. Structural Debt — Scannable and Fixable

Missing CI pipeline, zero test coverage, hardcoded secrets, unmanaged dependencies. This is measurable:

73% of AI-built repos have no CI pipeline
68% have zero tests
41% have hardcoded secrets

These are binary checks. Either CI exists or it doesn't. Either secrets are in env vars or they're hardcoded. A scanner can catch all of this.

2. Comprehension Debt — Harder to Measure

Code that works but nobody understands because nobody wrote it with intent. AI generates 200 lines where 40 would do. The abstractions are illogical. The reviewer's eyes glaze over.

This debt compounds because each untested module interacts with other untested modules. The failure modes multiply faster than the code volume.

The Gap

Most teams don't realize they have both types until the first production incident. By then, the structural debt has made the comprehension debt impossible to diagnose.

We built RepoFortify to catch Type 1 — the structural gaps that AI coding tools consistently skip. It checks 9 production readiness signals in seconds.

Type 2 is the next frontier. But you can't fix comprehension debt if your CI is broken and your tests don't exist.

Start with structure. The rest follows.

Free scan: repofortify.com — paste your repo URL, get a production readiness score across 9 signals. No signup required.