How AI-assisted development transformed an ambitious Rust project from concept to reality—and why knowing what you’re building matters more than ever

---

The Challenge

When I decided to build Nexus Explorer—a GPU-accelerated file explorer in Rust—I knew I was setting an ambitious goal. File explorers are deceptively complex: they need to handle millions of files, provide instant feedback, manage async I/O without freezing the UI, and deliver a polished user experience across multiple platforms.

Traditional development would take weeks, maybe months. I had 4 hours.

The Most Important Lesson: Know What You’re Building

Before I talk about AI and tools, let me be clear about something: AI-assisted development amplifies your expertise—it doesn’t replace it.

If you don’t understand:

• Why async I/O matters for file operations
• How GPU rendering differs from CPU rendering
• What makes a good UI architecture
• When to use caching vs. fresh data

...then AI will generate plausible-looking code that falls apart under real use. The AI doesn’t know your constraints, your users, or your performance requirements. You do.

This is why the research phase was critical. Before writing a single line of code, I spent time understanding:

1. GPUI’s architecture - Reading Zed’s source code to understand Entity/View separation
2. Async patterns in Rust - How tokio, channels, and background executors interact
3. File system performance - Why jwalk is faster than walkdir, how batching prevents UI thrashing
4. Search algorithms - Why nucleo (from Helix) outperforms traditional fuzzy finders

This research informed every decision. When the AI suggested something that didn’t fit the architecture, I could recognize it and steer toward the right solution.

Enter Kiro IDE: A Game Changer

This was my first time using Kiro IDE, and I’m now a convert. After this hackathon, Kiro is my go-to development environment.

What amazed me was Kiro’s structured approach to AI-assisted development. It’s not just "chat with an AI"—it’s a complete system for directing AI work through well-defined structures:

Requirements → Design → Tasks

This three-tier spec system transformed how I worked with AI. Instead of ad-hoc prompts, I had:

1. Requirements: What the feature needs to accomplish
2. Design: How it should be architected
3. Tasks: Specific implementation steps

When I pointed Kiro at these specs, it was like having a colleague I could direct with precision. The AI had a plan to follow. It understood context. It knew what we were building and why.

It was a breeze.

Seriously. I’ve used other AI coding tools, and they feel like shouting into the void hoping something useful comes back. Kiro felt like pair programming with someone who actually read the project documentation.

What is "Vibe Coding"?

Vibe coding is a development philosophy where you:

1. Describe intent rather than dictate implementation
2. Iterate conversationally with AI to refine solutions
3. Focus on architecture while AI handles boilerplate
4. Review and guide rather than type everything
5. Catch mistakes because you understand the domain

It’s like pair programming with an infinitely patient partner—but you’re still the senior engineer making the calls. And with Kiro’s spec system, that partner actually understands the bigger picture.

Day 1: Architecture and Foundation

Planning with Specs

Kiro’s spec system was invaluable. I created structured requirement documents that served as both documentation and AI context:

.kiro/specs/
├── file-explorer-core/
│   ├── requirements.md    # What we're building
│   ├── design.md          # How we're building it
│   └── tasks.md           # Implementation checklist
└── ui-enhancements/
├── requirements.md
├── design.md
└── tasks.md

This wasn’t just documentation—it was a contract between me and the AI. When I referenced these specs, Kiro understood the full context of what we were building.

But here’s the key: I wrote the requirements. The AI didn’t decide we needed generational request IDs to prevent stale async results—I did, based on my understanding of the problem. The AI helped implement it correctly.

Key Architectural Decisions (Made by Me, Implemented with AI)

Decision 1: GPUI Framework

I chose GPUI (from the Zed editor) for GPU-accelerated rendering. This was a calculated risk—GPUI is powerful but has limited documentation. My research showed it could deliver smooth scrolling through large directories, which was essential for the user experience I wanted.

Kiro helped by:

• Reading the GPUI source code to understand patterns
• Suggesting Entity/View separation based on GPUI’s ownership model
• Generating boilerplate that matched GPUI’s conventions

But when the AI suggested patterns that didn’t fit GPUI’s model, I recognized it and corrected course.

