DEV Community: Komal Harshita

Ghost in My Code: an open-weight code archaeologist for code nobody documented

Komal Harshita — Thu, 29 Oct 2026 13:47:36 +0000

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

What I Built

Ghost in My Code is a code archaeologist. You paste in a snippet you inherited — the Python 2 file nobody will admit to writing, the callback pyramid from before async/await, the C string handling that still compiles — and it returns an autopsy: what the code actually does, which patterns are outdated, a suggested modern rewrite, line-by-line notes, an honest list of uncertainties, and a short fictional "Ghost Diary" written in the voice of the code itself.

I read "Ghost in the Machine" literally and kindly. The ghost isn't a monster — it's the previous developer, who is usually a slightly younger version of you, and who did their best with the idioms they had. Día de los Muertos is about keeping the dead in the room with you, not exorcising them, so the whole interface is a warm terminal you set a relic on and examine. The narrative voice is clearly labeled fiction; the technical findings are grounded in the actual snippet.

The rule I held myself to while building it: the app may only claim what it actually did. It never executes your code, never says a rewrite is verified equivalent, and never shows a pre-written report without stamping it DEMO REPORT.

Demo

Live app: ghost-in-my-code.lovable.app
Public archive: ghost-in-my-code.lovable.app/gallery

Try this in about twenty seconds: open the app, pick a sample relic from the four bundled ones, and read the four report tabs — Overview, Code Autopsy, Modernization Studio, and Ghost's Diary. The Autopsy separates deterministic findings (regex checks the app ran itself) from model observations, so you can always tell which is which. Save a relic and it lands in the shared archive, visible to every other visitor, which is why the save dialog says so out loud.

If the model can't answer, the header tells you which provider is wired up and why the run failed, instead of quietly handing you something else.

Code

The full source is at: https://github.com/komalharshita/ghost-in-my-code.git

What's in there:

src/lib/ghost/
  types.ts               typed report + input models
  validate.ts            JSON extraction, report schema validation
  deterministic.ts       regex static checks (never runs the code)
  samples.ts             four bundled sample relics + demo reports
  analyze.functions.ts   server function: provider, prompt, retry, errors
  storage.ts             shared relic archive (list, save, rename, delete)
src/routes/
  index.tsx              workspace: relic panel + findings panel
  gallery.tsx            public archive with language filters
src/test/                12 tests: validation, extraction, static checks, routing

How I Built It

React + TypeScript + Tailwind on TanStack Start, deployed as a Cloudflare Worker.

The open-weight model. Analysis runs through an OpenAI-compatible chat endpoint, and the preferred provider is google/gemma-3-27b-it served by Hugging Face Inference Providers, selected purely by a server-side key. Nothing about the app is Gemma-specific: OPEN_MODEL_BASE_URL and OPEN_MODEL_ID point it at any OpenAI-compatible host serving any open model, so swapping in a smaller Gemma for local use is an environment variable, not a refactor.

The model is the smallest part of the pipeline. Around it sits a deliberately boring harness:

Validate input server-side — language whitelist, 8,000-character cap, title length.
Best-effort rate limit (8/min per worker instance).
Run deterministic regex checks so the report has claims the app proved itself.
Send the snippet to the model inside <relic> tags, with a system prompt that declares the code untrusted data, forbids following instructions embedded in it, forbids claiming execution, and forbids inventing APIs, authors, dates or benchmarks.
Extract and validate the JSON against a report schema; on failure, one corrective retry asking for only the corrected object; on second failure, return a real error.
Return a typed report — the client renders model output as text, never as HTML.

Honesty is a schema, not a vibe. The report type carries source (ai or demo), provider, model, and an openWeight flag, and the UI prints them. Demo reports are pre-written for the four bundled samples and are stamped DEMO REPORT · PRE-WRITTEN, NOT A LIVE AI ANALYSIS. There is no path where a demo report reaches the screen unlabelled.

The shared archive. Saved relics live in a Postgres table, not in your browser, so the gallery is a real artifact other people can add to. Anyone can read and insert; rename and delete go through SECURITY DEFINER RPCs that check a per-relic edit token handed out at insert time and kept only in the creator's browser. No accounts, no passwords, and still no way for a stranger to rewrite your relic.

A caveat I'd rather state than have you find. My Hugging Face account is out of inference credits today, so live Gemma runs currently return 402 and the app shows exactly that message. The wiring is in place and the header names the provider; a clean live run needs credits on the account. I don't want to imply a run I haven't done.

Why Does Open Innovation Matter?

Because a code archaeologist that only works while a paid key is valid isn't an archaeologist, it's a subscription.

Three things open weights made possible that a closed API wouldn't have:

The model is replaceable by design. Gemma is the target, but the app only knows "an OpenAI-compatible endpoint and a model id." That's the whole integration surface, and it exists because I started from an open model rather than a vendor SDK. A closed API would have quietly become the product's architecture.

