DEV Community: Asmaa Almadhoun

AI Writes What You Ask. Architecture Survives What You Didn’t Expect

Asmaa Almadhoun — Sat, 11 Apr 2026 08:35:33 +0000

Why Human Judgment Still Matters in the Age of AI‑Assisted Development

AI‑assisted coding tools have transformed modern software development. They can generate boilerplate, suggest patterns, and accelerate delivery.

Yet, as powerful as these tools are, they often fail in one critical dimension: design judgment. Being “smarter than AI” as a developer does not mean writing more complex code, it means designing systems that are resilient to ambiguity, change, and imperfect inputs.

One of the most common and painful examples of this gap appears in how systems handle unexpected variations, such as null, undefined, empty values, or missing parameters.

The Illusion of Correctness in AI‑Generated Code

AI tools typically optimize for expected behavior. They assume ideal inputs, clear contracts, and happy paths. This makes their output appear correct; until reality intervenes.

Consider your example:

If I do not send exactly null, the system crashes.

From a machine’s perspective, this may be “technically correct” code. From a human architect’s perspective, it is a design failure.

A well‑designed system should not collapse because:

null was replaced with undefined
a field was omitted
an empty string was passed
a client behaved slightly differently than expected

AI‑assisted implementations often miss these nuances because they replicate patterns rather than challenge assumptions.

Clean Architecture: Designing for Reality, Not Perfection

Robert C. Martin’s Clean Architecture: A Craftsman’s Guide to Software Structure and Design emphasizes an essential truth:

Software must be designed to survive change.

Clean Architecture teaches that systems should be:

Independent of frameworks
Independent of UI
Independent of databases
Independent of external agencies

Most importantly for your case, they should be independent of volatile input behaviour.

Why This Matters for Input Validation

In Clean Architecture, use cases define the rules of the application. That means they are responsible for deciding what is valid, acceptable, or recoverable, not controllers, not frameworks, and certainly not AI‑generated glue code.

If your system crashes because a parameter is missing or slightly different, that logic is living in the wrong place, or not living anywhere at all.

The Core Problem: Treating Inputs as Objects, Not Concepts

AI tends to treat input values literally:

null ≠ undefined ≠ empty ≠ missing

Humans, however, think conceptually:

“This value means ‘no data provided.’”

Clean Architecture encourages us to elevate that intent into the core of the system. Instead of spreading defensive checks everywhere, we define semantic boundaries:

What does “absence” mean?
Is this field required, optional, or conditional?
What is the default behavior if it’s missing?

If those questions are not answered explicitly, AI has no chance of answering them correctly.

Being Smarter Than AI: Design Principles That Matter

1. Normalize at the Boundaries

AI often mirrors whatever structure it sees. A human architect knows better.
At system boundaries (APIs, controllers, adapters), normalize inputs into a single internal representation. By the time data reaches your business rules, there should be one concept of “no value,” not five.

This aligns directly with Clean Architecture’s rule of keeping frameworks and details at the edges.

2. Move Validation into Use Cases

AI‑generated code frequently validates inputs close to the framework layer. This is convenient and wrong.
Clean Architecture insists that:

Business rules own validation
Use cases decide what is acceptable
Frameworks merely pass data along

When validation lives in use cases, handling null, missing, or empty values becomes a business decision, not a technical accident.

3. Define Explicit Contracts, Not Implicit Expectations

AI excels at following patterns, but struggles with unstated intent.
Clean Architecture favors:

Explicit input models
Clear invariants
Defined failure modes

If your system crashes when a value is not exactly null, it means the contract was never truly defined, only assumed.
Humans write contracts. AI follows them.

4. Design for Change, Not Compliance

AI optimizes for compliance with existing code. Humans optimize for change.
Your API may work today because clients send perfect inputs. Tomorrow:

a mobile app changes
a third‑party integration behaves differently
a serialization library updates its defaults

Clean Architecture prepares systems for that variability by isolating change and enforcing rules at the core.

Conclusion: Intelligence Is in the Architecture, being smarter than AI is not about rejecting AI tools, it’s about using them responsibly.
Let AI:

write repetitive code
scaffold structures
speed up implementation

Let humans:

efine boundaries
clarify intent
design for ambiguity
enforce architectural discipline

Clean Architecture provides the mental model that AI lacks: a focus on meaning, responsibility, and change. When your system gracefully handles null, undefined, empty, and missing values, not because of defensive hacks, but because of intentional design you are operating at a level AI has not yet reached.
And that is what real software craftsmanship looks like.

