DEV Community: M Yauri M Attamimi

From Backend Engineer to AI Engineer

M Yauri M Attamimi — Tue, 28 Jul 2026 15:02:18 +0000

The Natural Evolution from Backend Engineering to Agentic AI, and Why Elixir is the Runtime You Didn't Know You Needed

Disclaimer: The views expressed here reflect my personal opinions and interpretations based on hands-on experience. They are supported by community research and industry practices, but they represent my perspective, not absolute truths. AI engineering is evolving rapidly - what's current today may be obsolete tomorrow.

If you've been in Software Engineering for the past few years, you've watched the AI landscape shift beneath your feet at a pace that makes Moore's Law look leisurely. What started as a novelty of crafting clever prompts has matured into a full-fledged engineering discipline with its own architectures, patterns, and paradigms.
In a recent weekly developer sharing session, I presented my take on this evolution and Why I believe backend engineers are uniquely positioned to lead this next wave - and why Elixir and the BEAM VM are quietly becoming one of the most compelling platforms for the next generation of AI systems. This post is an expanded version of that talk.
Let's walk through the journey: from prompt engineering to agentic AI systems, and why your backend engineering skills matter more than ever.

The Evolution of AI Engineering

If we zoom out and look at the trajectory of AI application development, we can identify four distinct eras - each building on the last:

1. Prompt Engineering (2022–2024)

The central question: "What should I say to the model?"

This was the era of crafting the perfect prompt. We built chatbots and copilots, and the engineering work revolved around techniques like Chain-of-Thought (CoT), ReAct, few-shot prompting, and role-playing. The focus was squarely on the input - how to phrase things so the LLM gave us the best possible output.

2. Context Engineering (2025)

The central question: "What information should I provide to the model?"

As models grew more capable, we realized that prompting alone wasn't enough. The real differentiator became what context we fed the model. This gave rise to RAG (Retrieval-Augmented Generation) systems and grounded assistants. The engineering focus shifted to information architecture - how to retrieve, rank, chunk, and deliver the right information at the right time.

3. AI Agents (2025–2026)

The central question: "How do I make it autonomous?"

This is where things started getting interesting from a systems perspective. We moved from single-turn interactions to single autonomous agents that could reason, act, and observe in a loop. The engineering here combines what I call Harness Engineering and Loop Engineering - giving agents tools, memory, autonomy, and a structured cycle to follow.

4. Agentic AI Systems (2026+)

The central question: "How do agents collaborate?"

The frontier. We're now looking at multi-agent systems where multiple autonomous agents coordinate, delegate, and self-heal. This requires advanced loop engineering, distributed state management, and sophisticated orchestration - problems that should sound very familiar to backend engineers.

The Complete Picture

What Makes an AI Agent "Agentic"?

The term "agent" gets thrown around a lot. Not every chatbot with a tool is an agent. Let's clarify the spectrum:

Chatbot VS Agent VS Agentic AI

Core Traits of Agentic AI

For a system to truly be agentic, it should exhibit these properties:

Autonomy: Makes decisions without human intervention
Goal-Directed: Works toward defined objectives, not just responding to inputs
Adaptive: Adjusts behavior based on feedback and observations
Persistent: Maintains state across context window resets
Composable: Coordinates with other agents as part of a larger system
Observable: Telemetry and tracing are built in, not bolted on

The Key Shift: We're moving from "an LLM that responds" to "an LLM that executes in a loop."

The Two Pillars of Agentic AI

Building production-grade agentic AI comes down to two engineering disciplines:

Pillar 1: Harness Engineering

"What environment does the agent need?"

The harness is everything surrounding the LLM that makes it useful and safe:

Tools, APIs, and Capabilities - What can the agent do?
Constraints and guardrails - What shouldn't the agent do?
Error recovery & state persistence - What happens when things go wrong?
Security and permission models - Who can the agent act on behalf of?

Pillar 2: Loop Engineering

"What cycle drives the agent toward the goal?"

The loop is the engine of agency:

