DEV Community: Siddiqui Qamar

I Vibe-Coded an App for a $3,000 Hackathon. It Was Complete Slop 🫠

Siddiqui Qamar — Thu, 16 Jul 2026 06:56:42 +0000

In January 2026, I vibe-coded a Streamlit app to analyze dozens to hundreds of GitHub profiles in a single click. We all know GitHub provides their REST API, so the only thing remaining was to open Claude Code and pass the prompt. Run the app, and it worked. Easy peasy.

(P.S. This was my submission for a $3,000 hackathon, but the problem is real: how would you analyze that many profiles?👀)

But deep down, I knew the codebase was total slop. It felt like a house of cards that could crash at any second.

Things that were completely missing are:

Zero error handling: If one API call failed or hit a rate limit, the whole run died.
The UI freeze: If you passed 50 profiles, you had to stare at a frozen screen. There was no progress bar, leaving you guessing if the app crashed silently or was just slow.
Sequential processing: It ran one profile at a time. There was no parallel processing or async, making bulk runs painfully slow.
No batching: It was all or nothing.
No safety nets: No unit tests, no stop/resume buttons, and no way to export the partial data if you wanted to stop early.

Upgrading vibe code to real engineering

Since I now knew exactly what was missing and how to fix it, it was time to open the Claude Code window again.

Here is what changed:

Implemented parallel workers to fetch profile data concurrently, cutting down wait times significantly.
Added proper batch processing with real-time UI updates so you actually know where the queue stands.
Wrapped the API calls in robust error handling. If one profile fails, the app skips it, logs the error, and keeps moving.
Added controls to pause or stop a bulk run mid-way and instantly export whatever data had already been processed to a CSV.

The difference after implementing these changes was fabulous. The app didn't just get faster; it felt incredibly reliable and professional to use. My mentor always tells me: "There’s always a chance to improve and make it perfect later, but it should be done first."

The repository is open-source. You can check out the refactored code directly by clicking here ⭐️

BTW, I didn't win that hackathon, but the learning I gained throughout the process was epic.

Save yourself from drowning in feeds 🚩

Siddiqui Qamar — Thu, 09 Jul 2026 08:12:16 +0000

Dev.to is an absolute goldmine. On any given day, thousands of builders share brilliant engineering lessons, launch side projects, break down new AI models, or submit hackathon entries.

The problem is that this massive amount of information is hard to process.

We want to stay updated with the fellow builder community, but nobody has the time to click through fifty long posts just to see what someone built and why it matters.

So, I vibe-coded an internal tool called Dev.to ASSISTANT and decided to open-source it.

See it in action 🎬

Instead of explaining it, here is the tool turning the noise into a clean, structured summary in real-time:

From Infinite Scroll to Instant Value

The goal isn't to skip reading—it's to figure out exactly where to dive deep.

