DEV Community: TAGBA G-Josaphat E.

I Built a Local RAG Assistant with Ollama, ChromaDB and LangChain. Here's What I Learned

TAGBA G-Josaphat E. — Sat, 25 Jul 2026 14:36:54 +0000

During my internship at a software services company, I noticed a recurring problem: technicians spent hours searching through hundreds of pages of PDF manuals to answer client questions. The company deploys a suite of management tools accounting, HR, logistics mainly to public institutions managing projects funded by international donors.

I kept thinking: this is exactly the kind of problem LLMs were made for. So for my Master's project in AI & Big Data, I built an intelligent assistant to handle it.

The constraint that shaped every technical decision: no data could leave the local infrastructure. These institutions handle sensitive financial data it cannot be sent to OpenAI, Anthropic, or any cloud provider.

This forced me into the world of fully local LLMs. Here's what I built, what broke, and what I learned.

The Problem

The company had accumulated massive technical documentation PDF manuals, configuration guides, FAQ files but no efficient way to query it. When a technician faced an issue with the accounting module or the HR module, they searched manually. Slow, inconsistent, and dependent on individual expertise.

Classic LLMs can't help here: they don't know the private internal documentation. And without grounding in official docs, they hallucinate procedures dangerous when dealing with accounting operations for donor-funded projects.

The solution: RAG (Retrieval-Augmented Generation) make the LLM answer only from the official documentation, injected at query time.

What RAG Actually Is

Before the code, the concept in one sentence: instead of asking the LLM to "know" everything, you retrieve the relevant passages from your documents and inject them into the prompt as context.

The pipeline has two distinct phases:

Phase 1 : Ingestion (done once)

PDF documents
    ↓
Chunking (split into 300-character blocks)
    ↓
Embedding (convert each block to a vector)
    ↓
ChromaDB (store all vectors)

Phase 2 : Query (at each question)

User question
    ↓
Embed the question (same model)
    ↓
ChromaDB similarity search → top 3 chunks
    ↓
Inject chunks + question into LLM prompt
    ↓
Llama 3 generates a grounded answer

The key insight: the LLM never "knows" your documents. It reads them fresh at each query, from the context you provide. No fine-tuning needed. No retraining when docs are updated.

The Architecture: 4 Docker Services

Everything runs locally via Docker Compose. Four services, each with a clear role:

Service	Role	Port
Ollama	Runs Llama 3 locally	11434
ChromaDB	Vector database	8001
FastAPI	RAG pipeline + REST API	8000
Streamlit	User interface	8501

# docker-compose.yml (simplified)
services:
  ollama:
    image: ollama/ollama:latest
    ports: ["11434:11434"]
    volumes: ["./ollama_models:/root/.ollama"]
    environment:
      - OLLAMA_KEEP_ALIVE=24h

  chromadb:
    image: chromadb/chroma:latest
    ports: ["8001:8000"]
    volumes: ["./chroma_db:/chroma/chroma"]

  python-api:
    build: ./src
    ports: ["8000:8000"]
    depends_on: [ollama, chromadb]
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - CHROMA_HOST=chromadb
      - CHROMA_PORT=8000

Step 1 : Ingesting the Documentation

I ingested 10 documents accounting references (SYSCOHADA, SYCEBNL), a general accounting code, and internal user manuals. That's 2,111 pages split into 9,669 chunks.

# src/ingestion.py

import os
import chromadb
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_chroma import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings

DATA_DIR = "/app/data/documents"
COLLECTION_NAME = "documentation"

def load_documents():
    documents = []
    for fichier in os.listdir(DATA_DIR):
        if fichier.endswith(".pdf"):
            try:
                loader = PyPDFLoader(os.path.join(DATA_DIR, fichier))
                docs = loader.load()
                # Tag each chunk with its source document
                for doc in docs:
                    doc.metadata["module"] = fichier.replace(".pdf", "")
                documents.extend(docs)
            except Exception as e:
                print(f"Skipped {fichier}: {e}")  # Don't crash on encrypted PDFs
    return documents

def store_embeddings(chunks):
    embeddings = HuggingFaceEmbeddings(
        model_name="all-MiniLM-L6-v2",
        model_kwargs={"device": "cpu"}
    )
    # Explicit HTTP connection — not localhost, the Docker service name
    client = chromadb.HttpClient(host="chromadb", port=8000)
    Chroma.from_documents(
        documents=chunks,
        embedding=embeddings,
        collection_name=COLLECTION_NAME,
        client=client
    )
    print(f"Done — {len(chunks)} vectors stored")

