--- id: "lib-2026-10-14-team-development-in-the-ai-coding-era" type: "library" title: "Team development in the AI-coding era" title_original: "AI Coding 新時代的團隊開發：從一個人用 AI 到 AI Native 公司" lang: "ZH" org: "YC不只加速器 (HWDC 2026)" source_type: "Talk" date: "2026-10-14" week: "2026-W42" url: "https://nosov.ai/library/lib-2026-10-14-team-development-in-the-ai-coding-era/" original_url: "https://www.youtube.com/watch?v=-B9WLMJAiZM" tier: "B" tier_name: "Useful, limited" tier_reason: "First-hand keynote by YC Chen, founder of Noopher AI and former MediaTek Research technical manager, with a concrete spec failure and an open-source tool; one small start-up's experience, no measured outcomes beyond his own account." summary_basis: "transcript" original_minutes: "45" tags: ["business transformation", "spec driven development", "ai native org design"] --- # Team development in the AI-coding era Original title: AI Coding 新時代的團隊開發：從一個人用 AI 到 AI Native 公司 Tier B (Useful, limited): First-hand keynote by YC Chen, founder of Noopher AI and former MediaTek Research technical manager, with a concrete spec failure and an open-source tool; one small start-up's experience, no measured outcomes beyond his own account. Summary based on the full transcript. ## In short A keynote at iThome's Hello World Dev Conference 2026 (uploaded 14 October 2026) by YC Chen (陳宜昌), founder of Taiwanese start-up Noopher AI. He describes three levels of AI-assisted development: one person with AI, one person directing an agent team, and a company where a group of people works with a group of agents. The most useful parts are a documented failure of over-specification and an explicit split at Noopher between an all-AI execution team and a human decision team. ## Key numbers - 5,000+ lines: lines in the main spec the team spent a month writing; the generated code did not run even at module level - 1-2 days: time to get the whole system running after splitting it into three sub-modules with short specs - 3 people, 8 months: people and months to build the TASTE2 streaming voice system, which he says was impossible without AI coding - billion-level tokens: tokens spent in one month trying, and failing, to stabilise a kanban-driven agent team ## What it reports - Building TASTE2, a streaming spoken-dialogue model, the team spent a month writing a spec of more than 5,000 lines plus reference code. Generation ran for a long time and even the base modules did not work. - His diagnosis: the detail diluted the model's context. Splitting the system into three sub-modules plus an orchestrator, each with a short spec, produced a working sub-module within an hour one morning and a running system within one or two days. - His rule: a spec is scaffolding, to be taken down once code exists, because working code is a stronger and verifiable guide. - Noopher's process: humans agree the architecture; AI splits work into non-overlapping tickets; each ticket is aligned through a questioning skill that also writes a shared glossary (CONTEXT.md) and architecture decision records; specs live in GitHub issues and are closed after test-driven implementation. Review includes unit, integration, spec review and mutation testing. - Agent-team versions: v1 with Claude Code subagents was fast but pushed every question through one window; v2 with a kanban board added overhead for the agents and failed after a month of effort; v3, open-sourced as `oat-agents` (MIT), runs native Claude Code and Codex sessions with worktree isolation, per-agent token and cost display, and an assistant agent that reports status. - Org split: the execution team is all AI (implement, test, debug, review) and people write no code. People own decisions, understanding of the whole system, and exploration on prototypes. They lock three gates: verification method, interfaces and use cases. - Juniors lose the old path of editing one file a senior points to; they must understand the whole system from day one to direct agents. ## How they got it Personal experience from one research project and the first months of a start-up, plus a summary of public views from Matt Pocock, Boris Cherny, Simon Willison, DHH and Andrej Karpathy on specs versus prototypes and how much code to read. ## Limits - One team, no metrics beyond elapsed time and his own judgement; the 5,000-line failure is a single case. - He says the model may change once the company grows past the prototype stage. - The talk promotes his own open-source tool. ## Why it matters for companies The spec-size failure is a cheap lesson for any team adopting spec-driven agent work: shorter, module-level specs worked where one exhaustive document did not. The execution-versus-decision split gives a concrete role design to test, with clear human gates. The junior-development point matters for workforce planning: if the first job is directing agents, onboarding has to teach system understanding much earlier. ## Key passages in translation > 你不要把 spec 的地位 看成像是藍圖一樣 ... 而是你應該把 spec 當作鷹架 Do not treat the spec as a blueprint ... you should treat the spec as scaffolding. > 執行團隊呢完全是由 AI 來主控 負責實作 測試 除錯還有 review 人不寫程式碼 人只做決策 The execution team is run entirely by AI: implementation, testing, debugging and review. People write no code; people only make decisions. > AI Agent 只會做 不代表它會產生成果 做跟成果是兩件事情 That an AI agent can do the work does not mean it produces results. Doing and results are two different things. Original: https://www.youtube.com/watch?v=-B9WLMJAiZM