When you pass the assistant a tag (like #weekendchallenge or #ai), it uses a Gemma 4 layer to extract the meat of each post. You instantly get:

The exact "why" and "how" behind the project, stripped of fluff.
What tools, frameworks, or models were used.
Live reaction and comment counts so you can see what's sparking conversation.
A link right back to the original Dev.to post so you can jump in and engage with the author.

Built with the Community, For the Community

Because Dev.to is an open ecosystem that generously provides an official API, I wanted to build this in that exact same spirit.

The backend is built with Python (FastAPI) and the frontend dashboard uses Next.js. I’ve made the entire project completely open-source so any builder can run it locally, tweak the filters, or add new curation features.

If you want to discover great engineering lessons faster, track challenge submissions, or just find amazing people to follow without getting lost in the feed, give it a spin.

Check out the GitHub repository here ⭐️

If this tool helps you find a cool repository or saves you some scroll time, I’d love to hear your thoughts in the comments below!

I Built an AI Second Brain with Gemma 4

Siddiqui Qamar — Sun, 24 May 2026 17:47:38 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

Brain Dump — AI That Connects Your Knowledge

What I Built

Brain Dump is a second brain that turns scattered personal data into a searchable memory layer.

Users can capture notes, URLs, PDFs, screenshots, audio, video, and project files. The system extracts content, transcribes media with Whisper, builds embeddings, and enables semantic search across the entire knowledge base.

Instead of remembering filenames or folders, users can search naturally and retrieve the right context instantly.

Key Features

Semantic search across mixed-format content
Whisper-powered transcription
AI-generated summaries and insights
Memory connections + lightweight knowledge graph
SQLite-based MVP with production-ready migration path to Postgres + pgvector

Demo

Video walkthrough coming soon.

Code

Repository:

https://github.com/siddqamar/brain-dump

How I Used Gemma 4

Brain Dump uses gemma-4-26b-a4b-it through Google AI Studio API for contextual summarization and insight generation.

I chose the 26B A4B model because it provided a strong balance between reasoning quality, speed, and practical deployment for a hackathon-scale product.

Gemma powers:

Memory summarization
Context extraction
Insight generation
Relationship discovery between captured knowledge

The goal was to combine local knowledge management with modern AI retrieval workflows in a lightweight and developer-friendly MVP.

Using Notion to Turn Reading Sessions Into a Searchable Knowledge System

Siddiqui Qamar — Sun, 29 Mar 2026 17:47:16 +0000

This is a submission for the Notion MCP Challenge

What I Built

I built Reader’s Companion, a Chrome extension that turns online reading into something actually useful.

The idea came from a super common problem: you’re reading something valuable — a research paper, a long-form blog, documentation, even an ebook in the browser — and the moment you want to save something important, your focus breaks. You start switching tabs, copying text into notes, saving screenshots to nowhere, or telling yourself you’ll come back to it later.

And yeah… later never comes.

Reader’s Companion fixes that by making capture part of the reading flow itself.

So instead of treating reading and note-taking as two separate tasks, this makes them feel like one smooth workflow.

You can check out the code here:

[https://github.com/siddqamar/readers-companion.git]

How I Used Notion MCP

Notion is the core destination for the whole experience.

I used Notion MCP as the bridge that turns the extension from a simple capture tool into something that fits into a real workflow.

That means Notion becomes more than a storage layer. It becomes the place where reading turns into usable knowledge.

Closing Thought

A lot of tools help you collect information.

I wanted to build one that helps you stay in flow while doing it.

That is what Reader’s Companion is really about.

A skill that builds ATS friendly Resumes from terminal directly

Siddiqui Qamar — Mon, 02 Mar 2026 17:02:59 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

This is built for developers who prefer terminal-first workflows and want a resume that actually survives ATS screening. A lot of devs have solid skills and projects, but their resumes get filtered out before any human sees them because of formatting, structure, or missing keywords. I wanted to solve that problem where developers are most comfortable: the CLI.

What I Built

A Resume Builder Skill for Gemini CLI that automates three core workflows:
1) Build a clean resume from a single master JSON “source of truth”
2) Transform content into ATS-friendly structure using defined standards
3) Personalize the resume to a specific Job Description by extracting key requirements and aligning the resume accordingly

It also supports exporting the final resume as PDF or PNG.

Demo

