3 คะแนน โดย GN⁺ 2025-06-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เสนอความเห็นเกี่ยวกับความเป็นไปได้ในการเข้าถึงปัญญาประดิษฐ์ทั่วไป (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 ความคิดเห็น

 
GN⁺ 2025-06-17
ความคิดเห็นจาก Hacker News
  • แม้จะมีอคติอยู่บ้าง [0] แต่ผมคิดว่าควรสคริปต์โดยมีศูนย์กลางเป็น เอเจนต์โอเพนซอร์สที่ไม่ผูกติดกับ LLM
    เทคโนโลยีนี้กำลังเปลี่ยนรากฐานของการพัฒนาซอฟต์แวร์ ดังนั้นเราควรทำให้ยังควบคุมวิธีการทำงานของเราได้ต่อไป

    [0] https://github.com/all-hands-ai/openhands

    • ดูเป็นแหล่งข้อมูลที่ดี มีโมเดลที่ค่อนข้างทรงพลังหลายตัวที่รันบน Nvidia 4090 24GB ได้ และยังมี Devstral กับ Qwen 3 ด้วย
      ถ้าใช้ Ollama ก็รันบนฮาร์ดแวร์ของตัวเองได้ง่าย แต่ค่า GPU เป็นการลงทุนก้อนใหญ่ ถึงอย่างนั้นถ้าคุณจ่ายเดือนละ 250 ดอลลาร์ให้เครื่องมือกรรมสิทธิ์อยู่แล้ว ก็น่าจะคืนทุนได้ค่อนข้างเร็ว
    • แล้วถ้าโมเดลแบบปิดมันดีกว่าจริง ๆ ล่ะ ควรทำอย่างไร?
  • บทความนี้ค่อนข้างกระจัดกระจาย ก่อนอื่น สไลด์เด็ค ไม่ได้มีประโยชน์นักสำหรับการอธิบายโค้ดเบส
    มันมีเหตุผลที่คนแทบไม่ใช้สไลด์เด็คนอกจากเป็นตัวช่วยในการนำเสนอด้วยวาจา สิ่งที่พูดถึงส่วนใหญ่ในบทความไม่ใช่ความสามารถใหม่ และการทำ workflow automation มีคุณค่าและเจ๋งแน่นอน แต่ไม่เห็นว่า AGI มาเกี่ยวอะไรตรงนี้

    • แถมยังไม่น่าเชื่อถือด้วย เหมือนบทความจะพูดเรื่องนี้ไว้นิดหน่อย ผมแค่อ่านผ่าน ๆ
      ไม่ควรต้องใช้ LLM เพื่อทำความเข้าใจโค้ดเบส แค่ทำให้มันเข้าใจง่ายขึ้นก็พอ แน่นอนว่าทุนชอบทางลัดและการแฮ็กเพื่อปล่อยฟีเจอร์ถัดไปใน Q3
    • สิ่งที่ LLM มีประโยชน์ที่สุดอันดับหนึ่งคือการสร้าง ไดอะแกรม mermaidjs ของโค้ด
      รู้ว่ามันไม่ได้สมบูรณ์แบบเสมอไป แต่หลายครั้งมัน “ดีพอ” และในกรณีนี้ผมไม่เคยเจอ hallucination เจอแต่การตกหล่น ถ้าเห็นว่าขาดอะไรไป ก็บอกให้แก้ได้ง่ายมาก
    • จากน้ำเสียงของบทความ ดูเหมือนใช้คำว่า AGI แบบล้อเล่น และไม่ได้จริงจังกับตัวเองเกินไป ซึ่งสดใหม่ดี
      แน่นอนว่าถ้าบทความไม่มีข้อมูลที่มีประโยชน์เลยก็คงไม่สดใหม่ แต่จริง ๆ แล้วสไลด์เด็คอาจมีประโยชน์ต่อการทำความเข้าใจโค้ดเบสก็ได้ มันเป็นของ “มีก็ดี” ที่เราไม่อยากให้ 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

    • เดี๋ยวนะ อะไรนะ? ใช้ git worktree ทำหลายงานพร้อมกันได้อย่างไร?
  • เทอร์มินัลดูเหมือนจะเป็นอินเทอร์เฟซที่เกือบสมบูรณ์แบบสำหรับ LLM ผมสงสัยว่าแนวทางนี้จะได้รับความนิยมมากกว่า การผสานกับ IDE แบบเฉพาะทาง หรือไม่

    • ใช่ เข้าถึงได้แทบทุกอย่างจริง ๆ รวมถึง MCP server ด้วย ผมชอบมากที่ Claude Code สามารถตรวจสอบฐานข้อมูลด้วยผู้ใช้แบบอ่านอย่างเดียว หรือเปิดเบราว์เซอร์ Puppeteer เพื่อดูว่าการเปลี่ยน CSS ดูแปลกไหม
      มันเป็นอินเทอร์เฟซที่สมบูรณ์แบบ และ Anthropic ทำออกมาได้ถูกทาง
      มันยัง debug คลัสเตอร์ k8s ของผมด้วยคำสั่ง kubectl และตรวจ Prometheus ผ่าน API ได้ด้วย เจ๋งแค่ไหนล่ะ
    • ในระดับหนึ่งก็ใช่ แต่ผมคิดว่าอนาคตของ LLM จะเป็นการรัน ความพยายามแยกกัน 5 ชุด แบบขนานเพื่อสร้างข้อเสนอการแก้ไข เพราะเวลา LLM ถูกกว่าเวลามนุษย์
      เมื่อองค์ประกอบนี้เข้ามาใน workflow คุณจะอยากเปิดหลายคอนเทนเนอร์ และเมื่อนั้นข้อดีของเทอร์มินัลก็จะอ่อนลง
    • ยิ่งโมเดลดีขึ้น IDE ก็จะยิ่งดูเหมือนเครื่องมือระดับต่ำ
    • อะไรนะ? เทอร์มินัลเป็นอินเทอร์เฟซที่แย่ที่สุดตามตัวอักษรเลย
      หมายความว่าไม่อยากแก้โค้ดเองหลังจากมันถูกสร้างขึ้นมาแล้วเหรอ?
  • การขอให้อธิบาย borrow checker ของ Rust เป็นหนึ่งในตัวอย่างที่แย่ที่สุดในการแสดงความสามารถอ่านโค้ด เนื้อหานั้นมีอยู่ในข้อมูลฝึกเป็นกองพะเนิน

    • เห็นด้วย ถ้าขอให้อธิบายว่า exception ใน task ของ Python asyncio ถูกจัดการอย่างไร แม้จะให้โค้ดทั้งหมดไป มันก็จะส่ายไปส่ายมาเหมือน intern ที่แย่ที่สุดในโลก
      แถมยังไม่มีวิธี “สอน” ด้วย และต่อให้มี ก็ไม่คงอยู่เกินบริบทปัจจุบัน
      สำหรับงานที่สำคัญแต่ค่อนข้างเรียบง่าย ถือว่าเสียเวลาโดยสิ้นเชิง
    • การบ่นว่า “เนื้อหานั้นมีอยู่ในข้อมูลฝึกเป็นกองพะเนิน” นั้นแปลก
      ถ้ามีคนอธิบาย borrow checker ของ Rust ให้ผมฟัง ผมควรไม่ยอมรับเพราะคนนั้นเคยอ่านคำอธิบาย borrow checker มาก่อน แล้วบ่นว่า “มันอยู่ในข้อมูลฝึก” อย่างนั้นเหรอ? คิดว่าคนเราจะเข้าใจ borrow checker ได้โดยไม่เคยเรียนรู้มันมาในรูปแบบใดเลยหรือ?
      ผมพอเข้าใจสิ่งที่ต้องการจะสื่ออยู่บ้าง เครื่องมือแบบนี้ยังไม่มีหลักฐานมากนักว่าสร้างไอเดียใหม่ ๆ ได้ และเพราะมีความรู้จำนวนมหาศาล จึงตรวจจับปรากฏการณ์นั้นได้ยาก แต่ในทางปฏิบัติ แม้อยู่ในกรอบของ hallucination มันก็ยังมีประโยชน์และช่วยได้ เลยไม่ได้ใส่ใจมากนัก
  • ถ้าความใส่ใจในรายละเอียดเป็นหนึ่งในสัญญาณที่ดีที่สุดว่ามีความเป็นช่างฝีมือ การที่ ข้อกำหนดทางกฎหมาย ของ Anthropic ไม่สามารถปฏิบัติตามได้อย่างเป็นเหตุเป็นผล นั่นไม่ใช่สัญญาณที่ไม่ดีต่อการไว้วางใจให้เป็นผู้ดูแล ASI อย่างรอบคอบหรือ?
    ถ้าใช้ทำงานไม่ได้โดยไม่ละเมิดข้อห้ามการใช้งานเชิงแข่งขัน ก็คงไม่ได้ “ปลอดภัยระดับกฎ 3 ข้อของหุ่นยนต์” สักเท่าไร

    • ไม่รู้เรื่องฝ่ายกฎหมาย แต่ผลิตภัณฑ์อย่าง Claude Code แสดงให้เห็นร่องรอยของความใส่ใจในรายละเอียดแบบไม่กั๊ก
      ใส่ใจถึงขั้นรัน Haiku ในบริบทเพื่อสร้างคำกริยาน่ารัก ๆ ที่เหมาะกับตัวแสดงสถานะ “working…”
  • claude --dangerously-skip-permissions # science mode

    เห็นอันนี้แล้วขำ

  • เห็นด้วย Claude Code รู้สึกทรงพลังกว่า Cursor และหนึ่งในเหตุผลน่าจะเป็น ความสามารถในการสคริปต์
    สุดท้ายแล้ว Cursor คือเอดิเตอร์ ส่วน Claude Code คือมีดพับสวิสที่ฉีดสเตียรอยด์มา
    นอกจาก codebase แบบดั้งเดิมแล้ว ผมใช้ Claude Code เยอะมาก เอาไปรันงานสารพัดในคลัง Obsidian ให้มันสคริปต์ key binding แบบปรับแต่งเองในเครื่องที่อัปโหลดสกรีนช็อตไปยัง CDN ของผมแล้วให้ลิงก์ Markdown หรือให้มันทำโปรแกรมที่คุยกับ Ollama เพื่อสรุปคำสั่งเทอร์มินัลในช่วงหนึ่งวันที่ผ่านมา
    เมื่อก่อนต้องคิดก่อนว่าการเปลี่ยนฟอร์แมตไฟล์คุ้มพอจะทำเป็นสคริปต์ไหม หรือจะทำมือดี แต่ตอนนี้ก็แค่รัน Claude ในไดเรกทอรีนั้นแล้วให้มันจัดการ มีประโยชน์กับงานหลายอย่างจริง ๆ

    • ปัญหาคือ Claude Code จะทำงานได้ก็ต่อเมื่อมี แพ็กเกจราคา
      ใช้ผ่าน API ไม่ได้ เลยสงสัยว่าเดือนละ 100 ดอลลาร์จะพอจริงไหม ตอนนี้ใช้ทั้งวันทุกวัน และรู้สึกว่าน่าจะใช้เกินมูลค่า 100 ดอลลาร์ที่จ่ายไปมาก
    • อยากรู้จริง ๆ ว่าใช้ทำอะไรในคลัง Obsidian บ้าง
    • สคริปต์ Claude Code ยังไง? เคยใช้ผ่าน CLI มา แต่ไม่เคยนึกถึงการเรียก Claude Code จากสคริปต์เลย ฟังดูน่าสนใจทีเดียว
    • ไม่กี่วันก่อนให้ LLM จัดโน้ตจำนวนมหาศาลของผมลง โฟลเดอร์หมวดหมู่ โอ้โห มันช่วยได้จริง ๆ
  • นอกเรื่องนิด แต่ที่นี่อ่านยากมากเพราะ คอนทราสต์ระหว่างพื้นหลังกับตัวอักษร

    • สำหรับผมเป็นเพราะเคอร์เซอร์กะพริบด้านบนสุด ทำให้โฟกัสกับบทความยาก
    • ข้ามไปก็ไม่ได้พลาดอะไรมากนัก
  • ทั้งที่นี่และที่นั่นยังไม่มีใครพูดถึง Opus เลย
    หลังลองใช้มาหลายอย่าง ผมลงเอยกับแพ็กเกจ “Max” เดือนละ 100 ดอลลาร์ของ Anthropic เพื่อใช้ Claude Code แล้วก็พบว่า Claude Opus 4 เป็นโมเดลที่ดีที่สุดสำหรับสถานการณ์ของผมตอนนี้ คือโค้ดคณิตศาสตร์และงานวิจัย แต่ก็แพงที่สุดด้วย
    พอชนขีดจำกัดเซสชัน 5 ชั่วโมง เลยเปลี่ยนไปใช้ API และเผาเงินไปชั่วโมงละ 20 ดอลลาร์ ดังนั้นจึงอัปเป็น “Max” เดือนละ 200 ดอลลาร์ และยังไม่ชนขีดจำกัดอีก
    โมเดลสำคัญนะ เรื่องพวกนี้ทั้งหมดก็เหมือนกับการพูดว่า “ได้เจอคนที่ไม่ค่อยฉลาด” นั่นแหละ ก็แน่อยู่แล้ว

    • ทั้งหมดนี้ทำด้วย Opus