DEV Community: Aditya

While your build runs, walk

Aditya — Sun, 11 Oct 2026 16:13:53 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

A GitHub Actions run already knows how long it is. You start it, and then you sit there, watching a bar that has already done the counting.

Build Break takes that length and puts it on the phone. You paste a public repository, press start, and the screen becomes a clock that stays awake. You leave. If the street is worth keeping, you take one photo. When the run finishes, or when you decide you are done, a short journal entry is waiting.

The first screen says the whole thing in one breath. While your build runs, walk. Snap what you see. An open model writes the entry when you get back.

The screen is a glance. The walk is the rest of it.

Paste owner/repo, or a github.com URL, and the walk follows the newest run that is still going. The browser calls the public GitHub API from the phone, with no token. The countdown is the median of the last ten successful runs, minus the time already spent, and it never goes below zero. A repository with no successful history gets a fifteen-minute guess, and the page says so. "No recent successful runs, so this timer is a fifteen minute guess. The walk still ends when the run finishes." It checks that run every thirty seconds.

If the guess runs out and the build is still going, the headline changes. "Go walk," becomes "Still out." Under it: the build has not finished.

If nothing is in progress, the walk becomes a demo and one line says why. "No run in progress on that repo. This is a demo walk." A rate limit says "GitHub rate limit. This is a demo walk." A malformed URL stays on the start screen: "That does not look like a public GitHub repo." A repository GitHub cannot find stays an error too: "That repository is not public, or it does not exist." I would rather be told than be sent outside on a timer that was never real.

Leave the field blank and it is a demo from the first step, anywhere from ten to sixty minutes. That is the walk in the pictures below. The end is the start plus those minutes, so a reload keeps counting.

Demo

It is live at build-break.onrender.com. Open it on a phone. On a desktop the same page sits in a narrow column, because this is a thing you carry.

Press start with the field empty. The phone says go, and then a number. This one is 32:59, marked demo, with the screen kept awake.

Capture is there if you want a picture. End walk is there if you come back early. In this demo there is no model key, so the note under the photo is written on the machine, one sentence from a small local set:

The way ahead is quiet: pavement, trunks, and a pale sky.

That sentence is a stand-in. It lets you see the shape of a note before Gemma is pointed at a real street. It is not a record of a walk I took.

When the demo clock hits zero, the journal writes the entry in the same voice. You can also end the walk yourself and get the entry then. This one is stamped 11 Oct 2026, 12:45 PM IST, one minute, demo.

I went out Sunday afternoon, 12:45 PM, and stayed for a minute. The way ahead is quiet: pavement, trunks, and a pale sky. It was a short loop, and a good one.

The line I keep looking at is the one above the entry. This week: one walk, one minute outside while CI ran.

Point the app at Gemma and those stand-in sentences are replaced by whatever was actually in the photo, the weather if you allowed it, and how the run ended. On the laptop that model is Gemma 3 4B, because it can see. On Ollama Cloud it is Gemma 4 31B. The prompts stay the same.

Code

The license is MIT. The app is Next.js and TypeScript. Walks, notes, and the journal live in one SQLite file. Photos sit on disk next to it, under DATA_DIR.

GitHub is called from the browser. The model is one chat-completions client. The three screens are a start page, a walk, and a journal.

How I Built It

The open piece is the model, and the model is one HTTP call.

Build Break speaks the OpenAI chat completions API. Three environment variables aim it, and nothing else is hardcoded: LLM_BASE_URL, LLM_MODEL, and LLM_API_KEY. With no key, you get the local stand-in in the screenshots above. LLM_PROVIDER=mock keeps that path even when a key is sitting in the environment.

For a real note I point it at Ollama on the laptop:

LLM_PROVIDER=ollama
LLM_BASE_URL=http://localhost:11434/v1
LLM_MODEL=gemma3:4b
LLM_API_KEY=ollama

The key has to be non-empty, or the app assumes you have not chosen a model. Ollama ignores the value.

