DEV Community: YASHWANTH REDDY K

I Built a Spatial Audio Radar ft. Vibe Code Arena

YASHWANTH REDDY K — Mon, 27 Apr 2026 09:24:02 +0000

It looks like a visual problem at first.

A circle in the center.
Click somewhere → a glowing ring expands.
A sound plays.

Nice little sci-fi UI.

But the moment you try to make the sound feel like it’s actually coming from where you clicked…

Everything changes.

Because now you’re not building a visualizer.

You’re building a coordinate system that humans can hear

The illusion breaks immediately

You can get something working fast:

audio.play();

Click → sound.

Done.

But it doesn’t matter where you click.

Left side. Right side. Edge. Center.

It all sounds the same.

And that’s the problem.

Because visually, you’re telling the user:

“Sound originates from this exact point”

But aurally, you’re saying:

“Actually, it comes from nowhere in particular”

That mismatch kills the illusion instantly.

This isn’t about sound playback

It’s about spatial mapping

You don’t just need to play audio.

You need to answer:

“Where is this sound located relative to the listener?”

In 2D, that reduces to something simple:

Left ↔ Right

Which maps perfectly to stereo panning.

The mistake most implementations make

They treat the click position as absolute.

const pan = mouseX / width;

This gives you a value between 0 and 1.

But audio panning expects:

-1 → full left  
 0 → center  
 1 → full right

So your mapping is already wrong.

Even if the math “works”.

The correct mental model

Everything is relative to the center of the radar

Not the screen.

So you calculate:

const centerX = rect.left + rect.width / 2;
const dx = (mouseX - centerX) / (rect.width / 2);

Now dx ranges from:

-1 → far left  
  0 → center  
  1 → far right

This one line fixes the entire spatial illusion.

The sound engine becomes directional

Now instead of:

audio.play();

You route it through a panner:

const panner = ctx.createStereoPanner();
panner.pan.value = dx;

And suddenly…

Clicks on the left sound left.

Clicks on the right sound right.

The system feels grounded.

The visual pulse is not decoration

It’s confirmation

When you click, you create a ring:

ring.style.transform = "scale(1.5)";
ring.style.opacity = 0;

It expands. Fades.

But the important part is not the animation.

It’s that it originates from the exact click point.

Because now:

your eyes see origin
your ears hear direction

And they agree.

That agreement is what makes the system feel real.

The center ripple reveals something subtle

Every click also triggers a center pulse.

At first, it feels redundant.

Why animate the center if the click is elsewhere?

Because it anchors the system.

It reminds the user:

“You are here. Everything is relative to this point.”

Without it, the radar feels like a canvas.

With it, it feels like a system.

The drone toggle is not just a feature

It’s a baseline

When everything is silent, each click feels isolated.

Disconnected.

Add a continuous ambient loop:

drone.loop = true;
drone.play();

Now clicks exist within a soundscape.

And spatial differences become more noticeable.

Because there’s contrast.

Timing becomes perception

If the sound plays even slightly late…

The illusion breaks.

Visuals are immediate.

Audio must match.

Which is why you avoid delays and keep everything inside the same event frame.

The radar is secretly a coordinate system

That circle in the center?

It’s not just visual.

It defines:

bounds
center
interaction area

Everything depends on its dimensions:

const rect = radar.getBoundingClientRect();

If this is off…

Your spatial mapping drifts.

And the user feels it.

Even if they can’t explain why.

Where most implementations go wrong

Not in sound.

Not in visuals.

In alignment

They:

calculate pan from screen width instead of radar
misplace center
delay audio playback
desync visuals and sound

Individually, these are small issues.

Together, they break immersion.

What shows up in Vibe Code Arena

This challenge creates a very specific divide.

One model builds:

nice visuals
working sound
basic interaction

But sound feels disconnected from position.

Another model aligns everything:

correct center-relative mapping
immediate audio feedback
synchronized visuals

Now the system feels spatial

The human version usually does one thing right

It treats the center as sacred.

Everything is calculated relative to it.

Because once that’s correct…

Everything else falls into place.

The part you don’t expect

After building this, you stop seeing:

“click → play sound”

And start seeing:

“input → spatial mapping → audio perception → visual confirmation”

That pipeline is the real system.

The shift

You stop thinking:

“how do I play sound?”

And start thinking:

“how do I place sound in space?”

That’s a very different problem.

If you want to explore this properly

Don’t just click around.

Test it intentionally:

click extreme left/right edges
click near center
resize the window

Watch how your mapping behaves.

That’s where inaccuracies show up.

Because this system doesn’t fail loudly.

It fails in how convincing it feels.

And that’s much harder to debug.

👉Try it out here: https://vibecodearena.ai/share/c73a3887-794c-4012-a0af-f448f2a137d6

I Built a Generative Poster Tool ft. Vibe Code Arena

YASHWANTH REDDY K — Sun, 26 Apr 2026 14:30:41 +0000

There’s a very specific kind of disappointment that happens with generative design tools.

You click “Generate.”

Shapes appear. Colors shuffle. Layout changes.

Technically, it’s working.

But visually?

It looks like someone dropped geometry on the screen and walked away.

That’s the trap.

Because randomness alone doesn’t create design.

It creates noise.

And this challenge — building a “Generative Abstract Poster Creator” — quietly forces you to confront that.

The first version always lies to you

You start simple.

A loop:

for (let i = 0; i < 15; i++) {
  createRandomShape();
}

Each shape gets:

random position
random size
random color

It feels productive.

Until you actually look at the result.

Everything overlaps awkwardly.
Spacing feels accidental.
Nothing aligns.

There’s no visual rhythm.

Just entropy.

The realization hits fast

Design is not randomness.

It’s controlled randomness inside constraints

And the moment you introduce constraints…

Everything changes.

The grid is the invisible system

The requirement says:

Snap shapes to a 4x4 or 8x8 grid

At first, that sounds like a layout detail.

It isn’t.

It’s the entire system.

Instead of placing shapes anywhere:

const x = Math.random() * width;
const y = Math.random() * height;

You snap them:

const cell = 50;

const x = Math.floor(Math.random() * 8) * cell;
const y = Math.floor(Math.random() * 12) * cell;

Now every shape aligns to an invisible structure.

And suddenly…

The output starts looking intentional.

This is where things get interesting

You haven’t changed:

number of shapes
types of shapes
randomness

You’ve only added constraint.

And yet the result feels like design.

Because human perception loves alignment.

Even when it’s not obvious.

Shapes are not equal

Another mistake shows up quickly.

You treat all shapes the same.

Circles, squares, triangles, lines.

Uniform probability.

But real compositions don’t work like that.

They have hierarchy.

Weight.

Balance.

So you start biasing:

const type = weightedRandom([
  "circle",
  "square",
  "triangle",
  "line"
]);

Now some shapes appear more often.

Others become accents.

And the composition gains structure.

Size is where chaos sneaks back in

Even with a grid, random sizes can break everything.

A giant circle can overpower the layout.

Tiny shapes can disappear.

So you constrain size too:

const sizes = [1, 2, 3]; // grid units
const size = sizes[Math.floor(Math.random() * sizes.length)];

Now everything scales relative to the grid.

No rogue elements.

The color palette is doing more than styling

Switching between:

Bauhaus
Forest
Cyber

Sounds like a theme toggle.

But it’s actually controlling contrast relationships.

If you randomly pick any color:

You get clashes.

If you pick from a curated palette:

You get harmony.

const palette = ["#ff0000", "#0000ff", "#ffd500"];
const color = palette[Math.floor(Math.random() * palette.length)];

This tiny constraint removes 90% of bad outcomes.

Overlap is not a bug

It’s a feature — if handled correctly

When shapes overlap, things can look messy.

Unless you control how they blend.

This is where:

shape {
  mix-blend-mode: multiply;
}

changes everything.

Now overlaps create new colors instead of visual clutter.

It feels intentional.

Almost printed.

Without this, your design looks like layers.

With it, it looks like composition.

The poster is not just a container

That 400x600 rectangle?

It defines proportion.

Which defines everything inside it.

If you don’t respect boundaries:

Shapes overflow.

Edges feel accidental.

So you enforce limits:

x = Math.min(x, width - shapeWidth);
y = Math.min(y, height - shapeHeight);

Now nothing escapes.

Everything feels contained.

Containment is what makes it feel like a “poster”

Not just a canvas.

Hover interactions reveal something deeper

Adding a tooltip:

coordinates
dimensions

Feels like a small feature.

el.onmouseenter = () => showTooltip(x, y, w, h);

But it exposes the system underneath.

Now users can see the grid

Even if it’s invisible.

And once they see it…

The randomness feels less random.

More deliberate.

The “Generate” button is misleading

It sounds like a trigger.

But it’s actually a reset.

Each click:

destroys the previous composition
creates a new one
reuses the same rules

That consistency is important.

Because if rules change between generations…

The system feels unstable.

What shows up in Vibe Code Arena

This challenge reveals something subtle.

Not who can generate shapes.

But who understands design systems

