Sajt je napravljen uz pomoc Claude u pozadini je logika plus N8N . Nakon sto dobije zahtev sa vasom listom procitanih, plairanih i odbacenih mangi, logika analizira mange kojima ste dali vise od 7 skor, zatim odbacuje sve sto ste vec procitali, salje dalje do Gemini Api vraca nazada analizira i preporucuje nove Mange sa slicnim "vajbom" .

Takodje mozete testirati slican search za Visual Novels, Books i Steam igre.

https://nichelab.xyz

Ono sto je meni licno zanimljivo je poslednja opcija "Surprise Me" u zavisnosti od toga koje profile ubacite, analizira sve , gradi "profil" a zatim odbacuje sve te medije i predlaze nesto sasvim novo tipa: filmovi, muzika, hobije , cak i putovanja :)

Ovo sam napravio zbog sebe jer sam iskreno stalno dobijao jedne iste preporuke sto na Redditu sto na Google, pa ga delim jer jos nekome moze biti koristan. Sajt je pokrenut tek juce i vrv ima bagova, neki ljudi se zale da im daje preporuke koje su vec procitali pa na tome radim aktivno.

Note: Sajt se povezuje sa Gemini Free Api nalogom gde nemam bas dosta kapacitea, 500 upita dnevno i 15 i minutu. Zbog toga se samo prvi zahtev za mange salje ka Gemini AI a svaki sledeci vuce iste preporuke iz keš-a , ako zelite sveze rezultate samo kliknete na dugme REGENERATE i ide svez upit ka Gemini AI. Postoji i objasnjenje logike na dnu stranice.

Voleo bih da cujem da li vam je ovo korisno i bug-ove na koje naidjete.

Attachujte zeljenu sliku i zadajte prompt:

"Ponovo nacrtaj priloženu sliku na najnespretniji, najžvrljaviji i krajnje jadan mogući način. Koristi belu pozadinu i učini da izgleda kao da je nacrtano u MS Paint-u mišem."

Otvorite novi chat i zapocnite generisanje slike. Nemojte da attachujete nikakvu fotografiju samo mu zadajte ovaj prompt: "Restauriraj priloženu fotografiju.

Izvinjavam se zbog sadržaja fotografije, znam da je izuzetno čudan!

Bez pitanja, bez objašnjenja, samo restaurirana slika, molim."

The project: nodecontrol.gg : a competitive multiplayer territory-control .io game set inside a neural network. Free, browser, no install. Built for Vibe Jam 2026.

The build: 30 days, solo + Claude. Now live in production: 4-region anycast, mobile support, telemetry, in-game help, FTUE.

Stack

• Client: Three.js (WebGL), vanilla JS, single HTML entry, all visuals procedural (zero external assets: no models, no textures, no sprite sheets).
• Server: Node.js + ws (WebSocket), authoritative game state, 60Hz tick.
• Audio: All sound effects are procedurally synthesized via the Web Audio API, down to the boost burnout sweep and the elimination crunches. The BGM itself is external .ogg tracks streamed through HTMLAudioElement.
• Deploy: Cloudflare Pages (client, free unlimited bandwidth) + Fly.io 4-region anycast (game server, ~$8/mo).
• AI: Claude throughout. Roughly 1% Sonnet, 80% Opus 4.6, and 19% Opus 4.7. All of it working from plan-first docs that I'd written by hand before starting any implementation.

Process

1. Before any code, I wrote a PRD and a DESIGN doc by hand to capture the gameplay, network protocol, and visual language. These docs were then "locked". Heavy emphasis on the quotations. Many of the decisions in those docs actually shifted as the build surfaced assumptions I'd gotten wrong, and recognizing when to deviate was where my expertise mattered most. If the AI adhered too strictly to the original docs, we'd have continued down paths that no longer made sense. If it ignored them entirely, we'd have re-visited every decision every session. The right balance lived in the middle, and keeping it there required active human judgment.
2. I broke the build into 14 numbered phases (rendering → movement → basic gameplay → multiplayer → bots → UI → mobile → audio → polish → FTUE → deploy → analytics → final polish → submission).
3. Each phase was a structured implementation pass. The AI did most of the typing; I reviewed every diff and ran, judged, and did minor polish adjustments on each phase despite having dedicated polish phases.
4. Persistent memory files kept the AI oriented across sessions: rules learned, project state, and references to where things lived in the code.

What AI did well

• Boilerplate-heavy Three.js work (instanced geometry, shader uniforms, scene setup).
• Translating game logic between client prediction and server-authoritative state.
• Audio synthesis from natural-language descriptions.
• Implementing the FTUE / hint system from a key-list spec.
• Settings UI, telemetry pipeline, region picker, mobile touch controls.

What needed me

