วิธีเป็น AI Engineer ที่เก่งขึ้น 30 เท่าด้วย “รสนิยม”

• ในยุคที่ AI สร้างโค้ดได้จำนวนมาก ความสามารถหลักที่ใช้แยกคุณค่าของวิศวกรไม่ใช่ความเร็ว ความรู้ หรือประสบการณ์ แต่คือ “รสนิยม (taste)” หรือความสามารถในการประเมินว่าจะสร้างอะไร
• สมาชิกทีม OpenAI Codex ต่างก็สรุปตรงกันโดยอิสระว่า หากมีคนที่มี รสนิยมด้านซอฟต์แวร์ที่ดี ใครก็ตามก็สามารถกลายเป็นวิศวกรระดับ 10x ได้
• รสนิยมแบ่งได้เป็น 3 รูปแบบคือ การรับรู้ (recognition) · เข็มทิศ (compass) · วิสัยทัศน์ (vision) และทั้งหมดล้วนมาบรรจบกันที่กลไกเดียวคือคุณภาพของฟังก์ชันประเมินภายใน
• คุณค่าถูกสร้างขึ้นอย่างเข้มข้นใน 5 ด้าน ได้แก่ การเลือกปัญหา, สถาปัตยกรรมระบบ, การตัดสินคุณภาพ, ความเข้าใจผู้ใช้, การสื่อสาร
• ตอนนี้การเขียนโค้ดกลายเป็นสิ่งที่ถูกทำให้เป็นสินค้าแล้ว การตัดสินใจและการคิด จึงเป็นความสามารถแท้จริงที่ต้องตั้งใจฝึกฝน

---

โลกเปลี่ยนไปแล้ว แต่วิศวกรส่วนใหญ่ยังไม่รู้ตัว

• Dario Amodei ซีอีโอของ Anthropic คาดการณ์ในเดือนมีนาคม 2025 ว่า AI จะเขียนโค้ด 90% ได้ภายในไม่กี่เดือน ซึ่งตอนนั้นฟังดูเกินจริง
• Boris Cherny ผู้สร้าง Claude Code รายงานว่าในเดือนธันวาคม โค้ดที่เขา commit นั้น 100% ถูกเขียนโดย AI และเขาไม่ได้เปิด IDE เลยแม้แต่ครั้งเดียว
• Andrej Karpathy ซึ่งเคยเรียกเครื่องมือเขียนโค้ดด้วย AI ว่า “slop” ได้เปลี่ยนจุดยืนอย่างสิ้นเชิงในเดือนธันวาคม
  • “ในฐานะโปรแกรมเมอร์ ผมไม่เคยรู้สึกว่าตัวเองตามไม่ทันขนาดนี้มาก่อน และอาชีพนี้กำลังถูกปรับโครงสร้างใหม่อย่างหนัก”
  • DHH ผู้สร้าง Ruby on Rails ยอมรับว่าการต่อต้านก่อนหน้านี้เป็นเพราะ “โมเดลยังดีไม่พอ” และตอนนี้สถานการณ์กลับด้านแล้ว
  • Malte Ubl, CTO ของ Vercel กล่าวถึงว่า “ต้นทุนการผลิตซอฟต์แวร์กำลังเข้าใกล้ศูนย์”
• ระหว่างเดือนพฤศจิกายนถึงธันวาคม 2025 Opus 4.5, GPT-5.2, Gemini 3 ได้ก้าวข้ามเส้นแบ่งด้านความสามารถที่มองไม่เห็น ทำให้โค้ดจาก AI ไปถึงระดับวิศวกรที่ชำนาญในงานหลากหลายประเภท และลดเวลาจากหลายชั่วโมงเหลือเพียงไม่กี่นาที
• เมื่อการสร้างโค้ดถูกทำให้เป็นสินค้า สิ่งที่เหลืออยู่คือ วิศวกรรมซอฟต์แวร์ (การแยกปัญหา การตัดสินใจว่าจะสร้างอะไร การออกแบบการทดสอบ·ความน่าเชื่อถือ·การขยายระบบ การชั่งน้ำหนัก trade-off) ซึ่งก็คือรสนิยม

รสนิยมคืออะไรกันแน่

• รสนิยมตามที่ทีมวิศวกรรมชั้นนำพูดถึงมี 3 คำนิยาม ซึ่งเป็นการมองความสามารถเดียวกันจากคนละมุม

