ยังไม่มีใครรู้จริง ๆ ว่าควรสร้างด้วย AI อย่างไร

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

---

The Great Experiment Nobody's Running the Same Way

• ในการพัฒนา AI ตอนนี้ไม่มีใครรู้ วิธีที่ตายตัว
• เหมือนทฤษฎี 10,000 ชั่วโมงของ Malcolm Gladwell ที่ ความเชี่ยวชาญ แบบสะสมกลับใช้การไม่ได้ในสภาพแวดล้อมนี้
  • ความก้าวหน้าของ เครื่องมือ AI เร็วเกินกว่าจะสะสมความชำนาญได้ทัน
• แม้แต่ AI pair programming ก็ยังมีประสบการณ์จริงไม่ถึง 2 ปี ทำให้ทุกคนเป็น มือใหม่ อยู่เสมอ

My Current Experiment (Subject to Change)

• ก่อนเริ่มงาน ผู้เขียนอ้างอิง เอกสารหลัก 4 ฉบับ
  • pair_programming.md
  • project_plan_{some extension}.md
  • technical_considerations.md
  • mcp-browser-architecture.md
• ระบบเอกสารนี้ไม่ได้ถูกออกแบบมาตั้งแต่ต้น แต่เป็น ผลลัพธ์ที่ค่อย ๆ สะสมขึ้นแบบเฉพาะหน้า
  • ตอนแรกเริ่มจาก เอกสารด้านสถาปัตยกรรม เพียงฉบับเดียว แล้วค่อย ๆ เพิ่มเป็นสี่ฉบับจากปัญหาที่เกิดซ้ำและปัญหาในการสื่อสารข้อมูล
  • ไม่ได้หยุดที่สี่ฉบับเพราะคิดว่าเหมาะที่สุด แต่เพราะรู้สึกว่ายังไม่จำเป็นต้องเพิ่มอีก
• บางครั้งก็รู้สึกเหมือนกำลัง เล่นบทบาทสมมติ กับตัวเองว่า “เอกสารนี้คือสถาปัตยกรรม” หรือ “กระบวนการนี้คือ Official”
• แต่ซอฟต์แวร์จริงก็ใช้งานได้ และประเด็นสำคัญคือ แม้ระบบชั่วคราวแบบนี้ก็ยังสร้างผลลัพธ์ได้
• บทบาทของเอกสารแต่ละฉบับมีดังนี้
  • Architecture Overview: เริ่มจาก README และบันทึกว่า 'ซอฟต์แวร์นี้ดูเหมือนจะทำอะไร'
  • Technical Considerations: บันทึกความหงุดหงิดหรือปัญหาที่เกิดซ้ำ และเพิ่มรายละเอียดทุกครั้งที่ Claude สับสน
  • Workflow Process: บันทึกขั้นตอนที่ทำซ้ำมาเรื่อย ๆ แต่จริง ๆ แล้วไม่ใช่กฎทางการหรือเอกสารศักดิ์สิทธิ์ หากเป็นเพียงชุดวิธีที่บังเอิญได้ผลในครั้งนี้
  • Story Breakdown: งานย่อยเป็นช่วง ๆ ละ 15-30 นาที เพื่อรีเฟรชบริบทของบทสนทนาบ่อย ๆ เพราะ Claude ลืมเร็ว

Time Dilation in the Age of AI - การบิดเบือนของเวลาในยุค AI

• ระหว่างพัฒนา Protocollie ผู้เขียนพบว่าการทำงานร่วมกับ AI คือ ประสบการณ์ที่สั่นคลอนความรู้สึกเรื่องเวลาของการพัฒนาซอฟต์แวร์แบบเดิมอย่างสิ้นเชิง
• รูปแบบการทำโปรเจกต์คือสั่งให้ Claude ทำฟีเจอร์บางอย่าง จากนั้นก็ไปใช้เวลากับ ชีวิตส่วนตัว และคอยกลับมาตรวจดูพร้อมให้ ฟีดแบ็กสั้น ๆ เป็นระยะ
• เวลาที่ตั้งใจทำงานจริงมีเพียง ราว 90 นาทีต่อวัน แต่ AI กลับสร้าง โค้ดหลายพันบรรทัด ได้อย่างรวดเร็วในช่วงเวลาเดียวกัน
• เมื่อเทียบกับอินพุตแล้ว ผลลัพธ์ออกมาเร็วและมากเกินไป จนสูตรเดิมเรื่อง 投入-ผลลัพธ์, ความพยายาม-ผลงาน, เวลา-ความคืบหน้า พังทลายลง
• บางครั้งความเร็วในการพัฒนาแบบนี้ถึงขั้นทำให้รู้สึกผิด และรู้สึกสับสนเพราะมันไม่สอดคล้องกับกระบวนทัศน์การพัฒนาแบบดั้งเดิม จนบางทีก็เหมือนกำลัง โกงอยู่