The photo needs a model that can see. Gemma 3 at 270M and at 1B is text only, so those builds cannot read a picture. Gemma 3 4B can. It is asked for one short, warm sentence about what someone on a walk would notice: plants, animals, sky, the life of the street. No guessing past what is in the frame. The image is sent before the text, which is the order Gemma prefers.

The same model writes the journal. Three to five sentences, first person, drawn from the time of day, the minutes outside, the notes, and the last few entries. A fact it was not given is left out. Weather appears only if you allowed location. A pattern gets a sentence only when a word actually shows up again. Plain, warm, no hashtags.

Gemma 3, including the 4B, is released by Google under the Gemma Terms of Use (last modified 1 April 2026). The appendix on that page lists Gemma 3. It is Google's own license, with a prohibited-use policy. It is not the Apache License, and it is not an OSI open-source license. I use it because it can see a photo on a machine I already have, and that limit belongs in the post.

When the laptop cannot hold the model, the same client talks to Ollama Cloud at https://ollama.com/v1. The model id is gemma4:31b, taken from Ollama's own list. The :cloud alias is for a signed-in local Ollama, and it is the wrong string to send to the cloud API. Gemma 4 31B takes text and images and returns text, so one model still does both jobs. Gemma 4 is under the Apache License 2.0.

Changing the model is one line.

LLM_MODEL=gemma3:12b

Point LLM_BASE_URL at another host and the prompts stay put.

GitHub is called from the browser, so the request uses the phone's address. Unauthenticated calls are about sixty an hour. That is why a 403 becomes a demo walk with a sentence attached. Photos are resized in the browser to about 1024 pixels on the long edge, saved as JPEG, and only then uploaded to our own API. They are not sent to a model until an endpoint is configured. On localhost, that endpoint is Ollama on the same machine.

The journal clock is the browser's time zone. That is why the demo stamp reads IST. The page asks for location once: add the weather from where you are. A no is remembered. Coordinates are not stored.

Why Does Open Innovation Matter?

The picture is of the street you are standing on. I wanted it read on the machine, with no account and no fee for each photo.

Gemma 3 4B through local Ollama does that. If the sentence is too thin, I change LLM_MODEL. The prompts stay. A closed vision API would have been a shorter afternoon, and then every walk would have been a metered call, with the photo leaving the phone for someone else's account. A walk every time a build starts is a bad match for a meter.

Location is a choice for the same reason. Allow it, and the server asks Open-Meteo for the current conditions. There is no weather key. The sentence comes back in a fixed shape, like "28°C and clear." The latitude and longitude are not written into the journal. Refuse the prompt, and the entry never brings the weather up. Open-Meteo does see the coordinates when you allow them. A model provider does not receive the GPS. The database does not keep a record of where you were.

Gemma 4 is there for the day the laptop is not enough. Because it is Apache 2.0, I can host it, or let Ollama Cloud host it, on the same three variables. The Render blueprint points the host at gemma4:31b on Ollama Cloud, so the phone in your pocket does not have to be the computer that runs the weights.

Prize Categories

Best Use of Gemma. The one-line note and the journal entry are the model's work. On the laptop that is Gemma 3 4B, under the Gemma Terms of Use, because it can see. On Ollama Cloud it is Gemma 4 31B, under Apache 2.0. Either way the app is a thin timer around an open-weight model, and the model is one line to change.

Best Use of Render. Build Break is a Node server with a SQLite file and a folder of photos. That wants a disk that survives a restart. render.yaml is the blueprint: the web service on the starter plan, DATA_DIR at /var/data, a 1 GB disk, and the model variables in the host environment. A persistent disk needs a paid instance. A free instance forgets the journal on restart. The app is live at build-break.onrender.com.

A code edit can pass the request and still drop something the prompt never said

Aditya — Sun, 11 Oct 2026 12:23:15 +0000

This is a submission for the Kaggle Benchmarking Challenge.

What I Benchmarked

