DEV Community: Muhammad Haseeb

API vs MCP: Understanding the Shift From Developer Tools to AI Agents

Muhammad Haseeb — Mon, 19 Jan 2026 10:58:06 +0000

If you have been building software for a while, APIs probably feel second nature. They power almost everything we do, from fetching data to connecting services and automating workflows.

That model starts to feel limiting once AI agents enter the picture. APIs were built for humans writing deterministic code, while MCP is designed for AI systems that need to understand tools, reason about options, and decide what to do next.

This post explores that shift in a practical way.

What APIs Are Optimized For

An API is a predefined contract. A developer reads documentation, understands the endpoints, and writes code that calls them.

A typical API driven flow looks like this:

Everything is explicit. The developer already knows what to call and when to call it. The intelligence lives in the application logic, not in the API itself.

APIs assume the caller already understands the system.

Why APIs Struggle With AI Agents

Now imagine the caller is not a developer, but an AI agent.

The agent does not naturally know:

Which endpoints exist
Which parameters are required
Which system should be called first

You can hardcode this knowledge into prompts or glue code, but that approach becomes fragile very quickly.

Every new integration needs custom logic
Every API change risks breaking the agent
Every workflow must be defined upfront

This is the gap MCP tries to fill.

What MCP Brings

MCP stands for Model Context Protocol.

Instead of exposing raw endpoints, MCP exposes capabilities in a structured and machine readable way. An AI model can ask:

What tools are available
What inputs do they expect
What output will I get

The key difference is simple.

APIs tell you how to call something.
MCP tells the model what is possible.

This allows AI systems to reason about tools instead of following rigid instructions.

A Practical Example

Imagine you are building an AI travel assistant.
The user says:

I want to travel next week but avoid bad weather.

With APIs

The workflow is predefined by a developer.

User Request ↓ Hardcoded Logic ↓ Weather API ↓ Flight API ↓ Hotel API ↓ Response

The AI is following a script. Adding a new service later means rewriting the flow.

With MCP

The MCP server exposes tools like:

Search flights
Book hotels
Check weather
Create calendar events

The AI decides the order dynamically.

User Request ↓ AI Reasoning ↓ Tool Discovery ↓ Check Weather ↓ Search Flights ↓ Suggest Hotels ↓ Response

Nothing is hardcoded. The AI chooses the path based on intent and context.

Why MCP Matters

APIs assume certainty.
AI works best with exploration and decision making.

MCP acts as a bridge between AI reasoning and real world systems. It does not replace APIs. It makes them usable by AI.

Think of APIs as building blocks.
Think of MCP as instructions written for machines.

When to Use What

Use APIs when

Performance and predictability matter
Workflows are fixed
Humans control the business logic

Use MCP when

You are building AI agents
Workflows need to adapt dynamically
Tools change frequently

Final Thoughts

This is not API versus MCP.
This is API and MCP working together.

APIs remain the foundation. MCP adds a layer that allows AI to use that foundation intelligently.

As AI agents become more common, understanding this distinction will matter not because MCP is trendy, but because it matches how AI actually works.

How Frontend Engineers Can Make AI Accessible: Building Intuitive Interfaces for AI-Powered Apps

Muhammad Haseeb — Mon, 24 Mar 2025 03:27:38 +0000

Introduction

As a Frontend Engineer, I’ve always been fascinated by how we can make complex technologies simple and accessible for users. But here’s the thing: AI is no longer just a backend marvel—it’s becoming a frontend responsibility. Think about it: tools like ChatGPT, AI-driven dashboards, and personalized recommendation systems are only as good as their interfaces. In this post, I’ll share actionable tips on how we, as frontend developers, can bridge the gap between AI and end-users through intuitive and engaging interfaces. Let’s dive in!

Why Frontend Matters in AI 🚀

