DEV Community: Sheraz Manzoor

Another Year in Production 🎂

Sheraz Manzoor — Tue, 20 Oct 2026 21:55:14 +0000

Today is my birthday. 🎉

Another year of learning, debugging, breaking things, fixing them, and occasionally wondering why the code worked yesterday.

If life had a changelog, I hope this year's release includes fewer bugs, better decisions, and some meaningful improvements.

And yes, I'm already working on my next engineering article. More on that soon. 👨‍💻

For today, though, I'll accept birthday wishes as my uptime monitoring dashboard. 😄

Wish me a happy birthday, developers! 🎂

How a smart Engineering Decision Reduced Our costs by 25% and is continuously reducing.

Sheraz Manzoor — Sun, 11 Oct 2026 18:42:39 +0000

Our banking app had a feature, which let the users to find nearby branches and ATMs using their current location. And the users liked this feature very much.
It was straightforward from the user's perspective.

open app -> open maps tab -> find the branches and ATMs

But with a banking app, with a MILLIONS OF USERS, it was very costly. A user might request maps for several times a day and that will hit google maps api which bills based on the number of requests.

Consider a typical user journey. Someone opens the map before visiting a branch. They close it, return a few minutes later, and search for nearby ATMs. Another user makes a similar request in the same area. With a large user base, these otherwise ordinary interactions can generate a substantial number of external API requests.

Our orignal request flow was very simple.

flowchart LR
    A[User opens map] --> B[Application requests locations]
    B --> C[Google Maps API]
    C --> D[Results displayed]

There was nothing wrong with Google Maps. It provided the functionality we needed. The problem was how our application approached repeated requests.

That led us to a practical question:

Why should we make another external request for information we already have, when that information can legally and reliably be reused?

The objective wasn't to eliminate Google Maps. We still needed it when the application genuinely required information that wasn't available locally or needed a permitted refresh.

The objective was to stop treating every lookup as if it were the first one.

Let's store the map's data in our own database

This idea changed the whole picture. We decided when user opens the map, we get data from Google maps, and we store this data in our own database.
AND when the user opens the map again, we make the request to our database first, if requested data is there, we don't have to call the Google Maps API again. And if data is not there, the Google Maps will be requested to provide the required data and that will be stored in the database again.

It was attractive for a few reasons:

Fewer unnecessary external requests.
Lower recurring API spend.
Fewer network round trips on a path users hit constantly.
Reuse of information across requests, where reuse is appropriate and permitted.
Faster responses for frequent lookups.

A word on terminology, because it matters here. The persistent layer is information stored in our database. Redis, which came later, has a different and narrower role. And renaming "cache" to "database storage" changes nothing about what Google allows. The Terms prohibit caching Google Maps Content except where expressly permitted, and they list storing Google Maps Content outside the services among the things you can't do (Terms of Service, §3.2.3). Where the data sits doesn't decide whether you may keep it.

Implementation (2 layers, 2 jobs)

SInce we established database first strategy, we had to make lookups fast enough, that user don't notice the delay.

Earlier approach:

user opens map -> request sent to google maps server -> response back to client (user)
ONE API CALL ONLY

But with our idea

user open map -> request sent to bank server -> result not found -> request sent again to google maps api -> response back to client (user)
TWO API CALLS IF DATA IS NOT AVAILABLE IN OUR SERVER

So that was another challenge. So we found a way to manage this. RADIS !!

Initally Radis has all pointers about every data, that this specific requested data is not present in our server. So, the initial request is now never sent to our server if the requested data is not there.

And whenever that data or information is stored in database, the pointer to that specific data from the Radis Cache was removed.

Thus when user made the request, the first place to gp was Radis Cache. If data pointer is there, we would make the request directly to Google Maps API instead of hiting our server first. And if the data pointer was not in the Radis Cache, we made the requests to our server directly.
Speed lightening fast, least requests possible sent to the Google Maps API.

flowchart TD
A[User opens map] --> B{Check Redis Cache}

    B -->|Pointer exists: data unavailable locally| C[Request Google Maps API]
    C --> D[Return response to user]

    B -->|Pointer does not exist: data may be in database| E[Request Bank Server]
    E --> F{Data found in database?}

    F -->|Yes| G[Return stored data]
    G --> D

    F -->|No| H[Request Google Maps API]
    H --> I[Store eligible data in bank database]
    I --> J[Remove corresponding Redis pointer]
    J --> K[Return response to user]

    style B fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    style C fill:#fef3c7,stroke:#d97706,color:#92400e
    style H fill:#fef3c7,stroke:#d97706,color:#92400e
    style G fill:#dcfce7,stroke:#16a34a,color:#166534
    style J fill:#f3e8ff,stroke:#9333ea,color:#581c87

Next Challenge (stored information becomes outdated)

Eliminating unnecessary requests is only useful when the result returned to the user is still appropriate.

Location information changes. A branch may move, an ATM may close, and details about a place may be updated. Information that was accurate when first retrieved cannot be assumed to remain correct indefinitely.

Our reuse strategy therefore introduced another responsibility: managing freshness.

There are two obvious but undesirable extremes.

The first is to request fresh information every time. This may reduce reliance on older records, but it also sacrifices much of the performance and cost benefit of reuse, which was the basic goal.

The second is to keep using stored information indefinitely. That may look efficient in API usage statistics, but it risks showing users details that are no longer correct.

Neither approach is a good general policy.