Resolve measures a small code change. I wanted a score for the failure I keep seeing: the edit does the thing that was asked, and drops a behavior the prompt never said again.

Each item is one Python function and one requested edit. The model returns only the new function. The score is how many of 16 items are fully resolved, as a float from 0 to 1. A half-fix scores zero on that item.

There are two tasks. resolve checks the new behavior and the old behavior the prompt never restated. resolve-plus adds an edge suite the prompt never showed. The two tasks are separate generations, so the second score can land above the first.

The result this post is about: GPT-6.1 Sol and GPT-5.6 Luna are the only models at 0.9375 on both tasks. The task page rounds that to 0.94. Several other models match 0.9375 on resolve and then score lower on resolve-plus.

How it works

The prompt shows the function, the one change, and two sample inputs. Anything the model writes besides the new function is thrown away. Hidden tests then run in two lists.

Fail-to-pass is the new behavior.
Pass-to-pass is behavior the prompt never repeated.

An item counts only when every test in both lists passes. A timeout, a crash, a missing function, or an empty suite is a failure. One failed test fails the item.

resolve-plus uses the same rule and adds the edge suite. It is a new sample of the 16 items, not a second grade of the first sample.

Inspiration

This is the rule SWE-bench uses for a resolved issue, scaled down to functions I wrote. The paper is Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (ICLR 2024).

SWE-bench does not give credit because a patch compiles or because the new test passes. The issue is resolved only when the fail-to-pass tests and the pass-to-pass tests all pass. Resolve keeps that bar and drops the rest of the scaffolding: no scraped repository, no gold patch in the prompt, no tests written by the model. The failure worth reading is an edit that does the asked change and drops an invariant the prompt did not say again.

Models Tested

I started with one model from each of four families, then ran the Claude, GPT, and Gemini lines the proxy would serve, plus the open models listed below. Frontier and open models are charted separately so a single average cannot hide which group is carrying the score.

Twenty-three models have both scores. A model is on a chart only when both have finished. Blue is resolve. Orange is resolve-plus. Charts are sorted by resolve-plus.

Frontier: Claude Haiku 4.5, Haiku 5.5, Sonnet 5, Sonnet 5.5, Opus 5.5, GPT-5.4 mini, GPT-5.6 Luna, GPT-5.6 Sol, GPT-6.1 Sol, Gemini 3.5 Flash, Gemini 3.5 Flash-Lite, Gemini 3.6 Flash, Gemini 3.7 Flash, and Gemini 3.8 Flash.

Open: Gemma 4 31B, Gemma 4 26B, gpt-oss 20B, gpt-oss 120B, DeepSeek-R1, GLM-5, Qwen 3 235B, Qwen 3 Coder 480B, and Qwen 3 Next 80B Instruct.

Grok 4.5 and Grok 4.6 are in the Kaggle model list. The proxy returned model not found for both, so they are not on the charts. Qwen 3 Next 80B Thinking timed out three times on that same proxy, the last time after 3 of 16 items, so it is off the charts too.

Findings

All 23 models

GPT-6.1 Sol and GPT-5.6 Luna are tied at the top, 0.9375 on both tasks. That is 15 of 16 items, twice.

The next group matches the 0.9375 resolve score and lands at 0.875 on resolve-plus: DeepSeek-R1, Claude Sonnet 5.5, and Claude Opus 5.5. Each of them resolved 15 items on the first task and 14 on the second.

gpt-oss 20B is the bar that runs the other way, 0.75 then 0.875. The second task is a new sample, so a higher resolve-plus score is a different generation, not the edge suite helping. The floor of the combined chart is Qwen 3 235B and Gemma 4 26B, both at 0.6875 on resolve-plus.

Frontier models

The frontier chart is the same tie at the top, then a clean step down.

Opus 5.5 and Sonnet 5.5 both open at 0.9375 and close at 0.875. GPT-5.6 Sol opens at the same 0.9375 and closes at 0.8125, a two-item drop. Sonnet 5 holds 0.875 on resolve and falls to 0.75 on resolve-plus.