Two things worth noting:

I tag each chunk with its source document name as metadata this allows the LLM to cite its source in the answer
The try/except is not optional one encrypted PDF (it happened) would have crashed the entire ingestion without it. Install cryptography if you hit an AES error: pip install cryptography

Step 2 : Building the RAG Chain

# src/rag_chain.py

import chromadb
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.llms import Ollama
from langchain_chroma import Chroma
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser

def create_rag_chain():
    # Must be the same model used during ingestion
    embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2")

    client = chromadb.HttpClient(host="chromadb", port=8000)
    vectorstore = Chroma(
        client=client,
        collection_name="documentation",
        embedding_function=embeddings
    )

    # Retrieve top 3 most relevant chunks
    retriever = vectorstore.as_retriever(
        search_type="similarity",
        search_kwargs={"k": 3}
    )

    llm = Ollama(
        base_url="http://ollama:11434",
        model="llama3",
        temperature=0.3,
        num_predict=250   # Cap response length — critical on CPU
    )

    template = """You are a technical support assistant.
Answer ONLY from the provided context. Cite your source.
If the answer is not in the context, say so clearly.

Context: {context}
Question: {question}
Answer:"""

    prompt = ChatPromptTemplate.from_template(template)

    def format_docs(docs):
        return "\n\n".join([
            f"[Source: {d.metadata.get('module', '?')}]\n{d.page_content}"
            for d in docs
        ])

    # The full pipeline in 4 steps
    return (
        {"context": retriever | format_docs, "question": RunnablePassthrough()}
        | prompt
        | llm
        | StrOutputParser()
    )

The chain is a pipeline: retriever → prompt → llm → parser. LangChain's | operator makes this clean and readable. Each step passes its output to the next.

Step 3 : API and Interface

FastAPI exposes the chain as a REST endpoint:

# src/main.py

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from rag_chain import create_rag_chain

app = FastAPI(title="Local RAG Assistant")
chain = create_rag_chain()

class QueryRequest(BaseModel):
    question: str

@app.post("/query")
def query(request: QueryRequest):
    try:
        answer = chain.invoke(request.question)
        return {"question": request.question, "answer": answer}
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Streamlit makes it usable in a browser in 10 lines:

# src/app.py

import streamlit as st
import requests

st.title("Technical Support Assistant")
question = st.text_input("Your question:")

if st.button("Search") and question:
    with st.spinner("Searching documentation... (1-2 min on CPU)"):
        r = requests.post(
            "http://python-api:8000/query",
            json={"question": question},
            timeout=600
        )
        st.write(r.json()["answer"])

What Broke (and How I Fixed It)

This is the part nobody writes about. Three real problems I hit.

Problem 1 : ChromaDB v2 silently ignoring my data

I was connecting with the old client_settings syntax:

# WRONG silently stores data locally instead of sending to the server
Chroma.from_documents(
    documents=chunks,
    client_settings=Chroma.Settings(chroma_server_host="chromadb")
)

The ingestion ran without errors, showed 9669 chunks stored but ChromaDB had 0 vectors. Querying returned nothing.

The fix explicit HttpClient:

# CORRECT explicit HTTP connection to the ChromaDB Docker service
client = chromadb.HttpClient(host="chromadb", port=8000)
Chroma.from_documents(documents=chunks, client=client, ...)

Also: the v1 heartbeat endpoint (/api/v1/heartbeat) is deprecated. Use /api/v2/heartbeat to check if ChromaDB is alive.

Problem 2 : LangChain moved its modules

# Broke silently after a LangChain update
from langchain.prompts import ChatPromptTemplate           # ❌ ModuleNotFoundError
from langchain.schema.runnable import RunnablePassthrough  # ❌ ModuleNotFoundError

# Everything stable lives in langchain_core now
from langchain_core.prompts import ChatPromptTemplate      # ✅
from langchain_core.runnables import RunnablePassthrough   # ✅

LangChain has been refactoring aggressively across versions. If you hit ModuleNotFoundError, check langchain_core first it's the stable base layer they're committing to not break.

Problem 3 : Llama 3 timing out on CPU

Llama 3 (8B parameters) on CPU generates roughly 2-5 tokens per second. A 200-word answer takes 2+ minutes. My 120-second timeout was too short.

