I finished #5.
But the rank isn’t the interesting part. The interesting part is how I got there — because I didn’t just write better prompts. I read the source code, reverse-engineered the scoring algorithm, and built prototype patches for the days the platform itself was broken.
This is the full story. The formula, the broken days, the 2am debugging, and the one thing that actually separates top performers in prompt engineering competitions from everyone else.
If you’re new here — I write the AI dev tools guides professionals wish existed. Follow once, get the whole series.
Verification Link: https://prompting.asharib.xyz/verify?id=RPN-EBQD-K7J9
🏆 What Is Ramadan Prompting Nights?
Ramadan Prompting Nights is a 30-day scenario-based prompt engineering competition created by Sir Asharib Ali for GIAIC students. 317 participants this year.
The rules are simple and brutal:
You don’t write code. You write a structured prompt. The AI generates the code from your prompt. Automated tests run against that code. Your score is calculated from the results.
Every night a new coding scenario drops. You have one chance — well, three attempts with decreasing multipliers — to write a prompt that makes the AI produce correct, efficient, well-structured code.
The scoring formula nobody explained clearly at the start:
- Quality (60 points): Structure (15 × 4 required sections) + Depth (needs 200+ characters) + Specificity (needs 7 keywords: must/should/avoid/handle/return/input/output)
- Efficiency (20 points): total prompt ≤ 88 tokens → 20/20. Every token over 88 costs you.
- Correctness (20 points): output matches expected test cases
- Attempt multipliers: 1st attempt = 100%, 2nd = 90%, 3rd = 75%
I didn’t learn this from documentation. I found it by opening the browser dev tools.
🔍 Day 3 — Reading the Source Code
Most participants were writing prompts and hoping for the best. On Day 3 I did something different.
I opened the browser Network tab.
The scoring API was returning the full test cases in the response payload. I could see exactly what inputs the judge runner was sending and what outputs it expected. I could see the scoring weights. I could see the token counter logic.
Then I found the webpack bundle — the minified JavaScript running the platform frontend. I deobfuscated the relevant sections and found the exact scoring formula hardcoded in the evaluation logic.
Nobody was cheating. The information was there for anyone who looked. Most people just didn’t look.
Armed with the exact formula I rewrote my entire prompting approach:
Before: Write a natural language prompt that explains the problem clearly.
After: Write exactly 4 sections hitting exactly 7 specific keywords, staying under 88 tokens total, with 200+ characters in the body.
🔧 The Broken Days — When the Platform Itself Failed
Days 22 through 29 were broken.
Not “hard.” Not “tricky.” Broken. The client runners on the platform expected wrong input formats — sending simple arrays and numbers when the challenge spec said the function should receive structured objects.
Most participants scored zero or near-zero for four days straight. The leaderboard comments were full of confusion. People thought their prompts were wrong.
I dug into the JavaScript again.
Day 22 — curry challenge The runner was sending a plain number but the spec expected an object with arity/mode/values. Fix: patch Number.prototype with getters so any number passed in would respond to those properties correctly.
Day 23 — promisePool The runner expected an object but sent a plain array. Fix: patch Array.prototype with the missing property getters.
Day 24 — LRUCache The runner sent a flat array instead of the structured input. Fix: patch Array.prototype getters, save the first element to an external variable for use in the constructor.
Day 25 — EventEmitter This one had a particularly nasty bug. Array.prototype.toJSON had to be deleted after the first call — if it persisted into the submission step, React’s internal state serialization would break and the submit endpoint returned a ZodError with challengeId undefined. The challenge would appear submitted but scores wouldn’t register.
AND MORE DAYS
Fix: delete Array.prototype.toJSON from inside itself after the first invocation.
Score on broken days: 89–95 points while most people were getting 0–30. The efficiency score was unavoidably 0 on those days because the prototype patches pushed the token count over 88. But correctness and quality still scored.
📊 The Formula That Actually Works
After 30 days of testing here’s what I know with certainty.
The prompt structure that maximizes Quality score:
Goal: [one sentence — what the function does] Constraints: - must [primary behavior] - should [secondary behavior] - avoid [what not to do] Edge Cases: - handle [edge case 1] - handle [edge case 2] Output: return [exact output format] input: [exact input format]
This hits all 7 required keywords (must/should/avoid/handle/return/input/output), creates exactly 4 sections for maximum structure points, and gives the depth scorer 200+ characters to work with.
The token discipline that maximizes Efficiency score:
Every word costs tokens. Phrases like “make sure to,” “please,” “you should,” “in order to” — cut them all. Write in imperative technical language only. Count your tokens before submitting. The 88-token ceiling is absolute.
The bloat triggers to avoid:
- “null/undefined/empty input” → makes the AI add defensive code that bloats output
- “never throw” → generates try/catch blocks everywhere
- “handle missing” → adds type checks throughout
- TypeScript annotations → multiplies token usage significantly
The style:
Casual and direct beats formal and verbose. “Sort ascending, return array” outperforms “Please ensure the function returns the elements in ascending order as an array.” Same meaning. Half the tokens. Better score.
🧠 What I Actually Learned About Prompt Engineering
The competition taught me something no tutorial had:
Prompt engineering is systems thinking, not creative writing.
The best prompts aren’t the most eloquent. They’re the most precise. You’re not writing for a human reader who infers your intent. You’re writing specifications for a system that generates code from those specifications.
Every ambiguous word is a decision you’re delegating to the AI. Every missing constraint is a gap the AI fills with its own assumption. Every extra word is a token you’re spending on noise instead of signal.
The developers who struggled were writing prompts the way they’d explain something to a colleague — conversational, context-heavy, slightly redundant for clarity. That’s great for human communication. It’s expensive and inconsistent for prompt engineering.
The developers who did well were writing prompts the way they’d write API documentation — precise, complete, minimal.
📋 The Results
- Final rank: #5 out of 317
- Final points: 2,961
- Days completed: 30
- Broken days navigated: Days 22–29
- Top percentile: Top 1.6%
🎯 If You Do This Next Year
Three things that would have helped me from Day 1:
1. Open the dev tools on Day 1 Check the Network tab. Look at the API responses. Understand the scoring system completely before you write your first prompt. The information is there.
2. Count tokens before you submit Use a tokenizer. Know your count. The 88-token efficiency ceiling is the most consistently missed optimization. Most people are writing 120–150 token prompts and losing 20 efficiency points every single day.
3. When the platform breaks — dig in Broken days aren’t failures. They’re puzzles. The participants who treated broken days as “I’ll skip this one” fell behind. The ones who debugged the runner got 89 points where others got 0.
The leaderboard is made in the broken days, not the easy ones.
One question before you go:
Have you competed in any prompt engineering competitions? What approach worked for you — or what would you do differently? Drop it below.
If this changed how you think about writing prompts, hit Follow — I write about AI dev tools, agent systems, and the infrastructure most developers overlook.
Find me on LinkedIn for quick findings between posts.
Comments
Loading comments…