DEV Community: Waleed Shamhan

Ghost in the Machine: Necromancing Dead Codebases Locally with Gemma 3 & Ollama

Waleed Shamhan — Thu, 29 Oct 2026 23:50:31 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

Disclosure: this project was built with AI assistance — a local Gemma 3 model performed the code autopsy and drafted rewrites through Ollama, and a human verified every finding, rejected the invented ones, and wrote the tests. No cloud AI service was used.

Ghost in the Machine: Necromancing Dead Codebases Locally with Gemma 3 & Ollama

Introduction

Every developer’s GitHub profile is a graveyard. We've all got legacy repositories—abandoned scripts, forgotten utilities, and stale experiments written years ago that now sit gathering digital dust. For this year’s Hacktoberfest (Ghost in the Machine challenge), instead of building a trivial app, I decided to build something that resurrects the dead: The Legacy Code Necromancer.

It’s a local-first, zero-dependency CLI tool built in pure Python that uses Gemma 3 via Ollama to perform an autopsy on dead code, refactor it safely, and generate a haunted markdown audit report.

The Architecture: Privacy-First Code Necromancy

When you're dealing with legacy code, the biggest fear is leaking hardcoded API keys, database credentials, or sensitive secrets to cloud LLMs. That's why The Legacy Code Necromancer was built with strict constraints:

Local Loopback Only: It communicates strictly with 127.0.0.1 where Ollama runs. Any remote server connection is strictly rejected unless explicitly authorized.
Secret Scrubber: Before a single line of code is sent to Gemma 3, a built-in regex scrubber purges any potential keys, tokens, or sensitive strings, leaving the structural vulnerabilities (eval, pickle, etc.) exposed for analysis.

The Three Engines of the Necromancer

The tool runs three distinct phases against any legacy directory:

Phase 1: Code Autopsy: Scans the file tree (safely ignoring .git, node_modules, and binaries) and produces structured findings as JSON — severity, category, file path, and line — rendered into the Markdown report.
Phase 2: Revival & Patching: Refactors the haunted code into a clean, modern, testable structure (with syntax verification for Python targets).
Phase 3: The Haunted Audit Report: Generates a chilling, Halloween-themed Markdown report detailing the cause of death and the resurrection steps, complete with a persistent JSON session manifest (.necromancer-manifest.json) to resume work without duplication.

The Recorded Séance — what actually happened

No claims without evidence. On 30 October 2026 I ran the tool over the included haunted sample (two Python files, 57 lines, fake credentials planted deliberately) with gemma3:1b running locally on CPU through Ollama. The run took 404 seconds, 5 model calls, 16,388 characters sent, 18,208 received — and every raw reply is preserved.

The autopsy returned 15 findings. Human review confirmed 8 — including every planted critical flaw: the hardcoded credentials, eval, pickle deserialization, shell injection, SQL string interpolation, MD5 password hashing, and the removed time.clock / collections.Mapping APIs. The other 7 were invented or mislabeled — a "race condition" in single-threaded code, a "hardcoded credential" in a file that has none, "missing retries/backoff" for local file code — and the model's line numbers were guesses, not real line numbers. I rejected those, and the report says so.

The rewrite pass was the honest disappointment of the run: the small model's drafts echoed the redacted input verbatim — eval, pickle, SQL interpolation, MD5 and time.clock all survived. "Verified" in the report means only "compiles". Those drafts are not safe to run, and the report's "Cause of Death" prose (which invents a 2023 date and fixes that never happened) is preserved as evidence of what a small local model produces — not as documentation. The full annotated report, with a human curator's note on top, is in the repository at docs/example-haunted-audit-report.md.

That is the real story: the autopsy is strong, the curation is the product, and the audit trail is what makes it trustworthy.

Why Gemma 3?

The recorded run used gemma3:1b (806 MB) because this machine is RAM-constrained — and it delivered exactly the balance I needed for the autopsy: fast enough on CPU, with enough structural reasoning to understand chaotic, unmaintained legacy code, without sacrificing a single byte of code privacy. The tool accepts any local Gemma 3 tag; the 4B gemma3 is supported and is the recommended next run for stronger rewrites (untested on this machine).

