Login

u/Fit-Opening8216

r/FlutterDev r/vibecoding r/AIDiscussion r/AIToolCompare r/AppsWebappsFullstack
▲ 3 r/AIDiscussion+3 crossposts

I’ve developed a method for ranking AI users instead of models—two developers face off on a new problem, the code is run (no LLM referee), and the one who makes the fewest moves, acts the fastest, or writes the best prompts wins

Benchmarks rank the model. But on a real team, the variable that actually moves output is the person steering it — and nobody measures that. "I'm good with AI" is an unprovable line on a CV. I wanted a scoreboard for the wielder.

So I built a prototype. The design:

  • Two devs, one fresh problem, live. Each drives their own model over MCP — works with anything: local Llama/Qwen/DeepSeek/GLM/Kimi or hosted Claude/GPT.
  • The solution is executed against tests — no LLM-as-judge (judges get gamed). Pass/fail is mechanical.
  • Winner = fewest human-authorized moves, recorded on a hash-chained, tamper-evident log.
  • Per-model leaderboards. A Glicko rating per model so it's skill-vs-skill, not compute-vs-compute. Cross-model duels settle the rest.
  • No money, no stakes. The rank is the only reward — a public, verifiable record.

First real 2-player duel ran this week: both attacked "find the N+1 query," the verifier rejected the first answer (missed the batch-load) and accepted the rigorous one. Felt right.

reddit.com
u/Fit-Opening8216 — 6 days ago
▲ 11 r/FlutterDev

Update: my TikTok-style video pool plugin now runs on 6 platforms + lets you swap media_kit for fvp — you asked, it shipped

A while back I posted video_pool here — a Flutter plugin that runs a TikTok/Reels-style feed on a fixed pool of players (3 players handle infinite scroll via swapSource(), no dispose/realloc, no jank). The thread got two pieces of feedback that stuck with me:

  1. "Web and desktop support would be great, even if it doesn't do anything special there."
  2. "It'd be great to use the standard video_player interface, so I could switch the backend to fvp instead of media_kit."

Both are now shipped. Quick rundown, including the parts that went sideways — because that's the useful bit.

1. Web + desktop (now 6 platforms: Android, iOS, web, macOS, Windows, Linux) The core pooling/reconciliation is pure Dart, so the real work was the native edges. I went in assuming "importing dart:io breaks a web build" — and that turned out to be wrong. What actually broke flutter build web was a media_kit method that doesn't exist on web (NativePlayer.setProperty, used for HLS tuning). A plain import 'dart:io' compiles fine on web; only the runtime io calls throw. The fix was conditional compilation (dart.library.io): real impl on native, no-op stubs on web for the disk cache, thumbnail extractor, and the device monitor (thermal/memory throttling stays Android/iOS-only and degrades to no-ops elsewhere). Verified by actually building and running in Chrome and on macOS — the pool reconciles and plays real video, not just green unit tests.

2. VideoPlayerAdapter — swap the backend (fvp / ExoPlayer / AVPlayer) The pool already talked to players through a PlayerAdapter interface; media_kit was just the only implementation. There's now a VideoPlayerAdapter built on the official video_player package, so you can drop in any compatible backend:

adapterFactory: (_) => VideoPlayerAdapter(), // instead of MediaKitAdapter()

For fvp (libmpv) it's literally one extra line — fvp.registerWith() at startup and you're done.

The honest catch: video_player's controller has no in-place source swap, so VideoPlayerAdapter.swapSource() disposes the controller and creates a fresh one (decoder recreated, not reused). The video surface element stays mounted, but you lose the zero-realloc property that makes media_kit the lower-latency default. So it's a real choice, not a free win — pick video_player when you need a specific backend, keep media_kit for raw scroll performance.

3. A small reality check While verifying playback on web I discovered Google's classic gtv-videos-bucket sample URLs — the ones in roughly every Flutter video demo — now return HTTP 403. The example loaded nothing until I swapped them out. Funny how "it works on my machine" survives right up until you actually run it.

Known limitation: the package isn't WebAssembly-compatible — video_player imports dart:io unconditionally upstream, so anything depending on it is non-WASM. media_kit handles this correctly with conditional imports; video_player doesn't yet. Not much I can do until that's fixed upstream (without splitting the adapter into a separate package).

Now at 269 tests, MIT, 0.5.2.
pub.dev: https://pub.dev/packages/video_pool
GitHub: https://github.com/abdullahtas0/video-pool

Still genuinely after feedback — especially: does the VideoPlayerAdapter dispose-and-recreate trade-off matter for your use case, or is decoder reuse the whole reason you'd reach for this? And for anyone running feeds on web/desktop in production — what breaks first?

u/Fit-Opening8216 — 13 days ago