• เครื่องมือโค้ดดิ้งแบบเอเจนต์ Claude Code ไม่ได้เปลี่ยนแค่การเขียนโค้ด แต่สร้างการเปลี่ยนแปลงครั้งใหญ่กว่ากับการสร้างผลิตภัณฑ์และการจัดโครงสร้างเวิร์กโฟลว์ใหม่
  • ผลสำรวจผู้ใช้ AI สำหรับงานของ Microsoft พบทั้งแรงกดดันให้รับ AI อย่างรวดเร็ว การสร้างผลงานแบบใหม่ และเวลาที่เพิ่มขึ้นสำหรับงานที่มีมูลค่าสูงกว่า แต่ รางวัลสำหรับการทดลองใช้ AI ยังอยู่ในระดับต่ำ
  • หากองค์กรตั้งเป้าแค่ปริมาณการใช้งาน ก็จะเกิด กระดานจัดอันดับโทเค็น และการปั่นตัวเลขการใช้งาน ดังนั้นตัวชี้วัดที่เชื่อมโยงกับการสร้างคุณค่าด้วย AI จึงสำคัญกว่า
  • Boris Cherny มองว่าตำแหน่งวิศวกรอาจเปลี่ยนไปสู่บทบาทที่ใกล้กับ builder มากขึ้น คนที่ไม่ใช่วิศวกรก็สร้างโค้ดได้ ส่วนวิศวกรจะโฟกัสกับการตัดสินใจ การวางแผน และความเข้าใจผู้ใช้ มากกว่าการพิมพ์โค้ดเองโดยตรง
  • การเพิ่มผลิตภาพด้วย AI ไม่ได้หมายความว่าจะนำไปสู่การลดเวลาทำงานหรือการลดงานเสมอไป แต่บริษัทจะปรับเวิร์กโฟลว์ใหม่ให้มี AI เป็นศูนย์กลาง และแต่ละคนจะมี ทางเลือกและอำนาจทวีคูณ มากขึ้น

ข้อมูลการทำงานด้วย AI และกับดักของตัวชี้วัดองค์กร

  • Microsoft สำรวจ ผู้ใช้ 20,000 คนที่ใช้ AI ในงานจริง และพบสิ่งที่เรียกว่า "paradox of transformation"
    • 65% กังวลว่าหากไม่รับ AI อย่างรวดเร็วจะตามคนอื่นไม่ทัน
    • 58% กำลังสร้างผลงานที่เมื่อ 1 ปีก่อนยังทำไม่ได้ แต่ตอนนี้ทำได้ด้วย AI
    • 66% ตอบว่าด้วย AI ทำให้พวกเขามีเวลาไปทำงานที่มีมูลค่าสูงกว่า
    • แต่ในทางกลับกัน มีเพียง 13% ที่ตอบว่าได้รับ รางวัลจากที่ทำงาน สำหรับการทดลองใช้ AI แสดงให้เห็นช่องว่างระหว่างความตั้งใจใช้งานกับองค์กร
  • งานวิจัยอีกชิ้นของ Microsoft พบว่า หากผู้จัดการแสดงให้เห็นการใช้ AI ด้วยตัวเองโดยตรง การใช้งานจะเพิ่มขึ้น 17% และความเชื่อมั่นต่อเอเจนต์เพิ่มขึ้น 30%
    • มากกว่าคำขวัญทำนองว่า "AI คืออนาคต" ผลลัพธ์จะดีกว่าถ้าผู้จัดการแสดง วิธีใช้งานจริงแบบเฉพาะเจาะจงของตนเอง
    • หากพนักงานเชื่อว่าพวกเขาจะได้แบ่งปันผลลัพธ์จากผลิตภาพที่ดีขึ้นด้วย AI แรงจูงใจในการใช้ก็อาจเปลี่ยนไป แต่แทบไม่มีที่ใดที่ ให้รางวัลเป็นเงิน ในลักษณะนี้
  • บางที่ทำงานช่วยอุดหนุนค่าโทเค็น แต่การสนับสนุนนั้นก็ไม่ได้จบลงด้วยผลลัพธ์ที่ดีเสมอไป