Decision 2: Async-First Architecture

The core philosophy: The UI must never wait for the file system.

This wasn’t the AI’s idea—it came from my experience with file managers that freeze when opening large directories. I knew we needed:

• Background threads for I/O
• Channels for communication
• Batched updates to prevent render thrashing
• Generational IDs to discard stale results

┌─────────────────────────────────────────────────────────┐
│                    Main Thread (UI)                      │
│  ┌─────────┐  ┌──────────┐  ┌─────────┐  ┌──────────┐  │
│  │Workspace│  │ FileList │  │ Sidebar │  │ Preview  │  │
│  └────┬────┘  └────┬─────┘  └────┬────┘  └────┬─────┘  │
└───────┼────────────┼─────────────┼────────────┼─────────┘
│            │             │            │
└────────────┴─────────────┴────────────┘
│ async channels
┌─────────────────────────┼───────────────────────────────┐
│              Background Executor (GPUI)                  │
└─────────────────────────┼───────────────────────────────┘
│ spawn_blocking
┌─────────────────────────┼───────────────────────────────┐
│                 Tokio Thread Pool                        │
│  ┌─────────┐  ┌──────────┐  ┌─────────┐  ┌──────────┐  │
│  │ jwalk   │  │  notify  │  │  icons  │  │  search  │  │
│  └─────────┘  └──────────┘  └─────────┘  └──────────┘  │
└─────────────────────────────────────────────────────────┘

Decision 3: Steering Files for Consistency

I set up steering rules in .kiro/steering/ to maintain consistency:

# attention.md
- No unnecessary line comments
- Read files before making changes
- Always check gpui and adabaraka folders for component patterns
- Write clean, testable, maintainable code

These rules persisted across sessions, ensuring the AI maintained code quality standards that I defined.

Building the Core

With architecture defined, I started building. The conversation flow looked like:

Me: "Let’s implement the FileSystem model with LRU caching and generational request tracking"

Kiro: Generates implementation

Me: Reviews "The cache eviction isn’t considering modification time. When a directory changes on disk, we need to invalidate."

Kiro: Updates implementation with mtime tracking

This back-and-forth was constant. The AI accelerated implementation, but I was always reviewing, always steering.

Day 2: Features and Polish

The Terminal Integration

One feature I’m particularly proud of: each tab maintains its own terminal instance, and the terminal automatically follows your folder navigation.

Me: "When I navigate to a folder, the terminal should cd there automatically"

Kiro: Implements initial version

Me: "It’s not updating when I use the back button"

Kiro: Fixes navigation handlers

Me: "Each tab should have its own terminal state"

Kiro: Refactors to HashMap

This iterative refinement is the heart of vibe coding. I knew what I wanted; the AI helped me get there faster.

Smart Folders

I wanted saved searches that act like virtual folders. The implementation required:

• A query builder UI
• Persistent storage
• Real-time filtering

The AI generated the SmartFolderDialog component, but I specified the query options based on what power users actually need: text patterns, file types, date ranges, size filters.

Theme System

Supporting light and dark modes meant building a proper theme system:

pub struct ThemeColors {
pub bg_primary: Rgba,
pub bg_secondary: Rgba,
pub text_primary: Rgba,
pub accent_primary: Rgba,
// ... 20+ color tokens
}

Every component uses theme_colors() instead of hardcoded values. This was an architectural decision I made early—the AI just helped implement it consistently across 86 files.

The Numbers (Verified)

By the end of 48 hours:

Metric	Count
Rust source files	86
Lines of code	47,290
Passing tests	558
Platform targets	3 (macOS, Windows, Linux)

Performance

GPUI provides GPU-accelerated rendering, which means:

• Smooth scrolling through large directories
• Instant theme switching
• Responsive UI even during heavy I/O

The exact frame rate depends on your hardware and display, but the architecture ensures the UI thread is never blocked by file system operations.

Feature List