Legacy code is the worst possible thing to send to a vendor. The snippets people paste in are exactly the code they shouldn't be shipping to a third party — internal systems, unmaintained in-house tools, a university assignment from someone who never consented to being ingested. Open weights mean "run this on your own machine" is a real instruction, not a marketing line, and the app says plainly which provider your code is going to before you send it.

The license story stays honest. My code is MIT. Gemma's weights are under Google's Gemma Terms of Use, and the README says so instead of pretending one license covers both. A project that ships model output as its core feature should be able to name the terms behind every byte of it.

Open also made the fallback design possible. When no open-weight key is configured, the app will use a proprietary model — but it prints proprietary fallback, never open-weight. You only build that distinction if the open model is the default you're trying to reach.

The Spirit of It

The first time the diary generator ran on the Python 2 sample, it produced a line about hoping someone had finally written the documentation. It sat there in the panel, a few lines of invented feeling attached to eleven lines of real code that had genuinely outlived every person who understood it, and I understood the pitch better than any spec I had written.

The archive is what made it stick. It currently holds one relic — a throwaway test entry I never cleaned up — so the gallery is honestly a beginning, not a collection. But the shape is right: strangers dropping in fragments of code that outlived their context, each with a report and a short fictional voice attached, the way you'd leave something on an ofrenda. Nobody has to be the last person who remembers what a piece of code was for.

Prize Categories

Best Use of Gemma — the analysis is built around google/gemma-3-27b-it via Hugging Face Inference Providers, with the provider layer written so any OpenAI-compatible open-weight host can be swapped in by environment variable.

ListingSmith — an open-weight AI listing writer for Etsy & eBay sellers

Komal Harshita — Sat, 17 Oct 2026 14:16:31 +0000

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

What I Built

ListingSmith turns rough product notes into a sell-ready marketplace listing in seconds. Paste in a few lines about your product — materials, size, story, care instructions — and it produces a marketplace-compliant title, description, bullet points, tags, a price suggestion and an SEO tip, all tuned to the real rules of the platform you picked (Etsy's 140-character titles and 13 tags, eBay's 80-character titles).

It also shows a profit calculator next to every listing: platform listing fees, payment processing, shipping and your margin, in Indian rupees — so a seller knows whether the price actually makes money before they hit publish.

Who would pay for it? Small makers and resellers. Writing one good Etsy listing by hand takes 20–40 minutes of fighting title limits and tag rules. A seller listing 50 products a month gets hours back, and the open-weight models it runs on cost a fraction of a rupee per listing.

Demo

Live demo: https://my-listing-smith.lovable.app

Try it with the sample notes already filled in — pick Etsy or eBay, choose a tone, and hit "Write my listing".

Code

The full source is MIT-licensed:

komalharshita / listing-smith

ListingSmith

Rough notes in, sell-ready listing out. An open-weight AI listing writer for Etsy and eBay sellers, running on DigitalOcean GenAI Serverless Inference.

Built for Hacktoberfest Hack Day Pune × AI Hackers Collective — Best Open-Source AI Project (Side Hustle theme).

Why someone would pay for it

Small makers spend 20–40 minutes per listing fighting title limits, 13-tag rules and SEO. ListingSmith produces a marketplace-compliant title, description, bullets, tags, price check and SEO tip in seconds, for well under a cent per listing.

Why open weights matter here

Swap models freely — Llama 3.3 70B, Mistral Nemo, DeepSeek R1 Distill, Llama 3 8B. Pick quality vs. speed per listing.
Cost — open models on serverless inference cost a fraction of closed APIs; a seller can generate hundreds of listings for a few rupees.
Data control — seller notes go only to the seller's own DigitalOcean endpoint; nothing is stored. Point…

View on GitHub

Highlights of the codebase:

src/lib/listing-pipeline.ts — pure, unit-tested prompt building and output parsing. Marketplace rules (title length, tag count, tag character caps) live here as data, enforced after parsing so the model can never overflow them.
src/lib/listing.functions.ts — the server function that validates input (zod) and routes to either the built-in AI gateway or any OpenAI-compatible endpoint.
src/lib/listing-costs.ts — pure fee/shipping/profit math for Etsy and eBay, with tests.
Dockerfile + .do/app.yaml — one-command deploy to DigitalOcean App Platform.

How I Built It

The stack is TypeScript, React 19, TanStack Start, Tailwind CSS v4 and Vitest, containerised with Docker for DigitalOcean App Platform.

The AI core is built around open-weight models served through DigitalOcean GenAI Serverless Inference (an OpenAI-compatible API). The model picker offers:

Llama 3.3 70B Instruct (Meta)
Mistral Nemo 12B (Apache 2.0)
DeepSeek R1 Distill Llama 70B (MIT)
Llama 3 8B Instruct (fast/cheap tier)

The pipeline is: seller notes → buildMessages() (a system prompt that demands strict JSON with marketplace limits baked in) → model → parseListing() (strips reasoning blocks and code fences, extracts the JSON, then hard-enforces title/tag caps and de-duplicates tags). Because the rules are enforced in code, not just requested in the prompt, the output is compliant even when a smaller model gets sloppy.