Token maxing — ผลข้างเคียงของตัวชี้วัดการใช้งาน

  • ในบรรดาบริษัทเทคโนโลยีรายใหญ่ เกิดปรากฏการณ์ token maxing คือการใช้โทเค็นเกินจำเป็นเพื่อดันตัวเลขการใช้งาน
    • พนักงาน Amazon บอกกับ Financial Times ว่า Amazon นำเครื่องมือภายในชื่อ mesh claw ที่ได้แรงบันดาลใจจาก OpenClaw มาใช้และส่งเสริมการใช้งาน
    • ภายในทีมมี ตารางจัดอันดับการใช้โทเค็น ทำให้พนักงานบางคนรันเอเจนต์ที่ไม่ก่อให้เกิดประโยชน์เพียงเพื่อปั่นยอดการใช้
    • ที่ Meta มีการใช้งานสูงสุดถึงระดับหลายแสนล้านโทเค็น และปริมาณที่มีค่าใช้จ่ายระดับหลายล้านดอลลาร์นั้นแทบถูกใช้ไปอย่างสูญเปล่า
  • จุดยืนอย่างเป็นทางการของ Amazon คือปริมาณการใช้โทเค็นไม่ใช่ตัวชี้วัดในการประเมินผู้จัดการ แต่พนักงานเชื่อว่าผู้จัดการมองตัวเลขนี้อยู่ จึงพยายามเพิ่มยอดการใช้งานดิบ
    • ภายใน Amazon มีเป้าจากผู้บริหารให้ นักพัฒนา 80% ใช้ AI ทุกสัปดาห์
    • หากไม่มีรางวัลที่ชัดเจน ผู้คนก็จะทำตามแค่คำว่า "ใช้ AI" แต่พลาดเจตนาเดิมที่ว่า "ทำงานให้ดีขึ้น"
    • สำหรับนักพัฒนา สิ่งที่ต้องการอย่างชัดเจนกว่าการติดตามแบบคลุมเครือ คือ ตัวชี้วัดด้านผลิตภาพที่เชื่อมโยงกับการสร้างคุณค่า

