DEV Community: wong2 kim

I tried to vibe code on Windows. It broke me. So I built my own terminal.

wong2 kim — Wed, 25 Mar 2026 14:33:56 +0000

Every AI coding setup I saw online looked the same: Mac, tmux, agents running in split panes, everything humming along perfectly.

I was on Windows. It did not hum.

The tmux wall

tmux is the backbone of serious AI agent workflows. Persistent sessions, split panes, detach and reattach while your agents keep running.

On Windows, native tmux doesn't exist.

Fine — I'll use WSL.

WSL: close enough to break everything

WSL feels like Linux. For about 20 minutes, you think you've solved the problem.

Then the path issues start.

Windows sees: C:\Users\wooyoung\projects\wmux
WSL sees: /mnt/c/Users/wooyoung/projects/wmux

Same folder. Completely different contexts. AI agents write files into WSL. Your Windows-side editor can't find them. Your git is on the Windows side. Your dev server is on the Windows side. Your agent is happily working in a parallel universe.

The worst part: it works — until it doesn't. You're 40 minutes into a session before realizing your agent has been operating in the wrong dimension the entire time.

Port forwarding breaks hot reload. The agent hits localhost:3000, gets nothing, concludes the code is broken, and starts "fixing" code that was never broken.

You end up debugging a WSL networking quirk disguised as a React error.

Multi-agent made it dramatically worse

One agent is manageable. But real vibe coding in 2025 means an orchestrator, subagents, parallel tasks.

My setup: 6 terminal windows, 3 WSL instances, no way to tell which agent was doing what. One agent had gone completely silent — was it done? Crashed? Thinking?

I kept a Notepad file open just to track which terminal was which.

Then one Tuesday evening, I had three agents running in parallel. I wanted to check on one of them. Found it after clicking through four windows. It had been waiting for my input for 45 minutes. The other two had moved on — and built conflicting code against each other.

I closed everything. Went to bed. The next morning I started writing a PRD for Wmux.

What I built

Wmux is a Windows-native AI agent terminal. The problems I kept hitting are treated as first-class design constraints, not edge cases.

No WSL dependency. One filesystem context. No boundary crossings, no silent failures from agents writing to the wrong place.

All agents in one view. Every session visible in a single window. Status, last output, whether it's waiting — at a glance. Ctrl+D to split, Ctrl+N for a new workspace.

Browser automation built in. Claude Code can open a browser, click, fill forms, take screenshots — all via CDP. Not a workaround. A first-class feature.

Notifications that actually work. Output throughput-based detection: when your agent finishes, you get a desktop notification. No more staring at a terminal wondering if it's done.

Session persistence. Close Wmux, reopen it — your sessions are still there, scrollback intact. Like tmux. On Windows.

Why this matters

The corporate world runs Windows. The non-CS engineers I'm trying to get into AI coding run Windows. The developers who are just now discovering multi-agent workflows — a lot of them are on Windows.

The tooling just hasn't caught up. Mac users have cmux. Windows users have... friction.

If you want real multi-agent AI coding on Windows today, you either accept constant pain, or you build the environment yourself.

I chose to build.

v2.2.0 is out. Install in 30 seconds:

irm https://raw.githubusercontent.com/openwong2kim/wmux/main/install.ps1 | iex

Follow the build: github.com/openwong2kim/wmux

Previously: From engineering floor to App Store
Next: I deployed AI to 200 factory engineers. Here's what actually happened.

From Engineering Floor to App Store: What 10 Years as a Manufacturing Engineer Taught Me About Building Software

wong2 kim — Tue, 24 Mar 2026 03:37:45 +0000

No CS degree. No bootcamp. Just 10 years on factory floors and a stubborn belief that the software I needed should actually exist.

Here's how AI tools helped me make the jump — and 5 lessons from manufacturing that turned out to be my biggest advantage.

From Factory Floors to the App Store

I spent a decade in manufacturing engineering. Process optimization, quality control, equipment troubleshooting — the kind of work where every minute of downtime costs real money.

The whole time, I had one recurring frustration: the software tools I needed were terrible. Clunky tracking systems. Overpriced dashboards. Apps that felt like they were designed by people who had never touched a production line.

So I tried to learn to code. Multiple times. Tutorials, online courses, side projects. Every attempt hit the same wall — not because I couldn't think logically, but because the jump from "hello world" to a working product felt impossibly wide.

Then AI coding tools changed everything.

Why AI Was the Missing Piece

AI didn't teach me computer science. It did something better — it met me where I was.

Suddenly I could focus on what I was already good at:

Defining the problem clearly — engineering trained me for this
Breaking it into components — process engineering is literally this
Iterating fast — prototype, test, improve, repeat (factory mindset)

AI handled the syntax. I handled the thinking.

Within months, I shipped my first iOS app. Then another. And another.

What I'm Building Right Now

Pregnancy & Parenting App Suite — My wife and I couldn't find an app that wasn't riddled with ads or missing features. So I built one.
Enterprise AI Platform — RAG chatbot + auto-generated presentations for enterprise adoption. My manufacturing background directly applies here.
Markdown Note App — Notes for iOS with iCloud sync and on-device AI. Every note app was either too simple or too complex.
ADHD-Friendly Task Planner — Eisenhower Matrix meets Pomodoro timer. Built for brains that work differently.
AI Coding Terminal — Windows-native terminal with multi-agent control. The tool I wish I had when I started.

5 Lessons Manufacturing Taught Me About Software

1. Nobody cares about your architecture.

On the factory floor, nobody cares how elegant your process flow diagram is. They care if the product comes out right. Same with apps — solve the problem, and nobody asks if you used MVVM or MVC.

2. Ship first. Optimize later.

We had a saying: "Don't let perfect be the enemy of good enough for Tuesday's shipment." Get it working, get it in front of users, then iterate.

3. Constraints breed creativity.

Tight budgets. Broken equipment. Real deadlines. Manufacturing forces you to find creative solutions — and that's exactly what indie dev demands when you're the designer, developer, tester, and marketer all at once.

4. Ask "why" five times.

Toyota's "5 Whys" technique is the best debugging framework I've ever used. Don't fix the symptom. Keep digging until you find the root cause.

5. Domain knowledge is your superpower.

No CS grad knows what a manufacturing engineer needs from a monitoring tool. No bootcamp teaches what an expecting parent wants from a pregnancy app at 3 AM. Your non-tech experience isn't a weakness — it's the unfair advantage that helps you build things people actually want.

My Stack

Category	Tools
Mobile	Swift, SwiftUI
Web	React, Next.js, Tailwind CSS
AI/ML	Python, LangGraph, LLM APIs
Infra	Docker, Supabase, Local AI Server

The Honest Truth

AI didn't make me a software engineer. It made me a software builder.

I still don't know half of what a CS grad knows about algorithms. But I can identify a real problem, design a solution, and ship a product that people use. That's enough to build meaningful things.

If you're sitting on deep domain expertise in a non-tech field — healthcare, education, construction, whatever — the barriers have never been lower. You don't need a degree. You need a problem worth solving and the will to ship.

I'm new to DEV and writing about AI-assisted development from a non-CS perspective. If this resonates, I'd love to hear your story.

What did your "before" look like?