Instead, data freshness needs to be treated as part of the serving strategy. A record must be considered usable only within the rules applicable to that information.

That requires distinguishing at least three things:

Availability: Does a record exist?
Freshness: Is the record still suitable to serve?
Permission: Is the application allowed to retain and reuse that information in this way?

These questions are related, but they are not interchangeable.

A record can exist in the database and still be too old to use. A record can be fresh but subject to a storage restriction. And a record may be permitted to persist even though some related location details require a different refresh policy.

The external provider's rules matter here. For example, Google explicitly permits storing Place IDs for later reuse and recommends refreshing IDs older than 12 months because they may change. That recommendation is distinct from the 30-day caching limit for Places API latitude and longitude values. Google's Place IDs documentation explains both.

This is why I wouldn't recommend a universal expiration period for every field in a location-related record. The correct policy depends on the source, field, use case, and applicable terms.

Redis adds another consideration. Even if the persistent record is refreshed or corrected, an old Redis entry must not continue to take precedence over the newer information.

The system needs a consistent strategy for both layers: determine whether the information is valid to serve, update or invalidate affected fast-lookup entries when necessary, and avoid reintroducing stale values through a later cache fill.

The precise mechanics can vary. The essential requirement is that Redis accelerates the correct lookup path rather than becoming a second, inconsistent source of truth.

This was an important part of the engineering problem. Reducing external requests is not a success if the application achieves it by returning information users should no longer see.

Why Redis lives in one feature

This decision deserves its own section, because "add Redis" is a tempting reflex.

We chose Redis for one feature with one specific performance requirement:

Latency matters here. People reach for a branch finder when they need an answer now, and a map that fills in slowly feels broken.
The access pattern fits. The feature repeatedly requests the same eligible records, which is exactly where a low-latency lookup layer pays off.
The two stores do different jobs. The database gives durability and a source of truth. Redis gives speed on hot records. Neither replaces the other.
Everywhere else, it would be pure cost. Putting Redis into unrelated parts of the system would add deployment, monitoring, failure modes, and invalidation rules without solving any problem those parts actually have.

That's the difference between a targeted engineering decision and adopting a tool because it's popular. We didn't need Redis everywhere. We needed the maps feature to retrieve the information it already had as quickly as possible.

The results: faster lookups, lower API spend

I'd rather describe what changed accurately than decorate it with numbers I can't defend.

Less unnecessary traffic to Google Maps, because lookups we could answer ourselves stopped becoming outbound requests.
Faster responses whenever information could be served from Redis or the database.
Reuse across repeat requests of eligible information that previously would have been fetched again.
Lower API spend, as avoidable requests were eliminated.
A growing body of stored, eligible records, which gives more repeat lookups the chance to be resolved without an external call.

That last point comes with an asterisk. Growth has limits: anything with a retention limit has to leave on schedule, and refreshes cost calls of their own (the ID-only refresh being the documented exception). New locations, data changes, usage patterns, and provider pricing all move the total. More stored information improves the opportunity for reuse. It doesn't promise that costs fall forever.

If you want to prove a change like this works rather than just believe it, these are the numbers to track, with a baseline captured before you ship:

Google Maps API request count.
Cost per period, or per relevant user activity.
Redis and database hit rates, where measurable.
Median and p95 response latency.
Duplicate requests on missing records.
Stale-data and refresh rate.

📉 25% LOWER GOOGLE MAPS COSTS — AND STILL FALLING

Merged: 10 August 2026

As of the publication date, Google Maps costs have dropped to just 25% of their previous level — and continue to decrease.

Not because we switched providers. Not because we downgraded the experience.

Because we made a smarter engineering decision.

The broader lesson

The takeaway isn't "use Redis," and it isn't "store API responses." It's to understand your application's request patterns, then make deliberate choices about where data lives, when an external request is truly necessary, what can be reused, and how freshness is maintained.

For this feature, that meant combining five things:

Persistent storage of eligible data.
A feature-specific, low-latency lookup layer.
Correct handling of missing records.
Deliberate management of freshness.
Measurement of both performance and cost.

Each piece alone is a half-answer. Storage without freshness serves stale results. Speed without miss-handling multiplies calls. Neither means much if you can't measure it.

The biggest optimisation was not making an external API call faster. It was making fewer unnecessary calls, while returning the information users needed more quickly.

DISCUSS

If you found this helpful, and have such stories or smarter decisions, you or your team made, which really was super beneficial, please let me know in the comments and then discuss more engineering. Looking forword to your response felloz!!

The Frog That Lived: Let's learn about falsification.

Sheraz Manzoor — Tue, 06 Oct 2026 11:50:25 +0000

Suppose! You're a biologist and you have a claim based on your hypothesis that:

All the frogs we put in a deep freezer will die

To prove your claim you do an experiment.

You put 10 frogs in a freezer and the next day they all are dead in the deep freezer. Your confidence in your claim will rise. Now you do the same experiment on the 90 more frogs (10 frogs in a batch) and you get the same result. You'll be even more confident in your claim.

But can you say, your claim is scientifically proven? Never!

Now imagine that one of the frog from the eleventh batch survive under same conditions in the deep freezer. What does that mean? That falsified your claim. We don't need to do 100 more experiments to prove that the claim "All frogs in a deep freezer dies" is false. That's called falsification.

That asymmetry is the important part:

A finite collection of confirming examples cannot prove a universal claim, but a single valid counterexample can falsify one.