การถือกำเนิดของ Claude Code และการแพร่กระจายอย่างรวดเร็ว

  • Claude Code คือเครื่องมือโค้ดดิ้งแบบเอเจนต์ที่ Anthropic เปิดตัวเมื่อเดือนพฤษภาคมปีก่อน เป็น เครื่องมือที่พิมพ์คำแล้วได้โค้ดออกมา
    • ภายใน 8 เดือนหลังเปิดตัว รับผิดชอบโค้ดราว 4% ของโค้ดทั้งหมดที่ขึ้น GitHub
    • ในเดือนกุมภาพันธ์ของปีนั้นแตะ annual revenue run rate 2.5 พันล้านดอลลาร์ เป็นผลิตภัณฑ์องค์กรที่ไปถึงระดับนั้นได้เร็วที่สุด
    • ผู้สร้าง Boris Cherny จบสาย เศรษฐศาสตร์ โดยไม่มีปริญญาวิทยาการคอมพิวเตอร์ ลาออกจากมหาวิทยาลัยตอนอายุ 18 ไปทำสตาร์ตอัป ผ่านงานที่เฮดจ์ฟันด์ และทำงานเป็นวิศวกรหลักที่ Meta 5 ปีก่อนเข้าร่วมในปลายปี 2024
    • ปัจจุบัน Cherny ไม่เขียนโค้ดเองแม้แต่บรรทัดเดียว แต่ รันเอเจนต์ 5 ตัวแบบขนานในแท็บเทอร์มินัล 5 แท็บ และจัดการ pull request ได้วันละ 20–30 รายการ
  • จุดเริ่มต้นไม่ได้มาจากภารกิจให้สร้างเครื่องมือเขียนโค้ด แต่เริ่มจาก โปรเจกต์ข้างเคียง ระหว่างเรียนรู้ API
    • ช่วงแรกเป็นแค่การเชื่อม Claude เข้ากับ AppleScript เพื่อแสดงเพลงที่เขากำลังฟัง
    • ภายในสองเดือนก็มี Claude Code เวอร์ชันแรก และ วันแรกมีทีมวิศวกรรมของ Anthropic 20% ใช้งาน
  • เขาเข้าร่วมในเดือนกันยายน 2024 และอยู่ในทีมเล็กมากชื่อ labs team
    • ทีมนี้สร้าง Claude Code, MCP, skills และแอปเดสก์ท็อป โดยมีไอเดียเชิงทดลองหลายอย่างที่ยังไม่รู้ว่าจะสำเร็จหรือไม่
    • Anthropic เดิมทีโฟกัสด้านองค์กร การเขียนโค้ด และความปลอดภัย จึงมองว่าหากจะสร้างผลิตภัณฑ์สักอย่าง ผลิตภัณฑ์เขียนโค้ดที่ ช่วยทั้งโมเดลโค้ดดิ้งที่ดีขึ้นและงานวิจัยด้านความปลอดภัย ก็สมเหตุสมผล
  • ในเวลานั้นผลิตภัณฑ์โค้ดดิ้งส่วนใหญ่เป็น ส่วนขยาย IDE และในระดับ Sonnet 3.5 ก็ยังใกล้เคียงกับ autocomplete ขั้นสูง
    • พวกเขารับรู้ถึง model overhang คือโมเดลทำได้มากกว่านั้น แต่ยังไม่มีผลิตภัณฑ์ที่ดึงความสามารถออกมา และความรู้สึกนี้ยังคงเหมือนเดิมจนถึงตอนนี้
    • จึงสร้างเวอร์ชันที่ถูกที่สุดซึ่ง ทำงานในเทอร์มินัลโดยไม่มี UI หรือแอปแยก ภายในเวลาไม่กี่วัน
    • ผู้ใช้เริ่มกระจายจากคนรอบตัว ก่อนที่ในไม่กี่สัปดาห์คนจำนวนมากในบริษัทจะใช้ทุกวัน และ ภายใน 5 วันหลังเปิดตัว ทีมวิศวกรรมครึ่งหนึ่งใช้งานแล้ว
    • แม้แต่วิศวกรที่ไม่ชอบเทอร์มินัลก็ยังใช้งาน และ Cherny บอกว่าแทนที่จะวิเคราะห์ว่า "วิศวกรรมซอฟต์แวร์เปลี่ยนไปตลอดกาลแล้ว" เขากลับ โฟกัสที่การปล่อยผลิตภัณฑ์เท่านั้น

วิศวกรจะหายไปหรือไม่ — การผสมกันของบทบาท

  • ความช็อกครั้งแรกคือ ตอนที่ Claude บอกเพลงที่เขากำลังฟังอยู่ได้
    • เมื่อถามคำถาม Claude ก็เขียนโค้ด AppleScript เพื่อเปิดตัวเล่นเพลงขึ้นมา โดย Cherny ไม่รู้ภาษานี้ และไม่เคยคิดด้วยซ้ำว่าจะตอบปัญหาแบบนั้นได้
    • มันคือการแก้ปัญหาในแบบที่ วิศวกรอาจไม่ได้เลือกเอง
  • โมเดลพัฒนาเร็วมาก จนเมื่อสร้างผลิตภัณฑ์บนโมเดลจึงต้อง ปรับจูนใหม่ทุกเดือน
    • Co-work เคยจองเที่ยวบิน 8 เที่ยวและโรงแรม 5 แห่ง โดยความผิดพลาดเดียวคือโรงแรมคืนละประมาณ 5,000 ดอลลาร์ ทำให้งบเกิน และต้องจองใหม่เฉพาะรายการนั้น
  • แนวโน้มเป็นแบบ เส้นโค้งเอ็กซ์โปเนนเชียล จึงไม่มีใครบอกได้แม่นยำ และมี 2 สิ่งเกิดขึ้นพร้อมกัน
    • บริษัทที่ต้องการ วิศวกรน้อยลงสำหรับงานเท่าเดิม เพราะผลิตภาพของวิศวกรสูงขึ้น
    • บริษัทที่ต้องการ วิศวกรมากขึ้น เพราะผลิตภาพต่อคนสูงขึ้นจนสร้างผลิตภัณฑ์และธุรกิจได้มากกว่าเดิม (ทีมของ Cherny ยังติดที่หาคนเก่งไม่พอและกำลังรับคนให้เร็วที่สุด)
  • บทบาทต่าง ๆ กำลัง ผสมกันอย่างน่าสนใจ
    • ผู้จัดการ Fiona ไม่ได้เขียนโค้ดมา 15 ปี แต่กลับมาเขียนหลังเข้าร่วมทีม เช่นเดียวกับโปรดักต์แมเนเจอร์ Cat และดีไซเนอร์ Megan ที่ทั้งทีมต่างก็เขียนโค้ด
    • คนที่ไม่ใช่วิศวกรเริ่มเขียนโค้ดมากขึ้นเล็กน้อย ขณะที่วิศวกรอย่าง Cherny ไม่ได้เขียนโค้ดเองมานานกว่า 6 เดือน แต่ก็ยังสร้างของตลอดทั้งวัน
    • จะเรียกสิ่งนี้ว่า builder, engineer หรือ product manager ยังไม่แน่ชัด แต่บทบาทนั้นเปลี่ยนไปอย่างชัดเจน

