DEV Community: Soumyajit Mukherjee

AI Is Your Junior Developer. Here's Why You Still Need to Review Its Work

Soumyajit Mukherjee — Wed, 28 Oct 2026 04:07:14 +0000

AI coding assistants have made development faster. They can generate components, explain errors, suggest tests, and help developers explore unfamiliar technologies.

But here's the catch: AI can generate code faster than you can confidently verify it.

And that's where the real engineering challenge begins.

Common AI bottlenecks developers should understand

1. Hallucinated APIs and incorrect code

AI may suggest methods that don't exist, outdated syntax, or code that passes a quick glance but fails at runtime.

What to do: Check official documentation, run the code, and write meaningful tests.

2. Missing project context

AI might generate a technically valid solution that doesn't match your architecture, coding conventions, or actual requirements.

What to do: Share relevant context, define constraints, and specify acceptance criteria.

3. Security and performance issues

Generated code can introduce insecure input handling, exposed secrets, inefficient queries, or unnecessary dependencies.

What to do: Review security boundaries, validate inputs, profile performance, and use appropriate security checks.

4. Debugging generated complexity

Asking AI to fix its own mistakes repeatedly can create layers of patches instead of solving the root cause.

What to do: Reproduce the bug, isolate the failure, inspect assumptions, and understand the fix before accepting it.

5. Overdependence

If developers accept generated code without understanding it, they risk losing the ability to debug, maintain, and explain their own systems.

What to do: Treat AI-generated code as an opportunity to learn, not a substitute for learning.

Where AI boosts developer productivity

AI is genuinely useful for:

Generating boilerplate and scaffolding.
Creating initial unit tests and edge-case suggestions.
Explaining unfamiliar code and error messages.
Drafting documentation and refactoring proposals.
Exploring implementation alternatives.
Automating repetitive development tasks.

The goal isn't to write every line manually. It's to spend less time on repetitive work while preserving engineering quality.

The human-in-the-loop development workflow

Here's a simple workflow for working with your AI junior:

Plan: Define the requirements and expected behavior.
Delegate: Give AI a specific, bounded task.
Inspect: Review the generated code and its assumptions.
Test: Run tests, check edge cases, and validate integration.
Secure: Inspect permissions, inputs, secrets, and dependencies.
Understand: Make sure you can explain and maintain the solution.
Ship responsibly: Keep appropriate human approval for consequential changes.

Not every suggestion needs the same level of review. A variable rename isn't equivalent to an authentication change or a production database migration.

What developers need to strengthen

Problem-solving and debugging
Data structures and algorithms
System design
Database fundamentals
Security and performance
Testing and code review
Communication and technical decision-making

These skills make AI more useful because they help you recognize good output, catch bad output, and provide better instructions.

Final thought

Your AI assistant can be your fastest junior developer. But speed alone doesn't make a reliable engineer.

Let AI generate. Let tests challenge. Let human judgment decide.

How do you use AI in your development workflow? What's one mistake you've caught in AI-generated code?

Stop Building Full-Stack Projects Just for Your Resume in 2026

Soumyajit Mukherjee — Fri, 23 Oct 2026 12:37:35 +0000

If you're a fresher, a self-taught developer, or someone with 0–1 years of experience, you've probably heard this advice:

"Build projects to strengthen your resume."

It's good advice. But I think we need to take it one step further.

Build projects that solve problems people actually have.

A to-do app or a CRUD application is a perfectly reasonable learning exercise. The problem arises when we build dozens of tutorial-based projects without learning how to turn an idea into dependable software.

What's changing in full-stack development?

AI-assisted coding, automation, and increasingly capable web applications are changing how software gets built.

However, shipping code quickly isn't the same as shipping a reliable product. Developers still need to understand requirements, debug failures, design APIs, protect data, test behavior, and maintain applications.

Useful references:

7 full-stack projects worth exploring

1. AI-powered document search

Let users upload documents and ask questions about their contents.

Engineering challenges: document processing, retrieval, source citations, access control, privacy, and model cost management.

2. Small-business workflow automation

Build an appointment, invoicing, and customer-management system for one specific business type.

Engineering challenges: scheduling conflicts, permissions, validation, reminders, and reporting.

3. Developer deployment monitor

Track application health, errors, deployments, and incidents in one dashboard.

Engineering challenges: health checks, event ingestion, alerts, failure recovery, and observability.