• รสนิยมในฐานะการรับรู้ (Recognition)

  • ความสามารถในการ รู้สึกได้ ว่าในสอง implementation แบบไหนดีกว่า ก่อนจะอธิบายได้ด้วยซ้ำว่าเพราะอะไร
  • Emma Tang: การที่ระบบสะอาด ขยายได้ดี ไม่มีความซ้ำซ้อน และเข้าใจได้ง่ายจริงหรือไม่ เป็นเรื่องของรสนิยม
  • เหมือนเชฟที่ชิมซอสแล้วรู้ได้ทันทีว่าขาดความเปรี้ยว ก่อนจะระบุได้อย่างมีสติว่าอะไรหายไป การจับคู่แพตเทิร์นทำงานเร็วกว่าการให้เหตุผลอย่างมีสติ
  • กรณีที่ทีม Codex เลือก Rust แทน TypeScript สำหรับ CLI
    • แม้ทั้งคู่จะใช้งานได้ แต่พวกเขารับรู้ว่าข้อจำกัดของ Rust (strong typing, การจัดการหน่วยความจำแบบชัดเจน, dependency ที่น้อย) สร้างผลทางวัฒนธรรมวิศวกรรมที่ไปไกลกว่าข้อได้เปรียบทางเทคนิค
    • ไม่ใช่การตัดสินว่าเป็น “ภาษาที่เหนือกว่าทางเทคนิค” แต่เป็น “ภาษาที่หล่อหลอมพฤติกรรมที่ทีมต้องการ”
  • รสนิยมที่ไม่ดี: เลือก Rust เพราะมันกำลังฮิต หรือเพราะบล็อกบอกว่าเร็ว โดยไม่เข้าใจผลกระทบลำดับที่สอง

• รสนิยมในฐานะเข็มทิศ (Compass)

  • เป็นรูปแบบที่ Tibo พูดว่าวิศวกรต้องมี “เข็มทิศของตัวเอง” ไม่ใช่การประเมินสิ่งที่มีอยู่แล้ว แต่คือ ความสามารถในการรู้ว่าควรสร้างอะไรต่อไป
  • วิศวกรที่พูดได้ว่า “นี่ไม่ใช่ฟีเจอร์ที่ถูกต้อง” ก่อนจะเขียนโค้ดแม้แต่บรรทัดเดียว
  • กรณีที่ Boris Cherny ทำฟีเจอร์ todo list ของ Claude Code เป็นเวลา 2 วันด้วย prototype ราว 20 แบบ
    • เขาลองทั้ง inline todo, drawer UI, interactive pill, การแสดงผลด้านล่างหน้าจอ ฯลฯ ก่อนจะค่อย ๆ บรรจบสู่รูปแบบที่ให้ความรู้สึกว่าไม่ใช่ความบังเอิญ แต่เป็นสิ่งที่ควรเป็น
    • ภายหลังเขาอธิบายได้ว่าทำไมแบบสุดท้ายถึงดีกว่า แต่ความไม่พอใจต่อแบบกลาง ๆ ตั้งแต่แรกนั่นเองที่ทำหน้าที่เป็นเข็มทิศของรสนิยม
  • รสนิยมแบบเข็มทิศหายากกว่ารสนิยมแบบการรับรู้ เพราะมันทำงานอยู่ต้นน้ำก่อนการลงมือทำ

• รสนิยมในฐานะวิสัยทัศน์ (Vision)

  • ถูกอธิบายด้วยคำพูดของ SQ Mah ว่า “มนุษย์เป็นผู้กำหนดวิวัฒนาการ” และเป็นรูปแบบที่ยากที่สุด คือการรู้ว่าอะไรจะสำคัญในอีก 2 ปีข้างหน้า ไม่ใช่แค่อะไรที่ดีในตอนนี้
  • Peter Steinberger ผู้สร้าง OpenClaw รันเอเจนต์พร้อมกัน 5~10 ตัว และใช้เวลาส่วนใหญ่ไปกับสถาปัตยกรรมและการออกแบบระบบ
    • เขากล่าวว่า “โค้ดส่วนใหญ่เป็นแค่การแปลงข้อมูลที่น่าเบื่อ ดังนั้นควรทุ่มพลังไปที่การออกแบบระบบ”
  • ลำดับความสำคัญถัดไปของทีม Codex คือ การวางแผนบนบริบทที่สมบูรณ์ยิ่งขึ้น ซึ่งต้องอาศัยข้อมูลนอก codebase เช่น เป้าหมายทางธุรกิจ พลวัตของตลาด และลำดับความสำคัญของทีม
    • นี่คือรสนิยมแบบวิสัยทัศน์ที่ถูกนำไปใช้กับกลยุทธ์ผลิตภัณฑ์ ซึ่งมุ่งสู่อนาคตที่โมเดลไม่ใช่แค่ตัวสร้างโค้ดที่ดีกว่า แต่เข้าใจว่าทำไมซอฟต์แวร์นั้นจึงมีอยู่