Three things helped significantly:

Dropping k from 5 to 3 chunks shorter prompt = faster time-to-first-token
Adding num_predict=250 to cap response length without it, the model generates forever
Allocating more RAM to Docker via .wslconfig on Windows to avoid swap

Results

After setup, the assistant correctly answers questions grounded in the official documentation:

"How to close monthly payroll?" → Step-by-step procedure from the HR module manual
"How to create an account in the chart of accounts?" → Exact navigation path, source cited
"What does SYSCOHADA class 4 cover?" → Accurate definition from the accounting reference

And critically when the answer isn't in the documentation, it says so explicitly instead of hallucinating. That was the whole point.

Key Takeaways

On RAG:

The embedding model used during ingestion must be identical to the one used at query time. A different model produces incompatible vector spaces your similarity search returns garbage without any error message.

Chunk size matters more than expected. 500 characters worked less well than 300 for technical documents shorter chunks produce more precise retrieval.

Metadata on chunks is essential for source citation. Tag every chunk with its document name at ingestion time.

On local LLMs:

Running on CPU is slow but viable for non-real-time use cases like internal support tools.

num_predict is your most important parameter for performance. Without it, the model generates until it decides to stop sometimes never.

Docker container networking does not use localhost. Use the service name defined in docker-compose.yml (e.g., chromadb, ollama) as the hostname when connecting between containers.

This project is available on my github : https://github.com/josaphatstar/Assistant-Intelligent-RAG

What's Next

This RAG pipeline handles straightforward questions well. But it has a core limitation: it always does the same thing regardless of the question type. Whether you ask a procedural question or report a system crash, it searches the docs and answers. No reasoning about what strategy fits best.

In the next article, I'll show how I evolved this into an Agentic AI architecture with LangGraph where the system first decides which agent to call (documentation search, error diagnosis, or human escalation ticket), then acts accordingly.

I'm a Master's student in AI & Big Data, and this project came out of a real internship constraint no cloud, no API keys, just local infrastructure and open-source tools. I'm curious: have you built a local RAG pipeline under similar constraints? What stack did you use, and what broke first? Drop it in the comments I'd genuinely like to compare notes.

The Skill Level Of Young Developers Is Dropping. And Barely Anyone Wants To Admit It.

TAGBA G-Josaphat E. — Thu, 09 Jul 2026 20:39:32 +0000

Yesterday, during a class on advanced machine learning models, my professor said something that stuck with me.

"The skill level of young developers is declining year after year."

Not because they're less intelligent. Not because the curriculum is worse. But because they no longer take the time to think things through by themselves before handing their tasks off to AI.

He added something even more concrete: he sees this decline firsthand in the new interns he mentors. It's not an abstract trend for him it's something he watches happen in real time, intern after intern.

At first, it sounded like a slightly jaded professor's remark, the kind of comment every generation hears ("kids these days don't know how to do anything anymore"). But the more I think about it, the more I believe he's right, and that the problem runs deeper than we'd like to admit.

We're no longer learning through struggle

There's something essential about learning to code that we're losing: the struggle itself.

Spending two hours stuck on a dumb bug. Reading the same stack trace over and over. Searching, testing, failing, trying again. It's frustrating, sure. But that exact process is what builds real competence. It's by hitting the wall that you understand why a solution works, not just that it works.

Today, a lot of young developers never hit that wall anymore. They copy an error, paste it into an AI chat, grab a solution, and move on. The code works. But the understanding never actually happened.

The problem isn't the tool, it's the missing effort

I'm not saying AI is bad for learning to code that would be absurd, and a bit hypocritical since I use it myself every single day. The problem isn't the tool. The problem is using it to avoid effort instead of using it to support effort.

There's a huge difference between:

Using AI to understand something after you've tried to figure it out yourself, and
Using AI to avoid trying to figure it out yourself.

The first approach is a learning accelerator. The second is technical debt you take out against yourself and you'll pay it back later, with interest.

In 10-15 years: a shortage of real skill

Here's where I want to go with this, and it's the part that worries me the most.

If this trend continues, the average skill level of developers will keep dropping. Not dramatically or overnight, but slowly, generation after generation. More and more people will know how to "make code work," but fewer and fewer will actually understand what they're writing, be able to debug a complex problem without assistance, or design a solid architecture from scratch.

