DEV Community: Vatsal Trivedi

I got tired of manual code reviews so I built a free automated security pipeline

Vatsal Trivedi — Mon, 23 Mar 2026 07:06:39 +0000

Let me be upfront about something. For a while, our security process was basically vibes. Someone would glance over a PR, maybe catch an obvious thing, and we'd ship it. No linting enforcement. No dependency scanning. No idea if someone accidentally committed a database password six months ago.

It wasn't negligence exactly, it was the usual small team problem. Everyone's busy, security tooling feels like a rabbit hole, and the good stuff costs money we didn't want to spend.

Then I spent an afternoon looking into it properly and realised the entire thing was solvable for free, in a weekend. This is what I set up.

The constraints I was working with

Python (Django) backend, JavaScript/Node.js frontend
Everything lives on GitHub
Small team - I'd be the one maintaining this
Not willing to pay for tooling, at least not yet

The last point mattered a lot. Most "enterprise" security tools have pricing pages that just say "contact sales." Hard pass.

The approach: three layers, not one big tool

The mistake I almost made was looking for a single tool that does everything. That tool either doesn't exist or costs a lot. Instead, I split the problem into three layers based on how fast feedback needs to be:

Layer 1 — Before the code even leaves my machine. Pre-commit hooks. Fast, local, blocks commits instantly if something looks wrong.

Layer 2 — Before the code gets merged. GitHub Actions on every PR. Takes a few minutes, catches deeper security issues.

Layer 3 — The full picture. A proper dashboard showing the health of the entire codebase. Runs weekly and after every merge to main.

Each layer has a different job. Trying to do everything in one place means either slow commit times or shallow analysis. Keeping them separate means you get both speed and depth.

Layer 1: Pre-commit hooks

Install the framework once:

pip install pre-commit

Then drop this .pre-commit-config.yaml in your project root:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.3.0
    hooks:
      - id: ruff
        args: [--fix]
      - id: ruff-format

  - repo: https://github.com/pre-commit/mirrors-eslint
    rev: v8.57.0
    hooks:
      - id: eslint
        files: \.(js|jsx|ts|tsx)$
        additional_dependencies:
          - eslint@8.57.0
          - eslint-plugin-security@1.7.1

And activate it:

pre-commit install

That's the whole setup. Every developer runs pre-commit install once and then forgets about it.

What's actually running here

Gitleaks scans every commit for secrets - API keys, database URLs, tokens, anything that looks like a credential. If it finds one, the commit gets blocked before it goes anywhere:

# This commit will NOT go through
STRIPE_SECRET = "sk_live_abc123xyz"
DATABASE_URL = "postgres://user:password@prod-host/db"

I've seen codebases where dev credentials had been sitting in git history for years. This stops that from happening in the first place.

Ruff handles Python linting and formatting. It's genuinely fast - replaces flake8, black, and isort in one tool. The --fix flag means it auto-corrects most things silently. You barely notice it running.

ESLint with the security plugin catches JavaScript issues that normal linting misses, like using eval() with dynamic input or building RegEx from user-supplied strings (a classic ReDoS vector).

Layer 2: GitHub Actions on pull requests

Every PR against main or develop triggers two scanners automatically. The results show up directly in the GitHub Security tab on the PR - no context switching, no separate dashboard to check.

Create .github/workflows/security-scan.yml:

name: Security Scan

on:
  pull_request:
    branches: [main, develop]

jobs:
  trivy:
    name: Dependency Vulnerability Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Trivy
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          severity: HIGH,CRITICAL
          format: sarif
          output: trivy-results.sarif

      - name: Upload to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

  bandit:
    name: Python Security Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install and run Bandit
        run: |
          pip install bandit[toml]
          bandit -r . \
            -x ./node_modules,./venv,./.venv,./tests \
            -f json \
            -o bandit-report.json || true

      - uses: actions/upload-artifact@v4
        with:
          name: bandit-security-report
          path: bandit-report.json

Why these two tools specifically

Trivy scans requirements.txt and package.json against known CVE databases. When it finds something, it tells you the exact version you have, the CVE ID, the severity, and what version fixes it:

CRITICAL  CVE-2023-1234  cryptography 3.4.6 → upgrade to 41.0.0
HIGH      CVE-2023-5678  Pillow 9.0.0 → upgrade to 10.0.0

That's actionable. No digging through changelogs to figure out if you're affected.

Bandit understands Python and Django patterns specifically. It catches the stuff that generic linters miss - things like Django views doing raw SQL string concatenation, DEBUG = True making it into a non-dev file, or subprocess calls using shell=True. If you've worked on a Django codebase for a while you've probably seen all of these in the wild.

Layer 3: SonarQube for the full codebase picture

This is where it gets interesting. The previous two layers are reactive - they catch issues in code you're actively changing. SonarQube gives you a view of the entire codebase, including the stuff nobody's touched in two years.

One thing worth knowing before you go down the Semgrep route for this: Semgrep's free (Community) edition only analyzes code within a single function or file. It can't follow data across your application. SonarQube's community build does full cross-file analysis, which is what you actually want for a codebase-wide report.

Spin it up locally first

docker run -d --name sonarqube -p 9000:9000 sonarqube:community

Go to http://localhost:9000, log in with admin/admin, and immediately change the password. Create a project, grab a token, and add sonar-project.properties to your repo:

sonar.projectKey=your-project-name
sonar.projectName=Your Project Name
sonar.projectVersion=1.0

sonar.sources=.
sonar.exclusions=**/node_modules/**,**/venv/**,**/.venv/**,**/migrations/**,**/*.min.js

sonar.python.version=3.11

Then automate it

Create .github/workflows/sonarqube.yml:

name: SonarQube Full Scan

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * 1'  # Monday 2am

jobs:
  sonarqube:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # full history = better analysis

      - uses: SonarSource/sonarqube-scan-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

Add both secrets under Settings → Secrets → Actions in your GitHub repo.

Now it runs automatically every Monday and every time something merges to main. You just check the dashboard.

What the first scan actually found

I want to be honest about this because I've read too many posts that describe a perfect greenfield setup. This was a real codebase that had been built by humans under time pressure.

The first SonarQube scan came back with:

Hardcoded dev credentials that had been in the repo for months. Not production secrets, but still - they had no business being there.
A couple of Django views building SQL with string formatting instead of parameterized queries. Classic, boring, dangerous.
Several npm packages flagged by Trivy with HIGH severity CVEs, all with fixes available. Literally just needed version bumps.
A significant chunk of duplicated logic copied between files that had clearly diverged over time.

None of it was a disaster. But any of it could have become one. The SQL stuff in particular - that's the kind of thing that sits quietly in a codebase until someone thinks to try it.

Handling the noise

The first scan will surface a lot. Don't try to fix everything at once - you'll burn out and give up on the tooling entirely.

The priority order that works for us:

Severity	What we do
🔴 Critical	Don't merge. Fix it now.
🟠 High	Fix it this sprint.
🟡 Medium	Goes on the backlog.
🟢 Low	Fix it when you're touching that code anyway.

For SonarQube false positives - and there will be some - mark them as "Won't Fix" and add a comment explaining why. Dismissing without a comment just creates confusion later.

The ongoing cost

Once this is set up, the maintenance is genuinely minimal:

Pre-commit hooks run themselves. Zero maintenance.
GitHub Actions trigger themselves. Zero maintenance.
SonarQube dashboard - I spend maybe 20-30 minutes a week looking at it.
Once a month, run pre-commit autoupdate to pull in newer tool versions.

That's it. The pipeline runs whether I'm thinking about it or not, which is exactly the point.

Where to start if this seems like a lot

You don't need to do all of this at once. The pre-commit hooks alone are worth doing today - pip install pre-commit, drop in the config, run pre-commit install, and Gitleaks starts protecting your commits immediately. Takes maybe 20 minutes.

The GitHub Actions workflow is the next step, and it's mostly copy-paste. SonarQube requires the most setup but gives the most visibility.

Each layer is independent. Pick the one that solves your most pressing problem first and add the others when you're ready.

Resources