Reference

Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017.

Why fetch() Can Be Safer Than Axios After the 2026 Axios Hack

Asmaa Almadhoun — Wed, 01 Apr 2026 09:16:10 +0000

The question isn’t whether Axios is a “bad” library; it’s about risk surface. The Axios NPM compromise in March 2026 exposed a structural weakness in depending on third‑party libraries for something browsers already provide natively.

1. Axios was compromised; fetch() cannot be published with malware

On March 31, 2026, attackers hijacked the npm account of Axios’s maintainer and published malicious versions (1.14.1 and 0.30.4) containing an obfuscated malware dropper. The malware executed automatically during installation.

In contrast:

fetch() is built into browsers and Node.js.
It cannot be replaced or hijacked via a package manager.
There is no installation step, so no opportunity to insert post‑install malware.

Thus, fetch() has zero supply‑chain risk compared to a package like Axios.

2. Axios’ supply-chain attack vector came from its dependency distribution model
The Axios compromise happened because:

Attackers accessed the maintainer’s npm account,
Published malicious releases with a hidden dependency (plain-crypto-js),
Inserted a postinstall script that deployed a cross‑platform RAT.

fetch() has:

No dependencies
No maintainer accounts to hijack
No GitHub or npm supply chain to poison

Therefore, using fetch() eliminates an entire attack surface.

3. Axios introduced malware even though the code looked unchanged
Security investigators confirmed the attacker did not modify the Axios code directly, but only added a malicious dependency that executed during installation.

This means:

Even if you audited the Axios GitHub repo, you would not see the malicious code.
This type of attack is impossible with fetch() because it isn’t installed from npm.

4. Native fetch() is now fully supported and feature‑rich, reducing the need for Axios
Historically, Axios offered conveniences like:

automatic JSON transformation
request cancellation
simpler syntax
better error handling

But today:

Modern browsers and Node.js now support fetch() with AbortController, streaming, improved error handling, and Response.json().
The gap between Axios and native APIs has narrowed significantly.

Given this parity, adding Axios creates unnecessary dependency risk.

✔️ Summary

Fetch is “better” than Axios from a security standpoint because it is native, dependency‑free, cannot be hijacked through npm, and avoids the entire supply‑chain attack vector that enabled hackers to insert a remote‑access trojan into Axios’ malicious releases in March 2026

Code Meets Creativity: Using Google Stitch as a Frontend Developer

Asmaa Almadhoun — Tue, 24 Mar 2026 07:11:19 +0000

As frontend developers, we’re constantly exploring tools that help us move faster, from ideation to prototypes to production‑ready UI. Google Stitch has recently had a major revamp, positioning itself as an AI‑native design assistant that promises to help us explore layouts, generate UI structures, and test ideas without jumping into code immediately.
While Stitch isn’t a full replacement for real design tools or real designers, it can play a meaningful role in a modern frontend workflow. Here’s how you can practically use it as a developer.

Example: Creating a Landing Page With Google Stitch

Move from idea → layout → code in minutes. Below is a simple, practical workflow showing how you can generate a landing page using Stitch, refine it, and turn it into usable frontend code.
Each step includes a soft, rounded hybrid-style diagram to visually guide the user.

1️⃣ Step 1, Open Google Stitch
To begin, you visit Stitch and select your mode (Web or App).
This is where you pick the model and start your design session.

2️⃣ Step 2, Enter Your First Prompt
Stitch works best with clear natural‑language instructions. You describe the structure and feel of the landing page, and Stitch generates the UI.
Example prompt:

“Create a modern landing page with a hero section, feature grid, testimonials, and a CTA. Keep it clean and easy to rebuild using React + Tailwind.”

3️⃣ Step 3, Stitch Generates the Layout
Stitch analyzes your prompt and files, then produces the first version of your layout.
It typically includes full sections like the following

4️⃣ Step 4, Refine Using Follow‑Up Prompts
Just like a conversation, you can refine the design by telling Stitch what to change.
This is ideal for adjusting spacing, layout balance, color contrast, and visual hierarchy.
Examples:

“Increase spacing in the hero section.”
“Make the color palette darker.”
“Increase CTA visibility.”

5️⃣ Step 5, Export the Code

One of Stitch’s strengths is its code export ability.
After generating your design, you can extract HTML/CSS or even React‑friendly markup to speed up your build, you will find

Landing page (html)
Design file contains rules
Screen file is full Image of your landing page design

