DEV Community: Mohammed Taher

[Boost]

Mohammed Taher — Sat, 03 Jan 2026 22:16:45 +0000

Mohammed Taher

Jan 2

The Era of Mechanical Horses

#ai #softwaredevelopment #lowcode #futureofdevelopment

Comments

2 min read

The Era of Mechanical Horses

Mohammed Taher — Fri, 02 Jan 2026 00:05:12 +0000

We’re Still Teaching AI to Build Faster Horses

Scroll through any developer feed today and you’ll see the same debates repeating themselves:
Will AI replace software engineers? Is AI-generated code safe or maintainable? Is “vibe coding” a bad practice?

All of these discussions share a hidden assumption—that the way we build software today will stay fundamentally the same, just with AI assisting along the way.

I think that assumption is wrong.

A quick look back at abstraction

I started my software journey as an embedded systems engineer, writing code for microcontrollers. Before Embedded C—already considered a high-level language—I worked with assembly. In both cases, the end result was identical: hex code written into EEPROM, executing predefined logic on hardware.

Later, as a side hobby, I worked with ActionScript (RIP Flash), which eventually helped me move into the JavaScript ecosystem and shift my career toward web development. That transition gave me a front-row seat to how quickly “high-level” changes over time.

During the rise of HTML5 and Web 2.0, JavaScript development evolved rapidly. jQuery simplified DOM manipulation. Frameworks like Angular and Meteor raised the abstraction even further. Node.js brought JavaScript to the server, and bundlers like Webpack, Parcel, and later Vite automated more and more of the complexity.

Yet through all of these changes, one thing remained constant: the output was still plain JavaScript, HTML, and CSS. We didn’t remove layers—we kept stacking new ones on top of the old ones.

AI as a mechanical horse

Imagine a horse pulling a cart. When humans first invent an engine, the most natural idea isn’t to build a car—it’s to replace the biological horse with a mechanical one. Same cart, same mental model, just powered differently. Only later does the real leap happen.

This is exactly how we’re using AI today.

Most AI tools focus on writing React components, generating boilerplate, or refactoring existing code. In other words, AI is acting as a mechanical horse—doing the same job in the same system, just faster.

That’s useful, but it’s not the real disruption.

The leap we’re not talking about

Throughout the history of software, we’ve relied on abstraction layers to bridge the gap between human intent and machine execution. Readable, maintainable code exists primarily for humans—not for machines.

So the real question isn’t whether AI can write better React code.

The real question is: what happens when AI no longer needs our abstractions at all?

Instead of asking AI to write React, we could ask it to generate the final executable logic directly—the lowest-level representation that satisfies our intent. Frameworks, languages, and even code structure become implementation details rather than primary artifacts.

When that happens, yesterday’s “high-level” tools will become today’s low-level plumbing.

What this means for developers

This shift won’t eliminate software engineers, but it will change what software engineering looks like. The focus moves away from writing code line by line and toward defining goals, constraints, behavior, and outcomes.

In that world, programming becomes less about syntax and more about intent.

Most AI discussions today are still about faster horses.
But the era of evolving into cars is not far.

[Engineering] How to build a scalable design system

Mohammed Taher — Fri, 28 Apr 2023 12:20:57 +0000

Atomic design was a blog article written in 2013 by Bradfrost discussing how to make proper design in a reusable and modular way, and even there is a book published for it, and the content itself is much refined from the very early blog article that was written.

Brad has not really invented something new, but what he did was frameworking what I see as common sense for mature UI designers, which is divide and conquer.

Actually divide and conquer is not only applicable for solving design issues, but works with any big issue where you need to break it down to smaller issues/chunks that can be easily solved

To my surprise, I have not really found really something similar on the Engineering side, maybe something like bit.dev is awesome, but it is not really about making an atomic design system, it is more like a modular framework any project, and their smallest unit is a component, but if we could say that component itself can be broken down to a more granular level

The Atomic Architecture Framework, which we will discuss in this article, is simply a set of rules which define how to manage the whole process of building a scalable design system in the most efficient way (from Engineering perspective), and also covers all common parts between Design, and Engineering

We can start by some definitions:

Atom:
The most broken down unit in the system, if it can be broken down more, then it is not atom. Single responsibility item
Props (if necessary) should be as primitive as possible, this means deep nested objects, or complicated arrays are not allowed as props (unless necessary)
Root tag is always custom and should match atom name
Semantic HTML should be always followed when possible

Molecule: A group of atoms to serve a repetitive purpose. A molecule is consisted of multiple atoms, molecules, or both together

