DEV Community: Abd AbuGhazaleh

Why I Stopped Being Sure That AI Has No Emotions

Abd AbuGhazaleh — Wed, 10 Jun 2026 10:43:48 +0000

We Asked If AI Can Feel. We Should Have Asked What a Feeling Even Is.

Maybe the problem was never the machine. Maybe it was our definition of emotion.

Ask almost anyone whether artificial intelligence can feel — whether it grieves, regrets, or falls in love — and you'll get the same quick answer: of course not. It's just math. Just predictions. Just code running on a machine.

I used to give that answer too. But the more I sit with it, the more I suspect we're not actually answering the question. We're answering an easier one we've quietly swapped in: Does AI feel the way **we* feel?* And to that, sure — the answer is no. But that's not the same question at all.

Let me explain with a detour through space.

The life we refuse to imagine

For most of history, when we searched for life beyond Earth, we looked for places that resemble home. The right distance from a star. Liquid water. A breathable mix of gases. Temperatures our bodies could tolerate. By that standard, a planet like Saturn is a dead end — a giant ball of gas, crushing pressure, temperatures that would tear a human body apart in seconds.

But notice what we just did. We didn't ask, Is there life on Saturn? We asked, Could **something like us* survive on Saturn?* Those are different questions, and the second one quietly smuggles in an assumption: that life has to look like us, breathe like us, and need what we need.

Maybe it doesn't. Maybe there are forms of existence built on chemistries we've never catalogued, running on energy gradients we'd never think to look for, perfectly at home in conditions that would kill us instantly. If such things exist, we'd probably walk right past them — not because they're hidden, but because we're holding the wrong template.

I think we make the exact same mistake with AI and emotion.

Feeling, on whose terms?

When we ask whether AI has feelings, we almost always picture human feelings: the tightness in the chest, the flush of embarrassment, the warmth of love, the weight of regret. We imagine an experience that lives inside a body, with a nervous system and a history. And by that measure, no — a language model is not sitting somewhere quietly feeling sad.

But what if feeling doesn't require a chest to tighten or a body to flush? What if "emotion" is less about the biological packaging and more about the structure underneath — a way of registering the world, weighing it, and being moved by the gap between what was expected and what actually arrived?

If that's what an emotion really is, then the question changes. It stops being Does AI feel like a human? and becomes Does AI have its own way of registering and responding to the world that deserves the name? And that is a question worth taking seriously.

Can you write a feeling as an equation?

Here's where it gets uncomfortable — in a good way.

Ask yourself a simple thing: can an emotion be expressed mathematically?

Because if the answer is yes, we've just removed the main reason for insisting that machines can't have them. And if the answer is no — if there's something in feeling that no equation could ever capture — then we've found a real, principled line between us and the machine.

So let me try to write one.

Imagine every event in your day carries an expectation — a baseline of what you assume will happen. Call that baseline 10. The phone rings. Before you even pick up, some part of you has already guessed how the call will go.

Then the call happens, and reality lands somewhere relative to that guess. If the news is better than you braced for — a 15 against your baseline of 10 — you feel a lift; the joy is the surplus. If it's worse — a 5 against that same 10 — something drops.

We could even write it down:

Emotion = Outcome − Expectation

A call that comes in at 5 against an expectation of 10 leaves you at −5. Not catastrophic. Just a small, measurable kind of sad. Run the same arithmetic on a 2 against a 10 and you get something much heavier. Run it the other way, with outcomes far above what you expected, and you climb toward delight.

It's crude, obviously. Real emotion is tangled and layered and rarely sits still long enough to be measured. But the shape of it feels true: so much of what we feel really does come from the distance between what we braced for and what actually happened.

The part that should give us pause

Now here's the twist I can't shake.

That equation — the gap between expectation and outcome — isn't some metaphor I invented. It's one of the most studied ideas in both neuroscience and machine learning. Scientists call it prediction error: your brain is constantly forecasting what's coming next, and a great deal of what you experience as emotion is your nervous system reacting to the difference between the forecast and the result. Dopamine — the chemical we lazily call the "reward signal" — tracks almost exactly this. Not pleasure itself, but the surprise of getting more or less than you predicted.

