งานที่เมื่อก่อนต้องพัฒนาเป็นซอฟต์แวร์เต็มรูปแบบ วันนี้อาจใช้เพียงไฟล์ข้อความไฟล์เดียวก็ทำได้ Theo Browne ยกตัวอย่างนี้ขึ้นมาพูดในคีย์โน้ตปิดงานประชุม AI Engineer World's Fair 2026 ในทอล์กที่ชื่อว่า "ทุกอย่างที่เรารู้เกี่ยวกับการสร้างซอฟต์แวร์เปลี่ยนไปหมดแล้ว"

ตัวอย่างที่เขายกคือบริการเล็กๆ ที่ทำงานเองทุกเช้าเวลาเก้าโมง หัวใจของมันคือไฟล์ markdown ไฟล์เดียว หรือไฟล์ข้อความที่เราพิมพ์สั่งงานเป็นภาษาคนได้เลย เมื่อถึงเวลาที่ตั้งไว้ ระบบจะส่งไฟล์นี้ให้ AI อ่าน แล้ว AI ก็ทำตามคำสั่งในไฟล์ งานของ AI คือไล่เช็ก pull request หรือ PR (โค้ดที่รอรวมเข้าโปรเจกต์) ที่ค้างอยู่ใน 4 โปรเจกต์บนบริการเก็บโค้ดอย่าง GitHub จากนั้นประเมินว่าอันไหนควรรีบดูก่อน จัดลำดับความสำคัญ แล้วอัปเดตหน้าเว็บสรุปสถานะให้เสร็จราวเก้าโมงยี่สิบ งานแบบนี้เมื่อก่อนต้องเขียนซอฟต์แวร์ขึ้นมารองรับอย่างจริงจัง

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

สามยุคของโมเดล AI ที่เปลี่ยนวิธีเขียนโค้ด

เขาแบ่งพัฒนาการของโมเดล AI ในช่วงหลังออกเป็นสามยุคที่ต่างกันชัดเจน

เขาเรียกยุคแรกว่า ยุคที่โมเดลเรียกใช้เครื่องมือ โดยมี Sonnet 3.5 (โมเดล AI ตัวหนึ่งในตระกูล Claude) เป็นตัวแทน Sonnet 3.5 ไม่ใช่โมเดลแรกที่เรียกใช้เครื่องมืออื่นได้ แต่เป็นตัวแรกที่ทำงานนี้ได้สม่ำเสมอและน่าเชื่อถือพอจะนำมาใช้เขียนโค้ดจริงได้ทุกวัน

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

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

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

เรายังยึดติดกับเครื่องมือจากยุคก่อน AI

แล้วอะไรที่ยังฉุดรั้งเราไว้ เขาชี้ว่านักพัฒนายังยึดติดกับเครื่องมือหลายอย่างที่ออกแบบตามข้อจำกัดของยุคเก่า ทั้งที่วันนี้ไม่จำเป็นแล้ว

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

เขาบอกว่านักพัฒนาทุกวันนี้กำลังทำแบบเดียวกัน เรายังยึดเครื่องมือยุคเก่าที่ออกแบบมาในยุคที่มีแต่คนเป็นผู้ใช้งาน ตั้งแต่หน้าจอพิมพ์คำสั่งไปจนถึง Git (ระบบเก็บและซิงก์ประวัติการแก้โค้ดข้ามทีม) ทั้งที่ตอนนี้เริ่มมี AI เข้ามาทำงานร่วมด้วยแล้ว Git เป็นตัวอย่างที่เห็นภาพชัด ปกติทุกไฟล์ในโปรเจกต์จะซิงก์ได้ทั้งข้ามเครื่องและข้ามทีม ยกเว้นไฟล์ตั้งค่าอย่าง .env (ไฟล์เก็บค่าลับ เช่น รหัสผ่านหรือ key ต่างๆ) ที่แชร์กันได้ยากเป็นพิเศษ ปัญหานี้ยังอยู่เพราะความเคยชิน ไม่ใช่เพราะจำเป็นต้องเป็นแบบนั้น

อีกเรื่องที่เขาพูดถึงคือ นักพัฒนาชอบนิยามตัวเองด้วยภาษาโปรแกรมที่ใช้ เช่น การบอกว่าตัวเองเป็นคนเขียน JavaScript ราวกับภาษาที่ใช้เป็นเครื่องยืนยันความเก่ง เขาบอกว่าแม้แต่วิศวกรระดับซีเนียร์ก็ยังเป็นแบบนี้ แต่ในวันที่ AI เขียนได้แทบทุกภาษา การนิยามตัวเองว่าเชี่ยวชาญภาษาโปรแกรมตัวไหนก็เริ่มสำคัญน้อยลง

เรื่องที่ชัดที่สุดคือความไม่กล้าลบโค้ด เขาอธิบายว่าทีมมักติดกับดักที่เรียกว่า sunk cost หรือต้นทุนจม หมายถึงลงแรงเขียนอะไรไปแล้วก็เสียดายที่จะทิ้ง เขาถึงกับใช้คำว่า guilt merging (การยอมรวมโค้ดเข้าโปรเจกต์ทั้งที่รู้ว่ายังไม่ใช่ทางที่ถูก เพียงเพราะคนเขียนอุตส่าห์ลงแรงไปแล้ว) หลักคิดนี้สอดคล้องกับสกิลชื่อ ponytail ซึ่งช่วยให้ AI เขียนโค้ดน้อยลง เพราะโค้ดที่ดีที่สุดคือโค้ดที่ไม่ต้องเขียน ยิ่งมีโค้ดน้อย ภาระที่ต้องดูแลก็น้อยลง