4. URL safety analyzer

Analyze suspicious links using safe parsing, domain signals, threat intelligence, and optional ML integrations.

Engineering challenges: malicious input handling, rate limiting, caching, explainable risk indicators, and uncertainty.

5. Accessibility auditing tool

Help website owners discover common accessibility issues and learn how to fix them.

Engineering challenges: automated checks, severity classification, actionable reports, and testable recommendations.

6. Privacy-first expense tracker

Help users manage expenses, subscriptions, budgets, and recurring payments.

Engineering challenges: reliable calculations, private data handling, CSV imports, reporting, and data export.

7. Learning roadmap platform

Help learners convert a career goal into skill milestones, practical projects, and a trackable learning plan.

Engineering challenges: progress modeling, resource organization, personalized recommendations, and measurable outcomes.

What makes these projects stand out?

The stack alone doesn't make a project impressive.

A serious project should demonstrate:

Problem discovery: Who has the problem, and why does it matter?
Architecture: Why did you choose this database, API design, and technology stack?
Security: Are authentication, authorization, validation, and data protection handled properly?
Reliability: What happens when requests fail, services become unavailable, or users provide unexpected inputs?
Testing: Do automated tests cover important behaviors?
Deployment: Can someone access and try the working application?
Feedback: Did real users try it, and what did you improve?

You don't need Kubernetes, microservices, or AI agents in every project. Use complexity only when the problem justifies it.

A practical challenge for freshers

Try this four-week approach:

Week 1: Identify a problem and talk to potential users.

Week 2: Build the core workflow from frontend to database.

Week 3: Add validation, security, testing, and deployment.

Week 4: Gather feedback, fix problems, and document the engineering decisions.

Adapt the schedule to your availability. A smaller, completed project is better than a massive unfinished one.

How to describe it professionally

Instead of:

Built a full-stack application using React, Node.js, Express, and MongoDB.

Explain what the product does, who it helps, what challenges you solved, and what you learned.

Include real results only when you have evidence to support them.

Your GitHub repository should include a clear README, setup instructions, screenshots, architecture notes, testing instructions, and a link to the live application when available.

Final thought

You still need a job. Your resume and interview preparation still matter.

But your projects can do more than help you qualify for interviews. They can teach you to think like an engineer, create something useful, and build confidence through real feedback.

Stop collecting projects. Start shipping solutions.

What full-stack project would you build if your first goal were to help a real user rather than impress a recruiter?

Share your idea in the comments!

What I Learned From Building Small Projects Instead of Waiting for the Perfect Idea

Soumyajit Mukherjee — Fri, 23 Oct 2026 12:13:05 +0000

One of the biggest traps in software development is believing that the next project has to be revolutionary.

It doesn't.

A small project that gets finished can teach more than a huge project that remains unfinished.

Start With a Problem

Instead of asking:

What is the most impressive application I can build?

ask:

What small problem can I solve?

Examples:

Expense tracker
URL shortener
Markdown editor
Task manager
API monitoring dashboard
Bookmark manager

The project doesn't need millions of users.

It needs enough complexity to teach you something.

Build the First Version Quickly

The first version should be intentionally boring.

For example:

Create task
Read task
Update task
Delete task

Once that works, add complexity.

Maybe:

Authentication
Search
Pagination
Caching
Testing
Deployment
Monitoring

Now the project becomes a learning environment.

Don't Copy Tutorials Forever

Tutorials are useful for learning concepts.

But eventually close the tutorial and try building something independently.

That's where the gaps in your knowledge become visible.

You might suddenly discover:

I don't understand authentication.
I don't know how deployment works.
I don't know how to structure my API.
I don't know how to handle errors.

Those gaps are valuable.

They tell you what to learn next.

Finished Beats Perfect

A finished small project gives you:

Source code
A deployment
A README
Problems you actually solved
Lessons you can explain
Something you can show others A perfect project sitting in your notes gives you none of these.

Build → Break → Fix → Repeat

A useful development loop is:

Build
  ↓
Break
  ↓
Debug
  ↓
Understand
  ↓
Improve

Every bug is an opportunity to understand the system more deeply.

Final Thoughts

You don't need the perfect project idea.

You need a project that is just difficult enough to force you to learn something new.

Build small.

Finish things.

Then make the next project harder.

Why Rate Limiting Is Essential for Public APIs