ขั้น “การทดลองปาเส้นสปาเกตตี”

ผู้เขียนเรียกสภาพแวดล้อมการพัฒนา AI ในตอนนี้ว่าเป็นขั้นของ “การทดลองปาเส้นสปาเกตตี”

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

การนิยามใหม่ว่าการเขียนโปรแกรมคืออะไรกันแน่ - What Even Is Programming Anymore?

เมื่อมองย้อนประวัติศาสตร์ของการเขียนโค้ด ผู้เขียนตระหนักว่าเรากำลังก้าวเข้าสู่ยุคที่ “อธิบายสิ่งที่ต้องการ แล้วมันก็ถูกสร้างขึ้นมา” ตามพัฒนาการของ abstraction

• การใช้ AI ไม่ได้เป็นแค่ ชั้น abstraction ใหม่ เท่านั้น แต่กำลังเปลี่ยนไปเป็นสิ่งที่ต่างออกไปโดยสิ้นเชิง
• การเขียนโปรแกรมในตอนนี้ไม่ได้ต้องการแค่ความรู้ไวยากรณ์ ความเข้าใจอัลกอริทึม หรือความสามารถในการออกแบบระบบอีกต่อไป แต่ต้องการทักษะใหม่อย่าง 'จินตนาการที่เป็นรูปธรรม' และ 'การถ่ายทอดเจตนาอย่างแม่นยำ'
• “ความสามารถในการอธิบายสิ่งที่ต้องการได้อย่างชัดเจนและสม่ำเสมอ” กลายเป็นสิ่งสำคัญที่สุด

ความหมายเชิงปรัชญาของระบบ 4 เอกสาร - The Four-Document System as Accidental Philosophy

• ระบบ 4 เอกสารนี้ สุดท้ายแล้วคือเรื่องของ ความจำและการลืม เป็น “บันทึกของประสบการณ์ที่ไม่อยากทำซ้ำ”
  • Architecture Overview: “สิ่งที่อยากรู้หากฉันความจำเสื่อม”
  • Technical Considerations: “ปัญหาที่ไม่อยากเจอซ้ำอีก”
  • Workflow Process: “รูปแบบที่ไม่อยากพลาด”
  • Story Breakdown: “จะเดินหน้าต่ออย่างไรในสถานการณ์ที่ต้องเริ่มใหม่ทุกครั้ง”
• เอกสารทั้งหมดสุดท้ายแล้วทำหน้าที่เป็น ข้อความที่ส่งถึงตัวเองในอนาคต
  • กล่าวคือเป็นคู่มือให้ตัวเองเพื่อรับมือกับการสูญหายของข้อมูลในภายภาคหน้า

ที่ราบสูงอันไม่สบายใจและมือใหม่ถาวร - The Uncomfortable Plateau

ตอนนี้ทุกคนเหมือนกลายเป็น นักพัฒนารุ่นจูเนียร์ และติดอยู่ในสภาวะ มือใหม่ที่ไม่มั่นคงตลอดไป

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

Where This All Goes

ไม่มีใครรู้ว่าต่อไปจะสร้างอะไร จะใช้กระบวนการแบบไหน หรือจะยังใช้เอกสารสี่ฉบับนี้ต่อไปหรือไม่