Everything here is free. Nothing leaves your infrastructure. If you set this up and find something interesting on the first scan, I'd be curious to hear about it.

The "Lazy" Developer’s Guide to Twilio Auto-Replies (No Server Required)

Vatsal Trivedi — Mon, 09 Mar 2026 10:44:25 +0000

When building messaging workflows, one of the most common requirements is sending a default response when someone messages your number.

Normally this involves setting up a webhook, deploying a backend service, and writing some code to respond to incoming messages.

However, if your use case is simple — like sending a welcome message or acknowledgement — you can skip the backend entirely by using Twilio with TwiML.

Using TwiML Bins, you can configure automatic responses directly inside the Twilio Console, with no external server.

Let’s walk through how to do it.

The Idea Behind This Setup

Instead of sending incoming messages to your own application, you can have Twilio call a TwiML endpoint hosted by Twilio itself.

That endpoint simply returns instructions telling Twilio to send a message back.

The message flow looks like this:

User sends a message
        ↓
Twilio receives the message
        ↓
Twilio calls a TwiML Bin
        ↓
The TwiML response tells Twilio to send a reply

It’s a very clean setup and perfect for quick messaging workflows.

Step 1 — Create a TwiML Bin

Start by creating a TwiML Bin.

Inside the Twilio Console, go to:

Develop → Runtime → TwiML Bins

Create a new TwiML Bin and add the following TwiML:

<Response>
  <Message>
Hi 👋

Welcome!

You will now receive important updates and notifications through this messaging channel.

Thanks for connecting with us.
  </Message>
</Response>

Save the configuration.

Once saved, Twilio will generate a handler URL that looks something like this:

https://handler.twilio.com/twiml/EHxxxxxxxxxxxxxxxx

This URL acts as a small hosted endpoint that returns your TwiML instructions.

Step 2 — Configure Incoming Messages

Next, tell Twilio to call this TwiML endpoint whenever a message arrives.

Open your Messaging Service settings and navigate to the Integration section.

Under Incoming Messages, select:

Send a webhook

Then paste your TwiML Bin URL into the Request URL field.

Example configuration:

Setting	Value
Incoming Messages	Send a webhook
Request URL	TwiML Bin handler URL
HTTP Method	POST

Save the changes.

Step 3 — Test the Flow

Now try sending a message to your Twilio number.

If everything is configured correctly, this will happen:

A user sends a message to your number
Twilio receives it
Twilio calls the TwiML Bin
The TwiML response instructs Twilio to send a reply
The user immediately receives the welcome message

No backend services are involved.

Understanding the TwiML

The TwiML used here is intentionally simple:

<Response>
  <Message>...</Message>
</Response>

<Response> is the root element that Twilio expects.

<Message> instructs Twilio to send a message back to the sender.

When Twilio receives this XML response, it executes the instruction automatically.

Why This Approach Works Well

Using TwiML Bins is ideal when you want something simple and fast.

It works well for things like:

welcome messages
confirmation replies
acknowledgement responses
business hour notifications

Since everything is hosted inside Twilio, there’s no infrastructure to maintain.

When You Might Need Something More Advanced

TwiML Bins are great for static responses, but they are intentionally limited.

If your workflow requires things like:

conditional logic
menu systems
chatbot flows
database lookups
integration with other services

then you’ll likely want to use Twilio Studio or build a webhook-based backend.

Final Thoughts

TwiML Bins are one of the fastest ways to get an auto-reply system up and running.

For simple messaging workflows, they remove the need for backend infrastructure while still giving you full control over the response sent to users.

If you just need to greet users or confirm that their message was received, this approach can save a lot of development time.

How to Fix the NVM for Windows `NVM_SYMLINK` Activation Error

Vatsal Trivedi — Wed, 04 Mar 2026 11:17:15 +0000

If you're using NVM for Windows and see the following error:

nvm enabled activation error:
NVM_SYMLINK is set to a physical file/directory at C:\Program Files\nodejs
Please remove the location and try again,
or select a different location for NVM_SYMLINK.

You're not alone. This is a common issue when switching from a traditional Node.js installation to NVM.

