DEV Community: Jalal Maskoun

The Old Business Model of Knowledge Work Is Dead

Jalal Maskoun — Thu, 10 Sep 2026 20:12:59 +0000

I think Anthropic is right about something that most people still don't want to talk about.

Even if the AI race stopped today, the old business model of knowledge work is already dead.

For decades, we built an economy around people getting paid for what they know. You studied a domain. You became an expert. You sold that knowledge for an hourly rate or a salary.

But what happens when knowledge becomes extremely cheap to produce?

And it is not just cheap. It is becoming autonomous.

That is the part we are heavily underestimating. This isn't just a software engineering problem. It is not even really an AI problem. It is a fundamental economic problem.

This wave will eventually hit almost every knowledge-based career: lawyers, accountants, analysts, consultants, designers, marketers, developers, finance, operations, and a huge part of the traditional 9–5 office economy. Some jobs will disappear entirely. Many will mutate. New ones will emerge.

Pretending the economic structure stays the same doesn't make much sense.

The Decision We Have to Make

This is where the MENA region has a critical choice in front of it.

We can wait for AGI to arrive and then import whatever economic transformation happens somewhere else. Or we can start the transformation now.

I am not talking about the superficial approach of "let's add an AI wrapper to our existing software."

I am talking about agentic transformation across entire industries. Redesigning how companies operate from the ground up, how services are delivered, and how knowledge work is actually produced.

There are two distinct reasons to do this right now:

Preparation: We will be structurally prepared when AGI-level systems actually arrive.
Market Creation: We can create an entirely new market around that transformation. We can give our own knowledge workers a chance to build the new economy, rather than watching imported solutions quietly eliminate the old one.

Because if we wait until the technology is completely mature, the transition will already be decided for us.

The Uncomfortable Reality

I don't know exactly what the end state looks like. Nobody does.

But one thing is becoming increasingly difficult to argue against: The 9–5 knowledge economy as we know it is coming to an end.

The only question left is whether we actively shape what replaces it, or simply deal with whatever arrives.

The End of Code as the Final Product (The Agentic Shift)

Jalal Maskoun — Fri, 04 Sep 2026 19:52:13 +0000

We keep talking about AI as a "coding assistant." I think that framing is already becoming outdated.

A recent paper, Agentic Software: How AI Agents Are Restructuring the Software Paradigm by Zhenfeng Cao, makes a much bigger argument: AI agents may fundamentally change what we mean by software.

For about 50 years, the basic software engineering model was:
Humans write code → code contains the logic → machines execute it.

Agentic software flips that model entirely. Instead:
Humans define intent → agents reason → agents generate/use code → systems execute → outcomes are evaluated.

The code is no longer necessarily the product. It can become an ephemeral tool used by the agent to accomplish a goal.

That points to an interesting evolution in software delivery:

Licensed software: You received the software and managed much of the surrounding infrastructure.
SaaS: The vendor took over infrastructure and operational complexity.
Agent-as-a-Service (AaaS): The system increasingly takes on part of the decision-making and execution complexity itself.

And that changes software engineering at a much deeper level than AI writing code faster.

The Core Object of Engineering is Shifting:

From the code itself → To the autonomous system around it.
From explicitly encoding every rule → To designing how models reason and act.
From writing every instruction → To defining intent, constraints, evaluation, and outcomes.
From code author → To system architect and outcome auditor.

This creates a very different engineering discipline.

The hard problem may no longer be:

"How do I write the code?"

It is becoming:

"How do I design a system that can reason, act, recover from failure, and remain trustworthy?"

Architecture, observability, evaluation, security, human oversight, and system design may matter even more, not less, as the amount of code humans write directly continues to decline.

If AI-generated code becomes a mere implementation detail, what becomes the most valuable skill for a software engineer?

Read the original discussion and share your thoughts on LinkedIn

The Org Chart Is About to Become Obsolete

Jalal Maskoun — Thu, 03 Sep 2026 20:20:00 +0000

The org chart is about to become obsolete.

Not because companies will stop needing people.

Because companies will stop needing as many people to coordinate the work.

For decades, scaling a company meant scaling management. More employees led to more managers, more coordinators, more meetings, more reporting, and more bureaucracy.