• GPU-accelerated rendering via GPUI
• Parallel directory traversal with jwalk
• Fuzzy search powered by nucleo
• Multiple view modes (List, Grid, Column, Dual-Pane)
• Quick Look preview
• Integrated terminal with per-tab state
• Smart Folders (saved searches)
• Tags and Favorites
• Tabs and multi-window support
• Light and dark themes
• File operations (copy, move, delete, rename)
• Trash integration
• Network storage support
• Device monitoring

Lessons Learned

1. Research Before You Build

The most important work happened before I wrote any code. Understanding GPUI, async Rust, and file system performance let me make informed decisions and catch AI mistakes.

If you can’t evaluate the AI’s output, you can’t use it effectively.

2. Requirements Come From You

The AI didn’t know I needed:

• Sub-16ms response times
• Generational request tracking
• LRU caching with mtime invalidation
• Per-tab terminal state

These requirements came from understanding the problem domain. The AI helped implement them, but the vision was mine.

3. Specs Are Essential

The upfront investment in requirements and design documents paid off enormously. When I said "implement the tab system per the spec," Kiro understood the full context.

4. Steering Maintains Quality

Without steering rules, AI-generated code can drift in style and quality. The .kiro/steering/ files kept everything consistent across 47,000+ lines of code.

5. Iterate, Don’t Dictate

The best results came from describing intent and iterating:

• "The terminal should follow folder navigation" → initial implementation
• "It’s not updating when I use the back button" → fix navigation handlers
• "Each tab should have its own terminal" → refactor to HashMap

6. Trust but Verify

AI accelerates development, but you still need to:

• Review generated code for correctness
• Run tests frequently
• Check edge cases
• Understand what’s being built

I caught several issues where the AI’s implementation didn’t match the architecture I had in mind. Without domain knowledge, those bugs would have shipped.

The Human-AI Partnership

Here’s what I want you to take away: AI didn’t build this project. I did, with AI assistance.

The AI didn’t:

• Choose the tech stack
• Design the architecture
• Define the requirements
• Make performance tradeoffs
• Decide what features mattered

I did all of that. The AI helped me implement it faster than I could have alone.

This is the future of software development: humans providing vision, judgment, and domain expertise; AI providing velocity and breadth. Together, we built something that would have taken a team weeks to accomplish.

But it only works if you know what you’re building.

What’s Next

Nexus Explorer is open source and actively developed. Planned features include:

• Windows NTFS USN Journal for instant search
• Linux io_uring for maximum I/O throughput
• Cloud storage integration even though we have icloud locally ready on macOs

Why I’m Now a Kiro Convert

Before this hackathon, I was skeptical of AI coding assistants. They felt like autocomplete on steroids—useful for boilerplate, but not for real engineering.

Kiro changed my mind.

The difference is structure. Other tools give you a chat window and hope for the best. Kiro gives you:

• Specs that the AI actually follows
• Steering rules that maintain consistency across sessions
• Context awareness that understands your project’s architecture

When I wrote requirements like "the UI must never block on file system operations," Kiro didn’t just acknowledge it—it applied that principle across every feature we built together. When I defined steering rules about code style, those rules persisted through 47,000 lines of code.

It felt less like using a tool and more like directing a capable junior developer who never gets tired, never forgets context, and types at superhuman speed.

After this hackathon, Kiro is my daily driver. Not because AI writes better code than me—it doesn’t. But because the combination of my expertise and Kiro’s velocity produces results neither could achieve alone.

Conclusion

Building Nexus Explorer in 48 hours required two things: deep understanding of the problem domain, and AI tools that could keep up with my vision.

Kiro IDE and vibe coding didn’t replace engineering—they amplified it. Every architectural decision, every requirement, every tradeoff came from me. The AI just helped me move faster.

The structured approach—requirements, design, tasks—meant I wasn’t just prompting an AI. I was leading a project with AI as my implementation partner. That’s a fundamentally different experience, and it’s why I’ll keep using Kiro long after this hackathon ends.

The code is open source. The approach is reproducible. But the most important ingredient isn’t the AI—it’s knowing what you want to build and why. Kiro just makes it possible to build it faster than you ever thought possible.

---

Nexus Explorer is available on GitHub. Built with Rust, GPUI, and Kiro IDE.