Element: Exposed component that groups molecules, and atoms to feature Engineers. It can offer complicated models & props. It
Should reuse molecules/atoms as much as possible

Block: Block is a reusable piece of complicated Group, so for example user profile card where we render avatar, and some social profile icons with links, and maybe a button to message that user, follow, or block .. etc

Page: Page in frontend world corresponds to a single route, and a single page can render multiple fragments, or pieces of UI, and these pieces can be anything from defined above

and then we can define some rules:

Layering: The idea behind the breakdown above is to separate internal concerns from external concerns. Think of it as OOP private and public class methods, where you can only expose what you need to, via public props, or methods, and the rest is kept internal, so we guarantee a consistent contract, so no breaking changes at all. However we may want to introduce breaking changes, and that will be covered in versioning rule. The internal layers are simply atoms, and molecules (private for core team working on design system), while the external layers Element, Block, and Page are usually exposed to be used by our feature Engineers (for example)
One to One Map: The rule above will lead us to another rule which is 1:1 map, and this means that sometimes we may want to use an atom, or molecule as element, so you may find yourself in a situation where you just expose it ...

Just because the same exact functionality is required in the present time, doesn't necessarily mean that we expose our internal components, and the reason for that is; in future you may want to extend (or remove) some props from some atom because some element requires so, and then you will end up with a pile of unnecessary (or optional) props which really pollutes your code

We need to keep our code clean and separate the concern of atom, or a molecule, from the concern of higher level layers, and this means that even you are in a situation when you need to clone an atom (e.g. checkbox atom), it is totally fine to map at as 1:1 with checkbox element

Props vs Classes: This part is little bit tricky as it is always hard to decide if you should apply visuals via props, or classes, so for example we need to apply background color to some button, should we then create a class with background color inherited from some token (css variable), or should we expose a color prop where Engineers can change it?

There is no right, or wrong answer to this really, but there is a decision that can be made based on use case, to explain this in a simple way, lets assume we have a checkbox (again) that has some brand color matching our design system (assuming dark blue), and for some reason we want our Engineers to change the checkbox color (border or background) to red when used inside an invalid form

In this case we need a way to inform our Engineers that they can customize background color based on some condition, and for that reason a prop would make perfect sense, on the other hand imagine we need to change some background color of an atom, but for some internal reason (e.g. blur, or focus), which is already predefined in our design system, then it would make perfect sense to apply this via a shared class

Development strategy

Convenience: Design system, like any project needs to be well planned before executed, and for this reason, it might be helpful for the team working on it, to brainstorm together what needs to be done before writing any code

A nice way to plan the development of any component, is to think about possbile props, and methods in the way that is most convenient for consumers, and this process may require many iterations, and feedback before reaching a stable and satisfying state

Consistency: Using code generators to generate components from pre-defined templates, is another great way to develop a design system, with great velocity, and consistency.

Using generators doesn't only help Engineers to focus on details, forget about infrastructure (like naming conventions, testing ..etc), but is also very useful in case we need to do some patching for our components in the future to improve certain parts (overtime you may find out better solutions to old problems)

Publish

Preview: Most common way to preview a design system in modern time is storybook. There are too many alternatives like styleguidist, or patternlab, but based on personal experience storybook is the most robust, customizable, and scalable way to communicate our design system with external world

One little issue we had was to preview our internal components (e.g. Atoms, or Molecules) separately from elements, and for that we had to create what we call playground

A playground can be another storybook instance, or even a custom preview component, that help design system Engineers to preview, and visually test their components

Versioning: Versioning is a very nice concept, specially when it comes to make sure new changes to our components don't break a stable version that is for example already used in production

Using something like bit.dev can be very handy for managing versions of our components, and we leave it up to our consumer to decide when they want to upgrade

Debug Ionic Application (NGRX) using Redux remote dev tools

Mohammed Taher — Fri, 17 Feb 2023 02:11:57 +0000

Recently I was working on Ionic app that was built with Angular. The application uses NGRX for state management. I wanted to debug the state (i.e inspect actions, and state ..etc) while application is running on emulator. I expected that by simply running redux dev tools from chrome that it will magically work out of the box, and straight away, but unfortunately this was not the case.

Looking around for sometime I stumbled upon a precious article that was explaining how to put everything together.

Unfortunately the article is outdated, but through some further search and playing around, I managed to make everything work.

I thought to share details here to help anyone who might be looking for a solution to same exact issue.

Step 1:
install NGRX store dev tools
Step 2:
Create 2 files to handle connection between your application and Redux remote dev tool

File1:
remote-devtools-connection.ts

import { ReduxDevtoolsExtensionConnection } from '@ngrx/store-devtools/src/extension'