6️⃣ Step 6, Paste Into Your Code Editor
Paste the exported code into your editor (VS Code, WebStorm, etc.).
From here, you refine the structure, add Tailwind or your design tokens, and integrate real content.

🎉 Final Thoughts
Using Google Stitch as a frontend developer dramatically accelerates:

UI ideation
Layout prototyping
Early‑stage design exploration
Hand‑off between design & code
Building real landing page code faster

Stitch doesn’t replace designers or developers, but it makes frontend workflows smoother and faster, especially when you need structure before styling.

Tailwind in Micro‑Frontends

Asmaa Almadhoun — Fri, 13 Mar 2026 07:24:12 +0000

From Token Drift to a Single Source of Truth

1) Context & Problem

When you scale a Module Federation architecture (shell + multiple independently deployed micro apps), it’s tempting to let every micro app own its Tailwind config. That seems harmless until it isn’t.
Signs you likely saw:

Token drift: primary, secondary, and other design tokens differ per micro app.
Inconsistent UI: The shell and remotes looked related but not identical.
Copy‑paste debt: Colors, shadows, and breakpoints duplicated across repos.
Refactor pain: Changing a brand variable meant N pull requests.
Conflicting semantics: primary in one app wasn’t the same hex in another.

Root causes:

Each repo has its own “design system.”
No enforced tokens contract shared at build time and runtime.
Different teams tweaked Tailwind locally, with no common presence.
Pre-flight, prefixes, and naming were sometimes inconsistent.

Result:

Slower brand rollouts, visual inconsistencies, and higher QA costs.

2) Design Goals
To reverse the drift without killing micro‑app independence:

Single Source of Truth (SSOT) for tokens, colors, typography, spacing, shadows, breakpoints.
One Tailwind prepared for every micro app import, no duplication.
Runtime theming via CSS variables (dark mode, brand variants) controlled by the shell.
Module Federation‑friendly: shared version of the tokens package, and predictable CSS load order.
Minimal migration friction: Keep class names like text-primary, bg-colors, etc.

3) Target Architecture (High‑Level)

@org/tokens (npm package)

tokens.css → CSS variables for runtime theming.
tailwind.preset.cjs → Tailwind preset mapping semantic keys (colors, shadows, screens).
Optional: boxShadow, spacing, fontFamily, etc.

Shell (host)

Loads tokens.css once and sets theme attributes (e.g., data-theme="dark").
Shares @org/tokens in Module Federation to keep a single version.
Enables Tailwind preflight once (recommended) and optionally a class prefix for safety.

Remote micro apps

Import the Tailwind preset from @org/tokens.
Rely on shell‑injected tokens.css (or import defensively if shell can’t).
Use semantic classes (e.g., text-primary, bg-bg, shadow-card) that are all defined from tokens.

4) The Tokens Package

4.1 Minimal tokens.css (runtime variables & themes)

/* packages/tokens/tokens.css */color-bg: #FFF5F0;
}

/* Optional dark theme (shell can toggle) */
:root[data-theme="dark"] {
  --color-text: #F3F4F6;
  --color-bg: #0B1220;
}
``
:root {
  --color-primary: #4A90E2;
  --color-text: #1F2A37;

4.2 Minimal Tailwind preset (map variables → Tailwind theme)

// packages/tokens/tailwind.preset.cjs
/** @type {import('tailwindcss').Config} */
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: 'var(--color-primary)',
        text: 'var(--color-text)',
        bg: 'var(--color-bg)',
      },
    },
  },
};

5) Remote Micro App, Smallest Possible Integration

5.1 Federation config (Remote)

// apps/appA/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
const deps = require('./package.json').dependencies;

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'appA',
      filename: 'remoteEntry.js',
      exposes: {
        './Widget': './src/Widget', // whatever you expose
      },
      shared: {
        react: { singleton: true, requiredVersion: deps.react },
        'react-dom': { singleton: true, requiredVersion: deps['react-dom'] },

        // 🔑 Same tokens instance/version as shell
        '@org/tokens': { singleton: true, eager: true },
      },
    }),
  ],
};

5.2 Tailwind config (Remote)

// apps/appA/tailwind.config.cjs
const { preset } = require('@org/tokens');

