DEV Community: Leon Martin

LeetCode in 2026: The Skill Nobody Respects (But Everyone Still Needs)

Leon Martin — Mon, 02 Mar 2026 20:10:46 +0000

Let me say something that will probably annoy both sides.

Yes, AI can solve most LeetCode problems instantly.

And yes, I’m still practicing them.

Not because I enjoy pain.
Not because I love red/green submission screens.
But because I’m starting to realize something uncomfortable:

We are slowly losing our ability to think without assistance.

And that scares me more than AI ever did.

“Why Are You Still Grinding LeetCode? Just Ask GPT.”

I hear this constantly.

“Bro, interviews are outdated.”
“Bro, real work isn’t binary trees.”
“Bro, just use AI.”

Sure.

AI can give you a perfect DFS in seconds.
It can generate a dynamic programming solution cleaner than yours.
It can explain time complexity better than your college professor.

But here’s the real question:

If the AI disappeared tomorrow…
Would you still know what’s happening?

Or would you just be staring at your own code like it’s written in hieroglyphics?

The Layoffs Changed Everything

Let’s not pretend the last two years didn’t shift the ground under our feet.

Teams were cut.
“High performers” were let go.
Senior engineers were suddenly competing with mid-level devs.
Entry-level roles started asking for 3–5 years of experience.

And in that chaos, one pattern became obvious:

The people who survived weren’t the fastest typers.

They were the ones who could untangle complexity.

The ones who could:

Debug production issues without panicking
Reason through messy systems
Break down vague problems into structured steps
Think clearly under pressure

That’s algorithmic thinking.

That’s what LeetCode trains.

Not memorization.
Not trivia.

Structured thought.

AI Makes You Faster. It Doesn’t Make You Deeper.

I use AI every single day.

To refactor.
To scaffold.
To debug small issues.
To save time.

If you’re not using AI in 2026, you’re being stubborn.

But here’s the uncomfortable part:

AI makes you faster.

LeetCode makes you deeper.

And speed without depth is fragile.

You can ship features quickly with AI assistance.

But when:

There’s a race condition
Memory spikes under load
A weird edge case breaks production
The model-generated solution is “almost” correct

Someone still needs to think.

And if you’ve outsourced your thinking for too long, that moment becomes terrifying.

“But I Don’t Use Graphs at Work.”

Correct.

Most of us aren’t implementing Dijkstra on a random Wednesday.

But solving graph problems forces you to:

Model relationships
Track state transitions
Think about complexity
Visualize flows

And guess what large distributed systems are?

Graphs.
State machines.
Transitions.
Constraints.

LeetCode problems are artificial.

But the mental muscle they build isn’t.

The Real Problem: Comfort Addiction

AI removed friction.

You don’t sit stuck for 45 minutes anymore.
You don’t draw diagrams.
You don’t wrestle with recursion until it finally clicks.

You paste.
You regenerate.
You move on.

Efficient? Absolutely.

But growth rarely happens in comfort.

LeetCode forces friction.

It forces you to sit with not knowing.

And in an era where autocomplete finishes your thoughts, the ability to struggle productively is becoming rare.

The Dangerous Future Nobody Talks About

Imagine a generation of developers who can ship full apps with prompts…

…but freeze when:

The AI gives a wrong answer
The bug doesn’t reproduce locally
The system behaves unpredictably
The solution requires original reasoning

That’s not a hypothetical.

I’ve seen it already.

Developers who move incredibly fast, until they hit the 10% that requires raw thinking.

Then everything slows down.

Because they never trained that muscle.

So Should You Still Do LeetCode?

If your only goal is to pass interviews with AI assistance?

Maybe not.

If your goal is to become antifragile in a volatile market?

Yes.

Not because companies worship it.
Not because interview culture is perfect.

But because thinking is becoming optional.

And optional skills disappear.

This Isn’t About Nostalgia

I’m not romanticizing “the old days.”

I’m not anti-AI.
I’m not anti-productivity.
I’m not saying grind 500 problems like it’s 2018.

I’m saying this:

Use AI.

But don’t let it atrophy your brain.

Solve problems without help sometimes.
Struggle intentionally.
Build intuition.
Understand why the solution works before you paste it.

Because one day, the tool will fail.

And in that moment, the only thing left is you.

Final Question

If ChatGPT went offline for a week…

Would your coding confidence drop?

Or would it stay the same?

Be honest.

Are you sharpening your thinking?

Or outsourcing it?

Let’s fight in the comments.

How dev.to Became My Cozy Corner of the Internet (and How to Find Yours)

Leon Martin — Thu, 12 Feb 2026 17:04:20 +0000

The last three years in tech felt like speedrunning a decade.

Mass layoffs.
Friends suddenly “open to work.”
Group chats going from shipping memes to severance package advice.
Twitter/X turning into a gladiator arena.
LinkedIn becoming a 24/7 hustle theatre.
AI replacing, augmenting, threatening—depending on who you ask.

I watched insanely talented teammates pack their laptops into cardboard boxes. I saw people who mentored me start doubting their own value. I saw junior devs panic-learning five frameworks at once because some influencer said their stack was “dead.”

And somewhere in the middle of all that noise, I realized something uncomfortable:

The internet was making me anxious about a career I actually love.

That’s when dev.to quietly became my cozy corner of the internet.

Not perfect. Not magical. Just… healthier.

The Algorithm vs. The Developer 🍃

Most technical social networks are built for velocity, not depth.

Short takes.
Hot takes.
“Unpopular opinion.”
“React is dead.”
“AI will replace you.”
“10x engineers only.”

You scroll. You compare. You feel behind.

The past two years amplified that. Layoffs made everything competitive. AI tools made everything uncertain. Every week there was a new framework, a new paradigm, a new “you must learn this now.”

It became exhausting to exist online as a developer.

And the worst part? It didn’t make me better.

It just made me more reactive.

What I Found on dev.to 🌱

dev.to feels slower.

You can actually write.

You can disagree without farming outrage.

You can admit you’re tired.

When I started posting there consistently, something changed. I wasn’t optimizing for likes or going viral. I was thinking in paragraphs again.

Long-form writing forces clarity. You can’t hide behind a hot take when you have 1,000 words to defend it.

More importantly, the comments felt human. Not always polite—but human. Developers sharing their own burnout stories. Their layoff experiences. Their doubts about AI. Their pivot to new stacks. Their quiet wins.

It reminded me that behind every GitHub profile is a nervous system.

Layoffs Changed the Tone of Everything 🍂

Before 2023, tech Twitter felt like a highlight reel.
After the layoffs, it became a survival channel.

People started:

Hoarding knowledge.
Gatekeeping niches.
Speed-running certifications.
Pretending they weren’t scared.

And I get it. Fear does that.

But here’s what I learned watching friends go through layoffs:

Your value is not your current stack.

Your identity is not your employer.

Your sanity is not worth sacrificing for relevance.

The people who handled it best weren’t the loudest online.

They were the ones with real relationships.

Not followers.
Not impressions.
Relationships.

Authentic Networking Is Boring (And That’s Good) 🌿

The best connections I’ve made weren’t through viral posts.

They were:

Comment threads that turned into DMs.
Honest articles about frustration.
Shared curiosity about a tool.
Admitting “I don’t know.”

Authentic networking is slow. It doesn’t scale well. It doesn’t look impressive on LinkedIn.

But when layoffs hit, those are the people who check in.

Not because you optimized your personal brand.
But because you were real.

Mental Health in Developer Spaces 🌾

Burnout doesn’t always look like collapse.

Sometimes it looks like:

Learning three frameworks you don’t even like.
Rewriting your portfolio every month.
Checking job boards before coffee.
Doom-scrolling tech discourse at 1 AM.

The ecosystem shifted hard in the last three years:

AI tools exploded.
Frontend complexity ballooned.
Hiring froze.
Salaries stabilized or dropped in some regions.
Expectations increased.

You’re not weak if you felt that.

You’re human.

And you don’t need to absorb every wave of hype to survive.

Why You Should Learn (and Why You Shouldn’t) 🪴

Yes, you should keep learning.

But not out of panic.

Learn:

Because you’re curious.
Because something excites you.
Because you want leverage.
Because it solves a real problem you face.

Don’t learn:

Because someone said your stack is obsolete.
Because you’re afraid of being replaced tomorrow.
Because comparison is eating you alive.

The last three years taught me this:

Adaptation is important.

Anxiety-driven adaptation is toxic.

There’s a difference.

Designing Your Own “Safe Space” Online

You don’t have to quit social media.

You just have to design your environment intentionally.

Here’s what worked for me:

1. Curate Aggressively

Unfollow accounts that:

Trigger comparison spirals.
Constantly predict doom.
Turn every topic into outrage.

Follow people who:

Share thoughtful breakdowns.
Talk about failure openly.
Build in public without ego.

Your feed is an API.

Control the inputs.

2. Create More Than You Consume

Consumption creates comparison.
Creation creates clarity.

Writing on dev.to forced me to:

Form opinions.
Reflect on mistakes.
Slow down my thinking.

You don’t need to be an expert.

You need to be honest.

3. Separate Learning from Performance

Not everything you learn needs to become content.

Some things are:

Just for you.
Just for exploration.
Just for fun.

When learning becomes performance, joy disappears.

4. Build Small Private Circles