Soumyajit Mukherjee — Fri, 23 Oct 2026 11:41:37 +0000

A public API can receive requests from anyone.

That creates an obvious problem:

What stops one client from sending millions of requests?

Rate limiting.

Basic Idea

Suppose an endpoint allows:

100 requests per minute

A client that exceeds that limit might receive:

429 Too Many Requests

Why Rate Limit?

Rate limiting can help protect against:

Accidental request floods
Resource exhaustion
Credential abuse
Automated scraping
Some denial-of-service scenarios
Brute-force attempts It isn't a complete security solution, but it is an important layer.

Example

A simple policy could be:

GET /api/products
100 requests/minute

while a sensitive endpoint might use:

POST /api/login
10 requests/minute

Different endpoints often deserve different limits.

Where Should Limits Be Applied?

Possible strategies include limiting by:

IP address
User ID
API key
Session
Combination of identifiers

The appropriate strategy depends on the application.

Distributed Systems

If your application runs on multiple servers, an in-memory counter on each server can produce inconsistent results.

For example:

Server A → 50 requests
Server B → 50 requests

The user may effectively get 100 requests even though the intended limit was 50.

Shared infrastructure such as Redis is commonly used for distributed rate limiting.

Good User Experience

Rate limiting should be predictable.

API responses can communicate when clients should retry using appropriate headers and status codes.

Final Thoughts

Rate limiting isn't only a cybersecurity feature.

It is also a reliability mechanism.

A well-designed API protects itself from both malicious and accidental traffic spikes.

How CI/CD Changes the Way Developers Ship Software

Soumyajit Mukherjee — Fri, 23 Oct 2026 10:03:37 +0000

Imagine manually doing this every time you release an application:

Pull code
Install dependencies
Run tests
Build application
Copy files
Configure server
Restart application

It works.

But it's repetitive and error-prone.

CI/CD automates much of this process.

Continuous Integration

Continuous Integration means frequently integrating code changes and automatically validating them.

A pipeline might run:

git push
   ↓
Install dependencies
   ↓
Lint
   ↓
Run tests
   ↓
Build

If a test fails, the team gets immediate feedback.

Continuous Delivery

Continuous Delivery focuses on keeping software ready to deploy.

The pipeline may produce a deployment-ready artifact whenever code passes validation.

Continuous Deployment

Continuous Deployment goes further.

A successful pipeline can automatically deploy changes to production.

git push
   ↓
Tests
   ↓
Build
   ↓
Deploy
   ↓
Production

Why CI/CD Helps

It reduces manual work and creates repeatable processes.

It can also:

Catch bugs earlier
Standardize deployments
Reduce deployment mistakes
Make releases smaller
Improve developer confidence

Security Matters

Never casually expose secrets inside pipeline configuration.

Use secure secret-management mechanisms provided by your CI/CD platform.

Also consider:

Dependency scanning
Secret scanning
Permission restrictions
Build isolation
Deployment approvals

Final Thoughts

CI/CD isn't simply an automation script.

It's a way of turning software delivery into a repeatable engineering process.

Database Transactions Explained With a Simple Example

Soumyajit Mukherjee — Fri, 23 Oct 2026 09:57:21 +0000

Imagine transferring $100 from Account A to Account B.

Two operations must happen:

Subtract $100 from A
Add $100 to B

What happens if the first succeeds but the second fails?

Money disappears.

This is where database transactions become important.

What Is a Transaction?

A transaction groups multiple database operations into a logical unit.

Conceptually:

BEGIN

Subtract money from A
Add money to B

COMMIT

If something goes wrong:

ROLLBACK

The database attempts to return to the previous consistent state.

ACID

Transactions are commonly discussed using ACID:

Atomicity

All operations succeed, or none do.

Consistency

The database moves from one valid state to another.

Isolation

Concurrent transactions shouldn't incorrectly interfere with one another.

Durability

Committed changes should survive failures according to the database's guarantees.

Why Transactions Matter

Consider an e-commerce order.

You might need to:

Create order
Reserve inventory
Create payment record

If these operations are tightly coupled and one fails, the application may need transactional behavior.

Transactions Aren't Free

Transactions can introduce:

Locking
Contention
Complexity
Performance costs Therefore, they should be used intentionally.

Distributed Transactions Are Harder

When operations span multiple independent services, maintaining atomicity becomes significantly more complicated.

