DEV Community: Rome

Gemma 4 dense by default: why your local agent doesn't want the MoE

Rome — Sat, 23 May 2026 22:52:45 +0000

The decision you don't realize you're making

You sit down to wire Gemma 4 into a local agent loop — a Claude-Code-style tool-using harness, a long-context code reviewer, an offline research assistant. Google has handed you four architectures from the same release. The contest framing nudges you toward an obvious read:

E2B and E4B (effective-parameter) models for phones, browsers, and a Pi 5.
31B dense as the on-prem workhorse.
26B MoE as the efficient one — the mixture-of-experts variant that activates a fraction of its parameters per token and claims better quality per FLOP.

The cheap reflex, in 2026, is to reach for the MoE. It's the architecture every frontier lab is paying for. Mixtral, DeepSeek V3, Qwen3 — the production direction is one-way traffic. If the open release at your scale gives you an MoE option, you pick it. That's the move.

That move is wrong for the workload most of you will actually build.

For interactive local agents — multi-turn tool use, code editing, long-context reasoning chains where each step is read by a human or fed into the next step — the 31B dense is the right default, and the 26B MoE is the wrong one. The reason is not size, quality, or open-weights ergonomics. It's that agents fail on the tail, not the mean. Routing variance lives in the tail. That's the entire argument; the rest of this post is the math, the mechanism, and a benchmark you can run this weekend on whatever hardware you have.

The tail is the workload

A common mistake when reasoning about local-model deployments is to optimize the average. Tokens per second, mean time-to-first-token, throughput at batch 1 — these numbers are what every llama.cpp benchmark in your feed reports.

For a chatbot that gets one user message and emits one reply, the mean is fine. For an agent, it isn't.

Consider a 30-step tool-use loop — a typical ReAct-style agent doing local code search, file edits, test runs, and a final summary. Each step is a generation call. Suppose each call has a 3% probability of exceeding a soft timeout (say, the human watching the screen gives up and Ctrl-Cs). The probability that at least one step in the loop blows the timeout is:

1 - (1 - 0.03)^{30} \approx 0.60

A 3% per-step tail becomes a 60% chance of a visibly broken loop. Push the per-step tail to 1% and you're still at 26% loop-level failure across 30 steps. The mean latency could be excellent; the user experience is broken. Agents are tail-bound systems, the same way low-latency trading, search ranking, and request-level web serving are. Jeff Dean's "tail at scale" is, in fact, about exactly this — when you fan out many requests, the slowest one dominates. An agent fans out across time, not machines, but the math is identical.

This is the lens the architecture comparison has to be read through. Not "which model gets more right answers per FLOP," but "which model gets right answers reliably under the user's patience budget."

How MoE routing makes a tail

Every MoE forward pass routes each token through a small subset of the available experts. In Mixtral 8×7B, that's top-2 of 8 experts per token per MoE layer. In DeepSeek V3, it's top-K out of hundreds, with shared experts plus routed experts. The architectural details vary; the routing mechanism does not. A learned gating network emits expert probabilities; the implementation activates the top-K.

Several consequences fall out of this design — and they are not bugs, they're load-bearing features of why MoE works at all. They just bite a local agent harder than a batched cloud workload.

Active parameters per token are a distribution, not a constant. Google's naming for the MoE — gemma-4-26B-A4B, "26 billion total, 4 billion active" — describes an expectation across tokens, not a per-token guarantee. For a prompt that lands hard on a small number of experts — say, code in an unusual language, or a domain-specific token distribution — the same experts get hit on every layer, creating utilization hotspots. The total work across the layer is the same; the load balance is not. On a multi-GPU deployment this is fine, because the all-reduce across experts amortizes it. On a single-machine local deployment it shows up as per-token latency variance.