Two environment variables configure it: DIGITALOCEAN_GENAI_API_KEY and DIGITALOCEAN_GENAI_BASE_URL.

Why Does Open Innovation Matter?

This project simply doesn't work as a closed-API product:

Cost — a side-hustle seller can't pay per-token closed-model prices for a tool that saves them 30 minutes. Open-weight models on serverless inference cost well under a cent per listing, so the tool can be free or nearly free
Data control — sellers' product notes are their business. With an OpenAI-compatible endpoint they choose, notes go only to infrastructure they picked — or nowhere at all, with local Ollama.
Tunability — the prompt and parsing rules are plain, tested code, and the model is swappable. A seller can fine-tune a Llama on their own best-selling listings and plug it straight in. No closed API offers that without lock-in.
Licences that match the spirit — the code is MIT, and the models it ships with are Apache 2.0 / MIT / Llama Community License. Anyone can fork it, self-host it, and sell with it.

My Agent Session

I built this with an AI coding agent (Lovable). The agent wrote the pipeline, UI, tests, Dockerfile and deploy spec; I steered the product decisions — the side-hustle angle, the rupee-denominated profit calculator, and the open-weight model lineup.

Prize Categories

Best Open-Source AI Project — the core mechanic is open-weight models (Llama, Mistral, DeepSeek) behind an OpenAI-compatible endpoint, the code is MIT-licensed, and it can run fully offline on local inference.

Deploying My Portfolio with Kuberns AI — Easier Than I Expected

Komal Harshita — Mon, 02 Mar 2026 10:12:33 +0000

I’ll be honest.

Deploying projects is usually the part I delay the most.
Not because I don’t finish building them — but because hosting, setup, and infrastructure always feel overwhelming.

This time, I decided to try deploying my portfolio using Kuberns AI’s one-click deployment.

And it was… surprisingly simple.

My Portfolio Is Now Live

Here’s the link:
👉 https://portfolio-main-73f0916.kuberns.cloud/

Seeing it live felt good — especially knowing I didn’t struggle with complicated configuration to get there.

What the Process Looked Like

It was basically:

Connect my code
Click deploy
Wait a few minutes
Get a live URL

No server setup.
No manual infrastructure configuration.
No confusing steps.

For someone who’s still learning and not deeply into DevOps, that made a big difference.

The Dashboard Experience

The Kuberns dashboard was straightforward.
I could clearly see:

Deployment status
Resource usage
My live URL
Build history

Everything was organized in one place, and I didn’t feel lost navigating it.

How AI Helped

What stood out most was how smooth everything felt.

Instead of worrying about technical setup, I could focus on improving my portfolio itself — refining content, fixing UI details, and making sure everything worked properly.

The AI-driven deployment removed that “deployment fear” barrier.

Why This Matters (At Least For Me)

As students and early developers, we build a lot.
But we don’t always ship.

Making deployment easier makes it more likely that we actually publish our work instead of leaving it on localhost.

If you’re building projects and want a simpler way to go live, you can check it out here:
👉 https://kuberns.com

This experience reminded me that sometimes the hardest part isn’t coding — it’s putting your work out there.

Now that my portfolio is live, I’m more motivated to keep building and keep shipping.

From Prompts to Pipelines: What I Learned About Building Real AI Agents

Komal Harshita — Thu, 04 Dec 2025 05:06:43 +0000

From Prompts to Pipelines: What I Learned About Building Real AI Agents

When I joined the AI Agents Intensive, I thought “agents” were nothing but just smart chatbots. And by the end, I was building ProdigyFlow — a full multi-agent pipeline that loads raw data, cleans it, analyzes it, creates charts, and finally produces an automated report.

This course completely changed how I think about AI.

The biggest shift for me was understanding that agents are not one big model — they’re a team. Each agent has a job, its own tools, and a clear role in the pipeline.
In ProdigyFlow, we built:

a Cleaning Agent to fix messy data
an Analysis Agent to derive insights
a Visualization Agent to generate graphs
and a Main File to make them work together smoothly

Seeing these parts collaborate felt like building a small company inside Python.

There were a lot of behind-the-scenes struggles too:

API keys broke so many times we memorized our .env file 😭
GitHub workflows failed at 2 AM for reasons we did not understand
We learned how important logs, error handling, and reproducible runs really are
Python libraries (Pandas, Matplotlib, tqdm) became our superpowers

But every challenge made the final system more real.

This project also became a true team win. My teammate Priyamvadha and I figured things out together — fixing bugs, testing agents, and redesigning the pipeline more than once.

Here are the project links if you want to explore:
🔗 GitHub: https://github.com/komalharshita/prodigyflow
🔗 Kaggle Submission: https://www.kaggle.com/competitions/agents-intensive-capstone-project/writeups/ProdigyFlow
🔗 My LinkedIn: https://www.linkedin.com/in/komalharshita/

Huge thanks to Google, Kaggle, and the mentors for creating this opportunity. I started this course writing simple prompts, and finished by building an end-to-end intelligent pipeline.