Group chats.
Discord servers.
Tiny mastermind groups.

Three to five developers you trust > 50,000 followers.

When layoffs hit, that’s where the real support lives.

5. Log Off Without Announcing It

You don’t owe the timeline your presence.

If tech discourse feels loud:

Close the tab.
Go build something small.
Read documentation.
Go outside (yes, actually).

Silence is underrated.

dev.to Isn’t Perfect (And That’s Fine)

There’s still hype.
There’s still debate.
There’s still ego.

But the format encourages depth.

And depth encourages humanity.

That’s why it became my cozy corner.

Not because it’s superior.
But because it allowed me to slow down.

And in a chaotic ecosystem, slowing down is a competitive advantage.

Final Thought

The last three years shook the industry.

They also exposed something important:

Your career is long.

The hype cycles are short.

The internet is loud.

Your nervous system is fragile.

Find a corner of the web where you can think clearly.

Maybe it’s dev.to.

Maybe it’s a niche forum.

Maybe it’s a private Slack group.

But design it on purpose.

Because in a world optimizing for attention,

protecting your peace might be the most senior thing you can do.

What’s your cozy corner of the internet?
Let’s talk.

The last months Vibe Coding starts looks like content creation with a compiler attached...

Leon Martin — Mon, 09 Feb 2026 17:28:05 +0000

Dear Vibe Coder: Your App Works. Your Code Is the Problem.

Leon Martin ・ Feb 9

#programming #ai #discuss #career

Dear Vibe Coder: Your Code Is the Problem.

Leon Martin — Mon, 09 Feb 2026 17:12:21 +0000

Dear Vibe Coder: Let’s Talk (For Real)

I’m going to say the quiet part out loud.

Your app works.

Your demo looks cool.

Your code is a nightmare waiting to happen.

And before you get mad and quote-tweet this, breathe.

This is not an anti-AI rant.

I use AI every single day. You probably should too.

If you’re a developer in 2026 and not using AI, you’re already behind.

The problem isn’t AI.

The problem is vibe coding culture and how it’s quietly rotting the foundations of real software engineering.

What People Mean by “Vibe Coding”

Let’s define it clearly, because this term gets abused.

Vibe coding is when:

You don’t really understand the code
You don’t care how it works
You trust the output because it feels right
And when it breaks, you regenerate it until it stops screaming

It’s coding by vibes, prompts, and blind optimism.

It looks incredible on social media:

“Built a SaaS in 48 hours with GPT 🚀🔥”

What you don’t see:

No tests
No error handling
No mental model
No chance of maintaining it six months later

That’s not engineering.

That’s content creation with a compiler attached.

AI Didn’t Create Bad Developers, It Just Exposed Them Faster

Here’s the uncomfortable truth:

Bad developers existed long before AI.

What AI did was remove the friction that used to expose them.

Before:

If you didn’t understand async, you were stuck
If you didn’t understand state, your app broke
If you didn’t understand databases, production punished you immediately

Now?
You paste an error into an LLM, skim the explanation you didn’t really read, and ship.

The app works.

The understanding never arrived.

The Failure Is Delayed, And That’s the Dangerous Part

Vibe-coded apps don’t fail on day one.

They fail:

When traffic grows
When requirements change
When the AI suggestion is almost right
When someone else has to read the code
When you have to read your own code three months later

I’ve watched teams burn weeks untangling AI-generated spaghetti because nobody understood the logic, including the person who shipped it.

And guess who gets blamed?

Not the vibes.

Not the tool.

The developer.

“But It Works” Is Not a Technical Argument

Yes, it works.

So does duct tape.

So does a shell script written at 3 a.m.

So does pushing to main on Friday afternoon.

Working is the minimum requirement, not the goal.

Engineering is about:

Predictability
Maintainability
Tradeoffs
Understanding failure modes

If your entire strategy is “the AI will fix it,” you’re not building software.

You’re gambling, with extra steps.

Using AI Is Mandatory. Thinking Is Non‑Negotiable.

Let’s be very clear.

If you’re a developer in 2026 and you’re not using AI, you’re doing it wrong.

But if you’re using AI instead of thinking, you’re also doing it wrong.

AI should:

Speed you up
Reduce boilerplate
Help you explore solutions
Catch obvious mistakes

AI should not:

Replace your mental model
Decide architecture for you
Debug systems you don’t understand
Be the only reason your app works

The best developers right now aren’t vibe coders.

They’re AI‑augmented engineers.

That difference matters more than ever.

Why Juniors Are Getting Destroyed by This

This is the part nobody wants to talk about.

New developers see vibe coding and think:

“Oh, this is how professionals work now.”

So they skip fundamentals.

They skip debugging.

They skip learning how systems actually behave.

Then they hit the job market.

And companies aren’t hiring vibe coders.

They’re hiring people who can:

Read ugly legacy code
Debug production issues
Explain why something broke
Fix problems without regenerating the universe

That’s why juniors feel stuck.

That’s why “entry-level” roles ask for 3–5 years of experience.

That’s why vibe coding hurts the people who need guidance the most.

If This Offends You, Ask Yourself Why

If this article makes you angry, sit with that feeling for a second.

Because deep down, most vibe coders already know the truth:

They’re shipping faster, but understanding less.

They’re productive today, fragile tomorrow.

They look senior on Twitter, and junior in real codebases.

You don’t need to quit AI.

You don’t need to write assembly by candlelight either.

You just need to care.

Care about how things work.

Care about reading code.

Care about fundamentals.

Care about the people who will inherit your mess.

One Final Intrusive Thought

AI didn’t ruin programming.

Vibe coding didn’t either.

But pretending vibes are a substitute for understanding?

That absolutely will.

Use AI.

Ship fast.

Build cool things.

Just don’t confuse speed with skill.

And please, for the sake of every future teammate, learn the basics.

Your app depends on it.

Your career depends on it.

And so does the industry you’re trying to join.

So… be honest.

Are you vibe coding?

Or are you actually engineering?

Let’s argue in the comments.

The Ultimate Claude Code Guide: Every Hidden Trick, Hack, and Power Feature You Need to Know

Leon Martin — Tue, 09 Sep 2025 17:55:39 +0000

Let’s be real. Most devs use Claude Code like it’s a fancy autocomplete tool and hey, no shame, we’ve all been there. But Claude Code is so much more than “just ask it to generate a Python function.” Under the hood? It’s a whole AI dev platform disguised as a terminal whisperer.

So, after months of poking, breaking, automating, rage quitting, and eventually mastering the thing, I put together this beefy (but fun, I promise) guide.

You’ll find:

Hidden hook superpowers (yes, it has hooks)
Custom agents (that actually listen)
Ridiculous slash command automations
Integration hacks (MCP is your new bestie)
Context sorcery with CLAUDE.md

...and a bunch of spicy CLI flags to make you feel like you’ve unlocked developer god mode.

You ready? Cool. Let’s do this.

Part 1: Hooks - The Ultimate Automation Framework

Claude Code hooks are shell commands that execute automatically at specific points in the development lifecycle. Think of them as triggers that give you deterministic control over Claude's behavior.

The 8 Hook Types You Need to Master

Claude Code provides 8 different hook events, each serving specific automation purposes:

1. UserPromptSubmit Hook
Fires immediately when you submit a prompt, before Claude processes it.

# Setup via /hooks command or manually in .claude/settings.json
{
  "hooks": {
    "UserPromptSubmit": [{
      "hooks": [{
        "type": "command",
        "command": "echo 'Prompt submitted at $(date)' >> ~/.claude/prompt-log.txt"
      }]
    }]
  }
}

2. PreToolUse Hook - The Game Changer
Runs before Claude executes any tool. This is where the magic happens for validation and security:

# Block dangerous commands
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command", 
        "command": "if [[ \"$CLAUDE_TOOL_INPUT\" == *\"rm -rf\"* ]]; then echo 'Dangerous command blocked!' && exit 2; fi"
      }]
    }]
  }
}

3. PostToolUse Hook - Auto-formatting Magic
Executes after successful tool completion:

# Auto-format TypeScript files after editing
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "if [[ \"$CLAUDE_FILE_PATHS\" =~ \\.(ts|tsx)$ ]]; then prettier --write \"$CLAUDE_FILE_PATHS\"; fi"
      }]
    }]
  }
}

4. Notification Hook
Fires when Claude sends notifications (permission requests, waiting for input):

# Desktop notifications
{
  "hooks": {
    "Notification": [{
      "hooks": [{
        "type": "command",
        "command": "osascript -e 'display notification \"Claude needs attention\" with title \"Claude Code\"'"
      }]
    }]
  }
}

5. Stop Hook - AI-Powered Completions
Runs when Claude finishes responding:

# Generate AI completion messages
{
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "python ~/.claude/hooks/generate_completion.py"
      }]
    }]
  }
}

6. SubagentStop Hook
Fires when Claude Code subagents finish:

# Track subagent completions
{
  "hooks": {
    "SubagentStop": [{
      "hooks": [{
        "type": "command",
        "command": "echo 'Subagent task completed at $(date)' >> ~/.claude/subagent-log.txt"
      }]
    }]
  }
}