Expert utilization is non-uniform. A closer look at Mixture-of-Experts in LLMs (Lo et al., 2024) finds that routers tend to select experts whose outputs have larger norms, that expert diversity changes layer by layer, and that the final layer routes differently from intermediate layers. The implication for an agent's tail isn't subtle: which experts your tokens actually hit is a function of what the tokens are, and adjacent steps in an agent loop — where one step's output becomes the next step's input — can land in substantially different parts of the expert configuration space, with substantially different latencies. For a batch-mode service the variance washes out across many users; for a single agent loop, each user is the batch.

Load-balancing losses pull the model toward uniform expert use, but they don't guarantee it. Training-time auxiliary losses (Shazeer et al., 2017; Fedus et al., Switch Transformer) penalize over- and under-used experts so the model learns a roughly even distribution. Roughly even at the dataset level is not even on your specific prompt. The auxiliary loss is a soft prior; the runtime gating is what determines your tail.

The KV cache is mostly arch-agnostic, but the activations on top of it aren't. For Gemma 4 specifically we don't yet have the per-architecture cache numbers I'd want, but the general principle holds: the KV cache footprint at long context will be similar for dense and MoE in the same family (same attention layout, GQA, same hidden size), but the per-token activation cost will diverge. The MoE wins on raw FLOPs per token. It does not win on predictable FLOPs per token.

The dense model has none of this surface. Every token does the same work. Routing variance is zero because there is no routing. The p99 looks like the p50 plus the inherent system noise of your kernels, your scheduler, and your memory hierarchy. That's the property the agent loop wants.

The MoE memory myth

A second piece of the cheap reflex says: "26B MoE is smaller than 31B dense, so it fits better in my VRAM."

It doesn't.

MoE memory residence is all parameters, not just the activated ones. Every expert has to be loaded somewhere — either in GPU memory, or paged in from system RAM, or paged in from disk. The "26B" in Gemma 4 26B MoE is the residence footprint; the "activates a fraction per token" describes compute, not memory. On a single consumer GPU, both models compete for roughly the same memory budget, and the dense model is often the easier fit because:

Quantization is cleaner on dense. Dense weight matrices quantize uniformly; MoE quantization has to contend with expert-utilization skew, where rarely-routed experts get less calibration signal and degrade harder under aggressive bit-width reduction. Sub-1-bit MoE compression is feasible — see QMoE for the existence proof on Switch-Transformer-c2048 — but it requires custom kernels. The boring 4-bit path on the dense model is the path that already works in every local inference engine you'll touch (LLM-FP4 is the well-trodden version).
Offloading hurts MoE more. If you spill experts to CPU or disk, you pay the offload cost per token, conditional on routing. A dense model that spills paid the cost predictably; an MoE that spills pays it stochastically, and the stochasticity is — again — the tail.
Compilation is cleaner on dense. llama.cpp, MLX, and vLLM all support both, but the dense path has had more attention. Fewer corner cases in expert routing, GQA, and KV layout interactions. If you've ever had a custom kernel mis-handle expert dispatch, you know.

The 26B MoE will run on your machine. So will the 31B dense. Which one runs predictably is the question.

When the MoE is correct

I'm not arguing the 26B MoE is a bad model. It's the right model for several workloads — they just aren't the local-agent workload most readers building this weekend will actually have.

The MoE is the right pick when:

You're serving many concurrent users. Batching across requests amortizes routing variance. Hot experts become warm; cold experts get exercised. The per-token expectation is what you see.
You're throughput-bound, not latency-bound. Background processing, RAG indexing, bulk classification, synthetic data generation at scale. Anywhere the user isn't waiting on a single response.
You can afford a per-request retry budget. If a slow step is recoverable by re-issuing, the tail flattens out. Most agent loops can't recover gracefully — the partial state is already entangled with the world (a file was edited, a test was run).
You're deploying on accelerators with native expert-parallel support. Multi-GPU or TPU deployments where the all-reduce overhead is dominated by the FLOP savings. This is exactly where the MoE was designed to win, and it does.

The Gemma 4 26B MoE is, on its merits, an excellent open-weights MoE. Pick it for the workloads it was designed for. Don't pick it because the marketing material says "more efficient" and you didn't ask "efficient at what."

The decision matrix