Haiku 4.5 and Haiku 5.5 sit on the same pair, 0.875 and 0.875. On these 16 functions the newer small model did not move the score. Gemini 3.5 Flash and Gemini 3.6 Flash sit with them. Gemini 3.5 Flash-Lite is the frontier floor, 0.75 on both.

Open models

DeepSeek-R1 leads the open chart at 0.9375 and 0.875, level with Opus 5.5 and Sonnet 5.5 on the frontier chart. Gemma 4 31B is the only open model that holds 0.875 on both tasks. Gemma 4 26B is last, 0.75 then 0.6875.

Qwen 3 Coder 480B, at 0.875 and 0.8125, beats the larger general Qwen 3 235B, at 0.8125 and 0.6875. gpt-oss 120B and Qwen 3 Next 80B Instruct are flat at 0.8125. gpt-oss 20B is the open-chart exception: its second sample scores 0.875 after a 0.75 first sample.

Score against list price

The runs did not store tokens or a dollar bill, so this is not measured cost per item. The horizontal axis is the published output price per million tokens, taken from a rate card last updated 8 October 2026. That card reports the rates against the Anthropic, OpenAI, and Gemini pricing pages. Expensive is on the left. Cheap is on the right. A line connects models from the same provider. Open models are off this chart, and so are Gemini 3.6 Flash and Gemini 3.7 Flash, because that rate card does not list them. Haiku 5.5 is the under-100k rate. These prompts are one short function.

GPT-5.6 Luna is the efficient point: 0.9375 at $1.20 per million output tokens. GPT-6.1 Sol matches that score at $10. Claude Haiku 5.5 holds 0.875 at $0.50, the same score as Haiku 4.5 at $5 and Opus 5.5 at $20. Sonnet 5 and Sonnet 5.5 share the $10 output price. Sonnet 5.5 is the one at 0.875.

What a flat leaderboard hides

The first pass was one model from each of four families: Claude Haiku 4.5, Gemma 4 31B, GPT-5.4 mini, and Gemini 3.7 Flash. Each resolved 14 of 16 items. The leaderboard looks flat until the second row. Haiku and Gemma stay at 0.875 on resolve-plus. GPT-5.4 mini and Gemini 3.7 Flash fall to 0.8125.

Those two drops are different events.

On ring_push, each of those four models, on both tasks, made the requested change and failed a behavior the prompt never restated. Fail-to-pass passed. Pass-to-pass did not. A looser score would have counted those edits. This one does not. That miss was stable across those eight runs.

GPT-5.4 mini’s lower resolve-plus score is the extra suite. On truncate, the requested change and the old behavior both passed, and the edge suite failed. Haiku and Gemma did not lose an item that way.

Gemini 3.7 Flash’s lower resolve-plus score is a different generation of the same items. collapse_name passed the first time and failed the second. The extra suite was not what moved it.

One number is hiding three things: an edit that breaks an unstated invariant, an edit that misses an edge the prompt never showed, and a second sample of the same item that comes out differently.

One generation was enough to move collapse_name from a pass to a fail. A one-shot score is a noisy picture of a model that is close to the line. The next run I would make is more than one sample per item.

My Benchmark

The public benchmark is Resolve on Kaggle. It is version 1, Apache 2.0, and marked public. The leaderboard on that page shows the first four models. The task pages list every run, including ones that did not finish. A model is in the charts here only when both scores finished.

The two tasks:

Suggested citation: Aditya Kumar Puri. Resolve. https://www.kaggle.com/benchmarks/puriadityakumar/resolve/versions/1, 2026.

References

