DEV Community: Benedict Isaac

Opik by Comet The Open Source Observability Tool Every AI Builder Needs in Their Stack

Benedict Isaac — Sat, 11 Apr 2026 17:14:42 +0000

I came across Opik during the Commit to Change Hackathon by Encode Club, in partnership with Comet. I had never heard of it before, but after integrating it into my project, it became one of those tools I couldn't imagine building without.

If you're building LLM-powered applications whether that's a RAG pipeline, an AI agent, a chatbot, or any system that calls a

language model you already know the pain:
Something breaks and you don't know where
Your agent hallucinates and you can't trace why
Token costs spike and you have no visibility into what's consuming them
You change a prompt and don't know if it actually improved anything

Opik is the answer to all of that.
This article covers what Opik is, how it works, its core features, and how to integrate it into your existing LLM stack — with real code examples.

What is Opik?
Opik is an open-source LLM observability and evaluation platform built by Comet. It sits alongside your AI application and gives you complete visibility into everything your system does every LLM call, every tool invocation, every chain step logged, scored, and visualized in one dashboard.

It covers the full development lifecycle:
Development trace and debug your agents as you build
Evaluation score outputs and run experiments across prompt versions
Production monitor live traffic, detect issues, and auto-optimize

Think of it like this: if your AI agent is a car, Opik is the full onboard diagnostics system not just a dashboard light that tells you something is wrong, but the full readout that tells you exactly which component failed and why.

Core Concepts: Traces and Spans
Before diving into code, it helps to understand two key concepts Opik is built around.

A trace is a complete record of one end-to-end request through your LLM application. From the moment a user sends a question to the moment your app returns a response that entire journey is one trace.

A span is a single step inside that trace. If your agent calls a retrieval function, then calls the LLM, then formats the output — each of those is a span nested inside the parent trace.
This structure gives you surgical visibility. Instead of just knowing "the response was bad," you can see exactly which step produced the bad output, how long it took, and what it was working with.

Getting Started Installation
bash pip install opik
opik configure
Running opik configure sets up your API key and connects your environment to the Opik cloud dashboard. You can also self-host Opik if you prefer to keep everything local.

Core Integration The @track Decorator
The fastest way to get started with Opik is the @track decorator. Add it to any function in your LLM pipeline and Opik automatically logs it as a span.

python from opik import track

`@track
def llm_chain(user_question):
context = get_context(user_question)
response = call_llm(user_question, context)
return response

@track
def get_context(user_question):
# Retrieval logic hard coded here for simplicity
return ["The dog chased the cat.", "The cat was called Luky."]

@track
def call_llm(user_question, context):
# Your actual LLM call goes here
return "The dog chased the cat Luky."

response = llm_chain("What did the dog do?")
print(response)`

What happens when you run this:
llm_chain is logged as the parent trace
get_context and call_llm are logged as child spans nested inside it
Every input, output, and execution time is captured automatically
The full chain appears in your Opik dashboard instantly

No boilerplate. No manual logging. Just a decorator.

Integrations Works With Your Existing Stack
Opik isn't asking you to rewrite your application. It integrates directly with the tools you're already using:
LangChain:

`pythonfrom langchain_openai import ChatOpenAI
from opik.integrations.langchain import OpikTracer

opik_tracer = OpikTracer()
llm = ChatOpenAI(temperature=0)
llm = llm.with_config({"callbacks": [opik_tracer]})

llm.invoke("Hello, how are you?")
OpenAI SDK:
pythonfrom openai import OpenAI
from opik.integrations.openai import track_openai

openai_client = OpenAI()
openai_client = track_openai(openai_client)

response = openai_client.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": "Hello, world!"}]
)
LlamaIndex:
pythonfrom llama_index.core import set_global_handler

set_global_handler("opik")`

One line. That's it for LlamaIndex.
Opik also supports LiteLLM, DSPy, Ragas, OpenTelemetry, and Predibase so whatever your stack looks like, it fits in.

Evaluation Stop Guessing, Start Scoring
Once your traces are being logged, you can start running evaluations. Opik has built-in eval metrics including:

Hallucination detection flags responses that contradict the provided context

Answer relevance scores how well the response addresses the question

Context precision measures the quality of retrieved context in RAG systems

Factuality checks responses against a ground truth dataset
Moderation flags harmful or policy-violating content