• คำนิยามแบบบูรณาการ

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

ทำไมวิศวกรบางคนถึงมีรายได้มากกว่ามาก

• ก่อนยุค AI ช่องว่างด้านค่าตอบแทนอธิบายได้ด้วย 3 ปัจจัยคือ บริษัท อายุงาน และสายความเชี่ยวชาญ แต่ AI กำลังทำให้ตัวแปรทั้งสามนี้ปะปนกันหมด
• ช่องว่างระหว่างวิศวกรที่ยอดเยี่ยมกับวิศวกรทั่วไปในสตาร์ตอัปขยายจาก 3 เท่าเป็น 10 เท่า เพราะคนที่เก่งกว่าสามารถใช้ AI เพื่อสร้างผลงานระดับทีมเล็กได้
• แกนของอายุงานกำลังเปลี่ยนจาก ประสบการณ์การเขียนโค้ด ไปสู่ ประสบการณ์ในการตัดสินใจที่ดี
  • คุณค่าของ “รู้จัก React” ลดลง ขณะที่คุณค่าของ “ออกแบบระบบที่เชื่อถือได้ภายใต้ภาระโหลด” เพิ่มขึ้น
• จุดร่วมของวิศวกรที่สร้างช่องว่างใหญ่คือการตัดสินใจที่ ทบต้นสะสมมูลค่าได้
  • การตัดสินใจด้านสถาปัตยกรรมที่ดีเพียงครั้งเดียวอาจประหยัดงานได้หลายเดือนตลอดระยะเวลา 1 ปี
  • การตัดสินใจด้านผลิตภัณฑ์ที่ดีเพียงครั้งเดียวอาจเป็นตัวชี้ชะตาว่าฟีเจอร์จะถูกใช้งานจริงหรือไม่
• ต่อให้ทำงานหนักกว่า ก็อาจสร้างคุณค่าได้เพียงครึ่งหนึ่งของคนที่มีรสนิยมดีกว่า การรันเอเจนต์ 8 ตัวกับปัญหาที่ผิด ยังสร้างคุณค่าได้น้อยกว่าการรัน 2 ตัวกับปัญหาที่ถูกต้อง
• จากกรณีของ OpenAI วิศวกรที่มีประสิทธิภาพสูงสุดไม่ได้สร้างโค้ดมากขึ้น แต่เปลี่ยนโฟกัสไปใช้เวลากับ การคุยกับผู้ใช้ ทิศทางผลิตภัณฑ์ และความเข้าอกเข้าใจ มากขึ้น
  • บางคนกลับไปใช้ tab autocomplete เพราะ “รู้สึกว่าสูญเสียสัมผัสกับ codebase” และทั้งสองปฏิกิริยาก็ถือว่าใช้ได้

จุดที่คุณค่าถูกสร้างขึ้นจริง

• มีอยู่ 5 ด้านที่รสนิยมสร้างมูลค่าแบบไม่สมดุล และวิศวกรส่วนใหญ่แข่งขันได้เพียงหนึ่งหรือสองด้านเท่านั้น

• Zone 1: การเลือกปัญหา

  • เป็นการตัดสินใจเชิงรสนิยมที่มี leverage สูงที่สุดว่าอะไรควรถูกทำ แต่คนส่วนใหญ่แทบไม่คิดเรื่องนี้
  • วิศวกรที่มีรสนิยมจะถามว่า “ถ้าแก้สิ่งนี้ได้ดี ปัญหาอีกห้าข้อจะหายไปหรือไม่”
  • Peter Steinberger สนทนากับเอเจนต์ไปมาเป็นเวลานานเพื่อขัดเกลาแผน ท้าทายและโต้แย้ง จนกว่าจะพอใจจึงค่อยให้เอเจนต์ลงมือ แผนคืองาน ส่วนการลงมือทำคือสิ่งที่มอบหมายได้
  • ในระบบสิทธิ์ของ Claude Code เลือก แนวทางที่เรียบง่ายที่สุด แทน RBAC ที่ซับซ้อนหรือนโยบายแบบละเอียด โดยให้ขอสิทธิ์แล้วจดจำคำตอบ เพื่อออกสู่ตลาดได้รวดเร็วและใช้งานเข้าใจง่าย