Iteration logic - The classic Reason → Act → Observe cycle
Termination conditions - When does the agent stop?
Escalation policies - When should it alert a human?
Progress tracking and logging - How do we know what it's doing?

Think of it this way:

PROMPT → CONTEXT (info) → LOOP (cycle) → HARNESS (environment)

Each layer builds on the previous one. The prompt is what you say. The context is what you know. The loop is how you think. The harness is where you operate.

Why Backend Engineers Have a Massive Advantage

Here's something the AI hype cycle often misses: building agentic AI is fundamentally a backend engineering problem.

Look at the mapping:

If you've spent years building resilient, distributed backend systems, you already have the mental models for agentic AI. The LLM is just a new kind of unreliable external service that you need to wrap with retries, timeouts, state management, and observability.

Why Elixir for Agentic AI?

This is where I get genuinely excited. The BEAM virtual machine - the runtime behind Elixir - was practically designed for the kinds of workloads that agentic AI demands. Let's look at why:

1. Lightweight Processes

Each agent can run in its own isolated process, consuming as little as 25 KB of memory. If one agent crashes, it never takes down another. This maps perfectly to the "one agent, one process" model.

2. Supervision Trees

OTP supervisors detect crashes and restart agents in milliseconds. Failure recovery isn't something you build - it's something you get from the runtime. The "Let It Crash" philosophy is exactly what you want when an LLM call hangs, a tool fails, or an agent enters an unexpected state.

3. Massive Concurrency

BEAM schedulers handle thousands of concurrent agents with true parallelism - no thread pools to tune, no async/await gymnastics, no GIL to fight. When you're running hundreds of agents, each executing multi-step reasoning loops, this matters enormously.

4. Message Passing

Agents communicate via asynchronous messages, which is a natural fit for distributed agent systems. No shared state, no locks, just clean message-based coordination.

5. Hot Code Upgrades

You can update agent logic without downtime. In production agentic systems where agents may be running for hours or days, the ability to push behavioral updates live is critical.

The Elixir Tooling Ecosystem

The community is already building the tools we need.

ReqLLM - Composable LLM Interactions in Elixir

ReqLLM provides a unified, idiomatic Elixir interface for interacting with LLMs:

Unified API across providers (OpenAI, Anthropic, local models)
Flexible model specifications (string, tuple, struct formats)
Rich prompt support with structured data generation
Idiomatic Elixir - pipe-friendly, pattern-matching native
Tracks 92+ non-text operation models (vision, audio, etc.)

A simple example:

response =
  ReqLLM.chat!(
    "openai:gpt-4o",
    [
      %{role: "system", content: "You are a helpful assistant."},
      %{role: "user", content: "What is the capital of France?"}
    ]
  )

# Pattern match on the response
%ReqLLM.Message{content: answer} = response
IO.puts(answer)

Full source code: github.com/yauritux/reqllm_demo

Jido Framework - Production-Grade Agents in Elixir

takes things further by providing a framework for building production-grade agentic systems on the BEAM:

OTP-Native Architecture - Agents are GenServers with supervision trees
Immutable Agents - State transitions are explicit and traceable
AI Optional - Not every step needs an LLM; mix deterministic logic with AI reasoning
Explicit Effect Boundaries - Side effects are declared, not hidden
Massive Concurrency - Built on the BEAM's process model from day one. Every agent runs in its own lightweight process. If one crashes, nothing else is affected.

Real-World Example: Smart Ticketing Agents with Jido

To see how this comes together, let's look at a Smart Ticketing System built with Jido. Imagine a raw, panicked customer email comes in:

INPUT: "My dashboard is loading super slow and showing a 503 error. I have a big presentation in an hour and I'm freaking out!"

Instead of a single monolithic script trying to do everything, we route this through a multi-agent pipeline:

1. The Triage Agent

Prompt Strategy: Uses the CREATE framework (Context, Result, Explain, Audience, Tone, Edit) combined with Chain-of-Thought (CoT).
Input: Raw email text.
Action: Analyzes the emotional weight and extracts technical signals.
Output: Structured JSON.

