สูด AGI ผ่าน Claude Code
(kadekillary.work)- เสนอความเห็นเกี่ยวกับความเป็นไปได้ในการเข้าถึงปัญญาประดิษฐ์ทั่วไป (AGI) ผ่าน Claude Code
- ถ่ายทอดความประทับใจจากประสบการณ์จริงของผู้เขียนในการทำเซสชันเขียนโค้ดกับ Claude
- เน้นย้ำระดับความสามารถของ Claude ในด้าน ทักษะการเขียนโปรแกรม, องค์ความรู้ที่กว้างขวาง, และความคิดสร้างสรรค์
- กล่าวถึงความสามารถของ Claude ในการ เข้าใจบริบทและตีความโค้ด ที่แตกต่างจากเครื่องมือที่มีอยู่ในปัจจุบัน
- คาดการณ์ถึง ผลกระทบทางเทคนิค ต่อวิธีการพัฒนาและใช้งานปัญญาประดิษฐ์
บทนำ
- บทความนี้ถ่ายทอดความคิดของผู้เขียนเกี่ยวกับการเข้าใกล้ปัญญาประดิษฐ์ทั่วไป (AGI) ในระดับมนุษย์ หลังจากได้ลองประสบการณ์การเขียนโปรแกรมด้วย Claude Code
- ผู้เขียนรู้สึก ตกตะลึงและตื่นเต้น อย่างมากกับผลลัพธ์ที่ Claude แสดงให้เห็นในบรรดาเครื่องมือ AI เชิงสนทนาที่ได้ลองใช้เมื่อไม่นานมานี้
ประสบการณ์เซสชันเขียนโปรแกรมกับ Claude
- Claude สามารถแก้ไข คำขอด้านการเขียนโปรแกรม ที่ซับซ้อนได้อย่างรวดเร็วและสร้างสรรค์
- ไม่ได้ทำได้แค่การคำนวณง่าย ๆ หรือการทำงานซ้ำ ๆ เท่านั้น แต่ยังเข้าใจแก่นของปัญหาและ เสนอแนวทางใหม่ ได้ด้วย
- ผู้เขียนได้ขอให้ Claude ทำงานยากอย่าง การปรับให้เหมาะสม, การปรับปรุงโครงสร้าง, และการรีแฟกเตอร์โค้ด และรู้สึกประทับใจอย่างลึกซึ้งกับคุณภาพของงานเหล่านั้น
- Claude แสดงให้เห็นถึง ความเข้าใจบริบท ที่เหนือกว่า LLM รุ่นก่อน ๆ รวมถึงสามารถเข้าใจเจตนาของโค้ดได้ด้วย
จุดเด่นที่แตกต่างของ Claude Code
- ต่างจาก AI เชิงสนทนาทั่วไป Claude ไม่ได้แค่เขียนโค้ดได้เท่านั้น แต่ยังทำหน้าที่แบบนักพัฒนามนุษย์ได้ เช่น มองเห็น โครงสร้างของทั้งโปรเจกต์, รีวิวโค้ด, และอธิบายเจตนาในระยะยาว
- สามารถอธิบายรายละเอียด เขียนโค้ดทดสอบ และปรับตัวเข้ากับ ภาษาโปรแกรมและกระบวนทัศน์การเขียนโปรแกรม ที่หลากหลายได้
- แสดง ความสามารถเชิงรุก เช่น ชี้ข้อผิดพลาดทางตรรกะในโค้ดหรือเสนอแนวทางปรับปรุง
การรับรู้ถึงจุดวิกฤตของ AGI
- หลังจากประสบการณ์กับ Claude Code ผู้เขียนเกิดความเชื่อมั่นครั้งใหม่เกี่ยวกับความเป็นไปได้ในการไปถึง AGI ที่ใกล้ความจริงมากขึ้น
- คาดว่าโลกจะได้เห็นการเปลี่ยนผ่านจากการที่มนุษย์สร้างซอฟต์แวร์ด้วยตนเอง ไปสู่สภาพแวดล้อมการพัฒนาที่ขับเคลื่อนโดย AI ในไม่ช้า
บทสรุปและแนวโน้มในอนาคต
- Claude Code ไม่ได้เป็นเพียงเครื่องมือ AI ชิ้นหนึ่งเท่านั้น แต่แสดงให้เห็นถึงศักยภาพในการเปลี่ยน กระบวนทัศน์การใช้งาน AI ทั้งหมด
- ในอนาคต มนุษย์และ AI มีแนวโน้มจะ ร่วมกันออกแบบและพัฒนาโปรแกรม จนนำไปสู่วัฒนธรรมการพัฒนาซอฟต์แวร์ที่สร้างนวัตกรรมยิ่งขึ้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
แม้จะมีอคติอยู่บ้าง [0] แต่ผมคิดว่าควรสคริปต์โดยมีศูนย์กลางเป็น เอเจนต์โอเพนซอร์สที่ไม่ผูกติดกับ LLM
เทคโนโลยีนี้กำลังเปลี่ยนรากฐานของการพัฒนาซอฟต์แวร์ ดังนั้นเราควรทำให้ยังควบคุมวิธีการทำงานของเราได้ต่อไป
[0] https://github.com/all-hands-ai/openhands
ถ้าใช้ Ollama ก็รันบนฮาร์ดแวร์ของตัวเองได้ง่าย แต่ค่า GPU เป็นการลงทุนก้อนใหญ่ ถึงอย่างนั้นถ้าคุณจ่ายเดือนละ 250 ดอลลาร์ให้เครื่องมือกรรมสิทธิ์อยู่แล้ว ก็น่าจะคืนทุนได้ค่อนข้างเร็ว
บทความนี้ค่อนข้างกระจัดกระจาย ก่อนอื่น สไลด์เด็ค ไม่ได้มีประโยชน์นักสำหรับการอธิบายโค้ดเบส
มันมีเหตุผลที่คนแทบไม่ใช้สไลด์เด็คนอกจากเป็นตัวช่วยในการนำเสนอด้วยวาจา สิ่งที่พูดถึงส่วนใหญ่ในบทความไม่ใช่ความสามารถใหม่ และการทำ workflow automation มีคุณค่าและเจ๋งแน่นอน แต่ไม่เห็นว่า AGI มาเกี่ยวอะไรตรงนี้
ไม่ควรต้องใช้ LLM เพื่อทำความเข้าใจโค้ดเบส แค่ทำให้มันเข้าใจง่ายขึ้นก็พอ แน่นอนว่าทุนชอบทางลัดและการแฮ็กเพื่อปล่อยฟีเจอร์ถัดไปใน Q3
รู้ว่ามันไม่ได้สมบูรณ์แบบเสมอไป แต่หลายครั้งมัน “ดีพอ” และในกรณีนี้ผมไม่เคยเจอ hallucination เจอแต่การตกหล่น ถ้าเห็นว่าขาดอะไรไป ก็บอกให้แก้ได้ง่ายมาก
แน่นอนว่าถ้าบทความไม่มีข้อมูลที่มีประโยชน์เลยก็คงไม่สดใหม่ แต่จริง ๆ แล้วสไลด์เด็คอาจมีประโยชน์ต่อการทำความเข้าใจโค้ดเบสก็ได้ มันเป็นของ “มีก็ดี” ที่เราไม่อยากให้ junior ต้องใช้เวลาไปทำ แต่ถ้าจ่ายสัก 5 ดอลลาร์แล้วได้ผลลัพธ์ที่มีประโยชน์นิดหน่อย ก็ถือว่าค่อนข้างโอเค
ส่วนหนึ่งของการเปลี่ยนผ่านที่ทำให้การใช้ LLM ขยายกรอบความคิด คือมันทำให้เรากลับมามองสิ่งที่เมื่อก่อนเราไม่ชอบเพราะความพยายามสูงเกินไปเมื่อเทียบกับคุณค่า ถ้าไม่ต้องทำเองหรือเผาเวลาและสุขภาพจิตของคนในทีม ก็จะพูดได้ว่า “โอเค ลองไล่ดูโค้ดเบส แล้วเขียนทุกฟีเจอร์กับ requirement ทั้งหมดเป็นเอกสาร Markdown แบบตารางมา อาจออกมาดีกว่าที่คิดก็ได้ หรือถ้าไม่ก็ไปทำอย่างอื่นต่อ”
เป็นบทความที่ดี ผมก็สังเกตและใช้เทคนิคคล้าย ๆ กัน และ Claude Code ดีเป็นพิเศษ
ช่วงนี้ด้วย git worktree ทำให้ในแต่ละวันส่วนใหญ่ผมทำหลายงานพร้อมกันได้ และแต่ละงานก็เร็วกว่าเดิมมาก จนรู้สึกแปลกจริง ๆ
ในส่วน “sub-agent” ต้องยอมรับว่าการตั้งค่าให้ Claude Code เรียก o3 ผ่าน sigoden/aichat ช่วยชีวิตไว้มาแล้วนับครั้งไม่ถ้วน
มีปัญหาบางอย่างที่ o3 ทำได้ดีเป็นพิเศษ เช่น race condition และการหาบั๊ก ซึ่งต้องใช้บริบทจำนวนมากและความสามารถในการให้เหตุผลที่สูงมาก
แต่หลังจาก Opus 4 ออกมาก็ใช้น้อยลง และแน่นอนว่านี่ไม่ใช่ sub-agent อะไรเลย
ผมใช้ prompt นี้โดย @include ไว้ใน CLAUDE.md หลัก: https://github.com/pgflow-dev/pgflow/blob/main/.claude/advan...
sigoden/aichat: https://github.com/sigoden/aichat
เทอร์มินัลดูเหมือนจะเป็นอินเทอร์เฟซที่เกือบสมบูรณ์แบบสำหรับ LLM ผมสงสัยว่าแนวทางนี้จะได้รับความนิยมมากกว่า การผสานกับ IDE แบบเฉพาะทาง หรือไม่
มันเป็นอินเทอร์เฟซที่สมบูรณ์แบบ และ Anthropic ทำออกมาได้ถูกทาง
มันยัง debug คลัสเตอร์ k8s ของผมด้วยคำสั่ง kubectl และตรวจ Prometheus ผ่าน API ได้ด้วย เจ๋งแค่ไหนล่ะ
เมื่อองค์ประกอบนี้เข้ามาใน workflow คุณจะอยากเปิดหลายคอนเทนเนอร์ และเมื่อนั้นข้อดีของเทอร์มินัลก็จะอ่อนลง
หมายความว่าไม่อยากแก้โค้ดเองหลังจากมันถูกสร้างขึ้นมาแล้วเหรอ?
การขอให้อธิบาย borrow checker ของ Rust เป็นหนึ่งในตัวอย่างที่แย่ที่สุดในการแสดงความสามารถอ่านโค้ด เนื้อหานั้นมีอยู่ในข้อมูลฝึกเป็นกองพะเนิน
แถมยังไม่มีวิธี “สอน” ด้วย และต่อให้มี ก็ไม่คงอยู่เกินบริบทปัจจุบัน
สำหรับงานที่สำคัญแต่ค่อนข้างเรียบง่าย ถือว่าเสียเวลาโดยสิ้นเชิง
ถ้ามีคนอธิบาย borrow checker ของ Rust ให้ผมฟัง ผมควรไม่ยอมรับเพราะคนนั้นเคยอ่านคำอธิบาย borrow checker มาก่อน แล้วบ่นว่า “มันอยู่ในข้อมูลฝึก” อย่างนั้นเหรอ? คิดว่าคนเราจะเข้าใจ borrow checker ได้โดยไม่เคยเรียนรู้มันมาในรูปแบบใดเลยหรือ?
ผมพอเข้าใจสิ่งที่ต้องการจะสื่ออยู่บ้าง เครื่องมือแบบนี้ยังไม่มีหลักฐานมากนักว่าสร้างไอเดียใหม่ ๆ ได้ และเพราะมีความรู้จำนวนมหาศาล จึงตรวจจับปรากฏการณ์นั้นได้ยาก แต่ในทางปฏิบัติ แม้อยู่ในกรอบของ hallucination มันก็ยังมีประโยชน์และช่วยได้ เลยไม่ได้ใส่ใจมากนัก
ถ้าความใส่ใจในรายละเอียดเป็นหนึ่งในสัญญาณที่ดีที่สุดว่ามีความเป็นช่างฝีมือ การที่ ข้อกำหนดทางกฎหมาย ของ Anthropic ไม่สามารถปฏิบัติตามได้อย่างเป็นเหตุเป็นผล นั่นไม่ใช่สัญญาณที่ไม่ดีต่อการไว้วางใจให้เป็นผู้ดูแล ASI อย่างรอบคอบหรือ?
ถ้าใช้ทำงานไม่ได้โดยไม่ละเมิดข้อห้ามการใช้งานเชิงแข่งขัน ก็คงไม่ได้ “ปลอดภัยระดับกฎ 3 ข้อของหุ่นยนต์” สักเท่าไร
ใส่ใจถึงขั้นรัน Haiku ในบริบทเพื่อสร้างคำกริยาน่ารัก ๆ ที่เหมาะกับตัวแสดงสถานะ “working…”
claude --dangerously-skip-permissions # science modeเห็นอันนี้แล้วขำ
เห็นด้วย Claude Code รู้สึกทรงพลังกว่า Cursor และหนึ่งในเหตุผลน่าจะเป็น ความสามารถในการสคริปต์
สุดท้ายแล้ว Cursor คือเอดิเตอร์ ส่วน Claude Code คือมีดพับสวิสที่ฉีดสเตียรอยด์มา
นอกจาก codebase แบบดั้งเดิมแล้ว ผมใช้ Claude Code เยอะมาก เอาไปรันงานสารพัดในคลัง Obsidian ให้มันสคริปต์ key binding แบบปรับแต่งเองในเครื่องที่อัปโหลดสกรีนช็อตไปยัง CDN ของผมแล้วให้ลิงก์ Markdown หรือให้มันทำโปรแกรมที่คุยกับ Ollama เพื่อสรุปคำสั่งเทอร์มินัลในช่วงหนึ่งวันที่ผ่านมา
เมื่อก่อนต้องคิดก่อนว่าการเปลี่ยนฟอร์แมตไฟล์คุ้มพอจะทำเป็นสคริปต์ไหม หรือจะทำมือดี แต่ตอนนี้ก็แค่รัน Claude ในไดเรกทอรีนั้นแล้วให้มันจัดการ มีประโยชน์กับงานหลายอย่างจริง ๆ
ใช้ผ่าน API ไม่ได้ เลยสงสัยว่าเดือนละ 100 ดอลลาร์จะพอจริงไหม ตอนนี้ใช้ทั้งวันทุกวัน และรู้สึกว่าน่าจะใช้เกินมูลค่า 100 ดอลลาร์ที่จ่ายไปมาก
นอกเรื่องนิด แต่ที่นี่อ่านยากมากเพราะ คอนทราสต์ระหว่างพื้นหลังกับตัวอักษร
ทั้งที่นี่และที่นั่นยังไม่มีใครพูดถึง Opus เลย
หลังลองใช้มาหลายอย่าง ผมลงเอยกับแพ็กเกจ “Max” เดือนละ 100 ดอลลาร์ของ Anthropic เพื่อใช้ Claude Code แล้วก็พบว่า Claude Opus 4 เป็นโมเดลที่ดีที่สุดสำหรับสถานการณ์ของผมตอนนี้ คือโค้ดคณิตศาสตร์และงานวิจัย แต่ก็แพงที่สุดด้วย
พอชนขีดจำกัดเซสชัน 5 ชั่วโมง เลยเปลี่ยนไปใช้ API และเผาเงินไปชั่วโมงละ 20 ดอลลาร์ ดังนั้นจึงอัปเป็น “Max” เดือนละ 200 ดอลลาร์ และยังไม่ชนขีดจำกัดอีก
โมเดลสำคัญนะ เรื่องพวกนี้ทั้งหมดก็เหมือนกับการพูดว่า “ได้เจอคนที่ไม่ค่อยฉลาด” นั่นแหละ ก็แน่อยู่แล้ว