• Zone 2: สถาปัตยกรรมระบบ

  • คือวิธีที่ชิ้นส่วนต่าง ๆ ประกบกัน เป็นด้านที่ ครึ่งชีวิตยาวที่สุด ของรสนิยม การตัดสินใจที่ดีจะยังจ่ายผลตอบแทนอีก 2 ปีต่อมา ส่วนการตัดสินใจที่แย่จะสะสมเป็นหนี้เทคนิคที่บังคับให้ต้องเขียนใหม่
  • การตัดสินใจสร้าง agent loop ของ Codex เป็น state machine, การตัดสินใจของ Claude Code ที่จะเขียน business logic ให้น้อยที่สุดเท่าที่เป็นไปได้, และความหมกมุ่นเรื่องการขยายแบบโมดูลาร์ของ OpenClaw ล้วนเป็นการตัดสินใจเชิงรสนิยมด้านสถาปัตยกรรม
  • Boris Cherny: “ทุกครั้งที่มีโมเดลใหม่ออกมา เราจะลบโค้ดทิ้งเป็นกอง ๆ และวางโค้ดรอบโมเดลให้น้อยที่สุดเท่าที่ทำได้”
    • ทีมส่วนใหญ่เพิ่มโค้ดทุกครั้งที่มีรีลีส แต่ทีม Claude Code กลับลบออก เพราะ โมเดลคือตัวผลิตภัณฑ์ และสิ่งรอบข้างควรบางที่สุด

• Zone 3: การตัดสินคุณภาพ

  • คือการรู้ว่าสิ่งนั้นดีพอจะปล่อยแล้วหรือยัง หรือยังต้องทำเพิ่มอีก ซึ่งเป็นด้านที่ AI ช่วยไม่ได้ (เพราะไม่รู้ว่าอะไรคือ “พอ” ในบริบทเฉพาะ)
  • การรีวิวโค้ดแบบเป็นชั้นของ Codex: โค้ดที่ไม่ใช่แกนหลักให้ AI รีวิวอย่างเดียว แต่โค้ดเอเจนต์ที่เป็นแกนหลักต้องมีมนุษย์รีวิว
    • รสนิยมอยู่ที่การรู้ว่าโค้ดส่วนไหนสำคัญ ระบบสิทธิ์ต้องมีสายตามนุษย์ แต่การอัปเดต README ไม่จำเป็น
  • ทีม Codex เขียนโค้ดเกือบทั้งหมดด้วยพรอมป์ต์ แต่ฝ่ายอื่นภายในองค์กรอยู่ราว 70% ส่วน 30% ที่เขียนด้วยมือคือส่วนที่การตัดสินคุณภาพสำคัญที่สุด (“กฎ 30/70”)

• Zone 4: ความเข้าอกเข้าใจผู้ใช้

  • คือการเข้าใจว่ามนุษย์อีกฝั่งต้องการอะไรจริง ๆ เป็นด้านที่ AI อ่อนแอที่สุด
  • ข้อความโหลดตามบริบทใน Claude Code ที่ Boris ทำขึ้น (แทนวงหมุนธรรมดา ด้วยการแสดงว่าโมเดลกำลังทำอะไร) ไม่มีใครร้องขอ แต่ทำขึ้นเพราะการรอแบบไม่มีข้อมูลกับการรอแบบมีข้อมูลนั้นต่างกัน
  • ค่าเริ่มต้นของ sandbox ใน Codex ก็เป็นการตัดสินใจจากความเข้าอกเข้าใจผู้ใช้เช่นกัน Tibo: “ต่อให้เสียอัตราการนำไปใช้ เราก็จะไม่แนะนำสิ่งที่อาจไม่ปลอดภัยโดยค่าเริ่มต้น”
    • เป็นการเข้าใจว่าผู้ใช้จำนวนมาก “ไม่ได้เชี่ยวชาญเทคนิคมากนัก” และอาจเผลอทำสิ่งที่ย้อนกลับไม่ได้ จึงเลือก ความปลอดภัย มากกว่าความสะดวก

• Zone 5: การสื่อสารและการเล่าเรื่อง

  • คือการวางกรอบสิ่งที่สร้างขึ้นอย่างไร เป็นด้านที่วิศวกรมักประเมินค่าต่ำเกินไปอย่างสม่ำเสมอ แต่ตลาดกลับให้รางวัล
  • OpenClaw ของ Peter Steinberger มียอดค้นหา Google มากกว่า Claude Code และ Codex รวมกันในสัปดาห์ที่เป็นไวรัล
    • ชื่อที่ชัดเจน เดโมที่โน้มน้าวใจ และเรื่องเล่าว่า “คนหนึ่งคนสร้างผลงานได้เท่าทีม” เป็นตัวขับเคลื่อนการแพร่กระจาย
  • ไฟล์ AGENTS.md ของ Codex (README สำหรับ AI agent ไม่ใช่มนุษย์) คือรสนิยมด้านการสื่อสารที่ตระหนักว่าผู้อ่านเอกสารเปลี่ยนไปแล้ว และปรับรูปแบบให้สอดคล้อง