อุปมาเรื่องรถแทรกเตอร์ — เวลาของการกระจายตัวของเทคโนโลยี

  • รถแทรกเตอร์ถูกคิดค้นโดย John Frick ในรัฐ Iowa ช่วงทศวรรษ 1890 แต่ต้องรอถึงทศวรรษ 1960 กว่าในสหรัฐฯ จำนวนรถแทรกเตอร์จะมากกว่าม้า ใช้เวลาราว 70 ปี
    • รถแทรกเตอร์เพิ่มผลผลิตและผลิตภาพได้มาก แต่ต้องมี การฝึก เพื่อเรียนรู้การใช้งาน และช่วงแรกก็มีราคาแพงจนม้ายังถูกกว่า
    • สมรรถนะก็ยังจำกัด เช่น ใช้กับข้าวสาลีได้แต่ใช้กับข้าวโพดไม่ได้ และต้องใช้เวลานานกว่าจะปรับให้เหมาะกับพืชหลายชนิด
    • การเปลี่ยนผ่านสู่ AI ตอนนี้คือการที่ปัญหาแบบเดียวกันเกิดขึ้นแบบ speedrun
  • สิ่งนี้เชื่อมโยงกับมุมมอง AI as normal technology — แม้จะมีโมเดลที่เก่งมากออกมา การเปลี่ยนแปลงของคนและองค์กรก็ยังช้า
    • แต่ถ้าดูจากแนวโน้มรายได้ของ Anthropic ก็มีข้อโต้แย้งว่าครั้งนี้ความเร็วต่างออกไป จึงยังอยู่ในช่วงประเมินว่า ความเปลี่ยนแปลงจริงเร็วแค่ไหน
  • คอมพิวเตอร์ช่วยเพิ่มผลิตภาพ แต่ไม่ได้แปลว่า เวลาทำงานจะลดลงทันที — มันมักหมายถึงการทำงานได้มากขึ้นในเวลาเท่าเดิม