That model made sense when coordination required humans. It makes far less sense when AI agents can coordinate continuously.

Imagine an enterprise where:

HR agents handle recruiting workflows, compensation administration, compliance, and employee requests.
Operations agents monitor execution, SLAs, bottlenecks, and resource allocation in real time.
Finance agents reconcile transactions, flag anomalies, forecast cash needs, and initiate routine workflows.
Cross-functional agent swarms coordinate execution without waiting for a weekly status meeting.

The biggest impact of AI may not be replacing individual jobs. It may be removing entire layers of organizational coordination.

That changes what the company itself looks like:

Middle-management layers shrink.
Administrative coordination collapses.
Status meetings disappear.
White-collar roles built primarily around moving information between humans become increasingly difficult to justify.

The human role shifts from “Manage the work” to “Design, supervise, and improve the system that does the work.”

There’s an even bigger implication for finance. Today, companies carry enormous fixed costs in the form of salaries and headcount. Tomorrow, more of that operating model could become variable:

Payroll → Compute
Headcount → Agents
Management layers → Orchestration
Status reports → Real-time system telemetry

This doesn't mean the office disappears. It means the architecture of the office changes.

If you're building a company today, the strategic question is no longer: “Who should we hire next?”

It is: “Should this role exist as a human role at all?”

That is a much more uncomfortable question. And probably the most important one.

Read the original discussion and share your thoughts on LinkedIn

The Only AI Advantage That Can't Be Subscribed

Jalal Maskoun — Thu, 03 Sep 2026 19:41:17 +0000

In two years, every company will say "we use AI." That's not a prediction; it's already happening.

Which means "we use AI" isn't an advantage anymore. The model isn't your edge. Anyone can call the same tool you're calling.

The real edge is what you know that the AI doesn't: your customers, your failures, the messy details only you've lived through. Feed that in, and AI becomes powerful. Skip it, and you're just borrowing someone else's brain.

So the only question worth asking is: what do we know that no model does, and are we actually using it, or is it still stuck in someone's head?

That's the edge. Everything else is a subscription.

Read the original discussion and share your thoughts on LinkedIn

The Return of the Super App

Jalal Maskoun — Wed, 02 Sep 2026 20:37:14 +0000

Super apps were always the right idea. The timing was just wrong.

For years, the barrier wasn't strategy. It was the interface. You can't group twenty services into one app without burying the user in menus, tabs, and onboarding flows nobody finishes.

That barrier is gone.

When your app can talk to the user and then execute, you don't need twenty screens for twenty services. You need one conversation. The interface shrinks. The service layer expands. Complexity moves from the user's screen to the model's reasoning; where it belongs.

This is the moment super apps stop being a distribution problem and start being an execution problem. The companies that win this won't be the ones with the most features. They'll be the ones with the fewest screens standing between a user and what they actually need done.

If you're still designing for more screens, you're designing for the last decade.

Read the original discussion and share your thoughts on LinkedIn

Infinite Scroll Was Never a Feature

Jalal Maskoun — Wed, 02 Sep 2026 20:36:10 +0000

Every browse-and-filter interface was a workaround, not a feature.

Users were never asking for infinite scroll. They were asking for the thing they wanted. We gave them raw data and filters because the system couldn't understand the request; it could only display rows and let the user run their own query, manually, with their thumb.

That workaround is over.

Users already know what they want. They don't want to browse fifty options ranked by relevance score. They want the three that actually fit. AI models can finally take a real request and return a real answer, instead of a dataset dressed up as a decision.

The products that win next will stop asking users to do the filtering themselves. They'll do it for them and only show up when the match is right.

Infinite scroll wasn't a design choice. It was a limitation we mistook for a feature.

Time to build like the limitation is gone.

Read the original discussion and share your thoughts on LinkedIn

The "Delete" Mindset: Why Most AI Strategies Fail Founders

Jalal Maskoun — Wed, 02 Sep 2026 20:34:16 +0000

Most "AI strategy" in businesses right now is just adding a chatbot to something that was already broken.

That's not strategy. That's decoration.

The real question every CEO should be asking isn't "where can we add AI"; it's "which slow, manual decision in this company should no longer exist."

Approvals that take a week. Reports someone builds by hand every Monday. Customer answers that sit in a queue for a human to type out.