Karl Popper made this asymmetry central to his philosophy of science. In The Logic of Scientific Discovery, he argued that universal theories cannot be derived from finite observations, while a suitable observation that contradicts a theory can refute it. The same logical structure appears in engineering every time we test a claim about software. Popper, The Logic of Scientific Discovery Stanford Encyclopedia of Philosophy: The Problem of Induction

There is an important engineering distinction here: a passing observation is usually compatible with the hypothesis, while a valid counterexample is incompatible with it.

That is why one test failure can be much more informative than thousands of passing tests.

The Problem of Induction in Software Testing

Software testing is induction with a CI pipeline. You run a finite number of cases and infer a general claim: "this function is correct." Edsger Dijkstra said it bluntly decades ago: testing can reveal the presence of bugs, never their absence.

Suppose this function is intended to sort integers:

def sort_numbers(xs):
    return sorted(set(xs))

It works for many inputs.

It works for:

[]
[1]
[3, 1, 2]
[5, 2, 9, 7]

A large regression suite might happily contain thousands of examples like these.

But the function silently removes duplicates.

The counterexample is tiny:

[0, 0]

Expected:

[0, 0]

Actual:

[0]

One failure is enough to falsify the hypothesis:

"This function correctly sorts every list of integers."

A system with 99.999% boring behavior does not become 100% safe because the boring behavior was observed often.

The missing 0.001% may contain the incident.

Real world examples of falsification in Engineering

1. Google

Google had a large distributed MySQL environment, with many dependent services. The engineers assumed that if one the database fails, the rest of the system will continue working.

Instead of waiting for the database to crash in production, they tested their assumption. They intentionally failed one database out of hundreds. They expected a controlled failure.

But reality was different.

Within minutes of commercing test, numerous dependent services reported that both external and internal users were unable to access important systems. Some systems were intermittently or only partially accessible.

Google immediately aborted their test, restored the access and started investigating the issue.

They didn't found one issue, they found several issues:

Hidden dependencies existed between systems that were supposed to tolerate the database failure.
Their rollback procedure had not been sufficiently tested and was itself flawed.
A flaw existed in the database application-layer library.
Their incident-response process had not been sufficiently exercised.

Thw important part is what they did after all this.

Google fixed the library, improved the recovery process, and instituted periodic retesting. Their own SRE documentation explicitly describes the goal as breaking systems, observing how they fail, discovering hidden weaknesses, and then making changes to prevent those failures from recurring.

Source: Google SRE

2. Netflix

Netflix's move to AWS created a very different failure environment.

In a traditional data center, an individual server failing might be relatively infrequent and handled operationally.

In a large distributed cloud environment, individual instances can disappear, networks can fail, dependencies can become unavailable, and components can behave unpredictably. So the engineer's thought "Our services will continue working when individual infrastructure components fail."

So being the responsible engineers, instead of believing their assumption, they decided to test it. So they created an open source tool to test their assumptions called Chaos Monkey.

Chaos Monkey randomly terminates virtual machine instances and containers that run inside of your production environment. Exposing engineers to failures more frequently incentivize them to build resilient services.

But their test was even brutal.They built a Chaos KOng, which doesn't just kill a serer, it kills an entire AWS region.

During the Chaos Kong in exercise they found that traffic evacuate from the west region. The east region got a corresponding bump in traffic as it stepped up to play the role of saviour. As long as the aggregate metric followed that relatively smooth trend, Netflix knew that their system is resilient to the failover. At the end of the exercise, traffic reverted back to the west region.

AFter this reliability question changed forever. Instead of asking do we have two servers, they started asking what if we kill one?
Since then they regularly runChaos Kong exercises and they say, "it gives us confidence that even if an entire region goes down, we can still server our customers".

Source: Chaos Engineering Upgraded

3. My personal experience (A case study worth reading)

We were making a payment service in one of our project, that handled transactions through an external payment provider. The flow was very very simple:

Client -> Create Payment -> Payment Service -> Payment Provider -> Database

We ran unit tests. We had integration, duplication and timeouts tests. We had tests for successful payments and provider failure. It was a green forest. So we assumed that "If a customer retries the same payment request, we won't charge them twice".

That assumption sounded reasonable because we had an idempotency mechanism. The only problem was that we were testing known examples. We weren't actively trying to destroy the assumption.

So I changed the question. Instead of thinking does our idempotency code work, I thought what sequence of events would falsify the claim that our payment operation is idempotent.

AN interesting possibility arose.

What if:

Request 1 -> Payment Provider successfully charges the card -> Network timeout occurs -> Our API never receives the response -> Client retries -> Request 2

I deliberately produced this issue.

I mocked the payment:

Accept payment -> Record the charge -> Pretend the response was lost -> Return a timeout to our application.

Then I sent the same logical payment again. And you know what happened?
The second request generated another charge. This falsified our assumption before moving the app to production.

The solution was not simply

if retry:
    don't charge

We redesigned the operation around a stronger idempotency contract.

The request received a stable idempotency key:

POST /payments

Idempotency-Key: 8d7e...

The service persisted the operation state before allowing the workflow to complete:

idempotency_key
status
provider_transaction_id
result

A repeated request with the same key would then resolve to the existing operation instead of creating another payment.

More importantly, I kept the original failure scenario as a permanent regression test.


