DEV Community: Brandi

Why RiskLens CI Almost Broke Me

Brandi — Sat, 21 Mar 2026 22:24:29 +0000

The Beginning Looked Simple

When I started building RiskLens CI, the idea actually made sense to me.

Trigger on a GitLab merge request
Analyze code changes
Return risk level, issues, and recommendations

Conceptually… I understood it.

But the system itself? Completely different story.

It was running. The endpoint responded.

And I thought… okay this should be working.

It wasn’t.

This Felt More Advanced Than Anything I’ve Built

I’m going to be real here — this project felt advanced for me.

Not because I couldn’t understand the idea…

But because:

The system behavior was unfamiliar
The feedback loop wasn’t obvious
And small mistakes didn’t break things — they just made them worse

That part messed with me.

The “Almost Working” Stage Is the Worst

Everything looked like it was firing correctly:

Webhook → ✅
Backend → ✅
AI processing → ✅

But the results?

Slightly off
Missing detail
Not as “smart” as I expected

That’s when frustration really started setting in.

Because nothing was clearly broken.

Risk & Predictive Systems Are Not Forgiving

This is something I didn’t expect:

Risk assessment systems and predictive outputs are extremely sensitive.

If you’re not precise:

The risk score becomes meaningless
The issues feel generic
The recommendations lose value

And that’s exactly what I was seeing.

It wasn’t wrong… it just wasn’t useful.

What I Was Missing (And Didn’t Realize)

This is what took me the longest to understand:

I wasn’t missing logic — I was missing language

Sometimes it was:

One phrase in the prompt
One missing instruction
One unclear expectation

And that tiny gap changed everything.

When It Finally Clicked

This is when it started to feel real:

Now I was getting:

🔺 Risk Level: HIGH (75/100)
Clear summary of what was happening
Real issues tied to configuration + authentication
Recommendations that actually made sense

This wasn’t just output anymore.

This felt like a system.

What Changed Everything

I stopped thinking:

“Why isn’t this working?”

And started thinking:

“What EXACTLY am I not telling the system?”

That shift helped me:

Tighten my prompts
Be explicit about output format
Remove assumptions
Treat the AI like a strict executor

And that’s when everything came together.

The Frustration Was Real

There were moments where I felt like:

I was going in circles
The system was reacting but not improving
I was right there… but couldn’t see what was missing

That “almost working” phase is exhausting.

But it’s also where everything starts to click.

What I Learned

Precision > Complexity

Even simple ideas break without clear instructions.

AI Doesn’t Guess

If you don’t say it, it won’t do it.

Predictive Systems Require Control

You can’t be vague with risk analysis — you have to define everything.

Final Thoughts

If you’re building AI systems and feel stuck…

You’re probably not far off.

You might just be missing:

one phrase
one instruction
one piece of clarity

And once you find it — everything changes.

What’s Next

I’m continuing to evolve RiskLens CI into:

AI-powered code review assistant
Multi-agent analysis workflows
Automated fix + deployment previews

This is just the beginning.

If you're building something and it feels frustrating — especially with AI — you're not alone. You're probably closer than you think.

Building RiskLens CI: The Reality of AI + Dev Tooling Friction

Brandi — Thu, 19 Mar 2026 23:45:13 +0000

This one was different

I’ve built AI systems before.

RAG pipelines. Automation tools. Dashboards.

But building RiskLens CI?

This one pushed me in a different way.

Not because the idea was hard…

But because the environment was.

The constant back and forth

This wasn’t a straight build.

It was:

switching between tools
fighting with extensions
reconfiguring environments
debugging things that should have worked

And doing it over and over again.

One minute everything runs.

Next minute something breaks for no clear reason.

The hidden complexity of “AI-powered dev”

From the outside, it looks simple:

“Just use AI, build fast, ship.”

But in reality?

You’re dealing with:

API inconsistencies
environment mismatches
dependency conflicts
version issues across tools
cloud vs local differences

And when you’re building something like a CI assistant…

Everything has to work together.

The part nobody talks about