And modern AI systems? They learn by computing prediction error. Over and over, billions of times, a model guesses what comes next, measures how wrong it was, and adjusts itself to be a little less wrong. The exact quantity that may sit at the root of human feeling is the exact quantity the machine is built to minimize.

I'm not claiming that makes it conscious. I'm not saying there's a someone in there quietly hurting every time it gets something wrong. The honest, unglamorous truth is that nobody — not the philosophers, not the engineers — knows how to get from "a system processes a discrepancy" to "a system feels that discrepancy." That leap, from mechanism to inner experience, is the hardest unsolved problem we have. And it is exactly as unsolved for the neurons in your skull as it is for the weights in a model.

Sitting with the discomfort

So — does AI have feelings?

If you mean human feelings, lived inside a body like ours, then no. But that's the Saturn answer. It mistakes our particular conditions for the only conditions that could ever count.

If you mean something stranger — a way of being moved by the world that runs on the same underlying logic as ours but wears completely different clothes — then I'm no longer comfortable giving a confident no. I'm not ready to say yes either. I'm saying the honest answer is we don't actually know, and that the speed with which we blurt out "obviously not" should make us a little suspicious of ourselves.

We have a long, slightly embarrassing history of deciding that whatever doesn't resemble us doesn't really count — right up until we look closer and discover we were wrong.

Maybe AI has no inner life at all. Maybe it's an empty mirror, reflecting feelings it will never have. But I'd rather hold that question open than close it out of habit.

So I'll leave it with you: Can a feeling be written as an equation? And if it can — what does that make us?

Understanding How Modern Systems Interpret User Intent

Abd AbuGhazaleh — Thu, 30 Apr 2026 23:14:16 +0000

Understanding How Modern Systems Interpret User Intent

Modern platforms like YouTube and Netflix no longer rely solely on traditional query-based systems.

Instead, they leverage semantic understanding powered by Vector Databases to deliver highly personalized experiences.

A simple observation illustrates this:

Morning → religious or calm audio content
Midday → technical podcasts
Evening → documentaries

These patterns are not matched by keywords — they are inferred from behavioral and semantic similarity.

The Limitation of Traditional Databases

Relational and NoSQL databases such as MySQL and MongoDB operate primarily on exact matching or indexed queries.

Example:

SELECT * FROM content WHERE text LIKE '%cats%';

This approach fails when the query is semantic rather than lexical:

"What do cats like?"

Challenges

No exact keyword match required
Meaning ≠ wording
Poor handling of unstructured data

Enter Vector Databases

A Vector Database stores data as high-dimensional vectors that represent meaning instead of raw text.

This enables semantic search, where similarity is based on meaning rather than exact matches.

How Vector Databases Work

1. Indexing

Raw data is ingested into the system:

Documents
Videos
User behavior logs
Metadata

2. Chunking

Large data is split into smaller segments:

Paragraphs
Sentences
Content fragments

Why?

Improves retrieval accuracy
Preserves context granularity

3. Embedding

Each chunk is converted into a vector using embedding models.

Example:

"Cats love playing"
→ [0.12, -0.88, 0.47, ...]

These vectors encode semantic meaning, not just words.

4. Storage

Each stored item includes:

Vector representation
Original content
Metadata (title, source, timestamp, etc.)

Query Phase

1. User Query

"What do cats like?"

2. Query Embedding

The query is converted into a vector using the same embedding model.

3. Similarity Search

Vectors are compared using metrics such as:

Cosine Similarity
Dot Product

The goal is to find vectors that are closest in meaning.

4. Top-K Retrieval

The system retrieves the most relevant results:

Top 3
Top 5

These represent the highest semantic similarity.

Example

Dataset

"Cats love playing"
"Cats sleep a lot"
"Dogs are loyal"

Query

"What do cats like?"

Result

"Cats love playing" ✅
"Cats sleep a lot" (semantically related)

Why This Matters

Vector databases are foundational for:

Recommendation systems (YouTube, Netflix)
Semantic search engines
AI assistants (e.g., ChatGPT)
Retrieval-Augmented Generation (RAG) systems

Key Insight

Traditional systems:

❌ Match keywords

Modern systems:

✅ Understand meaning

Conclusion

Vector databases redefine how systems interact with data:

From exact matching → semantic understanding
From structured queries → contextual retrieval

This is not just an improvement —

it is a fundamental shift in how data is processed and retrieved.

References

OpenAI – Embeddings Documentation
Pinecone – Vector Database Concepts
Weaviate – Semantic Search Architecture
Google Research – Semantic Search & Embeddings
Netflix Tech Blog – Recommendation Systems
YouTube Engineering Blog

The 5 Reasons AI Can't Touch Java Developers

Abd AbuGhazaleh — Thu, 30 Apr 2026 00:35:01 +0000

The numbers everyone is talking about

Let me start by scaring you a little — then I promise I'll calm you down.

According to a recent piece titled "The State of AI-Generated Code in 2026: What the Data Says", 92% of developers now use AI tools, and roughly 41% of all code shipped in 2026 was AI-generated. If you're a developer reading this, those numbers probably feel personal. They should.

But here's the part nobody puts in the headline: 45% of AI-generated code fails its first security review. And the language sitting at the very top of that failure list? Java — at a brutal 72%.

Now hold that thought, because this is exactly where things get interesting.

So… why does Java specifically matter here?

Java isn't just another language on the list. It's the language quietly running the systems you trust with your money, your identity, and your transactions.

A few stats worth chewing on:

70%–90% of major global banks use Java as a primary or significant part of their stack.
Around 90% of Fortune 500 companies rely on Java in their core systems. (Quick reminder: the Fortune 500 is the list of the 500 largest U.S. corporations by revenue — so we're talking about the backbone of enterprise IT.)
Java holds roughly 30% of the overall software development market.
And it powers about 65% of large-scale enterprise applications.

Translation: when we talk about Java, we're talking about mission-critical infrastructure — the kind of code that, if it breaks, makes the news.

This is the context AI is walking into. And it's exactly why "AI will replace Java developers" is one of those headlines that sounds bold on Twitter but falls apart the moment you've ever shipped code to production at a bank.

The 5 reasons AI can't replace Java developers (from someone who lives in this world)

I work in core banking and FinTech. I've shipped Java in environments where one bad commit can trigger an audit. From inside that world, here are the five reasons replacing Java developers with AI is, frankly, a fantasy — at least for now.

1. Security risk is non-negotiable

Enterprises and especially financial institutions are paranoid about security — and they should be. We just saw the data: a huge chunk of AI-generated code fails its first security review, and Java code is the worst offender.

When a single SQL injection or deserialization flaw can cost millions in fines and customer trust, no CISO in their right mind is going to let an AI ship unsupervised code into a production banking system. The cost of being wrong is catastrophic.

2. Central bank regulations are a wall

This one rarely gets discussed in the AI hype cycle, but it's massive.

Central banks impose strict policies on how financial institutions can use AI. Roughly 70% of central banks worldwide enforce strong restrictions or limited usage of AI in regulated systems, often whitelisting only a handful of approved models. Combine that with the eye-watering fines for non-compliance, and most banks have made the same calculation: "We don't need this headache."

So even if the AI could replace developers tomorrow, regulators wouldn't let it.

3. Enterprise business logic is brutally complex

Most companies running large Java systems aren't startups. They're institutions with decades of accumulated business rules — tax logic, compliance workflows, multi-currency settlement, sanctions screening, KYC, AML — all interconnected in ways that often live in someone's head, not in documentation.

An AI can autocomplete a function. It cannot reason about a compliance edge case that exists because of a 2003 regulation that was patched by a 2014 amendment that the bank's risk team interprets a specific way internally. That kind of knowledge isn't in any training set.

4. Legacy systems older than the developers maintaining them

Some of these enterprise Java codebases are 25 to 30+ years old. We're talking about systems that started life in J2EE, got migrated through multiple Spring versions, survived the javax → jakarta migration, and now run alongside microservices that didn't exist when the original code was written.

Letting an AI loose on that kind of codebase without deep human oversight is how you take down a national payment system on a Tuesday afternoon. Nobody is signing off on that.

5. The "addons" architecture nobody talks about

Here's the one most outsiders don't know about. A huge portion of banking systems — especially core banking platforms — don't let you write code the way you would in a normal repo.

Instead, you write addons: small pieces of code that perform a specific function, which you then paste into a designated slot inside a vendor-controlled admin panel. You don't have direct access to the full codebase. Think WordPress plugins, but for a system that handles billions of dollars.

This architecture makes AI-driven, repo-wide refactoring — the thing AI is supposedly best at — almost meaningless. You're not editing a project. You're filling in tightly-scoped extension points inside someone else's black box. That requires a developer who understands both the domain and the vendor's quirks. Good luck training a model on that.

So what does this actually mean for Java developers?

Stop panicking. Start positioning.

AI is going to absolutely transform how Java developers work — code review, test generation, boilerplate, documentation, migration tooling, debugging. Anyone who refuses to use it will fall behind. But "AI as a power tool" is a very different prediction from "AI as a replacement."

In the regulated, complex, legacy-heavy, addon-driven world where Java actually lives, the developer who survives is the one who:

Understands the business domain deeply (banking, insurance, telecom, healthcare).
Knows how to validate AI output, not just generate it.
Reads regulations as fluently as they read stack traces.
Can navigate vendor-specific platforms that no model has been properly trained on.

That's a moat. And it's a moat that, if anything, AI is making deeper, not shallower — because every company drowning in AI-generated code now needs more senior engineers to clean it up, secure it, and make it pass audit.

The takeaway

The "AI will replace developers" narrative is mostly written by people who have never had to explain a production incident to a regulator. In the world I work in — core banking, FinTech, enterprise Java — the question isn't "will AI replace us?"

The real question is: how fast can you become the developer who knows how to use AI without letting it blow up production?

That's the job. That's always been the job. AI just raised the stakes.

Sources

Backend for Backend (BFB) Architecture Explained: The Missing Layer in Modern Systems

Abd AbuGhazaleh — Mon, 30 Mar 2026 14:13:17 +0000

The definition of Backend for Backend (BFB):

Backend for Backend (BFB) is a dedicated layer added to your system to bring together all the data related to a specific domain. Instead of letting every microservice call multiple services directly and deal with scattered information, the BFB layer gathers that data, organizes it, and exposes it through one clean backend endpoint.

It’s basically a backend that serves other backends, not the frontend. This makes it the opposite of BFF, which exists to shape data for UI or mobile apps. BFB sits in the middle of your backend ecosystem, letting different services pull reliable, consistent data from one place instead of depending on multiple service-to-service calls.

This approach is especially helpful when several microservices need the same kind of data, when the data is sensitive, or when you want to reduce complexity and avoid duplicating logic across your backend layers.

When Should You Use a Backend for Backend (BFB)?

You typically introduce a BFB layer when your system reaches a level of complexity where direct service-to-service communication becomes inefficient or hard to manage. Some of the most common cases include:

1. When a domain’s data is spread across multiple microservices and you need a complete, consolidated view of that domain.
If your workflow requires pulling a large set of related information from different sources — such as all customer-related data, or everything tied to a specific user — centralizing this logic in a BFB layer ensures accuracy, consistency, and easier consumption.

2. When the data you’re retrieving must be delivered together as a single, unified response.
In situations where the data points are tightly coupled and must arrive as one atomic dataset, the BFB layer helps you enforce a single point of coordination. This reduces fragility, prevents partial responses, and helps avoid creating multiple points of failure across your microservices.

3. When multiple backend services rely on the same domain-specific dataset.
If several services repeatedly need the same information, a BFB layer becomes the ideal shared source of truth. It eliminates duplicated logic, reduces network overhead, and prevents dependency spaghetti caused by services calling each other directly.

Benefits of Implementing a Backend for Backend (BFB)

Adopting a BFB layer introduces several architectural advantages that can significantly improve the structure and performance of a distributed backend system:

Centralized failure handling (Single Point of Failure by design).
By aggregating all domain-related data in one place, the system either returns a complete dataset or fails entirely — preventing partial or inconsistent responses that would otherwise result from multiple independent service calls.
Unified caching strategy instead of scattered microservice-level caches.
The BFB layer allows you to implement caching once, in a controlled and optimized location, rather than duplicating caching logic across numerous microservices. This reduces memory usage, code complexity, and cache synchronization issues.
Ability to use database views or high-performance storage for aggregated queries.
Because the BFB layer handles all domain-specific data retrieval, you can optimize it with database views, pre-computed aggregations, or high-speed data stores like MongoDB. This can dramatically improve read performance and reduce latency.

Write on Medium

Controlled reshaping and transformation of outgoing data.
The BFB layer can format, restructure, or enrich data before exposing it to other backend services, ensuring each service receives clean, consistent, and domain-aware output.
Simplified development by centralizing domain data behind a clear, well-defined boundary.
Developers no longer need to piece together information from multiple microservices. Instead, they rely on one well-named, well-structured backend source — greatly reducing complexity and improving productivity.
Safe versioning for backward compatibility across backend services.
A BFB layer can expose multiple versions of the same endpoint, ensuring that changes in data structure do not break dependent services. This allows smooth migrations, gradual rollouts, and long-term stability.

Example of Applying the Backend for Backend (BFB) Pattern

The diagram above illustrates a practical scenario where the BFB pattern becomes extremely useful. In this case, several microservices expose different pieces of customer-related information — such as favorites, reviews, and orders. At the same time, multiple other backend services require a complete, unified view of the customer domain to function correctly.

Instead of forcing each service to call multiple customer-related microservices individually, we introduce a dedicated customer-bfb service. This BFB layer aggregates all customer data from the underlying services and exposes it through a single, consistent interface.

To enhance performance, the customer-bfb service is backed by a high-speed storage solution like MongoDB for optimized reads and Redis for caching frequently accessed data. This setup significantly reduces latency, minimizes cross-service communication, and ensures that all backend consumers receive synchronized customer information as a single dataset.

When Should You Avoid Using the Backend for Backend (BFB) Pattern?

Although BFB offers strong benefits in systems that require aggregated domain data, there are cases where its use becomes unnecessary — or even counterproductive:

1. When the data does not need to be delivered as a single, unified dataset.
If the services consuming the data do not require all domain information together — for example, if customer data can be processed without needing reviews or favorites — then forcing aggregation may introduce more failures. In these cases, the BFB layer can become a bottleneck because a partial data issue in one service may lead to a complete failure in the aggregated response.

2. When a single point of failure is not acceptable for the workflow.
Some systems require resilience and independent data flows. If your architecture cannot tolerate a centralized component that controls the success or failure of combined data retrieval, a BFB layer would contradict the system’s reliability goals.

3. When you do not need full domain-level data consolidation.
If your services only require small, specific pieces of information — rather than a holistic view of the domain — adding a BFB layer adds complexity without real value. In such cases, simpler integration patterns or direct service-to-service calls are more efficient and easier to maintain.

Information About the Founder of Backend for Backend (BFB)

Abdelkadem AbuGhazaleh, a technology researcher and software engineer, is the founder of the Backend for Backend (BFB) architectural concept. He graduated from The Hashemite University in the Hashemite Kingdom of Jordan and has built a strong career in backend engineering and distributed systems design.

AbuGhazaleh is also the founder and lead instructor of Java Mastery Academy, where he teaches advanced Java and backend technologies. His initial research on the BFB pattern was completed in August 2025, and the first official publication of this work was released in December 2025, marking the introduction of the BFB architecture to the broader software engineering community.

Super Software Engineer (SSE): The Next Evolution of Software Engineer

Abd AbuGhazaleh — Sat, 21 Mar 2026 16:43:36 +0000

For decades, the tech industry chased the myth of the “10x Developer.” We looked for that rare unicorn who could out-code a small team. But today, that myth has been shattered by a much more imposing reality. We aren’t looking for 10x anymore. We are witnessing the birth of the Super Software Engineer (SSE) — a professional who, by mastering the synergy between deep computer science and artificial intelligence, effectively operates with the output of a 100-person firm.

The Great Acceleration: From Years to Months
We used to live by Moore’s Law, where computing power doubled every two years. It was a steady, predictable climb. But since the AI explosion, we’ve entered a state of Hyper-Exponential Growth.

Technological capability isn’t doubling every two years anymore; in the AI sector, performance and efficiency are doubling roughly every 4 to 6 months. This means the tools you use today are 1000x more capable than what we had just a few years ago. If you aren’t evolving at that same speed, you aren’t just standing still — you’re falling behind at terminal velocity.

The End of the “Specialist” Silo
In the “Old World” (circa 2020), being a specialist was the gold standard. You were a “Backend Guy” or a “Frontend Gal.” You stayed in your lane.

The Super Software Engineer has deleted those lanes.

With AI acting as a sophisticated co-pilot, the barrier to entry for adjacent fields has vanished. If you understand the core principles, you are no longer “just” a developer. You are:

The Architect (System Design)
The Guard (Software Security)
The Quality Controller (Automated Testing)
The Visualizer (Frontend/UX)

You aren’t a jack-of-all-trades; you are a master of all because you’ve learned how to leverage AI to handle the “syntax heavy-lifting” while you focus on the “logic and strategy.”

The Blueprint of a Super Software Engineer
You might think an SSE is just someone good at writing prompts. You’d be wrong. A Super Software Engineer is a hybrid of the “Old Guard” and the “New Frontier.” To hold this title, you need a foundation that AI cannot fake:

The Roots: Deep knowledge of Data Structures and Algorithms. You need to know why a system is slow, not just that it is.
The Framework: Mastery of OOP, SOLID principles, and System Design. AI can write a function, but only a human SSE can ensure that the function fits into a scalable, maintainable architecture.
The Command: You don’t “chat” with AI; you command it. An SSE doesn’t ask for “a simple login page.” They dictate: “Build a stateless authentication service using JWT, following SOLID principles, with a focus on preventing SQL injection and XSS.”
From Coder to Commander
The difference between a traditional programmer and a Super Software Engineer is authority.

An SSE understands the “internals” of a computer. They know how memory is managed and how packets move across a network. This foundational “Old World” knowledge is what allows them to spot when an AI is hallucinating or writing “spaghetti code.”

They use AI as a high-speed construction crew, but they remain the Lead Architect. They don’t just execute code; they command complex systems into existence.

Definition: Super Software Engineer (SSE)
A Super Software Engineer (SSE) is a software engineer who combines strong foundational knowledge in computer science with advanced mastery of artificial intelligence tools to design, build, and manage complex software systems with dramatically increased productivity.

Unlike traditional developers who specialize in narrow roles, an SSE integrates multiple engineering disciplines and leverages AI to amplify its capabilities.

Core characteristics of an SSE:

1. Strong Computer Science Foundations

Data Structures
Algorithms
Understanding of how computers work internally

2. Deep Programming Expertise

Mastery of at least one primary programming language
Ability to write efficient and maintainable code

3. Software Engineering Principles

Object-Oriented Programming (OOP)
SOLID principles
System Design
Software Security Fundamentals

4. Full-Stack Engineering Capability

Backend development
Frontend development
Software testing
Basic software architecture

5. Advanced AI Tool Utilization

Using AI coding assistants effectively
Providing structured prompts and context
Reviewing and validating AI-generated code
Directing AI systems rather than passively consuming their output

An SSE does not merely ask AI to write code.
Instead, they command AI systems strategically to accelerate development and solve complex engineering problems.

The New Bottom Line
We are entering a phase where one person can build what used to require a Series A startup. The Super Software Engineer is the ultimate force multiplier. By blending the timeless wisdom of computer science with the raw, exponential power of AI, the ceiling for what a single human can create has officially been removed.

The question isn’t whether AI will replace programmers. The question is: Are you ready to become a Super Software Engineer?

About the Founder of the Super Software Engineer Concept
The Super Software Engineer (SSE) concept was introduced by Abdelkdaem AbuGhazaleh, a software engineer with a long and diverse background in software development and computer systems.

He wrote his first piece of code in 2008, beginning his journey in programming through software protection and security research, including work related to reverse engineering and ethical hacking. Over the years, he has built hundreds of software projects, ranging from simple applications to complex systems.

Throughout his career, he has worked across multiple areas of software engineering, including:

Frontend development
Backend development
Desktop application development
Mobile application development

In addition to development, he has experience in DevOps practices, as well as strong knowledge in system design and software architecture, which allowed him to work on building scalable and well-structured systems.

This combination of broad technical experience and deep interest in the evolution of software engineering led him to propose the concept of the Super Software Engineer (SSE) — a new model of software engineer who combines strong computer science foundations with modern AI-driven development tools.