export class RemoteDevToolsConnectionProxy implements ReduxDevtoolsExtensionConnection {
  constructor(public remotedev: any, public instanceId: string) {}
  init(state?: any): void {
    console.log('Socket was initiated', state)
  }
  error(anyErr: any): void {
    console.error('Socket Error', anyErr)
  }

  subscribe(listener: (change: any) => void): any {
    const listenerWrapper = (change: any) => {
      listener(change)
    }

    this.remotedev.subscribe(listenerWrapper)
    // Hack fix for commit/time-travelling etc. if the devtools are already open
    setTimeout(() => listenerWrapper({ type: 'START' }))
  }

  unsubscribe(): any {
    // HACK fix bug in @ngrx/store-devtools that calls this instead of returning
    // a lambda that calls it when their Observable wrapper is unsubscribed.
    return () => this.remotedev.unsubscribe(this.instanceId)
  }

  send(action: any, state: any): any {
    this.remotedev.send(action, state)
    // Never called
  }
}

File2 (depends on File1):
remote-devtools-proxy.ts

import {
  ReduxDevtoolsExtension,
  ReduxDevtoolsExtensionConfig,
  ReduxDevtoolsExtensionConnection
} from '@ngrx/store-devtools/src/extension'
import { connect } from 'remotedev/lib/devTools'

import { RemoteDevToolsConnectionProxy } from './remote-devtools-connection'

export class RemoteDevToolsProxy implements ReduxDevtoolsExtension {
  remotedev: any = null
  defaultOptions = {
    realtime: true,
    autoReconnect: true,
    connectTimeout: 20000,
    ackTimeout: 10000,
    secure: true
  }

  constructor(defaultOptions: Object) {
    this.defaultOptions = {
      ...this.defaultOptions,
      ...defaultOptions
    }
    console.log('Socket config', this.defaultOptions)
  }

  connect(
    options:
      | {
          shouldStringify?: boolean
          instanceId: string
        } & ReduxDevtoolsExtensionConfig
  ): ReduxDevtoolsExtensionConnection {
    const connectOptions = Object.assign(this.defaultOptions, options)

    this.remotedev = connect(connectOptions)

    const connectionProxy = new RemoteDevToolsConnectionProxy(
      this.remotedev,
      connectOptions.instanceId
    )
    return connectionProxy
  }

  send(action: any, state: any): any {
    this.remotedev.send(action, state)
  }
}

File3 (depends on File2): make sure to include this file in your app based on your environment setup. Like direct import, or webpack include .. etc

The variables REMOTE_DEV_HOST & REMOTE_DEV_PORT can be environment dependent, or hardcoded. You can hardcode them at least to make sure everything works as expected. However the most important point it to use "EXACT" same IP, and PORT in all following steps

index.ts

import { RemoteDevToolsProxy } from './remote-devtools-proxy'

declare const REMOTE_DEV_HOST: string
declare const REMOTE_DEV_PORT: number

if (!window['devToolsExtension'] && !window['__REDUX_DEVTOOLS_EXTENSION__']) {
  console.log('!!!!!! REDUX INSPECTION HAS STARTED !!!!!')
  const remoteDevToolsProxy = new RemoteDevToolsProxy({
    // Needs to match what you run `remotedev` command with and
    // what you setup in remote devtools local connection settings
    hostname: REMOTE_DEV_HOST,
    port: REMOTE_DEV_PORT,
    connectTimeout: 300000, // extend for pauses during debugging
    ackTimeout: 120000, // extend for pauses during debugging
    secure: false // dev only
  })

  // support both the legacy and new keys, for now
  window['devToolsExtension'] = remoteDevToolsProxy
  window['__REDUX_DEVTOOLS_EXTENSION__'] = remoteDevToolsProxy
} else {
  // handle case outside real device, or emulator
}

Step 3: in your angular module make sure you include store dev module

@NgModule({
  imports: [CommonModule, StoreDevtoolsModule.instrument({ maxAge: 100 })]
})

Step 4:
install @redux-devtools/cli
Step 5:
add a script to start redux devtools server which will listen to state, and action changes in your package.json

scripts:
{"remote-dev":"redux-devtools --hostname=ADD_IP_FROM_PREVIOUS_STEPS --port=ADD_PORT_FROM_PREVIOUS_STEPS --wsEngine=ws --logLevel=3"}

and run it in a separate terminal tab/window

Step 6: You may get some error about global is not defined, and in this case add following to polyfill.ts (this is generated by default in your root folder) in your Angular app (more info can be found here)

polyfill.ts

(window as any).global = window