The frustration.

The restarting.

The feeling of:

“Why is this breaking again?”

It’s not just technical.

It’s mental.

Because you’re not solving one problem…

You’re solving layers of problems at the same time.

What RiskLens CI is teaching me

This project is teaching me:

how to debug across systems
how to work through unstable environments
how to stay consistent even when progress feels slow
how to build something that actually works

Real engineering vs perfect demos

There’s a difference between:

a demo that works once
a system that works consistently

RiskLens CI is forcing me into the second category.

Final thought

If you’re building with AI right now and feeling frustrated…

You’re not doing it wrong.

You’re just in the part nobody posts about.

👉 Full blog here:

https://bdcreativesystems-star.github.io/ai/career/machine%20learning/2026/03/19/getting-certified-in-ai-ml-while-watching-vibe-coders-move-faster.html

Why AI Systems Need Access Control (And What I Built)

Brandi — Thu, 19 Mar 2026 17:54:54 +0000

I Built a Secure AI Business Insights Agent (Because AI Needs Access Control)

Most AI projects focus on one thing:

👉 generating answers

But almost none focus on something just as important:

👉 who should be allowed to see those answers

So I built a Secure AI Business Insights Agent — a system designed not just to generate insights, but to control how those insights are accessed and used.

🧠 The Problem

AI systems today are incredibly powerful, but they often lack structure around:

who can access insights
what data is exposed
how agents act on behalf of users

In real business environments, this matters.

A system that gives the right answer to the wrong person is still a problem.

⚙️ What I Built

This project is a lightweight AI-powered dashboard that combines:

business data processing
insight generation
structured access awareness

The goal was to simulate how AI systems can operate in a more controlled and secure environment.

🧩 Core Features

📊 Generate business insights from data
🔐 Consider access control in how insights are delivered
🖥️ Simple dashboard interface (Streamlit)
⚡ Lightweight and fast to run

🛠️ Tech Stack

Python
Streamlit
Pandas
NumPy

🚀 Live Demo

You can try it here:

👉 https://secure-ai-business-agent-d8mdjkugcoresihnnsldqn.streamlit.app

🔍 What Makes This Different

A lot of AI tools today focus on output quality.

This project focuses on output responsibility.

That means thinking about:

whether the system should return an answer
what context is appropriate
how AI interacts with user roles

This is especially important as AI systems move into real business workflows.

🧠 What I Learned

This project reinforced that:

AI systems need more than intelligence — they need structure
access control is a critical part of AI design
even simple systems can model real-world constraints

🔮 What’s Next

Add authentication (Auth0 or similar)
Connect to live data sources
Expand into a multi-user system
Integrate LLM-based dynamic insights

💭 Final Thoughts

AI is moving fast.

But if we don’t think about security and control, we risk building systems that are powerful… but not practical.

This project is a small step toward building AI systems that are not just smart — but trustworthy.

If you're building AI tools, I’d love to hear how you're handling access control and security in your systems.

RAG + FastAPI in Action: Creating a Smart Business Analytics Dashboard in Python

Brandi — Thu, 19 Mar 2026 17:20:05 +0000

How I Built a RAG-Powered Business Insights Dashboard in Python + FastAPI

I have officially reached the point where I look at raw business data and think,

“Yeah... this needs a brain.”

So instead of building another dashboard that just throws charts on a screen and acts like that is enough, I decided to build something smarter: a RAG-powered Business Insights Dashboard using Python, FastAPI, embeddings, vector search, and LLM integration.

Because sometimes businesses do not just need data.

They need answers.

And preferably answers that do not require three meetings, five spreadsheets, and one person saying, “Let me circle back on that.”

This project was my way of combining backend engineering, AI workflows, and practical business use into one system that can actually help someone make decisions faster.

The Beginning (Where It Actually Started Working)

This was one of those small wins that felt bigger than it should have.

I finally got my FastAPI endpoint running locally, sent my first question through the system, and got a response back.

Was it perfect? Not even close.

Did it technically work? Yes.

And honestly… that is all I needed at that moment.