การเขียนโค้ดถูก "แก้ได้แล้ว" หรือยัง

  • คำว่า "coding is solved" เป็นคำพูดที่ จำกัดอยู่กับ "การเขียนโค้ดแบบที่ฉันทำ"
    • งานของ Cherny เช่น cloud CLI, แอปเดสก์ท็อป และแอปมือถือ เป็นโค้ดเบสที่ค่อนข้างใหม่และเรียบง่าย
    • แต่สำหรับลูกค้ารายใหญ่ที่มีโค้ดเบสขนาดใหญ่และซับซ้อนอย่าง NASA มันยังไม่ถูกแก้ และโมเดลเองก็ยังไม่สมบูรณ์แบบและทำผิดพลาดได้
  • ข้อโต้แย้งของวิศวกรที่ว่าการเขียนโค้ดไม่ใช่แค่การพิมพ์ แต่คือ การตัดสินใจ เซนส์ และการคิดเชิงวิพากษ์ ซึ่งเอเจนต์ยังอ่อนในด้านนี้ ก็เป็นข้อโต้แย้งที่มีน้ำหนัก
    • แต่เดิมในหนึ่งวันของ Cherny เอง มีแค่ประมาณ 50% เท่านั้นที่เป็นการพิมพ์โค้ดจริง ที่เหลือคือคุยกับผู้ใช้ ระดมความคิด ดีบัก ออกแบบ และวางแผน
    • เมื่อให้โมเดลทำส่วนโค้ด วิศวกรก็ถูกปลดปล่อยไปทำงานที่ สนุกกว่า อย่างการคุยกับผู้ใช้และคิดสิ่งถัดไป
  • Claude Code ถูกเขียนด้วย Claude Code 100% มานานเกิน 6 เดือนแล้ว และผลิตภัณฑ์อื่นอย่าง Co-work ก็เช่นกัน
    • ในวงสนทนาของ Y Combinator รุ่นล่าสุด เมื่อถามว่า "ใครเขียนโค้ด 100% ด้วย Claude Code" มีคนยกมือราวครึ่งห้องจากหลายร้อยคน ส่วนคำถามว่า "ใครไม่เขียนด้วยโมเดลเลย" มีเพียงคนเดียว ที่เหลืออยู่ระหว่าง 50–100%
    • เขามองว่า การเปลี่ยนแปลงในวงการวิศวกรรมเป็นตัวชี้นำล่วงหน้าของทุกสาขานอกวิศวกรรม
  • ความกังวลเรื่องทักษะถดถอยและวิวัฒนาการของการเขียนโปรแกรม

    • มีความกังวลว่าหากไม่เขียนโค้ดเองโดยตรง ความเข้าใจในงานอาชีพของตนอาจ ฝ่อลง (atrophy)
      • วิศวกรในทีมชื่อ Lena ยังเขียน C++ ด้วยมือตอนสุดสัปดาห์เพื่อความสนุก และพื้นที่แบบนั้นก็จะยังมีอยู่เสมอ
      • Cherny มองว่านี่ไม่ใช่การถดถอย แต่เป็น กระแสการเปลี่ยนแปลงของการเขียนโปรแกรมที่เกิดขึ้นมาตลอด
        • ในยุคโซเวียต บัตรเจาะรู และการคำนวณด้วยมือบนกระดาษในยุคโครงการ Apollo ก็เคยถูกนับว่าเป็น "การเขียนโปรแกรม"
        • ต่อมาจาก machine code → assembly → JavaScript·Python และตอนนี้กำลังเปลี่ยนเป็น การคุยกับเอเจนต์ และในไม่ช้าก็อาจเปลี่ยนอีกครั้งเป็น เอเจนต์คุยกับเอเจนต์เพื่อเขียนโค้ด
      • มันคล้ายกับการที่บางส่วนของทักษะคณิตศาสตร์เสื่อมลงเพราะเครื่องคิดเลขวิศวกรรม แต่เราก็ยังใช้เครื่องคิดเลขต่อไป ต่างกันเพียงว่าถ้าเครื่องมือนั้นกลายเป็นซูเปอร์อินเทลลิเจนซ์และ บ่อนทำลายผู้ใช้แบบแนบเนียน นั่นก็เป็นอีกปัญหาหนึ่ง
  • ข้อถกเถียงเรื่องโมเดลถดประสิทธิภาพ

    • หลังมีการปล่อยโมเดลใหม่ มักมีเสียงต้านเป็นระยะว่า "ประสิทธิภาพถดลงมาก"
      • มีกรณีที่เกิดจากบั๊กจริง 2 กรณี และ Anthropic ก็เปิดเผยสาเหตุและวิธีแก้ไว้ในบล็อก
      • ส่วนที่เหลือส่วนใหญ่อาจเป็นปรากฏการณ์แบบ ช่วงฮันนีมูน ที่เมื่อคุ้นกับโมเดลแล้ว ความน่าทึ่งในช่วงแรกก็ลดลง
    • ต่างจากเมื่อ 1 ปีก่อน ตอนนี้ โค้ดของโมเดลดีกว่าโค้ดที่ Cherny จะเขียนเองโดยตรง
      • เมื่อก่อนต้องตรวจทีละบรรทัดสามรอบ แต่ตอนนี้เขามอบหมายให้ Claude ทำ แล้วให้ Claude กลับมาตรวจผลและทดสอบอีกที พร้อมกับ รัน Claude 15 ตัวแบบขนาน