[Add your demo video link here]
[https://dev.to/qamar_dev_01/a-skill-that-builds-ats-friendly-resumes-and-actually-matches-the-jd-pmc]

Code

[https://github.com/siddqamar/resume-builder-skill.git]

How I Built It

I build this using Gemini CLI by describing the problem statement and use built-in web search capabilities. The skill is implemented as a CLI agent skill with a structured, repeatable workflow:

references/master_resume.json acts as the canonical resume data source
references/ats_standards.md contains ATS optimization and formatting rules
assets/templates/resume_markdown.md defines the output structure
SKILL.md contains the skill instructions and triggers

Users interact with it through natural language prompts inside Gemini CLI, for example:
@resume-builder personalize my resume for this Job Description: [Paste JD here]

A skill that builds ATS friendly Resumes (and actually matches the JD)

Siddiqui Qamar — Mon, 02 Mar 2026 15:01:40 +0000

If you’ve ever applied to a role you were clearly qualified for and still got nothing back, there’s a decent chance that your resume didn't pass the initial screening process.

Most resumes get screened by ATS before a recruiter sees them. If your formatting breaks parsing, your keywords don’t match the job description, or your structure isn’t predictable, your resume can get filtered out silently. No feedback.

That’s the gap I wanted to fix but in a way that fits how developers actually work.

Why a CLI skill, not another resume website?

Because developers live in the terminal.

We automate build steps, package releases, manage infra, ship code and then we’re supposed to open a drag-and-drop resume builder and fight PDF formatting like it’s 2009? Nah.

So I built a skill that lets you build, optimize, and tailor your resume without leaving your Gemini CLI.

The core design is simple

Your resume data should not live inside ten different documents.

Instead, it lives in one place, a master JSON file and the skill generates the output from that every time. That means updating your resume becomes a real dev workflow: change the source, regenerate, done.

What it actually does

First, it can generate a clean resume from your master data consistent structure, predictable headings, readable layout.
Second, it can transform your resume to be ATS-friendly, using a standards file that controls formatting rules and keyword optimization logic. No guessing what ATS wants. The rules live in the repo, and you can tweak them.
Third (and this is the fun one), it can personalize your resume for a specific job description. You paste the JD, it extracts the important skills/requirements, and aligns your resume content accordingly emphasizing relevant experience and language without you manually rewriting the whole thing every time.

That’s basically “resume tailoring” but as a deterministic workflow.

Usage: it’s meant to feel natural

I didn’t want it to feel like a tool with 30 flags. You trigger it like you’d talk to an agent:

@resume-builder personalize my resume for this job description: [paste JD]

Or if you’re updating your master profile:

@resume-builder add my new role as Senior Developer at X to my master resume

Why I think this helps the community

There are devs with real skills and real projects who lose opportunities because their resume is structured in a way machines don’t like. That’s not a talent problem that’s a tooling problem.

This skill is my attempt to make resume building feel like what it should’ve always been for developers: structured data → repeatable outputs → easy tailoring.

How I vibe coded a chrome extension using YOLO mode

Siddiqui Qamar — Thu, 26 Feb 2026 09:49:51 +0000

So, I took the famous 2048 puzzle game and decided to recreate it myself. Not for production, just an experiment to see how YOLO mode actually handles a full build when you stop micro-managing the coding agent.

Pro-tip: If you’re going to run YOLO mode, do it in a sandbox.

I used the Gemini CLI to vibe code the whole thing with Gemini 3 Pro for development.

Here’s exactly how it went down:

1. Start YOLO mode

This is like giving the permission to do whatever it takes to get the work done. It can execute commands, create files, and iterate without asking for a "Yes/No" confirmation at every line of code.

gemini --yolo

2. The Visual Prompt

Instead of typing out a massive spec, I just took a screenshot of the original 2048 game and pasted it directly into the terminal. Let the model review the UI so it actually understood the spatial logic before it started development.

3. The Context Loop

Now here the prompting skills comes in. See the example below how I started:

I want to recreate this game as a chrome extension... explain briefly.

And let the gemini ask me the follow-up questions. This ensured it actually grasped the requirements and manifest v3 constraints before it wrote a single line.

4. Ninja technique for vibe coding

Once the context was set, I had the terminal to create GEMINI.md and divide the whole development into easy achievable tasks and save it to TODO.md.

Having these files meant the agent always had a "source of truth" to look back at. It stayed on the plan regardless of what happened to the session.

5. Let Gemini Cook

At this point, I just sat back. The model handled the grid logic, the tile merging, and the extension packaging.

Wanna see code? Here's GitHub repo ⭐️

Conclusion:

This is the first time I built any chrome extension. The game works perfectly. It’s smooth, the logic is tight, and honestly I enjoyed the process. While I still need to add a memory layer so it remembers your state when you close the extension.