AI doesn't make those faster. It makes them unnecessary.

The companies that win the next 5 years won't be the ones with the most AI tools bolted on. They'll be the ones who deleted the most steps.

What's one process in your business that should disappear? Not speed up, but disappear?

Read the original discussion and share your thoughts on LinkedIn

Your AI Strategy Is Just Decoration

Jalal Maskoun — Wed, 02 Sep 2026 20:32:16 +0000

Most "AI strategy" in businesses right now is just adding a chatbot to something that was already broken.

That's not strategy. That's decoration.

The real question every CEO should be asking isn't "where can we add AI"; it's "which slow, manual decision in this company should no longer exist."

Approvals that take a week. Reports someone builds by hand every Monday. Customer answers that sit in a queue for a human to type out.

AI doesn't make those faster. It makes them unnecessary.

The companies that win the next 5 years won't be the ones with the most AI tools bolted on. They'll be the ones who deleted the most steps.

What's one process in your business that should disappear? Not speed up, but disappear?

Read the original discussion and share your thoughts on LinkedIn

Your AI Strategy Is Just an IT Request

Jalal Maskoun — Wed, 02 Sep 2026 20:30:29 +0000

If your AI strategy sits with your IT department, you don't have an AI strategy. You have a technology project. And that's a dangerous distinction.

100 years ago, carriage companies didn't lose because they built bad carriages. They lost because they misunderstood what the automobile was. They thought the new technology was simply a better version of what they already sold. It wasn't. It changed the entire operating system of the economy.

AI is doing the same thing to business.

Yet most companies are still asking: "Where can we use AI?" That's the wrong question.

The question is: "If we were building this company today, what would we design differently because AI exists?"

That's a CEO question. Not an IT question. Because the real opportunity isn't adding a chatbot.

It's rebuilding how work gets done.

Sales: Stop using AI to tell salespeople which leads to call. Build an AI sales agent that continuously monitors the market, identifies companies showing buying signals, researches the account, finds the right decision-makers, builds the business case, starts the conversation, follows up, handles objections, and books the meeting.
HR: Stop using AI to rank CVs. Build an AI recruiting agent that understands the roles you need, searches talent pools, identifies potential candidates, reaches out, has the initial conversation, evaluates fit against your requirements, schedules interviews, and keeps candidates engaged throughout the process.
Customer Service: Stop using AI to answer support tickets. Build an AI service agent that understands the customer's problem, checks their history, investigates the issue across your systems, takes action, resolves the problem, processes the necessary changes, and escalates only when human judgment is actually required.

That's the difference between using AI to automate tasks and using AI to redesign the company.

The companies that win with AI won't necessarily be the ones with the most sophisticated models. They'll be the ones willing to question the way they've operated for the last 10, 20, or 30 years.

Because AI doesn't just give you a faster way to do yesterday's work. It gives you permission to ask whether yesterday's work should exist at all.

So here's the uncomfortable question for every CEO:

If you had to rebuild your company from zero today, which department would look completely different?

That's probably where your AI strategy should start.

Read the original discussion and share your thoughts on LinkedIn

Introducing DFlex - A Modern Javascript Drag and Drop Library

Jalal Maskoun — Fri, 10 Nov 2023 10:03:44 +0000

I'm excited to announce the release of DFlex, a new Javascript library for building modern drag and drop interfaces.

DFlex aims to make it easy to add natural dragging, dropping, and sorting interactions to your web apps. It is lightweight, dependency-free, and works across all modern browsers.

Some key features of DFlex include:

DOM Manipulation - DFlex directly manipulates the DOM instead of reconstructing it like other libraries. This results in better performance and avoids layout shifts.
Transformation Scheduler - DFlex has its own scheduler and reconciler to transform elements. This prevents blocking and allows smooth, concurrent animations.
Custom Events & Listeners - DFlex provides custom events for dragging, interactivity, siblings, and more. It also has layout listeners to monitor state changes.
Modular Architecture - DFlex is built with a modular architecture, including separate packages for the DOM generator, utilities, store, draggable, and more.
Framework Agnostic - DFlex is framework agnostic and works with React, Vue, Angular, and vanilla JS.
Configurable - Options like dragging threshold, restrictions, auto-scroll, and more can be configured per element.

