DEV Community: Kamaumbugua-dev

I Built an AI That Finds Your Bugs and Rewrites Your Code to Fix Them.

Kamaumbugua-dev — Sun, 15 Mar 2026 21:36:43 +0000

How I built CodeLens — a Groq-powered code review tool that detects SQL injection, memory leaks, and O(n²) algorithms, then rewrites your entire file with all issues resolved. Full breakdown of the architecture, prompt engineering tricks, and the LLM hallucination problem I had to solve.

Every developer has shipped a bug they should have caught.

Not because they were careless. Because code review is expensive. You're scanning hundreds of lines for subtle patterns: a missing conn.close(), an f-string wired directly into a SQL query, a nested loop that looks innocent at n = 10 but detonates at n = 10,000.

I wanted to build a tool that never gets tired, never misses a pattern, and can tell you exactly what will go wrong in production — before you push.

That's CodeLens.

What It Does

Paste any code. In seconds you get:

A health score (0–100) with an animated gauge
Every vulnerability categorized by severity: CRITICAL, WARNING, INFO
Exact line numbers, descriptions, fix suggestions, and predicted production impact
A "Rework Code" button that rewrites your entire file with every issue resolved, with inline # FIX: comments explaining each change

Here's what it catches on a simple Python file:

CRITICAL  SQL Injection            L7     f-string in cursor.execute()
CRITICAL  Hardcoded Credentials    L27    password = "admin123"
CRITICAL  Unsafe eval()            L29    eval(open("config.txt").read())
CRITICAL  Plaintext Card Numbers   L15    print(f"...card {card_number}")
WARNING   Resource Leak             L16    file handle never closed
WARNING   Resource Leak             L42    db connection never closed
WARNING   O(n²) Complexity          L46    nested loop over same list
WARNING   Unbounded Cache           L38    dict with no eviction policy
INFO      Division by Zero Risk     L50    len(transactions) unchecked

Health score: 28 / 100.

One click later, the LLM rewrites the file. Every issue fixed. Every change commented.

The Stack

Deliberately lean:

React 19 (Vercel)  →  FastAPI (Render)  →  Groq API (llama-3.3-70b)

No database. No auth. No queue. Every request is stateless — code goes in, analysis comes out.

The frontend is a three-panel layout:

Code editor — line numbers highlight affected lines in red
Analysis dashboard — health gauge, metric bars, issue list with severity filters
Vulnerability slides — right panel with CSS scroll-snap, one full-height card per vulnerability

The backend has three endpoints worth talking about: /analyze, /fix, and /github/analyze.

The Hard Part: Getting the LLM to Return Valid JSON Every Time

The analysis response needs to be machine-parseable. Every time. Across any language, any code quality, any edge case.

This is harder than it sounds. By default, models wrap JSON in markdown fences, add explanatory preamble, or truncate responses mid-object when they hit a token limit. Any of these breaks the frontend.

My system prompt ends with:

Return ONLY valid JSON. No markdown, no code fences, no explanation outside the JSON.

And I strip artifacts post-response with:

raw_text = re.sub(r"^```

(?:json)?\s*", "", raw_text)
raw_text = re.sub(r"\s*

```$", "", raw_text)
analysis = json.loads(raw_text)

This handles 99% of cases. The remaining 1% raises a json.JSONDecodeError that returns a structured 500 to the client.

The Line Number Hallucination Problem

This was the most interesting bug I fixed.

Early versions of CodeLens would confidently report issues on lines that didn't exist. A 50-line file would get issues flagged at lines 73, 91, 108. The model was pattern-matching against training data — it recognized the type of bug and estimated a line number based on where it typically appears in codebases it had seen, not in the code you gave it.

The fix is obvious in hindsight: give the model line numbers to reference.

Instead of sending:

import sqlite3

def get_user(username):
    query = f"SELECT * FROM users WHERE username = '{username}'"

I send:

1 | import sqlite3
2 |
3 | def get_user(username):
4 |     query = f"SELECT * FROM users WHERE username = '{username}'"

And I add an explicit constraint to the prompt:

The code has 50 lines total. You MUST only reference line numbers
that actually exist (1 to 50).

The implementation:

def add_line_numbers(code: str) -> str:
    lines = code.splitlines()
    width = len(str(len(lines)))
    return "\n".join(
        f"{str(i+1).rjust(width)} | {line}"
        for i, line in enumerate(lines)
    )

Hallucinated line numbers dropped to near zero. The model now has a concrete anchor instead of a floating reference.

The Rework Pipeline

The "Rework Code" feature is a second LLM call chained to the first.

After analysis, the frontend sends the original code + the full issue list to /fix:

class FixRequest(BaseModel):
    code: str
    language: str
    issues: List[Any]

The fix prompt encodes every issue as a line-referenced instruction:

Fix ALL of the following issues in this python code:

ISSUES TO FIX:
  - [Line 7] [CRITICAL] SQL Injection: Use parameterized queries
  - [Line 27] [CRITICAL] Hardcoded Credentials: Use os.environ.get(...)
  - [Line 29] [CRITICAL] Unsafe eval(): Use json.load() instead
  ...

ORIGINAL CODE:
{code}

Return the complete fixed code with inline FIX comments.

The system prompt is strict:

Return RAW CODE ONLY. No markdown fences, no explanation, no preamble.
Add inline comments prefixed with # FIX: explaining each change.

The result gets placed back into the editor. The user sees their fixed file immediately.

The CORS Bug That Burned Two Hours

Deploying to Vercel + Render exposed something I'd glossed over: allow_origins=["*"] and allow_credentials=True is invalid per the CORS specification.

Browsers enforce this at the preflight stage. Your OPTIONS request returns 200, but the browser rejects the response because the spec says wildcard origins cannot coexist with credentials. You get a cryptic console error and a silent failure in the UI.

The fix is one line:

app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],
    allow_credentials=False,  # must be False with wildcard origin
    allow_methods=["*"],
    allow_headers=["*"],
)

Worth knowing before you spend two hours debugging network tab preflight responses.

The Vulnerability Slides

The right panel uses CSS scroll-snap-type: y mandatory. Each vulnerability gets its own full-height card:

scroll-snap-type: y mandatory;

<div style={{ height: "100%", scrollSnapAlign: "start" }}>
  <VulnSlide issue={issue} />
</div>

There's a dot navigation sidebar that syncs with the scroll position:

onScroll={(e) => {
  const idx = Math.round(
    e.target.scrollTop / e.target.clientHeight
  );
  setActiveSlide(idx);
}}

Rounding (not flooring) prevents the active dot from flickering during the snap animation — the snap always settles on an integer, but scrollTop passes through fractional values mid-animation.

Each slide has a "SLIDE" button in the issue list that calls:

slidesRef.current.scrollTo({
  top: idx * slidesRef.current.clientHeight,
  behavior: "smooth"
});

Bi-directional sync between the list and the slides, no state management library needed.

Deployment Notes

A few things that bit me:

Render cold starts. The free tier sleeps services after 15 minutes of inactivity. First request after sleep takes 30–50 seconds. I added a loading state with an explanation so users wait instead of leave.

Vite bakes env vars at build time. VITE_API_BASE is injected into the bundle when Vercel builds — not at runtime. Old preview deployment URLs serve old bundles permanently. The production domain always reflects the latest build. If your frontend is still hitting the wrong backend, you're on an old preview URL.

Railway port mismatch. I originally deployed on Railway. The dashboard had the networking port set to 8000, but the $PORT environment variable was 8080. Internal healthchecks passed (Railway probed the container directly), but external traffic failed at the edge with persistent 502s. Moved to Render, problem gone.

Try It

Live: codelens-new.vercel.app

Source: github.com/Kamaumbugua-dev/CODELENS

Paste the worst code you can find. The demo loads a Python file with SQL injection, hardcoded secrets, unsafe eval(), and an O(n²) algorithm. Hit Analyze, then Rework. The whole thing takes about 10 seconds on a warm backend.

Built by Steven K. — Head of AXON LATTICE LABS™

CodeLens™ — See your code's future before it ships.

I Built an AI That Sees Your Screen and Speaks Your Answers, Here's How

Kamaumbugua-dev — Thu, 26 Feb 2026 22:26:53 +0000

I Built an AI That Sees Your Screen and Speaks Your Answers — Here's How

This post was created for the purposes of entering the Gemini Live Agent Challenge hackathon. #GeminiLiveAgentChallenge

The Problem With Typing

Every day we spend hours switching between tabs, typing search queries, copying text, and manually reading through pages trying to find answers. What if you could just look at your screen and ask a question out loud — and get an answer spoken back to you instantly?

That's exactly what I built.

Voice UI Navigator is an AI agent that:

👁️ Sees your browser screen using Gemini multimodal vision
🎙️ Listens to your voice via the Gemini Live API
🔍 Searches Google in real time to research answers
🔊 Speaks results back to you naturally

No typing. No DOM access. No browser extensions. Just pure visual AI understanding — the same way a human would look at a screen.

Live demo: https://voice-navigator-913580598688.us-central1.run.app
GitHub: https://github.com/Kamaumbugua-dev/GEMINI_CODING_CHALLENGE

How It Works

The agent has three core capabilities wired together:

User uploads screenshot + speaks query
              ↓
       ADK Web Server (Cloud Run)
              ↓
    root_agent [gemini-2.0-flash-live-001]
         ↓                    ↓
analyze_screenshot()     google_search()
         ↓                    ↓
  Gemini Vision         Google Search API
  (reads pixels)        (real-time results)
         ↓                    ↓
     Voice response spoken back to user

1. Screen Vision (No DOM Required)

The user takes a screenshot of their browser and attaches it in the chat. The agent calls analyze_screenshot(), which sends the image to gemini-2.0-flash with a structured prompt asking it to identify:

Page type and title
Visible UI elements (buttons, links, inputs)
Main content summary
Suggested next actions

The key insight: Gemini doesn't need DOM access to understand a UI. It reads pixels the way a human does — and it's surprisingly accurate.

2. Real-Time Voice (Gemini Live API)

The agent runs on gemini-2.0-flash-live-001, which supports bidirectional audio streaming. Google's ADK handles the /run_live WebSocket endpoint automatically — users just click the microphone button and start talking. The agent can be interrupted mid-sentence, just like a real conversation.

3. Google Search Grounding

When the user asks about something that needs current information, the ADK google_search tool kicks in — pulling real-time web results and weaving them into the spoken response.

Tech Stack

Component	Technology
Agent Framework	Google ADK v1.25.1
Live Voice Model	`gemini-2.0-flash-live-001`
Vision Model	`gemini-2.0-flash`
Search	ADK `google_search` tool
Hosting	Google Cloud Run
Container Registry	Google Artifact Registry
CI/CD	Google Cloud Build
Language	Python 3.11

Building It: The Code

The entire agent lives in two main components.

The Agent (`app/agent.py`)

from google.adk.agents import Agent
from google.adk.tools import google_search
from google.genai import types

root_agent = Agent(
    name="voice_ui_navigator",
    model="gemini-2.0-flash-live-001",
    description="Voice-powered agent that sees your screen and searches the web.",
    instruction="""You are a Voice UI Navigator.
    When the user shares a screenshot, call analyze_screenshot.
    Use google_search for research questions.
    Always respond conversationally — you are speaking to the user.
    Never access the DOM. Read screens visually only.""",
    tools=[analyze_screenshot, google_search],
    generate_content_config=types.GenerateContentConfig(
        speech_config=types.SpeechConfig(
            voice_config=types.VoiceConfig(
                prebuilt_voice_config=types.PrebuiltVoiceConfig(
                    voice_name="Puck"
                )
            )
        )
    ),
)

The Vision Tool (`analyze_screenshot`)

async def analyze_screenshot(tool_context: ToolContext) -> dict:
    # Load the screenshot the user attached in the chat
    screenshot_part = await tool_context.load_artifact("screenshot.png")

    # Fall back: find any image artifact in the session
    if screenshot_part is None:
        artifact_names = await tool_context.list_artifacts()
        image_artifacts = [n for n in artifact_names
                          if n.lower().endswith((".png", ".jpg"))]
        if image_artifacts:
            screenshot_part = await tool_context.load_artifact(image_artifacts[-1])

    # Send image + structured prompt to Gemini vision
    client = Client(api_key=os.environ["GEMINI_API_KEY"])
    response = client.models.generate_content(
        model="gemini-2.0-flash",
        contents=[types.Content(role="user", parts=[
            screenshot_part,
            types.Part.from_text(analysis_prompt)
        ])]
    )
    return json.loads(response.text)

The trick here is ADK's artifact system. When a user attaches a file in the ADK web UI, it's automatically stored as a session artifact. The tool retrieves it with tool_context.load_artifact() — no custom file upload endpoint needed.

Deploying to Google Cloud Run

The entire deployment is containerized with Docker and deployed to Cloud Run.

Dockerfile

FROM python:3.11-slim
WORKDIR /workspace
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app/ ./app/
EXPOSE 8080
CMD ["adk", "web", ".", "--host", "0.0.0.0", "--port", "8080"]

Important: Run adk web . from the parent directory of your agent folder — not from inside it. ADK scans for agent packages one level down from where the command runs.

Build and Deploy

# Build and push to Artifact Registry
gcloud builds submit \
  --tag us-central1-docker.pkg.dev/YOUR_PROJECT/voice-navigator-repo/voice-navigator

# Deploy to Cloud Run
gcloud run deploy voice-navigator \
  --image us-central1-docker.pkg.dev/YOUR_PROJECT/voice-navigator-repo/voice-navigator \
  --platform managed \
  --region us-central1 \
  --allow-unauthenticated \
  --port 8080 \
  --set-env-vars "GEMINI_API_KEY=your_key,GOOGLE_GENAI_USE_VERTEXAI=False"

Lessons Learned (The Hard Way)

1. ADK directory structure is strict

ADK's web loader scans ALL subdirectories of the agents folder looking for agent packages. I had a tools/ subfolder inside my app/ agent directory — ADK tried to load it as a separate agent and threw:

No root_agent found for 'tools'.

Fix: Move all tools into the main agent.py file, removing any subdirectories inside the agent package.

2. Not all Gemini models support Live API

I wasted time with gemini-live-2.5-flash-native-audio (doesn't exist), gemini-1.5-flash (no live support), and gemini-2.0-flash (no live support). Only gemini-2.0-flash-live-001 works with ADK's /run_live WebSocket for real-time audio.

3. Cloud Build uses the Compute Engine service account

When gcloud builds submit fails with permission denied on Artifact Registry, the fix is NOT granting the Cloud Build service account — it's granting the Compute Engine default service account:

gcloud artifacts repositories add-iam-policy-binding voice-navigator-repo \
  --location=us-central1 \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
  --role="roles/artifactregistry.writer"

4. gcr.io is deprecated

Google Container Registry (gcr.io) is being replaced by Artifact Registry (pkg.dev). Use Artifact Registry for new projects — gcr.io pushes will fail silently on newer GCP projects.

5. Separate the vision call from the live audio session

Initially I tried to have the live model handle both audio streaming AND vision analysis simultaneously. This caused instability. The cleaner pattern: make a separate synchronous gemini-2.0-flash call inside the tool for image analysis, while the live session stays focused on audio I/O.

What Surprised Me About Gemini Vision

I expected to need DOM access or accessibility APIs to understand UI elements. I was wrong.

Given just a raw screenshot, gemini-2.0-flash correctly identified:

Button labels and their positions on screen
Navigation menus and their items
Form fields and their purposes
The page's primary content and intent
Actionable next steps the user could take

This opens up a genuinely powerful use case: an AI that works on ANY screen — web apps, desktop software, mobile screenshots — without needing any special integration or API access.

What's Next

Browser extension — automatically capture screenshots without manual attachment
Action execution — integrate with Playwright to actually perform the suggested navigation steps
Multi-turn screen memory — remember previous screenshots to understand navigation flow over time
Mobile support — accept screenshots from phone cameras for on-device assistance

Try It Yourself

git clone https://github.com/Kamaumbugua-dev/GEMINI_CODING_CHALLENGE.git
cd "GEMINI_CODING_CHALLENGE/ADK-STREAMING"
pip install -r requirements.txt

# Add your Gemini API key to app/.env
echo "GEMINI_API_KEY=your_key_here" > app/.env
echo "GOOGLE_GENAI_USE_VERTEXAI=False" >> app/.env

adk web . --no-reload

Open http://localhost:8000, attach a screenshot, and ask the agent what it sees.

https://github.com/Kamaumbugua-dev/GEMINI_CODING_CHALLENGE/blob/master/ADK-STREAMING/deploy.sh

https://github.com/Kamaumbugua-dev/GEMINI_CODING_CHALLENGE/blob/master/ADK-STREAMING/cloudbuild.yaml

Resources

Built for the Gemini Live Agent Challenge. #GeminiLiveAgentChallenge

If you found this useful, drop a ❤️ and follow for more AI agent builds!

My BCG X GenAI Job Simulation: Building a Financial Analysis Chatbot & Key Learnings

Kamaumbugua-dev — Thu, 27 Nov 2025 16:23:07 +0000

How a virtual internship sharpened my skills in data wrangling, business logic, and user-centric AI development.

From Theory to (Simulated) Practice

We all have projects in our portfolios, but how do we know if they truly reflect the skills needed in a real-world, high-stakes environment? That was my goal when I completed the BCG X GenAI Job Simulation on Forage.

The task was classic BCG: practical, business-focused, and impactful. I was challenged to build a functional prototype of a Generative AI tool for financial statement analysis. This wasn't just about writing code; it was about creating a solution that a consultant could use to quickly derive insights from complex company data.

In this article, I'll walk you through the project and, more importantly, the core skills I honed along the way.

The Project: A Financial Query Bot

The core deliverable was a Python-based chatbot that could answer natural language questions about a dataset of company financials. The dataset was in a long format, meaning financial terms (like 'Total_Revenue' and 'Net_Income') were rows, not columns.

Here's a high-level overview of the solution I built:

# 1. Data Wrangling: From Long to Wide Format
df_wide = df.pivot(index=['Company', 'Year'], columns='Financial_Term', values='Value').reset_index()

# 2. Core Logic & Metric Calculation
total_revenue = df_wide['Total_Revenue'].sum()
net_income_change = df_wide_sorted['Net_Income'].iloc[-1] - df_wide_sorted['Net_Income'].iloc[-2]
highest_revenue_company = df_wide.groupby('Company')['Total_Revenue'].sum().idxmax()

# 3. The Chatbot Interface
def simple_chatbot(user_query):
    # ... NLP logic to match queries with pre-calculated answers
    if text == "what is the total revenue":
        return f"The total revenue is {total_revenue:,.2f}."
    # ... other queries

The final product was an interactive command-line tool that could instantly answer questions like:

"What is the total revenue?"
"How has net income changed over the last year?"
"Which company has the highest revenue?"

The Skills Forged in the (Simulated) Fire

While the code is crucial, the simulation forced me to think and operate like a BCG X developer. Here are the key skills I developed:

1. Data Engineering & Wrangling with `pandas`

The raw data wasn't ready for analysis. My first step was to pivot the DataFrame from a long to a wide format. This is a common, critical task in data science. I solidified my understanding of pandas operations like pivot(), groupby(), and sort_values() to structure data for efficient computation.

2. Translating Business Logic into Code

This was the heart of the simulation. It wasn't enough to just calculate a sum; I had to understand what to calculate and why.

"How has net income changed?" required me to sort the data by year and calculate the difference between the two most recent entries. This honed my ability to implement time-series analysis logic.
"Which company has the highest revenue?" involved a groupby operation to aggregate data by company before identifying the maximum. This reinforced data aggregation techniques for business intelligence.

3. Prototyping with Generative AI Principles

While the chatbot used a rule-based approach (pattern matching), its design embodies a core principle of GenAI: creating a natural language interface for complex systems. I learned to structure a system where a user's unstructured query is mapped to a structured data operation, which is the foundational concept behind many sophisticated AI tools.

4. User-Centric Development & UX

A tool is useless if no one can use it. I built an interactive loop with clear user prompts, a help menu, and graceful handling of exit commands. Focusing on the user experience, even in a CLI, taught me to think beyond the algorithm and consider the human interacting with my code.

5. Code Readability and Maintainability

I made sure to write clean, commented, and well-structured code. Using functions, clear variable names (net_income_change instead of nic), and f-strings for formatted output are essential practices for collaborating in a professional environment, just as one would at a firm like BCG X.

Key Takeaways for My Developer Journey

Business Acumen is a Feature: The most elegant code is worthless if it doesn't solve a real business problem. This simulation was a constant exercise in aligning technical execution with business needs.
Start Simple, Then Scale: A rule-based chatbot was the perfect prototype. It proved the concept's value before needing the complexity of LLM API calls, prompt engineering, and associated costs.
The "Why" Matters as Much as the "How": Understanding why a consultant needs to see net income change is what led me to implement the correct sorting logic. Context is everything.

Final Thoughts

The BCG X GenAI Job Simulation was more than a certificate for my LinkedIn profile. It was a rigorous, practical test of my ability to deliver an end-to-end solution under realistic constraints. It pushed me to merge data skills with business thinking, and it gave me a tangible project that demonstrates my readiness to contribute in a tech-driven, strategic role.

If you're a student or a developer looking to break into the tech/consulting space, I highly recommend seeking out these simulations. They are a powerful way to bridge the gap between academic knowledge and industry application.

Have you completed a similar job simulation or built a project that taught you unexpected skills? Share your experience in the comments below! Let's learn from each other.

Revolutionizing Loan Risk Assessment: How I Built a Smarter Default Prediction Model That Actually Understands Finance

Kamaumbugua-dev — Wed, 19 Nov 2025 19:08:03 +0000

The $5 Million Problem That Broke My Model

It was supposed to be a straightforward machine learning project: build a loan default prediction model. I had the algorithms, I had the data, and I had the code. But then I tested a scenario that should have been a no-brainer a borrower with a $5 million annual income applying for a $15,000 loan. My model panicked and flagged it as "HIGH RISK."

That's when I realized: most machine learning models understand data, but they don't understand finance.

Beyond the Algorithm: When Math Meets Reality

The initial approach was technically sound logistic regression combined with decision trees, proper normalization, all the ML best practices. But the real world doesn't care about technical purity. A billionaire applying for a car loan isn't high-risk, no matter what the raw numbers say.

The breakthrough came when I stopped treating this as purely a machine learning problem and started treating it as a financial intelligence problem.

def apply_business_rules(self, input_data, model_prediction):
    """The secret sauce: common sense meets machine learning"""
    income = input_data.get('income', 0)
    loan_amount = input_data.get('loanamount', 0)
    credit_score = input_data.get('creditscore', 0)

    base_prob = model_prediction['avg_prob']
    adjusted_prob = base_prob

    # Rule 1: Debt-to-Income Ratio Reality Check
    if income > 0:
        dti = loan_amount / income
        if dti < 0.1:  # Tiny loan for this income level
            adjusted_prob *= 0.3  # Drastically reduce risk

The Architecture That Actually Works

Dual-Layer Intelligence

Most models stop at the algorithm. Ours has two brain hemispheres:

1. The Machine Learning Brain

Logistic regression for linear patterns
Decision trees for complex interactions
Ensemble averaging for stability

2. The Financial Expert Brain

Debt-to-income ratio analysis
Income tier adjustments
Credit score reality checks
Employment stability factors

# This simple ratio check fixes 80% of "obvious" errors
if income > 0 and loan_amount / income < 0.1:
    adjusted_prob *= 0.5  # Halve the risk for tiny relative loans

Smart Data Agnosticism

The biggest headache in financial ML? Every dataset has different column names. Instead of forcing users to reformat their data, I built a detective:

def detect_column_types(self, df):
    """Speaks the language of finance, not just data science"""
    feature_patterns = {
        'income': ['income', 'salary', 'annual', 'wage', 'earnings'],
        'loansoutstanding': ['loan', 'outstanding', 'current', 'existing'],
        # ... and so on for other financial concepts
    }

The "Aha!" Moments That Transformed the Model

Moment 1: The Debt-to-Income Epiphany

I was so focused on absolute numbers that I missed the most basic concept in lending: relative capacity. A $15,000 loan means completely different things to someone making $50,000 versus $5,000,000.

Moment 2: The Credit Score Reality Check

Credit scores follow predictable patterns. Excellent credit (750+) isn't just slightly better than good credit (700-750)—it's a fundamentally different risk category that needed exponential, not linear, adjustment.

Moment 3: The Employment Stability Insight

Two years at a job isn't the same as twenty years. The model needed to understand that employment duration has diminishing returns on risk reduction.

Technical Innovation: Making Complex Simple

Performance That Doesn't Compromise Accuracy

The initial model took minutes to train. The final version? Seconds. Here's how:

def train_logistic_regression_fast(self, X, y, learning_rate=0.1, iterations=50):
    """Vectorized operations instead of Python loops"""
    m, n = X.shape
    weights = np.zeros(n)

    for _ in range(iterations):
        # Vectorized forward pass - 100x faster than loops
        z = np.dot(X, weights) + bias
        predictions = self.sigmoid(z)

        # Vectorized backward pass
        errors = predictions - y
        dw = np.dot(X.T, errors) / m

        weights -= learning_rate * dw

Error Resilience That Actually Works

Instead of crashing on missing data, the model adapts:

# If default column not found, create reasonable defaults
if 'default' not in prepared_data:
    prepared_data['default'] = [0] * len(df)
    st.warning("No default column found. Using dummy values for model training.")

Real-World Impact: From Theoretical to Practical

Before Business Rules:

$5M income + $15K loan = "HIGH RISK" (30% PD)
Recent graduate with good credit = "MODERATE RISK"
Long-term employee with minor credit issues = "HIGH RISK"

After Business Rules:

$5M income + $15K loan = "VERY LOW RISK" (2% PD)
Recent graduate with good credit = "LOW RISK"
Long-term employee with minor credit issues = "MODERATE RISK"

The Streamlit Revolution: Democratizing Financial AI

What makes this project truly powerful isn't just the model it's the accessibility. With Streamlit, we transformed complex financial modeling into:

One-click setup - No installation headaches
Automatic data understanding - Upload any CSV format
Real-time explanations - Not just predictions, but reasoning
Professional risk assessment - Actionable insights, not just percentages

# Transparent risk factors that build trust
factors = []
if income > 200000:
    factors.append("✅ High income level")
if credit_score > 750:
    factors.append("✅ Excellent credit score")
if loan_amount / income < 0.1:
    factors.append("✅ Low debt-to-income ratio")

Lessons for the Next Generation of Financial ML

1. Domain Knowledge Beats Algorithm Complexity

The business rules layer provided more value than any sophisticated algorithm ever could.

2. Performance Matters for Adoption

A model that trains in 30 seconds gets used. One that takes 5 minutes gets abandoned.

3. Explainability Builds Trust

Showing the "why" behind predictions makes the model credible to financial professionals.

4. Resilience Beats Perfection

A model that works with imperfect data is more valuable than one that only works with perfect data.

The Future Is Adaptive Intelligence

This project proved something crucial: the next breakthrough in financial technology won't come from better algorithms alone. It will come from models that understand the context, the nuances, and the real-world logic of finance.

The code is open, the approach is proven, and the results speak for themselves. We're not just predicting defaults anymore—we're building financial intelligence that actually understands what it means to lend money.

Want to see the model in action or implement these concepts in your organization? The complete code is available on [https://github.com/Kamaumbugua-dev/Loan-Default-Prediction-Model], and I'm always open to discussing how adaptive financial intelligence can transform your risk assessment processes.

The future of financial ML isn't smarter algorithms it's algorithms that understand finance.

From JPMorgan's Trading Desk to Your Terminal: Building a Natural Gas Storage Valuation Engine

Kamaumbugua-dev — Sun, 09 Nov 2025 21:54:03 +0000

How I reverse-engineered Wall Street's approach to energy trading and built a production-ready quantitative pricing system

The Billion-Dollar Problem

Imagine you're an energy trader staring at a complex proposal: a client wants to store 1 million units of natural gas for 6 months. They'll inject in summer when prices are low and withdraw in winter when prices typically spike. The question every trading desk faces: "What's the fair price for this storage contract?"

This isn't academic it's the exact challenge I tackled in a JPMorgan Chase quantitative research simulation. The result? A sophisticated valuation engine that bridges the gap between complex energy markets and executable trading decisions.

What I Built

At its core, my system solves the fundamental equation of energy storage:

Contract Value = (Withdrawal Revenue - Injection Costs) - (Storage + Fees + Transport)

But the devil is in the details. Here's how we tackled the complexity:

The Architecture Deep Dive

class NaturalGasStorageValuation:
    def calculate_contract_value(self, injection_dates, withdrawal_dates, 
                               injection_volumes, withdrawal_volumes, ...):
        # 1. Validate physical constraints
        self._validate_inputs(...)

        # 2. Create chronological operation timeline
        operations = self._create_operations_timeline(...)

        # 3. Calculate detailed cash flows
        cash_flows = self._calculate_cash_flows(...)

        # 4. Return comprehensive valuation
        return {
            'net_present_value': ...,
            'cash_flow_details': ...,
            'operations_summary': ...
        }

Key Innovations

1. Multi-Period Scheduling
Unlike simple buy-low-sell-high models, our system handles complex schedules:

Multiple injection/withdrawal dates
Varying volumes at each operation
Storage level tracking across time

2. Real-World Constraints
We enforced physical realities that make or break deals:

# Can't inject more than storage capacity
if current_storage + volume > max_capacity:
    raise ValueError("Exceeds storage capacity")

# Can't withdraw more than available
if current_storage < volume:
    raise ValueError("Insufficient inventory")

3. Comprehensive Cost Modeling
Every dollar counts in energy trading:

Storage Costs: Daily rental fees for the facility
Injection/Withdrawal Fees: Per-unit charges for moving gas
Transport Costs: Fixed fees for each delivery/pickup
Price Spread: The core profit driver

Real-World Impact

Sample Trade Analysis

Let's value a realistic storage contract:

result = valuation_model.calculate_contract_value(
    injection_dates=['2024-06-15', '2024-07-15'],
    withdrawal_dates=['2024-12-15', '2025-01-15'],
    injection_volumes=[500000, 500000],  # 1M MMBtu total
    withdrawal_volumes=[500000, 500000],
    storage_cost_per_day=3333.33,       # $100K/month
    transport_cost_per_trip=50000       # $50K per operation
)

print(f"Contract NPV: ${result['net_present_value']:,.2f}")
# Output: Contract NPV: $589,966.67

Why this matters: That $589K isn't just a number, it's the difference between profitable trading and catastrophic losses.

The Quant's Toolkit: Key Features

1. Intelligent Price Interpolation

def _get_price(self, date):
    # Handles dates between monthly settlement points
    # Uses linear interpolation for realistic pricing
    # Falls back gracefully when data is sparse

2. Production-Grade Error Handling

try:
    result = model.calculate_contract_value(...)
    if result['success']:
        # Trade with confidence
    else:
        logger.error(f"Valuation failed: {result['error']}")
except Exception as e:
    # Never break the trading desk

3. Comprehensive Reporting

Every valuation returns:

Net Present Value: The bottom line
Cash Flow Details: Daily money movements
Operation Summary: Volume and efficiency metrics
Cost Breakdown: Where money is spent

Technical Deep Dive: The Cash Flow Engine

The heart of our system is the cash flow calculator:

def _calculate_cash_flows(self, operations, ...):
    cash_flows = []
    current_storage = 0

    for operation in operations:
        # Calculate storage costs since last operation
        storage_cost = self._calculate_storage_cost(...)

        if operation['type'] == 'injection':
            # Purchase gas + pay injection fees + transport
            cost = (operation['volume'] * operation['price'] +
                    operation['volume'] * injection_fee +
                    transport_cost)
            current_storage += operation['volume']
        else:  # withdrawal
            # Sell gas - pay withdrawal fees - transport
            revenue = operation['volume'] * operation['price']
            cost = withdrawal_fees + transport_cost
            current_storage -= operation['volume']

        cash_flows.append({
            'date': operation['date'],
            'net_cash_flow': revenue - cost - storage_cost,
            'storage_level': current_storage,
            # ... detailed breakdown
        })

This granular approach means traders understand exactly when money moves and why.

Beyond the Code: The Trading Desk Impact

For Quantitative Analysts

Model Transparency: Every calculation is traceable
Scenario Analysis: Test "what-if" scenarios instantly
Risk Identification: Spot constraint violations before execution

For Energy Traders

Rapid Pricing: Value complex contracts in milliseconds
Client Confidence: Explain pricing with detailed breakdowns
Risk Management: Avoid physically impossible operations

For Software Engineers

Production Ready: Error handling, logging, validation
Extensible Architecture: Easy to add new cost components
API Ready: Structured for integration into larger systems

Surprising Lessons from the Trading Desk

1. Simple Beats Complex (Sometimes)

I started with sophisticated stochastic models, but the clean, interpretable approach won. Trading desks need to understand why a price is what it is, not just trust a black box.

2. Constraints Drive Value

The most insightful moment was realizing that storage contracts aren't about predicting prices,they're about efficiently managing constraints. The money isn't made in forecasting; it's made in optimization.

3. Error Messages Are Risk Controls

# This isn't just coding, it's risk management
raise ValueError("Withdrawal would exceed available storage")

Every validation check is a potential million-dollar save.

Getting Started with Energy Trading Analytics

Basic Setup

# Install dependencies
pip install pandas numpy

# Load your market data
price_data = load_natural_gas_prices()

# Initialize the model
model = NaturalGasStorageValuation(price_data)

# Start valuing contracts

Example Analysis

# Test seasonal storage strategy
summer_price = 10.50  # June injection
winter_price = 12.00  # December withdrawal
spread = winter_price - summer_price  # $1.50/MMBtu

# Our engine calculates if this spread covers:
# - 6 months of storage costs
# - Injection/withdrawal fees
# - Transport costs
# - And still leaves profit

Visualization: Seeing the Money Flow

We built a comprehensive dashboard system that shows:

Cash Flow Timeline: When money moves in and out
Storage Levels: Inventory tracking across time
Cost Breakdown: Where expenses accumulate
Sensitivity Analysis: How NPV changes with key inputs

Why This Matters for Your Career

This project demonstrates the exact skills that separate good developers from great quantitative engineers:

Financial Acumen: Understanding trading economics
Production Mindset: Building robust, error-resistant systems
Domain Knowledge: Speaking the language of energy markets
Architectural Thinking: Designing for scale and integration

What's Next?

The future of energy trading analytics includes:

Real-time Market Integration: Live price feeds and volatility modeling
Machine Learning: Predictive models for optimal injection/withdrawal timing
Blockchain: Smart contracts for automated settlement
API Deployment: RESTful services for front-office integration

Join the Discussion

I'm curious to hear from the community:

Energy Professionals: What other factors would you include in storage valuation?
Quant Developers: How would you enhance the modeling approach?
Trading Desk Veterans: What features would make this indispensable for daily use?
ML Engineers: Where would machine learning provide the most value?

Check out the complete code on GitHub and star the repo if you find this approach valuable for your own quantitative finance journey!

Ready to Build?

Whether you're interested in quantitative finance, energy markets, or building production financial systems, this project offers a realistic starting point. The code is battle-tested, well-documented, and ready for extension.

The bottom line: We've taken the black magic out of energy storage valuation and replaced it with transparent, reproducible mathematics. And in today's volatile energy markets, that's not just good engineering it's good business.

What complex financial system will you build next?

quantitativefinance #energytrading #python #financialengineering #jpmorgan #algorithmictrading #datascience #fintech #machinelearning #tradingSystems

This project was developed as part of a JPMorgan Chase quantitative research simulation, demonstrating real-world skills in financial modeling and software engineering.

From JPMorgan's Trading Desk to Your GitHub: Building a Natural Gas Price Forecasting Engine

Kamaumbugua-dev — Sun, 09 Nov 2025 20:24:39 +0000

How I reverse-engineered Wall Street quantitative research and what it taught me about production ML systems

The Quant's Crystal Ball

What if you could predict natural gas prices months in advance? What if you could build the same type of forecasting systems used by Wall Street energy traders? That's exactly what I did in a JPMorgan Chase quantitative research simulation, and I'm opening up the complete engine for everyone to see.

This isn't just another ML tutorial this is a production-ready forecasting system that demonstrates how quantitative research meets MLOps in real-world financial applications.

The Business Problem

Energy companies and traders face a critical challenge: how to price long-term natural gas storage contracts when prices fluctuate daily. The solution requires:

Accurate price estimates for any historical date
Reliable 12-month future forecasts
Understanding of seasonal patterns and market trends
A system robust enough for million-dollar decisions

Architecture Deep Dive

The Hybrid Forecasting Model

The core innovation lies in combining multiple analytical approaches:

class NaturalGasPriceAnalyzer:
    def build_prediction_model(self):
        # Polynomial regression captures market trends
        self.trend_model = Pipeline([
            ('poly', PolynomialFeatures(degree=3)),
            ('linear', LinearRegression())
        ])

        # Seasonal adjustments handle recurring patterns
        self.calculate_seasonal_adjustments()

The Secret Sauce: Trend + Seasonality

Most forecasting tutorials stop at basic time series. Our approach mirrors professional quant systems:

Price_estimate = Trend_prediction + Seasonal_adjustment

Trend Component: Uses polynomial regression to capture long-term market movements, economic factors, and structural changes.

Seasonal Component: Identifies recurring monthly patterns winter heating demand spikes, summer price dips that repeat annually.

Key Technical Insights

1. Seasonal Pattern Discovery

After analyzing 4 years of data, clear patterns emerged:

def analyze_seasonal_patterns(self):
    monthly_avg = self.data.groupby('month')['price'].mean()
    print(f"High season: December (${monthly_avg[12]:.2f})")
    print(f"Low season: May (${monthly_avg[5]:.2f})")

Finding: Prices peak in winter (December-February) due to heating demand and dip in late spring (May-June) when demand is lowest.

2. Market Volatility Quantification

def print_statistical_summary(self):
    returns = self.data['price'].pct_change().dropna()
    volatility = returns.std() * np.sqrt(12)  # Annualized
    print(f"Annualized volatility: {volatility:.2%}")

Result: 7.8% annualized volatility moderate fluctuations that create both risk and opportunity for traders.

From Research to Production

The MLOps Bridge

This project demonstrates crucial MLOps principles:

1. Production Data Pipelines

def load_data(self, data_string):
    # Parse financial data with proper error handling
    dates, prices = self.parse_financial_format(data_string)
    return self.create_features(dates, prices)

2. Model Interpretability

Clear separation between trend and seasonal components
Statistical summaries that business users understand
Visualization that tells the price story intuitively

3. API-Ready Design

def estimate_price(self, target_date):
    """Public method for integration into larger systems"""
    return self.trend_prediction + self.seasonal_adjustment

Surprising Lessons Learned

1. Simple Models Often Win

I started with complex LSTM networks, but polynomial regression + seasonal adjustments provided better interpretability and nearly identical accuracy for this use case.

2. Domain Knowledge > Algorithm Complexity

Understanding why gas prices behave certain ways (winter demand, storage cycles) proved more valuable than sophisticated algorithms.

3. Financial-Grade Code Matters

Proper datetime handling
Scientific notation parsing
Edge case management
Statistical rigor

Getting Started

Basic Usage

# Initialize and analyze
analyzer = NaturalGasPriceAnalyzer()
analyzer.load_data(your_price_data)
analyzer.build_prediction_model()

# Get price estimates
price = analyzer.estimate_price(datetime(2025, 1, 15))
print(f"January 2025 forecast: ${price:.2f}")

Advanced Features

# 12-month forecast
future_prices = analyzer.extrapolate_future_prices(12)

# Comprehensive visualization
analyzer.visualize_analysis()

# Seasonal pattern analysis
seasonal_insights = analyzer.analyze_seasonal_patterns()

Real-World Impact

This system demonstrates skills that directly translate to financial technology roles:

Quantitative Research: Statistical analysis, pattern recognition
Risk Management: Volatility calculation, confidence intervals
Trading Systems: Price forecasting, market analysis
MLOps: Production model deployment, monitoring

Why This Matters for Your Career

As I discovered through this JPMorgan simulation, the bridge between academic ML and production financial systems requires:

Business Acumen: Understanding the "why" behind the analysis
Technical Rigor: Production-quality code and statistical validity
Communication Skills: Explaining complex models to non-technical stakeholders

What's Next?

Potential enhancements for the ambitious:

Real-time data integration from market APIs
Confidence intervals and probability distributions
Multiple scenario analysis (bull/bear cases)
Web dashboard with Streamlit or Dash
Integration with trading platforms

Join the Discussion

I'm curious to hear from the community:

What forecasting challenges have you faced in your projects?
How do you balance model complexity with interpretability?
Have you worked with energy or financial time series data?

Check out the complete code on GitHub and star the repo if you find it useful for your own learning journey!

This project was completed as part of a JPMorgan Chase quantitative research simulation, demonstrating real-world skills in financial analysis and machine learning operations.

machinelearning #quantitativefinance #datascience #python #mlops #timetSeries #forecasting #jpmorgan

From Raw Data to HR Insights: My Journey Through Python-Powered Analytics

Kamaumbugua-dev — Wed, 03 Sep 2025 19:15:41 +0000

Over the past few weeks, I’ve taken a deep dive into HR analytics using Python. Starting with a dataset of employee records, I explored everything from basic data cleaning to advanced dimensionality reduction with PCA. This post is a reflection of what I’ve learned—broken down into four key stages: Exploratory Data Analysis (EDA), Business Analysis, Data Visualization, and PCA.

Whether you're an aspiring data analyst or an HR professional curious about data-driven decision-making, this walkthrough will show you how Python can turn spreadsheets into strategy.

Part A: Basic Exploratory Data Analysis (EDA)

Before diving into insights, I had to understand the data:

Loaded the dataset using Pandas and previewed the first few rows
Checked the shape to see how many rows and columns I was working with
Inspected column types to identify numerical, categorical, and date fields
Counted unique values to spot identifiers and categorical features
Identified missing values using .isnull() and planned data cleaning
Described numerical columns with .describe() to understand distributions
Plotted salary distribution with Matplotlib to detect skewness
Calculated average age from the DOB column using datetime operations
Compared employment status (active vs terminated) using .value_counts()
Identified largest departments using Seaborn’s countplot()

Part B: Business Analysis

Next, I tackled questions that HR teams care about:

Average salary by department using groupby()
Employment status breakdown with a pie chart
Gender pay comparison using Seaborn’s boxplot()
Top recruitment sources via .value_counts()
Diversity Job Fair attendance calculated from a Boolean column
Engagement scores by department with a barplot
Race-based salary averages using groupby() and .mean()
Projects vs salary correlation visualized with a scatterplot
Marital status and salary compared using a barplot
Manager team sizes identified with groupby().size()

Part C: Data Visualization

To make the data speak visually:

Salary histogram to show distribution
Department headcount with a countplot
Satisfaction scores by department using a barplot
Termination trends over time with datetime plots
Gender-based salary boxplot to highlight disparities
Performance vs salary stripplot to spot trends
Correlation heatmap to reveal relationships between variables
Engagement vs satisfaction scatterplot to explore alignment
Stacked bar chart of employment status across departments
Absenteeism distribution with a histogram

Part D: PCA (Dimensionality Reduction)

Finally, I explored Principal Component Analysis (PCA) to simplify the dataset:

Standardized features using StandardScaler() to prep for PCA
Applied PCA and interpreted the first two components
Plotted explained variance to understand dimensional importance
Visualized PCA-reduced data colored by department
Identified top contributing variables to PC1 and PC2
Condensed engagement, satisfaction, and absences into one dimension
Grouped employees by performance in PCA space
Compared clustering before and after PCA using KMeans
Created a PCA biplot to show feature loadings
Discussed PCA use cases in HR—like simplifying survey data or improving clustering

Final Thoughts

This journey taught me how to:

Clean and explore data with Pandas
Visualize insights with Seaborn and Matplotlib
Answer strategic HR questions with analytics
Simplify complexity using PCA

HR analytics isn’t just about dashboards—it’s about understanding people through data. Whether you're optimizing recruitment, improving engagement, or analyzing performance, Python gives you the tools to make smarter decisions.

Thanks for reading! If you’ve worked with HR data or PCA, I’d love to hear your experiences. Drop a comment or share your favorite Python trick for workforce analytics.

Supervised Learning and the Power of Classification.

Kamaumbugua-dev — Fri, 22 Aug 2025 00:37:03 +0000

In the ever-evolving world of machine learning, supervised learning stands out as one of the most intuitive and widely used approaches. At its core, supervised learning is about teaching machines to learn from labeled data—just like a student learns from examples given by a teacher. The goal is to build models that can make predictions or decisions based on new, unseen data.

What Is Supervised Learning?

Supervised learning involves training a model on a dataset that includes both input features and known output labels. The model learns the relationship between the inputs and outputs during training, and then applies that knowledge to predict outcomes for new data. It’s called “supervised” because the learning process is guided by the correct answers—like having an answer key during practice.

There are two main types of supervised learning:

Regression: Predicting continuous values (e.g., house prices).
Classification: Predicting discrete categories (e.g., spam vs. not spam).

This article focuses on classification, which is arguably the most practical and exciting branch of supervised learning.

How Classification Works

Classification is about sorting data into categories. For example, given a set of features about a student’s interaction with an AI tutor, can we predict whether they’ll use the system again? That’s a binary classification problem—yes or no.

The process typically involves:

Data Preparation: Cleaning, encoding categorical variables, and scaling numerical features.
Model Training: Feeding the labeled data into a classification algorithm.
Evaluation: Measuring performance using metrics like accuracy, precision, recall, and F1-score.
Prediction: Applying the trained model to new data.

Models Used for Classification

There’s no one-size-fits-all model. Each has its strengths depending on the data and the problem:

Logistic Regression: Simple, interpretable, and surprisingly powerful for linearly separable data.
Decision Trees: Easy to visualize and understand, but prone to overfitting.
Random Forests: An ensemble of decision trees that improves accuracy and reduces overfitting.
Naive Bayes: Fast and effective, especially for text classification.
K-Nearest Neighbors (KNN): Classifies based on similarity to nearby data points.
Gradient Boosting: Builds models sequentially to correct previous errors—great for complex patterns.
XGBoost: A high-performance version of gradient boosting, often winning machine learning competitions.

My Personal Views and Insights

What fascinates me most about classification is its versatility. Whether you're predicting customer churn, diagnosing diseases, or filtering spam, classification models are everywhere. I’ve found that the real magic lies not just in choosing the right algorithm, but in understanding the data deeply. Feature engineering—creating meaningful inputs—is often more impactful than tweaking hyperparameters.

I also appreciate how classification forces you to think critically about fairness and bias. A model that predicts loan approvals or job suitability must be scrutinized to ensure it doesn’t perpetuate discrimination. That ethical dimension makes classification not just technical, but profoundly human.

Challenges I’ve Faced

Working with classification hasn’t always been smooth sailing. Some of the hurdles I’ve encountered include:

Imbalanced Data: When one class dominates, models tend to ignore the minority class. Techniques like SMOTE or adjusting class weights help, but it’s tricky.
Overfitting: Especially with decision trees, models can memorize the training data instead of generalizing.
Feature Selection: Including irrelevant features can confuse the model, while excluding important ones can cripple it.
Interpretability vs. Accuracy: Complex models like XGBoost offer high accuracy but are harder to explain, which can be a problem in sensitive domains.

Despite these challenges, classification remains one of the most rewarding areas of machine learning. It’s where theory meets real-world impact, and every dataset tells a story waiting to be decoded.

Navigating the Trade-Off Between Type I and Type II Errors: A Medical Perspective

Kamaumbugua-dev — Thu, 21 Aug 2025 19:03:42 +0000

In the world of data science and machine learning, classification models are powerful tools for decision-making. However, every model comes with the risk of making mistakes—specifically, Type I and Type II errors. Understanding where to trade off between these errors is crucial, especially in high-stakes fields like medicine.

Understanding Type I and Type II Errors

Type I Error (False Positive): The model incorrectly predicts a positive result when the truth is negative. In medical terms, this could mean diagnosing a healthy patient as sick.
Type II Error (False Negative): The model incorrectly predicts a negative result when the truth is positive. In medicine, this means failing to diagnose a sick patient.

The Medical Scenario: Cancer Screening

Imagine a classification model designed to detect cancer from patient data. The stakes are high—both errors have serious consequences, but their impacts differ.

Type I Error in Cancer Screening

What happens? A healthy patient is told they might have cancer.
Consequences: Emotional distress, unnecessary further testing (which may be invasive or expensive), and potential side effects from unwarranted treatments.

Type II Error in Cancer Screening

What happens? A patient with cancer is told they are healthy.
Consequences: Missed early treatment opportunities, disease progression, and potentially fatal outcomes.

Where to Trade Off: The Decision

The trade-off between Type I and Type II errors is often visualized using the confusion matrix and controlled by adjusting the model’s decision threshold.

Lowering the threshold increases sensitivity (recall), reducing Type II errors but increasing Type I errors.
Raising the threshold increases specificity, reducing Type I errors but increasing Type II errors.

In Medical Practice

In cancer screening, minimizing Type II errors is usually prioritized. Missing a cancer diagnosis can be life-threatening, so the model is tuned to catch as many true cases as possible—even if it means more false alarms (Type I errors). This is why many screening tests are designed to be highly sensitive, accepting a higher rate of false positives to ensure that no true cases are missed.

However, the balance isn’t always the same. For diseases where treatment is risky or expensive, or where false positives cause significant harm, the threshold may be adjusted to reduce Type I errors.

Conclusion

The trade-off between Type I and Type II errors is context-dependent. In medical scenarios like cancer screening, the cost of missing a diagnosis (Type II error) often outweighs the cost of a false alarm (Type I error). As data scientists and practitioners, it’s essential to understand the domain and collaborate with experts to set thresholds that best serve patient outcomes.

References:

If you found this article helpful, follow me on Dev.to for more insights on data science in healthcare!

Predicting House Prices with Python: Data Cleaning, Modeling, and Feature Importance

Kamaumbugua-dev — Thu, 21 Aug 2025 16:23:09 +0000

Introduction

In this project, I tackled a classic machine learning problem: predicting house prices based on various property features. The journey involved real-world data cleaning, feature engineering, model building, and interpreting results using both standard regression metrics and ANOVA-based feature importance. Here’s a summary of my approach, key insights, and the skills I developed along the way.

Project Workflow

1. Data Cleaning

Real-world datasets are rarely perfect. My first step was to ensure the data was clean and consistent:

Standardized column names by removing extra spaces, converting to lowercase, and replacing spaces with underscores.
Handled missing values by filling numeric columns with their mean values.
Standardized categorical values (like location, furnishing, and house_condition) by correcting typos and ensuring consistent capitalization.
Converted categorical variables to numeric using one-hot encoding.
Ensured all features were numeric and dropped or filled any remaining missing values.
Removed duplicate rows to avoid bias in modeling.

2. Feature Engineering

Derived new columns where useful (e.g., converting year built to house age).
Prepared categorical features for modeling by encoding them numerically.

3. Model Building

Model Used: Linear Regression from scikit-learn.
Training/Test Split: 80% of the data was used for training, 20% for testing.
Evaluation Metrics:
- Mean Squared Error (MSE)
- Root Mean Squared Error (RMSE)
- Mean Absolute Error (MAE)
- R² Score

Results:

MSE: 7.80e-22 (almost zero)
RMSE: 2.79e-11 (almost zero)
MAE: 1.74e-11 (almost zero)
R² Score: 1.0 (perfect fit)

Note: Such perfect results are rare in real-world scenarios and may indicate a very simple dataset or potential data leakage. Always double-check your data pipeline!

4. Feature Importance with ANOVA

To understand which features most influence house prices, I used ANOVA (Analysis of Variance) via f_regression from scikit-learn. This provided F-values and p-values for each feature, highlighting their statistical significance.

Key Insights from ANOVA:

Most Important Predictors:
- Converted_datatype_for_price($), Size_sqft, Converted_datatype_for_size_sqft
- House_condition_New, House_condition_Old
- Has_pool, Year_built
Moderately Important:
- Furnishing_Semi-Furnished, Lot_size
Not Significant:
- Bath_rooms, Garage_available, Location_Urban, and others

Visualization

I visualized the F-values and p-values using a heatmap to quickly identify the most influential features:

import matplotlib.pyplot as plt
import seaborn as sns

heatmap_data = anova_results.set_index('Feature')[['F_value', 'p_value']]
plt.figure(figsize=(10, 6))
sns.heatmap(heatmap_data, annot=True, cmap='YlGnBu', fmt=".2e")
plt.title('ANOVA F-value and p-value Heatmap for Features')
plt.show()

Skills and Experience Gained

Data Cleaning: Learned to handle missing values, standardize data, and ensure consistency.
Feature Engineering: Gained experience in transforming and encoding features for machine learning.
Model Evaluation: Used multiple regression metrics to assess model performance.
Statistical Analysis: Applied ANOVA to interpret feature importance and guide model refinement.
Visualization: Created clear plots to communicate results and insights.
Critical Thinking: Recognized the importance of checking for data leakage and overfitting.

Conclusion

This project was a comprehensive exercise in the end-to-end machine learning workflow, from raw data to actionable insights. The experience reinforced the importance of data preparation, careful model evaluation, and statistical interpretation in building robust predictive models.

**Thanks for reading! If you have questions or want to discuss more about data science and machine learning, feel free to

AI Meets Cloud: My Experience Passing Oracle’s AI Foundations Associate Exam

Kamaumbugua-dev — Thu, 21 Aug 2025 16:21:55 +0000

👋 Hi Dev Community!

I’m thrilled to share that I recently passed the Oracle Cloud Infrastructure (OCI) 2025 AI Foundations Associate Exam (1Z0-1122-25) with a score of 88%, well above the passing threshold of 65%! 🎉

🆔 Oracle Testing ID: OC6613094
📅 Exam Date: August 5, 2025
✅ Result: Pass
📊 Score: 88% (Passing Score: 65%)

This certification wasn’t just a badge to collect — it was a deep dive into the growing convergence between cloud computing, artificial intelligence, and machine learning. As a developer and data science enthusiast, the journey equipped me with technical insights and practical knowledge that I’m already applying in real-world scenarios.

What the Certification Covers

The Oracle Cloud Infrastructure AI Foundations Associate exam** focuses on critical AI and ML concepts within the Oracle Cloud environment. Here are the core areas I mastered during preparation and testing:

OCI Generative AI Services
Learned how to use Oracle’s Generative AI APIs to build intelligent apps that can understand, summarize, translate, and generate human-like content. These services are key for modern applications that rely on LLMs (Large Language Models).

Use Case: Automating content creation, chatbots, document analysis, and code generation.

🔎 OCI AI Services Overview
Explored Oracle’s prebuilt AI services, which include:

Language and Speech
Vision (Image Analysis)
Anomaly Detection
Forecasting
Document Understanding

These allow developers to integrate AI into their applications without needing to build models from scratch**.

OCI ML Services Overview
Gained insight into OCI's machine learning lifecycle: from data ingestion and preprocessing to model training, deployment, and monitoring. The platform supports both automated ML (AutoML) and custom model development.

Oracle Vector Search
This was a particularly exciting topic! Vector Search enables semantic search by matching the meaning of queries with the content — not just the keywords. It's critical for applications like recommendation systems, search engines, and AI chat assistants.

Supervised Learning Fundamentals
The foundation of many AI systems — I reviewed core principles of:
Regression – Predicting numerical values (e.g., stock prices, weather).
Classification – Categorizing data (e.g., spam vs. not spam, fraud detection).

These are essential concepts for any data scientist or machine learning practitioner.

Why This Matters

Cloud-native AI and ML tools are becoming essential for building scalable, intelligent applications. Earning this certification confirms my capabilities not just in theory, but in applying these technologies using Oracle's enterprise-grade infrastructure.

Whether you're a developer breaking into AI or a cloud architect expanding your toolkit, understanding how services like OCI AI, ML, and Generative AI work together is a huge advantage.

What’s Next?

This certification is just one step in my learning journey. I'm now focused on:

Experimenting with Oracle’s Generative AI SDKs
Building real-world applications using Vector Search
Exploring advanced ML model deployment in OCI
Contributing more AI and ML content here on Dev.to

Final Thoughts

The world is moving fast — and those of us in tech need to move with it. This certification has given me both the confidence and competence to build in the AI space, and I encourage anyone interested to explore the Oracle Cloud learning path.

Have questions about the exam or want to discuss AI/cloud careers? Let’s chat in the comments!

Let’s connect:

🔗 www.linkedin.com/in/steven-mbugua-kamau

oracle #cloudcomputing #AI #MachineLearning #OCI #GenerativeAI #certification #career #datascience #developers

From Data to Predictions: My Journey Building a California Housing Price Model.

Kamaumbugua-dev — Wed, 13 Aug 2025 11:24:22 +0000

Over the past few weeks, I’ve been diving deep into machine learning by working on a project that predicts California housing prices. This hands-on journey not only strengthened my technical skills but also gave me a clearer understanding of the workflow that turns raw data into actionable insights.

In this article, I’ll walk you through:

What I built

The skills I gained

Why these skills matter in the real world

Project Overview
The goal was to build a regression model that could predict median house prices in California using the California Housing dataset.

Here’s the process I followed:

Loading the dataset

housing = datasets.fetch_california_housing()
x = housing.data
y = housing.target

This dataset contains information such as median income, house age, and average rooms per household.

Feature Engineering
I expanded the dataset using Polynomial Features to capture more complex relationships between the variables:

poly = PolynomialFeatures()
x = poly.fit_transform(x)

This generated 37 additional features essentially combinations and squared values of the original features giving the model more information to learn from.

Train-Test Split
To ensure the model could generalize, I split the data into training (80%) and testing (20%) sets.

Model Optimization
I experimented with different learning rates and iteration counts using the HistGradientBoostingRegressor, a powerful gradient boosting algorithm:

model = HistGradientBoostingRegressor(
    max_iter=350,
    learning_rate=0.05
)
model.fit(x_train, y_train)

Evaluation
I measured model performance using the R² score:

r2 = r2_score(y_test, y_pred)
print(r2)

This score reflects how well the model explains the variation in housing prices.

Model Deployment
I saved the trained model using joblib so it can be reused in future applications without retraining:

joblib.dump(model, "housing_price_model.joblib")

Key Skills I Gained
Data Preprocessing & Feature Engineering

Learned how to transform raw datasets into forms that machine learning models can better understand.

Understood the importance of feature interactions through polynomial feature expansion.

Model Selection & Optimization

Experimented with different learning rates, iteration counts, and model architectures.

Gained experience in tuning hyperparameters to balance accuracy and computational efficiency.

Model Evaluation

Applied the R² score to assess model performance.

Learned how to interpret evaluation metrics in a real-world context.

Model Persistence

Used joblib to save and load trained models — a critical skill for deploying ML solutions.

Why These Skills Matter
These skills aren’t just academic exercises — they’re exactly what data scientists and machine learning engineers use in real-world projects.

Feature engineering is the backbone of improving model performance.

Hyperparameter tuning can make the difference between an okay model and a production-ready one.

Model evaluation ensures you’re building something that works beyond your own dataset.

Model persistence bridges the gap between experimentation and real-world application.

With these capabilities, I can confidently approach real-world datasets, build predictive models, and prepare them for production environments.

Next Steps
This project has been a solid step forward in my machine learning journey. My plan is to:

Experiment with ensemble models to further improve performance.

Deploy the trained model via an API so it can be used in web applications.

Apply similar workflows to other datasets, such as sales forecasting and recommendation systems.

If you’re a developer or employer looking for someone who can turn data into decisions, this project is a small window into how I approach machine learning challenges in a way that is methodical, curious, and results-driven.

I’d love to hear your thoughts on how would you have improved this model?

DEV Community: Kamaumbugua-dev

I Built an AI That Finds Your Bugs and Rewrites Your Code to Fix Them.

What It Does

The Stack

The Hard Part: Getting the LLM to Return Valid JSON Every Time

The Line Number Hallucination Problem

The Rework Pipeline

The CORS Bug That Burned Two Hours

The Vulnerability Slides

Deployment Notes

Try It

I Built an AI That Sees Your Screen and Speaks Your Answers, Here's How

I Built an AI That Sees Your Screen and Speaks Your Answers — Here's How

The Problem With Typing

How It Works

1. Screen Vision (No DOM Required)

2. Real-Time Voice (Gemini Live API)

3. Google Search Grounding

Tech Stack

Building It: The Code

The Agent (app/agent.py)

The Vision Tool (analyze_screenshot)

Deploying to Google Cloud Run

Dockerfile

Build and Deploy

Lessons Learned (The Hard Way)

1. ADK directory structure is strict

2. Not all Gemini models support Live API

3. Cloud Build uses the Compute Engine service account

4. gcr.io is deprecated

5. Separate the vision call from the live audio session

What Surprised Me About Gemini Vision

What's Next

Try It Yourself

Resources

My BCG X GenAI Job Simulation: Building a Financial Analysis Chatbot & Key Learnings

How a virtual internship sharpened my skills in data wrangling, business logic, and user-centric AI development.

From Theory to (Simulated) Practice

The Project: A Financial Query Bot

The Skills Forged in the (Simulated) Fire

1. Data Engineering & Wrangling with pandas

2. Translating Business Logic into Code

3. Prototyping with Generative AI Principles

4. User-Centric Development & UX

5. Code Readability and Maintainability

Key Takeaways for My Developer Journey

Final Thoughts

Revolutionizing Loan Risk Assessment: How I Built a Smarter Default Prediction Model That Actually Understands Finance

The $5 Million Problem That Broke My Model

Beyond the Algorithm: When Math Meets Reality

The Architecture That Actually Works

Dual-Layer Intelligence

Smart Data Agnosticism

The "Aha!" Moments That Transformed the Model

Moment 1: The Debt-to-Income Epiphany

Moment 2: The Credit Score Reality Check

Moment 3: The Employment Stability Insight

Technical Innovation: Making Complex Simple

Performance That Doesn't Compromise Accuracy

Error Resilience That Actually Works

Real-World Impact: From Theoretical to Practical

Before Business Rules:

After Business Rules:

The Streamlit Revolution: Democratizing Financial AI

Lessons for the Next Generation of Financial ML

1. Domain Knowledge Beats Algorithm Complexity

2. Performance Matters for Adoption

3. Explainability Builds Trust

4. Resilience Beats Perfection

The Future Is Adaptive Intelligence

From JPMorgan's Trading Desk to Your Terminal: Building a Natural Gas Storage Valuation Engine

The Billion-Dollar Problem

What I Built

The Architecture Deep Dive

Key Innovations

Real-World Impact

Sample Trade Analysis

The Quant's Toolkit: Key Features

1. Intelligent Price Interpolation

2. Production-Grade Error Handling

The Agent (`app/agent.py`)

The Vision Tool (`analyze_screenshot`)

1. Data Engineering & Wrangling with `pandas`