Jimenez, Carlos E., John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024. https://arxiv.org/abs/2310.06770
SWE-bench. https://www.swebench.com/
Kaggle Community Benchmarks. https://www.kaggle.com/benchmarks
kaggle-benchmarks Python library. https://github.com/Kaggle/kaggle-benchmarks
Google AI. “Introducing Community Benchmarks on Kaggle.” https://dev.to/googleai/introducing-community-benchmarks-on-kaggle-35nc
Frontier model API pricing, last updated 8 October 2026. https://www.developersdigest.tech/blog/frontier-model-api-pricing-june-2026
Anthropic pricing. https://www.anthropic.com/pricing
OpenAI API pricing. https://openai.com/api/pricing
Gemini API pricing. https://ai.google.dev/gemini-api/docs/pricing

I built an agent that asks permission before it touches anything

Aditya — Sun, 30 Aug 2026 18:25:43 +0000

Every agent demo I watched this month had the same ending: the agent clicked "confirm" on itself. Nobody in the video batted an eye. The narrator called it "fully autonomous" and moved on.

That's the part I can't get past. An agent that never stops isn't autonomous, it's just unattended.

So for the WeMakeDevs × TrueFoundry Agent Harness Hackathon, I built Recap: a research-paper autopsy you can drive. You hand it a paper, it dissects it, and every time it wants to do something irreversible, it stops and waits for you. The agent supervises papers. You supervise the agent.

Repo: https://github.com/puri-adityakumar/openwrite

The job I gave it

Research papers are a triage problem. You don't read one paper, you triage forty, and most of them don't deserve the forty minutes. The job I gave the agent: take an arXiv URL or a PDF, and come back with the parts a human actually needs. Not a summary. A workup.

One click from landing to cockpit. The demo credentials sit right there because a tired judge is a real user segment.

What comes back is five surfaces: a live Trail of everything the agent did, a Coverage grid, a Claims↔Evidence table, an Authors tab, and a downloadable Audit. The Claims↔Evidence table is the one I'd want as a reviewer. Every claim in the paper, next to the evidence the agent found for it, and the gaps in between.

The dashboard. First paint shows a populated run, not an empty state. Empty states are where demos go to die.

The pause is the product

Here's the feature I actually care about: three approval gates. Verify, Publish, Save. Before the agent does anything irreversible, it pauses and asks. Not a toast you can ignore. A full stop.

The Verify gate is deliberately obnoxious. Before the paper's untrusted code runs in a sandbox, you have to type the repo owner's name AND hold a button for three full seconds. That's not friction by accident. That's friction on purpose. Papers are not trusted code, and "run the repo this paper links to" deserves a speed bump.

The Verify gate. Type the owner, hold for three seconds. If it feels excessive, try imagining what the code does.

Annoying answer: most agent safety demos are theater. A checkbox nobody reads is consent, not control. A pause you have to hold open is control.

Wiring it up

The stack is boring on purpose: Next.js, Postgres, Redis, one docker compose up, everything local. The interesting wiring is the agent harness.

One command, no clone:

npx @truefoundry/trueforge@latest

That gives me a TrueForge server on localhost:8790. Then I registered GMI Cloud as the model provider, pointed at their Anthropic-compatible endpoint with a custom base_url, running MiniMax-M3. No adapter code. A curl with a manifest, done.

The cockpit mid-run. Real SSE events streaming in: turn created, deltas, tool calls. The Trail on the left is the agent's actual receipt.

My app talks to TrueForge through its REST + SSE API. lib/trueforge.ts ships an HttpTrueForgeClient, and the events come over the wire for real: turn.created, model.message.delta, tool.approval_required, turn.done. When a gate fires, my UI surfaces the pause, and your allow/deny decision routes back to TrueForge through its resume contract. Nothing in the hot path is mocked. There's a smoke script that proves the "pong" in the transcript came from the actual model.

What TrueForge took off my plate

This is the list I'd have underestimated a week ago:

The agent runtime itself: turn lifecycle, retries, cancellation. I would have hand-rolled a state machine and shipped at least two race conditions.
Event streaming. SSE with backpressure and reconnection is a project, not a file.
Model-provider plumbing. Swapping GMI in without writing an adapter was the single best "oh, that's it?" moment of the hackathon.
The approval-pause/resume contract. The hard part of human-in-the-loop isn't the UI, it's freezing a running turn and resuming it correctly after a human decides. That's a solved problem here, and I just used it.
Sandbox handling, with a local fallback when no cloud sandbox is configured.