• นักพัฒนาทุกคนจึงเป็นทั้ง ผู้เชี่ยวชาญในกิจวัตรของตัวเอง และ มือใหม่เต็มตัว ในสถานการณ์ใหม่ ๆ พร้อมกัน
• งานเพียง 4 วันอาจเทียบได้กับงานหลายเดือนในอดีต ทำให้ 'ความสามารถในการอธิบายสิ่งที่ต้องการ' กลายเป็นทักษะชี้ขาด
• แม้แต่เอกสารสี่ฉบับของผู้เขียนเองก็ไม่ใช่คำแนะนำหรือเทมเพลต แต่เป็นเพียง ร่องรอยหนึ่งของการทดลองร่วมกัน
• ทั้งเอกสาร กระบวนการ และวิธีการ ล้วนเป็น ผลผลิตชั่วคราว และวิธีของคนอื่นอาจไม่ใช่คำตอบของเรา

ท้ายที่สุด เราทุกคนกำลังสร้าง ปราสาททราย (ซอฟต์แวร์) ในช่วงน้ำลง และต่างก็รู้ว่าคลื่นแห่งความก้าวหน้าจะซัดมันหายไปอีกครั้งในไม่ช้า
อีกไม่นานคงมีใครสักคนลองใช้ระบบ 3 เอกสาร ระบบ 5 เอกสาร หรือแนวทางที่ต่างออกไปโดยสิ้นเชิง และวิธีนั้นก็อาจได้ผลเช่นกัน

บทสรุป

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

ท้ายที่สุด เอกสารทั้งสี่ฉบับที่ผู้เขียนใช้อยู่ เปิดเผยบน GitHub แล้วในตอนนี้

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

[laeyoung]

เดิมทีตั้งใจจะแปลแล้วโพสต์ช่วงสุดสัปดาห์ แต่โดน GN+ แย่งงานไปซะแล้ว 🥲

[truestar]

ตรงส่วนที่ว่า "ระบบเอกสารเองก็ไม่ได้ถูกออกแบบมาตั้งแต่แรก แต่เป็นผลลัพธ์ที่พอกพูนขึ้นมาแบบเฉพาะหน้า" นี่ทั้งรู้สึกอินมากและเผลอหลุดขำออกมาเลยครับ 555

[sinbumu]

มีคอมเมนต์ของพวกนอกรีตประหลาดโผล่มาอีกแล้ว อ้างว่าใครบางคนเป็นอาจารย์

[GN⁺]

ความคิดเห็นจาก Hacker News

• เห็นด้วยกับบทความนี้มาก ผมบังเอิญไปเจอ Kidlin’s Law หรือแนวคิดที่ว่า “ถ้าคุณเขียนปัญหาออกมาได้อย่างชัดเจน เท่ากับคุณแก้ไปได้แล้วครึ่งหนึ่ง” ซึ่งเป็นหลักการที่ทรงพลังมากในยุค AI ทุกวันนี้ เมื่อภาษาธรรมชาติกลายเป็นช่องทางหลักในการสื่อสารกับเทคโนโลยี ถ้าเรานิยามปัญหาได้ชัด ก็จะดึงศักยภาพของ AI ออกมาได้สูงสุดด้วย แนวทางการเขียนโค้ดแบบอะซิงโครนัสก็น่าสนใจมากเช่นกัน ส่วนตัวใช้ Repl.it บ่อยมาก และมันเปลี่ยนวิธีทำงานอย่างน่าทึ่งเพราะทำให้โฟกัสที่การแก้ปัญหาได้ เวลใช้เครื่องมือเขียนโค้ดแล้วรู้สึกเหมือนกินดาวหรือเห็ดใน Mario Kart ทั้งตื่นเต้นมาก แต่บางครั้ง AI ก็หลุดไปทางแปลก ๆ จนต้องเข้าไปตัดสินใจแทรกแซงแบบเรียลไทม์ เมื่อก่อนแค่ดูแลสแตกเดียวก็เหนื่อยแล้ว ตอนนี้เหมือนต้องรับมือกับสแตกไม่สิ้นสุด

  • ผมเองก็มักนึกถึงช่วงที่เติบโตมาเป็นวิศวกรซอฟต์แวร์ว่า ได้ใช้เวลาไปมากกับการเรียนรู้คำศัพท์ของโลกซอฟต์แวร์ เพื่อให้สามารถอธิบายสิ่งที่ตัวเองอยากทำได้

  • Repl.it บางทีงานที่ควรเสร็จในไม่กี่นาทีกลับใช้เวลาทั้งบ่าย แต่ก็มีหลายครั้งที่น่าผิดหวังมาก เพราะแม้จะลองใช้คำแนะนำใต้ช่อง prompt แล้วก็ยังไม่ทำงานอย่างที่ควร

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

