Do Side Projects Still Matter with AI Coding Assistants?

Mar 21, 2026

I spent last weekend vibe-coding a side project. Claude wrote 2,000 lines in three hours. It deployed without errors. And I felt… nothing.

The app worked. The code was clean. But something felt wrong. Did I actually build anything? Did I learn anything? Would anyone care about this project when AI can generate the same thing in an afternoon?

This question haunted me for days. So I dug into what developers on Reddit, Twitter, and real-world teams actually think about side projects in the AI era.

The Uncomfortable Truth About AI-Generated Projects

Here’s what happened when I showed my vibe-coded app to a senior engineer friend:

HIM: "Cool app. What problem does it solve?"
ME: "Uh... it tracks habits?"
HIM: "Is that a problem YOU have?"
ME: "Not really. I just thought it was cool to build."
HIM: "Then why build it?"

Ouch. But he was right. I had built something technically impressive but personally meaningless. AI amplified my ability to generate code, but it couldn’t give me a reason to care.

The Value Shift: From Syntax to Judgment

The Reddit discussion on this topic hit on something crucial. A comment with 84 upvotes stated:

“Projects matter more than ever, but the VALUE has shifted. Before AI, value was in writing code. Now value is in deciding what to build, understanding problems deeply, knowing when Claude gives you good enough vs hiding bugs.”

Let me show you what this means in practice.

Before AI: The Code Was the Achievement

[2019 Me]
  |
  +--> Learn syntax (months)
  +--> Debug for hours
  +--> Finally get it working
  +--> Put on portfolio
  |
  [Value: I know syntax]

After AI: Judgment Is the Achievement

[2026 Me]
  |
  +--> Identify real problem I care about
  +--> Use AI to prototype quickly
  +--> REVIEW output for bugs, security, edge cases
  +--> Iterate based on real usage
  +--> Explain WHY I built it this way
  |
  [Value: I understand systems + make good decisions]

The key insight: AI handles the “what” and “how” of coding, but you’re still responsible for the “why” and “whether it’s actually good.”

A Real Example: When AI Output Hides Bugs

I recently used Claude to build a file upload feature. It generated this:

from flask import request
import os

@app.route('/upload', methods=['POST'])
def upload_file():
    file = request.files['file']
    filename = file.filename
    file.save(os.path.join('uploads', filename))
    return 'File uploaded successfully'

Looks fine, right? That’s what I thought. Until I tried:

Uploading ../../../etc/passwd - path traversal vulnerability
Uploading a 10GB file - no size limit, memory exhausted
Uploading malicious.exe - no file type validation

AI gave me working code in seconds. But I needed real knowledge to catch three critical security issues that would have compromised the entire system.

from flask import request
from werkzeug.utils import secure_filename
import os

ALLOWED_EXTENSIONS = {'txt', 'pdf', 'png', 'jpg', 'jpeg', 'gif'}
MAX_FILE_SIZE = 16 * 1024 * 1024  # 16MB

def allowed_file(filename):
    return '.' in filename and \
           filename.rsplit('.', 1)[1].lower() in ALLOWED_EXTENSIONS

@app.route('/upload', methods=['POST'])
def upload_file():
    if 'file' not in request.files:
        return 'No file provided', 400

    file = request.files['file']

    if file.filename == '':
        return 'No file selected', 400

    if not allowed_file(file.filename):
        return 'File type not allowed', 400

    # Check file size (read first, then validate)
    file.seek(0, os.SEEK_END)
    size = file.tell()
    file.seek(0)

    if size > MAX_FILE_SIZE:
        return 'File too large (max 16MB)', 400

    filename = secure_filename(file.filename)
    file.save(os.path.join('uploads', filename))
    return 'File uploaded successfully'

The second version required understanding why each security measure mattered. AI couldn’t anticipate my specific deployment environment, user threat model, or business requirements.

What Hiring Managers Actually Look For

I asked three engineering managers what they think when they see AI-generated side projects. Their responses were consistent:

MANAGER 1: "I don't care that you built a to-do app in 2 hours with AI.
           I care that you can explain the trade-offs you made."

MANAGER 2: "Everyone has a portfolio now. What makes yours different is
           depth. Did you deploy it? Monitor it? Handle real users?"

MANAGER 3: "I want to see projects that solve problems the candidate
           actually has. Generic apps tell me nothing about them."

The pattern is clear: Depth and personal connection matter more than technical flash.

The New Side Project Framework

After reflecting on all this, I’ve changed how I approach side projects:

Phase 1: Problem Selection (No AI Allowed)

Questions to ask yourself:

1. Does this problem annoy me personally? (Yes = proceed)
2. Would I use this solution even if no one ever saw it? (Yes = proceed)
3. Can I explain WHY existing solutions don't work for me? (Yes = proceed)