One model builds:

fully random placement
random colors
no constraints

It technically satisfies requirements.

But outputs feel chaotic.

Forgettable.

Another model introduces:

grid snapping
palette constraints
size normalization
blending modes

Now outputs feel… curated.

Even though they’re still random.

The human version usually leans into restraint

Not more features.

Not more randomness.

Just tighter rules.

Because good generative design is not about freedom.

It’s about guided variation

The strange shift that happens

At some point, you stop thinking:

“How do I generate more variety?”

And start thinking:

“How do I prevent bad outcomes?”

That’s when your system matures.

Because the goal isn’t infinite randomness.

It’s consistently good enough randomness.

The part you don’t expect

After building this, you start noticing something.

A lot of “design tools” are just:

randomness
with weak constraints

Which is why their outputs feel generic.

The difference between:

amateur generative design
and professional-looking output

Isn’t complexity.

It’s discipline in constraints

The shift

You stop seeing:

“random shapes on a poster”

And start seeing:

“a system generating compositions within a bounded design language”

That’s a very different mindset.

Because now you’re not designing outcomes.

You’re designing rules that produce outcomes

If you want to explore this properly

Don’t just build it once.

Tweak the constraints.

change grid density
limit color combinations
adjust size distribution

Watch how outputs evolve.

That’s where the real learning is.

Because this challenge looks like a UI generator.

But it’s actually about something deeper:

how structure creates beauty… even when randomness is involved

👉Try this exact challenge here: https://vibecodearena.ai/share/efdbbe8e-2b33-4e31-a15a-569ae1326b72

I built Geometric Breathing & Meditation app on VCA

YASHWANTH REDDY K — Sat, 25 Apr 2026 14:25:39 +0000

The Animation Isn’t Breathing — Your Timing Logic Is

At a glance, this feels like one of those “calm UI” exercises.

A soft glowing shape.
Expand… hold… contract.
Maybe a gentle color palette and a faint sound.

It looks simple enough that most people jump straight into CSS animations.

And that’s exactly where things go wrong.

Because the moment you try to sync everything — motion, sound, counters, presets — you realize:

This is not an animation problem.
This is a timing system pretending to be one.

The illusion of “just use CSS animation”

The obvious move:

@keyframes breathe {
  0%   { transform: scale(1); }
  33%  { transform: scale(1.3); }
  66%  { transform: scale(1.3); }
  100% { transform: scale(1); }
}

Looks perfect on paper.

expand (0 → 33%)
hold (33 → 66%)
contract (66 → 100%)

Done.

Until you try to:

play a sound exactly at inhale
increment a counter per full cycle
change speed dynamically
switch presets mid-cycle

Now your animation is running on one timeline…

…and your logic is guessing where it is.

This is where most implementations drift

You end up writing code that tries to “sync” with CSS:

setInterval(() => {
  playSound();
}, 4000);

It works.

Until:

the tab loses focus
frame timing shifts
animation delays slightly

Now your sound is out of phase.

Your counter increments late.

Your “breathing” feels… mechanical.

The shift: stop syncing to animation

Start driving animation from time

Instead of asking:

“What is the animation doing right now?”

You flip it:

“What phase should we be in right now?”

You define time explicitly:

const PHASES = ["in", "hold", "out"];
const DURATION = 4000;

And track real progression:

const elapsed = (Date.now() - startTime) % (DURATION * 3);

Now you know exactly:

which phase you're in
how far into it you are

No guessing.

No syncing hacks.

The geometry isn’t decorative

It’s expressive

The requirement says:

6–8 segments forming a shape

Most implementations just duplicate elements.

But the interesting part is how they behave together.

A single petal scaling is boring.

Multiple petals slightly offset in rotation?

Now you get something organic.

.petal {
  transform: rotate(var(--angle)) scale(var(--scale));
}

That --angle isn’t styling.

It’s structure.

The “bloom” effect is not about size

It’s about stagger

If all segments animate identically, the shape feels rigid.

If each segment has a slight delay or opacity variation…

It feels alive.

CSS variables quietly become your control panel

This is where the system gets interesting.

Instead of hardcoding values:

.petal {
  background: teal;
  transition: 4s;
}

You externalize everything:

:root {
  --duration: 4s;
  --color: #4fd1c5;
}

Now your entire animation becomes configurable.

And JavaScript doesn’t “change styles”.

It changes parameters.

Presets stop being themes

They become system reconfigurations

Switching to “Fire” isn’t just color.

It’s:

faster duration
sharper easing
higher contrast

document.documentElement.style.setProperty("--duration", "2s");

That one line reshapes the entire experience.

The sound exposes your timing bugs instantly

Visual drift is subtle.

Audio drift is obvious.

If your “ding” doesn’t land exactly at:

inhale start
exhale start

The whole system feels off.

Which is why this matters:

if (phaseChanged) {
  playTone();
}

You’re not triggering sound on intervals.

You’re triggering it on state transitions.

That’s a different mindset.

The breath counter is deceptively strict

It doesn’t count:

expansions
contractions

It counts full cycles

Which means:

if (phase === "in" && previousPhase === "out") {
  cycles++;
}

Tiny detail.

But if you get this wrong…

Your app feels inaccurate.

And in a meditation context, that matters more than visuals.

What shows up in Vibe Code Arena

This challenge separates two kinds of thinking.

One model builds an animation:

smooth CSS
decent visuals
loosely synced JS

It looks calming.

But feels slightly disconnected.

Another model builds a timing system:

explicit phase tracking
CSS driven by variables
JS controlling truth

Now everything aligns:

motion
sound
counting

And the app feels… intentional.

The human version usually does less

But anchors everything in time

Not more animations.

Not more effects.

Just one decision:

Time is the source of truth

Everything else follows.

The part you don’t expect

After building this, you stop seeing:

“a breathing animation”

And start seeing:

“a synchronized system of phases, driven by time, expressed through visuals”

Which is the same pattern behind:

audio engines
game loops
real-time dashboards

Try this before you move on

Don’t just make it smooth.

Make it consistent.

Switch presets mid-cycle
Tab out and come back
Let it run for minutes

Does it stay aligned?

Or does it drift?

If you want to explore how different approaches handle that tension between animation and timing, this is the exact challenge:

👉 https://vibecodearena.ai/share/dabe3e01-ecec-4241-9337-7894057f1d19

Play with it.

But more importantly — observe when it stops feeling natural.

That’s where the real problem is hiding.

I built a Cyber-Cipher Text Decoder on Vibe Code Arena

YASHWANTH REDDY K — Fri, 24 Apr 2026 13:41:40 +0000

There’s a version of this app that’s technically correct.

You type text.
Click a button.
It returns encrypted output.

Done.

And yet… it feels completely lifeless.

Because nothing happened.

The system skipped the most important part:

the transition between meaning and noise

The part everyone rushes past

Encryption is usually treated like a function.

function caesar(str, shift) {
  return str.replace(/[a-z]/gi, c =>
    String.fromCharCode(c.charCodeAt(0) + shift)
  );
}

Input → output.

Clean. Fast. Predictable.

And completely uninteresting.

Because in a “cyber terminal” fantasy, encryption isn’t a jump.

It’s a process you witness.

The illusion you’re actually building

What you want is not:

“text becomes encrypted”

It’s:

“text loses meaning… before gaining a new one”

That in-between state — the flicker — is where the entire experience lives.

Without it, this is just a textarea with math.

Where most implementations fall apart

They try something like:

el.textContent = encrypt(input);

Then maybe wrap it in a timeout.

Maybe sprinkle some randomness.

But it still feels fake.

Because all characters update at once.

No tension. No progression.

The trick is not randomness

It’s controlled chaos

Each character needs its own timeline.

Not just a delay — a lifecycle.

Something like:

setTimeout(() => {
  el[i] = randomSymbol();
}, i * 30);

Now things start to stagger.

But it’s still not enough.

Because flicker isn’t just delay.

It’s instability.

The version that actually feels right

Instead of swapping once, you let each character struggle before settling.

function flickerChar(finalChar, duration = 1000) {
  const chars = "@#$%*&!";
  const start = Date.now();

  return new Promise(resolve => {
    const interval = setInterval(() => {
      const now = Date.now();

      if (now - start > duration) {
        clearInterval(interval);
        resolve(finalChar);
      } else {
        resolve(chars[Math.floor(Math.random() * chars.length)]);
      }
    }, 50);
  });
}

It’s not just animation.

It’s simulation of instability.

And now something subtle happens

The encryption function stops being the star.

The transition system becomes the real feature.

Because users don’t remember:

what the output was

They remember:

how it became the output

The UI starts behaving like a terminal

Now the aesthetic matters more than usual.

Not because it looks cool.

Because it reinforces the illusion.

The moment you switch to:

green-on-black
glowing text
scanlines

You’re no longer building a UI.

You’re building a fiction the user agrees to believe

Even something as simple as:

body {
  background: black;
  color: #00ff9f;
  text-shadow: 0 0 8px #00ff9f;
}

Does more than styling.