Try the Haunted Sample Yourself

Clone the repository, feed it the included haunted sample directory containing fake secrets and old bugs, and watch the necromancy unfold locally:

ollama serve
ollama pull gemma3:1b

python3 necromancer.py fixtures/haunted-legacy --model gemma3:1b

Demo — the recorded séance

This is the real console output of the run recorded on 30 October 2026, on CPU, against the included haunted sample:

Exhumed 2 file(s), 15 finding(s), 2 resurrected, 0 failed.
Report: necromancer-out/haunted-audit-report.md
Revived code: necromancer-out/revived

What the generated report recorded (verbatim vitals):

Measure	Value
Source files examined	2
Total lines	57
Secret lines redacted before prompting	2
Findings	15 (4 Critical · 4 High · 4 Medium · 3 Low)
Files resurrected	2 (drafts compile; curator review found they echo the input — see below)

A sample of the confirmed findings: hardcoded credential (Critical), eval() code execution, pickle deserialization, SQL string interpolation, MD5 password hashing, and the removed time.clock API. The full annotated report, with the human curator's note on what the model invented and what the rewrite drafts failed to fix, is in the repository at docs/example-haunted-audit-report.md.

Code

waleedshamhan2050-sys / legacy-code-necromancer

Local-first CLI that autopsies abandoned code, drafts safe rewrites, and writes a haunted audit report — powered by Gemma 3 via Ollama. No cloud, no secrets leave localhost.

👻 The Legacy Code Necromancer

Hacktoberfest 2026 — "Ghost in the Machine" challenge entry, Best Use of Gemma category. A local-first CLI that dissects abandoned code, resurrects it with Gemma 3 running entirely on your own machine through Ollama, and writes a haunted audit report you can verify line by line No cloud. No API keys. No code ever leaves localhost.

Every codebase has a graveyard: the utility written in 2019 that everyone is afraid to touch, the intern's bot, the script with the password still in it. The Necromancer does not delete the dead — it performs an autopsy, determines the cause of death, and brings the code back in a form that is safe to run. The ghost in the machine is not something to fear. It is something to understand.

The pipeline — three engines, one séance

abandoned project ──► 1. CODE AUTOPSY ──► 2. AUTO-REFACTORING

…

View on GitHub

Why Does Open Innovation Matter?

Because a closed API would have made this project impossible in the way that mattered. Abandoned code is the most personal code a developer owns — half-finished, half-secret, full of old credentials. Open-weight Gemma 3 running locally meant the autopsy never depended on a service that can disappear, change its prices, or read my code. Anyone can rerun the identical séance offline and audit every finding against the preserved raw output. A closed model gives you an answer; an open model gives you a process you can inspect. For a student on a metered connection in Yemen, that is the difference between a ghost story and a resurrection.

The Spirit of It

Día de los Muertos is about honouring the dead without fearing them. This tool does the same for old code: you do not delete your past work because it is flawed. You sit with it, understand it, and bring it back better — with a local model that never judges, never leaks, and never leaves the room.

Prize Categories

Best Use of Gemma — Gemma 3 (via Ollama, local inference) is the engine of the entire project: autopsy, rewrite drafts, and report prose all run through the open-weight model on localhost.

I Launched a WhatsApp Automation Service for Small Shops — Powered by Local Open Models

Waleed Shamhan — Tue, 20 Oct 2026 14:31:30 +0000

Small shops and restaurants in my region lose customers every day for a simple reason: nobody answers WhatsApp fast enough. The owner is busy, the same questions repeat — prices, opening hours, location, "do you deliver?" — and by the time someone replies, the customer has moved on.

So I built a service around a simple idea: an AI assistant on the shop's WhatsApp number that answers instantly, 24/7 — and it runs on open-weight models, locally.

What it does

