DEV Community: Ahmed Mahmoud

Building AI-Native Frontends with Claude Code and MCP

Ahmed Mahmoud — Sun, 28 Jun 2026 00:07:08 +0000

Headline: The wins come from context, not cleverness. An AI with your codebase, your design system, and your deploy logs in scope writes code that ships. Without that scope, it writes plausible code that doesn't.

Two years ago, AI coding tools were autocomplete with attitude. In 2026 they are a credible second engineer — provided you build the workflow around them. This is the workflow I run today at Devya Solutions and on personal projects like eng-ahmed.com.

The Stack

Claude Code in the terminal — long-horizon, multi-file edits with skills and subagents.
MCP (Model Context Protocol) servers for live access to docs, deployments, browser, and design tools.
Cursor or VS Code for inline edits when I want to stay in the IDE.

Why Context Is Everything

The single highest-leverage move in AI-assisted dev is feeding the model the right context. MCP servers do this without prompt stuffing.

Docs MCP — pulls current library docs at call time, so the model doesn't hallucinate the Tailwind v3 API in a v4 codebase.
Browser MCP (Claude-in-Chrome) — lets the agent open the running dev server, screenshot the page, and verify the change actually rendered.
Vercel MCP — fetches deploy logs and runtime errors directly. No more pasting logs.
Context-mode MCP — keeps file scans, search results, and command output in a sandbox, only surfacing what's relevant to your conversation.

A Real Workflow

The blog page redesign I just shipped was built in a single 45-minute session. Rough flow:

State the goal — two sentences, not a spec doc.
Let the agent scout — Claude Code greps, reads a few files, proposes a plan.
Iterate visually — screenshot the result, feed it back. The agent fixes the sticky-filter scroll bug in one turn.
Commit and push — a single cm shortcut runs build, commits, and pushes. Vercel deploys on push.

What the Agent Is Still Bad At

Holistic taste — it copies the closest example in your codebase. If that's mediocre, the new feature is mediocre.
Domain knowledge — it doesn't know your billing logic has a 30-day grace period. You have to write that down.
Knowing when to push back — it implements bad ideas efficiently. Saying "no, the user actually needs X" is still your job.

Design-System Discipline

The single biggest quality multiplier: a strict design system. Every token, every component name, every spacing scale documented. AI writes much better code against a clear system than against a sprawl of one-off styles.

Security & Trust

I never let the agent push to production without human review, and I scope its permissions tightly. AI accelerates whatever discipline you already have — including bad discipline.

Closing

The "10× engineer" cliché finally has a literal interpretation: a competent engineer with a well-instrumented AI partner ships materially more than they did in 2024. The differentiator is no longer typing speed; it's the quality of the workflow you build around the model.

I document my workflows publicly on eng-ahmed.com. To work with my team on AI-native product builds, reach out via Devya Solutions.

Signals vs React Compiler: The Fine-Grained Reactivity Showdown

Ahmed Mahmoud — Sun, 28 Jun 2026 00:05:23 +0000

Headline: Signals win on raw performance and mental clarity. React Compiler wins on ecosystem leverage and migration cost. For a greenfield app, signals are tempting; for a real product, ecosystem still wins.

For a decade the frontend community has chased the same goal: minimize unnecessary work. In 2026, two distinct answers reached production maturity at the same time — signals (Solid, Vue 4, Angular 20, Svelte 5) and the React Compiler. They solve the same problem from opposite directions.

The Problem Both Solve

The classic React mental model re-renders entire component trees when state changes, then relies on the developer to remember memo, useMemo, and useCallback to avoid waste. Most teams get this wrong in subtle ways and pay an interactivity tax — the INP score most apps fail.

Signals: Track at the Value Level

Signals are observable values. A component subscribes by reading the signal; when the signal changes, only that subscription re-runs. There is no virtual DOM diff for the unchanged parts.

// SolidJS
const [count, setCount] = createSignal(0);
<button onClick={() => setCount(c => c + 1)}>
  {count()} {/* only this text node updates */}
</button>

Smaller runtimes, fewer hydration mismatches, and an authoring model where "what re-renders" is something you can read off the page rather than guess at.

React Compiler: Memoize Automatically

React's bet is different. Instead of changing the runtime, change what the developer writes. The compiler analyzes your component, identifies stable values, and inserts memoization at build time. You delete every useMemo you ever wrote.

