DEV Community

M Yauri M Attamimi
M Yauri M Attamimi

Posted on

From Backend Engineer to AI Engineer

#ai #elixir #agents

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)
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)