ตัวอย่างของรสนิยม (และการไม่มีมัน)

• การเลือกเทคโนโลยีสแตก

  • ไม่มีรสนิยม: “ใช้ TypeScript เพราะดังสุดและทุกคนรู้จัก” ให้เหตุผลด้วยธรรมเนียม
  • มีรสนิยม: Boris เลือก TypeScript เพราะมัน “on distribution” สำหรับโมเดล Claude (คือสิ่งที่โมเดลจัดการได้ดีอยู่แล้ว) เป็นการปรับให้เหมาะกับจุดแข็งของโมเดล ไม่ใช่ความถนัดของทีม
    • Codex เลือก Rust เพราะต้องการการพึ่งพาภายนอกให้น้อยที่สุดที่ “ทำให้ต้องคิดถึงมาตรฐานวิศวกรรมที่ตั้งไว้” และตรวจดูได้ด้วยตนเอง แม้จะเป็นการตัดสินใจแบบเดียวกัน แต่ทั้งสองฝั่งต่างยึดข้อจำกัดเฉพาะ ไม่ใช่ความชอบทั่วไป

• การจัดการโค้ดที่ยังไม่เข้าใจทั้งหมด

  • ไม่มีรสนิยม: “AI สร้างให้แล้วและเทสต์ผ่าน ก็ปล่อยได้” โดยไม่คำนึงถึงความเพียงพอของเทสต์หรือความสามารถในการบำรุงรักษา
  • มีรสนิยม: Peter ปล่อยโค้ดที่ยังไม่ได้อ่านทั้งหมด แต่ไม่ใช่แบบสะเพร่า “ผมรู้ตำแหน่งและโครงสร้างของคอมโพเนนต์ รวมถึงการออกแบบระบบโดยรวม และปกติก็พอแล้ว”
    • เทสต์, linting และ local CI คือชั้นของการตรวจสอบ ฝั่งหนึ่งคือการเสี่ยงดวง แต่อีกฝั่งคือ ระบบที่รับประกันความถูกต้องเชิงโครงสร้าง

• การตอบสนองต่อคำขอฟีเจอร์

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

• การออกแบบสำหรับ AI agent

  • ไม่มีรสนิยม: README ทั่วไปที่มีคำแนะนำการตั้งค่าและ API endpoint
  • มีรสนิยม: Codex เขียน AGENTS.md เพื่อบอก AI ว่าจะสำรวจโค้ดเบสอย่างไร ใช้คำสั่งทดสอบอะไร และปฏิบัติตามมาตรฐานอย่างไร โดยจัดโครงสร้างโค้ดเบสให้ โมเดลประสบความสำเร็จได้อย่างหลีกเลี่ยงไม่ได้

• การรับมือ PR ที่ถาโถม

  • ไม่มีรสนิยม: มี PR ที่สร้างโดย AI หลั่งไหลเข้ามา แต่ยังใช้กระบวนการรีวิวเดิม ทำให้รีวิวเวอร์ล้นมือและคุณภาพตก
  • มีรสนิยม: ทีมของ Emma Tang กำหนดให้แนบ พรอมป์ต์มากับ PR หากไม่มี ก็จะถามใน Slack ว่า “พรอมป์ต์คืออะไร”
    • ในโลก AI การรีวิวเจตนามีประโยชน์กว่าการรีวิวโค้ด Peter เรียก PR ว่า “prompt requests” และสนใจพรอมป์ต์ที่ใช้สร้างมากกว่าตัวโค้ดเอง เมื่อหน่วยของการสร้างเปลี่ยน หน่วยของการรีวิวก็ต้องเปลี่ยนตาม

แผนฝึกรสนิยม (ไม่ใช่เรื่องความรู้สึก)

• คำแนะนำอย่าง “เก็บประสบการณ์ให้มากขึ้น” ใช้การไม่ได้พอ ๆ กับ “ออกกำลังกายให้มากขึ้น” ด้านล่างคือแผน 90 วันสำหรับสามรูปแบบ