Meanwhile, AI itself will keep improving, taking up more space, automating more tasks. That creates a scissor effect: more people relying entirely on AI, fewer people capable of supervising it, correcting it, or solving the problems it can't solve on its own.

The result: in 10 or 15 years, the people who kept real technical depth — who kept understanding the fundamentals instead of systematically outsourcing their thinking will be extremely rare. And a rare skill, in a market that will always need it, comes at a very high price.

The two categories of developers

I think we're heading toward a split:

A large mass who know how to use AI but depend on it completely interchangeable, easily replaced.
A small minority who genuinely understand what they're doing, capable of stepping in wherever AI fails.

That second group will end up grabbing pretty much every interesting opportunity and the salaries that come with them.

What this means for us, right now

If this reasoning holds up, the real question isn't "should we use AI or not." The question is: are we using it to learn faster, or to stop learning altogether?

I think the best long-term strategy for any developer starting out today is to keep imposing difficulty on themselves on purpose. Solve problems without AI from time to time. Understand the "why" before asking for the "how." Treat AI like a demanding mentor, not a permanent shortcut.

Because in a few years, "knowing how to use AI" won't be what sets anyone apart. Everyone will know how to do that. What will matter is: who still has real technical skill behind it.

And those people will be few. Which is exactly what will make them valuable.

Do you notice this trend around you, in your classes, or with people you mentor? Curious to hear your take in the comments.

This is part of a series where I share my honest thoughts on AI, learning, and building in tech.

Follow along on Facebook

AI Is Killing the SaaS Model. And I Think That's a Good Thing.

TAGBA G-Josaphat E. — Sat, 27 Jun 2026 10:36:02 +0000

I'll be honest with you.

The last time I considered paying for a SaaS product, I caught myself thinking: "Wait. Could I just build this myself?"

And the answer, increasingly, is yes.

That moment changed something in how I see the software industry.

AI democratized building. Nobody fully processed what that means yet.

A few years ago, building a working web app required real technical depth. Months of learning. A team. Infrastructure knowledge. It was a high barrier and SaaS products existed precisely because most people couldn't build their own tools.

That barrier is collapsing.

With AI, a developer even a junior one can now conceive, design, and ship a functional application in days. Not months. A solo student in their bedroom can build what used to require a funded startup.

And here's the logical consequence nobody talks about enough: if anyone can build software, why would they pay someone else for it?

I already think this way. And I don't think I'm alone.

Before subscribing to any tool now, I ask myself three questions:

Do I actually need all the features this SaaS offers, or just 20% of them?
Could I build a lightweight version that does exactly what I need?
Would maintaining it be worth the subscription cost?

More and more often, the answer points toward building my own version.

Not because I'm cheap. But because AI makes it genuinely faster and easier to build a custom solution than to adapt my workflow to someone else's product.

A personal project management tool. A custom dashboard. A note taking app with exactly the features I want. A budget tracker built around my actual habits.

Why pay $12/month for a tool that does 80% of what I need when I can build 100% of what I need in a weekend?

The SaaS products that will suffer

Not all SaaS will die. But I think a specific category is in serious trouble: the simple, single-purpose tools.

The ones that do one thing. Solve one problem. The ones where the value proposition is essentially: "We built this so you don't have to."

That value proposition just got a lot weaker.

If your product's entire moat is "we wrote the code and you didn't have to" AI just erased your moat.

Think about:

Simple form builders
Basic invoice generators
Lightweight project trackers
Note-taking apps with no unique angle
Simple landing page builders

Every single one of these is now buildable by a motivated developer with AI assistance in a weekend.

The SaaS products that will survive

The ones that survive will have something AI-assisted solo development can't easily replicate:

Network effects value that comes from other users being on the platform
Data moats insights and intelligence that come from aggregating millions of users' data
Deep integrations years of ecosystem connections that would take months to rebuild
Compliance and trust regulated industries where "I built it myself" isn't good enough
Scale infrastructure the kind of backend complexity that goes far beyond a weekend project

Notion, Stripe, Figma, Linear, these aren't threatened by someone building their own version. They offer something fundamentally hard to replicate alone.

The $9/month form builder with no unique angle? That's a different story.

What this means for developers building SaaS today

If you're building a SaaS product right now, I think this is the most important question you need to answer honestly:

Could a motivated developer with AI assistance replicate your core value in a weekend?