This guide explains the root cause and provides a guaranteed step-by-step fix.

Why This Error Happens

When Node.js is installed using the official Windows installer, it creates this directory:

C:\Program Files\nodejs

However, NVM for Windows uses this same path as a symbolic link (NVM_SYMLINK) to dynamically switch between Node versions.

If a physical directory already exists there, NVM cannot override it — and activation fails.

Step-by-Step Fix (Guaranteed Method)

Step 1: Close All Node-Related Applications

Before making changes:

Close all terminal windows
Close VS Code or any IDE
Stop any running Node.js applications

This prevents file locking issues.

Step 2: Open Command Prompt as Administrator

Press Start
Type cmd
Right-click → Run as Administrator

Administrator privileges are required because we are modifying Program Files.

Step 3: Take Ownership of the Directory

Windows may block deletion due to TrustedInstaller permissions.

Run:

takeown /f "C:\Program Files\nodejs" /r /d y

Then grant full permissions:

icacls "C:\Program Files\nodejs" /grant %username%:F /t

Step 4: Kill Any Running Node Processes

taskkill /f /im node.exe
taskkill /f /im npm.exe

This ensures no processes are locking files.

Step 5: Delete the Existing Node Directory

rmdir /s /q "C:\Program Files\nodejs"

Command flags explained:

/s → Deletes all subdirectories and files
/q → Suppresses confirmation prompts

Still Getting “Access is Denied”?

Open PowerShell as Administrator and run:

Remove-Item "C:\Program Files\nodejs" -Recurse -Force

Fallback Method (If Files Are Locked)

If the directory still refuses to delete:

Restart your system
Do not open any applications
Immediately open Command Prompt as Administrator
Run:

rmdir /s /q "C:\Program Files\nodejs"

This resolves most background file lock issues.

Re-Enable NVM

Once the directory is removed:

nvm on

Then install and activate a Node version:

nvm install 18
nvm use 18
node -v

You should now see the installed Node version.

Best Practice When Migrating to NVM

If you're switching from a direct Node installation to NVM:

Uninstall Node.js from Control Panel first
Manually verify that C:\Program Files\nodejs is deleted
Then install and configure NVM

This prevents activation conflicts entirely.

Final Thoughts

This error occurs because NVM relies on symbolic linking, and Windows does not allow it to overwrite an existing physical directory.

Following the above steps will completely resolve the NVM_SYMLINK activation error in most Windows environments.

From MySQL to PostgreSQL: My Django Migration Story (and a Tool to Help)

Vatsal Trivedi — Tue, 07 Oct 2025 13:35:07 +0000

Every project grows over time. You start with tools that work great in the beginning, but as your app and data grow, your needs change. That’s what happened to me. My Django app was built on MySQL, and it worked well for a long time. But as things scaled up, I realized I needed something more powerful and flexible.

So, I decided to move to PostgreSQL - a database known for better performance, advanced features, and scalability. But database migration is not an easy task. I had to make sure the data stayed safe, handle different data types between MySQL and PostgreSQL, and make the whole process repeatable and reliable.

Doing this manually with commands and scripts felt messy and risky. So, I decided to create a clean and reusable solution.

My Solution: A Toolkit for Django Migrations

To make the migration process easier, I built a small toolkit and wrote a step-by-step guide. I’ve open-sourced everything so that others can use it too.

👉 GitHub Repository:
https://github.com/trivedi-vatsal/django-mysql-to-postgres

The toolkit automates most of the hard work. The main script transfers your database schema and data from MySQL to PostgreSQL and maps the data types correctly.

I also added a few helper tools:

A connection tester to check your new database settings before starting.
A --dry-run option to test the migration safely without changing real data.
A cleanup script to remove old migration files after switching over.

My Approach

My main goal was safety and confidence. I made sure the process included steps like taking backups, testing connections, and running a dry run first. That way, you can migrate without worrying about data loss or downtime.

The guide in the repository explains everything - the commands, the scripts, and how to fix common issues. It’s based on my own migration experience, turned into a simple plan you can follow.

Why I’m Sharing This