You can also define your own custom metrics using the SDK.
The real power here is running experiments give Opik a dataset, define what "good" looks like using your chosen metrics, and let it automatically score different versions of your app against each other. You stop debating which prompt is better and start measuring it.

Guardrails Safety Built In
Opik ships with built-in guardrails that screen both user inputs and LLM outputs before they cause problems:

PII detection and redaction
Competitor mention filtering
Off-topic content detection
Custom content moderation rules

You can use Opik's built-in models or plug in your own third-party guardrail libraries. This means safety isn't an afterthought you bolt on at the end — it's baked into the same observability pipeline you're already running.

Automatic Prompt Optimization
This is one of the most powerful features Opik offers and one that most developers don't expect from an observability tool.
Once you've defined your evaluation metrics and built a test dataset, Opik can automatically generate and test improved versions of your prompts using four built-in optimizers:

Few-shot Bayesian finds the best few-shot examples for your use case
MIPRO multi-stage instruction and prefix optimization
Evolutionary optimizer iteratively evolves prompt variations
MetaPrompt (LLM-powered) uses an LLM to rewrite and improve your prompts

The result is a production-ready, frozen prompt that you can lock in and deploy with confidence without manually iterating through dozens of variations yourself.

Production Monitoring
When you ship to production, Opik keeps running. Every live request is logged, scored using online eval metrics, and surfaced in your monitoring dashboard.

This means:
You catch regressions immediately when a new model version behaves differently
You build new test datasets directly from real production traffic
You close the loop between what you tested in development and what actually happens with real users

Why This Matters Right Now
The conversation in AI development has shifted. A year ago, the focus was almost entirely on prompts write a better prompt, get a better output. That still matters, but it's not enough anymore.

As AI systems get more complex multi-agent workflows, RAG pipelines, tool-calling chains the failure modes multiply. You can't eyeball your way through 10,000 production traces. You need instrumentation.

Opik gives you that instrumentation. And because it's open source with 18k+ GitHub stars, it's backed by a real community — not a vendor lock-in waiting to happen.

Getting Started

Install: pip install opik
Configure: opik configure
Add @track to your LLM functions
Open your Opik dashboard and watch your traces appear

Free to start, no credit card required.
🔗 comet.com/site/products/opik
⭐ github.com/comet-ml/opik

Be The Best Of Who You Are

Benedict Isaac — Mon, 23 Mar 2026 14:21:32 +0000

Be The Best Bush 🌿

If all you can be is a bush… be the best bush.

What does this really mean?

There are moments where everything feels like the right path.
You want to pursue multiple things. Build, learn, explore, try everything.

And sometimes, your vision feels far bigger than your current reality.

But what if, right now, there’s something within reach?

Something small.
Something simple.
Something possible.

If all you can do at this stage is learn, then do it to the best of your ability.
Be exceptional at it. Become known for it.

Because over time, other paths begin to align.

Excuses won’t move you forward
execution will.

Start Where You Are

If all you can do is…

Learn → be the best learner
Build → be the best builder
Start small → dominate small
Practice → practice with intent
Show up → show up consistently
Think → think deeply and clearly

Be the best… at that level.

Not someday.
Now.

The Illusion of Doing Everything

I once heard a quote:

“Be the best of who you are.”

It sounds simple, but it carries weight.
Because the truth is trying to do everything at once isn’t always effective.

It’s not about whether it’s possible.
It’s about efficiency and impact.

Spreading yourself too thin may feel productive,
but often, it slows down real growth.

The Power of Focus and Synergy

A better approach is to find the synergy between your interests and your end goal.

Not abandoning your interests.
But sequencing them.

Master one thing first.
Then grow into the next.
Then begin to integrate those skills together.

That’s how depth is built.
That’s how people stand out.

Across Every Field
This applies everywhere.

Whether you're a:

developer
engineer
designer
writer
or builder of any kind

The principle remains the same.
Always aim for the top even if you're starting small.
Growth Over Averages

If you’re the best today,
be better than you were yesterday.

Progress compounds.

And over time, what once felt small
becomes your foundation.

You’re not meant to be average
you’re meant to grow.

The Systems Behind AI: Understanding LLMs and Their Place in Engineering

Benedict Isaac — Tue, 17 Mar 2026 17:20:23 +0000

You’ve used AI.
You’ve explored it.
You’ve probably even built with it.

But behind many of the AI systems we interact with today is something more fundamental.