• ผมชอบวิธีเขียนโปรแกรมแบบใหม่นี้มาก ไม่รู้ว่ามันจะไปจบตรงไหน แต่ตอนนี้พอใจมาก ทุกวันนี้ผมยังสร้างโค้ดในเวลาที่ปกติควรจะพัก และกลับรู้สึกเหมือนได้พักจริง ๆ มันดีมากโดยเฉพาะสำหรับนักพัฒนาระดับซีเนียร์ที่ทำงานมานาน ช่วงนี้งานแก้ไขโค้ดส่วนใหญ่ค่อนข้างน่าเบื่อ เวลาเห็นแพตเทิร์นผิด ๆ ในโค้ดแล้วอยากทดลองไอเดียใหม่ ก็ต้องเปลี่ยนหลายอย่าง เมื่อก่อนต้องไปค้น Stack Overflow แล้วนั่งคิดนาน แต่ตอนนี้แค่ Copilot ช่วยใบ้ หรือไม่ก็ให้ Claude จัดการให้หมด ตัวอย่างเช่น ผมสร้างตลาดหุ้นจำลองขึ้นมา งานที่ปกติมักผัดวันเพราะต้องต่อกับตลาดจริง ตอนนี้ Claude ทำไว้ให้หมดระหว่างที่ผมนั่งอ่าน HN และถ้าจะเพิ่มการทำกลยุทธ์เข้าไป งานซ้ำ ๆ ที่น่าเบื่อก็จัดการได้ทันที เรื่องอย่างพิมพ์ตกหรือเพิ่ม dependency ที่เคยเสียเวลามาก ตอนนี้ไม่ต้องแล้ว บางคนอาจกังวลว่าโค้ดจะเละ แต่ผมคุยกับ Claude ตลอดและตรวจทานการเปลี่ยนแปลงแบบวิจารณญาณ ประสบการณ์ช่วยได้ และผมก็มักจับได้เร็วเมื่อ AI พาไปผิดทาง ดังนั้นเหมือนผมเจอเครื่องมือพวกนี้ในจังหวะที่พอดีกับอาชีพตัวเองพอดี ปัญหาคือฝั่งนักพัฒนาจูเนียร์ เหมือนถูกพาขึ้นยอดเขาในคราวเดียวทั้งที่บันไดหายไปหมด เลยสงสัยว่าพวกเขาจะเติบโตกันอย่างไร

  • เห็นด้วยกับมุมมองเรื่องอนาคตของนักพัฒนาจูเนียร์ ผมอายุเกือบ 50 แล้ว เขียนโปรแกรมมากว่า 30 ปีในหลายสายงาน และรู้วิธีใช้งานเอเจนต์กับวางสถาปัตยกรรมให้แข็งแรงจากประสบการณ์ของตัวเอง ถ้าทุกอย่างถูก AI ปรุงมาให้หมดโดยไม่มีประสบการณ์รองรับ ผมก็สงสัยจริง ๆ ว่าคนรุ่นหลังจะเติบโตยังไง คงต้องรอดูเวลาเป็นคำตอบ

  • ผมเองก็สนุกกับการใช้โมเดลภาษาขนาดใหญ่ แต่การคอยพิมพ์ prompt อย่างเดียวต่อเนื่องมันน่าเบื่อและทำให้ไม่สบายใจเหมือนกัน เหมือนไม่เข้าใจจริง ๆ ว่าโปรแกรมทำงานยังไง การได้ลงมือสร้างอะไรเองมันสนุกมาก ส่วนงานซ้ำ ๆ ที่เคยทำมาแล้วหรือเรื่องที่ไม่ได้ใส่ใจมากก็โยนให้ LLM ทำ ผมเคยให้ Claude สร้างเกม snake บนเทอร์มินัลด้วย มันทึ่งมากจริง ๆ

  • สงสัยเหมือนกันว่าคุณตระหนักแล้วหรือยังว่าตัวเองกลับไปทนงานจุกจิกแบบเดิมไม่ได้อีกแล้ว ตั้งแต่ LLM มา ผมยิ่งอยากออกไปข้างนอกระหว่างทำงานมากขึ้น รู้สึกอิจฉานักพัฒนารุ่นใหม่อยู่เหมือนกันที่อาจไม่ต้องเสียเวลา 12 ชั่วโมงจ้องจอเพื่อพยายามเชื่อม black box สองก้อนเข้าด้วยกันแบบเมื่อก่อนอีกแล้ว

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

  • เครื่องมือพวกนี้น่าตื่นเต้นมากเพราะมันเข้ามาแทนงานน่าเบื่อที่ผมทำซ้ำมาเป็นพัน ๆ ครั้งตั้งนานแล้ว