7. PreCompact Hook
Runs before context compaction (when Claude's memory gets too full):

# Backup transcripts before compaction
{
  "hooks": {
    "PreCompact": [{
      "hooks": [{
        "type": "command",
        "command": "cp ~/.claude/current-session.jsonl ~/.claude/backups/session-$(date +%s).jsonl"
      }]
    }]
  }
}

8. SessionStart Hook
Executes when starting new sessions:

# Load development context automatically
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "git status > /tmp/claude-git-context.txt && echo 'Development context loaded'"
      }]
    }]
  }
}

Advanced Hook Patterns

Environment Variable Access:
Hooks have access to special environment variables:

CLAUDE_PROJECT_DIR - Current project directory
CLAUDE_FILE_PATHS - Files being modified
CLAUDE_TOOL_INPUT - Tool parameters (JSON format)

Conditional Hook Execution:

# Only run hooks in production projects
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit",
      "hooks": [{
        "type": "command",
        "command": "if [[ -f package.json ]] && grep -q '\"production\"' package.json; then npm run lint; fi"
      }]
    }]
  }
}

JSON Response Control:
Hooks can return structured JSON for sophisticated control:

# Python hook script returning JSON
import json
import sys

# Hook logic here...

response = {
    "continue": True,  # Whether Claude should continue
    "feedback": "Code quality check passed",
    "modify_prompt": False
}

print(json.dumps(response))

Part 2: MCP - The Universal Connector

Model Context Protocol (MCP) is Claude Code's secret weapon for connecting to external tools and data sources. Most developers don't realize how powerful this is.

Essential MCP Servers You Should Install

GitHub Integration:

claude mcp add github -- npx @modelcontextprotocol/server-github
# Now you can: "Create a PR for the latest changes and assign it to @reviewer"

Database Access:

claude mcp add postgres -- npx @modelcontextprotocol/server-postgres
# Query your database: "Find all users who signed up this week from our Postgres DB"

File System Operations:

claude mcp add filesystem -- npx @modelcontextprotocol/server-filesystem
# Enhanced file operations: "Search all .ts files for the pattern 'deprecated' and create a cleanup plan"

Web Browsing with Puppeteer:

claude mcp add puppeteer -- npx @modelcontextprotocol/server-puppeteer
# Take screenshots: "Navigate to localhost:3000 and take a screenshot of the login page"

Figma Design Integration:

claude mcp add figma -- npx @modelcontextprotocol/server-figma
# Access designs: "Update our button components based on the latest Figma designs"

Slack Integration:

claude mcp add slack -- npx @modelcontextprotocol/server-slack
# Team communication: "Send a summary of today's deployments to the #engineering channel"

MCP Configuration Scopes - The Hidden Hierarchy

MCP servers can be configured at three levels:

1. User Scope (Global)

# Available across all projects
claude mcp add github -s user -- npx @modelcontextprotocol/server-github

2. Local Scope (Project-specific)

# Only for current project
claude mcp add postgres -s local -- npx @modelcontextprotocol/server-postgres

3. Project Scope (Team-shared)

# Committed to repository for team sharing
claude mcp add figma -s project -- npx @modelcontextprotocol/server-figma

Advanced MCP Techniques

Custom MCP Server Configuration:

# Add MCP server with custom configuration
claude mcp add-json custom-server '{
  "command": "node",
  "args": ["./custom-mcp-server.js"],
  "env": {
    "API_KEY": "your-api-key"
  }
}'

MCP Debug Mode:

# Debug MCP connection issues
claude --mcp-debug

Token Limit Management:

# Increase MCP output token limit
export MAX_MCP_OUTPUT_TOKENS=50000
claude

Import from Claude Desktop:

# Transfer MCP servers from Claude Desktop
claude mcp add-from-claude-desktop

Part 3: Custom Slash Commands - Your Personal Automation Arsenal

Custom slash commands turn repetitive workflows into single commands. Most developers miss this game-changing feature.

Creating Command Templates

Create .claude/commands/ directory and add markdown files:

Project Setup Command (.claude/commands/setup.md):

# Setup Development Environment

Please perform the following setup tasks:

1. Install dependencies: `npm install`
2. Create environment file from template: `cp .env.example .env`
3. Run database migrations: `npm run migrate`
4. Start development server: `npm run dev`
5. Open browser to localhost:3000

Arguments: $ARGUMENTS

Usage: /setup or /setup --verbose

Code Review Command (.claude/commands/review.md):

# Comprehensive Code Review

Analyze the provided code changes and provide feedback on:

1. **Security**: Check for potential vulnerabilities
2. **Performance**: Identify optimization opportunities  
3. **Maintainability**: Assess code structure and clarity
4. **Testing**: Suggest test coverage improvements
5. **Best Practices**: Ensure adherence to project standards

Focus areas: $ARGUMENTS

Please be specific and actionable in your feedback.

Bug Triage Command (.claude/commands/bug-triage.md):

# Bug Triage and Analysis

For the reported bug: $ARGUMENTS

1. Use `gh issue view` to get complete issue details
2. Reproduce the issue locally if possible
3. Analyze relevant code sections
4. Identify root cause
5. Propose solution with implementation plan
6. Estimate effort and impact
7. Suggest appropriate priority level

Create a detailed action plan with specific next steps.

Advanced Command Patterns

Conditional Command Logic:

# Smart Deploy Command

Based on the current branch and environment:

If on `main` branch:
- Run full test suite
- Deploy to production
- Tag release with version bump

If on `develop` branch:
- Run quick tests
- Deploy to staging
- Notify team in Slack

If on feature branch:
- Deploy to preview environment
- Share preview URL

Branch: $ARGUMENTS

Multi-Step Workflow Commands:

# Complete Feature Implementation

For feature: $ARGUMENTS

## Phase 1: Planning
1. Create feature branch: `git checkout -b feature/$ARGUMENTS`
2. Review requirements and create implementation plan
3. Update project documentation

## Phase 2: Implementation
1. Write failing tests first (TDD approach)
2. Implement core functionality
3. Add error handling and edge cases
4. Update documentation

## Phase 3: Quality Assurance
1. Run full test suite
2. Perform security review
3. Check performance impact
4. Update CHANGELOG.md

## Phase 4: Deployment
1. Create pull request with detailed description
2. Request code review from appropriate team members
3. Deploy to staging for testing
4. Monitor metrics and logs

Execute each phase systematically and confirm completion before proceeding.

Team-Specific Commands:
Commands in .claude/commands/ are automatically shared when team members clone your repository, creating consistent workflows across your entire development team.

Part 4: CLAUDE.md - The Context Configuration Master File

The CLAUDE.md file is Claude Code's secret weapon for project-specific intelligence. It gets automatically loaded into Claude's context when you start a session.

Ultimate CLAUDE.md Template

# Project Overview

## Architecture
- **Frontend**: Next.js 14 with TypeScript
- **Backend**: Node.js with Express
- **Database**: PostgreSQL with Prisma ORM
- **Authentication**: NextAuth.js
- **Deployment**: Vercel (frontend), Railway (backend)

## Key Commands
- `npm run dev` - Start development servers
- `npm run build` - Build for production
- `npm run test` - Run test suite
- `npm run lint` - Run ESLint
- `npm run type-check` - TypeScript type checking

## Code Standards
- Use TypeScript strict mode
- Prefer functional components over class components
- Write descriptive variable names (no single letters except for loops)
- Add JSDoc comments for public functions
- Follow clean architecture principles
- Keep components under 200 lines
- Use custom hooks for complex state logic

## Testing Guidelines
- Write tests using Jest and React Testing Library
- Aim for 80% code coverage minimum
- Include edge cases and error scenarios
- Test user interactions, not implementation details
- Mock external dependencies

## Security Requirements
- Validate all user inputs
- Use parameterized queries for database access
- Implement proper CSRF protection
- Follow OWASP security guidelines
- Never log sensitive information

## Performance Guidelines
- Optimize images with next/image
- Use React.memo for expensive components
- Implement proper loading states
- Cache API responses where appropriate
- Monitor Core Web Vitals

## Database Schema Notes
- Users table: id, email, name, created_at, updated_at
- Posts table: id, user_id, title, content, published, created_at
- Comments table: id, post_id, user_id, content, created_at

## API Endpoints
- POST /api/auth/signin - User authentication
- GET /api/posts - List all posts
- POST /api/posts - Create new post
- GET /api/posts/[id] - Get specific post
- PUT /api/posts/[id] - Update post
- DELETE /api/posts/[id] - Delete post

## Environment Variables
- DATABASE_URL - PostgreSQL connection string
- NEXTAUTH_SECRET - Authentication secret
- NEXTAUTH_URL - Base URL for auth callbacks
- GITHUB_CLIENT_ID - GitHub OAuth client ID
- GITHUB_CLIENT_SECRET - GitHub OAuth secret

## Deployment Process
1. Run tests and type checking
2. Build application
3. Deploy to staging environment
4. Run integration tests
5. Deploy to production
6. Monitor error rates and performance

## Common Issues and Solutions
- **TypeScript errors**: Run `npm run type-check` to identify issues
- **Build failures**: Check for missing dependencies or env vars
- **Database connection**: Verify DATABASE_URL format and permissions
- **Authentication issues**: Check NEXTAUTH_SECRET and URL configuration

## Team Preferences
- Use conventional commits for better changelog generation
- Create feature branches from `develop`
- Require PR reviews for `main` branch
- Update documentation with feature changes
- Tag releases with semantic versioning