At this point, the system was not doing retrieval yet.

No embeddings. No vector search. No real intelligence.

It was basically just echoing my question back to me like:

“Hey, I hear you… I just don’t know anything yet.”

But that response meant the pipeline was alive:

FastAPI was running
The endpoint was working
The request/response cycle was solid

And that is where everything starts.

What I Wanted to Build

The goal was simple:

Build a dashboard where a user can upload business documents, reports, notes, or operational data, then ask questions in plain English and get useful, context-aware answers back.

Not generic AI answers.

Not hallucinated motivational speeches.

Not “As an AI language model...” nonsense.

I wanted the system to retrieve the right context first, then generate a grounded response based on the user’s actual business information.

That is where RAG comes in.

What Is RAG?

RAG stands for Retrieval-Augmented Generation.

At a high level, it works like this:

A user uploads documents or data.
The system breaks that content into chunks.
Those chunks get turned into embeddings.
The embeddings get stored in a vector database.
When the user asks a question, the system searches for the most relevant chunks.
The LLM uses those retrieved chunks to generate an answer.

So instead of the model guessing, it responds using actual information from the knowledge base.

Which is great, because guessing is fun in game shows, not in business reporting.

Why I Built This

I wanted to create something that felt more real-world than a standard chatbot.

A lot of businesses already have data.

What they do not always have is a fast way to turn that data into usable insight.

That gap is where this project lives.

This kind of system could be used for:

internal reporting
operational summaries
KPI analysis
executive question-answering
document intelligence
support for decision-making workflows

It is basically a way to make business data more conversational, more searchable, and a lot more useful.

The Tech Stack

Here is the stack I used for this build:

Python for the backend logic
FastAPI for the API layer
Embeddings model to convert text into vectors
Vector search for semantic retrieval
LLM integration for grounded answer generation
Frontend dashboard/UI for user interaction

This was the kind of project that reminded me why I like building AI systems in Python.

Python lets you move fast, wire things together cleanly, and feel powerful even while debugging something ridiculous.

Step 1: Ingesting the Data

The first step was getting the business content into the system.

That could include:

reports
PDFs
notes
CSV exports
internal documents
summaries
text-based records

Once the data came in, I needed to clean it and prepare it for retrieval.

That meant extracting text and splitting it into smaller chunks.

Why chunking matters

LLMs and vector search do not work well if you feed them giant walls of text.

So I split the documents into manageable chunks with overlap.

That overlap matters because context can get lost if you slice text too aggressively.

Too small, and the meaning disappears.

Too big, and retrieval gets messy.

Chunking is one of those quiet little engineering decisions that makes a huge difference later.

Step 2: Turning Text Into Embeddings

After chunking the content, I converted each chunk into an embedding.

An embedding is a numeric representation of text.

It captures semantic meaning so that similar ideas end up close together in vector space.

In normal human terms:

the system starts understanding that “revenue dropped last quarter” and “sales declined recently” are related, even if the words are not identical.

That is what makes semantic search so powerful.

Instead of keyword matching, the system can search by meaning.

Which is good, because business people do not all ask the same question the same way.

One person asks:

“Why are profits down?”

Another asks:

“What changed financially in Q4?”

Another asks:

“Why does this spreadsheet hate us?”

Same family of problem.

Step 3: Storing Embeddings for Vector Search

Once the embeddings were created, I stored them in a vector index so the application could retrieve the most relevant chunks later.

This is the core of the retrieval layer.

When a user asks a question, the system does not scan documents the way a normal search engine would.

Instead, it converts the question into an embedding too, then finds the closest matching chunks based on vector similarity.

That is the magic behind vector search.

It is less about exact words and more about conceptual closeness.

So if the uploaded document contains something like:

The policy period is effective from January 1, 2026 through December 31, 2026

and the user asks:

Where is the policy period located?

or even:

What are the coverage dates on this policy?

the system still understands what the user is trying to find.

That is because embeddings capture meaning, not just keywords.

Which is important… because nobody asks insurance questions the exact same way.