The Large Language Model (LLM).

LLMs power a large portion of modern AI systems and AI agents. They act as the core intelligence layer behind many tools and applications.

So before building more systems with AI, an important question becomes:

What exactly are LLMs?

What Are LLMs
A Large Language Model (LLM) is a computational model trained on vast amounts of data and designed for natural language processing, especially language understanding and language generation.

These models learn patterns in language and use those patterns to generate responses, reason through prompts, and assist in solving problems.

At a high level, LLM systems typically involve:

Encoders: which process and understand input information
Decoders : which generate responses or outputs
Modern LLMs combine these mechanisms to process context, relationships between words, and the structure of language.

But the real breakthrough that enabled today’s powerful models came from a particular architecture.

What Is a Transformer
Most modern LLMs are built using an architecture called the Transformer.

The Transformer architecture changed how models process sequences of information by introducing a mechanism called attention.

Instead of processing words one at a time in order like older neural networks, transformers can look at entire sequences of data simultaneously and determine which parts are most important.

This allows models to:

understand long-range relationships in text
maintain context across large inputs
generate more coherent and structured responses
Because of this design, transformers became the foundation for modern LLMs.

The Three Core Components of an LLM
At a simplified level, most LLM systems can be understood as a combination of three elements:

LLM = Data + Architecture + Training

Data
Large-scale datasets containing books, articles, code, conversations, and other forms of language.

This data teaches the model patterns of human communication and knowledge representation.

Architecture
The structural design of the model itself.

Today, this is primarily the Transformer architecture, which enables models to process complex relationships within data.

Training
The optimization process where the model learns to predict and generate language.

During training, the system adjusts millions or even billions of parameters to improve its predictions and outputs.

Together, these three components create the systems that power modern AI tools.

Engineering, AI, and the Missing Bridge
Coding, machine learning, and AI are incredibly valuable skills. But they were originally meant to complement engineering fundamentals, not replace them.

This observation raises an interesting thought.

What happens when we bring AI thinking back into engineering systems rather than keeping it limited to software?

Viewing AI from an Engineering Perspective
In engineering, almost every new technology eventually finds an entry point into physical systems.

So instead of thinking only about AI models running inside applications, another question emerges:

How can engineering systems and robotics systems behave or learn in ways similar to LLM-powered systems?

What would that actually look like?

Instead of only building software agents, we might begin designing systems where learning, decision-making, and adaptive behavior exist within engineered machines.

This idea goes beyond simple automation.

It begins to resemble something closer to an engineering model of intelligence.

From AI Agents to Intelligent Engineering Systems
Today, we often talk about AI agents in the context of software.

Agents can reason about tasks, interact with systems, retrieve information, and perform actions.

But if we extend this thinking into engineering systems, an interesting possibility appears.

Robotics systems and machines could potentially be designed to:

behave similarly to AI agents
integrate multiple data sources and signals
adapt to environments through learning
reason about tasks and actions
In this perspective, AI is no longer just a software capability.

It becomes something that can interact with and shape engineering systems directly.

This is where the worlds of AI, robotics, and engineering start to converge.

A Practical Question Builders Must Answer
As builders begin integrating AI systems into applications and infrastructure, another important question arises.

Should you build your own model, fine-tune an existing model, or use a pre-existing LLM?

Each approach has its own advantages and trade-offs.

Building Your Own Model
Provides maximum control and customization.

However, it requires extremely large datasets, significant computing resources, and specialized expertise.

Fine-Tuning an Existing Model
Allows developers to adapt a pre-trained model to a specific domain or problem.

This often provides a strong balance between performance and cost.

Using a Pre-Existing LLM
The fastest and most accessible option.

Most modern AI applications today rely on existing models and focus on building systems around them rather than training models from scratch.

The best choice depends on the complexity of the system, the resources available, and the specific problem being solved.

AI systems today are evolving rapidly.

But the most interesting opportunities may not only be in building larger models, but also in exploring how these systems integrate with real engineering systems and infrastructure.

Instead of thinking about AI purely as software, we can begin to ask:

How do intelligent models interact with machines, robotics systems, and the engineered world?

The future of AI may not only live in data centers and applications.

It may also live inside the systems we build to interact with the physical world.

Question for builders and engineers:

Is it better to build your own model for a system, fine-tune an existing model, or rely on pre-trained LLMs?