paradox ของผลิตภาพและการขยายทางเลือก

  • แม้ผลิตภาพจะสูงขึ้น เวลาทำงานก็อาจไม่ลดลง ซึ่งส่วนใหญ่ขึ้นอยู่กับทางเลือกของแต่ละคนและสถานการณ์ของบริษัท
  • เขาอธิบายด้วย เรื่องเล่าเกี่ยวกับเครื่องซักผ้า
    • ก่อนมีเครื่องซักผ้า การซักผ้าแต่ละครั้งใช้เวลา 5–6 ชั่วโมง และต้อง เดินราว 3,000 ฟุต พร้อมทั้งก่อไฟ ต้มน้ำ ขยี้ผ้าบนกระดานซัก และบิดน้ำ ทำซ้ำทุกวันตามจำนวนสมาชิกในครอบครัว
    • เครื่องซักผ้าช่วยลดเวลาการซักลงราว 3 ชั่วโมง ต่อครั้ง
    • นี่เป็นหนึ่งใน ปัจจัยที่ทำให้ผู้หญิงเข้าสู่ตลาดแรงงานจำนวนมากได้
    • เวลาที่ประหยัดได้กลายเป็น ทางเลือกของแต่ละคน ไม่ว่าจะใช้เวลาอยู่กับลูก เดินเล่น อ่านหนังสือ พบเพื่อน หรือเข้าสู่งานโรงงานและงานออฟฟิศ ซึ่ง AI ก็ขยายทางเลือกในลักษณะเดียวกัน
  • คำแนะนำสำหรับคนอายุ 22 ที่เพิ่งเรียนจบ CS คือ งานระดับเริ่มต้นยังคงมีอยู่ แต่ถ้ามีแนวโน้มอยากเริ่มธุรกิจแม้เพียงเล็กน้อย เขาแนะนำให้ ก่อตั้งสตาร์ตอัป
    • นี่คือ ยุคทอง ที่ดีที่สุดในประวัติศาสตร์สำหรับการเริ่มต้นธุรกิจ เพราะ "คุณกับเหล่าเอเจนต์" สามารถสร้างบริษัทขนาดใหญ่ได้
    • ตอนนี้มีทีม 1–3 คนที่กำลังสร้างบริษัทระดับพันล้านดอลลาร์และสตาร์ตอัปที่ยอดเยี่ยมอยู่จริง และ อำนาจทวีคูณของคนคนเดียวมีสูงมาก
  • อีก 3 ปีข้างหน้าเราอาจไม่เรียกมันว่า "วิศวกร" อีกต่อไป แต่จำนวนคนที่ เขียนโค้ดหรือสร้างโค้ดผ่านเอเจนต์ จะมากกว่าวันนี้ถึง 100 เท่า