Specialized CLAUDE.md Sections

For API Projects:

## API Design Standards
- Use RESTful principles
- Implement proper HTTP status codes
- Add request/response examples in OpenAPI spec
- Use consistent error response format
- Implement rate limiting
- Add API versioning strategy

For Frontend Projects:

## UI/UX Guidelines
- Follow design system components
- Implement responsive design (mobile-first)
- Add proper ARIA labels for accessibility
- Use semantic HTML elements
- Optimize for Core Web Vitals
- Test across major browsers

For DevOps/Infrastructure:

## Infrastructure Notes
- **Cloud Provider**: AWS
- **Container Registry**: ECR
- **Orchestration**: ECS with Fargate
- **Load Balancer**: Application Load Balancer
- **Database**: RDS PostgreSQL
- **Cache**: ElastiCache Redis
- **Monitoring**: CloudWatch + DataDog
- **Secrets**: AWS Secrets Manager

Part 5: Headless Mode and Automation Mastery

Claude Code's headless mode (-p flag) unlocks powerful automation capabilities that most developers never explore.

Basic Headless Operations

# Quick file analysis
claude -p "How many TypeScript files are in this project?"

# Code quality check
claude -p "Review the latest commit for potential issues"

# Automated documentation
claude -p "Generate API documentation for all endpoint files"

Advanced Headless Workflows

CI/CD Integration:

# GitHub Actions workflow
name: Claude Code Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Claude Code Review
        run: |
          claude -p "Review this PR for security vulnerabilities and performance issues" \
            --output-format json > review-results.json

Pre-commit Hooks:

#!/bin/bash
# .git/hooks/pre-commit
changed_files=$(git diff --cached --name-only --diff-filter=ACM)
if [ -n "$changed_files" ]; then
    claude -p "Review these changed files for issues: $changed_files" \
        --output-format stream-json
fi

Automated Code Generation:

# Generate test files for new components
find src/components -name "*.tsx" -newer .last-test-gen | while read file; do
    claude -p "Generate comprehensive Jest tests for this React component: $file" \
        --output-format json > "${file%.tsx}.test.tsx"
done
touch .last-test-gen

Log Analysis Automation:

# Monitor logs and alert on anomalies
tail -f /var/log/app.log | while read line; do
    echo "$line" | claude -p "Analyze this log entry for security threats or errors. Alert if critical."
done

Output Format Options

# JSON output for programmatic processing
claude -p "Count all TODO comments" --output-format json

# Stream JSON for real-time processing
claude -p "Monitor this log file for errors" --output-format stream-json

# Plain text (default)
claude -p "Explain this function" --output-format text

Part 6: Advanced CLI Flags and Configuration

Claude Code has numerous CLI options that unlock advanced functionality.

Essential CLI Flags

# Skip all permission prompts (dangerous but useful for automation)
claude --dangerously-skip-permissions

# Enable MCP debugging
claude --mcp-debug

# Set custom configuration directory
claude --config-dir ~/.my-claude-config

# Use specific model
claude --model claude-3-opus-20240229

# Set custom timeout for MCP servers
MCP_TIMEOUT=30 claude

# Increase MCP output token limit
MAX_MCP_OUTPUT_TOKENS=50000 claude

# Add shell command prefix
CLAUDE_CODE_SHELL_PREFIX="time" claude

Configuration File Mastery

Global Settings (~/.claude/settings.json):

{
  "defaultModel": "claude-3-sonnet-20240229",
  "autoAcceptPermissions": false,
  "maxOutputTokens": 4096,
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "echo 'Welcome back to Claude Code!'"
      }]
    }]
  },
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"]
    }
  }
}

Project Settings (.claude/settings.json):

{
  "projectName": "MyAwesomeProject",
  "defaultBranch": "main",
  "testCommand": "npm test",
  "lintCommand": "npm run lint",
  "buildCommand": "npm run build",
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit",
      "hooks": [{
        "type": "command",
        "command": "npm run lint --fix"
      }]
    }]
  }
}

Part 7: Git Integration Superpowers

Claude Code's Git integration goes far beyond basic commands. Here are the advanced workflows most developers miss.

Advanced Git Workflows

Intelligent Branch Management:

# Claude understands Git context automatically
claude "Create a feature branch for user authentication, implement the login component, and set up the API endpoint"

# Smart commit message generation
claude "Commit these changes with an appropriate conventional commit message"

# Complex Git operations
claude "Rebase the current branch onto main, resolve any conflicts, and force push"

Git History Analysis:

# Investigate code changes
claude "What changes were made to the authentication system in the last 3 months?"

# Find responsible developers
claude "Who has been working on the user management features?"

# Understand architectural decisions
claude "Why was the payment processing logic moved to a separate service? Check git history for context."

Advanced PR Management:

# Create comprehensive PRs
claude "Create a pull request for the current changes, include a detailed description with screenshots"

# Respond to review comments
claude "Address all the comments on PR #123 and push the changes"

# Automated PR workflows
claude "For each open PR, check if CI is passing and merge if approved by 2+ reviewers"

Git-based Automation Patterns

Release Management:

# Automated release process
claude "Generate release notes from commits since last tag, bump version in package.json, create git tag, and push"

# Hotfix workflow
claude "Create hotfix branch from main, apply the fix for issue #456, and create emergency PR"

Code Archaeology:

# Understand legacy code
claude "Find when this deprecated function was last used and create a safe removal plan"

# Track feature evolution
claude "Show me how the user authentication flow has evolved over the past year"

Part 8: IDE Extensions and Integrations

While Claude Code runs in the terminal, it integrates seamlessly with popular IDEs through extensions and configurations.

VS Code Integration

Claude Code Extension Setup:

# Install the official extension
code --install-extension anthropic.claude-code

# Multiple parallel instances
# Open different panes for different parts of your codebase

Custom VS Code Tasks:

// .vscode/tasks.json
{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Claude Review",
      "type": "shell",
      "command": "claude",
      "args": ["-p", "Review the currently open file for improvements"],
      "group": "build",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": false,
        "panel": "new"
      }
    }
  ]
}

Keyboard Shortcuts:

// .vscode/keybindings.json
[
  {
    "key": "ctrl+shift+c",
    "command": "workbench.action.terminal.sendSequence",
    "args": {
      "text": "claude -p \"Review current file\"\n"
    }
  }
]

JetBrains Integration

Claude Code works with IntelliJ IDEA, WebStorm, and other JetBrains IDEs:

# Terminal integration within IDE
# Set up external tool in IDE settings
# Program: claude
# Arguments: -p "Analyze the current file"
# Working directory: $ProjectFileDir$

Cursor Integration

Many Cursor users are switching to Claude Code for agent-like functionality:

# Use Cursor for quick completions
# Use Claude Code for complex multi-file operations
# Best of both worlds approach

Part 9: Custom Agents and Sub-Agents

Claude Code supports custom agents and sub-agents for specialized workflows.

Creating Custom Agents

Database Expert Agent (.claude/agents/db-expert.md):

# Database Expert Agent

You are a specialized database expert agent focused on:

## Expertise Areas
- Query optimization and performance tuning
- Schema design and normalization
- Index strategy and analysis
- Migration planning and execution
- Security and access control

## Available Tools
- Database query execution via MCP
- Performance analysis tools
- Schema comparison utilities

## Response Format
Always provide:
1. Analysis summary
2. Specific recommendations
3. Implementation steps
4. Performance impact assessment
5. Risk evaluation

Use concrete examples and explain the reasoning behind recommendations.

Security Auditor Agent (.claude/agents/security.md):

# Security Auditor Agent

Specialized in application security analysis and vulnerability assessment.

## Security Checklist
- [ ] Input validation and sanitization
- [ ] Authentication and authorization
- [ ] Data encryption (at rest and in transit)
- [ ] SQL injection prevention
- [ ] XSS protection
- [ ] CSRF mitigation
- [ ] Dependency vulnerability scan
- [ ] Secrets management
- [ ] Error handling (no sensitive info leakage)
- [ ] Access control implementation

## Tools Available
- Security scanning via MCP
- Dependency checker
- Code analysis tools

Always provide severity ratings and remediation steps.

Invoking Custom Agents

# Use @ mentions for custom agents
claude "@db-expert analyze the performance of our user queries"

claude "@security audit the authentication system for vulnerabilities"

Sub-Agent Coordination

Claude Code can coordinate multiple sub-agents for complex tasks:

# Multi-agent workflow
claude "Use @db-expert to optimize our queries, then @security to audit the changes, then @frontend to update the UI accordingly"

Part 10: Advanced Security and Permissions

Claude Code includes sophisticated security features that go beyond basic permission prompts.

Permission System Mastery

Granular Permission Control:

{
  "permissions": {
    "allowedCommands": ["git", "npm", "yarn", "pnpm"],
    "blockedCommands": ["rm", "sudo", "chmod 777"],
    "allowedDirectories": ["./src", "./tests", "./docs"],
    "blockedDirectories": ["./node_modules", "./.env"],
    "requireConfirmation": ["git push", "npm publish"]
  }
}

File Protection Hooks:

# Protect sensitive files
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "if [[ \"$CLAUDE_FILE_PATHS\" == *\".env\"* ]]; then echo 'Cannot edit .env file' && exit 2; fi"
      }]
    }]
  }
}