• สำหรับผม AI คือ Google Search ยุคถัดไปที่สามารถสนทนาบนข้อมูลทั้งหมดที่มีอยู่บนอินเทอร์เน็ตได้ เหมือนตอนที่เสิร์ชเอนจินแพร่หลายแล้วทำให้งานในหลายอุตสาหกรรมหายไป เช่น หนังสือพิมพ์ สมุดหน้าเหลือง สารานุกรม บริษัทท่องเที่ยว ฯลฯ AI ก็จะก่อการเปลี่ยนแปลงแบบนั้นเช่นกัน แต่ผมไม่คิดว่ามันเป็นวิกฤตเชิงภาวะการมีอยู่จริงอย่างที่หลายคนคิด AI ก็เป็นแค่เครื่องมือชนิดหนึ่ง คนฉลาดและสร้างสรรค์จะใช้มันทำสิ่งเจ๋ง ๆ ได้อีกมาก สุดท้ายแล้วขึ้นอยู่กับผู้ใช้ การค้นหากลายเป็นการแชต เมื่อก่อนเราต้องหาเอง เดี๋ยวนี้แค่คุยแล้ว AI ก็ไปหาให้ แถมทำได้มากกว่านั้นอีก

  • ยังไม่แน่ใจว่าอินเทอร์เฟซ LLM แบบแชตคือวิธีที่เหมาะที่สุดหรือเปล่า ดูเหมือนเราควรมีวิธีที่ฉลาดกว่านี้

  • ต่างจากยุคทองของ Google ตอนนี้สัดส่วนสัญญาณต่อสัญญาณรบกวนแย่ลงมาก และแหล่งที่มาของข้อมูลก็พร่ามัวขึ้น

  • ตอนนี้ผลการค้นหาของ Google เหมือนเอาขยะที่ AI สร้างขึ้นมาดันไว้เหนือข้อมูลที่ใช้ได้จริงไปแล้ว

  • เสิร์ชเอนจินยุคใหม่ให้แค่คำตอบ แต่ไม่ให้กระบวนการที่พาไปสู่คำตอบ ทำให้บทบาทของคนที่ค้นหาและบันทึกข้อมูลอย่างถูกต้องค่อย ๆ หายไป ถ้าสิ่งนี้หายไปจริง สุดท้ายทุกคนจะหลงทาง เพราะ AI นำข้อมูลเดิมกลับมาใช้ซ้ำ เราจึงต้องมีวิธีตอบแทนรายได้ให้ผู้สร้าง โดยเฉพาะนักข่าวสายวารสารศาสตร์คุณภาพ ไม่อย่างนั้นรากฐานของสังคมประชาธิปไตยอาจพังได้ อุตสาหกรรมข่าวอยู่ในภาวะวิกฤตมาหลายปีแล้ว และผลก็คือความไม่ไว้วางใจ ความแตกแยก ข้อมูลผิด และการชักจูงจากภายนอก ตอนนี้ AI อาจเป็นแรงกระแทกครั้งสุดท้ายที่ทำให้อุตสาหกรรมล้มลงได้ นี่ไม่ใช่แค่เรื่องแทนที่งาน แต่คือเส้นทางที่มืดมนมากที่เรากำลังเดินไป

  • นอกจากเรื่องค้นหาแล้ว มันยังมีประโยชน์อย่างชัดเจนในอีกหลายด้าน