ระดับใหม่ที่เรียกว่า markdown

เขายกโปรเจกต์ของตัวเองสามโปรเจกต์มาให้เห็นว่าการสร้างของใหญ่เปลี่ยนไปอย่างไร ย้อนไปปี 2021 เขาเคยทำเครื่องมือดึงโพสต์มีมสายโปรแกรมเมอร์จาก Reddit มาจัดรูปแบบเพื่อเอาไปโพสต์ต่อบน Twitter งานนั้นใช้เวลาสองสามวัน ตอนนั้นมันคืองานระดับ side project (โปรเจกต์เล่นๆ ข้างงานหลัก) แต่วันนี้งานแบบเดียวกันใช้เพียงไฟล์ markdown ไฟล์เดียวก็ทำได้ เช่นเดียวกับระบบเช็ก PR ที่ทำงานเองทุกเช้าเก้าโมง

ปีเดียวกันนั้นเขายังทำสตาร์ทอัพชื่อ Ping ที่ช่วยให้คนไลฟ์สตรีมทำคอนเทนต์คุณภาพสูงร่วมกันผ่านโปรแกรมไลฟ์อย่าง OBS ได้ ตอนนั้นมันคือสตาร์ทอัพเต็มตัว แต่เขาบอกว่าโปรเจกต์แบบนี้ทุกวันนี้กลายเป็นแค่ side project ส่วนโปรเจกต์ใหญ่ที่เขากำลังสร้างอยู่ตอนนี้คือ full-stack cloud ซึ่งเป็นแพลตฟอร์มแบบ Vercel (บริการนำเว็บและแอปขึ้นออนไลน์) แต่ครอบคลุมกว่า มีทั้งระบบล็อกอินและฐานข้อมูลมาในตัว

เขายังชี้ว่ามีงานอีกระดับที่เพิ่งเกิดขึ้น ทั้งเล็กและง่ายยิ่งกว่า side project เขาเรียกระดับนี้ว่า markdown tier งานในระดับนี้ใช้เพียงไฟล์ markdown ไฟล์เดียว โดยให้โมเดล AI อย่าง Codex (ผู้ช่วยเขียนโค้ดของ OpenAI) หรือ Claude อ่านและทำตามคำสั่งในไฟล์

คิดให้กว้าง ไม่ใช่แค่ใหญ่

เขาบอกว่าอย่ามองแค่การสร้างของให้ใหญ่ขึ้น แต่ให้คิดด้วยว่าจะทำให้รองรับงานได้กว้างขึ้นอย่างไร เขาอธิบายว่าซอฟต์แวร์มีสองแกน แกนแรกคือความกว้าง (breadth) หรือจำนวนรูปแบบงานที่รองรับได้ อีกแกนคือความลึก (depth) หรือจำนวนฟีเจอร์ที่มีในงานแต่ละแบบ

Vercel เลือกทำงานเพียงไม่กี่ด้านให้ดีมาก โดยเฉพาะการนำเว็บขึ้นออนไลน์ได้อย่างรวดเร็วและเสถียร แทนที่จะแข่งกับเจ้าใหญ่อย่าง AWS (บริการคลาวด์ครบวงจรของ Amazon) ในด้านจำนวนบริการที่ครอบคลุม สิ่งที่เปลี่ยนไปคือ AI ช่วยให้ทีมเล็กรองรับงานได้หลากหลายขึ้น ทั้งที่เมื่อก่อนการทำเช่นนี้ไม่คุ้ม เขายกตัวอย่างว่าตอนนี้แค่พิมพ์สั่ง AI ก็ให้มันสร้างระบบฐานข้อมูลพื้นฐานใส่เข้าไปในโปรดักต์ได้ในหนึ่งถึงสองวัน ขอแค่ให้ระบบดีพอให้ผู้ใช้เริ่มงานได้ ส่วนฟีเจอร์เฉพาะทางที่ยังขาด ก็ไม่ใช่ปัญหาของคนสร้างอีกต่อไป เพราะผู้ใช้ต่อเติมเองได้

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

เพดานขยับสูงจนแทบมองไม่เห็น

คำถามที่เหลืออยู่จึงไม่ใช่ "เราทำมันได้ไหม" อีกต่อไป แต่กลายเป็น "เรากล้าคิดการใหญ่แค่ไหน" เขาเองบอกว่าไม่รู้แล้วว่าคำว่าใหญ่เกินไปหมายถึงอะไร ไม่ว่าจะเป็นการเทรนโมเดลของตัวเองขึ้นมา สร้างระบบปฏิบัติการของตัวเอง หรือลงไปแข่งกับ Slack, AWS และ Salesforce ตรงๆ เขายอมรับว่ามันทั้งน่ากลัวและน่าตื่นเต้นในเวลาเดียวกัน

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

---

ที่มา: คีย์โน้ต Everything we knew about software has changed โดย Theo Browne