The latest articles on DEV Community by Abhinav Upadhyay (@abhinav1574k). https://dev.to/abhinav1574k https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4165154%2F24a9ad56-399b-4cd6-b9f6-921f69f76745.jpg https://dev.to/abhinav1574k en Abhinav Upadhyay Fri, 30 Oct 2026 18:21:30 +0000 https://dev.to/abhinav1574k/civicai-making-city-repair-reports-easier-to-prioritize-ln3 https://dev.to/abhinav1574k/civicai-making-city-repair-reports-easier-to-prioritize-ln3 <h2> What I built </h2> <p>At Hacktoberfest Hack Day Indore, I worked on CivicAI, a prototype for helping city teams review public infrastructure reports. The idea is to turn a photo of a road or utility problem into a structured report, then make the repair queue easier to understand.</p> <p>A citizen can submit an issue with a photo and location. The backend can send the image to Gemini for a suggested issue type, severity, confidence, responsible department, risk factors, and recommended action. If no API key is configured, or the Gemini request fails, the app falls back to a demo response so the flow can still be explored.</p> <p>Project repository: <a href="https://github.com/Abhinav1574k/CivicAI-AI-Powered-Public-Infrastructure-Monitoring-System" rel="noopener noreferrer">CivicAI on GitHub</a><br><br> MLH event submission: <a href="https://www.mlh.com/events/hacktoberfest-hack-day-indore-x-acropolis-institute-of-technology-and-research/submissions/01a11088-720b-4e56-6535-4b196ba4894d" rel="noopener noreferrer">Hacktoberfest Hack Day Indore</a></p> <h2> How it works </h2> <p>The frontend is built with React, TypeScript, and Vite. It communicates with a Node.js and Express API.</p> <p>The API handles issue reports and image analysis. For image analysis, the Gemini integration asks for structured JSON with the defect category, severity, confidence, department, risks, and suggested next action. A fallback demo mode keeps the interface usable without a configured model key.</p> <p>CivicAI also calculates a priority score from five factors: severity, number of reports, how long an issue has remained unresolved, location importance, and AI confidence. The resulting score maps to a priority level, with an explanation describing the factors that influenced it. The aim is to make triage more transparent than a queue that only reflects which report arrived first.</p> <p>The dashboard brings together issue details, map views, and summary analytics. Some of those summary figures are seeded demo data, so they should be read as part of the prototype rather than live municipal statistics.</p> <h2> What I learned </h2> <p>The most useful design question was not just “Can AI classify this photo?” It was “How can a reviewer see why this report was prioritized?” A score is easier to question and improve when the factors behind it are visible.</p> <p>I also learned how easily a polished dashboard can suggest that every workflow is production-ready. In this prototype, repair verification is represented with a fixed demo result; it does not yet compare before-and-after photos. Calling out that boundary is part of building a trustworthy demo.</p> <p>With more time, I’d validate model outputs more carefully, implement real before-and-after verification, and replace seeded dashboard metrics with data from a persistent store. I’d also test the scoring model with people who actually handle field repairs, since their feedback should shape which factors matter most.</p> <p>CivicAI is an experiment in making civic issue triage more structured and explainable. It is a prototype, not a deployed municipal service.</p> <h2> Related work </h2> <ul> <li> <a href="https://dev.to/tenetpvt/flint-turning-buses-into-citys-eyes-3700">FLINT: Turning Buses into City's Eyes</a> by TenET explores using vehicle routes to spot road issues.</li> <li> <a href="https://dev.to/adit_mehta_7dd815223144fe/building-a-community-issue-detection-system-using-vehicle-video-feeds-and-how-i-accelerated-lbi">Building a Community Issue Detection System Using Vehicle Video Feeds</a> by Adit describes detecting infrastructure issues from vehicle video.</li> </ul> <h1> mlhacks </h1> mlhacks hackathon ai webdev Abhinav Upadhyay Fri, 30 Oct 2026 17:36:12 +0000 https://dev.to/abhinav1574k/repo-ofrenda-a-local-memory-timeline-for-the-code-we-leave-behind-49o2 https://dev.to/abhinav1574k/repo-ofrenda-a-local-memory-timeline-for-the-code-we-leave-behind-49o2 <p>This is my submission for the <strong>Hacktoberfest Open-Source AI Challenge: Week 4 — “Ghost in the Machine.”</strong></p> <h2> Repo Ofrenda: a memory timeline for code </h2> <p>Software outlives the people and conversations that made it. A Git log preserves dates, commit messages, contributors, and changed files, but it is hard to see the shape of a project's past in a terminal listing.</p> <p><strong>Repo Ofrenda</strong> turns that history into monthly chapters. Select a chapter and a locally run open-weight model writes a short remembrance from the Git record, with commit references beside the story.</p> <p>This takes a different path through code archaeology from investigating a suspicious line: the aim is to help someone inheriting a repository see its seasons and milestones.</p> <h2> Try it </h2> <ul> <li> <strong>Interactive preview:</strong> <a href="https://abhinav1574k.github.io/Repo-Ofrenda---Ghost-in-the-Machine/demo.html" rel="noopener noreferrer">Repo Ofrenda on GitHub Pages</a> </li> <li> <strong>Source code and setup:</strong> <a href="https://github.com/Abhinav1574k/Repo-Ofrenda---Ghost-in-the-Machine" rel="noopener noreferrer">GitHub repository</a> </li> </ul> <p>The public preview uses a fictional neighbourhood library repository and clearly labeled sample stories. It does not call a hosted model; the model-backed experience runs locally, so repository history does not need to leave the developer's machine.</p> <p>To run that experience with Ollama:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>ollama pull qwen2.5:3b python3 make_demo.py /tmp/ofrenda-demo python3 repo_ofrenda.py /tmp/ofrenda-demo </code></pre> </div> <p>Then open <code>http://127.0.0.1:8787</code>. The README has instructions for using the tool with another Git repository and choosing a different Ollama model.</p> <h2> How it works </h2> <ol> <li>Git provides up to 500 commits across local branches: date, author, subject, and changed paths.</li> <li>Repo Ofrenda groups these records by month and renders a timeline.</li> <li>Selecting a chapter sends its commit metadata to the configured local Ollama endpoint.</li> <li>The prompt asks the model to stay within the supplied record and cite commit hashes. The app falls back to an evidence-only summary if the model is unavailable, does not cite a commit, or cites one outside the supplied records.</li> <li>The source commits remain visible beside the story.</li> </ol> <p>Citations help readers inspect the evidence, but they do not prove that every sentence is supported. The narration is an interpretation, not an authoritative account of contributors' intent.</p> <h2> Why open innovation matters here </h2> <p>Commit messages and contributor names can reveal private project context. Repo Ofrenda binds its web server to <code>127.0.0.1</code>, reads commit metadata rather than source files, and uses a local Ollama model instead of a hosted inference service. Readers can swap models to fit their hardware or run the timeline's evidence fallback while fixing a local model setup.</p> <p>Local inference has trade-offs: the model needs to be downloaded first, and generation speed depends on your machine. Once installed, the model can narrate a chapter without sending its commit metadata to a hosted AI provider.</p> <h2> What I built and verified </h2> <ul> <li>Python standard library for the local server and Git integration</li> <li>Git as the history source</li> <li>Ollama-compatible local model interface for open-weight narration</li> <li>A responsive HTML, CSS, and JavaScript interface</li> <li>An MIT license and a reproducible fictional Git fixture</li> </ul> <p>I verified the local timeline and story endpoints against six fixture commits across three months, including the evidence-only fallback. <strong>I did not run Ollama's model in this build environment</strong> because Ollama was not installed and available memory was limited. The public preview is a static, synthetic example; model narration is available by running the open project locally.</p> <h2> Related reading </h2> <p>Two DEV posts helped shape the constraints: <a href="https://dev.to/qaevelyn/not-in-corpus-teaching-a-local-model-to-abstain-instead-of-hallucinate-3hbm">“NOT IN CORPUS — teaching a local model to abstain instead of hallucinate” by @qaevelyn</a>, which emphasizes tested abstention when evidence is missing, and <a href="https://dev.to/pouria_zand/i-built-a-private-ai-assistant-that-queries-my-git-history-and-project-management-data-using-only-39mn">“I Built a Private AI Assistant That Queries My Git History and Project Management Data — Using Only Local LLMs” by @pouria_zand</a>, which explores keeping repository questions local.</p> <p>The current prototype groups history by month. Next, I would like to let people curate chapters around releases and compare each narration with the exact commit diff. What project memories would help you when you inherit a codebase?</p> <h1> devchallenge #hf26challenge </h1> devchallenge hf26challenge opensource ai