Answers frequent questions (prices, hours, location, menu/services) in seconds
Takes orders and notifies the owner immediately
Runs on Gemma 3 via Ollama on a local machine — no per-message API cost, and customer data stays with the business
Falls back to the owner when a question is outside what it knows

Why local open models?

Two reasons: cost and privacy. A cloud API bill grows with every conversation; a local model does not. And a small shop's customer chats never leave the shop's own hardware.

Packages

Basic — $80: FAQ auto-replies + welcome message
Advanced — $200: + order taking + instant owner alerts
Pro — $500: + spreadsheet logging of orders + weekly reports

Links

Service page: https://github.com/waleedshamhan2050-sys/AI-Post-Generator/blob/master/SERVICE.md
Live site: https://whatsapp-automation-service-waleedshamhan2050-4299.vercel.app

This grew out of my earlier project, an AI post generator for WhatsApp and Telegram channels — the same stack (Python + Ollama + Gemma 3), aimed at a different job: not creating content, but answering customers.

If you run a small business and drown in repeated WhatsApp questions, I'd love your feedback: what are the five questions your customers ask the most?

I Built a Local Agent That Reads My Chats Overnight and Writes My Morning Digest (Gemma 3 + Ollama)

Waleed Shamhan — Tue, 20 Oct 2026 12:59:43 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Every morning used to start the same way: me, half awake, scrolling through hundreds of unread messages across my group chats — a study group, a project team, friends — trying to figure out what I actually missed while I slept. A lecture moved. A deadline confirmed. A decision made without me. All buried under memes and "good morning" stickers.

So for Slow and Steady, I built the laziest possible solution: Morning Digest, a small local agent that does the scrolling for me.

It takes a Telegram Desktop export (or a plain-text chat log), looks at the last 12 hours of messages, and produces a short Arabic morning digest:

a headline of at most two lines,
the key topics as bullets,
and any decisions or action items, if there were any.

I wake up, run one command, and read for 30 seconds instead of scrolling for 15 minutes. That's the whole product: my future, better-rested self gets to be a little lazier — on International Sloth Day and every day after. 🦥

And it runs entirely on my own machine with Gemma 3 via Ollama. No cloud, no API key, no subscription.

Demo