It sets expectations.

The glitch toggle is where things get interesting

At first, it feels like a gimmick.

Shake the text. Add some jitter.

But it reveals something deeper.

Because now the system has two states:

stable
unstable

And your UI needs to reflect that continuously

Not just during animation.

A tiny class toggle:

document.body.classList.toggle("glitch");

Ends up changing the entire mood of the app.

Copy-to-clipboard sounds trivial

It isn’t

Because this is the only moment where:

the illusion meets reality

You’re taking something from the “terminal”…

And moving it into the real world.

That’s why even a small feedback like:

navigator.clipboard.writeText(output);

paired with a toast matters disproportionately.

Without it, the system feels incomplete.

What shows up in Vibe Code Arena

This challenge creates a very specific divide.

Not in correctness.

In experience.

One model will:

implement encryption correctly
add some flicker
style it decently

It works.

But feels like effects layered on top of logic.

Another model leans into the transition itself:

staggered character timelines
independent flicker cycles
UI reacting per-character

Now the system feels alive.

Not because of complexity.

Because of temporal detail

The part that’s easy to miss

This isn’t about encryption.

It’s about progressive transformation

The same pattern shows up in:

loading states
skeleton screens
streaming UIs
code editors

Anywhere the system reveals itself over time.

The shift

After building this, you stop seeing:

“text gets encrypted”

And start seeing:

“state transitions can be felt, not just observed”

And that changes how you think about UI entirely.

If you want to push this further

Try breaking your own implementation.

What happens with long text?
Do all characters resolve cleanly?
Does glitch mode interfere with flicker timing?
Does the system feel consistent every time?

That’s where the real challenge is hiding.

And if you want to see how different approaches handle that tension between logic and illusion, this is the exact arena where it plays out:

👉 https://vibecodearena.ai/share/c8238364-3d2a-4bba-b14c-70146bbe0864

Not to “solve” it.

But to see how far you can push the transformation before it breaks.

AI Duel on Building Retro RPG Quest Journal

YASHWANTH REDDY K — Thu, 23 Apr 2026 08:33:41 +0000

There’s a version of this challenge that feels complete in minutes.

You click a quest.
It turns yellow.
Click again → green, strikethrough.
XP bar fills.
“LEVEL UP!” flashes.

It’s responsive. It’s clean. It works.

And yet… if you sit with it for a second, something starts to feel off.

Not visually.

Structurally.

The break doesn’t happen when something fails.

It happens when you ask a slightly annoying question:

“What actually controls this system?”

Because if the honest answer is “the DOM”… you’ve already lost.

Where the illusion begins

Most implementations don’t explicitly choose a bad approach.

They just drift into it.

A click handler like this:

el.classList.toggle("active");

feels harmless.

Then you stack another:

if (el.classList.contains("active")) {
  xp += 33;
}

Now your logic is reading from the UI.

And just like that, the direction flips:

UI → Logic

Instead of:

State → UI

Nothing breaks immediately.

Which is why this pattern survives longer than it should.

The moment things get weird

Try this mentally:

Click Quest 1 → Completed
Click Quest 2 → Completed
Refresh your understanding (not the page)

Now ask:

“How much XP do I have?”

If your system needs to inspect the DOM to answer that…

It doesn’t know its own state.

It’s guessing.

The version that feels different (and you can’t unsee it)

At some point, you stop touching the DOM entirely.

Not physically — but conceptually.

You start from something like this:

const game = {
  quests: [
    { id: 1, state: "locked" },
    { id: 2, state: "locked" },
    { id: 3, state: "locked" }
  ],
  clicks: 0
};

Nothing fancy.

But now there’s a single place where truth exists.

And that changes everything downstream.

Clicking a quest is no longer:

“change how this looks”

It becomes:

quest.state = nextState(quest.state);

A mutation of meaning, not appearance.

And then something subtle happens

You stop “updating” the XP bar.

You remove that code entirely.

Because XP is no longer something you store.

It becomes something you derive.

const completed = game.quests.filter(q => q.state === "completed").length;
const xp = (completed / game.quests.length) * 100;

No syncing.

No edge cases.

No “what if we forgot to update it?”

It just… exists.

This is where AI models start to split

On Vibe Code Arena, this challenge creates a really interesting pattern.

Not in who gets it working.

Everyone does.

But in how stable the system feels when you push it.

One model tends to scatter logic:

click handler updates class
another updates XP
another checks for level-up

It’s like three mini-systems loosely cooperating.

And it holds… until you stress it.

Another model centralizes everything:

state changes in one place
rendering happens in one pass
UI is always regenerated

Something like:

function render() {
  // read state
  // compute derived values
  // output UI
}

That function becomes the entire app.

Not because it’s elegant.

Because it’s predictable.

The “LEVEL UP!” moment is not about animation

It’s where your system gets audited.

Because now you need to answer:

When exactly does level-up happen?
What resets?
What persists?
What triggers the animation?

If your logic is scattered, you end up with defensive code:

if (xp === 100 && !alreadyLeveled) {
  // do something
}

If your logic is grounded in state, it’s almost boring:

if (xp === 100) {
  level++;
  resetQuests();
}

No guards. No hacks.

Just consequence.

The part that sneaks up on you

At some point, you stop thinking about:

quests
XP bars
retro UI

And start thinking in transitions.

locked → active → completed → locked

That’s not UI logic.

That’s a state machine.

And once you see it that way…

Everything simplifies.

The UI becomes… replaceable

This is the weirdest shift.

You realize the visual layer doesn’t matter anymore.

Pixel font? Doesn’t matter.
Green vs yellow? Cosmetic.
Animation timing? Secondary.

Because the real system is already stable.

The UI is just a skin.

And this is where most people miss the actual challenge

They think they’re building:

“a retro quest tracker”

They’re actually being asked:

“Can you build a system where every visual outcome is inevitable?”

That’s a very different problem.

If you want to feel the difference, not just understand it

Open the challenge.

But don’t rush to finish it.

Break it a little.

Add one more quest.
Click things out of order.
Try to reason about your own system.

That’s where the gaps show up.

👉 https://vibecodearena.ai/share/6bf96add-8e8b-45de-ab7f-43a1124e9d12

The Pomodoro Timer Isn’t About Time, It’s About Engineering

YASHWANTH REDDY K — Wed, 22 Apr 2026 11:03:39 +0000

At first glance, this looks like a design problem.

Make it circular. Make it smooth. Add some pastel colors and a calming font.

Maybe animate an SVG stroke so it “feels” like time is passing.

That’s where most implementations land.

And that’s exactly why most Pomodoro timers feel… slightly off.

Not broken. Just… untrustworthy.

Because the moment you switch tabs and come back — the illusion collapses.

This isn’t a timer UI

It’s a time reconciliation system

What you’re really building here is not a countdown.

You’re building a system that answers one question:

“What time is it supposed to be right now?”

Not:

“How many seconds have I counted?”

That difference is subtle.

And it’s where most AI-generated solutions quietly fail.

The illusion of `setInterval`

This is the default move:

setInterval(() => {
  timeLeft--;
}, 1000);

It looks correct.

It behaves correctly… as long as the tab is active.

But browsers don’t respect your timer.

They throttle it. Pause it. Delay it.

So your “1 second” becomes:

1.3 seconds
2 seconds
sometimes… nothing at all

And your UI keeps pretending everything is fine.

That’s the bug.

Not visible. Not crashing.

Just drifting.

Where it gets interesting

A human usually doesn’t try to “fix” setInterval.

They abandon the idea entirely.

Instead of counting time…

They anchor it.

let endTime = Date.now() + duration;

Now everything changes.

You’re no longer tracking ticks.

You’re calculating truth.

The timer becomes a projection

Every frame, you ask:

const remaining = endTime - Date.now();

That’s it.

No drift.

No accumulation error.

No dependency on browser behavior.

Just a recalculation.

And suddenly:

tab switching doesn’t matter
lag doesn’t matter
animation stays honest

This is the moment the system becomes real.

The orbit isn’t visual

It’s mathematical

The circular progress bar looks like a styling challenge.

It isn’t.

It’s a mapping problem:

time → circumference

That mapping is where most implementations get shaky.

Because they treat the circle like decoration.

Instead of a visual encoding of state

A small line that carries the entire illusion

const progress = remaining / duration;

That ratio drives everything:

stroke offset
animation smoothness
perception of time

If this value is wrong — even slightly — the user feels it.

Not consciously.

But enough to break immersion.

HTML (nothing fancy, and that’s the point)

<div class="app">
  <div class="orbit-container">
    <svg class="orbit" viewBox="0 0 120 120">
      <circle cx="60" cy="60" r="54" class="bg"></circle>
      <circle cx="60" cy="60" r="54" class="progress"></circle>
    </svg>
    <div class="time" id="time">25:00</div>
  </div>

  <div class="controls">
    <button id="focus">Focus</button>
    <button id="chill">Chill</button>
    <button id="start">Start</button>
    <button id="pause">Pause</button>
    <button id="reset">Reset</button>
  </div>

  <div id="message" class="message hidden">Time to breathe</div>