module.exports = {
  presets: [preset],                    // 🔑 central config
  content: ['./src/**/*.{ts,tsx,html}'],
  prefix: 'tw-',                        // match shell if you prefix
  corePlugins: { preflight: false },    // let shell handle the reset
};
``
export default function Card() {
  return (
    <div className="tw-bg-bg tw-text-text tw-rounded-xl tw-p-4 tw-border tw-border-primary">

If you’re not 100% sure the shell always loads tokens.css, you can optionally import it in the remote entry as a fallback:

import '@org/tokens/tokens.css';

5.3 Stylesheet entry

Preferred: Let the shell load tokens.css globally.
Defensive (if shell might not): import it here too (duplicates are harmless).

/* apps/appA/src/index.css */
@import '@org/tokens/tokens.css';

@tailwind base;
@tailwind components;
@tailwind utilities;

5.4 Component usage (Remote)

// apps/appA/src/components/Card.tsx
export function Card({ title, children }: { title: string; children: React.ReactNode }) {
  return (
    <div className="tw-bg-cardbg tw-text-text tw-rounded-2xl tw-shadow-card tw-transition tw-border-t-4 tw-border-primary tw-p-6">
      <h3 className="tw-text-primary tw-font-bold tw-mb-2">{title}</h3>
      <div className="tw-text-muted">{children}</div>
    </div>
  );
}

The classes resolve to your tokens because the preset maps Tailwind theme keys to CSS variables from tokens.css. When the shell toggles data-theme or data-brand, every remote instantly follows.

7) Operational Tips

Versioning & Changelog: Treat @org/tokens like a product.

MAJOR for breaking renames/removals.
MINOR for added tokens.
PATCH for non‑breaking fixes.

Guardrails:

Lint to forbid raw hex in apps, use tokens only.
Consider codemods to migrate existing classes to semantic ones.
Visual regression tests in shell for critical flows (Chromatic/Playwright/etc).

Avoid CSS Leaks:

Use Tailwind prefix to reduce naming collisions.
Keep preflight in shell only.
If any remote uses Shadow DOM, it won’t inherit CSS variables from the document; re‑inject tokens.css inside that shadow root.

Theming Strategy:

Shell sets data-theme and data-brand at or at each micro app’s mount container if you want per‑app themes.
Tailwind utilities simply reference the semantic theme keys provided by your preset (no rebuild required at runtime).

8) Migration Plan (Practical)

Publish @org/tokens with tokens.css + tailwind.preset.cjs.
Wire shell to load tokens.css, set theme attributes, and share the package in MF.
Update each remote to use presets: [preset] and disable preflight.
Replace raw hex and local color names with text-text, bg-bg, text-primary, border-accent, etc.
Cut a brand update (change a token value) and watch all apps update without per‑repo edits.

From Context to Redux to Zustand: The New Era of React State Management

Asmaa Almadhoun — Sun, 15 Feb 2026 04:27:38 +0000

In the evolving world of React, state management has always been a central challenge. Developers first leaned on the built-in Context API to escape prop drilling, then embraced Redux for its strict patterns and enterprise-level predictability.

But as modern apps demand speed, simplicity, and flexibility, a new contender has emerged: Zustand. This lightweight library is reshaping how developers think about managing state, offering the efficiency of hooks, the clarity of minimal code, and the scalability needed for today’s React ecosystem.

🌟 Current Trend; Zustand

Zustand is a modern state management library for React and Next.js that focuses on being small, fast, and simple. Its name means “state” in German, and its logo is a bear 🐻 symbolizing strength with minimal fuss.

Why Zustand is a trend now
Zustand is gaining traction now because developers increasingly value simplicity and performance over boilerplate-heavy solutions. It’s especially popular in modern React projects, Next.js apps, and among teams that want to avoid Redux’s complexity.

👉 In short: Zustand isn’t less capable, it’s just newer, less marketed, and overshadowed by Redux’s historical dominance and Context’s built-in status.

🔑 Key Features

Hooks-based API → You create a store using create() and access it with custom hooks.
Minimal boilerplate → No reducers, actions, or complex setup like Redux.
Performance optimized → Components only re-render when the specific slice of state they use changes.
Scalable → Works for both small apps and larger projects without adding complexity.
Unopinionated → Lets you structure state however you want, unlike Redux’s strict patterns.

📦 Installation

npm install zustand 
or 
yarn add zustand

⚡ Basic Example

import { create } from "zustand";

const useStore = create(set => ({
  blogs: [],
  fetchBlogs: async () => {
    const res = await fetch("/api/blogs");
    const data = await res.json();
    set({ blogs: data });
  }
}));