{ 
  "reasoning": "customer is highly desperate...",
  "sentiment": "highly_negative", 
  "priority": "critical", 
  "error_code": "503"
}

2. The Diagnostic Agent

Prompt Strategy: Uses a ReAct Loop (Reason + Act) combined with Few-Shot Prompting.
Input: The extracted error_code = "503" from the Triage Agent.
Tools: check_server_status/1, restart_service/1.
Action: The agent reasons about the 503 error, calls the check_server_status tool, realizes the frontend process crashed, and executes restart_service.
Output: Technical resolution report.

{ 
  "issue": "503 service unavailable", 
  "root_cause": "web frontend process crashed", 
  "resolution": "service restarted successfully", 
  "status": "resolved"
}

Because these agents are built on Jido and the BEAM, the Triage Agent and Diagnostic Agent run in isolated processes. If the Diagnostic Agent hits a timeout while calling the external API, it crashes and restarts without bringing down the Triage Agent or the rest of the application.

Check out the full implementation at github.com/yauritux/smart_ticket

Conclusion: The Backend Engineer's Moment

The AI industry spent years telling us that the future belonged to ML researchers and data scientists. And for the era of model training, that was true. But we've entered a new era - the era of agentic AI systems - where the hardest problems are about orchestration, resilience, state management, and distributed coordination.
These are backend engineering problems. And the tools we've been using for decades - message queues, supervision trees, process isolation, hot deployments - are exactly the right tools for this job.
If you're a backend engineer looking at the AI space and wondering where you fit in: you're not behind. You're early. And if you're looking for a runtime that was practically designed for the concurrency, fault-tolerance, and distribution challenges of agentic AI, take a serious look at Elixir, Jido, and the BEAM.
The evolution from prompt engineering to agentic AI systems is the most exciting shift I've seen in my career. And the best part? The skills you already have are the skills this new era demands.

Go build something autonomous.

Questions? Thoughts? I'd love to hear from you. Feel free to reach out or drop a comment below.

How I Personally Grasp the Essence of Concurrency in Go

M Yauri M Attamimi — Wed, 25 Mar 2026 18:02:44 +0000

Philosophy, Patterns & The Power of Built-in Tools

Why Go says “Don’t communicate by sharing memory” and how to build robust systems without external libraries.

If you come from a background in Java (like me), Python, or JavaScript, the word “concurrency” might trigger a slight sense of anxiety. We are taught that threads are dangerous, race conditions are lurking around every corner, and debugging deadlocks is a nightmare.

Then you meet Go.

Go doesn’t just offer a new way to write concurrent code; it offers a new way to think about it. But beyond the famous mantras, how does this philosophy translate to actual engineering ? And perhaps most importantly, do you need external libraries to make it work ?

The answer is a resounding NO. Everything you need to build enterprise-grade concurrent systems is built directly into the language and its standard library.

In this post, we’ll recap the core philosophies of Go concurrency, explore the patterns that make it powerful, and highlight the built-in tools that let you implement them without adding a single dependency.

1. The Core Philosophy: CSP vs. Shared Memory

The most famous quote in Go concurrency comes from Rob Pike:

“Don’t communicate by sharing memory; share memory by communicating.”

This is the principle of CSP (Communicating Sequential Processes). To understand it, we need to contrast it with the traditional model.

The Traditional Model: Shared Memory

Imagine a single-occupancy bathroom in an office or any public places.

The Resource: The bathroom (a variable in memory).
The Problem: Multiple people (threads) need to use it.
The Solution: A lock on the door (mutex). You must acquire the key, use the bathroom, and return (release/unlock) the key after you use it.
The Risk: What if someone forgets to unlock the door ? (Deadlock). What if someone sneaks in without the key ? (Race Condition).

The Go Model: CSP

Imagine a factory conveyor belt (a Channel).

The Resource: The parts being built (data).
The Process: Worker A places a part on the belt. The belt moves it to Worker B.
The Safety: At any specific moment, only one person is holding the part. When it is on the belt, no one is touching it.
The Focus: You aren’t protecting a static (shared) variable; You are managing the flow of data.