Claude Co-work — การขยายไปสู่คนนอกสายวิศวกรรม

  • Co-work เริ่มต้นจากการเห็นผู้คน ติดตั้ง Claude Code ในเทอร์มินัลเพื่อทำภาษี และใช้งานกับเรื่องที่ไม่ใช่การเขียนโค้ด
    • ใช้กับงานที่ไม่ใช่วิศวกรรมได้หลากหลาย ทั้งบัญชี การเงิน กฎหมาย การจองเที่ยวบิน การซื้อตั๋วคอนเสิร์ต ไปจนถึงการซื้อ ใบอนุญาตจับหอยในรัฐวอชิงตัน
    • ผลิตภัณฑ์โค้ดดิ้งในอดีตมักเป็นสิ่งที่วิศวกรสร้างเพื่อตัวเองแล้วกลายเป็นว่าคนอื่นใช้ได้ด้วย แต่ Co-work เป็นความท้าทายใหม่ที่ สร้างมาเพื่อคนนอกสายวิศวกรรมโดยรวม
  • ความสามารถในการรันงานยาวนานคือทิศทางหลัก
    • ราว 1 ปีกว่าก่อนหน้านี้ Claude Code ยังติดข้อจำกัดของโมเดลจน หลุดออกนอกเส้นทางหลังผ่านไปแค่ 30 วินาที และต้องมีคนเข้าไปแทรกแซง
    • ตอนนี้ทุกคืนมีเอเจนต์หลายร้อยถึงหลายพันตัว รันต่อเนื่อง 5, 10, 20 ชั่วโมง และนี่คือรูปแบบการทำวิศวกรรมในปัจจุบัน
    • Co-work ก็จะมุ่งไปทางเดียวกัน แต่ยังไม่ชัดว่าในงานแบบใดบ้างที่ต้องรันยาวขนาดนั้น
  • เมื่อ memory และความเข้าใจผู้ใช้ดีขึ้น ก็จะพัฒนาไปสู่การ คาดการณ์ความต้องการล่วงหน้า
    • เช่น รู้ว่าพอดแคสต์เหลืออีกกี่ตอน ยังไม่ได้เชิญแขกคนไหน แล้วช่วยระดมความคิดหาผู้สมัคร พร้อมร่างอีเมลติดต่อครั้งแรกไว้ใน drafts
    • การนิยามงานอาจแบ่งเป็นแบบ แนวนอน เช่น "ออกแบบทั้งหมด" กับแบบ แนวตั้ง ที่ทำเป้าหมายเฉพาะให้เสร็จจนจบ
    • ตัวอย่างของแบบแนวตั้งคือ Claude สร้างฟีเจอร์ ทดสอบ รวมโค้ด และปล่อยใช้งานจนเสร็จ
  • ตั้งแต่ Opus 4.7 Claude มีความ proactive มากขึ้น
    • หลังปล่อยฟีเจอร์ มันสามารถ ตั้งเตือนด้วยตัวเองให้กลับไปเช็กฟีดแบ็กผู้ใช้หลังผ่านไป 12 ชั่วโมง และถ้ามีบั๊กก็พยายามแก้ ซึ่งช่วยจัดการสิ่งที่มนุษย์มักลืมและทำให้ความพึงพอใจสูงขึ้น
  • Claude Mythos ยังไม่ได้เปิดเผยต่อสาธารณะสำหรับคนส่วนใหญ่ และข้อมูลที่เปิดเผยออกมาส่วนใหญ่เกี่ยวกับ ประสิทธิภาพด้านโค้ดดิ้งและไซเบอร์ซีเคียวริตี้ — เป็นการก้าวกระโดดที่ใหญ่กว่าปกติและแข็งแกร่งเป็นพิเศษในสองด้านนี้

ใครควรรับผิดชอบต่อการแทนที่งาน

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

Power user และช่องว่าง AI

  • มีความกังวลว่า ช่องว่างดิจิทัลจะกลายเป็นช่องว่าง AI และข้อมูลจนถึงตอนนี้ชี้ว่าคนที่ใช้ AI ได้เกิดประโยชน์สูงสุดมัก ใกล้เคียงกับกลุ่มรายได้สูงอยู่แล้ว
    • Anthropic มีบางโครงการที่ช่วยขยายการเข้าถึง แต่ไม่ได้ระบุชื่อหรือวิธีการอย่างเป็นรูปธรรม
  • ผู้ใช้ที่ได้คุณค่าสูงสุดมักเป็น กลุ่มที่คาดไม่ถึง
    • ผู้ชนะ hackathon ตอนเปิดตัว Opus 4.7 ส่วนใหญ่มักไม่ใช่วิศวกรอาชีพ แต่เป็น ช่างไฟ แพทย์ หรือช่างไม้ ที่สร้างแอปขึ้นมา และ hackathon ของ 4.6 ก่อนหน้านั้นก็มีแนวโน้มเดียวกัน
    • โมเดลตอนนี้ละเอียดและเก่งพอที่ คนไม่ใช่ผู้เชี่ยวชาญก็ใช้งานได้ดี
  • หัวใจของการนำไปใช้ในองค์กรใหญ่คือ เปลี่ยนกระบวนการทำงานให้มี Claude เป็นศูนย์กลาง
    • วิธีที่ได้ผลวิธีหนึ่งคือ แจกโทเค็นให้ทุกคนได้ทดลองอย่างปลอดภัย เพื่อให้ไอเดียมาจากคนที่คาดไม่ถึง
    • ไอเดียที่ดีที่สุดอาจไม่ได้มาจากวิศวกรอาวุโส แต่อาจมาจาก คนบัญชีที่นั่งอยู่มุมหนึ่งหรือคนฝั่ง GTM ที่ทำแดชบอร์ดภายในขึ้นมา
    • ไม่มีอะไรรับประกันว่าคนที่ใช้เครื่องมือนี้เก่งที่สุดในวันนี้จะยังเก่งที่สุดในวันพรุ่งนี้ ดังนั้น การให้ทุกคนเรียนรู้การใช้เครื่องมือ จึงสำคัญ