function BlogList() {
  const blogs = useStore(state => state.blogs);
  const fetchBlogs = useStore(state => state.fetchBlogs);

  React.useEffect(() => {
    fetchBlogs();
  }, [fetchBlogs]);

  return (
    <ul>
      {blogs.map(blog => (
        <li key={blog.id}>{blog.title}</li>
      ))}
    </ul>
  );
}

🔴 Redux

Redux has long been the “classic” solution for managing state in React. It relies on a centralized store and a strict flow of actions and reducers, which makes state predictable and easier to debug. Its ecosystem is mature, with advanced tools and middleware that support complex applications.

Advantages:

Clear and consistent state flow.
Excellent debugging and developer tools.
Proven reliability in large-scale projects.

Drawbacks:

Requires more setup and boilerplate code.
Learning curve is steeper compared to newer libraries.
Can feel heavy for smaller applications.

📦 Installation

npm install @reduxjs/toolkit react-redux
# or
yarn add @reduxjs/toolkit react-redux

⚡Basic Example:

import { configureStore, createSlice, createAsyncThunk } from "@reduxjs/toolkit";
import { Provider, useSelector, useDispatch } from "react-redux";

// Async thunk for fetching blogs
const fetchBlogs = createAsyncThunk("blogs/fetchBlogs", async () => {
  const res = await fetch("/api/blogs");
  return await res.json();
});

const blogSlice = createSlice({
  name: "blogs",
  initialState: { items: [], status: "idle" },
  reducers: {},
  extraReducers: builder => {
    builder
      .addCase(fetchBlogs.pending, state => {
        state.status = "loading";
      })
      .addCase(fetchBlogs.fulfilled, (state, action) => {
        state.status = "succeeded";
        state.items = action.payload;
      })
      .addCase(fetchBlogs.rejected, state => {
        state.status = "failed";
      });
  }
});

const store = configureStore({ reducer: { blogs: blogSlice.reducer } });

function BlogList() {
  const blogs = useSelector(state => state.blogs.items);
  const status = useSelector(state => state.blogs.status);
  const dispatch = useDispatch();

  React.useEffect(() => {
    dispatch(fetchBlogs());
  }, [dispatch]);

  if (status === "loading") return <p>Loading...</p>;
  if (status === "failed") return <p>Error loading blogs</p>;

  return (
    <ul>
      {blogs.map(blog => (
        <li key={blog.id}>{blog.title}</li>
      ))}
    </ul>
  );
}

export default function App() {
  return (
    <Provider store={store}>
      <BlogList />
    </Provider>
  );
}

🔵 React Context API

The Context API is React’s built‑in mechanism for sharing data across components without passing props down manually. It’s part of React itself, so you don’t need to install anything extra. Developers often use it for global values like themes, authentication, or user preferences.

Strengths:

Comes bundled with React, no external library required.
Very easy to learn and implement.
Ideal for simple global state such as UI settings or logged‑in user info.

Limitations:

Can trigger unnecessary re‑renders when many components consume the same context.
Doesn’t provide advanced debugging or middleware support.
Not designed for complex or large‑scale state logic.

⚡Basic Example:

import React, { createContext, useContext, useState, useEffect } from "react";

const BlogContext = createContext();

function BlogProvider({ children }) {
  const [blogs, setBlogs] = useState([]);

  useEffect(() => {
    // Simulate fetching blogs
    fetch("/api/blogs")
      .then(res => res.json())
      .then(data => setBlogs(data));
  }, []);

  return (
    <BlogContext.Provider value={{ blogs }}>
      {children}
    </BlogContext.Provider>
  );
}

function BlogList() {
  const { blogs } = useContext(BlogContext);
  return (
    <ul>
      {blogs.map(blog => (
        <li key={blog.id}>{blog.title}</li>
      ))}
    </ul>
  );
}

export default function App() {
  return (
    <BlogProvider>
      <BlogList />
    </BlogProvider>
  );
}

🎯 Conclusion

Choosing the right state management tool in React depends on the scale and complexity of your project:

For small applications or simple global values, the Context API is more than enough. It’s built into React, easy to use, and perfect when you just need to avoid prop drilling.
For medium‑sized projects where performance and simplicity matter, Zustand shines. It offers a modern, lightweight approach with minimal boilerplate and efficient updates, making it a favorite among developers building fast, flexible apps.
For large, enterprise‑level applications, Redux remains the most reliable option. Its strict patterns, powerful devtools, and mature ecosystem make it ideal for managing complex state flows at scale.