I wrote the surfaces: gates, trail, audit, the cockpit UI. TrueForge ran the agent underneath them. That division of labor is the whole pitch.

Where it broke

The low point: the demo ran fine until tool execution. Daytona, the sandbox provider, kept refusing the write that publishes a sandbox snapshot. The docs made it sound like write:sandboxes was enough. It isn't. You also need write:snapshots, and nothing tells you that until the API returns a permission error mid-demo.

The fix I reached for was TrueForge's local sandbox fallback, which auto-engages when no cloud sandbox provider is configured. The demo lived. And to be clear about the trade: tool execution behind the gate is skipped right now, and the harness says so honestly in the audit as sandbox.disabled. It doesn't pretend. The audit shows the gap, which is exactly the behavior I built the whole product around.

Honestly, that's the part I'm proudest of: the failure mode is visible, not hidden.

The review loop nobody asked about

Quick one, because it shaped everything: every substantive change landed through a Qodo-reviewed pull request. Thirteen PRs, all reviewed. The approval-gates PR came back with 17 findings across two review passes, including a race condition in my event reducer and a missing TTL guard that could have double-approved a gate. Every finding triaged before merge. The loop became the norm: PR, review, fix, merge. 237 unit tests and 54 E2E tests green at the end of it.

The whole run

If you'd rather watch than read:

180 seconds, the whole run, no cuts.

The audit at the end. Every action logged, every decision attributed. If the agent did it, the audit can prove it.

The agents are coming either way. The interesting question isn't whether they can do the work. It's whether you can see them doing it.

Repo: https://github.com/puri-adityakumar/openwrite

Biryani, With Love: A Deccan-Inspired Interactive Atlas

Aditya — Sun, 02 Aug 2026 11:31:41 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing.

What I Built

Biryani, With Love is an interactive editorial atlas about the many regional traditions that share the name biryani.

I chose biryani because comfort food is rarely only about flavour. It can hold a city, a family ritual, a migration story, a celebration, and a memory of home in the same pot. The landing page follows that idea from Hyderabad through India and across the Indian Ocean.

The experience includes:

A research-led map of eight Indian biryani traditions
A method lab comparing kachchi, pakki, and one-pot cooking sequences
A guided loop through fourteen traditions across nine countries
A comparison tool for grain, method, flavour, heat, perfume, tang, and richness
A historical route connecting language, court kitchens, regional grains, and Indian Ocean migration
A research shelf that makes the supporting sources visible

The visual system is inspired by a contemporary Deccan pavilion. Saffron, peacock green, pomegranate red, plum, brass, and ivory create the palette. The hero uses CSS-built arches, minarets, jali panels, steam, rice grains, garnish, and an open copper handi.

Demo

Open the full CodePen

Journey

Finding the right metaphor

My first version treated the page like a clean editorial index. It was readable, but it did not carry enough of the warmth, ceremony, and visual richness of the subject.

The breakthrough was to stop treating biryani as a list of recipes and instead design an edible atlas. Each section became a different way to read the same dish: geography, cooking sequence, migration, flavour, and memory.

Researching the architecture

The heritage direction was grounded in specific references rather than a generic ornamental style.

I studied the Charminar architecture described by Hyderabad District, particularly its four-sided arches, minarets, carved rings, and Qutb Shahi lotus details. I also looked at a sixteenth-century Indian jali in The Metropolitan Museum of Art, where stars, hexagons, and interlocking geometry create a play of light and pattern.

Those ideas became solid-color architectural frames, small lattice details, geometric rules, and the central handi illustration. I kept the interface modern by using strong editorial typography, square cards, clear hierarchy, and restrained motion.

Correcting the map

The first map used a simplified world dataset and looked noticeably wrong. I replaced it with the official Survey of India 1:16m outline vector, including the island territories.