Workload	Pick
Single-user local agent loop (tool use, code edit, multi-turn)	31B dense
Local long-context Q&A (one or two large reads, then short outputs)	31B dense
Local RAG service with many concurrent users	26B MoE
Local batched synthetic-data or evaluation pipelines	26B MoE
Background indexing, classification, summarization at scale	26B MoE
Fine-tuning on a narrow domain (small dataset, limited compute)	31B dense (MoE fine-tuning collapses expert specialization at small data scales)
Mech-interp / SAE / circuit work on an open MoE	26B MoE (it's the interesting object)
Phone, Pi 5, browser deployment	4B effective (you don't have a choice)
Cloud or multi-GPU server deployment	26B MoE (this is where it wins)

Two things to flag explicitly. First, the fine-tuning row: MoE fine-tuning is a research subfield of its own because the router and the experts have to be tuned coherently, and small datasets can collapse expert specialization. If you have 5,000 examples and want to teach Gemma 4 your codebase's conventions, the dense model is the more forgiving target. Second, the mech-interp row: a 26B MoE with open weights is a genuinely exciting interpretability artifact — see the GemmaScope lineage on Gemma 2 dense — and if your "agent" is actually a circuit-analysis pipeline, the MoE is the more interesting object. That's a different essay.

The benchmark you should run this weekend

Don't take my word for any of the above. The whole point of running models locally is that you can measure. Here is the experiment, three ways, calibrated for the hardware most of you actually own.

What to measure: not tokens per second. Measure per-step p50, p95, and p99 latency across at least 200 generation calls, with prompts that approximate your real workload (short turns, mixed lengths, occasional long-context reads). If you can run an actual agent loop end-to-end, even better — record the per-step distribution and synthesize the loop-level success probability.

Apple Silicon (M2 / M3 / M4):

# Build llama.cpp with Metal backend
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp && cmake -B build -DGGML_METAL=ON && cmake --build build -j

# Community-quantized GGUFs (Google ships safetensors; unsloth ships GGUF)
huggingface-cli download unsloth/gemma-4-31B-it-GGUF \
  gemma-4-31B-it-Q4_K_M.gguf --local-dir .
huggingface-cli download unsloth/gemma-4-26B-A4B-it-GGUF \
  gemma-4-26B-A4B-it-Q4_K_M.gguf --local-dir .

# Benchmark: 200 generations of 512 tokens, log per-call timing
./build/bin/llama-bench -m gemma-4-31B-it-Q4_K_M.gguf  -n 512 -r 200 -o json > dense.json
./build/bin/llama-bench -m gemma-4-26B-A4B-it-Q4_K_M.gguf -n 512 -r 200 -o json > moe.json

The 26B-A4B suffix on the MoE is Google's naming for "26B total params, ~4B activated per token" — the very expectation-vs-distribution gap discussed above. llama-bench gives per-call timings; pipe through jq to extract the per-call latencies and compute your own quantiles. For a richer view, MLX-LM gives cleaner kernel timing on Apple Silicon and lets you verify the dispatch overhead directly.

Consumer NVIDIA (RTX 4090, 3090, A6000):

# vLLM with the official safetensors, served on the same machine
pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model google/gemma-4-31B-it --quantization awq \
  --port 8000 &

# Drive it with a benchmark harness — 200 requests, log per-request latency
python -m vllm.benchmarks.bench_serving \
  --backend openai-chat --endpoint /v1/chat/completions \
  --base-url http://localhost:8000 \
  --model google/gemma-4-31B-it \
  --num-prompts 200 --dataset-name sharegpt \
  --result-filename dense.json

vLLM's benchmark suite reports p50/p95/p99 directly. Repeat with --model google/gemma-4-26B-A4B, compare the p99 columns, and that's your answer.

A note: vLLM's MoE kernel quality varies by version. Check the supported models page before assuming both architectures get equal-quality dispatch. This is itself part of the dense-by-default argument — the ecosystem is more battle-tested on dense.

Pi 5 / phone (Gemma 4 E4B):

The MoE-vs-dense decision doesn't apply at this tier — you're running the E4B effective-parameter model, not because you chose to, but because it's what fits. The interesting benchmark here is different: measure token-level latency *variance* on the same prompt set across multiple runs. Edge silicon shares compute with the OS scheduler, and your real tail will be dominated by OS jitter, not architecture. Use time plus a wrapper that logs to a CSV:

# On Pi 5 with llama.cpp built for ARM
for i in $(seq 1 200); do
  /usr/bin/time -f "%e" ./build/bin/llama-cli \
    -m gemma-4-E4B-it-Q4_K_M.gguf \
    -p "$(jq -r ".prompts[$((i % 50))]" prompts.json)" \
    -n 256 -no-cnv 2>>latencies.csv
done

The lesson on the edge is the same as on the workstation: optimize for the experience the user actually has, which is the tail.

What to take away beyond this release

Gemma 4 forces a clean architectural choice at the same scale tier — dense versus MoE, 31B versus 26B. The next open release will too. The release after that. The "always pick MoE because it's more efficient" reflex was correct for cloud training and cloud serving, and it has been pattern-matched into local deployment where it doesn't belong.

The lens that holds up across releases is not parameter count and not FLOPs per token. It is the latency profile of your workload. If a single user is waiting on a single response chain, you want predictable tokens, not cheap tokens. If many users are sharing a pool of compute and the throughput is what's billed, you want cheap tokens at the expense of any single user's tail.

The open-weights ecosystem is mature enough now that you don't have to pick on vibes. Two llama-bench runs and a quantile calculation will tell you the answer for your hardware and your prompts. Run them before you commit to an architecture.

The dense model is the default. The MoE is the optimization. Treat them in that order.

Submitted to the DEV.to Gemma 4 Write-About challenge, May 2026, with some help from AI. Code samples have been validated against the relevant tool documentation; concrete benchmark numbers are intentionally omitted because the right benchmark is your benchmark, on your hardware, with your prompts.

CodeMender Doesn't Work Without a Skeptic

Rome — Sat, 23 May 2026 22:52:05 +0000

The headlines at Google I/O 2026 went where you'd expect — Gemini 3.5, the new intelligent eyewear shipping in the fall, Antigravity 2.0 with its new CLI and subagents. CodeMender — Google DeepMind's autonomous code-security agent — got folded into Agent Platform almost as a footnote. Most coverage moved on.

That's a mistake. CodeMender is the most architecturally significant announcement of the event, and not because it finds bugs. Tools have found bugs for decades. It's significant because of how it claims to find them, and because of what its architecture quietly admits about where AI security is actually heading.

Read Google's own description of how CodeMender works:

CodeMender is an AI-powered agent utilizing the advanced reasoning capabilities of our Gemini models to automatically fix critical code vulnerabilities. […] These patches are then routed to specialized "critique" agents, which act as automated peer reviewers, rigorously validating the patch for correctness, security implications and adherence to code standards before it's proposed for final human sign-off.

Read that twice. A reasoning model proposes a patch. A separate "critique" agent — Google's own term — sits behind it and rigorously validates before anything reaches a human. CodeMender isn't a model. It's a loop. And the critique agent is doing the load-bearing work.

The pitch that has been DOA for eighteen months

Every AI-security vendor since 2024 has been selling roughly the same pitch: large language models will find vulnerabilities faster than humans, with broader coverage and cheaper cost per finding. The demos look magical — a model reads a function, mumbles something about CWE-89, and produces a patch.

What the demos don't show is what happens at scale. The genuine signal those tools surface is real and useful — that's the upside that makes the category viable. But security analyst attention is the scarcest resource in the company. After two or three findings turn out to be noise, the analyst marks the next one as noise too — independent of whether it's real. Trust falls off a cliff and does not amortize back. This isn't speculative; it's the binding constraint on any scanner's adoption curve.

Static analyzers shipped with well-documented false-positive problems for two decades; the LLM-on-top wave inherited and often amplified them. Snyk's DeepCode AI describes itself as combining "symbolic and generative AI, several machine learning methods, and the expertise of Snyk security researchers" — explicitly a hybrid stack, not a single model. GitHub's Copilot Autofix "leverages the CodeQL engine, GPT-4o, and a combination of heuristics" — again, an LLM embedded in a deterministic pipeline, not a model alone. The products that struggled were the ones that shipped a single LLM with no scaffolding around it. The products that survived were the ones that figured out the scaffolding was the problem.

The model wasn't ever the bottleneck. Trust calibration was.

What CodeMender quietly admits

The architecture description is a structural concession. Auto-patching makes the false-positive problem worse, not better — a wrong patch doesn't just waste analyst time, it changes the codebase, breaks the build, sometimes introduces a new bug downstream. If "find a bug" is hard to ship with high enough precision, "find and fix a bug" is harder still.

You cannot solve this by training a better generator. Train the model to be more conservative and recall collapses. Train it to be more aggressive and precision collapses. The recall-precision frontier of a single model is fundamentally bounded by its prompt and its training distribution.

What you can do is split the job. One model proposes. Another model disposes. The proposer is recall-biased: it throws a wide net, surfaces everything that smells like a vulnerability, optimizes for not-missing. The critique agent is precision-biased: its job is to take each finding and try to kill it. Is this exploit actually reachable? Is there a guard upstream the proposer missed? Is this a known false-positive pattern? Does the proposed patch break existing tests?

The critique agent is the architecture. Without it, the proposer's output is unshippable. With it, the system can claim what CodeMender does claim: that it surfaces validated patches for human review rather than a firehose of speculative ones.

That decoupling — the model that finds the bug is not the model that decides the bug is real — is the entire ballgame.

Why a two-model loop composes better than one smart model

Proposer-skeptic decomposition isn't new. Math reasoning uses proposer-verifier loops. Multi-agent debate frames the same idea. RLHF with adversarial critics is the training-time version. Ensemble methods in classical ML have known forever that diverse weak learners beat a strong monolith on tasks with asymmetric error costs.

What's security-specific is that the asymmetry isn't a nice-to-have — it's the binding constraint that makes monolithic models structurally unshippable. When error costs are asymmetric, you don't want a single model trading off precision against recall on one axis. You want two models trading off against each other on different axes.

Four concrete payoffs from the decomposition:

Different models for different roles. The discovery model can be your biggest, most expensive reasoning model, because it runs once per file. The critique model can be smaller, faster, cheaper, running many times per finding. Cost-latency becomes a tunable knob, not a constraint baked into the architecture.
Independent post-training. Discover a new false-positive pattern the system keeps surfacing? You don't retrain the giant discovery model. You add an adversarial example to the critique distribution and ship.
Hot-swappable foundations. As foundation models improve, you swap them in without rebuilding the loop.
Auditable disagreements. When the proposer says "vuln" and the critique says "no," you have a structured artifact — a transcript of an argument — a human can inspect. This is the explainability story monolithic models can't tell.

The pattern, in code

The naive single-pass setup that has powered two years of demos:

findings = discovery_model.scan(code)
return findings  # FP-saturated, analyst trust gone in two findings

The decomposed loop:

candidates = discovery_model.scan(
    code,
    prompt=DISCOVERY_PROMPT,  # recall-biased: "find anything that smells wrong"
)

validated = []
for finding in candidates:
    if finding.confidence < DISCOVERY_THRESHOLD:
        continue
    verdict = critique_model.adjudicate(
        finding,
        prompt=CRITIQUE_PROMPT,  # adversarial: "try to kill this finding"
        context=finding.surrounding_code(),
    )
    if verdict.kept and verdict.confidence > PRECISION_THRESHOLD:
        validated.append(finding.with_verdict(verdict))

patches = [patch_model.propose(f) for f in validated]
return [p for p in patches if regression_tests_pass(p)]

CodeMender — running on Google's most capable reasoning models — still needs the critique stage. The structural decomposition does more for shippability than another order of magnitude in foundation-model parameters.

Where the convergence is

This pattern is showing up everywhere a serious security tool ships. Purdue's LLMSCAN separates concerns explicitly: syntactic facts come from Tree-sitter parsing (verifiable, deterministic); the LLM handles only the semantic facts parsing can't reach. The insight isn't quite "skeptic-after-proposer" — it's "ground the proposer in structure the LLM can't hallucinate." Same recall-precision frontier, attacked one tier earlier.

The RAPTOR framework goes the other direction. Candidate findings from classical pattern-matching (Semgrep, CodeQL) flow through progressive validation gates that include reachability verification via Z3 SMT solving and an exploitation-feasibility check before anything surfaces. A four-stage skeptic stack behind a recall-biased finder.

CodeMender is the most prominent expression of a pattern that has been forming quietly for over a year. The convergence is the signal.

The actual moat

Here is where the I/O 2026 announcement gets genuinely interesting, and where most takes on it will miss the point.

The architecture itself is not a moat. Anyone can stack two LLMs. The recipe is now public — Google just published it.

The moat is the critique model's training distribution.

Think about what makes a critique agent useful in production. It is not the cleverness of the prompt. It is the catalog of adjudicated false-positive patterns the model has been exposed to — the corpus of "the proposer flagged this, a human checked it, the human said: not a vuln, here's why" examples. That corpus is built by burning analyst trust the first time and never the second. It compounds slowly. It cannot be scraped. It is utterly specific to the languages, frameworks, and idioms of the customer base that produced it.

CodeMender, in its first six months, had upstreamed 72 security fixes to large open-source codebases, including projects of over four million lines. The output is impressive on its own. What matters more for Google's strategic position is what those 72 fixes built: a labeled corpus of "proposed patch, critique verdict, human sign-off" tuples that nobody else has and nobody else can quickly acquire. Every accepted fix narrows the gap between Google's critique distribution and the actual statistical landscape of real vulnerabilities in deployed code. Every rejected patch sharpens the critique's nose for the specific shape of plausible-but-wrong fixes.

CodeMender's moat is the critique agent's experience, not its capability. The architecture is the cost of entry. The corpus is the durable asset.

Auto-remediation as forcing function

Here is the counterintuitive corollary. Most observers will read CodeMender as a find-and-patch tool that prioritizes auto-fix because Google wants the dramatic demo. The deeper reason is structural: auto-fix is the only forcing function that exposes whether a finding was real.

Think about the feedback signal. A patch that doesn't compile is a confirmed false positive. A patch that compiles but breaks behavioral tests is a confirmed false positive. A patch that compiles, passes tests, but gets rejected by a maintainer with "this isn't a security issue" is a confirmed false positive — and the maintainer's reasoning becomes training data for the next iteration of the critique agent.

Compare this to a detection-only tool that surfaces findings to humans and asks them to triage. The feedback is delayed, ambiguous, often never logged — a JIRA ticket marked "won't fix" doesn't tell the model why. The find-then-fix architecture closes the loop with a far higher-fidelity signal.

Auto-remediation isn't a UX feature riding on top of detection. It is the validation mechanism that makes detection improve over time. Tools that lean into the find-and-fix loop will out-improve tools that try to perfect detection in isolation, because they will be ingesting orders of magnitude more high-quality false-positive feedback per unit of analyst time.

What this means for the rest of the stack

A few extrapolations:

The unit of value in AI security is the loop, not the model. Disciplined validation with a mediocre foundation model will out-ship a state-of-the-art foundation model wrapped in a naive single-pass setup. Vendors who think the model is the product are about to get out-shipped by vendors who think the loop is the product.
Critique-model training data is the new ImageNet. The next round of M&A in security tooling will not be about who has the best static analyzer. It will be about who has the deepest labeled corpus of validated-and-rejected findings. The companies worth buying are the ones whose loops have been running longest with real analysts in them.
Open-sourcing the loop won't kill the moat. Google could publish CodeMender's full architecture tomorrow. The architecture isn't the asset. The accumulated critique distribution — the millions of micro-judgments embedded after a year-plus of running against real OSS — does not transfer with the source code.

The real headline

The story buried in CodeMender's I/O 2026 footnote is that Google — the company with the resources to build any single model it wants — has decided the path forward in code security runs through architecture and through accumulated experience, not through model capability alone. They did not announce a bigger reasoning model with better vuln-detection benchmarks. They announced a loop that has been running for over six months, learning from real upstream contributions, and getting more useful with every accepted patch.

The model is not the product. The critique agent is not the product. The corpus the critique agent has been trained on is the product. Everything else is infrastructure around that compounding asset.

Notes and sources:

Google's I/O 2026 developer keynote roundup — official announcements including Antigravity 2.0 and the CodeMender integration into Agent Platform.
Google DeepMind's CodeMender announcement — source for the architecture quote and the description of "critique" agents as automated peer reviewers (October 2025).
SiliconANGLE coverage — the 72-fix figure and the codebase-size detail.
The New Stack's Antigravity / CodeMender I/O 2026 writeup — framing on the agentic platform positioning.
LLMSCAN (Purdue) and RAPTOR — adjacent architectures converging on the same recall-then-precision pattern.
Used AI for research and writing.

Interactive 3D Office Desk

Rome — Fri, 04 Jul 2025 04:09:37 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, Holistic Webdev: Office Space

Submission by dev username: member_01928ffe

What I Built

For this challenge, I decided to step away from traditional 2D layouts and build something that felt truly immersive and personal: a fully interactive 3D digital desk space. My goal was to create more than just a webpage; I wanted to build an experience. This virtual office isn't just a static image—it's a dynamic environment where every object tells a story and serves a purpose.

The scene starts with a "hero" view of a complete desk setup. From there, the user can scroll down to navigate through a series of full-screen drawers, each dedicated to a different project. But the interaction doesn't stop there. Almost every item on the desk is clickable, opening up detailed pop-up modals:

The Monitor: Brings up a modal with a snippet of code.
Sticky Notes: Each note opens a unique, interactive to-do list.
The Calendar: Reveals a fully functional, navigable calendar widget.
Mail: Opens a ready-to-use email editor.
Name Card: Displays a weekly timesheet and a sign-out option.
The Camera: Shows a gallery of photos with captions.

This project was an ambitious attempt to blend the lines between a user interface and a tangible, explorable space.

Demo

You can experience the live version of the project.

Below is an embedded version of the interactive desk scene. Click on the objects, scroll down to explore the drawers, and see what you can discover!

See the Pen
Interactive 3D Office Desk in Three.js by Rome (@Rome-1)
on CodePen.

Journey

This project was a deeply meaningful journey for me. For a while, I'd been looking for a challenge that would not only let me flex my existing web design and frontend skills but also push me into new, unfamiliar territory. This hackathon was the perfect opportunity.

I started with a simple photo of a desk and a question: "What if this was real?" That question led me down the rabbit hole of WebGL and, specifically, Three.js. The learning curve was steep. Moving from the predictable world of CSS layouts to the boundless 3D space of a element was both daunting and exhilarating. I spent so many hours learning about scenes, cameras, lighting, materials, and raycasting for interactivity.

One of the choices I'm most proud of is the scrolling navigation. Instead of simple anchor links, I wanted the transition from the main desk to the project drawers to feel like a seamless, cinematic camera movement. Implementing this required custom logic to control the camera's position with the mouse wheel, creating a unique, webpage-like feel within a 3D environment.

Every interactive pop-up was its own mini-project. Building the dynamic calendar, the to-do lists where you can check off items, and ensuring that all modals felt polished and prevented background interactions was a fantastic exercise in detail-oriented development.

This hackathon has been more than just a coding challenge; it's been a reaffirmation of my passion for creating engaging and beautiful user experiences. It has reignited my confidence in my design sensibilities and given me a powerful new tool in Three.js to bring even more ambitious ideas to life. I walk away from this not just with a project I'm incredibly proud of, but with a renewed sense of what's possible on the web.