Switching from MySQL to PostgreSQL was a big improvement for my project. It helped me scale faster and manage data more effectively.

If you’re planning to move your Django project to PostgreSQL, check out the repo. I’d love to hear your feedback or how it works for you.

Happy coding!

[Boost]

Vatsal Trivedi — Sun, 05 Oct 2025 10:52:13 +0000

Vatsal Trivedi

Sep 24 '25

My Pinch of Salt: Did AI and LLMs Kill the "First-Time Correct" Engineer?

#discuss #ai #coding #llm

Comments

2 min read

Leaving Breadcrumbs for Your AI: The Hansel and Gretel Approach

Vatsal Trivedi — Tue, 30 Sep 2025 09:11:39 +0000

I recently discovered a game-changing technique from Giuseppe Gurgone's article: comment directives. It's fundamentally simplified how I work with AI coding assistants, calling it "leaving breadcrumbs" for my AI, much like Hansel and Gretel guiding their way through the woods.

Instead of writing massive, detailed prompts in my terminal, I now embed instructions directly into my code using special comments. The context stays exactly where it's needed, which is a huge win for efficiency.

My Go-To: The `@implement` Directive

The core of this workflow is the @implement directive.

When I plan an enhancement, but don't want to implement it yet, I drop a directive like this right into the file:

Example Directive:

class UserService {
  /* @implement
   * Add a caching layer for user data:
   * - Cache user objects by ID in a Map
   * - Expire entries after 5 minutes
   * - Return cached data if available and fresh
   */
  async getUser(id: string): Promise<User> {
    // Current implementation...
  }
}

Later, I just tell my AI (like Claude Code): "Implement all the @implement directives."

Why I Love It:

Context is Local: The AI has all the specific instructions right next to the code signature it needs to change.
Instant Documentation: The AI doesn't just write the code; it converts the directive into proper JSDoc (or similar documentation), ensuring the code is clean and explained immediately.

Beyond Implementation: `@docs`

The pattern is flexible. I use the @docs directive to provide external context for the AI:

/*
 * This component renders a list of products using suspense.
 * @docs https://react.dev/reference/react/Suspense
 */
function ProductList() {
  // ...
}

This ensures the AI is aware of the necessary technical background without me needing to manually fetch and paste links.

Conclusion

I highly recommend trying this. It moves instructions out of a separate task list and directly into your source code, creating a much smoother, human-centered development experience with AI.

I found this method from here: Comment Directives for Claude Code

Note: The AI-assisted coding space is changing fast. Always validate techniques for your specific use case.

The Cleanest Way to Handle Unused Variables in TypeScript

Vatsal Trivedi — Mon, 29 Sep 2025 15:58:14 +0000

We've all been there. You're deep in the zone, maybe mapping over an array, setting up an Express middleware, or defining a React component. You’re required to accept a parameter you don’t actually need, and like clockwork, your linter starts complaining:

'props' is declared but its value is never read. @typescript-eslint/no-unused-vars

What’s your gut reaction? Do you litter the code with // eslint-disable-next-line comments, creating technical debt? Do you surrender and weaken a valuable rule in your config? Or do you just learn to ignore the yellow squiggly lines that silently judge your work?

There's a much cleaner, more professional solution, and it's been hiding in plain sight: the humble underscore _.

A Quick Story

I remember the exact moment this convention went from a "nice-to-have" to a "must-enforce" on my team. I was doing a code review on a new feature. A mid-level dev had implemented a component that was connected to a third-party library. The library's withProvider HOC passed down a bunch of props - data, isLoading, error, and refetch.

Our component only needed data and isLoading. The dev’s solution was to just destructure all of them and let the linter scream about error and refetch being unused.

// The code I was reviewing
const MyComponent = ({ data, isLoading, error, refetch }) => {
  // ...logic using data and isLoading
};

The PR description simply said, "Linter warnings are expected." That was a red flag. It wasn't just about messy code; it was about a mindset. It communicated a willingness to fight the tools instead of working with them.

I left a simple comment: "Let's signal that error and refetch are intentionally unused. Prefix them with an underscore."