The eight city points are projected from geographic coordinates instead of being positioned by eye. The map remains a cultural navigation device, but its outline and locations now have a defensible source.

Building the interactions

The project is a single responsive HTML document with inline CSS and vanilla JavaScript. CodePen separates those same three layers into its HTML, CSS, and JavaScript panels.

JavaScript is used purposefully for:

Switching regional map stories
Updating cooking method diagrams
Running and pausing the global biryani loop
Filtering traditions by geography
Comparing two traditions
Updating the historical route
Respecting reduced-motion preferences

The page contains no raster food photography. The hero, diagrams, decorative architecture, and interface details are created with HTML, CSS, and inline vector geometry.

Accessibility and usability

I wanted the atlas to remain useful beyond its visual impact. It includes:

Semantic sections and heading structure
Keyboard-operable SVG map points
Visible focus states
A skip link
Live regions for changing content
Reduced-motion support
Responsive layouts for narrow screens
Source links for the research claims
Clear notes where flavour scores are interpretive rather than scientific measurements

What I Am Proud Of

I am most proud that the page does not rank biryanis or declare one authentic winner. It gives each tradition enough context to feel distinct while showing the shared ritual underneath: rice, patience, adaptation, and memory.

The final result feels like a love letter, a research object, and a modern landing page at the same time.

AI Collaboration

I used OpenAI Codex as a collaborative coding, research, and iteration tool. I directed the concept, selected the biryani theme, reviewed each visual pass, identified inaccuracies, and made the final design decisions. The implementation and research sources were checked and refined through that collaboration.

DUM: Breaking the Seal on Hyderabadi Biryani with Pure CSS

Aditya — Sun, 02 Aug 2026 06:19:47 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

Hyderabadi dum biryani is more than a dish to me—it is a ritual. The sealed handi, the slow charcoal heat, the suspense before the atta crust is broken, and the first rush of saffron, mint, birista, and spice all feel inseparable from the experience.

I wanted to turn that moment into an interactive midnight poster: Hyderabad’s skyline behind a copper handi, with the food hidden until the viewer breaks the seal.

Demo

Click BREAK THE SEAL to lift the lid and reveal the four biryani layers.

How it works

The artwork is built with HTML and CSS only:

A native <details> / <summary> control stores the open and closed states.
CSS :has() coordinates the seal crack, lid lift, layer reveal, steam, labels, embers, and state-aware copy.
Rice grains, mint leaves, birista, spices, meat, copper patina, flour dust, the skyline, and the moon are all CSS shapes.
There are no images, SVGs, canvas, JavaScript, gradients, or frameworks.
A mobile composition and prefers-reduced-motion keep the piece responsive and accessible.

The reveal is deliberately choreographed:

seal cracks → lid lifts → layers separate → labels arrive → steam settles

Journey

The hardest part was keeping the illustration detailed without losing the strong poster silhouette. I iterated on three areas:

Material: hammered copper marks, soot, flour residue, dough cracks, and print texture.
Depth: curved food layers, overlapping grains, steam arches, and ingredient silhouettes.
Motion: a staged opening sequence rather than making every element animate at once.

The most satisfying decision was using a semantic HTML control for the interaction. The artwork still works with a keyboard, and disabling motion does not hide the final state.

I used Codex as an iterative coding and visual-critique partner. I directed the concept, cultural references, composition, and final decisions, while the agent helped implement and test the CSS system.

What I’m proud of

The finished piece stays intentionally constrained: one HTML file, one CSS file, a small palette, and no image assets. The interaction adds drama, but CSS remains the star of the submission.

Thanks for taking a look—and remember: patience is the final ingredient.

AI Storyline Generator

Aditya — Sun, 14 Sep 2025 21:49:45 +0000

This is a submission for the Google AI Studio Multimodal Challenge

What I Built