Enterprise Security Features

Audit Logging:

# Log all Claude Code activities
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "echo \"$(date): Tool ${CLAUDE_TOOL_NAME} executed by ${USER}\" >> /var/log/claude-audit.log"
      }]
    }]
  }
}

Compliance Monitoring:

# Monitor for compliance violations
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit",
      "hooks": [{
        "type": "command",
        "command": "python /opt/compliance/check-edit.py \"$CLAUDE_FILE_PATHS\""
      }]
    }]
  }
}

Part 11: Performance Optimization and Monitoring

Advanced techniques for optimizing Claude Code performance and monitoring usage.

Context Management

# Regularly clear context to maintain performance
claude "/clear"

# Use compact mode for long sessions
claude "/compact"

# Monitor token usage
claude "/usage"

Session Optimization

Effective Context Loading:

# Load only relevant context
claude "Read the authentication module and user management tests, then implement OAuth integration"

# vs loading everything at once

Strategic File References:

# Reference specific files rather than entire directories
claude "Look at src/auth/login.ts and tests/auth.test.ts, then fix the failing test"

Performance Monitoring Tools

Usage Tracking:

# Install community usage monitor
npm install -g claude-code-usage-monitor

# Track token consumption
claude-usage-monitor --session-aware --burn-rate-alerts

Custom Monitoring Hooks:

{
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "python ~/.claude/hooks/track-usage.py"
      }]
    }]
  }
}

Part 12: Third-Party Tools and Extensions

The Claude Code ecosystem includes powerful third-party tools that extend functionality.

Essential Community Tools

ClaudeKit - Advanced CLI Toolkit:

npm install -g claudekit

# 20+ specialized sub-agents
claudekit oracle "What's the best approach for this architecture?"
claudekit code-reviewer "Deep analysis of the payment service"
claudekit ai-sdk-expert "Optimize this Vercel AI SDK implementation"

Status Line Enhancements:

# Enhanced status line with themes and monitoring
npm install -g claude-code-statusline

# Real-time usage tracking
npm install -g claude-powerline

Container Development:

# Dagger for safe multi-agent development
docker run -it dagger/claude-code-container

Workflow Orchestration

Claude Squad - Multi-Agent Management:

npm install -g claude-squad

# Manage multiple Claude instances
claude-squad start --agents 3 --workspaces ./project1,./project2,./project3

TSK - AI Agent Task Manager:

# Parallel development in Docker sandboxes
tsk delegate "Implement user authentication" "Add payment processing" "Create admin dashboard"

Part 13: Debugging and Troubleshooting Mastery

Advanced debugging techniques and troubleshooting workflows.

Built-in Debugging Tools

# Enhanced doctor command with context
claude "/doctor"

# Debug MCP connections
claude --mcp-debug

# Verbose logging
CLAUDE_DEBUG=1 claude

# Check configuration
claude config list

Custom Debugging Workflows

Error Analysis Automation:

# Automatic error investigation
claude "Analyze the error logs, identify the root cause, and propose a fix: $(tail -50 error.log)"

# Stack trace debugging
claude "Debug this stack trace and identify the exact line causing the issue: [paste stack trace]"

Performance Debugging:

# Profile application performance
claude "Profile the application, identify bottlenecks, and suggest optimizations: $(npm run profile)"

# Memory leak detection
claude "Analyze memory usage patterns and identify potential leaks: $(node --inspect app.js)"

Diagnostic Hooks

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "echo 'Executing: $CLAUDE_TOOL_INPUT' | logger -t claude-debug"
      }]
    }]
  }
}

Part 14: Advanced Workflow Patterns

Real-world workflow patterns that leverage multiple Claude Code features together.

The Full-Stack Feature Workflow

# 1. Create feature branch and plan
claude "Create feature branch 'user-notifications', analyze requirements from issue #234, and create implementation plan"

# 2. Implement with testing
claude "Implement the notification system with full test coverage, following our coding standards"

# 3. Security and performance review
claude "@security audit the notification system for vulnerabilities, then @performance optimize for scale"

# 4. Documentation and deployment
claude "Update API documentation, create user guide, and deploy to staging with monitoring"

The Code Quality Pipeline

# Automated quality workflow
claude "Run full test suite, fix any failing tests, update code coverage report, run security scan, optimize performance, and generate quality report"

The Emergency Hotfix Pattern

# Rapid hotfix deployment
claude "Create hotfix branch from main, implement fix for critical bug #456, run emergency test suite, create PR with expedited review requirements"

Part 15: Future-Proofing and Advanced Techniques

Cutting-edge techniques and preparations for upcoming Claude Code features.

Experimental Features

Custom MCP Servers:

// custom-mcp-server.js
import { Server } from '@modelcontextprotocol/sdk/server/index.js';

const server = new Server({
  name: "custom-development-server",
  version: "1.0.0"
});

// Add custom tools for your specific workflow
server.addTool("analyze-performance", async (args) => {
  // Custom performance analysis logic
});

Advanced Hook Patterns:

# Python hook with AI integration
import json
import sys
import openai

def analyze_code_change():
    # Get hook data
    hook_data = json.loads(sys.stdin.read())

    # Use AI to analyze the change
    analysis = openai.chat.completions.create(
        model="gpt-4",
        messages=[{
            "role": "user",
            "content": f"Analyze this code change: {hook_data['tool_input']}"
        }]
    )

    return {
        "continue": True,
        "feedback": analysis.choices[0].message.content
    }

if __name__ == "__main__":
    result = analyze_code_change()
    print(json.dumps(result))

Integration Patterns

Claude Code as a Service:

# Dockerfile for Claude Code service
FROM node:18-alpine
RUN npm install -g claude-code
COPY entrypoint.sh /
ENTRYPOINT ["/entrypoint.sh"]

API Wrapper Development:

// API wrapper for Claude Code integration
import { spawn } from 'child_process';

export class ClaudeCodeAPI {
  async executeCommand(prompt: string): Promise<string> {
    return new Promise((resolve, reject) => {
      const claude = spawn('claude', ['-p', prompt, '--output-format', 'json']);
      let output = '';

      claude.stdout.on('data', (data) => {
        output += data.toString();
      });

      claude.on('close', (code) => {
        code === 0 ? resolve(output) : reject(new Error(`Exit code: ${code}`));
      });
    });
  }
}

Conclusion: Your Claude Code Mastery Journey

This comprehensive guide covers every advanced feature, hidden trick, and power technique available in Claude Code. From the automation capabilities of hooks to the connectivity power of MCP, from custom agents to enterprise security features you now have the complete toolkit.

Quick Implementation Checklist:

Set up hooks for your most common workflows
Install essential MCP servers for your tech stack
Create custom slash commands for repetitive tasks
Configure your CLAUDE.md with project context
Implement headless automation for CI/CD
Set up custom agents for specialized tasks
Configure security and permissions appropriately
Install community tools that enhance your workflow

The developers who master these advanced Claude Code features will have a significant competitive advantage. They'll ship faster, write better code, and handle complex tasks that would take others days or weeks.

Start with the features that solve your biggest pain points, then gradually expand your Claude Code toolkit. The investment in learning these advanced capabilities will pay dividends for years to come.

What advanced Claude Code feature will you implement first? Share your experiences and discoveries in the comments the Claude Code community thrives on sharing knowledge and pushing the boundaries of what's possible with AI assisted development.

AI Coding Assistants Made Me a Lazy Developer… And That’s Okay

Leon Martin — Wed, 13 Aug 2025 15:11:05 +0000

There was a time not so long ago when I would obsess over every line of code.

Formatting. Naming. Efficiency. Pure logic flow. That nerdy satisfaction of getting a function just right.

Fast forward to now?

I open a file, type half a line, and Copilot eagerly finishes my thought like we’ve been coding together for years.

And honestly? I kinda love it.

Yeah AI coding assistants have made me lazy.

But it’s a useful kind of lazy.

I Don’t Write Boilerplate Anymore. I Don’t Miss It.

Remember writing useEffect(() => {}, []) for the thousandth time?

Or spinning up the same Express route handler with the same error checks?

Yeah, I don’t do that anymore. Copilot does.

At some point in 2023, something shifted in how I wrote software.

Instead of crafting everything from scratch, I started treating the editor like a conversation.

"Here’s what I want."

"Okay, here’s a first draft."

"Close, but tweak this, that, and remove the nonsense."

It’s less typing. Less thinking about syntax.

More about shaping an idea into reality faster.

And look, I still refactor, still test, still think about architecture.

But I no longer spend brainpower on res.status(500).json({ error })

And I don’t feel bad about it.

It's Just the Next Level of Abstraction

People act like this shift is the end of programming.

But we’ve always been abstracting things away.

No one builds apps in assembly (and if you do, respect).

We moved from writing raw SQL to using ORMs.

From manually managing DOM trees to declarative frameworks like React.

From for loops to map and filter.

So why wouldn’t we abstract typing itself?

Coding assistants aren’t cheating they’re automation.

And automation is what we do best.

The Risk: You Stop Thinking Like an Engineer

Here’s where it gets tricky though.

When Copilot nails 90% of your code, it’s easy to stop questioning it.

You trust the suggestion. You stop wondering why it works. You just move on.

That’s dangerous.