• เดือนที่ 1: สร้างรสนิยมด้านการรับรู้ผ่านการเปิดรับอย่างมีโครงสร้าง

  • กลไกคือการเปิดรับความแปรผันจำนวนมาก แล้วตามด้วยการสะท้อนคิดอย่างจงใจ
  • สัปดาห์ 1–2: ศึกษาเครื่องมือนักพัฒนา 10 ตัวที่คุณชื่นชม
    • ติดตั้ง Codex CLI, Claude Code, Linear, Supabase, Stripe dashboard, Vercel, Tailwind, Railway, Resend และผลิตภัณฑ์ที่ไม่ใช่ซอฟต์แวร์อีก 1 อย่าง (เช่น นิทรรศการพิพิธภัณฑ์ที่ออกแบบดี หรือเมนูร้านอาหาร)
    • เขียนอย่างละ 15 นาที: คุณสังเกตอะไรใน 60 วินาทีแรก อะไรทำให้ยินดี อะไรทำให้งุนงง และคุณจะขโมยการตัดสินใจใดมาใช้
    • เครื่องมือที่ดีจะแสดงผลลัพธ์ก่อนใน 30 วินาทีแรก ก่อนอธิบายกระบวนการ ส่วนเครื่องมือที่แย่จะอธิบายสถาปัตยกรรมก่อนแสดงให้เห็นว่าทำไมคุณควรสนใจ
  • สัปดาห์ 3–4: ศึกษาเปเปอร์ 10 ชิ้นเพื่อเอาวิธีวิทยา ไม่ใช่เพื่อค้นพบ
    • เปเปอร์ BLEU score ต้นฉบับ, เปเปอร์ Constitutional AI ของ Anthropic, เปเปอร์ PageRank ของ Google, บันทึก Netflix Prize, เปเปอร์ Scaling Laws
    • เขียนว่า: อะไรทำให้วิธีวิทยานั้นงดงาม อินไซต์เดียวที่ทำให้มันใช้ได้ และจะประยุกต์กับโดเมนของฉันอย่างไร
    • คุณจะพบว่าหลักการเชิงโครงสร้างอย่างเกณฑ์ประเมินที่ชัดเจน การเปิดเผยข้อจำกัดอย่างตรงไปตรงมา และการตั้งรูปแบบอย่างเรียบง่ายแทนความซับซ้อน ปรากฏซ้ำข้ามสาขา

• เดือนที่ 2: สร้างรสนิยมแบบเข็มทิศผ่านการแยกแยะเชิงรุก

  • แบบฝึกหัดรายสัปดาห์ “Side-by-Side”: หา 2 ตัวอย่างประเภทเดียวกัน แล้วเขียน 500 คำว่าทำไมอันหนึ่งจึงดีกว่าอีกอัน (เอกสาร API สองชุด, บล็อกเทคนิคสองบท, แผนภาพสถาปัตยกรรมสองแบบ, เฟรมเวิร์กการประเมินสองชุด)
    • ห้ามใช้คำว่า “ชอบมากกว่า” ต้องระบุกลไกอย่างเป็นรูปธรรมเสมอว่า “สิ่งนี้ดีกว่าเพราะ…”
    • ตัวอย่าง: เอกสารของ Stripe ดีกว่าเพราะจัดโครงสร้างตาม สิ่งที่นักพัฒนาต้องการทำ (ส่งการชำระเงิน จัดการข้อผิดพลาด) ไม่ใช่ตามสถาปัตยกรรมภายใน
  • แบบฝึกหัดรายวัน “Practice Noticing”: ทุกครั้งที่ดูเครื่องมือ เปเปอร์ หรือโค้ด ให้เลือกการตัดสินใจหนึ่งอย่างของผู้สร้าง แล้วจดหนึ่งประโยคว่า “ทำไมถึงเป็นสิ่งนี้ ไม่ใช่ทางเลือกที่เห็นชัดอยู่แล้ว” หลังครบ 30 วัน รูปแบบในข้อสังเกต 30 ข้อจะกลายเป็นรสนิยมที่กำลังก่อตัว

• เดือนที่ 3: สร้างรสนิยมแบบวิสัยทัศน์ผ่านการประยุกต์เชิงสร้างสรรค์

  • สัปดาห์ที่ 9: ออกแบบสิ่งที่คุณเป็นเจ้าของใหม่ (โฟลว์ onboarding ของทีม, README ของโปรเจกต์, developer experience ของ evaluation pipeline) โดยใช้สิ่งที่เรียนมา
  • สัปดาห์ที่ 10: เขียนงานที่แม่นยำที่สุดเท่าที่เคยเขียน ไม่ใช่ชิ้นที่ยาวที่สุดหรือครอบคลุมที่สุด แต่เป็นงานที่ทุกย่อหน้าทำหน้าที่ของตัวเอง และเปลี่ยนวิธีคิดของผู้อ่าน
  • สัปดาห์ที่ 11: ออกแบบระบบจากศูนย์ แล้วอธิบายทุกการตัดสินใจด้วย first principles ไม่ใช่ด้วยธรรมเนียม (“ใช้ microservices เพราะเป็น best practice” แต่เป็น “ทีมมี 4 คน, ทราฟฟิกคาดการณ์ได้, และความเรียบง่ายในการ deploy มีค่ามากกว่าประโยชน์ด้านการสเกลที่ยังไม่จำเป็นใน 18 เดือน จึงใช้ monolith”)
  • สัปดาห์ที่ 12: แชร์รสนิยม สอนความแตกต่างของสองแนวทาง และเขียน AGENTS.md สำหรับโค้ดเบสของตัวเอง เพราะความสามารถในการเข้ารหัสรสนิยมลงในระบบและเอกสารคือเส้นแบ่งระหว่างทักษะส่วนบุคคลกับศักยภาพขององค์กร