• อยากรัน Claude Code จากมือถือบน cloud VM เพื่อจะได้คอยให้ feedback และทำงานต่อไปเรื่อย ๆ ระหว่างเดินเล่นหรือปั่นจักรยาน

  • ดูเหมือนว่าจะทำอะไรคล้าย ๆ กันได้แล้วด้วยเครื่องมืออย่าง vibetunnel
    https://vibetunnel.sh

• อัตราส่วนระหว่างอินพุตกับเอาต์พุตเป็นเรื่องที่น่าสนใจ ปกติเรามักพยายามเพิ่มปริมาณเอาต์พุตให้มากที่สุด แต่ตอนนี้กลับตรงกันข้าม ผมไม่ได้ต้องการปริมาณสูงสุด แต่อยากให้งานถูกแบ่งเป็นขั้นที่เป็นรูปธรรมและตรวจสอบได้มากกว่า ตอนเขียน requirements ร่วมกับ Cursor ช่วงแรกมันทำได้ดี แต่ปัญหาคือบางครั้งมันเผลอสร้างโค้ดจำนวนมากที่เบี่ยงจากแผนไปเลย และยังมีเรื่องเล็ก ๆ อย่างใส่บรรทัดว่างหลังหัวข้อ Markdown ไม่ได้ หรือเรื่องที่ต้องคอยบอกซ้ำ ๆ รู้สึกว่าอยากควบคุมกระบวนการแบบวนซ้ำ คุณภาพ และความสม่ำเสมอได้มากกว่านี้ AI จะเก่งมากเมื่อเราทำให้ปัญหาเปิดกลายเป็นปัญหาปิดที่ทดสอบได้ ผมต้องการเครื่องมือที่ช่วยให้เปลี่ยนปัญหาเปิดให้เป็นปัญหาปิดได้

• พอเจอประสบการณ์แบบ “เดินเข้าออฟฟิศไปทดสอบสิ่งที่ Claude ทำไว้ ถ้ามันเวิร์กก็ commit แล้ว push” ซ้ำ ๆ แบบนี้ ก็รู้สึกว่าในฐานะที่ปรึกษาด้านความปลอดภัยไซเบอร์ อนาคตน่าจะหาเงินได้เยอะมากจริง ๆ

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

• ผมไม่คิดว่านี่คือ vibe coding แต่มันเป็นอะไรใหม่ไปเลย ผมเรียกมันว่า “flex coding” บ่ายเดียวก็ทำทั้งแอปเสร็จและยังเป็นพ่อที่ดีได้ด้วย แค่บอกว่า “ช่วยทำ UI ต่อเซิร์ฟเวอร์ให้หน่อย” แล้ว Claude ก็ไปเขียนโค้ด ส่วนผมก็กลับไปใช้ชีวิตต่อ ทำอาหารเช้า เล่นกับลูก ดูทีวี แล้วระหว่างนั้น Claude ก็ยังเขียนโค้ดต่อไป ผมแวะกลับมาทดสอบและให้ feedback ทุก ๆ หนึ่งหรือสองชั่วโมง

  • ในเชิงอารมณ์มันน่าดึงดูดมาก และเป็นไลฟ์สไตล์ที่หลายคนใฝ่ฝัน แต่โค้ดของ Claude เชื่อถือได้ถึงระดับนั้นจริงหรือ ถ้าจะเอาไปคิดเงินลูกค้าหรือใช้ในผลิตภัณฑ์ที่เอาชื่อเสียงตัวเองไปค้ำ คำตอบของผมคือ “ไม่” พอใช้เองแล้วเจอทั้ง reference error การคัดลอกชนิดข้อมูลเดิมมาแล้วเปลี่ยนแค่ชื่อ รวมถึงกรณีที่ไม่มี type error เลยแต่ก็ยังผิดอยู่บ่อย ๆ พอให้มันเขียนเทสต์ ก็เคยเจอว่าถ้าเทสต์ล้มเหลวมันไม่ได้ล้มเหลวจริง แต่ไปสร้างเทสต์ประหลาดที่ผ่านแค่การตรวจสอบตัวเองแทน การได้ใช้เวลากับครอบครัวเป็นเรื่องดีมาก แต่ผมคงไม่แนะนำให้เอาแอปที่ทำแบบนี้ไปใช้กับเรื่องสำคัญ

  • มันทำให้นึกสงสัยว่าทำไมต้องจ่ายเงินเดือนให้คนที่ทำงานแบบนี้ และถ้าผมทำเองได้ ทำไมต้องจ่ายเงินให้ซอฟต์แวร์ด้วย

  • เตือนไว้ก่อนนะ อีกไม่นาน Claude อาจเริ่มบ่นให้คุณไปทำงานบ้างก็ได้