If the answer is yes you have a problem. Not an immediate one. But a growing one.

The market for "we built this so you don't have to" is shrinking. The market for "we built something you genuinely couldn't build yourself" is still very much alive.

My honest take

I think we're entering a world where software splits into two categories:

Personal, custom tools built by individuals for themselves, free, perfectly tailored, AI-assisted
Platform-scale products with network effects, data, compliance, and infrastructure that individuals can't replicate

The middle ground the simple paid SaaS with no unique moat is going to get squeezed from both sides.

And honestly? I think that's good for users. We've been paying subscription fees for tools that were always a little too generic, a little too bloated, a little too expensive for what they actually delivered.

AI is giving us a way out.

What do you think are you starting to build your own tools instead of paying for SaaS? Or do you think paid products will always have an edge that self-built tools can't match?

This is part of a series where I share my honest thoughts on AI, learning, and building in tech.
*Follow along on Facebook

Is AI Making Us More Vulnerable? The Growing Threat of Cyberattacks in the AI Era

TAGBA G-Josaphat E. — Tue, 16 Jun 2026 18:55:50 +0000

Something feels different about security incidents lately.

Breaches, leaks, account takeovers, phishing campaigns they're not new. But their frequency, sophistication, and scale seem to be growing at a pace that feels genuinely alarming.

Instagram accounts hacked overnight. Corporate systems compromised in hours. Phishing emails that sound disturbingly human.

As someone studying AI & Big Data, I can't help but ask: is AI responsible for this? And if so, how?

I think the honest answer is: yes but in two very different ways.

The two faces of AI in cybersecurity

When we talk about AI and cyberattacks, most people imagine one scenario: hackers using AI to attack systems faster and smarter.

That's real. But it's only half the picture.

The other half is something we talk about far less: the vulnerabilities that come from integrating AI into systems in the first place.

These are two very different problems. And conflating them leads to the wrong solutions.

Problem 1: AI is expanding the attack surface

Every time a platform integrates an AI feature, they're adding something new to their infrastructure. And new infrastructure means new potential vulnerabilities.

AI systems require:

Massive data pipelines more data flowing through more systems
APIs connecting multiple services more endpoints that can be exploited
Third-party models and tools more external dependencies, more trust relationships
Real-time processing less time to detect anomalies before damage is done

Many organizations are integrating AI features faster than their security teams can audit them. And the consequences are already visible.

In June 2026, hackers reportedly manipulated AI-powered support systems to gain unauthorized access to Instagram accounts. The attack didn't target traditional software vulnerabilities it targeted the AI system itself, exploiting the automated account recovery flow that Meta had built with AI.

This is the new reality: attackers are no longer just targeting your code. They're targeting your AI pipelines, your automated flows, your trust relationships.

We've also seen entirely new categories of AI-specific attacks emerge:

Prompt injection tricking AI systems into ignoring their safety rules
Model poisoning corrupting training data to manipulate AI behavior
API abuse exploiting poorly secured AI endpoints to extract data or bypass authentication

Problem 2: Your supply chain is now a weapon

If you're a JavaScript developer, this one should concern you directly.