If any answer is "no", stop. AI can't give you a problem worth solving.

Phase 2: AI-Assisted Building (With Review)

Use AI for:

Boilerplate setup
Common patterns (auth, CRUD, API endpoints)
Generating tests (then review them)
Documentation drafts

But review everything. Add comments explaining why you made each choice.

Phase 3: The “Last 10%” (Human Work)

This is where real learning happens:

[The Last 10% AI Can't Do]
  |
  +--> Edge cases from real user feedback
  +--> Performance issues at scale
  +--> Integration problems with external services
  +--> Weird bugs that only happen in production
  +--> Accessibility issues
  +--> Mobile responsiveness edge cases
  |
  [This is where you become valuable]

When you write about your project:

Start with the problem, not the solution
Explain what AI helped with vs. what you did manually
Share the bugs you caught and how you found them
Discuss what you learned about the domain, not just the code

Why This Matters for Different Career Stages

For Juniors

Side projects show you can ship end-to-end. But focus on:

BAD: "I built a Twitter clone in a weekend with Claude"
GOOD: "I built a Twitter clone, hit rate limits at 100 users,
      switched to a queue-based architecture, and learned why
      message queues matter for scaling"

For Seniors

Projects demonstrate architectural thinking:

BAD: "Here's my polished side project"
GOOD: "I noticed no tool existed for [specific problem], so I built one.
      Here's the architecture diagram, here's why I chose PostgreSQL over
      MongoDB, and here's how I'd scale it to 10x users"

For Career Changers

Projects prove practical skills:

BAD: Generic portfolio of tutorial apps
GOOD: One deep project related to your previous domain expertise
      (e.g., former teacher builds ed-tech, former accountant builds
      financial tools)

Common Mistakes I Made (So You Don’t Have To)

Mistake 1: Building “Cool” Things Without Personal Connection

What I did: Built a cryptocurrency tracker
Why it failed: I don't own crypto, don't care about it
What I learned: AI can generate any app; my insight is the problem

What I do now: Only build things I personally need

Mistake 2: Treating AI Output as Production-Ready

What I did: Deployed Claude's code directly
What happened: Security vulnerabilities, no error handling, hardcoded values

What I do now: Every AI-generated line gets reviewed, tested, and documented

Mistake 3: Skipping the “Boring” Parts

What I did: Focused on features, ignored tests and docs
Why it mattered: When I came back later, I had no idea how it worked

What I do now:
- Write tests for critical paths
- Document architectural decisions
- Add comments for "why" not "what"

Mistake 4: Building for the Portfolio

What I did: Chose projects that looked impressive
What happened: Shallow understanding, couldn't answer deep questions

What I do now: Build projects I'll actually use. Depth > breadth.

The Practical Test

Here’s how I now evaluate whether a side project is worth building:

[PRE-BUILD CHECKLIST]

Problem Understanding:
[ ] Can I explain this problem in one sentence?
[ ] Do I have personal experience with this problem?
[ ] Can I list 3 reasons existing solutions don't work for me?

Learning Goals:
[ ] What will I learn that AI can't teach me?
[ ] What domain knowledge will I gain?
[ ] What "last 10%" skills will this develop?

Commitment:
[ ] Will I use this for at least 6 months?
[ ] Will I maintain it when bugs appear?
[ ] Would I still build this if no one ever saw it?

If I can't check all boxes, I don't build it.

What Changed for Me

I went from building generic portfolio pieces to working on things I genuinely care about:

[BEFORE]
- Habit tracker (don't need it)
- To-do app (don't need it)
- Weather app (don't need it)
Result: Felt empty, learned little

[AFTER]
- Personal finance tool (solves my actual pain point)
- Recipe organizer for my specific dietary restrictions
- CLI tool for my specific workflow at work
Result: Deep learning, genuine interest, real users (even if just me)

The difference is night and day. I actually want to work on these projects. I catch edge cases because I use them daily. I understand the domain deeply because I live in it.

The Bottom Line

Side projects matter more than ever. But the value has shifted:

OLD VALUE: I can write syntax
NEW VALUE: I can identify problems worth solving

OLD VALUE: I can generate code
NEW VALUE: I can evaluate code quality

OLD VALUE: I can build features
NEW VALUE: I can understand systems

OLD VALUE: I have a portfolio
NEW VALUE: I have judgment and depth

AI is a force multiplier for people who know what to build. It’s a crutch for people who don’t.

The question isn’t “Should I build side projects with AI?” The question is “What problems do I understand deeply enough that AI can help me solve them?”

Build what you need. Use AI to build faster. But never stop asking why you’re building it.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!