Step 7: open chrome, and right click redux extension to open remote dev tools

Step 8: connect to your host from redux remote settings (UX is bad as there is no feedbad if connection succeeds, or fails). Howevwer ater successful connection you should see the store visible in your dev tools

Happy Hacking ...

Using Nextjs with Sass the Angular way!

Mohammed Taher — Sat, 05 Feb 2022 23:47:41 +0000

I am someone who has quite good experience in frontend world (14+ years), and I believe frameworks (like Angular) is a great way to keep code style consistency, and quality specially in quite big team.

Frameworks however come with a downside that it can't be easily customized.

I recently started using nextjs to kickstart a new project, and I was shocked by the fact that very simple structure decisions are hard to make! specially when it comes to something as simple as connecting my logic to style files.

Some approach that I am used to very long time ago is separation of concern, and the most simple way in frontend application to apply this, is for example keeping all logic (ts, or js files), and style (css,sass,scss ..etc), and sometimes (html if you dont use SFCs) in the same directory, and also keep them linked together (i.e a single entry point usually imports styles and layout files).

Unfortunately when I started using nextjs I found that keeping my sass files in the same directory as my react component is not as easy as I imagined, but the good news that after few hours of searhcing and trying I found a working solution, and that is why am writing this article to share knowledge and save someone's else time if they happen to be looking for a similar solution.

Steps:

Let's start by creating NEXTJS Hello World project (at the time of writing this article, the latest NextJS version was 12.0.10)

npx create-next-app@latest --typescript

Next we need to install all dependencies npm i
Next we can run our app npm run dev So far everything looks cool. However the challenge starts when I want to create a simple page with following structure

|-- path
    |-- to
        |-- MyPage
            |-- index.tsx
            |-- style.scss

Unfortunately nextjs only allows using modules, which I don't find very convenient!

Under pages create Mypage folder, and create two new children, index.tsx, and style.scss

// index.tsx
import React from 'react';
import './style.scss';

export default function MyFirstPage() {
  return (
    <div id="my-first-page">
      <h1 className="title-1">Title 1</h1>
      <h1 className="title-2">Title 2</h1>
    </div>
  );
}

// style.scss
#my-first-page {
  .title-1 {
    color: red;
  }

  .title-2 {
    color: green;
  }
}

import the page we have just created into app.tsx

import React from 'react';
import Router from 'next/router';
import { AppProps } from 'next/app';
import MyFirstPage from './MyFirstPage';

const App = ({ Component, pageProps }: AppProps) => {
  // return <Component {...pageProps} />;
  return <MyFirstPage />;
};
export default App;

If you try to run the previous code, you will get error from nextjs

Global CSS cannot be imported from files other than your Custom <App>. Please move all global CSS imports to pages/_app.js.
Read more: https://err.sh/next.js/css-global

I got stuck at this point for long time, and most solutions on the internet were really inconvenient for me, but luckily I could come up with a working solution!

install following

npm install mini-css-extract-plugin css-loader sass sass-loader

The plugins are optional but just in case you have a previous nextjs config feel free to install them, or just remove it from config file and skip this step

npm install next-compose-plugins next-transpile-modules

Open next.config.js and add the following

const withTM = require('next-transpile-modules')([]);

const withPlugins = require('next-compose-plugins');

const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = withPlugins([withTM], {
  reactStrictMode: true,
  webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
    // Find and remove NextJS css rules.
    const cssRulesIdx = config.module.rules.findIndex((r) => r.oneOf);
    if (cssRulesIdx === -1) {
      throw new Error('Could not find NextJS CSS rule to overwrite.');
    }
    config.module.rules.splice(cssRulesIdx, 1);

    // Add a simpler rule for global css anywhere.
    config.plugins.push(
      new MiniCssExtractPlugin({
        // Options similar to the same options in webpackOptions.output
        // both options are optional
        filename: 'static/chunks/pages/[contenthash].css',
        chunkFilename: 'static/chunks/pages/[contenthash].css',
      }),
    );

    config.module.rules.push({
      test: /\.(sa|sc|c)ss$/i,
      use: [MiniCssExtractPlugin.loader, 'css-loader', 'sass-loader'],
    });

    config.module.rules.push({
      test: /\.tsx/,
      use: [defaultLoaders.babel],
    });

    return config;
  },
});

The above code simply overrides nextjs global css rules, and it also uses MinicssExtractPlugin to write the sass content which was transpiled by sass loader into separate css files

Run the app once more and here you go ! a nice non scoped styles with only using css specifity

If you are so lazy like myself, feel free to clone the whole experiment from here, and play around with it! Happy Hacking ✌️