One person asks:

“Where is the policy period?”

Another asks:

“What dates does this policy cover?”

Another asks:

“When does this thing even start and end?”

Same question. Different wording. Same intent.

And this is exactly where traditional keyword search starts to struggle.

But with vector search, the system can connect those dots and return the right section of the document without needing perfect phrasing.

That is what makes this architecture so powerful for document-heavy workflows like insurance, contracts, and compliance.

Step 4: Building the Retrieval Pipeline

Once the vector store was ready, I built the retrieval flow.

The pipeline looked something like this:

Receive the user’s question
Convert the question into an embedding
Search the vector database for the most relevant chunks
Return the top matching results
Pass those results into the LLM prompt
Generate a grounded answer

This is where the application starts to feel smart.

Because now the model is not just answering from general training.

It is answering from retrieved business context.

That difference matters a lot.

Without retrieval, an LLM can sound polished and still be wrong.

With retrieval, the answer has a much better chance of being relevant, specific, and actually helpful.

Step 5: Integrating the LLM

After retrieval, I passed the relevant chunks into the LLM with a prompt that basically said:

here is the user’s question
here is the retrieved context
answer based on this context
stay grounded in the source material

This step is where the user gets the final result.

The LLM is not acting like a standalone oracle.

It is acting more like a reasoning layer on top of retrieved knowledge.

That was important to me because I did not want a flashy chatbot.

I wanted a useful system.

The LLM’s job was to:

summarize findings
explain trends
answer business questions clearly
stay tied to the source content

In other words, I wanted intelligence with receipts.

Step 6: Wrapping It in FastAPI

To make the system usable, I built the backend in FastAPI.

FastAPI was a strong fit for this project because it is lightweight, fast, and works really well for AI-powered backend services.

I used it to handle things like:

file upload endpoints
document processing
query submission
retrieval logic
response generation

One thing I like about FastAPI is that it stays out of your way.

It lets you focus on building the actual system instead of fighting the framework.

And for AI tools, that matters.

Because trust me, the AI side will already provide enough “character building moments.”

When It Finally Clicked (The System Actually Thinking)

This was the moment where everything came together.

Not just an API responding.

Not just a model generating text.

But an actual system retrieving the right context and answering based on real data.

Document: Insurance policy (11 pages)

Chunks created: 46

Model: Local LLM (Llama3 + RAG pipeline)

I uploaded a document, asked a question, and the system:

found the correct section
identified the exact page
returned a grounded answer
included source references

That is when it stopped feeling like a project…

and started feeling like a real product.

No guessing. No vague responses.

Just:

“Here is your answer, and here is exactly where it came from.”

That level of clarity is what makes RAG systems powerful in real-world use.

Because businesses do not just want answers.

They want answers they can trust.

Step 7: Creating the Dashboard Experience

Once the backend was working, the next piece was the dashboard itself.

I wanted the UI to feel practical and clean:

upload data
ask questions
view answers
surface insights in a usable format

The real value of the system is not just that it can answer questions.

It is that it gives users a more natural interface for interacting with business information.

Instead of digging through files, filtering endless tables, or guessing where the answer might live, they can just ask.

That shift is huge.

A good AI dashboard should reduce friction, not create a new kind of complicated.

What Made This Project Interesting

This project brought together several parts of modern AI engineering in one place:

Backend API design

I had to structure the application in a way that was modular, clean, and scalable.

Document ingestion

Getting data into the system in a usable format is always more work than it sounds.

Embeddings and semantic search

This is where the system starts becoming intelligent instead of just reactive.

LLM orchestration

Prompt design, retrieval flow, and answer grounding all matter here.

Real-world usefulness

This was not built as a gimmick. It was built as a system that could support actual business workflows.

That combination is exactly the kind of work I enjoy most.

Challenges I Ran Into

Like every AI project, this one had its moments.

And by “moments,” I mean those fun little stretches where everything should work in theory, but reality has other plans.

A few of the main challenges were:

Chunk quality

If the text chunks were too small, retrieval lost meaning.