In Go: You don’t protect a variable with a lock! You pass the variable over a chan. Ownership is transferred safely from one goroutine to another.

2. The Engineering Mantra: Sequence and Backpressure

There is a second, practical mantra that follows the philosophy:

“Don’t over engineer things by using shared memory and complicated, error prone synchronization primitives; instead, use message-passing between Goroutines so variable and data can be used in the appropriate sequence.”

This is where Go shines in production. Channels aren’t just for moving data; they are for controlling time.

The Relay Race Analogy

Shared Memory: Workers check a whiteboard every second to see if the previous step is done. (Busy waiting, complex logic)
Channels: Workers stand in a line. Worker 2 physically cannot start until Worker 1 hands them the baton.

Why this matters:

Sequence Guaranteed: A receive operation ( <- ) blocks automatically until data arrives. You don’t need to write if done {...} loops.
Natural Backpressure: If the Consumer is slow, the Channel fills up. The Producer automatically blocks and waits. This prevents your program from consuming all RAM trying to process data faster than the database can save it.

3. The Producer-Consumer Problem (Solved Simply)

The classic Producer-Consumer pattern is kind of “Hello World” of concurrency. It solves the problem of balancing speed between data creation and data processing.

In many languages, implementing a bounded-buffer (a queue that stops accepting data when full) requires complex condition variables and locks.

The Traditional Way (as conceptually handled in Java)

// Requires Mutex, Condition Variables, Wait(), Signal(), etc.
// Easy to get wrong. Hard to read.
void put(item) {
    lock.acquire();
    while (queue.isFull()) { condition.wait(); }
    queue.add(item);
    condition.signal();
    lock.release();
}

The “Go” Way

In Go, a Buffered Channel is a thread-safe Producer-Consumer queue.

// Create a buffer that holds exactly 5 items
buffer := make(chan int, 5)

// Producer
go func() {
    for i := 0; i < 100; i++ {
        buffer <- i // Automatically blocks if channel is full (Backpressure!)
    }
    close(buffer)
}()

// Consumer
go func() {
    for item := range buffer { // Automatically blocks if channel is empty
        process(item)
    }
}()

That’s it. No locks. No condition variables. No manual signaling. The language runtime handles the synchronization for you.

4. The Go Standard Toolbox (No External Libraries Needed)

One of Go’s greatest strengths is that you do not need third-party frameworks to handle different patterns of concurrency. The standard library is batteries-included.

+---------------------+----------------+------------------+--------------+
|.  Pattern.          |. Tool.         | Package.         |.  Built-In ? | 
+---------------------|----------------|------------------|--------------+
| Lightweight Threads | goroutine      | Language Keyword |  ✅ Yes      |
| Communication       | chan           | Language Keyword |  ✅ Yes      |
| State Protection    | sync.Mutex     | sync             |  ✅ Yes      |
| Wait Groups         | sync.WaitGroup | sync             |  ✅ Yes      |
| High Perf Counters  | atomic         | sync/atomic      |  ✅ Yes      |
| Lifecycle/Timeout   | context        | context          |  ✅ Yes      |

Structure Concurrency with context

In traditional concurrency, knowing when to stop a goroutine is hard. Go solves this with the context package. It allows you to cascade cancellation signals.

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// Pass ctx to your goroutines. 
// If the timeout hits, all listening goroutines stop gracefully.

This prevents goroutine leaks, a common bug in other languages where background tasks keep running forever after a request finishes.

5. When to Break the Rules

While “Share memory by communicating” is the default path, Go is pragmatic. As an engineer we know that there’s “size fits for all”. It always depends on the usecase / problem we’re trying to solve. There are times when shared memory is better:

Simple State: If you just need to protect a simple config map or cache, a sync.Mutex is often clearer than setting up a channel loop.
Performance: Channels have a small overhead. For extremely high-frequency counters, sync/atomic is faster.
Internal State: If a struct has internal state that shouldn’t be exposed, protecting it with a mutex inside its methods is cleaner.

The Rule of Thumb:

Use channels to orchestrate flow (pipelines, worker pools)

Use mutexes to protect state (caches, configs)