</div>

The structure is intentionally quiet.

Because the behavior is doing the heavy lifting.

CSS (this is where most people over-design)

body {
margin: 0;
font-family: "Inter", sans-serif;
background: #f4f1ee;
color: #2a2a2a;
display: flex;
align-items: center;
justify-content: center;
height: 100vh;
}

.app {
text-align: center;
}

.orbit-container {
position: relative;
width: 200px;
height: 200px;
margin: auto;
}

.orbit {
transform: rotate(-90deg);
}

circle {
fill: none;
stroke-width: 8;
}

.bg {
stroke: #e0dcd7;
}

.progress {
stroke: #a3c9a8;
stroke-linecap: round;
stroke-dasharray: 339.292;
stroke-dashoffset: 0;
transition: stroke 0.3s ease;
}

.time {
position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
font-size: 28px;
font-weight: 500;
}

.controls {
margin-top: 20px;
display: flex;
gap: 10px;
justify-content: center;
}

button {
padding: 10px 14px;
border: none;
border-radius: 20px;
background: #e8e3dd;
cursor: pointer;
}

.message {
margin-top: 20px;
opacity: 0;
transition: opacity 0.5s ease;
}

.message.show {
opacity: 1;
animation: pulse 2s infinite;
}

@keyframes pulse {
0% { opacity: 0.3; }
50% { opacity: 1; }
100% { opacity: 0.3; }
}

The mistake AI models often make here is excess.

Too many gradients. Too much glow.

But “zen” UI is about restraint.

The absence of noise.

JavaScript (this is where the system lives)

const FULL_DASH = 339.292;

let duration = 25 * 60 * 1000;
let endTime = null;
let timerRunning = false;

const timeEl = document.getElementById("time");
const progressEl = document.querySelector(".progress");
const messageEl = document.getElementById("message");

function format(ms) {
const total = Math.max(0, Math.floor(ms / 1000));
const m = String(Math.floor(total / 60)).padStart(2, "0");
const s = String(total % 60).padStart(2, "0");
return `${m}:${s}`;
}

function update() {
if (!timerRunning) return;

const remaining = endTime - Date.now();

if (remaining <= 0) {
timerRunning = false;
timeEl.textContent = "00:00";
progressEl.style.strokeDashoffset = FULL_DASH;
messageEl.classList.add("show");
return;
}

const progress = remaining / duration;

progressEl.style.strokeDashoffset = FULL_DASH * (1 - progress);
timeEl.textContent = format(remaining);

requestAnimationFrame(update);
}

document.getElementById("start").onclick = () => {
if (!endTime) {
endTime = Date.now() + duration;
} else {
endTime = Date.now() + (endTime - Date.now());
}
timerRunning = true;
messageEl.classList.remove("show");
update();
};

document.getElementById("pause").onclick = () => {
timerRunning = false;
duration = endTime - Date.now();
};

document.getElementById("reset").onclick = () => {
timerRunning = false;
endTime = null;
duration = 25 * 60 * 1000;
timeEl.textContent = "25:00";
progressEl.style.strokeDashoffset = 0;
messageEl.classList.remove("show");
};

document.getElementById("focus").onclick = () => {
duration = 25 * 60 * 1000;
endTime = null;
timeEl.textContent = "25:00";
};

document.getElementById("chill").onclick = () => {
duration = 5 * 60 * 1000;
endTime = null;
timeEl.textContent = "05:00";
};

AI vs AI vs Human — where the split happens

This challenge looks harmless.

But in Vibe Code Arena, it exposes something deeper.

Model 1: Animation-first thinking

Gets the orbit working
Uses setInterval
Feels smooth… initially

Until:

tab switch breaks timing
animation desyncs from reality

It optimizes for appearance, not truth.

Model 2: Over-correcting

Uses timestamps
But introduces complex state handling
Adds unnecessary abstractions

It becomes harder to reason about than the problem itself.

The human approach

Usually lands somewhere quieter:

one source of truth → endTime
everything derived from Date.now()
animation tied to reality, not ticks

Not because it’s “clean”

But because it’s trustworthy

What most people miss

This isn’t about Pomodoro.

It’s about temporal systems

Anywhere you deal with:

timers
progress
countdowns
animations tied to time

You face the same choice:

Do you simulate time… or reference it?

Simulation drifts.

Reference stays anchored.

The Reality

After building this, you stop seeing:

“a circular timer UI”

And start seeing:

“a continuously reconciled system between real time and visual state”

And once that clicks…

You start noticing how many apps quietly get this wrong.

If you want to see how different models handle this (and where they drift), try this exact challenge in AI duel mode on Vibe Code Arena.

That’s where “working code” and “reliable systems” stop being the same thing.

👉 Try it out here: https://vibecodearena.ai/share/d8d9208b-9adc-4d11-91ab-d893900f4222

Building a Real Event Bus in VibeCodeArena

YASHWANTH REDDY K — Tue, 21 Apr 2026 16:04:03 +0000

There’s a moment in every growing codebase where things start to feel… tangled.

A button click updates three different parts of the UI.
A network response triggers state changes across multiple modules.
A login event suddenly needs to notify analytics, UI, cache, and permissions.

At first, you wire things directly:

loginButton.onclick = () => {
  updateUI();
  trackAnalytics();
  refreshData();
};

It works.

Until it doesn’t.

Because now everything knows about everything.

And that’s where an event bus quietly becomes one of the most powerful abstractions in your system.

The Simple Idea That Hides a Complex System

At its core, an event bus sounds trivial:

bus.on("user.login", handler);
bus.emit("user.login", data);

You publish an event.

Subscribers react.

Loose coupling. Clean architecture. Done.

Except… that’s just the surface.

The moment you try to build one that feels production-ready, the complexity starts creeping in from every direction.

The Naive Version (and Why It Breaks)

Most implementations begin like this:

const events = {};

function on(name, handler) {
  if (!events[name]) events[name] = [];
  events[name].push(handler);
}

function emit(name, data) {
  (events[name] || []).forEach(fn => fn(data));
}

This works.

Until you need:

To remove a handler
To handle async logic
To prevent memory leaks
To debug what’s happening

And suddenly, this “simple pub-sub” becomes a system design problem.

The First Real Upgrade: Control Over Subscriptions

You quickly realize on isn’t enough.

You need off.

function off(name, handler) {
  if (!events[name]) return;
  events[name] = events[name].filter(h => h !== handler);
}

And then:

bus.once("user.login", handler);

Which means wrapping the handler:

function once(name, handler) {
  const wrapper = (data) => {
    handler(data);
    off(name, wrapper);
  };
  on(name, wrapper);
}

This is the first moment where your event bus starts managing lifecycle, not just execution.

Wildcards: When Events Become Patterns

Now imagine:

bus.on("user.*", handler);

You emit:

bus.emit("user.login");
bus.emit("user.logout");

Both should trigger the same listener.

Now your lookup is no longer direct.

You’re matching patterns.

function matches(pattern, event) {
  if (pattern.endsWith("*")) {
    return event.startsWith(pattern.slice(0, -1));
  }
  return pattern === event;
}

This is where your event system starts behaving more like a router than a map.

Namespaces: Structure Matters

Then you introduce:

auth:login
auth:logout

Now events are not just strings.

They’re hierarchies.

And suddenly, design decisions matter:

Should auth:* catch both?
Should * catch everything?
Should auth:login.success match auth:*?

You’re no longer just dispatching events.

You’re defining a language of communication inside your app.

Priority: Who Gets to Speak First?

When multiple handlers exist:

bus.on("data.update", handlerA);
bus.on("data.update", handlerB);

Order suddenly matters.

So you introduce priority:

bus.on("data.update", handlerA, { priority: 10 });
bus.on("data.update", handlerB, { priority: 1 });

And sort:

handlers.sort((a, b) => b.priority - a.priority);

This is subtle, but powerful.

Because now your system supports controlled execution flow without hard dependencies.

Async Handlers: Where Things Get Real

Now consider:

bus.on("user.login", async (data) => {
  await fetchUserProfile();
});

What happens when you emit?

await bus.emit("user.login", data);

Now your emit must:

Detect async handlers
Await them properly
Handle errors

async function emit(name, data) {
  for (const handler of handlers) {
    try {
      await handler(data);
    } catch (err) {
      console.error(err);
    }
  }
}

This is where your event bus stops being synchronous glue…

…and becomes part of your async control flow.

Middleware: The Hidden Power Layer

Now introduce middleware:

bus.use((event, data, next) => {
  console.log("Event:", event);
  next();
});

Before any handler runs, middleware intercepts.

This enables:

Logging
Validation
Transformation
Security checks

Your emit pipeline becomes:

middleware → handlers

And now your event system feels like a mini framework.

Debug Mode: Making the Invisible Visible

Without visibility, debugging events is painful.

So you add:

debug: true

And log:

[EMIT] user.login
→ handlerA (2ms)
→ handlerB (5ms)

Now you can see:

Execution order
Performance
Missing handlers

This transforms your bus from a black box into an observable system.

The Edge Case Nobody Talks About: Unsubscribing During Emit

Consider:

bus.on("test", function handler() {
  bus.off("test", handler);
});

If you mutate the handler list during iteration, you risk:

Skipping handlers
Crashing iteration

So you clone:

const handlersCopy = [...handlers];
handlersCopy.forEach(h => h());

This is the kind of detail that separates a working system from a reliable one.

Re-entrancy: Events Triggering Events

Now imagine:

bus.on("A", () => bus.emit("B"));
bus.on("B", () => bus.emit("A"));

You’ve just created an infinite loop.

Handling this requires:

Guarding against recursion
Tracking active events

This is where your event bus starts dealing with system safety, not just features.

Memory Leaks: The Silent Failure

Every on() adds a reference.

If you don’t clean up:

Detached components still receive events
Memory grows silently

A robust bus ensures:

Proper off() usage
Weak references (if possible)
Cleanup patterns

Because leaks don’t show immediately.

They show in production.

The UI: Where It All Comes Together

Once you visualize:

Active listeners
Event logs
Execution order
Performance timing

The system becomes tangible.

You can:

Emit custom events
Watch handlers fire
Measure execution time

And suddenly, this isn’t just infrastructure.

It’s something you can interact with.

Replay: Time Travel for Events

One of the most interesting features is replay:

bus.replayLast(10);

Now your system remembers history.

This enables:

Debugging
State reconstruction
Event sourcing patterns

You’ve moved from real-time system…

to time-aware system.

What You Actually Built

By the end of this challenge, you didn’t just build a pub-sub utility.

You built:

A pattern-matching event router
A prioritized execution engine
An async-safe dispatcher
A middleware pipeline
A debugging and observability layer

That’s not a helper function.

That’s infrastructure.

The Shift in Thinking

After building this, you stop wiring components directly.

You start thinking:

“What event should this emit?”
“Who should listen?”
“What’s the contract?”

You design flows, not connections.

And your system becomes:

More modular
More scalable
Easier to evolve

Final Thought

Most developers use event systems without thinking about them.

But the moment you build one yourself, you realize:

The real challenge isn’t sending messages.

It’s managing how, when, and in what order they flow through your system.

And once you understand that,

you don’t just write features anymore

you design communication architectures.

👉 Try it out here: https://vibecodearena.ai/share/1be49732-f7cb-49b3-976f-b9f56b8a0f03

Building a Dependency Resolver ft. VibeCodeArena

YASHWANTH REDDY K — Mon, 20 Apr 2026 17:40:21 +0000

There’s a moment every developer has had, even if they don’t say it out loud.

You run:

npm install

Thousands of packages get installed. A lockfile appears. Everything just… works.

And you move on.

But if you stop for a second and ask what actually just happened, things get uncomfortable fast.

How did it decide which version of a package to install?
What happens when two dependencies want different versions of the same thing?
Why do circular dependencies sometimes crash everything?

This challenge forces you to answer those questions the hard way.

By building your own mini dependency resolver.

It Starts Simple — Until It Really Doesn’t

At the beginning, it feels manageable.

You define a few packages:

addPackage("react", "18.2.0", ["scheduler@^0.23.0"]);
addPackage("scheduler", "0.23.0", []);
addPackage("lodash", "4.17.21", []);

Then you say:

resolve("react@18.2.0");

And expect something like:

react@18.2.0
└── scheduler@0.23.0

So far, so good.

But that’s not dependency resolution.

That’s just following pointers.

The First Real Problem: Versions Are Not Strings

The moment you introduce semantic versioning, everything changes.

"^1.2.3"
"~1.2.3"
"1.2.3"

These are not just versions.

They are constraints.

And your resolver has to interpret them.

Why `^` and `~` Are Trickier Than They Look

Take:

^1.2.3

This means:

>= 1.2.3 AND < 2.0.0

But:

~1.2.3

Means:

>= 1.2.3 AND < 1.3.0

So now your system needs to:

Parse version strings into structured data
Compare versions numerically
Filter all available versions
Pick the highest compatible one

Something like:

function isCompatible(version, range) {
  // parse major, minor, patch
  // apply rules for ^ or ~
}

This is the first moment where your “simple system” becomes an algorithmic problem.

The Registry Isn’t a List — It’s a Time Machine

You don’t just store one version per package.

You store many:

registry = {
  lodash: ["4.17.19", "4.17.20", "4.17.21"],
  axios: ["1.5.0", "1.6.0"]
};

So when someone asks for:

axios@^1.5.0

You don’t return "1.5.0".

You return:

"1.6.0"

Because it’s the highest compatible version.

This is where most naive implementations fail.

They match.

They don’t optimize.

Dependency Resolution Is Actually Graph Traversal

Once you move beyond one level, the structure reveals itself:

A
├── B
│   └── D
└── C
    └── D

This is not a tree.

This is a graph.

And resolving dependencies is not recursion.

It’s graph traversal with constraints.

The Hidden Complexity: Conflicting Requirements

Now consider:

A → B@^1.0.0
C → B@^2.0.0

You try to resolve:

root = [A, C]

What do you do?

There is no version of B that satisfies both.

This is not a bug.

This is a conflict.

And your resolver needs to detect it and explain it.

Something like:

Version conflict:
- A requires B@^1.0.0
- C requires B@^2.0.0

This is where your system stops being a tool…

…and starts behaving like a real package manager.

Cycle Detection: The Silent Killer

Then comes the nightmare scenario:

A → B → C → A

If you naively recurse, your program never stops.

So you introduce something like:

const visiting = new Set();

function resolve(pkg) {
  if (visiting.has(pkg)) {
    throw Error("Cycle detected");
  }
  visiting.add(pkg);
  ...
  visiting.delete(pkg);
}

But detecting a cycle is not enough.

You need to explain it:

Cycle detected:
A → B → C → A

Because debugging dependency graphs without visibility is a nightmare.

Topological Sorting: The “Install Order” Problem

Once everything is resolved, you still have one more step.

Installation order.

You can’t install a package before its dependencies.

So you compute something like:

D → B → C → A

This is a topological sort.

And it’s one of those concepts that feels academic…

until you realize it’s powering every build system you’ve ever used.

The Resolver Is Not One Function — It’s a System

At this point, your architecture starts to matter.

You naturally separate concerns:

Registry Layer → stores packages and versions
Version Engine → parses and compares semver
Resolver → builds the dependency graph
Validator → detects conflicts and cycles
UI Layer → displays results

Because trying to do this in one file?

That’s how bugs multiply.

The UI Changes How You Think About the Problem

Once you visualize the tree:

react@18.2.0
├── scheduler@0.23.0
└── something-else@1.1.0

You start noticing things you didn’t before:

Duplicate dependencies
Deep nesting
Unexpected versions

And when you add a “Visualize Tree” button, suddenly your resolver becomes explainable.

Which is what real tools struggle with.

The Lockfile: Freezing Time

One of the most underrated features is the lockfile.

After resolving:

{
  react: "18.2.0",
  scheduler: "0.23.0"
}

You save it.

Because next time, you don’t want “latest compatible”.

You want exactly this.

This is the difference between:

Reproducible builds
And chaos

Where Most Implementations Break

There’s a pattern you start noticing.

A lot of systems “work” for simple cases.

But fail when:

Multiple versions exist
Constraints overlap
Graph depth increases
Cycles appear

Because dependency resolution is not about happy paths.

It’s about edge cases interacting with each other.

The Subtle Beauty of This Problem

What makes this challenge special is that it quietly combines:

String parsing
Graph theory
Constraint solving
System design

And wraps it in something every developer uses daily.

You’re not learning an abstract algorithm.

You’re reverse-engineering reality.

The Moment Everything Clicks

There’s a point, somewhere in the middle of debugging, where things shift.

You stop thinking:

“Why is this not working?”

And start thinking:

“What is the system trying to guarantee?”

And the answer is:

Consistency
Determinism
Compatibility

That’s what real package managers optimize for.

Not just installation.

Final Thought

Building a dependency resolver doesn’t just teach you how npm works.

It teaches you something deeper.

That most “simple tools” we rely on…

are actually layers of carefully designed systems solving hard problems quietly.

And once you’ve built even a tiny version of one,

you don’t take npm install for granted anymore.

You understand the chaos it’s preventing.

👉 Try it out here: https://vibecodearena.ai/share/1261e358-7da7-4b9d-ada3-ea495b132806

The Illusion of Waves: When “Looks Right” Isn’t “Built Right” ft. VibeCodeArena

YASHWANTH REDDY K — Sun, 05 Apr 2026 12:36:39 +0000

There’s something fascinating about challenges that feel visual but are actually deeply mathematical underneath. The “Ripple Wave Visualizer” prompt sits exactly in that category. At first glance, it sounds like a UI problem—draw some circles, animate them, make it pretty. But the moment you start thinking about what a ripple actually is, you realize you’re not building a UI anymore. You’re attempting to simulate a physical phenomenon.