• รู้สึกว่าเครื่องมือซอฟต์แวร์ที่ใช้ LLM ยังมีข้อจำกัด ไม่มีวิธีใช้ global system prompt เดียวร่วมกันกับทุกแอปที่ใช้ OpenRouter Key และก็ย้ายบทสนทนาจากแอปหนึ่งไปอีกแอปหนึ่งได้ลำบาก แม้แต่สิทธิ์เข้าถึง MCP tool ชุดเดียวกันในทุกแอปก็ยังให้ไม่ได้อย่างเหมาะสม ตอนนี้ UX ของ Claude Code น่าจะดีที่สุดแล้ว แต่ผมไม่อยากถูกผูกกับการสมัคร Claude และอยากเชื่อมกับผู้ให้บริการที่ต้องการผ่านคีย์ของตัวเอง

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

  • พูดอย่างเป็นธรรม ซอฟต์แวร์เชิงพาณิชย์จริง ๆ หลายตัวก็ไม่ได้ใส่ใจเรื่องพวกนี้อย่างเหมาะสมเหมือนกัน

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

  • น่าประหลาดใจที่ยังมีคนเชื่อว่าการพัฒนาจะสเกลได้ด้วยแนวคิดประมาณว่า “ระบบเอกสารสี่ชิ้นของฉันเหรอ? มันก็แค่สปาเกตตีที่บังเอิญกลายเป็นแพตเทิร์น และพรุ่งนี้อาจพังหมด เราก็แค่โยนสปาเกตตีใส่กำแพงใหม่อีกครั้ง”

• ช่วงนี้ผมกำลังทดลองแนวทางพัฒนาที่อิงโมเดล และรู้สึกอินมากกับส่วนในบทความที่ถามว่า “การเขียนโปรแกรมคืออะไรกันแน่?” ผมใช้ทั้งประสบการณ์ 25 ปีและพื้นฐานวิทยาการคอมพิวเตอร์ทั้งหมด แต่ก็ไม่แน่ใจว่านี่นับเป็นการเขียนโปรแกรมแบบดั้งเดิมที่ต้องลงมือเขียนโค้ดเองหรือเปล่า ตอนนี้มันให้ความรู้สึกเหมือนเป็นนักบินที่คอยบังคับเครื่องมือ มากกว่าจะเป็นช่างฝีมือที่ลงมือทำเอง คนที่ชอบงานทำมืออาจออกจากอุตสาหกรรมนี้ภายใน 5 ปีข้างหน้า แม้แน่นอนว่ายังมีบางส่วนที่ต้องทำมืออยู่ แต่ระเบียบวิธีแบบใหม่กำลังเปิดขึ้น ตอนนี้ยังไม่ใช่ทุกคนที่ชำนาญกับมัน แต่สุดท้ายมันก็จะกลายเป็นส่วนหนึ่งของอุตสาหกรรม

  • เมื่อก่อนถ้าอยากเพิ่มผลิตภาพก็จำเป็นต้องสะสมความรู้ แต่เพราะ LLM ตอนนี้เรากระโดดข้ามไปสู่ขั้นผลิตภาพได้เลย มันไม่ใช่แค่การทำให้ความรู้เป็นประชาธิปไตย แต่เป็นการทำให้ตัวความรู้เองไม่จำเป็นอีกต่อไป