Whiteboard คือแอปที่ให้ AI เขียนโค้ดอย่าง Claude Code หรือ Codex วาดแผนภาพอธิบายงานที่มันเพิ่งทำ ก่อนที่เราจะกด merge ซึ่งเป็นขั้นตอนรวมโค้ดเข้าโปรเจกต์

ลองนึกภาพเวลาเราสั่งงานผู้ช่วยอัตโนมัติอย่าง agent ไปชิ้นหนึ่ง แล้วมันลงมือแก้โค้ดรวดเดียวหลายสิบไฟล์ หน้าต่าง diff ซึ่งแสดงส่วนต่างโค้ดที่เปลี่ยนแปลงก็ยาวเหยียดจนเลื่อนอ่านไม่ทัน ช่วงไฟล์แรกๆ เรายังพอตรวจละเอียดได้ แต่พอถึงไฟล์กลางๆ ก็เริ่มตาลายจนต้องกดปล่อยผ่าน สุดท้ายเราก็ merge โค้ดทั้งก้อนเข้าโปรเจกต์ไปทั้งที่ยังไม่เข้าใจดีพอ

Whiteboard เป็นผลงานของทีม /dev/fast กลุ่มเพื่อนสมัยมหาวิทยาลัย 4 คนที่ลาออกจากตำแหน่ง Tech Lead มาทำสตาร์ตอัปด้วยกัน โดยตอนนี้พวกเขาอยู่ในโครงการบ่มเพาะสตาร์ตอัปชื่อดังอย่าง Y Combinator รุ่น W26

ในโพสต์เปิดตัวบน Hacker News ซึ่งเป็นเว็บบอร์ดของคนสายเทคโนโลยี พวกเขาเล่าว่า ตอนใช้ agent เร่งทำระบบเวอร์ชันแรกของโปรเจกต์ก่อนหน้า งานเดินหน้าเร็วขึ้นจริง แต่ Pull Request หรือคำขอรวมโค้ดที่กด merge ไปโดยไม่ได้เข้าใจก็พอกพูนขึ้นเรื่อยๆ จนแม้แต่จะกลับมาแก้ระบบของตัวเองก็ยังยาก พวกเขาเรียกปัญหานี้ว่า Cognitive Debt หรือหนี้ความเข้าใจ

ปัญหาที่ว่าทำไมขั้นตอนตรวจโค้ดอย่าง code review ถึงกลายเป็นคอขวดใหม่ เราเคยเล่าไปแล้ว และ Whiteboard ก็คือเครื่องมือที่ทีมนี้สร้างขึ้นมาใช้เองเพื่อแก้ปัญหานั้น ถ้าคุณใช้ agent ทำงานทุกวันหรือต้องคอยตรวจโค้ดที่ AI เขียน นี่คือเครื่องมือที่เข้ามาช่วยปิดช่องโหว่ตรงจุดที่เรามักเผลอปล่อยผ่านไป

Whiteboard ให้ agent วาดอธิบายงานของตัวเอง

README ซึ่งเป็นหน้าเอกสารแนะนำโปรเจกต์บน GitHub ระบุว่า Whiteboard เป็นแอปเดสก์ท็อปโอเพนซอร์สที่คนกับ agent ใช้ออกแบบซอฟต์แวร์ร่วมกันในพื้นที่เดียว แอปนี้ไม่ได้มาแทน agent ที่เราใช้อยู่ แต่เชื่อมต่อเข้ากับ Claude Code หรือ Codex ตัวเดิม แล้วเพิ่มเครื่องมือให้ agent วาดลงบนกระดานได้ พอเราถามถึงงานที่มันทำ agent ก็จะวาดแผนภาพอธิบายขึ้นบนกระดานนั้นทันที

ลองนึกถึงการยืนคุยหน้าไวท์บอร์ดจริงกับเพื่อนร่วมทีม เพื่อนค่อยๆ วาดลูกศรให้ดูว่าข้อมูลวิ่งจากไหนไปไหน พอคุยเสร็จเดินออกจากห้อง เราก็เข้าใจระบบนั้นเป็นอย่างดี ทีมผู้สร้างบอกว่าพวกเขาคิดถึงบรรยากาศการยืนคุยหน้ากระดานอย่าง whiteboard session แบบนี้ จึงทำแอปนี้ขึ้นมาใช้เอง