The revised code came back minutes later:

// The clean, intentional version
const MyComponent = ({ data, isLoading, _error, _refetch }) => {
  // ...logic using data and isLoading
};

No more warnings. No more excuses in the PR description. It was a small change that reflected a much bigger principle: we write code for humans first, machines second. It clearly communicated intent, and that’s the hallmark of a seasoned developer.

Why the Underscore Is So Powerful

Using an underscore prefix for unused variables isn't a hack. It's a widely accepted convention that signals professionalism and brings tangible benefits.

It Screams Intent: An underscore tells every developer who reads your code, "I acknowledge this variable's existence, and I have deliberately chosen not to use it." It’s the difference between a potential bug (user that was forgotten) and a clear choice (_user which is intentionally ignored).
It Works With Your Linter: Instead of disabling the incredibly useful @typescript-eslint/no-unused-vars rule, you configure it to respect this convention. You get the best of both worlds: you still catch truly unused variables (like typos or leftovers from a refactor) while allowing the intentionally unused ones to pass.
It's a Cross-Ecosystem Language: This pattern isn't unique to TypeScript. You'll see it in Python, C#, and many other languages. Adopting it makes your code more accessible and demonstrates a breadth of experience.

Putting It into Practice: Common Examples

So, where can you use this simple trick? Pretty much anywhere an unused variable shows up.

1. React Props and Hooks

This is a daily occurrence in React development. A component might receive props it only passes down, or a custom hook might return a value you don't need in a specific instance.

// Example: A component that doesn't use all its props
interface UserProfileProps {
  userId: string;
  name: string;
  // This prop is required by the parent, but not used here
  onSelect: (id: string) => void; 
}

// Don't do this:
// const UserProfile = (props: UserProfileProps) => <h2>{props.name}</h2>;

// Do this:
const UserProfile = ({ name, ..._rest }: UserProfileProps) => <h2>{name}</h2>;

Or when working with hooks like useState where you only need the setter:

const [_ , setSomeValue] = useState(initialValue);

2. Callback Parameters

The classic use case. You often need the index but not the item, or vice versa.

const items = ['a', 'b', 'c'];

// I only need the index here.
items.forEach((_item, index) => {
  console.log("Index:", index);
});

3. Object Destructuring

Ever needed to pull just one or two properties from a large API response object? The underscore is perfect for signaling which fields you’re intentionally discarding.

const { usefulField, _unusedField, _anotherUnused } = apiResponse;

console.log(usefulField);

The One-Time Setup: Configure ESLint

To make this convention seamless, you need to tell ESLint about it. It's a simple, one-time change to your .eslintrc file.

{
  "rules": {
    "@typescript-eslint/no-unused-vars": [
      "error",
      { 
        "argsIgnorePattern": "^_", 
        "varsIgnorePattern": "^_",
        "caughtErrorsIgnorePattern": "^_"
      }
    ]
  ]
}

argsIgnorePattern: "^_": Ignores function arguments that start with an underscore.
varsIgnorePattern: "^_": Does the same for all other variables.
caughtErrorsIgnorePattern: "^_": Ignores error variables in try...catch blocks.

A Small Habit with a Big Impact

Adopting the underscore prefix is one of those small disciplines that separates good code from great code. It demonstrates foresight, cleanliness, and a respect for your teammates who will read and maintain your work. It silences unnecessary noise, signals your intent clearly, and keeps your entire codebase looking sharp and professional.

The next time you see that no-unused-vars warning, don't write an excuse. Just add an underscore.

My Pinch of Salt: Did AI and LLMs Kill the "First-Time Correct" Engineer?

Vatsal Trivedi — Wed, 24 Sep 2025 16:41:32 +0000

I remember a time, not too long ago, when the goal was to be First-Time Correct. It was a badge of honor. It meant you spent hours whiteboarding, meticulously planning your logic, and debating data structures before a single line of code was written. Committing something broken to the main branch was a walk of shame. The aim was craftsmanship.

Today, something feels different. We're all about velocity. The pressure is to push, to merge, to keep the CI/CD pipeline green and buzzing. And our new AI coding buddies—our Copilots and LLM assistants—are more than happy to help.