AI is powerful, but its true potential is unlocked when users can interact with it seamlessly. Think about tools like ChatGPT, AI-driven dashboards, or personalized recommendation systems. The frontend is where users experience the magic of AI. As frontend engineers, our job is to make this experience smooth, intuitive, and delightful.

Key Challenges in AI-Powered Frontends

Complexity vs. Simplicity:
- AI models often produce complex outputs. Our challenge is to present these outputs in a way that’s easy to understand.
- Example: Instead of showing raw data, use visualizations like charts, graphs, or natural language summaries.
Real-Time Interactions:
- Many AI applications require real-time updates (e.g., chatbots, live recommendations). This means optimizing for performance and ensuring smooth user interactions.
- Tools like WebSockets or Server-Sent Events (SSE) can help here.
Handling Uncertainty:
- AI isn’t perfect. Sometimes it produces unexpected or incorrect results. As frontend developers, we need to design interfaces that handle these edge cases gracefully.
- Example: Provide fallback options or clear error messages when the AI fails.

Tips for Building AI-Powered Frontends

Leverage Modern Frameworks:
- Use frameworks like Vue.js, React, or Svelte to build dynamic, responsive interfaces that can handle real-time AI interactions.
Focus on UX:
- AI can feel intimidating to users. Use progressive disclosure—show only what’s necessary and reveal more details as the user interacts.
- Example: Start with a simple input field and gradually introduce advanced options.
Visualize AI Outputs:
- Turn raw AI data into something meaningful. Use libraries like D3.js or Chart.js to create interactive visualizations.
Test, Test, Test:
- AI behavior can be unpredictable. Test your frontend with different AI outputs to ensure it handles all scenarios gracefully.

Conclusion

AI is transforming the way we build applications, and as frontend engineers, we have a unique opportunity to shape how users interact with this technology. By focusing on simplicity, performance, and user experience, we can make AI accessible to everyone.

What’s your take on AI-powered frontends? Have you worked on any projects that combine AI and frontend development? Share your experiences or questions in the comments—I’d love to hear from you! 👇

Best Time to Refactor: Tips for Refactoring a Legacy Code Base

Muhammad Haseeb — Sun, 16 Jun 2024 11:31:05 +0000

As software engineers, we all know that refactoring is important for maintaining and improving code quality. However, its very common being lazy.

Imagine a scenario where, during a code review, someone identifies a code smell and suggests some changes. You might respond by saying there's no time for that now and that we'll add it to our technical debt backlog. Or perhaps you leave a few TODO comments instead of taking the time to write clean code. It’ll get done eventually, right?
No! In reality, these tasks rarely get completed once they’re consigned to the limbo of “to be done later.” There's always something more urgent than refactoring.

In this post, we'll explore some tips for deciding the best time to refactor and how to do it in a legacy codebase.

Best Time to Refactor

Refactoring is a continuous process that should be done throughout the development cycle. So, if I had to answer that in one word that would be NOW. Pretty explicit from the cover!

"Its always the best time to refactor"!

However, there are certain times when you will find the opportunity to do refactoring.

1. When Adding New Features

Adding new features to an existing code base can be a good opportunity to refactor. Refactoring before adding new features can help to reduce the technical debt and improve the overall quality of the codebase. It's easier to refactor before adding new features than after.

2. When Fixing Bugs

Fixing bugs can also be a good time to refactor. If a bug is caused by poorly written code, refactoring can help to prevent similar bugs from happening in the future. Refactoring while fixing bugs can also make the code easier to understand and maintain.

3. When Working on Code That's Already Being Touched

If you're already working on a specific section of the codebase and you feel a room for improvement, it can be a good opportunity to refactor that section as well. This can help to improve the quality of the codebase and reduce technical debt.

Refactoring in a Legacy Code Base

Refactoring in a legacy code base can be challenging. Legacy codebases are often large, complex, and poorly documented, making it difficult to understand the code's behavior and dependencies. Here are some tips for refactoring a legacy code base:

1. Understand the Code

Before you start refactoring, it's essential to understand the codebase's structure and behavior. This includes understanding how different components interact with each other, identifying areas of the codebase that are prone to errors, and determining the code's overall complexity.

2. Identify Code Smells

Identifying code smells is crucial for effective refactoring in a legacy codebase. Common code smells include duplicated code, long methods, and excessive nesting. Identifying these code smells can help you prioritize which sections of the codebase need to be refactored.

3. Start Small

Refactoring a legacy code base can be overwhelming, so it's essential to start small. Identify small sections of the codebase that can be refactored without impacting the rest of the codebase's behavior. Starting small can help you build momentum and reduce the risk of breaking the codebase.

4. Write Tests

Writing tests can have a significant impact on refactoring and it help you to ensure that your refactoring efforts don't introduce new bugs or break existing functionality. Tests can also serve as documentation for the codebase, making it easier to understand and maintain in the future.

5. Refactor Incrementally

Refactoring a legacy codebase can be a time-consuming process, so it's essential to do it incrementally. Refactor small sections of the codebase at a time, and make sure that the code still works as expected after each change.

Practical Example: Refactoring with Ag-Grid and Formik

In one of my projects, we used Ag-Grid for an enterprise application to display large amounts of data, hierarchies, and computations, making it highly customizable and extensible. We had numerous computations on the grids and were using Formik for managing the state of the grid as a form.

Working with a legacy codebase, we faced the need to incorporate enterprise features from newer versions of both Ag-Grid and Formik which had a lot of performance improvements. However, directly updating these libraries was not feasible due to significant breaking changes.

To address this challenge, we adopted an incremental approach:

1. Initial Setup: We installed the latest versions of Ag-Grid and Formik alongside the existing versions. This allowed us to experiment without disrupting the current functionality.

2. Starting Small: We began by updating a small, manageable section of the application. This section was chosen for its simplicity and minimal dependencies, reducing the risk of introducing errors.

3. Creating a Reference Implementation: Successfully updating this small section provided us with a reference implementation. This served as a guide for how to handle similar updates throughout the codebase.

4. Gradual Rollout: Using the reference implementation, we incrementally updated other sections of the application. This step-by-step approach minimized risks and allowed for continuous testing and verification.

5. Comprehensive Testing: Throughout the process, we ensured thorough testing at each stage. Writing and running tests helped us catch and fix issues early, maintaining the stability of the application.

This methodical and incremental strategy enabled us to modernize the codebase effectively. By breaking the task into smaller, manageable pieces, we were able to mitigate risks, ensure compatibility, and gradually leverage the new features offered by the updated libraries.

_
I would love to hear from you guys on the following:_

What's the most challenging refactoring you've tackled, and how did you approach it?
How do you prioritize refactoring in your development workflow?
What are your favorite refactoring techniques or tools, and why?
Have you ever faced resistance to refactoring within your team or organization? How did you overcome it?
How do you balance the trade-off between refactoring for maintainability and delivering new features quickly?

The UseEvent Hook

Muhammad Haseeb — Mon, 05 Sep 2022 08:58:18 +0000

This article needs prior understanding of Hooks. So, if you are not already familiar please checkout the official docs.

I came across this hook while reviewing a PR of one of my colleagues ciprian. One of my colleagues introduced a hook in his PR and we had a long healthy technical discussion around that as it was solving this issue.

Motivation for introducing useEvent

The React core team published a Request for Comment (RFC) for a new React hook: useEvent. This post attempts to capture what this hook is and how it works.

Also here is the proposal for useEvent hook and It hasn't been released yet (by the time I am writing this post) and its behavior could change.

The real problem

let’s wrap our heads around the problem before we jump into what useEvent is. React’s execution model is largely powered by comparing the current and previous values of state/props. This happens in components and in hooks like useEffect, useMemo, and useCallback.
Lets see this example to make better understanding of the problem.