จุดสำคัญที่ต้องเข้าใจคือ Whiteboard เป็นพื้นที่สำหรับ "อ่าน" ไม่ใช่สำหรับ "เขียน" โค้ด ทีมเล่าว่าทุกวันนี้พวกเขาปล่อยให้ agent ทำงานในหน้าต่างของมันเอง แล้วเปิด code editor หรือโปรแกรมแก้ไขโค้ดไว้แค่ตรวจ diff ทีละบรรทัด พวกเขาจึงตั้งใจทำ editor สำหรับตรวจโค้ดโดยเฉพาะขึ้นมา ส่วนการเขียนโค้ดยังปล่อยให้เป็นหน้าที่ของ agent ตัวเดิม

สิ่งที่ทำให้ Whiteboard ต่างจากการนั่งเพ่ง diff ปกติมีอยู่ 3 เรื่อง คือ แผนภาพที่คลิกแล้วพาไปดูโค้ดจริง, diff ที่อ่านโครงสร้างโค้ดออก และ Decision Log ที่บันทึกว่า agent ตัดสินใจอะไรไปเองบ้าง

คลิกแผนภาพแล้วพาไปดูโค้ดจริง

เรื่องแรกคือแผนภาพบนกระดานคลิกได้ agent วาดแผนภาพได้หลายแบบ เช่น Sequence Diagram ที่ไล่ลำดับการทำงานให้เห็นว่าโค้ดส่วนไหนเรียกใช้ส่วนไหน, ER Diagram ที่แสดงความสัมพันธ์ระหว่างตารางข้อมูล หรือจะดึงข้อความมาจาก trace ซึ่งเป็นบันทึกขั้นตอนการทำงานก็ได้ ไม่ว่าจะคลิกที่จุดไหน แอปก็จะเปิดไฟล์โค้ดส่วนที่เกี่ยวข้องให้ทันที

ถ้าเทียบกับการคุยหน้ากระดานจริง นี่ก็เหมือนจังหวะที่เราชี้ไปที่ลูกศรเส้นหนึ่งแล้วถามว่า "ตรงนี้อยู่ในโค้ดส่วนไหน" เพื่อนก็เปิดโค้ดบรรทัดนั้นให้ดูทันที

ทีมพัฒนา Whiteboard เวอร์ชันแรกด้วย HTML ล้วน แต่พบว่าผูกแผนภาพเข้ากับโค้ดจริงได้ยาก ปัญหานี้สำคัญมาก เพราะข้อดีข้อเสียของการออกแบบมักจะโผล่มาให้เห็นหลังจากลงมือเขียนโค้ดรอบแรกไปแล้ว การสลับไปมาระหว่างแผนภาพกับโค้ดจึงต้องทำได้ง่ายและราบรื่น

ทีมจึงตัดสินใจสร้าง Whiteboard ขึ้นบน Code OSS ซึ่งเป็นแกนโอเพนซอร์สของโปรแกรมเขียนโค้ดยอดนิยมอย่าง VS Code ทำให้เราใช้คีย์ลัดชุดเดียวกับ VS Code ได้เลย และยังกด jump to definition ไปดูจุดประกาศฟังก์ชันได้ผ่านระบบ LSP แบบเดียวกับที่ VS Code ใช้อีกด้วย

diff ที่ย่อฟังก์ชันยาวเป็น pseudocode

เรื่องที่สองคือหน้า diff ของ Whiteboard ที่ทีมเขียนขึ้นมาใหม่ด้วยภาษา Rust ปกติแล้ว diff ทั่วไปจะแสดงทุกบรรทัดที่เปลี่ยนแปลงเหมือนกันหมด ทั้งโค้ดหลัก เทสต์ และเอกสาร แต่ diff ตัวใหม่นี้อ่านโค้ดเป็นโครงสร้าง มันจึงรู้ว่าตรงไหนเป็นฟังก์ชันใหม่ และตรงไหนเป็นเทสต์ แล้วเลือกแสดงเฉพาะส่วนสำคัญที่เราควรอ่าน

ค่าเริ่มต้นของแอปมีอยู่ 2 อย่าง อย่างแรกคือ แอปจะย่อฟังก์ชันใหม่ที่ยาวให้เหลือ pseudocode หรือโค้ดฉบับย่อที่เขียนเป็นภาษาคนอ่าน ทำให้โค้ดยาวหลายสิบบรรทัดเหลือเพียงไม่กี่บรรทัดที่อ่านเข้าใจง่าย สรุปให้เห็นว่าฟังก์ชันนี้รับค่าอะไร ตรวจสอบอะไร และส่งอะไรกลับ อย่างที่สองคือ โค้ดเทสต์และการแก้ไขเอกสารจะพับเก็บไว้ก่อน เพื่อไม่ให้รกสายตา