The Chatbot Workflow

Think about how we interact with a tool like ChatGPT. We ask a question. It gives an answer. It's not quite right. We tweak the prompt. Ask again. Still not there. We rephrase, add context, and ask a third time. Voilà, the perfect solution.

Now, look at our Git history. Does it look familiar?

A commit is pushed. The build fails. A quick fix is pushed. It passes tests but breaks something downstream. Another commit is pushed. This cycle continues, a rapid-fire conversation with the codebase, until we stumble upon the correct solution. We're essentially mimicking our chatbot interactions in our development process. The feedback loop of writing code is instantaneous, but the feedback loop of shipping working software is getting bigger, messier, and riddled with the ghosts of failed attempts.

Redefining "Versions"

Some argue that we can never be "First-Time Correct," and I agree. Perfection is a myth. But we used to have a system for imperfection. We had v1, v2, and so on. These were deliberate releases, accompanied by clear notes on what was working, what was failing, and what was intentionally skipped. It was a structured approach to iteration.

Now, our versioning feels… different. It's becoming:

v1: The code the AI generated in five seconds.
v1.1 through v1.9: The flurry of commits I had to make myself to fix all the things the AI missed, misunderstood, or hallucinated.

Our measure of success is subtly shifting from "Is it correct?" to "How fast did the AI help me fix the things it got wrong?" We've traded the discipline of forethought for the convenience of AI-powered hindsight. We're becoming expert editors of machine-generated code rather than architects of robust systems.

We gained speed, no doubt. But in our race for velocity, are we forgetting the art of being right? 🤔

So here's my open-ended question for you: Are we trading the enduring satisfaction of craftsmanship for the fleeting high of a passing pipeline?

Lets Be Real: Its Time to Ditch `any` for `unknown` in TypeScript

Vatsal Trivedi — Mon, 22 Sep 2025 11:22:57 +0000

We’ve all seen it in a pull request. A developer hits a snag with a tricky data type, and to get things working, they reach for the easiest tool available: any. It gets the job done and silences the compiler, but it comes at a hidden cost.

Our team has a Husky pre-commit hook set up to flag any, which is a great first step. But we all know that in a pinch, the --no-verify flag is an easy out. This makes the code review our most important line of defense. When you spot an any that has slipped through, it's the perfect opportunity to advocate for its safer, smarter alternative: unknown.

The Danger of `any`: A "Trust Me" Promise to the Compiler 🙈

Let’s be blunt: using any is like telling the TypeScript compiler to just look the other way. When you type a variable as any, you're effectively saying, "Disable all type-checking for this. I know what I’m doing."

This means you can do literally anything with that variable, and TypeScript won't stop you until it explodes at runtime.

Here's a classic example:

let myData: any;

myData = "This is a string";

// TypeScript has no problem with this line...
// but it will crash your app!
console.log(myData.toFixed(2)); 
// 😱 Uncaught TypeError: myData.toFixed is not a function

// The compiler is also perfectly happy with these obvious errors:
myData.someMethodThatDoesNotExist();
const result = myData * 10;

Every any you use punches a hole in the type safety we rely on TypeScript for. It turns potential compile-time catches into frustrating runtime bugs and makes refactoring a dangerous guessing game.

The Savior: `unknown` to the Rescue! 🦸

This is where unknown comes in and saves the day. Just like any, you can assign any value—a string, a number, an object—to a variable typed as unknown.

So what’s the big deal? The crucial difference is that unknown won't let you do anything with the value until you first prove what it is. You are forced to handle the uncertainty before you can use it.

Think of an unknown variable like a locked box. You know something’s inside, but you have to check what it is before you can safely use it.

Let's fix the previous example with unknown:

let myData: unknown;

myData = "This is a string";

// The compiler immediately stops you. This is a good thing!
// ❌ Error: Object is of type 'unknown'.
console.log(myData.toFixed(2));