I built DFlex to push drag and drop capabilities further and handle complex interfaces at scale without compromises. The project is MIT licensed and open source on GitHub.

Here is a simple DnD component using React and DFlex:

// Simple DFlex DnD Component 

import React from 'react';
import { store, DnD } from '@dflex/dnd';

let draggableInstance; 

const DFlexDnD = ({ id, children }) => {

  const ref = React.useRef();

  React.useEffect(() => {
    if (ref.current) {
      store.register({ id });
    }

    return () => store.unregister(id);
  }, [id]);

  const onMouseDown = e => {
    if (e.button === 0) {
      draggableInstance = new DnD(id, {x: e.clientX, y: e.clientY});
    }
  };

  const onMouseMove = e => {
    if (draggableInstance) {
      draggableInstance.dragAt(e.clientX, e.clientY); 
    }
  };

  const onMouseUp = () => {
    if (draggableInstance) {
      draggableInstance.endDragging();
      draggableInstance = null;
    }
  };

  return (
    <div
      ref={ref}
      onMouseDown={onMouseDown}
      onMouseMove={onMouseMove}
      onMouseUp={onMouseUp}  
    >
      {children}
    </div>
  );

};

export default DFlexDnD;

With just a few lines of code, we can add drag and drop capabilities to a component. The DFlex store manages registration, while the DnD instance handles the dragging logic.

I'd love for you to check out the DFlex website to see examples and live demos. Let me know if you end up building something cool with DFlex! I'm always looking for feedback to help improve the library.

dflex-js / dflex

The sophisticated Drag and Drop library you've been waiting for 🥳

DFlex

DFlex is a Javascript library for modern Drag and Drop apps. It's built with vanilla Javascript and implemented an enhanced transformation mechanism to manipulate DOM elements. It is by far the only Drag and Drop library on the internet that manipulates the DOM instead of reconstructing it and has its own scheduler and reconciler.

Features

Dynamic architecture.
Traverse DOM without calling browser API.
Infinite DOM transformation instead of reconstructing the DOM tree with every interaction.
Customized and enhanced reconciler targets only elements transformed from origin.
Isolated from data flow with a scheduler prevents any blocking event.
Prevent layout shift that happens with any Drag and Drop mechanism.
Animated transformation with each interaction.
Headless and compatible with any modern JS framework.
Targeting each DOM element individually based on registration.
Event driven and fully customized API.
Extensible using its own matching algorithm instead of flat recursion algorithm(s).
Support three different types…

View on GitHub

To Puppeteer, or to Cypress

Jalal Maskoun — Wed, 22 Jul 2020 20:21:46 +0000

Working on a layout is not easy when there are too many possibilities and it gets more complicated if it's related to mouse direction. It's not just up and down, you literally need to test all horizontal and vertical possibilities. Imagine you also study elements getting effected by mouse movement, where things getting harder and harder.

In the nutshell, I am a hard unit-test believer, but in this case, you definitely need to do testing and not a unit test we are talking here about an end-to-end test where you see elements moving virtually and experience each case individually.

Jalal Maskoun

Jun 27 '20

Using unit and integration tests in Jest

#showdev #javascript #testing

2 min read

The big question is how you do it, taking into consideration that your project already uses a unit test with Jest.

Puppeteer it

The wise decision in my case is to use, Puppeteer. You integrate Puppeteer with Jest in jest.integration.config.js a whole new config and start writing your first integration test.

{
  "preset": "jest-puppeteer"
}

Everything is async in Puppeteer so you go by something like this to get your element:

const element = await page.waitForSelector("#id-something");

I need to get element box size so I added:

const elmBox = await element.boundingBox();

const {x, y, width, height} = elmBox

// do something here...

You immediately start to notice that's Puppeteer is natural. I am not learning something new, it's easy to use and you supposedly can go further. Let's try mouse events.

// move the mouse to new coordinates 
await page.mouse.move(100, 200);

// triggers mouse down
await page.mouse.down();

// move the mouse to new horizontal position
await page.mouse.move(500, 200);

// triggers mouse up
await page.mouse.up();

Very easy. Very handy. Except there's a configuration related. you can't keep the browser open, there's no time travel, and you can't repeat the test cases individually. So, if you test and develop by doing TDD it's nearly impossible to actually see what's going on. You can slow down the test but if you running a server and you wait to browser to re-launch that's means waiting for infinity.