Example

This onClick event handler needs to read the currently typed text:

function Chat() {
  const [text, setText] = useState('');

  // 🟡 Always a different function
  const onClick = () => {
    sendMessage(text);
  };

  return <SendButton onClick={onClick} />;
}

Let's say you want to optimize SendButton by wrapping it in React.memo. For this to work, the props need to be shallowly equal between re-renders. The onClick function will have a different function identity on every re-render, so it will break memoization.
The usual way to approach a problem like this is to wrap the function into useCallback hook to preserve the function identity. However, it wouldn't help in this case because onClick needs to read the latest text:

function Chat() {
  const [text, setText] = useState('');

  // 🟡 A different function whenever `text` changes
  const onClick = useCallback(() => {
    sendMessage(text);
  }, [text]);

  return <SendButton onClick={onClick} />;
}

The text changes with every keystroke, so onClick will still be a different function on every keystroke. (We can't remove text from the useCallback dependencies because otherwise the onClick handler would always "see" the initial text.

What's the solution

A new hook useEvent is being proposed to ensure we have a stable reference to a function without having to create a new function based on its dependents.

What is `useEvent` hook?

A Hook to define an event handler with an always-stable function identity.

By comparison, useEvent does not take a dependency array and always returns the same stable function, even if the text changes. Nevertheless, text inside useEvent will reflect its latest value:

function Chat() {
  const [text, setText] = useState('');

  // ✅ Always the same function (even if `text` changes)
  const onClick = useEvent(() => {
    sendMessage(text);
  });

  return <SendButton onClick={onClick} />;
}

As a result, memoizing SendButton will now work because its onClick prop will always receive the same function.

When to use useCallBack?

You must be curious about what would be the use-cases where useCallBack will be useful after we have the useEvent hook? I had the same question back then.

Well, useCallaback will be used for memoizing render functions. For example:

  const renderItem = useCallback(() => (
    <span>{itemName}</span>
  ), [itemName])

Why? because useEvent cannot be used for this scenario as it would keep the same reference for render function, and this is not desired, because we need a changing ref so that we know when to rerender.

Event handlers wrapped in useEvent will throw if called during render. (Calling it from an effect or at any other time is fine.) So it is enforced that during rendering these functions are treated as opaque and never called. This makes it safe to preserve their identity despite the changing props/state inside.

You can see many more evidences on that issue and RFC itself, I am not listing those here to keep this post concise. Overall, I think this is going to be a great addition to the React ecosystem.

Here is what my colleague did to mock the same behavior that useEvent would probably be doing soon.

export default function useEventCallback<Args extends unknown[], Return>(
  fn: (...args: Args) => Return,
): (...args: Args) => Return {
  // ref is not initialized, in order to ensure that we can't call this in the render phase
  // ref.current will be undefined if we call the `fn` during render phase (as a render function)
  const ref = useRef<(typeof fn) | undefined>(undefined);

  useLayoutEffect(() => {
    ref.current = fn;
  });

  return useCallback(
    (...args: Args) =>
    // make sure that the value of `this` provided for the call to fn is not `ref`
      ref.current.apply(void 0, args),
    [],
  );
}

Hit the ❤️ if it was useful. Please share your feedback so I can make my blog posts more helpful. 😊

Avoid ignoring react-hooks/exhaustive-deps linting warnings

Muhammad Haseeb — Tue, 09 Aug 2022 19:08:00 +0000

This post is inspired by the conversation on this github issue which was shared by a colleague in one of our technical meeting. There are so many other cases discussed here so its worth reading.

Rationale

While working with a react hook, you must have been in a situation when you get this linting warning react-hooks/exhaustive-deps. You try to add the dependency to the array and may ended up in an infinite loop or any unexpected behavior;

For example:

You have a state count in your component and you want to increment it only once. Most likely you will write in this way.

  useEffect(() => {
    setCount(count + 1);     
  }, []);

This will give you a warning that React Hook useEffect has a missing dependency: 'count'. Either include it or remove the dependency array

You have an easy exit: that is to ignore the error by disabling the rule;

// eslint-disable-next-line

useEffect(() => {
  setCount(count + 1);
  // eslint-disable-next-line
}, []);

**It worked - Great job!!! 👏** But wait;

The design of useEffect forces you to confront it. You can of course work around it, but the default is to nudge you to handle these cases. Instead of disabling these warnings, I've found it worth finding a way to accommodate the dependency array requirements.

In most situations its practically possible and I will talk about some very common use-cases here.

For state dependencies

In the preceding example, you can get rid of that warning using a callback in your setCount method because count will no longer be a dependency 😊

useEffect(() => {
  setCount((count) => count + 1);
}, []);

Another drawback off adding // eslint-disable-next-line could be that it will not warn you about future dependencies. i.e If you made some changes in that hook which has a dependency but you forgot to add it in the dependency array, you will not get a warning now as you already have disabled that. This could lead to unexpected behavior and even break your app.

For function dependencies

When you use any function in the useEffect hook.
Let’s consider you have a function that uses name as argument and does something. You will get an es-lint warning for not adding the function in the dependency array.

const functionName = (name) => {
  // do something
};

useEffect(() => {
  functionName(name);
}, [name]);

But, even adding it directly to the dependency wont fix it and you will get another warning that you have just caused an infinite loop because someFunction has a different reference on each render. So whats the fix?

The solution here is likely to wrap that function in a useCallback hook because useCallBack will return a memoized callback. It makes certain that the function doesn’t change references between renders.

const functionName = useCallback((name) => {
  // do something with count
}, []);

useEffect(() => {
  functionName(name);
}, [name, functionName]);

PS:

As per official useCallBack docs make sure that every value referenced inside the callback should also appear in the dependencies array.

Here is another use-case I saw on the same github issue related to useCallBack, where a user will add an email and invite those email to the app. It potentially fix the deps into [emails, props]. Whereas, actually it needs to update the function reference only when onSubmit change and not any other prop.

const handleSubmit = React.useCallback(
  () => {
    props.onSubmit(emails);
  },
  [emails, props]
);

This is because technically props.onSubmit() passes props itself as this to onSubmit call. So onSubmit might implicitly depend on props and the best practice is always de-structuring.

Valid-Case

I also want to talk about one of the legitimate cases that I found on the same thread, where you may have to disable extraneous dependency warning

useEffect(() => {
    window.scrollTo(0, 0);
  }, [activeTab]);

Summary

Its very common to disable/ignore react-hooks/exhaustive-deps linting warnings in most cases. Probably you actually want to fire the hook when the dependency changes. It might not seem like it at first, but there are probably some edge cases for which your effect logic will fail if you don’t include the variable in the dependency array. So, you should try to fulfill react hook dependency requirements with given ways instead disabling.

Hit the ❤️ if it was helpful and you learn something new

Do we even need if/else?

Muhammad Haseeb — Tue, 07 Dec 2021 05:58:08 +0000

Flow control is one of the first things we all learn as programmers.
We are going to learn about some of the alternatives we have, that from my point of view are generally more cleaner and safer.

Lets take a simple example to start with;

if/Ternary

const isWeekend = (day) => {
  let message;
  if (day === 'sunday') {
      message = "Its a weekend";
  }
  return message;
};

We have a function isWeekend which takes a dayand returns if its a weekend or not. Now this has an issue, but JavaScript itself doesn't give us any kind of error. We didn't return any message if its not sunday. So we can do something like this or add an else block:

const isWeekend = (day) => {
  let message = 'Its a working day :(';
  if (day === 'sunday') {
      message = "Its a weekend";
  }
  return message;
};

Now, as As the title says, do we even need if for this simple conditional block? No, we can use a ternary instead.
So we can update our function isWeekend like this:

const isWeekend = (day) =>
  day === "sunday" ? "Its a weekend" : "Its a working day :(";

// or

const isWeekend = (day) =>
  'Its a ${ day === "sunday" ? "weekend" : "working day :(" }';

Advantages of ternaries over ifs:

It forces to cover both if and else case.
Less code footprints.
More readable.
Another big advantage is that we can initialize a constant based on condition i.e.

const a = condition? 'value1' : 'value2';

We cannot achieve this using if else and will have to use let instead of const.

if/Switch

But what if we have to cover multiple conditions. Instead of using multiple ifs we should use the switch statement. Let take the same example, this time we need to have a condition for all the possible days i.e.

// multiple case switch program
  switch (day) {
    case "monday":
    case "tuesday":
    case "wednesday":
    case "thursday":
    case "friday":
      return "Its a working day :(";
      break;
    case "saturday":
    case "sunday":
      return "Its a weekend";
      break;
    default:
      return "thats not even a day";
      break;
  }

Plain Objects and the ??

We can even use plain objects and the nullish operator.

const daysMap = (day) =>
  ({
    "monday": "Its a working day :(",
    "tueday": "Its a working day :(",
    "wednesday": "Its a working day :(",
    "thursday": "Its a working day :(",
    "friday": "Its a working day :(",
    "saturday": "its a weekend",
    "sunday": "its a weekend",
  }[day] ?? "thats not even a day");

const isWeekend = ( day ) => daysMap(day);

Those who are not familiar with the ?? operator, it checks either it has a value or nullish (null or undefined). If day is nullish, then we use defaultValue, it not, use the value itself.

Conclusion:

There might be some cases where we have to use if/else. But, in my opinion, we can use the alternatives in most cases.

Any thought??

#coding #softwareengineering #productivity #cleancode #codingtips #javascript #webdev #devlife #programming #computerscience

How to reuse component's props in TypeScript

Muhammad Haseeb — Mon, 29 Nov 2021 13:37:26 +0000

We often find ourself defining types for the props that are not actually part of that component and are used in some other component.

Lets take a simple example:
Suppose we have a Parent and a Child component with following props.

import React from 'react';
import { Child } from './Child';

type Props = {
  greeting: string;
  firstName: string;
  lastName: string;
};

export const Parent: React.FC<Props> = ({ greeting, firstName, lastName }) => {
  return (
    <>
      <span> {greeting}</span>
      <Child firstName={firstName} lastName={lastName} />
    </>
  );
};

import React from 'react';

type Props = {
  firstName: string;
  lastName: string;
};

export const Child: React.FC<Props> = ({ firstName, lastName }) => {
  return (
    <>
      <div>{firstName}</div>
      <div>{lastName}</div>
    </>
  );
};

⚠️ Problem Statement:

Repetitive Props

Type for firstName and lastName are also defined in Parent because it needs to be passed down to the Child component.

Code Sync issues

If one part changes we need to make sure the others stays in sync.
If the Child component is used in a similar pattern elsewhere we need to make sure we update the props there too.

💡 Solution:

We can use ComponentProps to extract the Props directly form the component's type and use rest and spread syntax to avoid repetition.

import React, { ComponentProps } from 'react';
import { Child } from './Child';

type Props = ComponentProps<typeof Child> & {
  greeting: string;
};

export const Parent: React.FC<Props> = ({ greeting, ...childProps }) => {
  return (
    <>
      <span> {greeting}</span>
      <Child {...childProps} />
    </>
  );
};

Benefits:

Creating the parent's props by merging them with it's child's solves the code sync issues.
Makes a unique source of truth.

PS: If you only need some of the props in the Child component, you can use Partials.

#coding #softwareengineering #productivity #webdeveloper #cleancode #codingtips #javascript #webdev #devlife #programming #computerscience