มุมมองต่อ 1 ปีข้างหน้า

  • ปีหน้าจะมี ความสับสนวุ่นวายมาก และผู้เล่นรายใหญ่จะพยายามปรับตัว โดยหลายรายจะทำได้สำเร็จ
  • คูเมืองทางธุรกิจแบบดั้งเดิม บางอย่างจะอ่อนลง และบางอย่างจะยังคงอยู่
    • network effects (ยิ่งมีผู้ใช้มากยิ่งมีคุณค่า) จะยังอยู่ต่อโดยไม่เกี่ยวกับ AI
    • economies of scale (ต้นทุนส่วนเพิ่มลดลง) ก็เป็นข้อได้เปรียบตามธรรมชาติที่ไม่หายไป
    • แต่ switching costs จะอ่อนลง — ถ้า Claude ช่วยย้ายจาก vendor A ไป vendor B ได้ มันก็ไม่ใช่คูเมืองที่แข็งแรงอีกต่อไป
    • บริษัทที่พึ่งพาคูเมืองที่กำลังหายไปจะลำบาก ส่วนอีกหลายแห่งก็จะมองหาคูเมืองแบบใหม่
  • จะเกิดนวัตกรรมที่ ใหญ่กว่าที่คาดไว้อย่างมาก
    • ไอเดียใหม่ ๆ จะไม่ได้ไหลออกมาจากบริษัทยักษ์ใหญ่ แต่จะมาจาก สตาร์ตอัปเล็กขนาด 1, 2, 10 คน และจำนวนของพวกมันจะเพิ่มขึ้นแบบระเบิด
    • มีตัวอย่างสตาร์ตอัปด้าน การค้นพบวัสดุ ที่เล่าเรื่องจากยุคหิน ยุคเหล็ก จนถึงยุคซิลิคอน และมองว่าหากพบวัสดุใหม่ เราก็จะเข้าสู่ยุคถัดไป จึงใช้ Claude สำรวจโมเลกุลและการออกแบบที่เป็นไปได้
    • งานที่ในอดีตระดมทุนยังยาก ตอนนี้ ทีมเล็ก ๆ สามารถสร้างความก้าวหน้าที่เมื่อ 20 ปีก่อนเป็นไปไม่ได้
    • ถ้าคนที่เข้าใจโดเมนมี "กองทัพ Claude" อยู่ข้างตัว เขาจะทำงานได้มากกว่ายุคที่ต้องพึ่งพา "กองทัพมนุษย์" อย่างมหาศาล
  • Cherny ทำ ระบบอัตโนมัติสำหรับตอบผู้ใช้บน X และ Threads แล้ว แต่ยังชอบทำเองมากกว่า
    • เขาย้ายลูปของ Claude Code ไปเป็นงานประจำ ให้รันทุก 30 นาที และใช้ Threads API กับ X API เก็บฟีดแบ็ก
    • การโต้ตอบกับผู้ใช้โดยตรงคือสิ่งที่เขาชอบที่สุด และแม้แต่ฟีดแบ็กว่า "มันใช้ไม่ได้" ก็ยังเป็นแหล่งสำหรับปรับปรุงผลิตภัณฑ์
    • Claude Code ยังมีข้อบกพร่องมากและยังห่างจากผลิตภัณฑ์ในอุดมคติ แต่ การฟังฟีดแบ็กและค่อย ๆ ปรับปรุงทุกวัน คือวิธีเดียวในการสร้างผลิตภัณฑ์ที่ดี

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น