My Journey of Vibe Coding: From Copy-Paste to Building a 3D Desktop Environment

 As we all learn and adapt in this fast-moving tech landscape, one truth has become unavoidable: Artificial Intelligence is now an everyday reality.

AI itself isn’t brand new. The core concepts and theoretical foundations have been around since I was back in secondary school. However, the modern explosion of Large Language Models (LLMs)—kickstarted by OpenAI—opened a completely new window for civilization. It reshaped our paradigm and fundamentally altered how developers think, design, and write software.

As a programmer, system analyst, and system architect, I jumped in early. I may not be an AI researcher training base models from scratch, but as a practitioner and power user, my workflow has undergone a massive transformation.

Here is the story of how I went from manually copy-pasting code snippets to "vibe coding" entire spatial desktop environments.

The Early Days: The Copy-Paste Era

Like many developers, my journey started with the OpenAI ChatGPT web interface.

Back then, dedicated coding agents didn't really exist yet. There was no deep IDE integration, and I hadn't hooked up tools like GitHub Copilot into my day-to-day workflow. My interaction with AI was basic and entirely manual:

1. Describe a bug or ask for a function.

2. Copy the code block.

3. Paste it into my editor.

4. Tweak it when it inevitably broke.

It was useful for quick lookups, but it wasn't a structural game-changer just yet.

Going Local and the Mid-2025 Vibe Coding Shift

Equipped with an AMD Ryzen AI+ Max 395 machine, I began experimenting with local models. But before local AI could fully mature for my daily workflow, gemini-cli arrived, and my real experience with agentic vibe coding officially began.

Working with gemini-cli in mid-2025 was a mix of awe and mild frustration. Early models and agents frequently suffered from context drift, wandering away from the architectural boundaries I had carefully established.

BUT it was still miles ahead of writing code line-by-line.

Projects that previously took me 1 to 2 months were suddenly getting wrapped up in 1 week with significantly higher overall quality.

• My Role: I shifted my focus almost entirely to high-level requirements, system architecture, and code review.

• The Agent’s Role: The agent filled in all the tedious gaps I usually skipped when trying to push out a quick prototype—plugging memory leaks, polishing UI components, and wrangling complex CSS layouts.

The Quotas, aether.ing, and the Quest for Local Autonomy

As I began juggling 2 to 3 active projects at a time, Google was incredibly generous with gemini-cli. But good things in tech rarely stay unchanged for long. Google eventually transitioned to Antigravity 2.0, introducing strict quota limits even for Workspace users on Pro plans.

Meanwhile, the AI arms race between OpenAI, Anthropic, and Google accelerated wildly. Model after model hit the market. While everyone was raving about flagship cloud models like Opus, I tried to stay optimistic about local AI to avoid accumulating monthly SaaS subscriptions.

I even started building my own custom agent platform, aether.ing, aiming to empower my workflow using local LLMs hosted on my home server.

However, as the generous gemini-cli tier ended and Antigravity 2.0 proved too restrictive for heavy architectural sessions, I found local LLMs struggling under the weight of complex agentic demands. I experimented extensively with HuggingFace community fine-tunes of Qwen 3.5 and 3.6, but running local 27B or 120B parameter models felt like bringing a knife to a gunfight when compared to the massive remote models being deployed. When Alibaba released Qwen 3.8 at 2.4 Trillion parameters and Kimi launched K3 at 2.8 Trillion parameters, I had to admit reality: my local hardware couldn't keep pace for deep multi-file refactoring. I postponed heavy vibe coding objective on aether.ing, paring its role down to creative co-writing.

The Turning Point: Chipping In for Fable 5 & Opus 5

After hearing endless chatter about the architectural reasoning capabilities of Anthropic's latest models, the release of Fable 5 (with a trial for Pro subscribers) pushed me over the edge. I decided to chip in $20 to test the waters.

The results were staggering.

Case 1: jWebDBAdmin

I had an old, unpolished internal tool named jWebDBAdmin. It had been used by me and a few colleagues for a long time, carrying hundreds (if not thousands) of lines of legacy code. I wanted to add new features, but I was too tired to sink hours into manual refactoring.