launch: {
 devtools: true,
 slowMo: 500,
},

Even with Puppeteer reaching version 5 there's a gap in its ecosystem. Because it's not a testing framework.

Puppeteer is a Node library which provides a high-level API to control Chrome or Chromium over the DevTools Protocol.

Trying Cypress

The first issue with Cypress, that you need to start from scratch. A new assertion, a new testing framework, with a new structure.

The installation includes examples that really help to know where you are going and what your test cases should look like. You use a chain of commands. You get something, trigger it, test it.

cy.get("#id-something").then((elm) => {
elmBox = elm[0].getBoundingClientRect();

const {x, y, width, height} = elmBox
});

Cypress uses trigger to trigger an event

cy.get("#id-something")
  .trigger("mousedown", { button: 0 })
  .trigger("mousemove", { clientX: 100, clientY: 200 });

It uses a whole different approach but once you read it you easily get it. Until you start to use assertion.

This is from Cypress documentation:

cy.get('.error').should('be.empty')
cy.contains('Login').should('be.visible')
cy.wrap({ foo: 'bar' }).its('foo').should('eq', 'bar')

You take a deep breath and ask yourself, should I really have to learn this? Even something like beforeAll in cypress is before. So, you get the sense that whatever transition you make it's not going to be smooth as you expect.

But your test runs with zero-config, with time travel, and yes you can repeat it forever. And it's super-fast.

However, my problem is not with speediness. I need, at a certain point to be able to repeat the same test command.

It turns out, Cypress automatically takes a screenshot for every command and you simply can highlight it forever which means a totally new debugging experience.

Conclusion

When it comes to increasing productivity, end-to-end test can be the real solution. Forget about all articles tell you about the benefits of testing and why you should use e2e. I personally experienced a huge difference in fixing bugs saving hours of chasing needles in a haystack.

Puppeteer can be a solution for expanding your test cases. But if you are using it with development, the answer is Cypress.

Cypress is rich with examples, and a supportive community. It's designed for the end-to-end tests; therefore, you won't struggle using it. If you are familiar with Mocha it won't take you a long time to get familiar with assertation. And it's amazing how you can use it even with no previous background about this type of testing. Most importantly, you immediately start experiencing the benefits of each test you write instead of figuring out how to configure it with your project.

Using unit and integration tests in Jest

Jalal Maskoun — Sat, 27 Jun 2020 16:42:16 +0000

I was trying to use jest-puppeteer with monorepo project i'm working on in roadmap aiming to add integration tests using puppeteer.

And honestly, I didn't have any idea how to load different jest.config.js for different packages I already have in the monorepo.

In case anyone stuck in the same problem as me. The simple solution is to separate the unit test from an integration test. Obvious? didn't seem so for me.

This "separation" should be reflected in the project structure, config files, and running scripts.

Of course, the main problem I faced here, is dealing with the switching environment. I use testEnvironment: "jsdom" and to run puppeteer you have to remove any testing environment and use preset: "jest-puppeteer".

Lesson 1: You can't run all tests at once.
Lesson 2: It doesn't matter if you are using monorepo or not.

So, I ended up with the following structure:

myProj1/
  src/
  test/
    integration/
      myFrist.test.js
    foo.test.js
    bar.test.js
  package.json

myProj2/
  ...
myProj3/
  ...
jest.config.js
jest.integration.config.js
package.json

What's in config files?

Well, not much at all.

In jest.config.js, the main goal is to exclude the integration test.

module.exports = {
  testEnvironment: "jsdom",
  testPathIgnorePatterns: ["test/integration"],
};

Inside jest.integration.config.js, make sure to test only the integration files.

module.exports = {
  preset: "jest-puppeteer",
  testRegex: "/integration/",
};

And finally inside root package.json:

"scripts": {
   "test:unit": "jest",
   "test:e2e": "jest -c jest.integration.config.js",
   "test": "yarn test:unit && yarn test:e2e",
 },

Using jest -c to pass a custom config for Jest. Since I have jest.config.js for the unit test there's no need to pass one, Jest will automatically read it. But that's not the case for test:e2e.

Eventually, the test script will run both integration and unit tests.