I created AI Storyline Generator, a web app that turns a set of images and a short text prompt into a cohesive narrative. It helps writers and artists quickly build stories or prototypes by offering three modes: Surprise Me (short story with optional cover art), Light Novel (full chapter with illustrations), and Manga (panel art).

Demo

Demo Video

Screenshots

LINK

Applet Link 🌱
Note: I was not able to publish the app due to billing issues. Please accept the published app link. Thankyou.

How I Used Google AI Studio

Used gemini-2.5-flash-image-preview for vision–language tasks like story generation and all image outputs.
Used gemini-2.5-flash for Manga mode to reliably create structured JSON scripts.

Multimodal Features

Image-to-Story Generation: Combines multiple images and text into a connected plot.
Narrative-Aware Illustration: Generates key-scene illustrations directly from the AI-written story.
Automated Manga Pipeline: Creates a full manga page by chaining image analysis, JSON scripting, and panel art generation

Efficient Architecture 101: Is Your Upload Strategy Actually Efficient?

Aditya — Tue, 26 Aug 2025 17:15:06 +0000

Before we start...

So, why this series? I've recently jumped straight into the complexities of system design, and I think the best approach to learning is by writing blogs and sharing what I have learned. My goal is to create simple blogs with humor and a lot of diagrams. Please note, I'm still learning, so if you're experienced and find something that can be improved or is incorrect, please share your thoughts.

The Challenge: A Real-World Bottleneck

Not long ago, I was digging through a codebase and found a classic file upload setup. The user would select a file in their browser, the browser would send it to our backend server, and then the server would upload it to a cloud storage bucket like AWS S3.

It worked, but it was far from efficient. The architecture looked something like this:

So, approach has some serious drawbacks

It's Slow for the User: The file has to make two trips over the internet. The user is stuck waiting for both to complete.
It Hogs Server Resources: Imagine 100 users uploading large videos at once. Your server is suddenly trying to process gigabytes of data, choking its memory, CPU, and bandwidth. This is a classic scalability nightmare.
It Can Be More Expensive: You're paying for the bandwidth twice – once for the data coming into your server, and again for it going out to the cloud storage. Ouch.

A Slightly Better Approach (That's Actually Worse)

So, to fix the speed issue, why not just upload directly from the browser? Modern tools like the AWS SDK for JavaScript let you do just that. The flow seems simpler and faster.

But this comes with a giant, flashing, red security warning. To allow the browser to upload, you have to embed your secret access keys directly in the frontend code. This is like leaving the master key to your entire house under the doormat.

Anyone with a little know-how can open their browser's developer tools, find your keys, and gain full, unrestricted access to your storage bucket. It's a disaster waiting to happen.

The Real Solution: Pre-Signed URLs

This is where we get the best of both worlds: the speed of a direct upload and the security of a server-managed process.

A pre-signed URL is a special, temporary, and secure link that your server generates. It gives a user permission to perform a specific action (like uploading a file with a specific name) directly to your cloud storage, but only for a limited time.

the browser first asks the server for permission. The server then generates a temporary, pre-signed URL and sends it back. The browser uses this special URL to upload the file directly to cloud storage. The server's only job is to authorize the request, not to handle the heavy file transfer itself.

So, Why prefer pre-singed url for uploads?

Enhanced Security: Your cloud storage credentials are never exposed on the client-side.
Improved Performance: Files are uploaded directly to cloud storage, reducing latency for the user.
Increased Scalability: Offloads the bandwidth and processing load from your server, allowing it to handle more application requests.
Cost Optimization: Reduces egress bandwidth costs from your server.

Best Practices

Use Short-Lived URLs: Always configure pre-signed URLs with the shortest possible expiration time (e.g., 5-15 minutes) to minimize the risk of misuse.
Utilize Multipart Uploads: For large files, leverage multipart uploads. This involves generating multiple pre-signed URLs to upload the file in chunks, which improves reliability.
Implement Resumable Uploads: In case of network interruptions, a robust implementation should allow the upload to resume from the last successfully uploaded part, rather than restarting the entire process.