Architectures may instead use patterns such as:

Saga
Outbox Pattern
Event-driven workflows

Final Thoughts

Transactions protect data integrity.

Whenever multiple changes must behave like one logical operation, understanding transactions becomes essential.

Why Observability Is Different From Logging

Soumyajit Mukherjee — Fri, 23 Oct 2026 09:22:02 +0000

Many developers think observability means "add more logs."

Logging is important.

But observability is broader.

The Three Common Pillars

Observability is commonly discussed through:

Logs
Metrics
Traces

Each answers different questions.

Logs

Logs tell you about events.

Example:

2026-08-14 14:20:03
Order 12345 payment failed

Useful, but often isolated.

Metrics

Metrics measure numerical behavior.

For example:

HTTP requests/sec
CPU usage
Memory usage
Error rate
Request latency

You might discover:

95th percentile latency = 2.4 seconds

That tells you something is happening at scale.

Traces

Distributed tracing follows a request across multiple components.

For example:

API Gateway
   ↓
User Service
   ↓
Order Service
   ↓
Payment Service
   ↓
Database

If the request takes five seconds, tracing can help identify where that time went.

Why Logs Alone Aren't Enough

Imagine:

Payment failed

A log tells you the payment failed.

A metric tells you that payment failures increased from:

0.5% → 12%

A trace can help show that requests are timing out inside a specific dependency.

Together, these signals provide much better visibility.

Final Thoughts

Logging answers:

What happened?

Metrics help answer:

How often is it happening?

Tracing helps answer:

Where did the request spend its time?

Understanding all three is an important step toward production-grade engineering.

The Difference Between Authentication and Authorization

Soumyajit Mukherjee — Fri, 23 Oct 2026 09:14:15 +0000

Authentication and authorization are often confused.

They answer two completely different questions.

Authentication

Authentication asks:

Who are you?

Examples include:

Passwords
Passkeys
OAuth
Multi-factor authentication
Biometrics When a user logs in, the system authenticates their identity.

Authorization

Authorization asks:

What are you allowed to do?

Suppose Alice is authenticated.

That doesn't mean Alice should be able to:

Delete every user
View financial reports
Modify system settings

The application needs authorization rules.

Example

Imagine an API:

DELETE /users/123

Authentication determines:

Is this request associated with Alice?

Authorization determines:

Is Alice allowed to delete user 123?

Role-Based Authorization

A simple system might define:

const roles = {
  USER: ["read"],
  ADMIN: ["read", "write", "delete"]
};

Then middleware can enforce permissions.

Why This Matters

A common security mistake is:

User is logged in
        ↓
Allow everything

Authentication isn't authorization.

Resource Ownership

Authorization can also depend on ownership.

For example:

GET /users/123/profile

might be allowed only if:

request.user.id === 123

or the user has an administrative permission.

Final Thoughts

Remember the distinction:

Authentication = Who are you?
Authorization  = What can you do?

Keeping these concepts separate leads to much safer application designs.

Caching: The Performance Trick That Can Also Break Your Application

Soumyajit Mukherjee — Fri, 23 Oct 2026 09:03:57 +0000

Caching is one of the most effective ways to improve application performance.

It can also produce some of the strangest bugs developers encounter.

Why Cache?

Suppose a page repeatedly requests the same expensive data.

Without caching:

Request
  ↓
Application
  ↓
Database
  ↓
Response

With caching:

Request
  ↓
Cache
  ↓
Response

The expensive operation can potentially be avoided.

Cache-Aside Pattern

One common strategy is:

let value = await cache.get(key);

if (!value) {
  value = await database.getData();
  await cache.set(key, value);
}

return value;

The application checks the cache first.

If the data isn't there, it loads the data from the database and stores it in the cache.

The Hard Part: Invalidation

Imagine you cache:

user:123

Then the user changes their name.

The database now says:

Alex Smith

but the cache still says:

Alex Johnson

Your application now returns stale information.

This is why developers often repeat:

There are only a few hard things in computer science, and cache invalidation is one of them.

TTL

A time-to-live can automatically expire cached values.

product:123
TTL: 300 seconds

This doesn't eliminate stale data completely, but it limits how long it can remain.

Cache Everything?

No.

Caching data that changes frequently can create complexity without providing much benefit.

Final Thoughts

Caching should be introduced around measurable performance problems.