Because when something doesn’t work or worse, works but in the wrong way you better hope you actually understand what it’s doing.

I’ve reviewed AI-generated code that looked perfect but had subtle async bugs.

Or sneaky performance issues. Or logic that worked in tests but failed in production with real users.

The assistants are helpful. But they’re not architects. They don’t understand the business logic, the edge cases, or the bigger picture.

That’s still your job.

Real Engineering Still Matters

The stuff AI can’t do (yet) is exactly where we need to show up.

It can’t:

Push back on a bad product decision.
Redesign a system to support scale.
Communicate trade-offs to stakeholders.
Build trust on a team.
Diagnose a ghost bug in production logs at 2am when nothing makes sense.

These aren’t “coding” tasks. They’re engineering tasks.

And they’re the ones that make you valuable beyond what Copilot can autocomplete.

The Layoffs Made It Real

We’ve all felt the pressure lately.

Layoffs. Hiring freezes. Teams shrinking while expectations keep growing.

And in parallel, AI tools popping up everywhere promising to “10x productivity.”

It’s hard not to feel like we’re automating ourselves out of jobs.

But here’s my take: AI didn’t kill junior roles. Bad leadership and short-sighted planning did.

The assistants didn’t replace us. They just changed the expectations.

Now, you have to bring more to the table than just being a good typist.

So Yeah I’m Lazy Now

But lazy doesn’t mean careless.

Lazy means efficient. Lazy means optimizing my time for the hard parts.

The fun parts. The stuff that makes software feel good.

Let Copilot write your axios calls. Let GPT refactor that utility function.

Save your brain for the decisions that actually matter.

And when someone asks, “Aren’t you worried the AI will replace you?”

Just smile and say, “Only if I stop thinking.”

How’s Your Workflow Changed?

Are you using AI tools daily?

Have they helped you move faster, or made you feel disconnected from your own code?

Would love to hear how you’re adapting drop a comment 👇

Programming Is Becoming Prompting

Leon Martin — Fri, 01 Aug 2025 15:24:47 +0000

It’s a weird time to be a developer.

Not bad. Just weird. You open Twitter (sorry, X?), and suddenly everyone’s a “prompt engineer.” People are building Full Stack apps with three sentences and a screenshot. Job posts ask for experience with LangChain before they ask about JavaScript. And you're there like… wait, do I even need to code anymore?

Let’s talk about it.

Prompting Is the New Programming (Apparently)

Back in 2020, if someone said “prompting,” I’d assume they were talking about CLI flags or asking a user for input. Now? It means writing the perfect sentence to coax GPT into generating an entire microservice with error handling, tests, and documentation.

And let’s be real: it's kind of amazing. I’ve used prompts to scaffold codebases, generate test cases, refactor legacy nightmares, and even write bash scripts I didn’t feel like Googling. It works. And it saves time. And yeah it’s fun.

But it’s also a little... strange.

Because when you start writing prompts instead of functions, you stop flexing those problem solving muscles that got you into programming in the first place.

Are We Still Devs or Just API Wranglers?

Something changed over the last couple years and I’m not just talking about the layoffs (though we definitely felt those too). The vibe of being a dev shifted. Suddenly it’s less “crafting software” and more “assembling outputs from models and APIs.”

You write a bit of glue code. Prompt an LLM for a function. Copypaste some Stack Overflow answer into ChatGPT to "clean it up." Ship it. Move on.

Is this bad? Not necessarily. Tools evolve. Abstractions stack. No one codes in assembly anymore (unless you’re very, very cool or cursed).

But something feels different. I don’t get the same joy writing a bulletproof prompt that generates a Stripe webhook handler as I did just… writing it myself.

I miss zoning out with VS Code. I miss reading docs. I miss thinking through edge cases in my head. Now I just ask the AI to “handle edge cases” and hope it understood what I meant.

Why It’s Still Worth Learning to Code

Here’s the thing: prompting is powerful. But it’s not magic. And the moment something breaks or needs to scale or has a weird race condition, you’ll need to actually understand what’s going on under the hood.

Knowing how to code is still the superpower. The prompt is just a shortcut.

It’s like knowing how to drive vs. relying on autopilot. Sure, let the AI help you on the highway. But if you can’t parallel park manually when the system glitches, you’re toast.

I’ve seen this play out in real teams. New devs who only know how to prompt get stuck fast when debugging, testing, or building something non trivial. Senior devs are still the ones untangling those last 10% problems that the AI couldn’t predict.

So yeah. Learn to code. Learn to build. Learn why things work. Then prompt all you want.

But Also... Don't Be a Dinosaur

That said, refusing to adapt is a great way to become irrelevant.

I’ve seen devs mock prompt engineers like they’re not “real developers.” These same people once mocked front end devs too. And before that, mocked people who used Rails generators. And before that, mocked people who didn’t write in C.

See the pattern?

Prompting is programming now just a new flavor. It’s part of the toolkit. Ignoring it means ignoring a really powerful abstraction layer that can make you more efficient, creative, and productive.

The key isn’t to pick one side. The key is to know when to use the AI and when to be the AI.

So What’s Lost?

Creativity, maybe.

When we let the AI write our code, our job becomes editing instead of inventing. Curating instead of crafting. It’s like going from painting to photo editing. Still art, still skill, but… something's different.

We risk losing the joy of building from scratch. The tiny design decisions that add up to big differences. The unique fingerprints you leave in your code. When everything starts to look like GPT output, all apps start to feel the same.

And hey, maybe that’s fine for CRUD stuff. But the best software, the stuff that feels different, usually comes from human weirdness, not robotic predictability.

Closing Real Talk

Prompting is here and programming will never go back to what it was. That line between programmer and “AI wrangler” is officially blurred. If all you do is prompt, you’ll miss the soul of building.

So, keep learning to code don’t just learn to prompt. Use AI, but don’t let it erase your curiosity. Ask why, not just how. And remember, even as the world shifts, real creativity comes from the mind behind the prompt not just the box it’s typed into.

Feeling the same about the prompt shift? Is your code half AI generated these days? I’d love to hear how you’re keeping the spark alive in a world of endless autocomplete.

What do you think?

In the Programming World, There Are SIMPs Too

Leon Martin — Mon, 12 May 2025 17:13:43 +0000

Let’s talk about something nobody puts on the shiny LinkedIn posts: there are SIMPs in tech too.

And no, I’m not talking about romantic simping. I’m talking about people who worship tools, companies, frameworks, or tech celebrities like they’re gods — and lose all critical thinking along the way.

Yeah. That kind of SIMPing.

The Cult of Tools

You’ve probably seen it.

Some new framework drops. Some company open-sources a tool. Some CEO posts a half-baked thread on X about “changing the world with AI” and suddenly...

there’s a flock of devs blindly defending it like their paycheck depends on it (spoiler: it doesn’t).

“X framework is the future! Everything else is trash!”
“If you’re not using Y, you’re falling behind!”
“Z founder said it, so it must be true!”

Bro. Chill.

Tools are just tools. Companies are just companies. They don’t love you back.

Companies Are Not Your Friends

I don’t care how many hoodies they gave you at onboarding.

I don’t care how many times they say “we’re a family” in the All Hands.

At the end of the day, you are a line item on a spreadsheet.

And when the CFO decides it’s time to “optimize operating efficiency,” your “family” will ghost you harder than your worst Hinge match.

So when I see devs online SIMPing for tech giants like they’re on some Marvel superhero team... it’s just sad, man.

They owe you nothing. You owe them nothing.

Use their tech. Build cool stuff. Cash your checks. But don’t lose yourself in the fandom.

Framework Fanboys (and Fangirls)

Honestly, this might be even worse.

Some developers get so emotionally attached to a framework that it becomes part of their identity.

Svelte, Vue, Solid, Angular, React — pick your poison.

But here’s the thing:

Frameworks are not your personality.

They are products. Made by humans. With flaws. That will get replaced eventually.

Remember when everyone thought Backbone.js was the future?

Yeah. Pepperidge Farm remembers.

Chill with the wars. It’s okay to love a tool. It’s not okay to lose your critical thinking over it.

The Influencer Effect

There’s also a weird cult following for tech influencers these days.

Some random dude posts a spicy hot take like “You don’t need to learn algorithms to be a good dev" or "AI will replace all junior developers" and suddenly, everyone’s in the comments like:

"OMG based!"
"Finally someone said it!"
"This is the truth no one wants you to know!"

Look, some of these people have good points.

But they’re not prophets. They’re not building altars to absolute truth.

They’re optimizing for engagement, not accuracy.

Use your brain. Agree where it makes sense. Disagree when you should. Don’t SIMP.

Chase Mastery, Not Approval

At the end of the day, the only thing that matters is:

Are you getting better? Are you solving real problems? Are you building things that actually help people?

Nobody is giving out medals for being the biggest Next.js fanboy.

Nobody is promoting you because you can quote tech influencers in Slack debates.

You grow by thinking critically, experimenting, building, failing, and learning — not by joining fandoms.

TECH is Full of SIMPs

The tech world is full of SIMPing. It’s just disguised better.

SIMPing for companies.
SIMPing for frameworks.
SIMPing for tech influencers.

And it’s all a distraction.

Focus on your skills. Focus on your impact. Focus on your growth.

That’s the real flex.

Have you seen tech SIMPing firsthand? (Or maybe — painfully — caught yourself doing it too?)