function Cart({ items }) {
  const total = items.reduce((s, i) => s + i.price, 0);
  return <Total amount={total} />;
}

The compiler caches total across renders when items is referentially stable.

Head to Head

On a synthetic counter benchmark, Solid is roughly 3× faster than React + Compiler. On a realistic 200-component dashboard rerender, the gap shrinks to ~1.4×. On a real product (the kind we ship at Devya Solutions), the gap was negligible after accounting for network and database latency.

The Ecosystem Cost

Signals require you to leave the React ecosystem. That means re-evaluating routing, data fetching, charts, design system, error monitoring, and the LLM coding assistant your team uses. Most LLMs in 2026 generate React idioms by default — the "invisible teammate" effect is real and meaningful.

Practical Advice

Greenfield, performance-critical, small team → Solid or Svelte 5
Greenfield, product velocity matters → React + Compiler
Existing React app → adopt the React Compiler this quarter. Free wins, no migration.
Want signal semantics inside React → look at @preact/signals-react for opt-in fine-grained state.

Closing Thought

The signals camp won the architectural argument; React won the distribution argument. In 2026, both are valid choices — and the right one depends more on team and tooling than on benchmarks.

For more frontend architecture writing, visit eng-ahmed.com or follow what we're building at Devya Solutions.

React Server Components in Production: Lessons from 2026

Ahmed Mahmoud — Sun, 28 Jun 2026 00:03:20 +0000

Headline: RSC is a serious win for bundle size and TTFB, but only if your team commits to the new mental model. Half-adoption is worse than not adopting at all.

What Actually Changed

RSC moves rendering of components that don't need interactivity to the server. The browser receives a serialized tree, not a JavaScript bundle. The result on a real e-commerce surface we migrated at Devya Solutions:

−42% client JS on the product listing page
−180ms TTFB after enabling streaming
+0.08 INP regression on a poorly-split page (we'll come back to this)

The Three Component Types You Actually Use

Server Components — fetch, render, never ship JS. Default for everything.
Client Components ("use client") — for interactivity, hooks, browser APIs.
Shared Components — pure presentation, work in both. Sweet spot for design systems.

The pitfall: every "use client" directive is a bundle entry point. One careless chart-library import pulls 80KB into every page.

Data Fetching Patterns That Survived

async function ProductList({ category }) {
  const products = await db.products.findMany({ where: { category } });
  return products.map(p => <ProductCard product={p} />);
}

We deleted ~3,000 lines of React Query setup.

Server Actions for Mutations

'use server';
export async function addToCart(formData: FormData) {
  const productId = formData.get('productId');
  await db.cart.add({ productId });
  revalidatePath('/cart');
}

What Still Hurts

Error boundaries — server-thrown errors surface as opaque digests in production
Third-party clients — anything that touches window needs a Client Component wrapper
Caching mental model — Next.js 15 made caching explicit, but the layers still confuse new hires

The INP Regression — And the Fix

Smaller JS doesn't automatically mean snappier interaction. Our regression: a deeply nested Client Component tree hydrated late. Fix: hoist the interactive island higher, pass server data as a prop.

Should You Adopt RSC?

Yes for new Next.js apps. For existing Pages Router apps, migrate route-by-route, not big-bang.

I write more production React patterns on eng-ahmed.com and ship them through Devya Solutions.

⛓️Scoping in JavaScript

Ahmed Mahmoud — Fri, 24 Feb 2023 22:12:58 +0000

Understanding scope is key for writing organized and effective code. In this blog post, we'll check out how scoping works in JavaScript and how it can help you, So first lets take a look at the difference between free and bound variables…

Free vs. Bound variables

Variables declared outside of functions have global scope and are accessible from anywhere in the code, while variables declared within functions have local scope and are only accessible within that function.

A free variable is a variable that is used within a function, but is not declared within that function nor passed to it as a parameter. It is either declared in the global scope or in an outer function's scope.

A bound variable, on the other hand, is a variable that is declared within a function and is only accessible within that function.

Here's an example to illustrate this:

let x = 10; // Global scope

function foo() {
  console.log(x); // Free variable
}

function bar() {
  let y = 20; // Bound variable
  foo();
}

bar();

In this example, x is a free variable because it is used within the foo function, but it is not declared within the foo function. It is declared in the global scope.

y is a bound variable because it is declared within the bar function and is only accessible within that function.

Another Example:

function fun() {
    let a = "a"
    function innerfun(){
         a = "b" //Free variable
    }
    innerfun();
    console.log(a); //b
}
fun()

variable a is accessible by the inner function though the change reflect on outer

function fun() {
    let a = "a"
    function innerfun(){
        let a = "b" //Bound variable
    }
    innerfun();
    console.log(a); //a
}

this inner variable a only exists within the scope of the inner function, and has no effect on the variable a in the outer function.

Dynamic vs. Static Scoping

Now lets discover the difference between dynamic scoping and static/lexical scoping…

The concept of dynamic and static scoping is determined by the design of the programming language, not by the runtime or execution time.

Static/lexical Scoping

In static scoping (also known as lexical scoping), the scope of a variable is determined at compile time (interpretation time in JavaScript) based on the location of the variable declaration in the code. In other words, the scope of a variable is determined by the blocks of code in which it is defined and can be referenced.

Dynamic Scoping

In dynamic scoping, the scope of a variable is determined at runtime based on the call stack. In other words, the scope of a variable is determined by the sequence of function calls that led to the current point of execution.

For Example:

// Dynamic vs. Static scoping example
function foo() {
  console.log(a);
}

function bar() {
  let a = "b";
  foo();
}

let a = "a";
bar();

// Output in dynamic scoping: "b"
// Output in lexical scoping: "a" <== Output

Also here:

// Dynamic vs. Static scoping example
function foo() {
  console.log(a);
}

function bar() {
    a = "b"; //Reference for a in global scope
  foo();
}

let a = "a";
bar();

// Output in dynamic scoping: "b" 
// Output in lexical scoping: "b" <== Output

In the previous example the Output in the previous example is b that’s because bar function has access to variable a in the global scope as it carries a reference to it in its local scope not because of JavaScript using dynamic scoping.

JavaScript Scoping

JavaScript uses lexical scoping, meaning that the scope of a variable is determined by the location of the variable declaration in the code, not by the runtime environment.

This means that variables in JavaScript are statically scoped and that the scope of a variable is determined at the time the code is written, not at the time it is executed (from within the call-frame / execution context).

But don’t confuse this with the concept of inner function getting the variable value from the outer function for example:

function bar() { //Outer
  let a = "b";
  function foo() { //Inner
      console.log(a);
  }
  foo();
}

let a = "a";
bar();

//Output because of closures: "b"

Although the behavior is similar to dynamic scoping (not the same) due to the existence of closures in JavaScript output in the previous example will be b (I will make a full separate post on closures)

Scopes in JavaScript

there are three main scopes in JS

Global Scope

In JavaScript, global scope is for variables and functions that are accessible everywhere in the code. These variables are declared outside of any function and can be used all over.

Local Scope

Local scope, also known as function scope, is for variables and functions that are only accessible within a certain function. This is handy for creating functions you can use again and again.

Block Scope

Block scope, which was introduced in the ES6 version of JavaScript, is for variables or functions that are only available within a certain block of code, like an if statement or a for loop. This is a great way to keep your variables neat and tidy, to ensure your variables are block scoped always declare them with let and const keywords.

Scoping concepts

those are concepts that are thought to be actual scopes but they are not…

Script Scope

Script scope is not a real scope, but it's a term that's used to refer to the scope of the whole script file. This means that anything declared outside of a function is accessible to the entire script, regardless of which function the code is in, you can think of it as an extension for the global scope that is specific to let and const declared variables.

Lexical Scope / Closure Scope

Lexical scope is not an actual scope, but it's a concept used to refer to the way that JavaScript looks for variables in the code. It looks for variables in the local scope first and, if it can't find them, it looks for them in the global scope. This helps to identify which variables are accessible where and helps to keep code organized.

you can find amazing animated illustrations on Lydia Hallie post about scoop chaining
here is a link to check out her post:

⚡️⛓JavaScript Visualized: Scope (Chain)

Closures

Closures are a concept in JavaScript that involve a function accessing an outer function's variables and functions. Closures allow developers to create private variables that can only be accessed within the function, which is a great way to keep code organized and efficient. Closures are not a scope, but they provide some of the same benefits that scope can provide.

(I will talk more in detail about closures in a full separate post)

Conclusion

To wrap it up, scope is an essential concept in JavaScript and understanding how it works can make your code run more smoothly and stay organized. Whether you're using global, local, or block scope, it's important to keep your variables in order. With a bit of practice and knowledge, you can use scope to your benefit.