DEV Community: Naji Louis

Building a Local RAG AI Agent for Airline Reviews with Ollama

Naji Louis — Fri, 16 Jan 2026 16:51:24 +0000

I wanted to explore how far I could go with a fully local AI agent using Retrieval-Augmented Generation (RAG). As a small curiosity-driven evening project, I decided to build an agent that can answer questions about airline reviews — entirely offline, fast, and inexpensive.

This article walks through the idea, tools, and architecture behind the project, with minimal but practical Python code.

Tech Stack Overview

Here’s what I used:

Language: Python

LLM runtime: Ollama

Models:

llama3.2 for question answering
mxbai-embed-large for embeddings

Vector store: Chroma

Libraries:

langchain
langchain-ollama
langchain-chroma
pandas

Dataset: Airline Reviews (CSV) from Kaggle

Why Ollama?

I installed Ollama on a Linux cloud server, but one of the nicest things about it is that it also runs smoothly on most modern PC and Laptops.

Ollama made this project:

Easy to run locally
Cheap (no API costs)
Fast enough for experimentation

Perfect for side projects and learning.

Dataset Preparation

The dataset comes from Kaggle and contains airline reviews in CSV format.

To make vector ingestion faster and lighter:

I created a reduced CSV version
Kept only the columns relevant for semantic search (review text, airline name, rating, etc.)

This significantly improved:

Embedding generation time
Vector store loading speed

High-Level Architecture

The flow is straightforward:

Load airline reviews from CSV using pandas
Generate embeddings using mxbai-embed-large
Store vectors in Chroma
Retrieve relevant reviews for a user question
Pass retrieved reviews + question to llama3.2
Generate an answer strictly based on retrieved content

This is classic RAG but fully local.

Prompt Design

I kept the prompt explicit and restrictive to avoid incorrect information:

You are an expert in answering questions about airline reviews.
Use the provided reviews to answer the question as accurately as possible.

Here are some relevant reviews: {reviews}

Here is the question to answer: {question}

IMPORTANT: Base your answer ONLY on the reviews provided above. If no reviews are provided, say "No reviews were found."

This single instruction already improved answer reliability a lot.

Minimal Python Setup (Conceptual)

The code is intentionally basic and readable:

Load CSV with Pandas
Create embeddings with Ollama embeddings
Store & query vectors with Chroma
Chain retrieval + LLM with LangChain

I avoided over-engineering — the goal was clarity, not abstraction layers.

Example Results

I tested the agent with different types of questions.

✅ Example 1: Valid Question

Question:

How do passengers generally feel about Emirates ?

Result: The agent retrieved multiple relevant reviews and summarized them correctly.

❌ Example 2: No Relevant Data

Question:

Is Honda CRA a good SUV car ?

Result: Since no relevant reviews were retrieved, the agent responded:

No reviews were found...

Correct fallback when no data exists
This behavior is exactly what I wanted — no incorrect information.

GitHub Repository

The full source code is available here:

👉 GitHub Repo: local-AI-agent-RAG

You can also check it out and run it on your own machine by following the instructions provided in the README file.

Final Thoughts

This project was mainly built out of curiosity and for fun — a way to experiment with local RAG systems without overcomplicating things.

That said, the same approach can scale much further. With a larger dataset and more performant hardware, you can build something significantly faster, more accurate, and production-ready.

For now, it serves as a solid proof of concept and a reminder that meaningful AI projects don’t always need massive infrastructure to get started 🚀

Why Prompts Matter: How AI Answers Change Based on What You Ask

Naji Louis — Thu, 13 Nov 2025 15:38:54 +0000

In today’s world of AI tools like ChatGPT, Gemini, and Microsoft Copilot, one thing stands out:
👉 The way you ask a question completely changes the answer you get.

That’s what we call prompting.

Even when asking the same thing, tiny changes in how you phrase it can shift the tone, depth, or even the accuracy of the answer.

What Is Prompting?

Prompting is how you communicate with an AI tool — basically, the instructions you give.

If you think of AI as a new teammate, your prompt is your task description. The clearer you are, the better the results.

Example 1 – ChatGPT

Let’s say you ask ChatGPT about JavaScript.

Prompt 1:

Explain JavaScript.

Response:

JavaScript is a programming language used to add interactivity to websites.

Now, let’s make it more specific.

Prompt 2:

Explain JavaScript in a fun, beginner-friendly way.

Response:

Think of a website as a body. HTML is the skeleton, CSS is the style, and JavaScript is the brain that makes it move and respond.