def test_payment_is_idempotent_when_provider_succeeds_but_response_is_lost():
    provider.charge_side_effect = [
        ChargeSucceededButResponseLost(),
        ExistingChargeResponse(),
    ]

    first = create_payment(idempotency_key="abc")
    second = create_payment(idempotency_key="abc")

    assert number_of_provider_charges() == 1
    assert second.payment_id == first.payment_id

We didn't discover the bug cuz we added another 500 happy-path tests, we discovered it because we added what would falsify our assumption.

Falsification in Practice: Property-Based Testing, Fuzzing, and Model Checking

Property-based testing: a frog hunter, not a frog counter

Example-based tests say "for this input, expect that output." Property-based testing (PBT), pioneered by QuickCheck and available in Python via Hypothesis, says "for all inputs of this shape, this property should hold" and then tries to break it.

Here are two properties any sort must satisfy:

from collections import Counter
from hypothesis import given, strategies as st

@given(st.lists(st.integers()))
def test_sort_properties(xs):
    out = my_sort(xs)

    # Property 1: output is in non-decreasing order
    assert all(a <= b for a, b in zip(out, out[1:]))

    # Property 2: output is a permutation of the input

Our function silently drops duplicates. Hypothesis found a counterexample and then shrank it to the smallest failing input, [0, 0].

The test never asked "does [3, 1, 2] sort correctly?" It asked "can I find any input that violates these properties?"

An honest caveat is that PBT is still sampling. Hypothesis runs 100 examples per test by default, and 100 passes prove nothing about the 101st. PBT is a better frog hunter, not a proof engine. Its advantage is that it looks in places you wouldn't think to look.

Model checking: search for the counterexample trace

Formal methods embrace the asymmetry too. A model checker such as TLC (for TLA+) or SPIN takes a model of your system and an invariant and asks: is there any reachable state that violates it? If there is, you get a counterexample trace, the exact sequence of steps that leads to the violation.

Amazon has publicly described using TLA+ to find subtle concurrency and fault-tolerance bugs in distributed systems, including ones whose failing traces were dozens of steps long. No human writes a test for step 35 of an obscure interleaving, but a checker that exhaustively searches for a falsifying path will find it.

Fine print: if a checker exhausts a finite model without finding a violation, you've proven the invariant for that model. The model is not your production system, and you're still one wrong assumption away from a surviving frog.

Fuzzing: you only need one crash

You don't have to prove a parser is safe. You have to find one input that crashes it.

Fuzzers like AFL and libFuzzer do exactly that, mutating inputs and using coverage feedback to steer toward unexplored code paths. It's falsification with a compass. Barton Miller's original 1990 fuzz study threw random garbage at common UNIX utilities, and a startling fraction crashed or hung. Every crash was a frog that lived.

For anything that eats untrusted bytes, such as parsers, protocol handlers, and deserializers, fuzzing is the cheapest falsification engine you can buy.

Debugging is falsification, too

A bug report is a falsifying observation. You don't need a theory of every way your system can fail. You need one reproducible failure.

That's why the debugging workflow looks the way it does. You reproduce the failure, minimize it (shrink the input, git bisect the commit), and turn it into a test. Hypothesis's shrinking is the same instinct, automated.

One caution: a failing test falsifies the conjunction of your code, your test, your environment, and your assumptions. Before you declare victory, check that the frog was really a frog. A flaky test, a bad fixture, or a wrong expectation can all produce a false alarm. Once a failure is reproducible, though, it's decisive. Don't argue with it and don't average it against the 4,000 tests that passed.

Why This Matters for Engineering Culture

There is a difference between asking, how can we prove this works and asking what would make our belief that this works wrong?

The second question is much more productive and drives results.

Test design. A confirmation mindset writes the happy path and a couple of edge cases, then stops when the checkmarks turn green. While, a falsification mindset asks what property must always hold and how to violate it.

Code review. Instead of "does this look right?", ask "what might break this?" Reviewers who hunt counterexamples find different bugs than reviewers who skim for plausibility.

Incident response. A production incident is a falsifying observation about your mental model of the system. The right response is to update the model, not to explain why the incident was unlucky. Then you add the counterexample to the suite so that frog can never surprise you twice.

Chaos engineering makes the connection explicit. Its method is to state a hypothesis about steady-state behavior, inject failure, and look for the experiment that contradicts you.

Practical Takeaways

Write tests that try to falsify invariants, not just confirm happy paths. Ask "what must always be true?" and then try to violate it. In the organization, I work in, we have made several tools that inserts inputs that break the system, make yours.
Use property-based tests for logic-heavy code (parsers, serializers, state machines, data transformations, anything with round-trip or ordering properties).
Fuzz anything that handles untrusted input: parsers, protocols, file formats, input validation.
Treat a green suite as evidence of absence of known counterexamples, not as proof of correctness. Say it that way in your head, and in your release notes.
When one test fails, treat it as decisive. Stop, reproduce, fix, and add the counterexample to the suite permanently.
In design reviews, ask: "What would falsify this design? What's the smallest input that breaks this assumption?"
Define your domain precisely. Vague claims ("handles all valid input") invite arguments about whether a counterexample counts.

Charcole v2.3.0 is a BOMB 💣

Sheraz Manzoor — Fri, 15 May 2026 15:17:10 +0000

If you are a Nodejs Backend Developer, your life is going to change. Let's figure out why???

Introduction

Charcole is a modern CLI built to help developers scaffold, configure, and ship production-ready projects with confidence. Charcole removes repetitive setup work so you can focus on building features instead of fighting boilerplate.

What is charcole??

Charcole is an opinionated project scaffolding tool designed for real-world development workflows.

