DEV Community: Devanshukoli

I Had 48 Hours and a GitHub URL. Here's What Broke on the Way to Production.

Devanshukoli — Sun, 09 Aug 2026 16:09:51 +0000

The Zerops Challenge is simple on paper: 48 hours, build something, deploy it on Zerops, submit. What actually happens in those 48 hours is less simple. This is the honest version of mine — what I built, how I actually used AI while building it, and the three specific ways production said no before it said yes.

What I actually built

DevFlow takes a public GitHub repository URL and turns it into something you can actually explore instead of manually digging through. Paste a repo, and it clones it, figures out the languages, frameworks, dependencies, folder structure, and API routes, and turns all of that into a knowledge graph you can query — including asking it plain-English questions about the codebase, grounded in what it actually found, not just a model's general guess about what a typical repo looks like.

The idea came from a problem I actually have: joining an unfamiliar codebase always means the same slow ritual — README, package.json, folder structure, entry point, routes, services, repeat until it clicks. DevFlow is my attempt at compressing that.

The pipeline:

GitHub repo URL
      ↓
Analysis job queued
      ↓
Worker clones + inspects the repo
      ↓
Extract languages, frameworks, dependencies, API surface
      ↓
Project facts into a FalkorDB knowledge graph
      ↓
Explorable report + "Ask DevFlow" Q&A

Three services, deployed on Zerops: the frontend, the API, and a worker that pulls jobs off a queue and does the actual repo analysis in the background — so a big repo doesn't hang an HTTP request while it clones and inspects.

Why I didn't just throw the repo at an LLM

The lazy version of this idea is: clone repo, dump the files into a prompt, ask an LLM to explain it. I didn't want that, for one concrete reason — if you ask an LLM to "explain this architecture" with no grounding, you can't tell if the answer reflects the actual repo or the model's general assumptions about what repos like this usually look like.

So the graph comes first. Facts get extracted deterministically — no LLM involved in deciding "this is a monorepo" or "this exposes a REST API" — and only once those facts exist does the AI layer get to answer questions, using the graph as its source of truth instead of its own memory.

How I actually used AI Studio, honestly

I used Google AI Studio during the build, mostly for prototyping speed. I want to be specific about what that means, because "I used AI" can mean wildly different things, and the Zerops Challenge rules require disclosing this properly anyway — I'd rather over-explain than have it look vague.

I didn't ask it to build the app. I broke the project into individual pieces:

a specific analysis step,
a specific worker task,
a specific piece of the graph pipeline

and had AI Studio implement one bounded piece at a time. Every piece got checked against three things before I moved on:

did it build,
did the tests pass,
did it actually behave correctly when I ran it myself.

If any of those failed, I fixed it, or fed the failure back and re-tried. Nothing got accepted because it looked plausible — it got accepted because I ran it and watched it work.

That distinction mattered more than usual on this project, because the parts that actually took real debugging time weren't things AI Studio touched at all — they showed up once the code hit Zerops in production, which is where prototyping speed stops mattering and the actual environment starts talking back.

Failure #1: Node said 20, pnpm wanted 22

First deploy attempt on Zerops failed immediately:

pnpm 11.20.0
requires at least Node.js v22.13

The Zerops environment was running Node 20. Straightforward once I saw it — pin the base image to Node 22 — but it's the kind of failure that only shows up once you leave your local machine, where whatever Node version happened to be installed just quietly worked.

Failure #2: pnpm blocked its own dependencies

Fixed the Node version, redeployed, hit a new wall:

ERR_PNPM_IGNORED_BUILDS

pnpm's newer dependency build-script approval model was silently refusing to run install scripts for a few packages. This was new to me — I didn't know pnpm distinguished between "installing a dependency" and "letting that dependency run its own build steps" until it stopped one of mine cold. Fix was to explicitly allow the specific build scripts instead of disabling the safety check outright.

Failure #3: it built, then it wouldn't start

This is the one that actually took the longest to figure out, because the build succeeded. Green build, no errors, felt done. Then the process crashed on startup:

TypeError [ERR_INVALID_ARG_TYPE]
The "path" argument must be of type string or an instance of URL. Received undefined

Traced back to fileURLToPath(...) being called with something undefined — an ESM-related path resolution issue that only showed up at runtime, not at build time. Which is the actual lesson here: a successful build tells you the code compiles. It tells you nothing about whether the process survives being started. Those are two different checks, and I'd been treating a green build like a finish line.

The visible symptom downstream was a 502 — because the API process was crashing before it ever bound to a port, health checks failed, and Zerops had nothing to route traffic to. Debugging a 502 by looking at networking first would've been a waste of time here; the process was already dead before networking was even relevant.

How I actually used Zerops

Three services running: the frontend (static), the API, and the worker. The API and worker both needed to talk to Supabase for persisted analysis data and to FalkorDB for the graph layer, so getting service-to-service networking and environment variables right across all three was its own small project. The worker is what makes the async pipeline possible — repo analysis happens off the request thread entirely, so the frontend can show real job progress instead of a spinner that means nothing.

What actually mattered

Not the AI Studio prototyping speed, honestly, even though that helped. What mattered was the loop I used everywhere, on the app code and on the deploy config both: change something, run it for real, read what actually happened, fix the actual cause, repeat. AI Studio moved implementation faster. It didn't skip a single one of these three failures for me — I found all three by reading logs, not by asking a model what was probably wrong.

Repo: https://github.com/Devanshukoli/devflow
Live deployment: https://frontend-2d86.prg1.zerops.app/

My login endpoint had a 5.4 second P99. I was sure I knew why. I was wrong.