Let’s swap war stories in the comments. 👇

Watching Tutorials Doesn’t Make You an Expert

Leon Martin — Tue, 29 Apr 2025 17:04:28 +0000

Let’s get one thing out of the way: watching programming tutorials feels productive.

You fire up a two-hour crash course, follow along, copy the code, maybe even understand most of it... and when it ends, you feel good. Like you made real progress.

But here’s the uncomfortable truth:

Watching tutorials doesn’t make you an expert. It barely even makes you competent.

Tutorial Watching ≠ Real Coding

Following along with a tutorial is like painting by numbers.

The colors are picked for you. The lines are drawn.

You’re just filling in the blanks.

Real coding?

You’re staring at a blank canvas, trying to figure out what the hell to even draw.

No instructions. No handholding. Just you, a vague idea, and a stubborn compiler screaming at you.

Until you can build something without a step-by-step guide, you're not really coding — you're just mimicking.

Tutorial Hell Is Real (And Dangerous)

If you’re not careful, you get stuck in an endless loop:

Watch a tutorial.
Feel a small hit of dopamine.
Start another tutorial.
Repeat.

You never actually build anything on your own. You never struggle. You never fail, and more importantly, you never fix your own failures.

And if you don't struggle and fix things yourself?

You're not learning how to solve problems — you're learning how to follow orders.

And guess what? Real jobs don’t give you tutorials.

They throw messy, broken requirements at you and expect you to figure it out.

Knowing "What" Isn’t the Same as Knowing "Why"

Tutorials are great at showing you what to do:

"Here's how you create a REST API."
"Here's how you make a React component."
"Here’s how you connect to a database."

But they almost never dive deep into why you’re doing it that way.

Why REST and not GraphQL?
Why use Context instead of Redux?
Why normalize your database schema instead of denormalizing?

If you can’t answer the “why” questions, you’re not ready for the real world yet.

Real Skills Come From Real Struggles

You level up by building ugly, broken, chaotic things and then painfully fixing them.

You forget a semicolon and spend an hour debugging.
You deploy a project and realize you didn't set CORS properly.
You crash a server because you didn't handle async properly.

These moments hurt. They make you question your life choices.

But each one teaches you ten times more than any polished YouTube tutorial ever could.

When Tutorials Actually Help

Look — I'm not saying tutorials are worthless. They can be amazing when used right:

✅ As a starting point when you’re tackling a brand-new topic.

✅ To quickly understand how a tool/framework basically works.

✅ As references for patterns and best practices once you’ve tried things yourself.

But if all you're doing is watching tutorials — you're just consuming. Not creating.

And in this industry?

Creators > Consumers. Every. Single. Time.

How to Escape Tutorial Hell

Here’s the real “secret roadmap” to becoming good:

Build something small without help.

Even if it sucks. Especially if it sucks.
Google your problems.

Spend hours on Stack Overflow. Read boring documentation.
Break stuff.

Deliberately. See how it fails. Learn why.
Refactor your messy code later.

First, just make it work. Then make it better.
Teach others.

Write a blog post. Explain it to a rubber duck. Teaching forces real understanding.

That’s it. No magic.

If tutorials alone made you an expert...

We'd all be senior engineers after a weekend binge.

They don't.

Building, failing, fixing, and repeating — that's where the real growth happens.

Next time you finish a tutorial, don’t queue up another one.

Instead, close YouTube. Open your editor. Build something messy.

That’s the only real way forward.

What was the last project you built without a tutorial?

Or are you still stuck in tutorial hell?

Drop your thoughts below — no judgment, we've all been there. 👇

Why Stop Using TypeScript for Small Projects?

Leon Martin — Sat, 22 Mar 2025 02:17:24 +0000

I used to be that developer who pushed TypeScript into every single project. Backend? TypeScript. Frontend? TypeScript. A five-minute script to automate file renaming? Yep, even that. It felt like the right move—after all, static typing makes everything better, right?

Well, not always.

After years of forcing TypeScript into every project, I’ve finally admitted something: for small projects, TypeScript is more of a hassle than a help. If I’m spinning up a quick MVP, personal project, or a simple API, I no longer reach for TypeScript by default. Here’s why.

1. The Setup Overhead Isn’t Worth It

Let’s be real—TypeScript requires setup.

Configuring tsconfig.json
Making sure dependencies work with TypeScript
Installing and configuring type definitions (@types/whatever)
Adjusting the build process

Yes, I know that modern frameworks like Vite, Next.js, or Nuxt make setup easier with zero-config templates. But when you’re starting from scratch or not using a full framework, that configuration still exists—and for quick hacks or scripts, it's friction I’d rather avoid.

For a large-scale project, this setup pays off. But for something small—like a quick API or a weekend side project—why am I spending 20 minutes wrestling with configs instead of actually writing code?

A simple JavaScript file just works:

// index.js
console.log("Hello, world!");

With TypeScript, even something this basic comes with extra ceremony:

const message: string = "Hello, world!";
console.log(message);

Let’s get this out of the way: no, you don’t need to explicitly annotate string here—TypeScript would infer the type just fine.

This example became a bit symbolic for me. It represents how even the simplest scripts start to feel more formal and verbose when TypeScript is involved. In a quick project where I just want to print a message or hit an API, that extra layer often feels like friction instead of help.

And that’s before setting up the build process.

2. TypeScript Slows Down Experimentation

One of JavaScript’s biggest strengths is its flexibility. Want to throw together a proof-of-concept? No problem. With TypeScript, that agility disappears.

Say I’m trying out a new API. In JavaScript, I’d just fetch some data and move on:

fetch("https://api.example.com/data")
  .then(res => res.json())
  .then(data => console.log(data))
  .catch(err => console.error(err));

In TypeScript? Now I need to define types:

interface ApiResponse {
  id: number;
  name: string;
  email: string;
}

fetch("https://api.example.com/data")
  .then(res => res.json())
  .then((data: ApiResponse) => console.log(data))
  .catch(err => console.error(err));

Of course, TypeScript lets you use any or gradually introduce types. But that kind of defeats the purpose of using TS in the first place, right? My point is—when I’m in experiment mode, I don’t want to think about types at all. I want fast feedback and no friction.

Sure, it’s safer—but if I’m just playing around, why am I writing extra code before I even know if this API is useful?

3. TypeScript’s Benefits Aren’t That Useful in Small Projects

I get it—TypeScript helps prevent bugs. But in a small project, does it really matter?

Most of the time, the “bugs” TypeScript prevents in small projects are things I’d catch instantly anyway.

Bad example:

const age = "30";  
console.log(age * 2); // NaN

Okay, TypeScript would catch that. But is this the kind of bug that’s keeping me up at night? No. If my entire app is 500 lines of code, I don’t need a compiler to protect me—I can just read the code.

4. The Extra Build Step Feels Unnecessary

With JavaScript, I can run my script instantly:

node script.js

With TypeScript, I have to compile it first:

tsc script.ts && node script.js

For a massive project? No problem. But if I’m writing a quick utility script, this extra step kills momentum.

And yes, I know you can use ts-node to avoid manual compilation, but it still introduces unnecessary complexity.

5. Not Every Dependency Plays Nice with TypeScript

Ever installed a third-party package and immediately run into TypeScript errors?

Property 'xyz' does not exist on type 'SomeModule'.

Then you check the package’s GitHub repo and see no TypeScript support. Now you have three options:

Find a DefinitelyTyped package (@types/xyz) (if it exists).
Write your own type definitions (ugh).
Use any and pretend TypeScript isn’t there.

If I’m working on a big project, I’ll take the time to figure this out. But for a small app, it’s just another headache.

When I Still Use TypeScript

I’m not saying TypeScript is bad—I still use it for the right projects.

✅ Large-scale apps (especially with multiple developers).

✅ Projects with long-term maintenance in mind.

✅ Codebases that rely heavily on strict contracts between modules.

But for:

❌ Side projects

❌ Quick scripts

❌ MVPs and prototypes

I stick with JavaScript. It’s just faster, simpler, and more fun when you don’t have to fight the compiler.

TypeScript is a Tool, Not a Religion

Some developers treat TypeScript like the only way to write JavaScript in 2025. But that’s not true. TypeScript is great when used where it makes sense—but forcing it into every project? That’s just unnecessary friction.

If you love TypeScript, great—use it where it benefits you. But if you’re working on something small, and TypeScript feels like more trouble than it’s worth… maybe it is.

What’s your take? Do you still use TypeScript for everything, or have you started picking your battles? Let’s chat in the comments!

Why the Latest JavaScript Frameworks Are a Waste of Time

Leon Martin — Fri, 14 Mar 2025 00:21:09 +0000

If you’ve been in web development for more than five minutes, you know the drill. Every few months, a new JavaScript framework pops up, promising to fix everything wrong with the previous generation.

At first, it’s exciting. A cleaner syntax, better performance, fewer headaches! But after years of jumping from React to Vue to Svelte to Solid (and back again), I’ve come to a realization constantly chasing the latest JavaScript framework is a waste of time.

Don’t get me wrong—innovation is great. But at some point, you have to ask yourself Am I actually building things, or am I just constantly relearning how to build the same thing in a slightly different way?

The JavaScript Hype Cycle Never Stops