โปรเจกต์ 5 อย่างเพื่อเร่งการสร้างรสนิยม

• 1. สร้างเฟรมเวิร์กประเมินสำหรับโค้ดที่ AI สร้าง

  • ไม่ใช่ linter หรือ test runner แต่เป็นเฟรมเวิร์กที่ตอบคำถามว่า “โค้ด AI นี้พร้อมพอสำหรับ production หรือไม่” โดยกำหนด rubric ของตนเองขึ้นมา (ความถูกต้อง, การบำรุงรักษา, ประสิทธิภาพ, ความปลอดภัย, สไตล์)
  • นำไปใช้และให้คะแนนกับ PR ที่ AI สร้างจริง 50 รายการ ปรับ rubric โดยอิงจากคะแนนที่น่าประหลาดใจ เผยแพร่ผลลัพธ์ และสร้างรสนิยมใน Zone 3 (การตัดสินคุณภาพ)

• 2. ออกแบบการ onboarding โปรเจกต์โอเพ่นซอร์สใหม่

  • fork เครื่องมือที่แม้จะเคารพในเทคนิคแต่ onboarding ชวนอึดอัด แล้วออกแบบประสบการณ์นักพัฒนาใน 5 นาทีแรกใหม่ เขียน README และคู่มือเริ่มต้น จัดโครงสร้างให้ผู้มีส่วนร่วมหน้าใหม่สามารถส่ง PR ได้ตั้งแต่วันแรก
  • สร้าง Zone 4 (ความเข้าอกเข้าใจผู้ใช้) และ Zone 5 (การสื่อสาร) ไปพร้อมกัน

• 3. สร้าง “แบบทดสอบรสนิยม” สำหรับทีม

  • เขียนเอกสารคู่แนวทางการ implement 10 คู่ โดยในแต่ละคู่มีฝั่งหนึ่งที่มีรสนิยมดีกว่า แล้วถามวิศวกร 5 คนว่าฝั่งไหนดีกว่าและเพราะอะไร
  • ผลลัพธ์ที่น่าสนใจไม่ใช่คำตอบที่ถูกต้อง แต่คือ ความเห็นที่ไม่ตรงกัน จุดที่มาตรฐานคลาดเคลื่อนคือรากของบั๊ก หนี้เทคนิค และการทำงานซ้ำ สร้าง รสนิยมขององค์กร ที่มี leverage สูงที่สุด

• 4. เปิดตัวผลิตภัณฑ์ภายใต้ข้อจำกัด 48 ชั่วโมง

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

• 5. เขียนบล็อกเทคนิคที่เปลี่ยนวิธีคิด

  • ไม่ใช่ tutorial หรือ how-to แต่เป็นบทความที่จัดองค์ประกอบแนวคิดที่คุ้นเคยขึ้นใหม่จนผู้อ่านมองมันต่างออกไปในภายหลัง (การตระหนักว่ารสนิยมก็คือการประเมิน, การมองว่าการลบโค้ดทุกครั้งที่มี model release ไม่ใช่แค่ธรรมเนียม แต่เป็นปรัชญาด้านสถาปัตยกรรม)
  • สร้าง Zone 5 (การสื่อสาร·การเล่าเรื่อง) โดยมุมมองที่แท้จริงคือรากฐานของรสนิยมทั้งหมด

เพิ่มประสิทธิภาพเส้นทางอาชีพโดยยึดรสนิยมเป็นศูนย์กลาง

• หยุดแข่งขันเรื่องความเร็ว

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

• ลงทุนกับ ‘ทักษะข้างเคียง’ ที่รสนิยมต้องการ

  • จุดร่วมของวิศวกรระดับท็อปคือพวกเขาไม่ได้เป็นแค่ coder, Boris เป็นผู้ก่อตั้งสตาร์ตอัป, Emma เป็นผู้นำด้าน data infrastructure ที่ Stripe นาน 4 ปี, Peter ขยาย PSPDFKit จนเป็นธุรกิจระดับโลก
  • รสนิยมต้องมี วัตถุดิบตั้งต้น ความคิดเชิงผลิตภัณฑ์ การรับรู้ด้านดีไซน์ ความเข้าใจธุรกิจ และความสามารถในการสื่อสาร คือวัตถุดิบที่ทำให้รสนิยมเกิดขึ้นได้