The project ships with a synthetic sample export (sample/result.json — 30 fictional messages across two groups, so nobody's real chats are involved). Running:

ollama pull gemma3
python3 digest.py sample/result.json

And here is the actual digest it produced from that sample (24 messages in the 12-hour window, generated locally by gemma3 — the full output is committed in the repo as sample_output.md):

ملخص الصباح

تطور مشروع الهاكاثون مع التركيز على تطوير "وكيل ملخص الصباح"، بالإضافة إلى مناقشات حول جدول الأعمال والمواعيد.

أهم المواضيع:

تطوير "وكيل ملخص الصباح" باستخدام Gemma 3.

إعدادات مشروع الهاكاثون (تاريخ التقديم، مراجعة المسودة، اختبار الملخص).

مناقشة حول محاضرة قواعد البيانات ومحاضرة الشبكات.

تذكير بواجب التشفير.

قرارات ومهام:

تاريخ التقديم لمشروع الهاكاثون: الخميس.

مراجعة مسودة منشور DEV من قبل الجميع.

إعداد عينة محادثة وهمية لاختبار الملخص (عمر خالد).

إرسال ملخص محاضرة الشبكات (أحمد صالح).

تعد مسودة ملف README الليلة (سارة أحمد).

البدء في العمل على واجب التشفير الليلة (خالد عمر).

تذكير بتسليم واجب التشفير يوم الخميس (ليلى حسن).

Every item in that list is really in the sample chats — the moved database lecture, the Thursday submission, who owes whom the network notes. Nothing was edited or touched up; that's the raw model output. On this machine's CPU the 4B model took about 5 minutes end to end; gemma3:1b does the same job in under 2 minutes with a shorter, rougher digest (also committed in the repo for comparison).

Code

waleedshamhan2050-sys / morning-digest

Morning Digest — a local agent that reads your Telegram chat exports overnight and writes a short Arabic morning digest. Gemma 3 + Ollama, fully local. Hacktoberfest 2026 Week 3: Slow and Steady.

☀️ Morning Digest — read less chat, know everything

A tiny local agent that reads your group chats overnight and hands you a short Arabic morning digest: a two-line headline, the key topics, and any decisions or action items — so you can be gloriously lazy and still miss nothing.

Built for the Hacktoberfest Open-Source AI Challenge — Week 3: "Slow and Steady" (build something with open-weight models that rewards laziness 🦥).

It runs 100% locally with Gemma 3 via Ollama. Your chats are private — they should never have to visit a cloud API just to be summarized.

How it works

Export a chat from Telegram Desktop (Settings → Advanced → Export Telegram data, JSON format) — or use any plain-text chat log.
Run the digest on the export. It takes the last N hours of messages (default 12 — last night), anchored at the latest…

View on GitHub

The whole tool is one Python file (digest.py) with a single dependency (requests). The repo also includes a parser test that runs without the model:

python3 tests/test_parse.py   # 5/5 passing: window filtering, entity flattening, service-message dropping, multi-chat exports, text-log parsing

How I Built It

The stack is deliberately boring — boring is what you want at 7 AM:

Gemma 3 (Google's open-weight model family) served locally by Ollama, called through its native HTTP API. The default model is gemma3 (configurable via OLLAMA_MODEL); gemma3:1b is there when I'm in a hurry.
Parsing: Telegram Desktop exports message text either as a plain string or as a list of formatting entities, and pads the file with service events (joins, pins) and empty media messages. The parser flattens entities, drops the noise, and keeps a flat {timestamp, chat, sender, text} list. Plain .txt logs work too.
Time window: the digest covers the last --hours N (default 12), anchored at the latest message in the export — because exports are made in the morning, "recent" means the tail of the file.
Chunking: a busy night can overflow a small model's context, so messages are split into chunks, each chunk is summarized, and then the summaries are summarized into the final digest. Two passes, no lost middle.
Provider pattern: this reuses the pattern from my Week 2 project (AI Post Generator): Ollama by default, OpenAI as an optional --provider, model chosen from the environment. One codebase, local-first.

Verified locally: the agent ran end to end against Gemma 3 served by Ollama 0.40.6 on this machine — with gemma3 (4B) for the digest shown above, and with gemma3:1b for a faster comparison run. Both outputs are committed in the repo. The parser tests pass 5/5 without a model, and pointing the tool at a stopped Ollama server produces a friendly "start it with ollama serve" error instead of a stack trace (also tested).

Why Does Open Innovation Matter?

This project only makes sense because the model is open-weight and the inference is local:

Privacy is the feature. A chat export is one of the most personal files on your computer. Sending it to a closed API so a stranger's server can summarize your friends' messages is a terrible trade. With Gemma 3 on my own machine, the file never leaves the laptop — the summary is computed a meter away from where the chats live.
It works where I live. I'm a student in Yemen. Internet cuts, no international payment card for API credits, no PayPal. A closed API makes my morning digest a luxury I literally cannot pay for. An open-weight model makes it free forever: set up once, run every day, owe nobody anything.
No lock-in, real ownership. If a better small open model ships next month, I change one environment variable. My tool doesn't break when a provider changes pricing, deprecates a model, or suspends an account.

A closed API could summarize the chats too — but it couldn't give me this: a private, offline, zero-cost habit that runs on hardware I already own. That's what open made possible.

The Lazy Payoff

The honest math: catching up on my groups used to take roughly 15 minutes of scrolling every morning, most of it noise. The digest takes about 30 seconds to read. Even better, I no longer have to remember to check whether the database lecture moved or who promised to send the network notes — if it was said overnight, it's in the digest, under "Decisions and action items."

Setup cost: one ollama pull and one Python file. Daily effort since then: zero. Slow and steady, indeed.

Prize Categories

Best Use of Gemma — the digest is generated by Gemma 3 running locally via Ollama; the open-weight model is the core of the project, not an accessory.

Cybersecurity Roadmap #2: Computer Basics Every Security Learner Needs

Waleed Shamhan — Fri, 16 Oct 2026 18:07:23 +0000

This is episode 2 of my Cybersecurity Roadmap series, where I learn cybersecurity in public. Last time: what cybersecurity is and the CIA triad. Today: the computer basics you need before any hacking or defending makes sense.

You cannot protect what you do not understand. So let us build the mental model.

1. Hardware: what actually runs your code

CPU — executes instructions. Every program, including malware, is ultimately instructions for the CPU.
RAM — fast, temporary memory. Turn the power off and it is gone. Passwords and keys sitting in RAM can be stolen while the machine runs.
Storage (SSD/HDD) — permanent memory. Deleted files are often recoverable, because "delete" usually just marks space as reusable.
Network card — connects the machine to other machines. Every attack from the internet arrives through it.

Security lesson: data in RAM is exposed while the machine runs, and "deleted" does not mean "gone".

2. Operating system: the boss of the machine

The OS (Windows, Linux, macOS) sits between programs and hardware. It decides:

Which program runs when (processes)
Who can read or change which file (permissions)
Which program may use the network (firewall rules)

Two security ideas live here:

Processes: every running program is a process. Malware is just a process you did not want. Task Manager (Windows) or ps (Linux) shows you what is running.
Users and permissions: files and programs have owners and permission levels. A normal user account cannot change system files; an administrator can. This is why you should not browse the web as administrator — any malware you run inherits your permissions.

3. Files, extensions, and why they matter

A file's extension hints at what it is — but it is only a hint:

.txt, .pdf, .jpg — usually data, not programs
.exe, .bat, .sh — programs that run when opened
.docx, .xlsx — documents that can contain macros (code!) — a classic malware carrier

Security lesson: "invoice.pdf.exe" is a program, not a PDF. Windows hides extensions by default — turn "show file extensions" on. It is a five-second change that stops a whole class of tricks.

4. The command line is not optional

A lot of security work happens in the terminal: checking processes, inspecting files, testing networks. You do not need to memorize everything — you need to be comfortable with:

Listing files and moving between folders (ls, cd, dir)
Reading a file (cat, type)
Seeing what is running (ps, Task Manager)
Checking network connections (netstat, ss)

If the command line scares you, practice ten minutes a day. It pays off in every later episode.

5. Updates: the most boring, most important defense

Most successful attacks do not use genius zero-days. They use known vulnerabilities in unpatched software — bugs the vendor already fixed. Updating your OS, browser, and apps closes those holes. Automatic updates exist for a reason: turn them on.

Quick checklist before the next episode

[ ] You can explain CPU, RAM, storage, and network card in one sentence each
[ ] You know what a process is and how to list running ones
[ ] You know why running as administrator is risky
[ ] File extensions are visible on your machine
[ ] Your OS and browser are up to date

Next episode: Networks — how data actually moves, and why that matters for attackers and defenders. Follow along, and tell me in the comments: Windows, Linux, or macOS — what do you learn on?

Cybersecurity Roadmap #1: What Is Cybersecurity, Really?

Waleed Shamhan — Fri, 16 Oct 2026 18:07:22 +0000

Welcome to my Cybersecurity Roadmap — a series where I learn cybersecurity in public, one topic at a time, and share everything I learn. No fluff, no assumed knowledge. If you are a student or a beginner wondering where to start, this series is for you.

In this first episode: what cybersecurity actually is, why it matters, and the three ideas everything else is built on.

What is cybersecurity?

Cybersecurity is the practice of protecting systems, networks, and data from digital attacks. Those attacks usually aim to do one of three things:

Steal information (passwords, personal data, business secrets)
Damage systems (delete data, shut down services, spread malware)
Trick people (phishing, scams, fake websites)

Every defense you will ever learn — firewalls, encryption, strong passwords, updates — exists to stop one of those three.

The foundation: the CIA triad

Almost everything in cybersecurity comes back to three goals, known as the CIA triad:

1. Confidentiality — only the right people see the data

Your messages, passwords, and files should be readable only by the people allowed to see them. Tools: passwords, encryption, access control.

2. Integrity — the data stays correct and unmodified

Nobody should be able to secretly change your data — not a bank balance, not a grade, not a medical record. Tools: hashing, digital signatures, backups.

3. Availability — the system works when you need it

Security means nothing if the service is down. Systems must stay up and reachable for legitimate users. Tools: redundancy, backups, protection against denial-of-service attacks.

A real attack usually breaks at least one of the three. A phishing email that steals your password? That breaks confidentiality. Ransomware that encrypts your files? That breaks availability (and often confidentiality too). A tampered download? That breaks integrity.

Why should you care?

Your accounts, photos, and messages are targets — attackers automate their work, so you do not need to be famous to be attacked.
Companies lose money and trust after breaches, so cybersecurity is one of the most in-demand skills in tech right now.
The basics stop most attacks. You do not need to be a hacker to be safer — you need the fundamentals, applied consistently.

What's next in this series

What is cybersecurity (this post)
Computer basics every security learner needs
Networks: how data actually moves
The CIA triad in depth: encryption and hashing
Common attacks: phishing, malware, and social engineering
And more — one topic at a time.

If you are learning too, follow along and tell me in the comments: what made you interested in cybersecurity?

AI Post Generator, Now Running on Local Open-Weight Models (Gemma 3 + Ollama)

Waleed Shamhan — Fri, 16 Oct 2026 18:02:00 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

AI-Post-Generator is a Python command-line tool that generates professional Arabic posts for WhatsApp and Telegram channels. I originally built it on a hosted API — and for this challenge I added a new mode that runs it on a local open-weight model (Gemma 3) through Ollama, with no hosted API involved.

Who would pay for it? Anyone who runs a channel and posts every day: channel owners, small businesses, media coordinators, and community managers. Writing fresh, consistent posts daily is the tedious task they all complain about — this tool turns a topic + a template into a ready post in seconds.

The problem it solves is threefold: the blank page (what do I post today?), consistency (same voice across every post), and cost/privacy (with the local mode, there is no per-post API bill and the channel's content never leaves the owner's machine).

Demo

Run it with the local open-weight model (default):

ollama pull gemma3
python main.py
# or explicitly:
python main.py --provider ollama --model gemma3

The original hosted mode still works:

python main.py --provider openai

Below is a real post generated by the tool running Gemma 3:1b locally via Ollama — topic "daily reading", template "morning motivation". The exact output is also saved in the repo as examples/gemma3_local_sample.txt:

صباح الخير يا أصدقائي! 📚

هل تبحث عن طريقة رائعة لتهدئة ذهنك، وتعزيز تركيزك، وفتح أبواب جديدة للمعرفة؟ القراءة اليومية هي الحل! ☀️

تذكروا، القراءة ليست مجرد قراءة، بل هي رحلة استكشافية، وتطوير الذات، وراحة البال. 🧘‍♀️

اكتشفوا قوة القراءة! 📖

شاركوا معنا أفكاركم حول القراءة اليومية. ما هي الكتب التي تحبون قراءتها؟ 🤔

دعونا نُشجع بعضكم البعض! 🤝

#صباح_الخير #تحفيز #إيجابية

Code

https://github.com/waleedshamhan2050-sys/AI-Post-Generator

The open-model mode is a --provider flag in main.py: get_client() points the same OpenAI-compatible client at the local Ollama server (http://localhost:11434/v1) instead of the hosted API, and the model defaults to gemma3 (configurable via OLLAMA_MODEL in .env or --model). The prompt, the JSON templates, and the saving logic are unchanged — only the provider changes.

How I Built It

Ollama for local inference — it exposes an OpenAI-compatible API, so the same client code works for both the hosted and the local path.
Gemma 3, an open-weight model, as the default local model.
JSON templates for each post type (announcement, quick tip, morning motivation, upcoming event, interactive question) with guiding examples.
python-dotenv for configuration (OLLAMA_MODEL, OLLAMA_BASE_URL, and the optional OPENAI_API_KEY for the hosted mode).

The key design decision: one codebase, two providers. The tool does not care where the model lives — the templates and the flow stay the same.

Why Does Open Innovation Matter?

This project is the reason I believe in open innovation:

Cost: a channel owner posting daily would pay per-post API fees forever. With a local open-weight model, the marginal cost of a post is zero — which is what makes the business actually work for small channels.
Privacy: channel content, business announcements, and audience ideas never leave the owner's machine. Nothing is sent to a third-party API.
No lock-in: no vendor can change the pricing, rate limits, or terms under you. If one model stops suiting you, you swap it — llama3.2, qwen2.5, mistral — without rewriting the tool.
Works offline: the tool runs on a laptop with no connection, which matters for users with unreliable internet.
Built for a niche: the templates are tuned for Arabic WhatsApp/Telegram channel style — a niche a general-purpose hosted API handles poorly out of the box.

Open weights made this possible. A closed API could never offer all five at once.

Prize Categories

Best Use of Gemma

Customer Purchase Prediction with Logistic Regression - A Beginner's End-to-End ML Project

Waleed Shamhan — Fri, 16 Oct 2026 16:38:45 +0000

When I finished my first machine learning lectures, I wanted a project that used everything I had learned: data loading, preprocessing, train-test split, scaling, training, and evaluation. So I built a small but complete project: predicting whether a customer will purchase a product, based on their age, salary, experience, and gender.

The dataset is tiny (8 customers), which makes it perfect for learning — you can follow every number by hand.

The data

Age	Salary	Experience	Gender	Approved
22	500	1	Male	No
25	600	2	Female	No
28	700	3	Male	No
31	800	4	Female	Yes
34	900	5	Male	Yes
37	1000	6	Female	Yes
40	1100	8	Male	Yes
43	1200	9	Female	Yes

Approved is the target: Yes means the customer bought, No means they didn't. The rest are the features.

Step 1: Load the data and encode the categories

Models work with numbers, so the Gender and Approved columns need encoding: Male = 0, Female = 1, No = 0, Yes = 1.

import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import accuracy_score

data = {
    'Age': [22, 25, 28, 31, 34, 37, 40, 43],
    'Salary': [500, 600, 700, 800, 900, 1000, 1100, 1200],
    'Experience': [1, 2, 3, 4, 5, 6, 8, 9],
    'Gender': ['Male', 'Female', 'Male', 'Female', 'Male', 'Female', 'Male', 'Female'],
    'Approved': ['No', 'No', 'No', 'Yes', 'Yes', 'Yes', 'Yes', 'Yes']
}
df = pd.DataFrame(data)
df['Gender'] = df['Gender'].map({'Male': 0, 'Female': 1})
df['Approved'] = df['Approved'].map({'No': 0, 'Yes': 1})

Step 2: Split features and target, then train/test

X = df[['Age', 'Salary', 'Experience', 'Gender']]
y = df['Approved']

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42
)
# Train shape: (6, 4) — Test shape: (2, 4)

test_size=0.2 means 20% of the data goes to testing. random_state=42 makes the split reproducible.

Step 3: Scale the features

Age ranges up to 43, Salary up to 1200. Without scaling, the bigger numbers dominate the model. StandardScaler fixes that — and the key rule is: fit only on the training data, then transform both sets.

scaler = StandardScaler()
X_train = scaler.fit_transform(X_train)
X_test = scaler.transform(X_test)  # never fit_transform on test data!

Step 4: Train and evaluate

Since the target is yes/no, this is a classification problem, and logistic regression is the natural first model:

model = LogisticRegression()
model.fit(X_train, y_train)

y_pred = model.predict(X_test)
print("Actual:   ", list(y_test))   # [0, 1]
print("Predicted:", list(y_pred))   # [0, 1]
print("Accuracy: ", accuracy_score(y_test, y_pred))  # 1.0

The model predicted both test customers correctly: accuracy 1.0.

Step 5: Predict a new customer

Now the fun part — a brand-new customer: age 36, salary 950, 6 years of experience, female. The new data must go through the same scaler (transform, not fit):

new_customer = [[36, 950, 6, 1]]
new_customer_scaled = scaler.transform(new_customer)
prediction = model.predict(new_customer_scaled)
print("Approved" if prediction[0] == 1 else "Not Approved")  # Approved

Result: Approved (Yes) — the model predicts this customer will purchase.

What I learned

Preprocessing is half the project. Encoding categories and scaling features matter as much as the model itself.
Never fit on test data. Fitting the scaler on test data leaks information and gives fake results.
Small data teaches the pipeline. With 8 rows I could trace every step; the same pipeline scales to thousands of rows.
Accuracy on 2 test samples is not proof. A 1.0 here is encouraging, not conclusive — real evaluation needs more data and more metrics (precision, recall, confusion matrix).
If you are learning ML, build this project yourself and change one thing at a time: try a different random_state, add a feature, or compare logistic regression with a decision tree. That is where the real learning happens.

I Built an AI Post Generator for WhatsApp and Telegram - Here's What I Learned

Waleed Shamhan — Fri, 16 Oct 2026 16:21:37 +0000

I'm an IT student, and I also work as a media coordinator. That means I live in two worlds: writing code, and writing content. One day I got tired of staring at a blank screen every time I needed a post for a WhatsApp or Telegram channel, so I built a small tool to solve my own problem: AI-Post-Generator.

It's a Python command-line tool that generates professional posts for WhatsApp and Telegram channels using AI. You can find it here: https://github.com/waleedshamhan2050-sys/AI-Post-Generator

The problem

Running a channel means publishing constantly: announcements, tips, motivational posts, interactive questions. Writing all of that by hand is slow, and the tone drifts from post to post. I wanted something that could produce good drafts fast, in a consistent voice, and in Arabic.

How it works

The flow is deliberately simple:

You pick a topic and a template from the command line.
The tool loads a JSON template for that post type (announcement, tip, motivation, interactive question) with guiding examples.
It sends the prompt to the OpenAI API (using gpt-4.1-mini) and gets back a generated post.
The generated post is saved automatically in an examples/ folder, so you can reuse or review it later.

The tech stack is small: Python 3.x, the OpenAI API, python-dotenv for managing the API key safely in a .env file, and JSON for the templates.

Design decisions I am proud of

Templates instead of free-form prompts. Every post type has a JSON template with examples. This keeps the output consistent and lets me steer the AI toward a specific kind of post instead of hoping for a good result.

Arabic-first. The tool generates posts in Modern Standard Arabic with appropriate emojis, because that is the audience I write for. Most AI writing tools I tried defaulted to English, so this mattered to me.

Keep the secrets out of the code. The API key lives in a .env file, never in the source. It is a small thing, but it is the kind of habit I want to keep for every project.

What I learned

Building this taught me more than the tool itself:

Python CLI apps: structuring a command-line program and keeping the code clean and documented.
Working with AI APIs: how to call the OpenAI API, shape prompts through templates, and handle the response.
Structured data: using JSON to store and manage templates in an organized way.
Environment management: keeping sensitive data like API keys secure with .env files.
Prompt design: writing templates that guide the AI toward a specific post type is a skill of its own.
Content automation: how the whole loop of creating content for social channels can be automated.

What is next

I want to add direct publishing to channels, more template types, and support for scheduling posts. The goal is the same as when I started: less time staring at a blank screen, more time on the ideas that matter.

If you run a channel or create content regularly, I would love to hear how you handle the blank-page problem. And if you try the tool, feedback is welcome.