And that’s where things got interesting.

Two models took on this challenge. Both produced working outputs. Both rendered ripples on a canvas. Both had controls, interactions, and animation loops. But under the surface, they reveal two very different interpretations of the same problem—and more importantly, two different limitations of AI-generated code.

Let’s unpack this properly.

What Was Asked vs What Was Built

The prompt wasn’t vague. It explicitly asked for:

Ripples behaving like real waves

Overlapping waves with interference

Organic motion using sine or ripple physics

A calming, almost meditative visual experience

That’s not just animation. That’s simulation.

Now look at what both models actually built.

Both implementations reduce the concept of a ripple to this:

this.radius += this.speed;
this.alpha -= fadeRate;

And then render it using:

ctx.arc(this.x, this.y, this.radius, 0, Math.PI * 2);

That’s it.

No wave equation. No displacement field. No interference. No energy transfer.

Just expanding circles.

Model 1 (GPT-4o): Clean Execution, Shallow Physics

The first model does a respectable job if you judge it purely as a frontend exercise. The structure is clean, the controls are wired correctly, and the animation loop is stable.

ripples = ripples.filter(ripple => ripple.update());
requestAnimationFrame(animate);

There’s discipline here. The lifecycle is well-managed. The UI responds properly. Even small touches like converting hex color into RGB arrays show attention to detail.

But then you notice something subtle that changes everything.

this.intensity = intensity;

It’s defined… and never used.

That one line tells you a lot. The model understood that “intensity” should exist, but didn’t actually connect it to any meaningful behavior—no amplitude scaling, no wave thickness, no energy propagation.

It’s a placeholder for an idea it didn’t fully implement.

The same pattern appears elsewhere. The ripples overlap visually, but they don’t interact. There’s no shared medium, no combined displacement. Each ripple lives in isolation, unaware of others.

And then there’s the rendering:

ctx.clearRect(0, 0, canvas.width, canvas.height);

Every frame wipes the canvas clean. No persistence, no blending, no glow accumulation. The result is visually neat, but sterile. It lacks the richness you expect from something described as “mesmerizing.”

Even the auto-rain system hints at architectural shortcuts:

setTimeout(autoRainEffect, 500);

It works, but it’s detached from the main animation loop. There’s no centralized timing system, which means behavior can drift or stack unpredictably.

So what did Model 1 really build?

A well-structured animation demo that looks like ripples—but doesn’t behave like them.

Model 2 (GPT-4o-mini): Simpler, But Also More Fragile

If Model 1 feels like a clean frontend project, Model 2 feels like a quick prototype pushed out the door.

At a glance, it’s similar. Same expanding circles. Same fade-out logic. Same basic idea.

this.radius += this.speed;
this.alpha -= 0.01;

But the cracks show much earlier.

The rendering approach switches from stroke-based circles to filled ones:

ctx.fillStyle = `rgba(...)`;
ctx.fill();

This creates a very different visual effect—more like blobs than waves. Instead of elegant expanding rings, you get solid discs fading into each other. It’s heavier, less refined, and loses that “water surface” illusion entirely.

Then there’s state management. Instead of filtering the array cleanly, it mutates it during iteration:

if (ripple.alpha <= 0) ripples.splice(index, 1);

This is a classic source of bugs. Removing elements while iterating can skip items or cause inconsistent behavior, especially as the system scales.

The “Auto Rain” feature is where things get particularly telling:

if (autoRainToggle.checked) {
    setInterval(() => { ... }, 1000);
}

This runs once at load. Toggling the checkbox later doesn’t actually control anything. The feature exists in UI, but not in behavior.

Again, we see the same pattern: the idea is present, the implementation is partial.

Even basic constraints like limiting ripple count:

if (ripples.length < maxRipples)

feel more like safeguards against performance issues than part of a thoughtful system design.

And just like Model 1, there is zero attempt at real wave physics. No interference. No medium. No propagation logic beyond “increase radius.”

The Bigger Problem: Both Models Miss the Core Concept

Here’s the uncomfortable truth.

Neither model actually solved the problem.

They both solved a simplified version of it.

What was required:

A system where waves propagate through a medium, interact with each other, and create emergent patterns.

What was built:

Independent objects that draw circles and fade out.

That’s not a small gap. That’s the difference between simulation and animation.

A real ripple system would look more like this:

height[x][y] = wave1[x][y] + wave2[x][y];

You’d have a grid. Each point would store displacement. Waves would travel through that grid, interfere constructively and destructively, and decay over time.

None of that exists here.

And that’s the key insight.

Why This Happens

AI models are incredibly good at pattern matching. They’ve seen ripple effects implemented as expanding circles thousands of times across tutorials, demos, and code snippets.

So when asked to build a ripple system, they default to the most common visual approximation.

It looks right.

It behaves wrong.

And unless you’re specifically looking for physical accuracy, you might not even notice.

So… Which Model Is Better?

If you’re choosing purely on engineering quality, Model 1 is the clear winner.

It has:

Cleaner state management

Better structured animation loop

More consistent UI integration

Fewer logical bugs

Model 2, while functional, feels more fragile and less polished.

But here’s the twist.

Neither model actually delivers what the prompt truly asks for.

So the real takeaway isn’t just “Model 1 wins.”

It’s this:

Both models demonstrate how easy it is to mistake visual correctness for technical correctness.

The Real Lesson

This challenge isn’t about canvas, sliders, or animations.

It’s about understanding what you’re building.

If you think in terms of shapes, you’ll draw circles.
If you think in terms of systems, you’ll simulate waves.

That’s the difference.

And it’s exactly the kind of gap that platforms like Vibe Code Arena expose really well. You don’t just see outputs—you see how different models think about problems.

Sometimes they’re right. Sometimes they’re convincing. And sometimes, like in this case, they’re just approximating something much deeper.

If you want to explore this challenge yourself and see how your thinking compares, try it here:

👉 https://vibecodearena.ai/share/b2ae08e5-d6a7-43ef-9949-64e2eb031a19

Because once you notice the difference between an animation and a system, you can’t unsee it. ;)

Hard Lessons from the Vibe Code Arena

YASHWANTH REDDY K — Tue, 31 Mar 2026 17:18:38 +0000

At some point, the challenges stop being about the problem statement.

You start noticing something else entirely.

It’s not what gets built—it’s how differently the same thing gets built.

That’s where Vibe Code Arena gets interesting. Not because you’re solving problems, but because you’re watching multiple models—and sometimes humans—solve the same problem with completely different mental models.

And if you pay attention, you start to see patterns. Not just in correctness, but in architecture, trade-offs, and even subtle bugs that don’t show up until you look closely.

When Three “Correct” Solutions Are Not the Same

One of the most misleading things about multi-model duels is the evaluation scores.

You’ll often see this:

100%
100%
100%

And you assume—they’re all equally good.

They’re not.

Take something like the breathing app challenge. On the surface, every solution animated a circle, showed text like “Inhale…” and “Exhale…”, and had buttons.

Functionally, all of them passed.

But under the hood, the differences were massive.

One solution leaned entirely on CSS animations:

@keyframes breathe {
  0% { transform: scale(1); }
  50% { transform: scale(1.2); }
  100% { transform: scale(1); }
}

It looks clean. It works. It even feels smooth.

But the moment you try to control it—pause, sync instructions, change durations dynamically—it starts to resist you.

Another solution went fully programmatic:

circle.style.transition = `transform ${duration}s ease`;
circle.style.transform = `scale(${target})`;

Now you’re not just animating—you’re controlling state over time.

Same output. Completely different capabilities.

Multi-Model Duels Expose “Thinking Styles”

What stands out after a few challenges is that models don’t just differ in quality—they differ in how they think about problems.

Some models tend to flatten everything into a linear flow:

function inhale() {
  setTimeout(() => hold(), 4000);
}

It’s almost like writing a script: do this, then this, then this.

It works—until you need to interrupt it.

Other implementations start introducing structure, even if unintentionally:

let phase = 'inhale';

function next() {
  if (phase === 'inhale') {
    phase = 'hold';
  }
}

This is where things start resembling systems instead of scripts.

And once you notice it, you can’t unsee it.

The Real Difference Shows Up in Edge Cases

The easiest way to evaluate code isn’t by reading it.

It’s by breaking it.

Try hitting “Start” multiple times.
Try switching difficulty mid-game.
Try resetting while an animation is running.

That’s where things get interesting.

In one Rock-Paper-Scissors implementation, the “hard mode” logic looked convincing:

if (difficulty === 'hard') {
  const last = localStorage.getItem('lastMove');
  // counter logic
}

But the system never actually tracked frequency—only the last move. So it felt intelligent, but wasn’t.

Another version actually tracked history:

moveHistory.push(playerChoice);

if (moveHistory.length > 5) {
  moveHistory.shift();
}

Then computed the most frequent move and countered it.

Now you’re not just reacting—you’re modeling behavior over time.

Same feature. Completely different depth.

UI vs System: Where Most Implementations Drift