If they were too large, results became noisy.

Retrieval relevance

Not every returned chunk was equally useful, so tuning retrieval mattered.

Prompt structure

The LLM needed enough context to answer well without getting overloaded.

Keeping answers grounded

It is one thing for an answer to sound smart.

It is another for it to actually be correct.

That is one reason I like RAG so much.

It gives you a framework for making LLM outputs more trustworthy.

Why This Matters for Real Businesses

A lot of companies are sitting on useful information, but they cannot access it quickly.

The data exists.

The reports exist.

The documents exist.

But the workflow for turning all that into insight is still too manual.

A system like this helps bridge that gap.

It can support teams that need to:

analyze internal reports faster
answer operational questions
search through business documentation
generate summaries from existing knowledge
make decisions with better context

That is where AI becomes valuable to me — not as a toy, but as a working layer inside a real process.

What I Learned

This build reminded me that strong AI systems are not just about plugging in an LLM.

The real work is in the architecture.

You need:

clean ingestion
smart chunking
solid embeddings
useful retrieval
grounded prompting
a clean API layer
a user experience that makes the system worth using

That is the part I enjoy most: building systems where all the pieces actually work together.

Because anybody can say “AI-powered.”

I want to build things that earn the label.

Final Thoughts

Building this RAG-powered Business Insights Dashboard was one of those projects that perfectly blended software engineering and AI system design.

It was technical, practical, and honestly a lot of fun to build.

I got to work across:

Python development
FastAPI architecture
embeddings
vector search
retrieval pipelines
LLM integration
intelligent dashboard workflows

And more importantly, it solved a real problem.

That is always the goal.

I am not interested in building AI just to say I built AI.

I want to build tools that help people work smarter, move faster, and get better answers from the information they already have.

And if I can do that without the dashboard looking like it was designed during a spreadsheet-induced panic attack, even better.

Tech Used

Python
FastAPI
Retrieval-Augmented Generation (RAG)
Embeddings
Vector Search
LLM Integration
AI-Powered Business Intelligence Workflows

Closing

Projects like this are exactly why I enjoy building AI/ML software.

I like creating systems that go beyond static dashboards and basic automation — tools that can actually understand context, retrieve meaningful information, and return useful answers in real time.

This is the kind of work I want to keep building more of.

If you are working on AI tools, backend systems, or intelligent business applications, this space is only getting more interesting.

I Didn’t Quit… I Built an AI Instead 💻

Brandi — Wed, 18 Mar 2026 19:04:17 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

I Built a Secure AI Business Insights Dashboard (With Login + AI Recommendations)

Brandi — Tue, 17 Mar 2026 18:48:20 +0000

🚀 Project Overview

I built a Secure AI Business Insights Agent designed to simulate a real-world internal business tool — not just a dashboard, but a system that combines authentication, analytics, and AI-generated insights.

🔐 Why This Matters

Most dashboards show data.

But businesses don’t need more charts — they need actionable insights and secure access to sensitive information.

This project focuses on:

Turning raw data into decisions
Protecting access with authentication
Simulating real internal AI tools

🔑 Key Features

✔ Secure login system (protected access)

✔ AI-generated business insights

✔ KPI tracking and forecasting

✔ Clean dashboard UI using Streamlit

📊 Dashboard Highlights

Revenue and order tracking
Monthly trend visualization
Regional performance breakdown
AI-style recommendations based on patterns

🛠 Tech Stack

Python
Streamlit
Pandas
NumPy

🌐 Live Demo

👉 Try it here:

https://secure-ai-business-agent-d8mdjkugcoresihnnsldqn.streamlit.app

💻 GitHub

👉 View the code:

https://github.com/bdcreativesystems-star/secure-ai-business-agent

🔮 What’s Next

Role-based access (admin vs user)
Real data integrations
Advanced ML forecasting models

💡 Final Thoughts

I’m focused on building real-world AI tools, dashboards, and automation systems that businesses can actually use — not just experiments.

If you’re working on something similar or have ideas, I’d love to connect.