• เลือกบทบาทที่ให้รางวัลกับรสนิยม

  • บทบาทที่ทำตามสเปกที่นิยามไว้อย่างชัดเจนให้ค่ากับความเร็ว ส่วนบทบาทที่ต้องตัดสินใจว่าจะสร้างอะไร อย่างไร และแค่ไหนถึงเพียงพอ จะให้รางวัลกับรสนิยมโดยตรง
  • บทบาทที่รสนิยมได้รับผลตอบแทนสูงเป็นพิเศษ: วิศวกรผู้ก่อตั้งในสตาร์ตอัประยะเริ่มต้น, tech lead ในบริษัทผลิตภัณฑ์, วิศวกรแพลตฟอร์ม·อินฟราที่ออกแบบระบบให้วิศวกรคนอื่นขึ้นมาทำงานต่อได้, วิศวกรด้านประสบการณ์นักพัฒนา, วิศวกร staff+ ที่ดูแลการตัดสินใจด้านสถาปัตยกรรมข้ามทีม

• สร้างผลงานสาธารณะที่สะท้อนรสนิยม

  • ในยุค AI portfolio สำคัญกว่าเรซูเม่ หลักฐานอยู่ที่ผลลัพธ์ที่สร้างออกมา (โอเพ่นซอร์สที่ออกแบบมาดี, บล็อกเทคนิคที่มีมุมมองสม่ำเสมอ, ผลิตภัณฑ์ที่ผู้คนใช้งานจริง)
  • OpenClaw ของ Peter พูดได้ดังกว่าเรซูเม่ใด ๆ และต้นแบบ Claude Code ของ Boris ก็พิสูจน์รสนิยมได้ดีกว่าคำตอบในการสัมภาษณ์เชิงพฤติกรรมใด ๆ

ความจริงที่ไม่น่าพอใจ

• รสนิยมกระจายอย่างไม่เท่ากัน และจะยังคงเป็นเช่นนั้นต่อไป บางคนสั่งสมมันจากการตัดสินใจหลายพันครั้งตลอด 15 ปี จึงมีจุดเริ่มต้นที่ตามให้ทันไม่ได้ด้วยแผน 90 วัน
  • ทีม Codex ทำงานในบริษัทที่สร้างโมเดลและเข้าถึงโทเค็นได้ไม่จำกัด ส่วน Peter มีจุดเริ่มต้นที่ไม่ธรรมดาจากประสบการณ์ 20 ปีและการ exit บริษัทมาแล้ว
• แต่ช่องว่างระหว่าง “ไม่มีรสนิยม” กับ “มีรสนิยมอยู่บ้าง” นั้นมหาศาลในแง่ผลกระทบต่ออาชีพ และ อุดได้ การก้าวจากคนที่รับ ticket แล้ว implement ไปเป็นคนที่เสนอว่าจะสร้างอะไรผ่าน user research และใช้ AI implement ไปจนถึงการทดสอบและสถาปัตยกรรม นั่นแหละคือรสนิยม
• คำยอมรับอย่างตรงไปตรงมาของ Gergely Orosz: “มันเหมือนมีบางสิ่งที่มีคุณค่าถูกพรากไปอย่างกะทันหัน การจะเขียนโค้ดให้เก่งต้องใช้ความพยายามมาก และความทรงจำที่ดีที่สุดคือการจดจ่อแล้วพิมพ์ไอเดียออกมา”
  • ความรู้สึกสูญเสียที่ทักษะการเขียนโค้ดด้วยมือลดความสำคัญลงนั้นเป็นเรื่องจริง แต่ ความสามารถในการรู้ว่าโค้ดแบบไหนควรมีอยู่ ควรถูกจัดโครงสร้างอย่างไร และเมื่อไรจึงถือว่าเพียงพอ คือความสามารถที่แท้จริงมาโดยตลอด
• วิศวกรที่จะรุ่งเรืองต่อจากนี้คือคนที่ตระหนักถึงสิ่งนี้ รสนิยมคือหน้าที่ของงานนี้มาเสมอ เพียงแต่ก่อนหน้านี้มันซ่อนอยู่ในตัวโค้ด และ AI ที่เข้ามารับหน้าที่พิมพ์แทนก็ทำให้มันปรากฏชัด

[clastneo]

โอ้ ตอนนี้แค่ 10x ก็ไม่พอแล้วสินะ ต้องเริ่มคิดถึง 30x แล้วเหรอ 555

[channprj]

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