On May 11, 2026, between 19:20 and 19:26 UTC just six minutes an attacker published 84 malicious versions across 42 @tanstack/* npm packages. If you've built anything with React or modern JS tooling, you've almost certainly used TanStack. @tanstack/react-router alone has over 12 million weekly downloads.

The attack was elegant and terrifying. The attacker forked a TanStack repository, submitted a malicious commit, and triggered GitHub Actions to automatically build and publish the malware poisoning the CI/CD cache in the process. No npm tokens were stolen. The pipeline itself became the weapon.

The malicious packages could silently exfiltrate AWS credentials, GitHub tokens, SSH keys, and .npmrc contents automatically, on every developer machine that ran npm install.

The blast radius extended far beyond TanStack. Grafana Labs, OpenAI, and Vercel were all impacted through downstream dependencies. Other compromised packages included tools from Mistral AI, Bitwarden, and Aqua Security.

This wasn't an isolated incident either it was the fourth wave of an ongoing campaign by a threat group called TeamPCP, using a self-replicating worm dubbed "Mini Shai-Hulud."

The lesson? Every npm install is a trust decision. And most of us make hundreds of them without thinking.

Problem 3: Hackers are using AI to attack smarter

On the other side of the equation, the people attacking these systems are also using AI and it's fundamentally changing what attacks look like.

Phishing used to be easy to spot. Broken English, obvious templates, suspicious links. Most people learned to recognize them.

Now? AI generates phishing emails that are grammatically perfect, contextually relevant, and deeply personalized. It can scrape your LinkedIn, your GitHub, your public social profiles and craft a message that sounds like it came from your actual manager.

Microsoft tracked a phishing platform called Tycoon2FA that generated tens of millions of phishing emails per month and was linked to nearly 100,000 compromised organizations. At its peak, it accounted for roughly 62% of all phishing attempts Microsoft was blocking monthly. It didn't just steal passwords it intercepted MFA tokens in real time, defeating two-factor authentication entirely.

Nation-states are in this too. Microsoft and OpenAI confirmed that threat actors aligned with China, Iran, North Korea, and Russia are actively using large language models to enhance their offensive operations reconnaissance, scripting, social engineering at scale.

Voice cloning, deepfake video, AI-generated text all now available to attackers at low cost. What used to require an expert team can be done today with the right prompts and a modest budget.

So which is it AI in systems, or AI as a weapon?

Both. And they compound each other.

Organizations are rushing to integrate AI features to stay competitive, often outpacing their security practices. At the same time, attackers are rapidly adopting AI to improve their techniques. The result is a widening gap between attack capability and defense readiness.

It's not that AI is inherently dangerous. It's that speed of adoption without security rigor creates windows of vulnerability that sophisticated attackers are very good at exploiting.

Sam Altman himself acknowledged the possibility of a "world-shaking cyberattack" in 2026 as AI capabilities accelerate. That's not fear-mongering it's a signal that even the people building these systems know we're in uncharted territory.

What this means for you as a developer

A few concrete things worth thinking about:

Audit your dependencies the TanStack incident proves that even massively popular, well-maintained packages can be compromised
Harden your CI/CD pipelines GitHub Actions cache poisoning is a documented, repeatable attack class
Treat AI integrations like any third-party dependency understand their failure modes, limit their permissions
Be skeptical of any input that reaches an AI model prompt injection is real and underestimated
Educate your users the human layer is still the most exploited vector, and AI is making social engineering much harder to detect

The question I keep coming back to

We're in a moment where AI is being embedded into everything build pipelines, support systems, authentication flows faster than our collective ability to understand the risks.

The attacks we're seeing aren't theoretical anymore. They hit tools we use every single day.

So here's what I want to know: as a developer, how are you thinking about security in your own projects? Has the TanStack incident changed how you approach your dependencies?

Drop your take below especially if you've been directly affected by a supply chain attack.

This is part of a series where I share my honest thoughts on AI, learning, and building in tech *
*Follow along on Facebook

Learning to Code in the AI Era Feels Broken. And Nobody Talks About It.

TAGBA G-Josaphat E. — Wed, 10 Jun 2026 20:51:13 +0000

Let me be honest about something uncomfortable.

When you're learning to code today really learning, from scratch, fighting with syntax errors and logic bugs and CSS that refuses to behave there's a voice in the back of your head that won't shut up.

"AI could do this in 3 seconds."

That voice is brutal. And I think it's making learning harder than it's ever been.

When I started, AI wasn't there to do it for me

I started web development a few years ago. JavaScript was confusing. CSS felt like a random guessing game. I spent entire evenings debugging a function that turned out to have a missing semicolon.

But here's the thing: there was no shortcut. I had to figure it out. The struggle wasn't optional it was the path.

Every bug I fixed alone left a mark. Every concept I finally understood after hours of confusion became part of how I think as a developer.

Now I look at someone just starting out in 2024-2025 and I wonder: what is their path?

The new frustration nobody prepares you for

Imagine spending three days trying to understand how async/await works in JavaScript.

You watch tutorials. You read docs. You write broken code, fix it, break it again. You're exhausted.

Then a friend casually says: "Just ask ChatGPT, it'll write the whole thing for you."

And it does. Perfectly. In 4 seconds.

That feeling I don't have a perfect word for it. It's somewhere between frustration, discouragement, and a quiet existential question: why am I even doing this the hard way?

For someone just starting out, that feeling can be enough to make them quit. Or worse to never really start learning at all.

The gap between using and understanding

Here's what worries me most about the current moment.

There's a growing gap between two types of people in tech:

Those who can use tools to build things
Those who understand what's happening under the hood

AI is making the first group explode in size. Anyone can ship a working app today with minimal technical knowledge. That's genuinely amazing.

But the second group the people who truly understand systems, who can debug when things break in unexpected ways, who can make real architectural decisions that group is built through struggle. Through learning the hard way.

And right now, we're making the hard way feel pointless.

The basics still matter. Maybe more than ever.

I learned HTML before I touched any framework. I wrote vanilla JavaScript before I used Vue or React. I understood what a loop actually does before I let anyone human or AI write one for me.

That foundation is why I can look at AI-generated code and know if it's good, bad, or dangerous. It's why I can debug when things break. It's why I can have opinions about architecture instead of just accepting whatever the AI gives me.

If you skip the basics, you don't become a developer. You become dependent on a tool you don't understand.

And tools break. Tools change. Tools have limits you can't see if you don't know what's underneath.

So. Vibe coding.

If you haven't heard the term: vibe coding is the idea of building software almost entirely through AI prompts, with minimal traditional coding. You describe what you want, the AI builds it, you iterate.

Some people think it's the future of development. Some think it's a dangerous shortcut. Most of us are somewhere in the middle, figuring it out.

I genuinely don't have a definitive answer. But I have a question I keep coming back to:

If a new developer today learns entirely through vibe coding never really wrestling with the fundamentals what kind of developer are they in 5 years?

Are they more creative and productive because they offloaded the boring parts?

Or are they fragile, because they built on a foundation they never actually learned?

I don't know. But I think how we answer that question will define what "being a developer" means in the next decade.

What do you think? Should beginners learn the basics the hard way before touching AI? Or is vibe coding a legitimate new path into tech? Drop your take below I really want to know.

This is part of a series where I share my honest thoughts on learning, AI, and building a career in tech.
Follow along on Facebook

The Hidden Problem With Learning Through AI

TAGBA G-Josaphat E. — Wed, 03 Jun 2026 19:44:06 +0000

AI is an incredible learning tool. I said it in my previous article, and I still believe it.

But after spending months learning new web frameworks and technologies with AI as my main companion, I noticed something uncomfortable.

I was moving fast. But was I really understanding?

The old way was painful and powerful

Before AI, learning a new technology meant suffering.

You'd hit a bug. You'd search for hours. Read Stack Overflow threads, YouTube videos. Try things that didn't work. Get frustrated. Sleep on it. Come back the next day and finally click. It works.

That process was slow. Sometimes humiliating. Often exhausting.

But here's what I didn't realize at the time: that struggle was doing something to my brain.

Every hour spent searching, failing, and retrying was building a deep, almost physical understanding of the concept. When I finally found the solution, I owned it. I knew not just the answer, but every wrong path around it.

Now I just ask. And get an answer. Instantly.

With AI, that whole painful loop collapses into a single message.

Bug? Ask AI. Confusing concept? Ask AI. Don't know the right syntax? Ask AI.

The answer comes in seconds. Clean. Well-explained. Usually correct.

And I move on.

The problem is: moving on is not the same as understanding.

What I actually noticed

Learning Vue, Nuxt, and other web technologies with AI, I realized something: I needed to build far more projects than before to reach the same depth of understanding.

Without AI, one difficult project could teach me something deeply because I had wrestled with every problem alone.

With AI, I could finish that same project twice as fast, but the understanding was shallower. I had to build three or four more projects to reach the same level of genuine comprehension.

The friction wasn't just wasted time. The friction was the learning.

This doesn't mean AI is bad for learning

I'm not saying we should go back to suffering alone for hours.

What I'm saying is: we need to be intentional.

A few things that help me:

Try first, ask second. Before asking AI, I give myself at least 15-20 minutes to struggle alone. The struggle primes my brain to actually absorb the answer.
Ask AI to explain, not just fix. Instead of "fix this bug", I ask "why is this happening and what does it teach me about how this framework works?"
Build more, copy less. More small projects from scratch. Less copy-pasting AI-generated code without understanding it.

The bottom line

AI accelerates learning. But depth still comes from doing really doing and from the discomfort of not knowing yet.

The goal isn't to avoid AI. It's to use it without losing the struggle that makes knowledge stick.

Have you felt this too? Are you learning faster but sometimes feeling like things don't fully sink in? Let's talk in the comments.

Follow my journey on Facebook I share thoughts on tech, learning, and building in the open.

I'm a Master's Student in AI & Big Data. And AI Just Gave Me My Freedom Back.

TAGBA G-Josaphat E. — Tue, 26 May 2026 16:37:13 +0000

I'm currently preparing my Master's degree in AI & Big Data.

You'd think that means I spend my days confidently building neural networks, designing data pipelines, and shipping ML models. And in a way, yes — that's the curriculum.

But here's the thing no one really talks about in tech education: we learned a lot of things, and almost none of them deeply enough.

The paradox of a broad curriculum

In my program, we covered a bit of everything. Machine learning. Big Data architecture. Statistics. Cloud infrastructure. Web development. Databases. Computer vision. NLP.

Every few weeks, a new topic. Every few weeks, just enough to understand the surface before moving on.

I don't blame my professors or my school. That's just the nature of a two-year program trying to give you a panoramic view of a field that's enormous.

But it left me with a strange feeling: I knew about a lot of things, but I couldn't really do most of them.

And as graduation gets closer, the pressure grows: pick a lane. Choose a specialty. Decide who you are professionally.

Web developer? Data engineer? ML engineer? Backend dev? DevOps?

I had to choose — because that's how the job market works.

The cost of choosing

Here's what hurt the most about that choice: curiosity doesn't disappear when you pick a lane.

I chose to focus on web development alongside my studies — Vue/Nuxt, JavaScript, TypeScript, CSS. I love it. But I've always been drawn to everything else too.

I'd look at a computer vision project and think: "I want to build something like this."

I'd see a cool data pipeline and think: "I want to understand how that really works."

I'd read about systems programming, DevOps, mobile development, and feel that familiar pull.

But exploring those domains felt expensive. Not in money — in time and frustration. The entry cost for any new technical field is high: new syntax, new mental models, new tooling, new vocabulary. You spend weeks just getting comfortable before you can do anything interesting.

And with a Master's thesis, coursework, and personal projects already fighting for my attention, that entry cost was almost always too high.

So I held back. I watched from the edges.

Then AI changed the equation

When I started using AI as a learning companion — not just to generate code, but to actually explore — something shifted.

The entry cost dropped dramatically.

Now when I'm curious about something new, I don't have to start from zero alone. I have a thinking partner that:

Explains new concepts by connecting them to things I already know
Helps me read and understand code from domains I'm not fluent in
Answers the "dumb" questions I'd be embarrassed to ask anyone else
Turns a confusing error message into an actual learning moment

Want to understand how a Kafka pipeline works? I can explore it in a real conversation, mapped to my existing mental models — not by reading a dense 40-page documentation for two weeks.

Curious about how a specific ML architecture actually processes data? I can dig into it interactively, ask follow-up questions, build a mental picture.

The translation layer that used to take weeks now takes a conversation.

This is not about shortcuts

I want to be honest here, because I know how this sounds.

This is not about having AI do everything for me. It's not about faking expertise I don't have.

It's about removing the fear and friction of being a beginner in something new.

I still struggle. I still hit walls. I still have to put in real work to actually understand things. But now I can get to the interesting part — the part where concepts click, where I can build something small, where curiosity turns into real knowledge — without burning weeks just fighting the setup.

That changes everything about how willing I am to explore.

What I actually believe now

For a long time, I thought choosing one specialty was the only responsible path. The market rewards experts, right? Go deep. Become the AI person, or the frontend person, or the data person.

But I've started to think that framing was always a bit off.

The most impactful people in tech I look up to aren't people who know one thing incredibly well. They're people with wide peripheral vision — who understand enough about different domains to connect ideas, ask better questions, and see things that pure specialists miss.

AI didn't make me a generalist overnight. But it gave me permission to be curious without guilt, and the tools to turn that curiosity into something real.

Where I am now

I'm still a Master's student in AI & Big Data. Still building in Vue/Nuxt. Still figuring out what my career will look like.

But I no longer feel like I have to wall myself off from everything that isn't my specialty.

I explore data engineering because it helps me understand the full picture of what I'm studying.

I write frontend code because building things that people can see and touch keeps me grounded.

I poke at ML projects not because I'll be an ML researcher, but because understanding them makes me better at everything else.

Am I an expert in all of these? Absolutely not.

But am I afraid of any of them? Not anymore.

Are you also a student or early-career dev who feels pressure to specialize? How do you handle the tension between depth and curiosity? I'd love to hear your experience in the comments.