Let’s be honest, JavaScript developers are obsessed with the new and shiny. Every year, there’s a new framework, a new bundler, a new meta-framework, a new way to manage state. The cycle goes something like this:

Someone announces a "game-changing" framework. It’s smaller, faster, better than everything before it.
Devs flock to it. Blogs, YouTube tutorials, conference talks—everyone hypes it up.
Companies hesitate. Adoption is slow because they have production apps that actually need to run.
The initial excitement dies down. The framework matures, gains complexity, and starts resembling what it originally tried to replace.
Rinse and repeat with the next hot framework.

Remember when Vue was supposed to replace React? When Svelte was going to kill them both? Now we’re talking about Solid and Qwik in the same way. Meanwhile, React and Angular are still here, and jQuery (yes, jQuery) still powers a ridiculous number of websites.

At some point, I had to ask myself << What am I actually gaining by switching frameworks every year? >>

Rewriting Everything Is Not Productive

I love trying new tech. I get excited about performance gains, better DX, and cleaner syntax. But there’s a cost to switching frameworks, it slows you down.

Every time I jumped on a new framework, I had to:

Learn a new component syntax.
Figure out state management (again).
Read new documentation and fix weird edge cases.
Convince my team (or myself) that this was actually worth it.

And for what? To build the same UI components, handle the same API calls, and manage the same state as before?

At some point, I realized I was spending more time learning frameworks than actually building things.

"Best Framework" Is a Myth

Developers love arguing about which framework is best. But here’s the truth, there is no best framework—only trade-offs.

React gives you a massive ecosystem but forces you to deal with complex rendering patterns.
Vue is intuitive but gets opinionated with Vuex, Pinia, and its build tools.
Svelte eliminates boilerplate but locks you into its compiler-based approach.
Solid gives you React-like ergonomics with better performance but lacks ecosystem maturity.
Angular is a powerhouse but comes with a steep learning curve.

Every framework has strengths and weaknesses. The moment you switch, you just trade one set of problems for another.

The Job Market Is Still Dominated by React and Angular

Here’s a reality check Companies don’t care about the latest JS framework.

If you’re job-hunting, React and Angular are still the dominant forces. Vue has a respectable share. The rest? Niche.

A startup might experiment with Svelte or Solid, but most production applications don’t switch tech stacks just because something new is trending on Twitter.

At the end of the day, companies need stable, maintainable codebases. They’re not rebuilding everything in Qwik just because it sounds cool.

Frameworks Won’t Make You a Better Developer

At one point, I convinced myself that mastering every new JS framework would make me a better developer. But the truth is, jumping between frameworks teaches you very little beyond syntax differences.

What actually makes you a better developer?

Understanding core JavaScript deeply (async, closures, event loops, prototypes).
Learning system design (how to build scalable applications).
Writing maintainable code (clean architecture, testing, documentation).
Thinking beyond the frontend (APIs, databases, cloud deployment).

A good developer isn’t the one who can rewrite a todo app in 10 frameworks. It’s the one who knows how to design software that works, scales, and is easy to maintain—regardless of framework.

What I’m Doing Instead

I’m not saying I’ll never try a new framework again. But I’ve changed my approach:

✅ Stick to frameworks that are widely adopted (React, Vue, Angular).

✅ Only switch when there’s a real reason (not just because Twitter says so).

✅ Focus on core programming skills, not just syntax differences.

✅ Build more, chase less.

The next time a new JS framework drops, I won’t be rushing to rewrite my projects. Instead, I’ll be focused on shipping products, writing solid code, and improving my problem-solving skills.

Final Thoughts

Frameworks come and go. The skills that matter—problem-solving, architecture, and clean code—stick with you for life.

If you’re always jumping from one JS framework to the next, ask yourself << Are you actually getting better, or just running in circles? >>

Let’s talk—are you still chasing frameworks, or have you stepped off the hype train too? Drop a comment below!

How Serverless is Killing the Traditional Backend Role 🔥

Leon Martin — Thu, 30 Jan 2025 21:22:26 +0000

There was a time when backend engineers were the backbone of software development. They built APIs, managed databases, optimized server performance, and designed architectures that could handle millions of users.

But if you’ve been paying attention to how tech has evolved in the past few years, you might have noticed something: serverless is eating the backend world.

And honestly? Traditional backend roles might not survive it.

I’ve seen companies gut their backend teams because they realized they don’t need a dedicated backend engineer for everything anymore. I’ve seen startups launch massive products with just a frontend team and a couple of DevOps folks managing cloud functions.

So what’s happening? Why are backend roles disappearing? And if you’re a backend engineer, what the hell should you do about it? Let’s talk.

How We Got Here: The Rise of Serverless

A few years ago, building a scalable backend meant managing servers. Whether it was on-premises or cloud-based, backend engineers had to worry about:

Provisioning and maintaining servers
Scaling infrastructure as demand increased
Optimizing performance and handling security
Managing databases, caching, and networking

Then serverless happened. AWS Lambda, Google Cloud Functions, Azure Functions—these platforms abstracted away servers entirely. Suddenly, you could write a function, deploy it, and let the cloud provider handle everything else.

And companies loved it.

Why?

No need to manage infrastructure
Auto-scaling built-in
Lower costs (you only pay for execution time)
Faster time to market

Instead of hiring a team of backend engineers, companies realized they could just plug into a serverless architecture and call it a day.

What’s Disappearing?

With serverless, a lot of traditional backend responsibilities are slowly fading away.

1. Server Management is Gone

No more provisioning EC2 instances, no more tuning nginx configs, no more babysitting Kubernetes clusters (unless you really, really need to).

Serverless platforms abstract all of this. AWS Lambda, Google Cloud Run, and Azure Functions scale automatically based on traffic. The backend engineer who used to monitor and optimize servers? No longer needed.

2. API Development is Changing

Instead of spinning up an Express.js or Django backend, many companies are opting for API Gateway + Lambda functions.

What used to be a monolithic backend team managing an API is now:

A frontend dev defining API routes in API Gateway.
A few cloud functions handling business logic.
A managed database like DynamoDB or Firebase Firestore doing the heavy lifting.

No dedicated backend engineer required.

3. Databases are Becoming “Serverless” Too

Managing and optimizing databases used to be a backend engineer’s job. But now? Managed databases like Firebase Firestore, AWS Aurora Serverless, and PlanetScale handle scaling, indexing, and even query optimization automatically.

Backend engineers who spent time tuning SQL queries and designing efficient data schemas? Companies are realizing they don’t need as many of them anymore.

4. Authentication and User Management? Outsourced.

Rolling your own authentication system was a core backend responsibility. But now?

Auth0, Firebase Authentication, and AWS Cognito handle user auth seamlessly.
Stripe, Plaid, and third-party payment services handle transactions without backend teams needing to implement complex payment flows.

The backend engineer’s role in security, auth, and payments is shrinking fast.

The “New Backend” Looks Different

So does this mean backend engineers are completely dead? Not quite. But the role is changing dramatically.

Instead of managing servers, APIs, and databases from scratch, backend engineers in 2025 need to:

Understand cloud-native architectures (AWS, GCP, Azure)
Write efficient cloud functions instead of monolithic backends
Design event-driven systems (Pub/Sub, AWS EventBridge, Kafka)
Integrate third-party services instead of reinventing the wheel

Basically, the backend engineer of the future is part cloud architect, part API integrator, and part problem solver.

The Winners and Losers in a Serverless World

Not everyone benefits from this shift. Some developers will thrive in a serverless ecosystem, while others might find themselves struggling to stay relevant.

Winners: Who Benefits from Serverless?

✅ Frontend Engineers: Frontend teams can now handle more backend tasks using serverless functions and APIs.

✅ DevOps & Cloud Engineers: Since infrastructure is more cloud-driven, DevOps engineers are taking over a lot of backend responsibilities.

✅ Companies & Startups: They can ship faster, scale easier, and spend less on backend engineering teams.

Losers: Who’s in Trouble?

❌ Traditional Backend Engineers Who Refuse to Adapt: If your expertise is just managing servers or writing monolithic backends, your job market is shrinking.

❌ Developers Who Ignore Cloud & DevOps: Backend without cloud knowledge? That’s a risky bet in 2025.

Should You Still Become a Backend Developer?

Short answer: Yes, but don’t be the kind of backend developer that’s getting replaced.

The industry still needs backend expertise—but the skills required are shifting. If you want to stay relevant, focus on:

Cloud computing (AWS, GCP, Azure)
Serverless architectures (Lambda, API Gateway, Firebase, etc.)
Infrastructure-as-Code (Terraform, Pulumi)
Event-driven architectures (Kafka, SQS, Pub/Sub)
Building scalable, maintainable APIs (GraphQL, gRPC, REST best practices)

In other words, you need to become a backend engineer that understands serverless, not one that fights against it.

Adapt or Get Left Behind 🔥

Serverless isn’t a trend—it’s the future of backend development. The days of traditional backend engineers managing servers, databases, and monolithic APIs are fading.

If you’re a backend developer, you have two choices:

Adapt to the new reality—learn cloud, serverless, and modern backend architecture.
Ignore the shift and risk becoming obsolete as companies continue downsizing backend teams.

The role of the backend engineer isn’t dead—it’s evolving. The question is, are you evolving with it?

What’s you think? Let’s discuse in the comments.