อย่างไรก็ตาม การตั้งค่าเริ่มต้นแบบนี้ก็มีสิ่งที่ต้องแลกมา เพราะเทสต์ที่พับไว้คือส่วนที่เราจะมองไม่เห็นในตอนแรก ถ้างานชิ้นไหนจำเป็นต้องตรวจเทสต์อย่างละเอียด เราก็ต้องกดเปิดดูเอง หรือปรับแต่งการตั้งค่าผ่านระบบปลั๊กอินที่ทีมเปิดให้แก้ได้ทั้งหมด ส่วนเอนจินที่ใช้เปรียบเทียบโค้ด ทีมงานได้แยกออกมาเป็นโปรเจกต์โอเพนซอร์สอีกตัวชื่อ diffr

Decision Log บอกว่า agent ตัดสินใจอะไรไปเอง

เรื่องที่สามช่วยตอบคำถามที่ diff ทั่วไปตอบไม่ได้ ทีมเล่าว่าเวลา agent ทำงาน พวกเขาตามความคิดของ agent ไม่ค่อยทันว่ามันตัดสินใจอะไรไปเองบ้าง และการตัดสินใจเหล่านั้นส่งผลต่องานอย่างไร ทีมจึงสร้างฟีเจอร์ที่ให้ agent ค้น trace ของตัวเอง แล้วนำมาลิงก์ไว้บนกระดาน ซึ่งทีมเรียกว่า Decision Log

บนกระดานเราจึงเห็นข้อมูล 2 ด้านคู่กัน คือความต้องการที่เราสั่งกลายเป็นโค้ดแบบไหน กับการตัดสินใจข้อไหนบ้างที่ agent ทำไปเองโดยไม่ได้ถามเรา

ลองนึกภาพว่าเราสั่งแค่ให้เพิ่มช่องค้นหา แต่ระหว่างทาง agent กลับเปลี่ยนวิธีเก็บข้อมูลไปด้วย ถ้าดูแค่ใน diff การเปลี่ยนแปลงนี้จะปนอยู่กับโค้ดบรรทัดอื่นจนสังเกตได้ยาก แต่ถ้า agent ลิงก์ trace ช่วงนั้นไว้บนกระดาน เราจะเห็นทันทีว่าตรงนี้มันเลือกเอง และคลิกเข้าไปดูโค้ดจุดนั้นได้เลย

ถ้าไม่มีส่วนนี้ การตัดสินใจของ agent ก็จะค่อยๆ แทรกเข้าไปอยู่ในระบบเงียบๆ ทีละข้อ จนวันหนึ่งกลายเป็นโค้ดส่วนที่ไม่มีใครอธิบายได้ว่ามีไว้ทำไม ซึ่งก็คือปัญหาหนี้ความเข้าใจที่ทีมผู้สร้างเจอมากับตัวนั่นเอง

เริ่มจาก branch ที่ agent เพิ่งทำเสร็จ

README แนะนำให้เริ่มจาก branch ที่ agent เพิ่งแก้โค้ดเสร็จ โดยมี 3 ขั้นตอนง่ายๆ:

1. ดาวน์โหลดแอปจากเว็บของ Whiteboard แล้วเปิดขึ้นมา
2. เชื่อมต่อ Claude Code, Codex หรือ agent ตัวอื่นจากหน้าแรกของแอป
3. สั่ง agent ให้รีวิว branch ปัจจุบันเทียบกับ main หรือโค้ดหลักเวอร์ชันล่าสุด แล้วเปิดผลลัพธ์ใน Whiteboard

ในขั้นตอนที่ 3 เราพิมพ์สั่ง agent ได้ง่ายๆ ประมาณนี้:

รีวิว branch ปัจจุบันเทียบกับ main ล่าสุด แล้วเปิดผลใน Whiteboard

นอกจากนี้ README ยังมีตัวอย่างพรอมต์สำหรับงานที่มีการเปลี่ยน API ซึ่งเป็นช่องทางเชื่อมต่อระหว่างระบบ พรอมต์นี้จะขอให้ agent แสดงข้อมูลสำคัญ 3 อย่างก่อน คือ หน้าตาของ API ที่เสนอ, ตัวอย่างการเรียกใช้ และเหตุผลที่ต้องเปลี่ยน จากนั้นค่อยลงรายละเอียดว่าโค้ดเขียนอย่างไรและทำงานอย่างไร:

hey, this stack of commits is set up so i can get an [api] to do [objective]
i'd like to see:
- proposed api
- examples
- motivations for this (if available to you in context/in the repo)
and then we can dive into implementation + explaining how things worked.

เวลาใช้งาน ให้แทนที่ [api] ด้วยชื่อ API ที่แก้ไข และแทน [objective] ด้วยเป้าหมายของงาน ข้อดีของการสรุปแบบนี้คือ ถ้าหน้าตา API ออกแบบมาผิดทิศทางตั้งแต่แรก เราจะรู้ตัวทันทีก่อนที่จะเสียเวลาไปไล่อ่านโค้ด

ถ้าไม่ชอบส่วนไหนที่ agent วาดมา ก็แค่ไฮไลต์ข้อความตรงนั้น คัดลอกส่งกลับไปให้ agent แล้วมันจะวาดกระดานใหม่ให้ตรงกับที่เราต้องการ

สำหรับโมเดล AI ทีมงานแนะนำจากประสบการณ์ที่ใช้จริงว่า Whiteboard ทำงานได้ดีที่สุดกับโมเดลอย่าง GPT-6 Sol และ Claude Opus 5.5 เพราะได้ทั้งความฉลาด ค่าใช้จ่าย และความเร็วที่สมดุลกัน ถ้าอยากเห็นหน้าตาการทำงานก่อนติดตั้ง ทางทีมก็มีคลิปเดโมราวหนึ่งนาทีให้ดูด้วย

รีวิวงาน agent ตัวเอง กับรีวิวงานคนอื่น

ทีมผู้สร้างเล่าว่า ปัจจุบันมีคนในบริษัทอย่าง Salesforce และ Modal ใช้ Whiteboard รีวิวโค้ดที่เปลี่ยนแปลงระดับสถาปัตยกรรมหรือสเปกระบบ ซึ่งเป็นงานสำคัญที่คนรีวิวอยากลงมือตรวจด้วยตัวเอง ทีมแบ่งจังหวะการใช้งานไว้ 2 รูปแบบ:

จังหวะแรกคือ ใช้รีวิวงานของ agent ตัวเองก่อนกด merge โดยสั่งให้ agent ทำตัวต้นแบบขึ้นมา พร้อมกับสร้าง Whiteboard session ควบคู่กันไป จากนั้นเราค่อยปรับแก้การออกแบบตามสิ่งที่เห็นบนกระดาน

จังหวะที่สองคือ ใช้รีวิวงานของคนอื่น ทีมบอกว่ามันเข้ากันได้ดีมากกับเครื่องมือรีวิวโค้ดอัตโนมัติอย่าง Greptile โดยงานชิ้นเล็กๆ ก็ปล่อยให้ตัวรีวิวอัตโนมัติตรวจไป ส่วนงานสำคัญที่ต้องใช้วิจารณญาณของคน ค่อยเปิดเป็น Whiteboard session ขึ้นมาดูร่วมกัน

แน่นอนว่างานแบบไหนนับเป็นงานเล็ก เป็นเกณฑ์ที่เราต้องกำหนดเอง ถ้าตั้งเกณฑ์เข้มไป แม้แต่งานแก้คำผิดก็ต้องมาเปิดกระดานให้เสียเวลา แต่ถ้าตั้งเกณฑ์หลวมไป งานที่เปลี่ยนโครงสร้างระบบก็อาจหลุดรอดไปได้โดยมีแค่ตัวรีวิวอัตโนมัติตรวจเท่านั้น

ข้อจำกัดที่ต้องรู้ก่อนโหลด

ปัจจุบัน Whiteboard ยังติดป้ายสถานะทดสอบอย่าง beta อยู่บนหน้าเว็บ และมีข้อจำกัดที่ทีมงานบอกไว้ตรงๆ ใน README ดังนี้:

• ยังไม่รองรับ Windows: ตอนนี้ดาวน์โหลดได้เฉพาะ macOS และ Linux รุ่น Fedora เท่านั้น ส่วนเวอร์ชัน Windows ทีมงานตอบในกระทู้ว่าอยู่ในแผนแล้ว
• แก้ไขไฟล์ในแอปไม่ได้: การแก้โค้ดยังต้องทำผ่าน agent หรือ code editor ตัวเดิมของเรา หลังจากมีคนทักเรื่องนี้ในกระทู้ ทีมงานจึงเปลี่ยนคำเรียกโปรดักต์บน GitHub และหน้าเว็บ จาก IDE ที่เป็นโปรแกรมพัฒนาครบวงจร มาเป็น canvas แทน ถ้าเห็นคำว่า IDE ในชื่อโพสต์เปิดตัวเดิมก็หมายถึงตัวเดียวกัน
• ยังตรวจหลาย repository พร้อมกันได้ไม่ดี: repository หรือที่เรียกสั้นๆ ว่า repo คือคลังเก็บโค้ด ถ้างานชิ้นไหนแก้โค้ดข้ามหลาย repo การเปิดไล่ตรวจไฟล์ทั้งหมดในรีวิวเดียวยังทำได้ไม่ราบรื่นนัก
• แชร์แล้วไม่อัปเดตตาม: เรากดแชร์รีวิวให้อีกเครื่องได้ แต่ถ้ามีการแก้ไขเพิ่มเติมหลังจากแชร์ อีกฝั่งจะไม่เห็นการเปลี่ยนแปลง ต้องกดแชร์ใหม่อีกรอบ

แอปฟรี แล้วข้อมูลไปไหน

ตัวแอปเดสก์ท็อปเป็นโอเพนซอร์สภายใต้ MIT License ซึ่งเปิดให้ใครก็นำไปใช้งาน แก้ไข หรือแจกจ่ายต่อได้อย่างอิสระ และแอปทำงานกับโค้ดในเครื่องของเราเองทั้งหมด

ส่วน Telemetry คือข้อมูลการใช้งานแบบไม่ระบุตัวตนที่แอปส่งกลับไปให้ทีม ข้อมูลนี้ไม่มีโค้ด, diff, ข้อความบนกระดาน, พรอมต์ หรือคำตอบของโมเดล และเลือกปิดได้ตลอดเวลา สมาชิกทีมชี้แจงในกระทู้ว่า ข้อมูลใน repo จะไปถึงทีมงานก็ต่อเมื่อเรากดยินยอมส่งเองตอนรายงานบั๊ก หรือตอนกดแชร์ Whiteboard session ออกไปเท่านั้น

เรื่องการหารายได้ ทีมวางแผนจะเก็บเงินจากกลุ่มลูกค้าองค์กรผ่านเวอร์ชันเว็บแบบ hosted ที่ทีมดูแลเซิร์ฟเวอร์ให้ โดยจะมีฟีเจอร์อย่างการจัดการ session, การเก็บประวัติการทำงานของ agent และการรีวิวโค้ดพร้อมกันหลายคน แต่ทีมก็ย้ำว่าทุกฟีเจอร์จะเปิดให้เรานำไป self-host บนเซิร์ฟเวอร์ของตัวเองได้เสมอ

ครั้งหน้าก่อนกด merge

ครั้งต่อไปที่ agent ทำงานชิ้นใหญ่เสร็จ อย่าเพิ่งรีบกด merge ลองสั่งให้มันอธิบายสิ่งที่เพิ่งทำบน Whiteboard แล้วไล่ดูแผนภาพให้เห็นภาพรวม คลิกลงไปดูโค้ดตรงจุดที่ไม่แน่ใจ และเปิดดู Decision Log ว่ามันตัดสินใจอะไรไปเองบ้าง

เข้าใจโค้ดให้ดีก่อนกด merge และเข้าใจการทำงานทั้งหมดก่อนปล่อยขึ้นใช้งานจริง ส่วนขั้นตอนการพาแอปขึ้นเว็บจริง เราเคยเล่าไว้แล้วในบทความเรื่องเครื่องมือปล่อยระบบอย่าง golive-skill

เพราะช่วงเวลาที่เราทำความเข้าใจโค้ดชิ้นหนึ่งได้ง่ายที่สุด คือตอนที่มันยังแยกอยู่ใน branch ของมันเอง ก่อนที่มันจะ merge เข้าไปพันกับโค้ดส่วนอื่นทั้งระบบ

ที่มา:

• บทความ devdotfast/whiteboard: open-source canvas for thoughtful software design จาก /dev/fast
• บทความ Whiteboard by /dev/fast — The canvas for thoughtful software จาก /dev/fast
• บทความ Show HN: Whiteboard (YC W26) – An open-source IDE for thoughtful software design จาก Hacker News