I fed jWebDBAdmin to Fable/Opus with a wishlist of major new requirements. In just two 5-hour sessions, the model completely rebuilt the project from the ground up—adding auto-complete, sleek UI polish, and intelligent AI-assisted query suggestions.

Case 2: Applikasi KTG & Vibrefy

• Applikasi KTG: Complex feature sets that used to take 1–2 weeks of manual vibe coding were added and verified in just 2 days.
• Vibrefy: A personal project I had sitting in a drawer for months was completely polished, structured, and uploaded to GitHub directly with the help of the agent.

The Hidden Perk: Automated Git Plumbing

As a developer who never enjoyed dealing with the tedious overhead of Git branching, merge conflicts, and commit management, using agents like Claude Code took that pain away entirely. The agent handles all the Git plumbing while I focus on design decisions.

Going Wild: From Web Apps to 3D Spatial Computing

Once you realize you can build outside your traditional domain knowledge, things get exciting fast.

The Android Media Problem (Vibrefy Mobile)

I had media files encoded in AC3 audio that couldn't play natively inside Android's Google Chrome. I wanted a custom player, so I decided to build a dedicated Android client for Vibrefy.

The catch? I had zero prior experience in native Android development.

With the AI agent handling the framework specifics, we pushed far beyond a standard player. Why stop at standard 2D video? We transformed it into a full 3D and VR media player with support for Nreal / Xreal Air AR glasses—something impossible inside a standard web browser.

The Ultrawide Debugging Need (HoloFrame)

Using the Xreal Air glasses with a Mac presented another roadblock. While Xreal offers Nebula for Mac with virtual screens, the resolution limits made reading long, dense log files during debugging nearly impossible. I needed a single wide canvas where I could read an entire log line from left to right without truncation.

My goal: A virtual desktop canvas running at 7680 × 2160 resolution.

That project became HoloFrame, giving me the exact high-density virtual display real estate I needed for heavy debugging sessions.

The Ultimate Challenge: Spatiand (A 3D Desktop from Scratch)

Eventually, relying on existing host operating systems and window-capture software felt too limiting. Most AR/VR desktop setups use window-capture: rendering an app to a 2D desktop buffer, capturing the pixels, and re-projecting the frame into 3D space. It is inefficient and clunky.

I wanted true spatial computing: an lightweight OS environment where applications directly draw inside 3D space.

After brainstorming hardware options—and guided by ChatGPT's memory of my previous setups—I settled on my target rig: a mobile Mini-PC setup combined with my SteamDeck (running SteamOS) and Xreal Air glasses.

Then came the craziest prompt I've ever thrown at Opus 5: Build a 3D desktop environment from scratch with minimal external dependencies, targeting SteamOS and Xreal Air.

This wasn't a project solved in 2 days, or even a week. I’ve had to fight through strict 5-hour messaging limits and weekly quota caps while balancing side projects. But step by step, byte by byte, it's coming together.

Conclusion: Focus on Architecture, Let the Vibe Flow

Vibe coding isn't about letting an AI blindly write code while you sit back and sleep. It’s about elevating your role as a software builder.

By letting high-tier LLM agents handle syntax, framework boilerplate, UI styling, edge-case memory safety, and Git operations, I am free to spend 90% of my time doing what I love: system architecture, creative hardware integration, and solving real user problems.

Stay tuned—Spatiand will be landing on GitHub soon!

Introducing Aether: The Open-Source Workspace Powered by AI

Managing digital workspace assets across local drives, remote servers, cloud platforms, and AI tools often feels fragmented. Aether is an open-source platform designed to unify your files, remote environments, workflows, and AI assistants into a single, cohesive experience.

Whether you need to manage distributed files, interact with smart AI agents, or run terminal sessions directly from your browser, Aether brings your workspace tools under one roof.

What Makes Aether Unique?

1. Unified Multi-Storage Access

Aether breaks down silos between storage services. Instead of juggling different tabs and cloud providers, Aether lets you seamlessly interact with local file systems, remote environments via SSH, and cloud storage like Google Drive inside one clean interface.

2. Embedded AI Assistants & Specialized Agents