6. Beyond the Basics: Actor Model & Async

Go’s model is unique compared to other ecosystems:

Vs. Async/Await (JS/Python): Go hides the complexity. You write code that looks synchronous (e.g., response:= http.Get(...)), but the runtime parks the goroutine efficiently. No callback hell, no explicit await keywords everywhere.
Vs. Actor Model (Erlang/Elixir/Akka): Go is similar but more flexible. In Actor Model pattern: mailboxes (channel in Go) belong to actors. In Go, channels are independent entities that multiple goroutines can share. However, you can build an Actor in Go using a goroutine + switch statement + channel, but you aren’t forced into that paradigm.

Conclusion

Concurrency in Go is not just about doing multiple things at once; its about composing those things safely.

By adopting the CSP philosophy, you shift your mindset from protecting resources (locks) to managing flow (channels). By leveraging the built-in tools like chan, context, and sync, you avoid the dependency hell common in other ecosystems.
You get:

Safety: Race conditions are harder to introduce.
Backpressure: Systems self-regulate under load.
Simplicity: Complex workflows look like simple pipeline.

So.. the next time you face a concurrency problem, remember the mantra: Don’t communicate by sharing memory. Share memory by communicating. And trust the tools that come right out of the box.

Clean Code Architecture in Go

M Yauri M Attamimi — Sun, 05 Apr 2020 14:40:57 +0000

Everyone can write code to produce a software that functionally works as expected, yet not everyone care about how's their code architecture look like. The best chosen algorithms not always save us from the bad software design. There are many code architectures around, and recently i've been struggling and trying to promote the Clean Code Architecture from Robert C. Martin a.k.a. Uncle Bob. Let's start with how this sort of code architecture looks like in Go.

I’m gonna start by implementing some of the functionalities within a shopping cart since it’s pretty straightforward. Bear in mind that what i’ll be showing here is restricted to the bounded context of the shopping cart, means we’ll just focus with the process of how a user/buyer choose the item and adding that particular item into his cart, and subsequently continue with the checkout. As for the billing/payment part, that will be in the bounded context of another service such as payment service. (if you’re neither really familiar nor confidence with what bounded context is, i would suggest you to read another article of mine from here.

By the way, all of the source code i explain here can be cloned/forked from

yauritux / clean-code-architecture

My personal opinion on the Clean Code Architecture in the context of Domain Driven Design (DDD), yet i adopted some terms from the Onion Architecture such as domain to avoid any misleading interpretations with the Entity in DDD

What are highlighted in the grey colors were standing outside of our shopping cart bounded context. Hence, we won’t tackle the nitty gritty details of those objects within our code implementation since those things would be in other services (e.g. product catalogue service and user service). Nevertheless, we’ll still be having those objects within our code, in the context of what our shopping cart needs. For instance, we won’t need user credentials information in our shopping cart since that should be catered from the user service context. Basically, we just need user information which is related to the shopping cart itself, such as: user_session_id, shipping address, billing address (furthermore, address information should also be catered from another service, e.g. : address service, even this is also optional).

There are some rules for this architecture those we must bear within our mind. I've summarized those rules as following:

Dependency between layer should be going inward in one direction. As far as i concern, it was designed like this to avoid any circular dependencies.
A layer should depend only on one direct layer (one level) beneath it, it shouldn’t know any layers beyond that level. For instance, A depends on B ( A → B ), and B depends on C ( B → C ), yet A shouldn’t know anything about C.
Each layer should depends upon abstraction ( interface ) rather than implementation. This complies with what Uncle Bob said about 2 rules to fix RFI issues, you can read it from my old article here.

Let’s jump to the implementation by creating our project folder from the terminal and also initialize the go module as shown below:

mkdir cart-service && cd cart-service
go mod init github.com/yauritux/cart-svc

Next step is creating our pkg directory (mkdir pkg) from the same terminal. This pkg directory will contain our implementation logic for the shopping cart which complies with the clean code architecture we’re discussing here.

By referring to the depicted shopping cart process diagram earlier, we’ll be having these following entities within our code:

User (this also represents a Buyer in the shopping cart bounded context).
Cart (as the name implies, this is our cart object which holds our shopping items).
Product (used as a placeholder for the product information. And for the sake of simplicity…, we won’t have any product categories because our goal here was merely to discuss the Clean Code Architecture).

I create those 3 entities within my pkg/domain/entity folder. To keep it simple, i deliberately marked all of the fields as exported fields (moving forward, we can think about hiding the fields information behind the setter / getter which are commons in Java).

Cart Entity:

User Entity:

Product Entity:

And here our value objects ( pkg/domain/valueobject ):

Cart Items (strongly related to Product entity).
Buyer Address (comprises of Billing and Shipping addresses, determined by the Address Type).

CartItem Value Object:

BuyerAddress Value Object:

Additionally, we will also have our enums as shown below:

If you’re wondering about the differences between entities and value objects, you can read it from

DDD Part II - M Yauri Attamimi - Medium

M Yauri Attamimi ・ Jul 15, 2017 ・ 5 min read
Medium

The next important thing to do is to implement our core business logic, which is part of Entities in Clean Code Architecture, or Core Domain in terms of Onion Architecture. This is something that is related to the enterprise business rules out of the application service rule.

In order to implement this kinda thing, we need to setup our aggregate root (i call it as user_cart aggregate). Again, take a look at what i wrote here if you’re still wondering about what is the aggregate all about.

Another to-do thing is to setup our repositories. Bear in mind, that when we’re talking about repository, it’s not always about the database. The storage implementation could be anything such as: web services, file, in-memory, etc.., and they should be abstracted by following some contracts defined on the interface. In that way, we can use them interchangeably later since we make our client code depends on the interface rather than directly on the implementation. In order to make it possible, we should start by abstracting our repositories with interfaces such as following:

Cart Repository Interface:

User Repository Interface:

Product Repository Interface:

I would assume that some of you will be asking about those empty interfaces :-). Why do they exist ? Why do we use them ?.