Instead of starting every nodejs project from scratch, Charcole gives you:

Clean, structured project foundations
Sane defaults based on modern best practices
A fast, guided CLI experience
Flexibility to grow without lock-in
The revolutionary repository system, which helps you test your apis without a real database.
Built in modules for authentication, swagger docs and a full-fledged payments modules.

It’s built for developers who care about clarity, best practices, speed, and maintainability.

Why Charcole exists?

Most starters fall into one of two traps:

Too minimal → you still spend hours wiring basics
Too complex → hard to customize or understand

Charcole sits in the middle.

It provides just enough structure to be productive on day one, while staying transparent and customization as your project evolves.

Checkout the full documentation HERE
If you want to contribute, checkout the RESPOSITORY (If you find it helpful, please star the repository as well, it'll be a great favor)
Check it out on NPM

You're Not a Coder Anymore. You're an Orchestrator. (And That's a Good Thing)

Sheraz Manzoor — Wed, 06 May 2026 10:43:31 +0000

The shift from AI autocomplete to AI agents is the biggest change in software development since version control -- and most devs aren't ready for it.

If you're still treating your AI tools like a smarter Stack Overflow, you're already behind.

In 2026, the developers shipping the most code aren't the ones who type the fastest or know the most syntax by heart. They're the ones who've figured out how to orchestrate AI agents like a conductor leads an orchestra. One experienced developer with the right agentic framework can produce the output of a team of four or five engineers.

That's not hype. That's what's actually happening in the industry right now.

So let's talk about what "AI-agentic development" actually means in practice, how it changes the way you write and review code, and how you can start building these habits today.

First, What Even Is an AI Agent?

Before we go further, let's make sure we're on the same page.

A traditional AI coding tool (like early Copilot) works like autocomplete on steroids. You write a comment or a function signature, and it suggests what comes next. You're still driving. The AI is just filling in words.

An AI agent is different. You give it a goal, and it figures out the steps. It can:

Read your existing codebase to understand context
Create files, write tests, and scaffold components
Run commands and check the output
Fix its own errors and iterate
Open pull requests when it's done The mental model shift is huge. Instead of asking "what code should I write next?", you start asking "what do I want to exist that doesn't exist yet?" and then delegating the building to an agent.

The Old Workflow vs. The New Workflow

Here's a concrete example. Let's say you need to build a user authentication module with JWT tokens.

The old workflow (2022-era AI):

You: // create a function to generate a JWT token
AI: suggests a 10-line function
You: copy, paste, tweak, move on

You're still writing 80% of the code. The AI is a lookup tool.

The new workflow (agentic, 2026):

You open your terminal and type something like:

# Using Claude Code as an example agent
claude "Build a JWT authentication module. Use jsonwebtoken,
store refresh tokens in Redis, add middleware for protected routes,
and write Jest tests for each function. Follow the existing project
structure in /src."

The agent then:

Reads your /src directory to understand your file structure and naming conventions
Checks your package.json for existing dependencies
Scaffolds auth.service.ts, auth.middleware.ts, and auth.test.ts
Runs the tests and fixes any failures it finds
Reports back with a summary You didn't write the code. You defined the outcome.

What This Means for Your Day-to-Day Work

This shift changes where your mental energy goes. Let's break it down.

1. Prompting is now a core skill

How you describe a task determines the quality of what you get back. Vague instructions produce vague code. Precise instructions with context produce production-ready code.

Compare these two prompts:

Bad:  "Add error handling to my API"

Good: "Add error handling to all async functions in /src/routes/*.ts.
      Use a centralized error handler middleware. Return structured JSON
      errors with a 'code', 'message', and 'details' field.
      Log errors using the existing Winston logger in /src/utils/logger.ts."

The second prompt gives the agent constraints, existing context, and an expected output format. You'll get something you can actually use.

2. You review more than you write

Your job becomes code review at a higher level. Instead of reviewing your own work line by line as you go, you're reviewing entire feature scaffolds and asking:

Does this follow our architecture patterns?
Are there security implications I need to check?
Is this the right abstraction, or is it over-engineered? This is actually a more valuable use of your time. The mechanical typing is handled. The judgment is still yours.

3. Architecture decisions matter more, not less

Here's the thing people get wrong: they think agentic AI tools reduce the need for technical expertise. It's the opposite.

If you give an AI agent bad architectural direction, it will build you a very clean, well-tested, beautifully scaffolded bad system. Garbage in, garbage out, just faster.

Knowing why you'd use a message queue vs. a direct API call, why you'd separate your domain logic from your infrastructure layer, why you'd reach for an event-driven pattern in one scenario vs. a request-response pattern in another -- these skills are more important now than ever. Because you're the one making those calls.

A Practical Agentic Workflow You Can Steal

Here's a workflow pattern that senior devs are adopting right now. Think of it as "spec-first" development.

Step 1: Write a task spec, not just a ticket

Before you hand anything to an AI agent, write a short spec file:

# Task: Add rate limiting to the public API

## Goal
Prevent abuse by limiting requests to 100 per 15 minutes per IP address.

## Constraints
- Use express-rate-limit (already in package.json)
- Apply globally in app.ts, not per-route
- Return a 429 status with a clear error message
- Add an exemption for internal service-to-service calls (identified by X-Internal-Token header)
- Write integration tests using supertest

## Files to touch
- src/app.ts (add middleware)
- src/middleware/rateLimiter.ts (create this)
- tests/rateLimiter.test.ts (create this)

## Do NOT change
- Any existing route handlers
- Authentication logic

This spec becomes your agent's system prompt. It gives it constraints, context, and a clear scope boundary.

Step 2: Run the agent with the spec

claude --file task-spec.md

Or paste it directly into your tool of choice.

Step 3: Review the diff like a PR

When the agent is done, treat its output exactly like you'd treat a pull request from a junior developer. Check the logic, check the edge cases, check that the scope didn't drift.

git diff

Look for:

Did it touch files you said not to touch?
Does the test actually assert the right things, or does it just pass trivially?
Are there any magic numbers or hardcoded values that should be config? ### Step 4: Iterate with follow-up prompts

Agents shine in iteration. If something is off, be specific:

"The test passes when the rate limit is hit but it's not testing the
X-Internal-Token exemption. Add a test case for that."

This back-and-forth is fast. A correction that would take you 20 minutes to track down and fix takes 30 seconds to describe.

The Pitfalls (Don't Skip This Section)

Agentic development is powerful, but it's easy to shoot yourself in the foot if you're not careful.

Pitfall 1: Trusting without reading

The number one mistake is treating AI output as safe to ship without reading it. Agents can and do:

Introduce subtle bugs in edge cases
Write tests that pass trivially (testing that true === true, essentially)
Use deprecated APIs they learned from older training data
Over-engineer simple solutions Always read the diff. Every single time.

Pitfall 2: Scope creep in agent runs

Agents are eager. If your spec is vague, they'll fill the gaps with assumptions. Sometimes those assumptions touch things you didn't want touched.

Mitigate this by being explicit about scope boundaries in your spec, as shown above. "Do NOT change X" is a sentence worth writing.

Pitfall 3: Context rot in long sessions

The longer an agent session runs, the more likely the agent is to lose track of early constraints. For big features, break the work into multiple smaller agent runs rather than one giant session.

Run 1: Scaffold the data models and migrations
Run 2: Build the service layer
Run 3: Wire up the API routes
Run 4: Write tests for the complete flow

Each run starts fresh with the relevant context. This produces cleaner, more consistent output than one mega-prompt.

Pitfall 4: Skipping security review

AI agents don't have your threat model. They'll write code that works in the happy path but miss things like:

SQL injection vectors in dynamic queries
Missing authorization checks on sensitive endpoints
Storing sensitive data in logs Treat any agent-written code that handles user input, authentication, or data persistence with extra scrutiny.

The Skills That Actually Matter in 2026

If you want to level up as a developer in this new landscape, here's where to invest:

Double down on systems thinking. Understand distributed systems, data modeling, and software architecture at a deeper level. The agents build. You design.

Get comfortable with TypeScript. End-to-end type safety across client and server is now the baseline expectation. Agents produce much better, more consistent code when your codebase has strong types.

Learn to write clear specs. This is basically technical writing. Ambiguity is the enemy. Practice writing requirements that a developer who knows nothing about your project could follow.

Understand what agents can't do well. Novel algorithmic problems, nuanced UX decisions, security audits, performance profiling -- these still need deep human attention. Know where the handoffs are.

Stay hands-on in the code. The developers who drift too far from the actual code and become "prompt managers only" will lose their technical judgment quickly. Keep reading code, keep debugging, keep understanding the system.

So, Are Developer Jobs Going Away?

Let's address the elephant in the room.

No. But the shape of the work is changing fast.

The developers who treat AI agents as a threat are going to have a harder time than those who treat them as leverage. A skilled developer with agentic tools doesn't get replaced. They get multiplied.

Think of it like this: a great architect doesn't get replaced by better construction equipment. Better equipment just means they can build more ambitious things.

The floor is rising. Junior developers who rely on agents too heavily without building foundational understanding will struggle. But experienced developers who know their craft and add orchestration skills on top will be absurdly productive.

Getting Started Today

If you haven't started experimenting with agentic tools, here's the shortest path to getting your hands dirty:

Set up Claude Code, Cursor, or GitHub Copilot Workspace in a real project you're working on
Pick one well-defined, low-risk task (not something in production-critical code) and write a spec for it as described above
Run the agent and review the output like a PR without running it yet
Iterate with follow-up prompts until the output meets your bar
Then run the tests, check the behavior manually, and decide if it's shippable That first successful run where you go from "here's what I want" to "here's working, tested code I didn't have to type" is a genuinely mind-shifting experience.

The developers who build this muscle now will have a significant head start over those who wait until it's "mainstream." In a lot of teams, it already is.

Wrapping Up

The core shift is this: your value as a developer is no longer in your typing speed or your ability to recall syntax. It's in your ability to think clearly about what needs to exist, define it precisely, and evaluate what gets built.

That's actually a more interesting job. More architecture, more judgment, more design, less boilerplate.

The era of AI as autocomplete is already over. The era of AI as collaborator is here. The question is whether you're going to treat these tools like a smarter search engine or like a team member you can delegate to.

Start delegating.

Have you started using agentic workflows in your day job? What's working for you and what's been a pain? Drop a comment below, I'd love to hear how others are adapting their workflows.

Many of my followers liked this post and it got so much love. So sharing it again for the new folks out there,

Sheraz Manzoor — Tue, 05 May 2026 19:16:05 +0000

Sheraz Manzoor

Jul 19 '24

Good Commit ✔ VS. Bad Commit ❌: Best Practices for Git

#git #github #webdev #beginners

1012

4 min read

Coding is dead; Engineering is not.

Sheraz Manzoor — Sat, 28 Feb 2026 17:19:29 +0000

Tech industries have been marking something as dead, since the internet came. They marked PHP dead, they marked the desktop apps dead, now they're saying coding is dead. So, let's disscuss, is coding really dead?

With vibe coding platforms, the startups are bragging about, shipping without developers. Some even say;

If AI can write code, what's left for developers?

Answer to the question.

To answer that bitter question, I would love to share my personal experiences.

First experience is very recent, I guess it was in December. A client approached me on Linkedin, and said this exactly;

"I have created a website with loveable, everything is fine but there's an issue. On google page insights the performance score is only 28%. Can you fix this and bring the score to 90+?"

So, AI generated the website for him, but he still needed my services. And when I looked his code, there were 2000+ lines of code in various single files, images loading on the homepage were above 5 mb, most of'em.

And I did my "engineering" and the performance boosted to 98.

The second experience is that client approached me with a very similar situation, I'll edit his message a bit to avoid confidential information leaks, he said;

"I have a THAT specific issue, I'm trying to resolve it with AI from weeks, but nothing worked out, can you help me in this please? Give me a quotation and a timeline"

So, AI failed at that certain problem, which was basically "Engineering" related; not about "Coding"

To cut the story short, the coding is really dead, but engineering didn't and it'll never.

The death of Coding

Let's be honest; Writing the boilerplate code was never the highest form of intelligence. We even found free templates which really helped a lot several times.

CRUD oprations, API endpoints, forms validations, UI design, these tasks are increasingly automated, and don't be sad, it's not a tragedy, it's progress. Just like calculators didn't kill Mathematics, AI wouldn't kill Engineering. After AI, just an idea died;

A developer is someone who writes the code line by line

What coding was? And why it wasn't enough?

In very descriptive way, "Coding was just syntax execution". And on the other hand, "Engineering is problem solving".

An engineer understands ambiguous requirements, designs scalable systems, anticipates failure modes, balances performance, security, costs and UX, makes trade-off under real world pressure. So, coding is a language, engineering is the mindset.

Why Engineering will always survive?

Real world problems are very messy, they aren't like simple vanila problems. Client contradicts themselves, requirements change in the mid-build, business goals conflicts with technical realities.

Engineering is the ability to shape chaos into meaningful systems. AI can generate functionality, it cannot take responsibility.

AI works always with context and patterns. Now, from the experiences I shared, many files had 2000+ lines of code, not a single AI can make edits in that single file, and reality we have tens and thousands of files, what will AI do there? It'll crash. On the other hand, Engineers write systems based on domain knowledge, business context, user behavior and organized constraints. Context is not a prompt, context is experience.

Here's my new blog post, I had been working and testing Nextjs 15 for two months and here's a summary of it.

Sheraz Manzoor — Tue, 09 Dec 2025 10:37:30 +0000

Sheraz Manzoor

Dec 9 '25

What's new Nextjs in 15?

#nextjs #react #javascript #typescript

2 min read

What's new Nextjs in 15?

Sheraz Manzoor — Tue, 09 Dec 2025 10:36:23 +0000

Vercel Recently launched Nextjs 15, and decaled it as stable and ready for production. Today we'll disscuss what's new in Nextjs 15.

Basically there are new features in Nextjs 15;

React 19 RC Support

Next.js 15 RC now supports React 19 RC. This includes the new features for both client and server side rendering. One of the new features in React 19 is Actions which is a very common use case in React Apps to perform Data Mutation and then update in response.

For example; when a user submits a form to change their name, you'll make an api request and then handle a response.

`@next/codemode` CLI

Now you can easily upgrade to latest Nextjs and React versions

npx @next/codemod@canary upgrade latest

Turbopack Dev (Stable)

Performance and stability has been improved to the next level.

React Compiler (Experimental)

The React Compiler is a new compiler created by the React team at Meta. Complier understands your code at a deep level through it's understanding of plain JavaScript semantics and the rules of React, which allows it to add automatic optimizations to your code.

The code reduce the amount of manual memorization developers has to do with apis such as useMemo and useCallback, making code simpler, easier to maintain, and less error prove.

Hydration Error Improvements.

Nextjs continues to build on those by an improved hydration error view. Hydration errors now display the source code of the error with suggestion on how to address the error.

Such improvements help the developers to better understand the error fix it in low time.

Caching Updates

In Nextjs 15, caching default for fetch requests, GET Route handlers and Client Route Handlers and client router cache has changed from cached by default to uncached by default.

If you want to retain the previous behavior, you can continue to opt-into caching.

Partial Prerendering (Experimental)

Partial Prerendering is a new rendering strategy that combines the benefits of static and dynamic rendering on the same route. Quite similar to parallel routing, right? With PPR, you can wrap any dynamic components in a Suspense Boundary.

When a new request comes in, Nextjs will immediately serve a static HTML shell from the cache, then render and stream the dynamic parts in the same HTTP request.

`unstable_after` API (Experimental)

This executers a stream after a response finishes streaming.

So, these were the backbone new features of Nextjs 15, I find them quite fascinating and interesting, and after using them from almost two months (October 2025 to December 2025), I can now witness that is really lot much better already, and in the next releases it will improve further more.

I would love to hear your thoughts, questions and critics on it.

How to deal with a slow API, a story in two parts.

Sheraz Manzoor — Sat, 02 Aug 2025 12:24:30 +0000

Why optimize when you can simply... shift the problem to someone else?

Understanding React's `use` API

Sheraz Manzoor — Fri, 21 Feb 2025 17:23:09 +0000

A Sneak Peek into React’s `use` API: Simplifying Async Data Fetching

React's use API is an experimental yet powerful feature designed to simplify asynchronous data fetching within components. Instead of juggling useEffect and state variables, use lets you directly await promises inside the render phase.

Why is `use` a Game-Changer?

✅ Eliminates unnecessary useEffect hooks

✅ Works seamlessly with Server Components

✅ Simplifies async operations for cleaner, more readable code

How Does it Work?

Here's a quick look at how use fetches data directly inside a component:

import { use } from "react";

async function fetchData() {
  const response = await fetch("https://jsonplaceholder.typicode.com/posts/1");
  return response.json();
}

export default function Post() {
  const data = use(fetchData());
  return (
    <div>
      <h2>{data.title}</h2>
      <p>{data.body}</p>
    </div>
  );
}

Is use Ready for Production?

⚠️ Not yet! The API is still experimental and currently works best with React Server Components. However, it shows great promise in simplifying data fetching workflows.

Read Full Blog →

🚀 Introducing My Personal Tech Blog: CodePanda.online 📝

Sheraz Manzoor — Sun, 16 Feb 2025 11:47:20 +0000

Hey everyone! 👋

I’m super excited to share that I’ve launched my personal blog website — CodePanda.online! It’s a space where I’ll be sharing my knowledge, experiences, and helpful tips for web developers and tech enthusiasts.

💻 What to Expect on CodePanda:

✅ Hands-on tutorials for JavaScript, TypeScript, React, Next.js, and more.
✅ Practical Tips & Tricks – Quick solutions to common coding challenges.
✅ Insights from real-world projects I’ve worked on.
✅ In-Depth Tutorials – Step-by-step guides on JavaScript, TypeScript, React, Next.js, and more.
✅ Snippets and solutions you can use in your own apps.

I created CodePanda to document my journey as a developer and help others by sharing what I learn along the way. Whether you're just starting out or already deep into your coding career, I hope my posts make your development life a little easier.

🔗 Check it out here: codepanda.online

I’d love for you to stop by, explore, and let me know what topics you’d like me to cover next! 🚀🔥

DEV Community: Sheraz Manzoor

Another Year in Production 🎂

How a smart Engineering Decision Reduced Our costs by 25% and is continuously reducing.

Let's store the map's data in our own database

Implementation (2 layers, 2 jobs)

Next Challenge (stored information becomes outdated)

Why Redis lives in one feature

The results: faster lookups, lower API spend

📉 25% LOWER GOOGLE MAPS COSTS — AND STILL FALLING

The broader lesson

DISCUSS

The Frog That Lived: Let's learn about falsification.

The Problem of Induction in Software Testing

Real world examples of falsification in Engineering

1. Google

2. Netflix

3. My personal experience (A case study worth reading)

Falsification in Practice: Property-Based Testing, Fuzzing, and Model Checking

Property-based testing: a frog hunter, not a frog counter

Model checking: search for the counterexample trace

Fuzzing: you only need one crash

Debugging is falsification, too

Why This Matters for Engineering Culture

Practical Takeaways

Charcole v2.3.0 is a BOMB 💣

Introduction

What is charcole??

Why Charcole exists?

You're Not a Coder Anymore. You're an Orchestrator. (And That's a Good Thing)

First, What Even Is an AI Agent?

The Old Workflow vs. The New Workflow

What This Means for Your Day-to-Day Work

1. Prompting is now a core skill

2. You review more than you write

3. Architecture decisions matter more, not less

A Practical Agentic Workflow You Can Steal

Step 1: Write a task spec, not just a ticket

Step 2: Run the agent with the spec

Step 3: Review the diff like a PR

The Pitfalls (Don't Skip This Section)

Pitfall 1: Trusting without reading

Pitfall 2: Scope creep in agent runs

Pitfall 3: Context rot in long sessions

Pitfall 4: Skipping security review

The Skills That Actually Matter in 2026

So, Are Developer Jobs Going Away?

Getting Started Today

Wrapping Up

Many of my followers liked this post and it got so much love. So sharing it again for the new folks out there,

Good Commit ✔ VS. Bad Commit ❌: Best Practices for Git

Coding is dead; Engineering is not.

Answer to the question.

The death of Coding

What coding was? And why it wasn't enough?

Why Engineering will always survive?

Here's my new blog post, I had been working and testing Nextjs 15 for two months and here's a summary of it.

What's new Nextjs in 15?

What's new Nextjs in 15?

React 19 RC Support

@next/codemode CLI

Turbopack Dev (Stable)

React Compiler (Experimental)

Hydration Error Improvements.

Caching Updates

Partial Prerendering (Experimental)

unstable_after API (Experimental)

How to deal with a slow API, a story in two parts.

Understanding React's `use` API

A Sneak Peek into React’s use API: Simplifying Async Data Fetching

Why is use a Game-Changer?

How Does it Work?

Is use Ready for Production?

🚀 Introducing My Personal Tech Blog: CodePanda.online 📝

💻 What to Expect on CodePanda:

`@next/codemode` CLI

`unstable_after` API (Experimental)

A Sneak Peek into React’s `use` API: Simplifying Async Data Fetching

Why is `use` a Game-Changer?