Just adding a few words (“fun” and “beginner-friendly”) completely changes the tone and structure.

Example 2 – Gemini

Prompt 1:

What is React?

Gemini might respond:

React is a JavaScript library developed by Meta for building user interfaces.

Prompt 2:

What is React? Explain it as if I’m new to web development.

Response:

React helps developers build reusable pieces of a web page called components — like small blocks you can combine to build modern, fast websites.

Again, the difference is in the prompt clarity.

Example 3 – Microsoft Copilot

Microsoft Copilot also shows how the way you ask a question affects the quality of the response.

Prompt 1:

Explain the benefits of TypeScript.

Copilot might respond:

TypeScript adds static typing to JavaScript, helping developers find errors earlier and write more reliable code.

Prompt 2:

Explain the benefits of TypeScript for a junior web developer who is learning JavaScript.

Response:

TypeScript helps you write cleaner JavaScript by catching mistakes before you run the code. It’s great for beginners because it provides hints and suggestions that make learning easier and projects more manageable.

The difference is clear, adding context (“for a junior web developer”) completely changes how Copilot frames the explanation.

Why This Matters

Whether you’re coding, writing, or brainstorming, prompting is the key to getting better results.

Good prompts save time, reduce back-and-forth, and help you get answers that fit your exact needs.

Here are a few things I’ve learned:
✅ Be clear about your goal.
✅ Add context or examples.
✅ Define the tone (formal, friendly, technical, etc.).
✅ Tell the AI who it should act as (“You are a senior developer reviewing code…”).

Final Thoughts

AI isn’t magic — it’s responsive to how you talk to it.
When you write better prompts, you train yourself to think clearly and communicate effectively.

So next time you use ChatGPT, Gemini, or Microsoft Copilot, remember:
🗣️ The better your prompt, the smarter your result.

AI is changing the way we review code, it's faster, smarter, and more consistent. Here’s how tools like Copilot and CodeRabbit are shaping the future of code reviews.

Naji Louis — Fri, 31 Oct 2025 16:45:02 +0000

Naji Louis

Oct 31 '25

How AI Tools Are Changing Code Reviews

#codereview #ai #githubcopilot #softwaredevelopment

Comments 1

3 min read

How AI Tools Are Changing Code Reviews

Naji Louis — Fri, 31 Oct 2025 16:34:00 +0000

Code review has always been one of the most important parts of software development.
It’s where bugs are caught, quality improves, and developers learn from each other.

But let’s be honest — code reviews can also be time-consuming and repetitive.
Sometimes, reviewers spend hours pointing out the same small issues: missing semicolons, unclear variable names, or unused imports.
That’s where AI-powered tools like GitHub Copilot and CodeRabbit start to shine.

The Old Way of Reviewing Code

Traditionally, a developer submits a pull request (PR), and another developer manually reviews it:

Check for syntax or formatting issues
Ensure naming and structure are consistent
Verify logic and potential edge cases
Suggest improvements or simplifications

It’s an important process, but it often slows things down — especially in teams where everyone is busy coding.

Enter AI Code Review Assistants

AI tools like Copilot (by GitHub) and CodeRabbit are helping automate parts of this process.
They don’t replace humans — but they make the review smarter and faster.

GitHub Copilot
Most developers know Copilot as a coding assistant that helps write code.
But GitHub introduced Copilot for Pull Requests, which adds AI to your review process.

It can:

Generate summaries of code changes
Suggest possible issues or improvements
Even write comments automatically on pull requests

So instead of spending time writing “You forgot to handle null values here,” you can focus on higher-level discussions — like architecture or performance.

CodeRabbit
CodeRabbit takes AI reviews one step further.
It acts as a virtual reviewer that analyzes your pull requests automatically and leaves comments just like a human reviewer would.

What’s nice about it:

It integrates with GitHub, GitLab, and Bitbucket
It highlights potential bugs, smells, or style issues
It learns over time from your codebase and review patterns
It can be customized to match your team’s coding standards

In short, it’s like having another experienced teammate who never gets tired of reviewing.

How These Tools Help in Real Projects

Here’s what I personally found useful when trying them:

Faster feedback — small issues get caught immediately.
Cleaner PRs — reviewers see the important stuff, not style fixes.
Consistent quality — AI follows the same rules every time.
Knowledge sharing — less experienced developers learn good practices through AI suggestions.

And since tools like CodeRabbit or Copilot integrate directly into GitHub workflows, they fit naturally into existing pipelines.

What AI Can’t Replace

AI tools are great at identifying surface-level issues and patterns, but they can’t replace human judgment.