Devanshukoli — Sat, 18 Jul 2026 16:06:19 +0000

Found this completely by accident. I wasn't debugging anything, I was just poking around a SigNoz instance I'd self-hosted the night before, ahead of a hackathon build sprint. Opened the Service tab, and there it was.

skillbridge-api — P99: 5449.97ms. Error rate: 0.00%.

Zero errors is the annoying part. Nothing crashed, nothing threw, nothing would ever show up in an alert (not that I have any set up yet, but you get the idea). The app was doing exactly what it was told to do. It just took 5.4 seconds to do it.

Quick context if you're new here: SkillBridge is my side project, ed-tech app, Node/Express backend, Supabase for the DB, React frontend. I wired up SigNoz mostly to see what an actual OpenTelemetry setup looks like on a real app instead of a toy example. Wasn't expecting to find a real bug on day one. Found one anyway.

Trace #1: the login flow

Opened a trace for /api/auth/login:

Login — 873.95ms
Find User — 745.99ms
- a GET out to Supabase — 322.09ms, with tls.connect / tcp.connect / dns.lookup nested inside it
Verify Password — 124.42ms

124ms for bcrypt is fine, that's the whole point of bcrypt being slow. 746ms to fetch one user row is not fine.

The gotcha that had nothing to do with the bug but still cost me 10 minutes

Poking through other traces, I found a service literally named this:

unknown_service:C:\Users\Devanshukoli\scoop\apps\nvm\current\nodejs\nodejs\node.exe

That's what SigNoz falls back to when you forget to set OTEL_SERVICE_NAME. It just uses the binary path instead. Not a big deal until you've got two or three scripts running and your service list turns into unreadable garbage. Fix is one line:

OTEL_SERVICE_NAME=skillbridge-worker node script.js

Mentioning it because nobody tells you this until you hit it yourself, and then it's obvious.

The actual bug

That exact "unknown_service" trace is where the real evidence was sitting, which I only noticed because I'd already opened it to laugh at the naming issue. Seven back-to-back GET calls, each 300–600ms, none of them overlapping:

315.03ms
331.15ms
302.51ms
600.00ms
321.15ms
393.40ms
...
total: 2.52s

Seven round trips to the same downstream service, one after another. Not "one query is slow." Just a straight-up queue that nobody asked for.

My first guess (wrong)

Staring at all those tls.connect spans showing up over and over, I figured: we're probably spinning up a new Supabase client on every request, so we keep paying a fresh handshake each time.

Reasonable guess. Took about a minute to check, and it died instantly:

let supabaseInstance: SupabaseClient | null = null;

export function getSupabaseClient(): SupabaseClient {
  if (supabaseInstance) return supabaseInstance;
  supabaseInstance = createClient(url, anonKey);
  return supabaseInstance;
}

Already a singleton. My theory was just wrong, and I'm glad I checked the file instead of writing that guess down as fact.

What was actually going on

Found it in supabaseGetCurriculum:

const { data: tracks } = await supabase.from('skillbridge_tracks').select('*');
const { data: rawModules } = await supabase.from('skillbridge_modules').select('*').order('order', { ascending: true });
const { data: rawLessons } = await supabase.from('skillbridge_lessons').select('*').order('order', { ascending: true });
const { data: rawProjects } = await supabase.from('skillbridge_projects').select('*');
const { data: progressData } = await supabase.from('skillbridge_progress').select('*').eq('user_id', userId);
const { data: submissionsData } = await supabase.from('skillbridge_submissions').select('*').eq('user_id', userId);

Six queries. None of them need each other's result. All six waiting in line anyway, because that's just how it comes out when you're writing a function at 1am and not thinking about what actually depends on what.

The fix

const [
  { data: tracks },
  { data: rawModules },
  { data: rawLessons },
  { data: rawProjects },
  { data: progressData },
  { data: submissionsData },
] = await Promise.all([
  supabase.from('skillbridge_tracks').select('*'),
  supabase.from('skillbridge_modules').select('*').order('order', { ascending: true }),
  supabase.from('skillbridge_lessons').select('*').order('order', { ascending: true }),
  supabase.from('skillbridge_projects').select('*'),
  supabase.from('skillbridge_progress').select('*').eq('user_id', userId),
  supabase.from('skillbridge_submissions').select('*').eq('user_id', userId),
]);

Where I have to be honest with you

Ran it. First trace after the fix: 1.49s total, and two of the calls clearly ran at the same time, no repeated handshake between them. I was pretty happy about that.

Ran the exact same endpoint again a few minutes later. 2.44s. Three separate calls, each one paying its own tls.connect and tcp.connect again, like nothing carried over from the last request at all.

Same code path. Same endpoint. Two completely different results. I wanted to go check the Service tab and see if P99 had actually moved over the last hour, and make sure my dev server had actually restarted with the new code instead of me testing against a stale process. Then my laptop crashed. An hour before this was due.

So that's where it ends for now. Not fixed-and-confirmed. Fixed-and-hopeful. Which, if I'm honest, is closer to how most of my debugging actually goes anyway.

What I'd tell past-me

Zero error rate doesn't mean zero problems. Nothing pages you for "technically correct but slow."
Check your theory against the actual code before you say it out loud. My first guess sounded smart and was completely wrong.
Promise.all isn't magic, it just relocates the bottleneck. I've now got a single query sitting around 1s that I still need to look at.
One good trace after a fix proves nothing on its own. Two traces disagreeing means you need the aggregate number, not another screenshot.

If you're building something and haven't wired up tracing yet, do it before you think you need it. I self-hosted SigNoz for this, and it found me a bug I wasn't even looking for on day one. Probably will for you too.