As far as i concern, we’ll be having different models for every layer in order to make our architecture more loosely-coupled. In that case, we should abstract our interface model as far as we can, thus we can have more flexibility within our code. Let’s say for the user repository interface, we can have 2 implementations for it, one implementation to get the user information from the database, and another one to get the information from a web service (e.g. REST). Therefore, definitely we’ll have 2 models here, one based on the database model, and another one is based on the web request-response model. That’s the reason why we use empty interface ( interface{} ) within our repository interface. You get it right ? :-). Don’t worry, everything will become clear once we implement our interface.

For the sake of simplicity, we'll be implementing just in-memory repository for now since our first goal is merely to discuss about how’s our clean code architecture will be looked like. However, i will incrementally update the code later for another kind of storage / repository, such as database or web service.

Let’s start to implement our repository interface by creating another directory (at the same level with our domain directory) as shown below:

mkdir -p pkg/adapter/repository/inmem/model

And here are our models (inside the pkg/adapter/repository/inmem/model directory) to be used in the context of our in-memory repository (remember about the interface{} before, when we designed our repository contract interface).

User Model for In-Memory Repository Implementation:

Cart Model for In-Memory Repository Implementation:

Product Model for In-Memory Repository Implementation:

subsequently followed by our in-memory repository implementation for those 3 models respectively (inside /adapter/repository/inmem directory):

User In-Memory Repository Implementation:

Cart In-Memory Repository Implementation:

Product In-Memory Repository Implementation:

And the use cases for cart and user as written below :

User Usecase Port:

User Usecase Interactor:

Cart Usecase Port:

Cart Usecase Interactor:

Product Usecase Interactor:

Last but not least, let’s create a small CLI program to test our shopping cart functionalities that we’ve created so far.

Shopping Cart CLI tester using in-memory repository:

Ok, some of you might get overwhelmed with all of the code here (while some of you might not), especially in regards with the use case port and interactor (what would be the difference between those 2).

Test our CLI by using this following command from the terminal:

go run cmd/cli/main.go

You can grab the full code from here

Let me know for any concerns and/or questions from you guys :-).