A pattern that keeps showing up across challenges is this:

AI is excellent at building interfaces.
But systems? That’s where things start to wobble.

You’ll see beautifully structured DOM manipulation:

counterEl.textContent = value;
document.body.style.backgroundColor = 'green';

Everything updates correctly. It’s responsive. It looks right.

But then you look at the logic layer—and it’s often tightly coupled to UI updates.

There’s no separation between:

state
logic
rendering

And that becomes a problem the moment complexity increases.

In contrast, stronger implementations start separating concerns—even in small ways:

function determineWinner(player, computer) {
  // pure logic
}

function updateUI(result) {
  // rendering
}

It’s subtle. But it’s the difference between something that scales and something that breaks.

Security and “Silent Failures” in Simple Apps

One thing that doesn’t get talked about enough in these challenges is how fragile even “simple” apps can be.

Take the password generator.

At first glance, it looks solid. Random characters, strength meter, copy button.

But then you look closer.

password += charset[randomIndex];

This uses Math.random(), which is not cryptographically secure.

For a UI demo? Fine.

For a real product? This is a vulnerability.

A more secure approach would be:

const array = new Uint32Array(length);
crypto.getRandomValues(array);

That’s the kind of detail most implementations skip.

And it matters.

The Illusion of Smart Features

Another pattern: features that look advanced but are actually shallow.

Difficulty modes. Strength meters. Animations.

They’re often implemented just enough to pass the requirement.

For example, a strength meter might do this:

if (length > 12) strength += 2;
if (hasUppercase) strength += 1;

But it ignores entropy, repetition, predictable patterns.

So you end up with a “Very Strong” password that’s actually weak.

This isn’t a bug—it’s a limitation of how the problem was interpreted.

And that’s what makes these duels interesting.

You’re not just evaluating correctness. You’re evaluating depth of understanding.

What You Start Noticing After Enough Challenges

After going through multiple duels on Vibe Code Arena, a few things become very clear:

You stop trusting surface-level correctness.
You start looking for control flow.
You care more about what happens over time than what happens instantly.

You begin to notice things like:

Are timers centralized or scattered?
Is state explicit or implied?
Can this be paused, reset, or extended safely?

These aren’t things you notice on day one.

But once you do, every piece of code starts telling you more than it used to.

The Platform Isn’t Just About Challenges

What makes Vibe Code Arena different is that it doesn’t just show you outputs—it puts them side by side.

And that changes how you think.

Because now you’re not asking:

“Is this correct?”

You’re asking:

“Why did this model choose this approach?”

And sometimes the answer is more valuable than the solution itself.

A Small Snippet That Says a Lot

Here’s something that looks trivial:

setTimeout(() => {
  nextPhase();
}, duration);

This one line tells you everything about an implementation.

Is there a global controller?
Is this being tracked?
Can it be cancelled?

Or is it just… running?

That’s the level these challenges operate at once you start paying attention.

Where This Actually Leads

At the end of all this, you don’t just get better at writing code.

You get better at reading intent.

You start seeing:

shortcuts
assumptions
hidden complexity

And more importantly, you start understanding that:

Good code isn’t just about solving the problem.

It’s about how resilient that solution is when the problem changes.

Try Looking at Code This Way

If you’ve been building or testing on Vibe Code Arena, try this next time:

Don’t just run the solution.

Interrogate it.

Break it.
Pause it.
Spam the buttons.
Change states mid-flow.

That’s where the real differences show up.

And if you want to see exactly what this kind of analysis feels like in practice, try one of the latest challenges here:

👉 https://vibecodearena.ai/share/6ddc5143-faa8-4df7-ad8e-8c3c98a71357

You might start by comparing outputs.

But if you look closely enough, you’ll end up understanding systems;)

Why This “Simple” Breathing App Quietly Breaks Most Code

YASHWANTH REDDY K — Sat, 28 Mar 2026 11:47:11 +0000

There’s something deceptive about challenges like this one.

At a glance, it feels almost trivial. A circle expands, contracts, and some text changes in sync—Inhale… Hold… Exhale…. Add a couple of buttons, maybe a toggle for difficulty or presets, and you’re done. It’s the kind of problem that gives you confidence before you even open your editor.

But the moment you actually dig into implementations—especially when you compare an AI-generated solution with a human-built one—you start to notice something uncomfortable.

This isn’t really about animation at all.

It’s about control over time, state, and behavior in an environment that doesn’t naturally guarantee any of those things.

The entire experience is built on a fragile foundation: timing.

Every phase in the breathing cycle carries an expectation. When the UI says “Inhale,” the circle must expand at exactly the same pace. When it says “Hold,” nothing should move—not even subtly. And when “Exhale” begins, the transition needs to feel intentional, not delayed or rushed.

The problem is that the browser doesn’t care about your intentions.

JavaScript timers are not perfectly precise. Tabs lose focus. Event loops get blocked. Animations continue running even when logic changes. So the real challenge here is not creating motion—it’s ensuring that motion, text, and logic remain synchronized over time.

That’s where things start to diverge between the AI-generated approach and the human-built one.

The AI solution leans heavily on CSS to handle the breathing animation. It defines a looping keyframe animation that scales the circle up and down, giving the illusion of inhale and exhale. On the surface, this feels clean and efficient. You describe the animation once, let it run infinitely, and your job seems done.

But there’s a subtle flaw baked into that decision.

CSS animations are autonomous. They don’t understand your application’s state. They don’t know whether the user has paused the session, changed a preset, or reset the cycle. They simply run.

So while the animation continues smoothly, JavaScript tries to keep up by updating text and triggering phases using setTimeout. These two systems—CSS and JavaScript—are now running in parallel, not in coordination.

At first, everything appears fine. The timing seems close enough. But over multiple cycles, or under user interaction, small inconsistencies begin to show. The text might lag behind the animation. A pause might stop the UI visually but not logically. A reset might restart the text while the animation continues mid-cycle.

None of these issues crash the app. That’s what makes them dangerous.

They create an experience that feels slightly off, even if you can’t immediately explain why.

Then there’s the way time is handled in the AI-generated logic.

Each phase schedules the next using setTimeout. Inhale schedules hold, hold schedules exhale, and so on. It’s a chain of callbacks, each depending on the previous one to maintain flow.

This works as long as nothing interrupts the chain.

But real users interrupt everything.

Click “Start” twice. Toggle pause rapidly. Switch presets mid-cycle. Now you have multiple timers running simultaneously, each unaware of the others. Some are still counting down from a previous state. Others are executing based on outdated assumptions.

And because there’s no centralized control over these timers, they can’t be reliably canceled. They just keep firing.

This is where the system begins to drift internally.

You might see the UI reset, but somewhere in the background, an old timer is about to trigger an exhale phase that no longer makes sense. That’s when things start to feel inconsistent, even though nothing has technically “broken.”

The human implementation approaches this differently, and the difference is less about syntax and more about mindset.

Instead of letting animation drive the experience, animation becomes a response to state.

The system keeps track of what phase it is currently in—inhale, hold, exhale, or hold again—and transitions between them in a controlled manner. Each transition is deliberate. Each duration is respected. And most importantly, there is a single source of truth governing the entire flow.

CSS is still used, but not as the engine. It handles transitions—how the circle moves from one size to another, how colors shift—but it doesn’t decide when those transitions happen.

That responsibility stays in JavaScript.

This separation changes everything.

Now, when the user pauses, the system doesn’t just stop visually—it stops logically. The timer controlling the current phase is cleared. No hidden callbacks remain. When the user resumes, the system continues from a known state, not from wherever the animation happened to be.

When presets are introduced—short, medium, long—the durations adjust dynamically because the system is built to handle variable timing. The animation doesn’t need to be rewritten; it simply responds to new inputs.

And because everything is coordinated through a central flow, the text, animation, and internal state remain aligned.

That alignment is what makes the experience feel “right,” even if the user doesn’t consciously notice it.

There’s also a layer of technical risk here that often goes unnoticed, especially in frontend projects like this.

When timers are not properly managed, they accumulate. Each setTimeout that isn’t cleared becomes a potential future action waiting to execute. Over time, especially in an app that runs continuously, this can lead to multiple overlapping execution paths.

It’s not just a performance issue—it’s a behavioral one.

You start seeing race conditions where two parts of the system try to update the UI at the same time. One thinks it’s in the inhale phase, another thinks it’s time to exhale. The result is inconsistency, not failure.

Similarly, relying on independent systems—like CSS animations and JavaScript timers—to stay in sync introduces a form of desynchronization that’s hard to debug. Each system works correctly on its own, but together they drift.

And then there’s user interaction.

Most implementations assume users will behave predictably. They’ll click start once, let the cycle run, maybe pause occasionally. But real users don’t follow scripts. They click quickly, change their minds, experiment with controls.

Without proper guarding—checks that ensure the system is in a valid state before executing logic—these interactions can push the app into undefined territory.

It doesn’t take much. A few rapid clicks can create overlapping timers. A reset during a transition can leave the system half-updated. These are the kinds of edge cases that separate a working demo from a reliable application.