// Here's how you work with it safely:
if (typeof myData === 'number') {
  // OK, inside this block, TypeScript now knows myData is a number.
  console.log(myData.toFixed(2));
} else if (typeof myData === 'string') {
  // And in here, it knows it's a string.
  console.log(myData.toUpperCase());
}

By switching to unknown, you’re prompted to write more defensive, robust code. It makes you handle different cases explicitly with type guards like typeof or instanceof, leading to a much more stable application.

The Code Reviewer's Playbook

Spotting an any during a code review is a great teaching moment. Here’s how to approach it constructively:

Understand the "Why": The developer was likely just trying to solve a typing problem quickly. No need to be critical.
Explain the Risk: Briefly mention that any bypasses type safety and can hide bugs that will only show up at runtime.
Offer the Solution: Suggest replacing any with unknown. Then, guide them to add the necessary type check (e.g., an if block) to safely access the variable. This not only resolves the immediate risk but also makes the code's intent clearer for everyone.

The Bottom Line

While any is a tempting shortcut, it undermines the very reason we use TypeScript. unknown gives you the same flexibility to accept any type of value but without sacrificing type safety.

By encouraging the use of unknown in our code reviews, we're fostering a habit of writing more deliberate, predictable, and robust code. It forces us to confront uncertainty head-on, resulting in fewer bugs and a healthier codebase. So next time you're tempted to use any, pause and reach for unknown instead. Your future self—and your teammates—will be grateful.

DEV Community: Vatsal Trivedi

I got tired of manual code reviews so I built a free automated security pipeline

The constraints I was working with

The approach: three layers, not one big tool

Layer 1: Pre-commit hooks

What's actually running here

Layer 2: GitHub Actions on pull requests

Why these two tools specifically

Layer 3: SonarQube for the full codebase picture

Spin it up locally first

Then automate it

What the first scan actually found

Handling the noise

The ongoing cost

Where to start if this seems like a lot

Resources

The "Lazy" Developer’s Guide to Twilio Auto-Replies (No Server Required)

The Idea Behind This Setup

Step 1 — Create a TwiML Bin

Step 2 — Configure Incoming Messages

Step 3 — Test the Flow

Understanding the TwiML

Why This Approach Works Well

When You Might Need Something More Advanced

Final Thoughts

How to Fix the NVM for Windows `NVM_SYMLINK` Activation Error

Why This Error Happens

Step-by-Step Fix (Guaranteed Method)

Step 1: Close All Node-Related Applications

Step 2: Open Command Prompt as Administrator

Step 3: Take Ownership of the Directory

Step 4: Kill Any Running Node Processes

Step 5: Delete the Existing Node Directory

Still Getting “Access is Denied”?

Fallback Method (If Files Are Locked)

Re-Enable NVM

Best Practice When Migrating to NVM

Final Thoughts

From MySQL to PostgreSQL: My Django Migration Story (and a Tool to Help)

My Solution: A Toolkit for Django Migrations

My Approach

Why I’m Sharing This

[Boost]

My Pinch of Salt: Did AI and LLMs Kill the "First-Time Correct" Engineer?

Leaving Breadcrumbs for Your AI: The Hansel and Gretel Approach

My Go-To: The @implement Directive

Beyond Implementation: @docs

Conclusion

The Cleanest Way to Handle Unused Variables in TypeScript

A Quick Story

Why the Underscore Is So Powerful

Putting It into Practice: Common Examples

1. React Props and Hooks

2. Callback Parameters

3. Object Destructuring

The One-Time Setup: Configure ESLint

A Small Habit with a Big Impact

My Pinch of Salt: Did AI and LLMs Kill the "First-Time Correct" Engineer?

The Chatbot Workflow

Redefining "Versions"

Lets Be Real: Its Time to Ditch `any` for `unknown` in TypeScript

The Danger of any: A "Trust Me" Promise to the Compiler 🙈

The Savior: unknown to the Rescue! 🦸

The Code Reviewer's Playbook

The Bottom Line

My Go-To: The `@implement` Directive

Beyond Implementation: `@docs`

The Danger of `any`: A "Trust Me" Promise to the Compiler 🙈

The Savior: `unknown` to the Rescue! 🦸