You still need humans to:

Understand business logic
Evaluate performance trade-offs
Discuss naming and readability in context
Make final merge decisions

So, think of AI as a helper — not a reviewer that replaces you, but one that frees you up for deeper discussions.

The Future of Code Reviews

The combination of human expertise + AI assistance is where the real power lies.
Developers will spend less time on repetitive tasks and more on meaningful feedback, architecture, and learning.

In the near future, we might see AI that:

Suggests unit tests automatically for new code
Detects security risks in real-time
Explains complex logic in natural language during review

It’s not about removing humans from the process — it’s about making humans more effective reviewers.

Final Thoughts

Since trying these tools, I’ve noticed my code reviews are faster, and my pull requests are cleaner before anyone even looks at them.
AI doesn’t replace communication or collaboration — it just removes friction.

If your team hasn’t tried tools like Copilot for PRs or CodeRabbit, give them a shot.
You’ll still need human insight, but you’ll spend less time chasing small issues and more time building better software

Why I Stopped Using ngIf and ngFor in Angular

Naji Louis — Mon, 27 Oct 2025 00:28:56 +0000

I’ve been using Angular for quite some time, and like many developers, I got used to writing *ngIf, *ngFor, and ngSwitch in almost every component. They worked fine until Angular introduced a new syntax that completely changed how I write templates.

I’m talking about the new control flow syntax:
@if, @else, @for, @let, @switch, @case, and @default.

At first, I didn’t pay much attention. But after giving them a try, I quickly realized how much cleaner, simpler, and more natural my templates became.
Here’s why I stopped using the old syntax and why you might want to as well.

The Problem with the Old Syntax

The old *ngIf, *ngFor, and ngSwitch directives worked well, but they had a few downsides:

The asterisks * looked strange to new developers.
You often needed extra <ng-container> or <ng-template> tags.
Nested conditions and loops were harder to read.

Angular’s new syntax fixes all of that. It’s built directly into the template engine, meaning no more directives — just clean, readable control flow.

@if and @else
The new @if syntax replaces *ngIf and feels much closer to regular JavaScript logic.

Before:

<div *ngIf="isLoggedIn; else guestPart">
  Welcome back!
</div>

<ng-template #guestPart>
  Please log in.
</ng-template>

Now:

@if (isLoggedIn) {
  <div>Welcome back!</div>
} @else {
  <div>Please log in.</div>
}

✅ Easier to read
✅ No blocks or template references
✅ Perfect for nesting conditions

@for
The classic *ngFor still works, but @for feels cleaner and reads more like plain JavaScript.

Before:

<ul>
  <li *ngFor="let user of users; trackBy: trackById">
    {{ user.name }}
  </li>
</ul>

Now:

<ul>
  @for (user of users; track user.id) {
    <li>{{ user.name }}</li>
  }
</ul>

✅ Simpler syntax (track instead of trackBy)
✅ No asterisk confusion
✅ Easier to reason about

@let
Sometimes you need to store a local variable in your template.
@let makes that super easy.

Before:

<ng-container *ngIf="user as u">
  <p>Hello {{ u.name }}</p>
</ng-container>

Now:

@let u = user;
<p>Hello {{ u.name }}</p>

✅ Cleaner variable handling
✅ Works outside @if blocks
✅ Makes templates easier to follow

@switch, @case, and @default
The new @switch syntax replaces ngSwitch and feels just like a real switch statement in JavaScript.

Before:

<div [ngSwitch]="status">
  <p *ngSwitchCase="'active'">Active</p>
  <p *ngSwitchCase="'inactive'">Inactive</p>
  <p *ngSwitchDefault>Unknown</p>
</div>

Now:

@switch (status) {
  @case ('active') {
    <p>Active</p>
  }
  @case ('inactive') {
    <p>Inactive</p>
  }
  @default {
    <p>Unknown</p>
  }
}

✅ More readable
✅ No extra attributes
✅ Matches JavaScript logic perfectly

How to Start Using It

You’ll need Angular 17 or newer to use this new syntax.
If you’re upgrading, just run:

ng update @angular/core@latest @angular/cli@latest

No extra setup or imports needed — it’s ready out of the box.

Final Thoughts

After switching to the new syntax, my templates feel much cleaner and easier to maintain.
I don’t need to wrap everything in containers or remember special * rules anymore.

If you’ve been using Angular for a while, try replacing a few *ngIf or *ngFor blocks with the new syntax and you’ll instantly see the difference.

Sometimes small changes make a big impact and this one definitely does.