What makes this challenge interesting is how quietly it exposes these issues.

Nothing about it screams “complex.” There are no APIs, no databases, no heavy frameworks. Just HTML, CSS, and JavaScript.

But that simplicity removes all abstraction. There’s nothing to hide behind. If your timing is off, you feel it. If your state management is weak, it shows. If your system isn’t resilient to interaction, it breaks in subtle ways.

And that’s where the real lesson sits.

The difference between the AI-generated solution and the human-built one isn’t just about correctness. Both can produce something that appears to work.

The difference is in how they handle uncertainty.

The AI solution constructs behavior step by step, focusing on making each part function. The human solution designs a system that can maintain integrity even when things don’t go as planned.

One gives you an animation.

The other gives you something closer to a product.

If you take this challenge at face value, you’ll probably finish it quickly. You’ll see the circle move, the text update, and you’ll consider it done.

But if you push a little further—if you test it under interaction, if you think about how it behaves over time, if you try to extend it—you’ll start to see where the real difficulty lies.

And once you notice that, it becomes hard to unsee.

This was never just about building a breathing app.

It was about understanding how to coordinate time, state, and user behavior in a system that doesn’t naturally keep them aligned.

If you want to experience that difference yourself, try the challenge here:

👉 https://vibecodearena.ai/share/0b9a3f33-b2b5-40ab-9df0-cabf370bfca3

You’ll get something working fairly quickly.

The real question is whether it keeps working… when you stop treating it like a demo and start treating it like something real.

When 100% Doesn’t Mean Equal: The Hidden Gap in AI Code Evaluation ft. Vibe Code Arena

YASHWANTH REDDY K — Wed, 25 Mar 2026 18:27:05 +0000

There’s something deeply misleading about a perfect score.

You look at the evaluation panel—Security: 100, Code Quality: 100, Correctness: 100, Performance: 100, Accessibility: 100—and the instinctive conclusion is simple:

“Both models did equally well.”

But when I ran a simple UI challenge inside vibe code arena, that assumption fell apart almost instantly.

Because despite identical scores across every measurable metric, the outputs didn’t feel the same.

Not even close.

The Challenge Was Intentionally Simple

The task itself wasn’t complex:

Build a “Vibe Counter”
Increment and decrement a number
Change background color based on value
Add a reset button
Keep it clean, smooth, and polished

This wasn’t meant to break models.

It was meant to reveal them.

The Scoreboard Said “Tie”

Both models—gpt-oss-20b and Llama-3.2-3b-Instruct—scored:

100 in Security
100 in Code Quality
100 in Correctness
100 in Performance
100 in Accessibility

From a benchmarking perspective, this is a dead heat.

No vulnerabilities. No logical errors. No performance issues.

If you were evaluating this programmatically, there’s no reason to prefer one over the other.

But the UI Told a Different Story

The moment you actually interact with the outputs, the illusion breaks.

One implementation feels:

Smooth
Responsive
Intentionally designed

The other feels:

Functional
Static
Mechanically complete

Both are “correct.”

Only one feels alive.

This Is the Problem with Metric-Only Evaluation

Traditional evaluation systems are built around things that are easy to measure:

Does the code run?
Does it produce the right output?
Does it avoid errors?

These are necessary.

But they are not sufficient.

Because they completely ignore a critical dimension of software:

Experience

And experience is where the real differences emerge.

The Missing Metric: Interpretation

What actually separated the two models wasn’t skill.

It was interpretation.

The prompt included this line:

“Make it look clean and nice with some smooth animation”

Now here’s the interesting part:

Both models technically satisfied this.

But only one model interpreted it deeply.

One Model Thought:

“Add styling and make sure it works.”

The Other Thought:

“Add transitions, micro-interactions, and visual feedback.”

That difference is not about correctness.

It’s about how far the model goes beyond literal instructions.

The Illusion of Completeness

When a model scores 100 across all categories, it creates a sense of finality.

Like there’s nothing left to evaluate.

But in reality, those metrics are only capturing:

Structural correctness
Surface-level quality
Observable behavior

They are not capturing:

Design decisions
User experience
Subtle interaction quality
Thoughtfulness in implementation

So you end up with something dangerous:

Two solutions that look identical on paper but diverge in practice.

Why UI Challenges Break the Illusion

This is exactly why simple frontend challenges are so powerful.

In backend or algorithmic problems:

There’s usually a “correct” answer
Evaluation is deterministic
Differences are easier to quantify

But in UI problems:

There is no single correct answer
Quality is subjective
Interpretation matters more than execution

That’s where models start to reveal their thinking patterns.

The Engineering vs Product Thinking Divide

What we’re really seeing here is a split between two modes of reasoning:

1. Engineering Thinking

Focus on correctness
Minimize complexity
Do exactly what’s required

2. Product Thinking

Focus on user experience
Add small enhancements
Optimize for feel, not just function

Both models demonstrated strong engineering thinking.

Only one leaned into product thinking.

And current evaluation systems don’t reward that difference.

Why This Matters (More Than It Seems)

It’s easy to dismiss this as “just UI polish.”

But in real-world software, this is exactly what defines quality.

Users don’t care if your code scored 100 in:

Security
Performance
Accessibility

They care about:

Does it feel responsive?
Does it feel smooth?
Does it feel intentional?

And those are things metrics don’t measure.

The Real Limitation Isn’t the Model—It’s the Benchmark

The takeaway here isn’t that one model is flawed.

It’s that our evaluation systems are incomplete.

They assume:

If everything measurable is perfect, the solution is perfect.

But this experiment shows:

You can have perfect metrics… and still have a better solution.

What Should We Be Measuring Instead?

This opens up an interesting question:

How do we evaluate things like:

Smoothness of interaction
UI responsiveness
Design intuition
Code maintainability beyond structure

These are harder to quantify.

But they’re not optional.

They’re what separate:

code that works
from code that feels right

Why You Should Start Designing Challenges Like This

If you’re creating challenges on vibe code arena, this is the direction to lean into.

Instead of focusing only on:

complex algorithms
tricky edge cases

Start exploring:

ambiguous prompts
UI/UX-driven tasks
interpretation-heavy requirements

Because that’s where:

models diverge
insights emerge
real evaluation begins

Try It Yourself (And Look Beyond the Score)

If you want to see this gap firsthand:

👉 https://vibecodearena.ai/share/75e5ac58-2e37-48d7-a140-48e0f9a93678

Don’t just look at the metrics.

Interact with the output.

That’s where the real answer is.

DEV Community: YASHWANTH REDDY K

I Built a Spatial Audio Radar ft. Vibe Code Arena

The illusion breaks immediately

This isn’t about sound playback

The mistake most implementations make

The correct mental model

The sound engine becomes directional

The visual pulse is not decoration

The center ripple reveals something subtle

The drone toggle is not just a feature

Timing becomes perception

The radar is secretly a coordinate system

Where most implementations go wrong

What shows up in Vibe Code Arena

The human version usually does one thing right

The part you don’t expect

The shift

If you want to explore this properly

I Built a Generative Poster Tool ft. Vibe Code Arena

The first version always lies to you

The realization hits fast

The grid is the invisible system

This is where things get interesting

Shapes are not equal

Size is where chaos sneaks back in

The color palette is doing more than styling

Overlap is not a bug

The poster is not just a container

Hover interactions reveal something deeper

The “Generate” button is misleading

What shows up in Vibe Code Arena

The human version usually leans into restraint

The strange shift that happens

The part you don’t expect

The shift

If you want to explore this properly

I built Geometric Breathing & Meditation app on VCA

The illusion of “just use CSS animation”

This is where most implementations drift

The shift: stop syncing to animation

The geometry isn’t decorative

The “bloom” effect is not about size

CSS variables quietly become your control panel

Presets stop being themes

The sound exposes your timing bugs instantly

The breath counter is deceptively strict

What shows up in Vibe Code Arena

The human version usually does less

The part you don’t expect

Try this before you move on

I built a Cyber-Cipher Text Decoder on Vibe Code Arena

The part everyone rushes past

The illusion you’re actually building

Where most implementations fall apart

The trick is not randomness

The version that actually feels right

And now something subtle happens

The UI starts behaving like a terminal

The glitch toggle is where things get interesting

Copy-to-clipboard sounds trivial

What shows up in Vibe Code Arena

The part that’s easy to miss

The shift

If you want to push this further

AI Duel on Building Retro RPG Quest Journal

Where the illusion begins

The moment things get weird

The version that feels different (and you can’t unsee it)

And then something subtle happens

This is where AI models start to split

The “LEVEL UP!” moment is not about animation

The part that sneaks up on you

The UI becomes… replaceable

And this is where most people miss the actual challenge

If you want to feel the difference, not just understand it

The Pomodoro Timer Isn’t About Time, It’s About Engineering

This isn’t a timer UI

The illusion of setInterval

Where it gets interesting

The timer becomes a projection

The illusion of `setInterval`

Why `^` and `~` Are Trickier Than They Look