First understand:

What is expensive?
How frequently is it requested?
How often does it change?
How stale can it safely be?

Then design the cache.

What Makes a Good Git Commit?

Soumyajit Mukherjee — Fri, 23 Oct 2026 08:55:53 +0000

Git commits are more than checkpoints.

They form a historical record of how a project evolved.

Unfortunately, many repositories contain commits like:

update
fix
changes
final
final2
please work

These messages aren't very useful.

A Better Commit

Instead of:

fixed stuff

write:

Fix duplicate order creation during checkout

A good commit should communicate the purpose of the change.

Keep Commits Focused

A commit like:

Add authentication

might include:

Login
Registration
Password reset
UI redesign
Database migration
Random formatting changes That's difficult to review.

Instead, separate logical changes when possible.

Why Small Commits Help

Focused commits make it easier to:

Review code
Revert changes
Find bugs
Understand history
Cherry-pick changes
Debug regressions

Conventional Commits

Some teams use a convention such as:

feat: add password reset flow
fix: prevent duplicate payments
docs: update installation guide
refactor: simplify user service
test: add order validation tests

This creates predictable history.

Commit Messages Should Explain Why

This:

Update payment service

is vague.

This is better:

Retry failed payment requests after temporary gateway errors

The second message tells future developers what changed and why it matters.

Final Thoughts

Your Git history is documentation.

Write commits as if someone will need to understand them six months from now.

How HTTP Status Codes Make APIs Easier to Understand

Soumyajit Mukherjee — Fri, 23 Oct 2026 08:49:24 +0000

HTTP status codes are more than numbers.

They communicate what happened during an HTTP request.

Using them consistently makes APIs easier to consume and debug.

2xx: Success

A common example:

200 OK

means the request succeeded.

Another important status is:

201 Created

which is useful when a resource has been created.

For example:

POST /users

might return:

201 Created

4xx: Client Problems

These usually indicate that something about the request isn't acceptable.

Examples:

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
409 Conflict
429 Too Many Requests

For example, an unauthenticated request might receive:

401 Unauthorized

while an authenticated user lacking permission may receive:

403 Forbidden

5xx: Server Problems

These indicate that the server encountered an error.

The classic example:

500 Internal Server Error

Another useful code is:

503 Service Unavailable

which can indicate temporary service unavailability.

Why Consistency Matters

Imagine an API that returns:

for every request, even when something fails.

The client now has to inspect custom fields to determine whether the operation succeeded.

Standard HTTP semantics make APIs much easier to understand.

Don't Overcomplicate It

You don't need to memorize every status code.

Start with:

These cover a large portion of everyday API development.

Final Thoughts

Good API design isn't only about endpoints and JSON.

The status codes are part of the API contract too.

Understanding JWT Authentication Without the Hype

Soumyajit Mukherjee — Fri, 23 Oct 2026 08:41:14 +0000

JSON Web Tokens are widely used for authentication.

They're also widely misunderstood.

A JWT is not automatically more secure than sessions.

It is simply a token format with specific properties.

Basic JWT Structure

A JWT commonly consists of three sections:

Header.Payload.Signature

For example:

xxxxx.yyyyy.zzzzz

The payload can contain claims:

{
  "sub": "12345",
  "role": "user"
}

Important: JWT Payloads Are Not Secret

JWT contents are typically encoded, not encrypted.

Therefore, don't place sensitive information inside them.

For example, avoid putting:

{
  "password": "secret123"
}

in a JWT.

Authentication Flow

A common flow is:

User logs in
     ↓
Server validates credentials
     ↓
Server issues token
     ↓
Client sends token with requests
     ↓
Server validates token

Token Expiration

Tokens should generally have appropriate expiration periods.

Short-lived access tokens can reduce the impact of token theft.

Some architectures also use refresh tokens to obtain new access tokens.

Storage Matters

Where tokens are stored affects security.

Developers should understand the risks of:

XSS
CSRF
Token theft
Insecure browser storage
Long-lived tokens There isn't a universal storage strategy that is correct for every architecture.

JWT Isn't a Session Replacement by Default

Traditional server-side sessions can be simpler for many applications.

The right choice depends on requirements.

Final Thoughts

Learn JWT as an authentication mechanism, not as a security buzzword.

The important questions are:

Where is the token stored?
How long does it live?
How is it revoked?
How are requests authenticated?