Aether goes beyond standard file management by embedding AI into your daily tasks. From co-writing assistants and general helpers to specialized AI agents tailored for coding and productivity, smart assistance is always integrated directly alongside your files and documents.

3. Web-Based Terminal & Real-Time Connectivity

Work with your connected servers and local tools without leaving your browser. Built-in interactive terminal support and real-time updates provide a smooth, responsive workspace experience without requiring complex desktop setups.

4. Flexible Authentication & Customization

Designed for flexible deployment, Aether supports OpenID authentication, user setting controls, and modular provider configurations, making it easy to adapt to both individual needs and team environments.

Why Open Source?

Workspace management and productivity platforms should be transparent, extensible, and community-driven. Releasing Aether as open-source allows developers, creators, and power users to inspect, customize, and shape the future of unified digital workspaces together.

Whether you want to build custom AI agent skills, integrate new storage providers, or host Aether on your own infrastructure, the project is open for everyone.

Get Started

Aether is now live and available for self-hosting, testing, and contribution.

• Explore the Project: Check out the source code, installation steps, and technical architecture guidelines directly on GitHub.

• Get Involved: Report issues, suggest new features, or submit pull requests to help expand Aether's capabilities.

Welcome to a more connected way to work. Welcome to Aether.

How I Used Vibe Coding to Build HoloFrame: Bringing Big-Screen AR Back to Mac

 Like many people who picked up a pair of Xreal AR glasses, I had one simple dream: a massive, high-resolution virtual screen hovering right in front of my eyes wherever I opened my Mac. No bulky external monitors, no wasted desk space—just a giant floating workspace that goes wherever I do.

When Xreal originally launched their Nebula app for macOS, it felt like the future was finally here. But over time, official support waned, updates stalled, and the app became increasingly difficult to rely on. My glasses were slowly turning into an expensive pair of standard sunglasses sitting next to my laptop.

Instead of waiting for an official fix that might never come, I decided to build my own solution: HoloFrame.

Letting AI Do the Heavy Lifting: Enter "Vibe Coding"

If you told me a few years ago that I’d write software to communicate directly with hardware glasses, I probably would have laughed. Building something like this requires getting under the hood of hardware engineering:

• Decoding low-level USB HID protocols to talk to the glasses directly.

• Extracting raw IMU sensor data (accelerometers and gyroscopes).

• Performing complex 3D math and view-smoothing calculations so the screen stays firmly anchored in virtual space without making you feel motion sick.

Ordinarily, figuring out those low-level protocols and spatial calculations would require weeks of reading hardware specs and brushing up on advanced trigonometry. But in the era of vibe coding, I didn't need to write every line of math by hand.

I acted as the architect—defining the vision, testing the behavior, and steering the direction—while letting AI handle the grueling USB protocol plumbing and real-time head-tracking logic.

Meet HoloFrame

The result of this experiment is HoloFrame, a lightweight native Mac application designed to give you back your virtual multi-monitor experience.

Here is what HoloFrame brings to the table:

• Instant Big Screen Virtualization: Turns your Xreal glasses into a massive, crisp virtual display for macOS.

• Smooth Head Tracking: By leveraging custom sensor fusion and view smoothing, the screen stays pinned in mid-air seamlessly as you turn your head.

• Lightweight & Native: Built specifically for macOS, bypassing bloated frameworks to keep CPU usage low and battery life high.

• Zero Frustration: Plug in your glasses, launch the app, and get straight to work.

Why This Project Matters

HoloFrame started as a personal itch to fix a broken workflow, but it ended up demonstrating something bigger: hardware is no longer locked behind wall-off ecosystems.

When hardware companies move on or stop updating their software, community-driven development can step in. With AI acting as an assistant for low-level protocol decoding and mathematical crunching, building tailored software for your favorite gadgets is more accessible than ever.

If your Xreal glasses have been gathering dust because of unsupported Mac software, it's time to wipe them off. HoloFrame is here to give you back your workspace.

Check out the repo, try it out, and let me know how it works for your daily workflow!

Hemera — A Lightweight Bridge for Local & Cloud AI Models