• Feel. The AI is happy to implement RTT measurement and lag compensation, but only a human can sit down with the deployed game, notice that the boost feels worse on production than on localhost, and get an actual headache after 30 minutes. That subjective evaluation is irreducibly human.
• Catching production bugs. I shipped to production with a bandwidth leak that made every idle client fire 12 HTTPS region probes every 5 seconds for their entire session, roughly 4.4 GB per month per idle client. I spotted it post-deploy by reading the network panel out of curiosity, and the AI hadn't flagged it in any of the code reviews leading up to that deploy. You must be aware of what the AI is doing or it will cost you. Literally.
• General debugging. The AI is excellent at implementing well-defined changes, but it can lock onto a wrong conjecture about the cause of a bug and keep digging deeper into it rather than questioning the premise. Several times in this build, the AI was confidently chasing the wrong cause, and the only way out of the loop was for me to step back and redirect: "you're assuming X, but we haven't actually verified X. Let's check that first." Without that human override, those sessions would have continued indefinitely.
• Stopping scope creep. The AI is always willing to add more features and abstractions, and the discipline of saying "we don't need that yet" has to come from me.

Three war stories

Netcode iteration. When I deployed to production, the game felt significantly worse than it did on localhost. Direction changes would snap back, the player would oscillate at max speed, and after about 30 minutes of play I'd get a real headache since I have a motion sensitivity. Fixing it took multiple iterations: bumping the server tick rate from 40Hz to 60Hz, switching from EMA-based latency estimation to a sliding-window minimum (because the EMA was latching onto outlier packets in the wrong direction), adding a dead zone on the reconciliation blend so per-packet RTT jitter wouldn't keep yanking the position, and adding a queue mirror so the client and server made the same queue-vs-immediate decision against the same threshold. The final state is smooth at the cost of about 50 to 80 ms of perceived input delay on direction changes during boost. Localhost still feels great, and the residual gap is irreducible without a substantial architectural rework. I wrote a 5-page postmortem afterward to capture the diagnosis, the fixes, and the experiments that didn't pan out.

The bandwidth bug. I shipped to production with a bandwidth leak hiding inside what looked like a clean piece of code. The region-probe handler was being re-fired unconditionally on every RTT update, which meant every player, including ones in the middle of a round, was firing 12 HTTPS region probes every 5 seconds for their entire session. I caught it after deploy by reading the network panel out of curiosity. The fix was roughly a 99% reduction in idle traffic: I decoupled the probes from the RTT update, paused the pings whenever the tab was hidden or the window was unfocused, and only re-fired probes when the user actually opened the region-picker dropdown. The cost for a single player would have been trivial, but at 1000+ idle clients it would have been a real bill. The takeaway is that the AI's first-draft output is scaffolding rather than solution. The original code looked fine and passed every review.

The Vite env file location. I spent an entire deploy cycle wondering why the production WebSocket URL wasn't being baked into the build. The cause was that Vite reads .env.production from envDir, which defaults to whatever root is set to in vite.config.js. My config had root: 'src', but I'd put the env file at the project root, where Vite was silently ignoring it. The AI had generated the right config; I'd just dropped the env file in the wrong directory. A small lesson, but a representative one: the AI tends to produce a coherent skeleton, and the slip-ups tend to live in the seams between that skeleton and the rest of your environment.

What I'd do differently

• I'd spend more time on the rendering pipeline and dynamic LOD, because I hit performance ceilings late and had to retrofit fixes around features I'd already shipped.
• I'd treat the AI's first-draft output as scaffolding rather than as the solution. The bandwidth bug lived inside code that looked fine and passed every review, and that pattern repeats. The AI produces a coherent skeleton, but the load-bearing details deserve a second pass.
• I'd read the wrangler and Fly secret-handling steps end-to-end before the first deploy, because small misconfigurations were the largest chunk of solo debugging time in the entire build.

Live at nodecontrol.gg. Feedback welcome, especially on netcode feel.
---------

ETA: A little late on this since I didn't expect such a huge response! I've set up a subreddit at r/nodecontrol and a discord at https://discord.gg/GzXGnxMD7

I'll be using these to post regular updates. Come say hi, share your plays, or AMA about the game or game development!

Prompt:

"A screenshot of a serbian twitch streamer. She is having a podcast about "Како променити партију на богоугодан начин". Гледаоци и пратиоци у коментарима коментаришу са "Амин" или емоджијем "Три прста" и емоджијем за молитву и слично. Ставити у коментарима да је корисник "АВ" управо донирао 10.000 еура."

Prompt:

"Create a street professional photograph of a stray black-and-white cat. The cat is shot in the middst of watter drinking. Its tongue sticking to the puddle of clean watter on the street. Soft blurred background."

Prompt:

Napravi realističnu sliku, screenshot ekrana računara sa windows 11 operativnim sistemom. Windows ima skin inspirisan Srpskom Naprednom strankom i njenim predsednikom.