DEV Community: Nikita Gupta

How I Built a Lightweight Local AI Assistant (Python + PyQt6 + Ollama)

Nikita Gupta — Mon, 13 Jul 2026 19:08:52 +0000

I built a fast, privacy focused desktop assistant by keeping the architecture modular and lightweight.

The Tech Stack
->Python & PyQt6 (Frontend UI and Screen Capture)
->Ollama API (Local LLM Backend)
->PyInstaller (Standalone Packaging)

Why Decouple the UI from Ollama?
Instead of embedding a multi-gigabyte model file directly into the application, I used a client-server split.

Lightweight Executable: The desktop app stays tiny because Ollama handles the heavy model inference externally in the background.

Resource Efficiency: System RAM and VRAM are managed dynamically by the operating system rather than choking a single monolithic process.

Solving the Windows DPI Scaling
A core feature is a custom screen-snipping tool. However, Windows DPI virtualization often desyncs logical mouse coordinates from physical screen pixels, causing cropped selections to pull from completely wrong areas.

Instead of relying on flaky operating system scaling multipliers, I bypassed the issue using direct dynamic ratio calculations, Capture the raw full-screen image first.

Calculate the exact mathematical ratio between the physical image size and the widget size.
Multiply the user's selection coordinates by that ratio to crop exact physical pixels cleanly.

Packaging It Up
By separating the UI and application logic from the raw model weights, compiling a clean, portable standalone .exe using PyInstaller takes seconds and avoids massive build file sizes.

Keeping your AI engine external isn't just easier to build, it is a cleaner, more scalable architecture for local desktop software.

Fixing My House Price Prediction App

Nikita Gupta — Sat, 11 Jul 2026 08:33:28 +0000

I built a web app that estimates house prices. You type in details about a house like its location, age, and number of rooms and a machine learning model calculates a price based on historical data.

I ran into two main bugs that stopped the app from making predictions. Here is what happened and how I fixed the code.

The Webpage Crash The Problem: As soon as I started the server and opened the website, it crashed completely.

The Cause:
The code for the webpage was designed to remember what you typed into the form so your numbers wouldn't disappear after you clicked "Predict." However, when you load the page for the very first time, you haven't typed anything yet. Because that data was missing, the webpage panicked and broke.

The Fix:
I updated the backend code to hand the webpage a blank slate (an empty set of data) when it first loads. This gave it what it needed to load normally without crashing.

The Data Mismatch The Problem: Once the webpage was loading properly, I tried to predict a price. It failed again, throwing errors about a "shape mismatch."

The Cause:
Before the machine learning model can predict a price, the input numbers have to be scaled down by a mathematical tool. When I trained this model, that tool was built to handle exactly 10 numerical inputs. But my app was trying to hand it 15 inputs all at once, including text-based choices like "Ocean Proximity." It didn't know how to handle the text, so it threw an error.

The Fix:
I split the background process into two steps. First, the code separates the 10 numbers and scales them properly. Then, it takes the text choice (like whether the house is near the ocean), translates it into a format the computer understands, and attaches it back to the numbers. This gave the model the exact 15-piece format it was expecting.

Wrapping Up
I also added a safety net to the code so that if an error like this happens again, it displays a clean message on the webpage instead of crashing the whole server. Once the predictions were calculating correctly, I saved the changes and pushed the updated code to my GitHub repository (https://github.com/nikitagpt05/House-Price-Prediction). The app is back up and running.

Why 97% Accuracy is a Lie: My Journey from ANN to CNN

Nikita Gupta — Mon, 06 Jul 2026 15:34:15 +0000

You know the feeling. Your model trains perfectly, the validation loss drops, your accuracy hits a 97.5% on the MNIST dataset and it feels like it might work fine.

Then you build a real-time UI, test it yourself, and your model completely falls apart.

That is exactly what happened with my latest project: a real-time handwritten digit recognizer built with PyTorch and Pygame.Here is how my "perfect" Artificial Neural Network (ANN) failed in the real world, and the engineering steps I took to fix it.

The Setup
The goal was simple. Build a black Pygame canvas where a user can draw a number (0-9) with their mouse, and have a PyTorch model predict the number the moment they release the click.

I started with a standard flattened ANN. It trained. But the second I drew a number on the screen, it guessed wrong almost every time.Especially numbers like 6,7,8,9.

The Problem: Domain Shift
The issue was Domain Shift.

An ANN flattens a 28x28 image into a 1D array of 784 pixels. It doesn't actually understand shapes; it just memorizes where bright pixels should be.

The Dataset: The MNIST training data has perfectly centered, thin pen strokes.
The Real World: My Pygame digital brush was thick. My hand jittered. The numbers weren't perfectly centered.

Because the lines were thicker, the pixels didn't perfectly align with the ANN's expectations, and it completely failed to recognize the numbers.

The Experiment: The "Model Arena"
To fix this, I decided to upgrade to a Convolutional Neural Network (CNN), which actually looks for edges, curves, and loops using spatial filters.

But I wanted to prove it was better. So, I built a Model Arena: a script that ran both the ANN and the new CNN side-by-side on the exact same drawing. I even built an Ensemble feature to average their probabilities.

The result? The CNN broke too. It started guessing the number 8 for almost everything.

The Fix: Normalization & Optimization
It turns out, the architecture wasn't the only issue. It was the math.

During training, I normalized the PyTorch dataset to a range of [-1, 1]. But my Pygame image pre-processing was scaling the pixels from [0, 1]. The CNN was receiving numbers it didn't expect, panicking, and defaulting to 8 (the mathematical center of the dataset).

Once I spotted the bug, the fix was incredibly satisfying. I updated the Pygame tensor math.
I also reduced the brush thickness to mimic a real pen, and dropped the random rotation in my training data augmentation from 15° to 5° so the shapes wouldn't distort too heavily.

The Takeaway
After those fixes, the CNN's accuracy skyrocketed. It easily recognized my live handwriting, completely outperforming the ANN (which I ended up deleting entirely).

The biggest lesson? A high accuracy score on a pristine dataset means absolutely nothing if your live environment doesn't perfectly match your training environment.

You can check out the final, fully optimized CNN architecture on my GitHub:

nikitagpt05 / Handwritten-Digit-Recognizer

Handwritten Digit Recognizer (PyTorch & Pygame)

This is a real-time app that guesses the numbers you draw on the screen. It is built with PyTorch and Pygame. This project shows how a machine learning model can perform perfectly on standard training data but struggle with real-world inputs, and how changing the underlying architecture fixes those issues.

How the Project Evolved

I went through three main testing phases to get the accuracy right for live, interactive drawings.

1. The First Attempt (ANN) I started by building a basic Artificial Neural Network (ANN). It scored about 97.5% accuracy on the standard MNIST dataset. But when I drew numbers with my mouse in the actual app, it failed constantly. An ANN flattens an image into a single line of pixels, so it does not actually understand shapes, edges, or curves. If I used a thick digital brush or drew the number slightly off-center…

View on GitHub

Have you ever had a model fail in production after passing all your tests? Let me know in the comments!