Running local LLMs often means dealing with moving targets. Runtimes like llama.cpp move at a breakneck speed—sometimes releasing multiple builds in a single day. While that pace brings support for new quantizations immediately, an engine update today can easily break or regress a model that ran perfectly yesterday.

On top of that, managing different GPU backends (CUDA, ROCm, Vulkan), missing dynamic libraries, and setting up models for different client tools usually means juggling multiple local setups.

If you want to run local GGUF models—or route to cloud providers—without worrying about an engine update breaking your setup, you quickly run into friction.

That's why I came with idea of Hemera—a flexible local AI engine manager, wrapper, and proxy router written in Java.

The Spirit of the Project

The philosophy behind Hemera is simple: unify your AI tooling into one quiet, self-contained service.

Instead of juggling different local wrappers or hardcoding provider-specific integrations into your apps, Hemera sits in the middle. It acts as both a local engine orchestrator and a multi-dialect API translator.

I wanted a tool that:

• Doesn't force a framework on you: Zero external dependencies—no Maven, no Gradle, no heavy web frameworks, and no npm build step. Just JDK 21+ and a single 112 KB JAR file.

• Never deletes what worked: Engine builds live side-by-side. Updating llama.cpp never removes older versions, so if a new build misbehaves, you can roll back or pin a model to a previous tag in one click.

• Handles local & remote natively: Reads local GGUF files directly, manages backends (CUDA, ROCm, Vulkan) per model, and makes remote models (DeepSeek, OpenAI, Gemini, Claude) look like local endpoints.

Key Features

• One Endpoint, Three Dialects: Supports Ollama, OpenAI, and Anthropic Claude endpoints on a single port (12434). Every tool in your stack—from the native ollama CLI to Claude Code—can drive your models.

• Engine Versioning & Rollbacks: Keep multiple engine releases and GPU backends (ROCm, CUDA, Vulkan, SYCL, CPU) installed simultaneously without interference.

• Smart GPU Discovery (ELF Header Inspection): If a GPU build is missing vendor dynamic libraries, it often quietly falls back to CPU execution at a crawl. Hemera reads ELF headers on startup, detects missing .sodependencies, searches system paths, and automatically sets LD_LIBRARY_PATH for that process.

• Virtual Model Aliases: A single GGUF file can be configured as multiple named models—each with its own context size, GPU offload settings, chat templates, and environment variables.

• Native GGUF Inspection & Safe Deletion: Built-in direct GGUF header reading (GgufReader.java) parses metadata without external CLI tools. Deleting a model in the UI only drops the configuration, keeping expensive GGUF files safe.

• Minimalist Web Dashboard: An embedded, zero-framework web UI (vanilla HTML/CSS/JS) that follows your OS light/dark theme for monitoring running models, engine PIDs, and proxy settings.

Under the Hood (Architecture)

Hemera’s codebase is structured around a few core modules inside ing.aether.hemera:

ing.aether.hemera
├── api         # API dialects (OpenAI, Claude, Ollama) & Proxy Dispatcher
├── engine      # Engine downloaders, ELF/Tar handling, Instance lifecycle
├── model       # Bare-metal GGUF reader & Model Registry
├── http & json # Custom HTTP router & lightweight JSON engine
└── web         # Admin REST API endpoints & static dashboard assets

1. The Proxy & API Layer (hemera.api): Intercepts incoming requests, normalizes payloads via ProxyDispatcher, translates between protocols on the fly, and routes requests to local processes or cloud APIs while preserving Server-Sent Events (SSE) streaming.

2. The Engine Orchestrator (hemera.engine): Manages executable runtimes. It resolves required native shared libraries (LibraryResolver.java), handles binary archives (Tar.java), and manages the lifecycle of local engine processes (InstanceManager.java).

3. The Model Registry (hemera.model): Instead of relying on external CLI tools to inspect files, ModelScanner searches local directories and uses GgufReader to parse tensor metadata directly from binary headers to feed the central registry.

4. Core Infrastructure (hemera.http & hemera.json): Powered by a custom hand-rolled JSON parser and HTTP router running on Java's virtual threads for maximum efficiency.

Check out the code on GitHub: github.com/peprasetya/hemera