Humans Are Always the Bottleneck Skip to main content Hashnode kdy1: The way I think Open search (press Control or Command and K) Toggle theme Open menu Hashnode kdy1: The way I think Open search (press Control or Command and K) Toggle theme Write Command Palette Search for a command to run... Humans Are Always the Bottleneck How I Build Software with Labor0 and Codex Updated September 7, 2026 • 11 min read • View as Markdown D DongYun Kang Part of series Agentic coding On this page A day of AI-native development Finding 46 bugs with GPT 6 Astra AI reviews AI until it runs out of comments Why a human still has to look Small tasks are the foundation From six terminal sessions to more than fifty Routing models by cost and difficulty This workflow will change again Today, a single prompt turned 46 SWC issues into 45 pull requests. I do not know exactly how long it took. While the work was running, I was looking at my phone and playing games. By the time I checked, the work had already moved on without me. My name is kdy1. I created SWC, an open-source compiler project, and previously worked at Deno and Vercel. These days, I spend a lot of time building Labor0 , along with Watchtower and theaiplatform.app at Zephyr Cloud IO. My development workflow has changed dramatically over the past few years. I used to do nearly everything myself. Now, almost all of my development work involves Labor0 and Codex automatic review. I have one rule that shapes the entire process: Humans are always the bottleneck. Human-in-the-loop is still essential. Decisions must be made by a human, and I still review and merge pull requests myself. But I want the AI to drive the work and call me into the loop as few times as possible. When Labor0 encounters a decision, it can send me a question through something like a web push notification. Once I answer, it continues. When a PR is ready, I review and merge it, but Labor0 does not need to wait for me before starting the next independent task. A day of AI-native development On the day I wrote this, I worked on Labor0, Watchtower, and SWC, in that order. For Labor0, I wrote three PRDs: An automatic learning feature similar to Devin’s Knowledge system Voice controls for desktop and Apple Watch apps A large refactoring of Labor0’s messenger integration, so that status updates appear naturally inside the corresponding Slack or Discord thread I started implementing the messenger refactoring. The other two remain PRDs for now. I always use my Write PRD skill when writing a PRD. I use GPT 5.6 Sol for this work. The skill does not make decisions for me. I make every decision myself. What surprised me, though, is how few decisions I need to make relative to the size of the projects I run. The absolute number is not small because these projects are large, but it is still much lower than I would have expected. The skill turns PRD writing into a conversation. It identifies decisions that need to be made, and I resolve them. I saw this clearly while working on Watchtower, a Sentry-compatible error monitoring and observability system that I recently started building in public. Watchtower uses a spec-driven development process. While writing PRD #13 , I initially wanted to use Connect RPC because I prefer strongly typed systems. JSON over HTTP was recommended instead, so I spent a few rounds of conversation checking whether Connect had a serious limitation. It turned out that the main concern was Rust support for Protobuf and its surr