23 คะแนน โดย GN⁺ 2026-01-07 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Claude Opus 4.5 แสดงให้เห็นถึง ความสามารถในการพัฒนาแบบอัตโนมัติ ในระดับที่สามารถสร้างแอปพลิเคชันคุณภาพสูงได้โดยแทบไม่ต้องให้ผู้พัฒนาเข้ามาแทรกแซง ซึ่งแตกต่างจาก AI เอเจนต์สำหรับเขียนโค้ดแบบเดิม
  • สามารถสร้างโปรเจกต์ที่ใช้งานได้จริงเสร็จในเวลาสั้น ๆ ตั้งแต่ ยูทิลิตีแปลงภาพบน Windows แบบง่าย ๆ ไปจนถึง เครื่องมือบันทึกและตัดต่อวิดีโอ, แอปโพสต์อัตโนมัติด้วย AI และ แอปติดตามคำสั่งซื้อและคำนวณเส้นทาง
  • Opus 4.5 จัดการงานพัฒนาที่ซับซ้อนได้ด้วยตัวเอง เช่น การตั้งค่าแบ็กเอนด์ Firebase, การวิเคราะห์ error log และแก้ไขอัตโนมัติ, และ การตั้งค่าดีพลอยด้วย GitHub Actions
  • ผู้เขียนระบุว่าตนเองไม่ได้เข้าใจโครงสร้างโค้ดทั้งหมด แต่ก็ยืนยันว่า Opus 4.5 สามารถ แก้บั๊กได้เองและเสนอแนวทางรีแฟกเตอร์ ได้
  • ประสบการณ์นี้สะท้อนว่าโอกาสที่ AI จะเข้ามาแทนที่นักพัฒนาเริ่มกลายเป็นความจริง และเป็น จุดเปลี่ยนของยุคการพัฒนาที่มี AI เป็นศูนย์กลาง

การมาของ Opus 4.5 และความแตกต่างจาก AI เอเจนต์เดิม

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

โปรเจกต์ 1 – ยูทิลิตีแปลงภาพบน Windows

  • Opus 4.5 สร้างยูทิลิตีที่มีฟังก์ชัน แปลงฟอร์แมตภาพจากเมนูคลิกขวาใน Windows Explorer ได้เสร็จจากการสั่งเพียงครั้งเดียว
    • ใช้ dotnet CLI เพื่อทำบิลด์และแก้ข้อผิดพลาดโดยอัตโนมัติ
    • มีเพียง error ของ XAML เท่านั้นที่ต้องเปิดดูใน Visual Studio แล้วคัดลอกส่งให้
  • ยังตั้งค่าให้ครบทั้ง เว็บไซต์สำหรับดีพลอย, สคริปต์ติดตั้ง PowerShell และ pipeline ดีพลอยอัตโนมัติด้วย GitHub Actions
  • การทำโลโก้ใช้ Figma AI ส่วน Opus เขียน สคริปต์แปลง SVG และฟอร์แมตไอคอน ให้

โปรเจกต์ 2 – เครื่องมือบันทึกหน้าจอและตัดต่อ

  • เริ่มจาก ยูทิลิตีบันทึก GIF ที่คล้าย LICEcap แล้วต่อยอดไปถึงความสามารถด้านตัดต่อวิดีโอและรูปภาพ
    • สร้าง ฟีเจอร์เพิ่มรูปทรง, ครอบตัด, เบลอ และฟังก์ชันตัดต่ออื่น ๆ ได้ภายในไม่กี่ชั่วโมง
  • ซอร์สโค้ดถูกเปิดเผยไว้บน GitHub และผู้เขียนบอกว่า “พัฒนาไปได้ไกลมากภายในไม่กี่ชั่วโมง”
  • สิ่งนี้ยืนยันว่า Opus 4.5 สามารถทำได้ไม่ใช่แค่ UI แต่รวมถึง งานเชื่อมต่อแบ็กเอนด์ ด้วย

โปรเจกต์ 3 – แอปโพสต์อัตโนมัติด้วย AI

  • พัฒนา แอปมือถือที่ใช้ AI โพสต์ลง Facebook Page อัตโนมัติ ด้วย Opus 4.5
    • หลังอัปโหลดรูป AI จะทำ การสร้างแคปชันและตั้งเวลาโพสต์ ให้
    • Opus ตั้งค่า แบ็กเอนด์ Firebase, การยืนยันตัวตน, storage และ cloud functions ผ่าน CLI ด้วยตัวเอง
  • ผู้เขียนเล่าว่าระหว่างที่ตนไปติดตั้งมู่ลี่ Opus ก็สร้างแอปเสร็จแล้ว
  • Opus ยังสามารถ วิเคราะห์ error log แล้วแก้เองอัตโนมัติ และสร้าง แดชบอร์ดสำหรับการจัดการ ให้ได้ด้วย
  • งานที่เดิมต้องใช้เวลาหลายเดือน กลับ เสร็จได้ภายในไม่กี่ชั่วโมง

โปรเจกต์ 4 – แอปติดตามคำสั่งซื้อและคำนวณเส้นทาง

  • แยกวิเคราะห์อีเมลคำสั่งซื้อจาก Gmail เพื่อคำนวณ ตารางเวลา, เส้นทาง, เวลาขับรถ และบันทึกระยะทางสำหรับภาษี โดยอัตโนมัติ
  • Opus 4.5 จัดการ การเชื่อม Google Authentication และการเชื่อมต่อ Firebase ได้ในครั้งเดียว
  • ผู้เขียนประเมินว่า “งานที่ถ้าทำมือจะทรมานมาก Opus กลับทำได้อย่างสมบูรณ์แบบ”

ความเข้าใจโค้ดและประเด็นด้านคุณภาพ

  • ผู้เขียนบอกว่าแม้ตนเอง ไม่รู้ Swift แอปก็ยัง ทำงานได้อย่างสมบูรณ์
  • Opus 4.5 สามารถ หาบั๊กและแก้เองได้ ทำให้ผู้เขียนเดินหน้าพัฒนาได้โดยไม่จำเป็นต้องรู้โครงสร้างภายในทั้งหมดของโค้ด
  • ต่อคำถามเรื่องคุณภาพโค้ด ผู้เขียนอธิบายว่า “ถ้าโค้ดนั้นเป็นโค้ดที่ AI จะอ่านและดูแลรักษาเอง ความสามารถในการอ่านของมนุษย์ก็ไม่สำคัญ”
  • ใช้ พรอมป์ต์สำหรับเขียนโค้ดเฉพาะทางด้วย AI ภายใน VS Code เพื่อสร้างโค้ดที่เน้น โครงสร้างที่ LLM เข้าใจได้ง่าย

หลักการเขียนโค้ดที่มี AI เป็นศูนย์กลาง

  • พรอมป์ต์ตั้งต้นอยู่บนสมมติฐานว่าเป็น “โค้ดที่ AI จะเขียนและดูแลรักษา”
    • เน้น โครงสร้างเรียบง่าย, จุดเริ่มต้นชัดเจน, การทำ abstraction ให้น้อยที่สุด และ coupling ต่ำ
    • ให้ความสำคัญกับ control flow ที่ชัดเจน, ฟังก์ชันที่เรียบง่าย, structured logging และความง่ายในการสร้างใหม่
  • เมื่อต้องรีแฟกเตอร์โค้ด Opus จะจัดทำเอกสาร รายการสิ่งที่ควรปรับปรุงตามลำดับความสำคัญ (สูง·กลาง·ต่ำ)
  • เมื่อตรวจสอบด้านความปลอดภัย จะมีการขอให้ตรวจ API key, การจัดการล็อกอิน และการจัดเก็บข้อมูลอ่อนไหว
    • ผู้เขียนยอมรับว่าในแง่ความสมบูรณ์ด้านความปลอดภัย “ตอนนี้ยังมั่นใจแค่ประมาณ 80%”

การเปลี่ยนผ่านสู่ยุคพัฒนาด้วย AI

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

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

3 ความคิดเห็น

 
wegaia 2026-01-08

พอลองให้ Opus 4.5 แก้โค้ดแค่บรรทัดเดียว กลับเห็นว่ามันลบโค้ดตั้งค่าที่อยู่เหนือขึ้นไปเองราว ๆ 10 บรรทัด พอถามว่าทำไมถึงลบ มันก็บอกว่าเหมือนเป็นโค้ดที่ไม่มีความหมายเลยลบออก..

 
GN⁺ 2026-01-07
ความคิดเห็นจาก Hacker News
  • งานที่วิศวกรระดับกลางรับผิดชอบไม่ใช่แค่การสร้างแอปใหม่ แต่คือการออกแบบโครงสร้างโดยคำนึงถึง ความสามารถในการขยายระบบและความเข้าใจได้ง่าย
    Opus 4.5 จัดการคำขอระดับ “ช่วยสร้างแอปสักตัว” ได้ดี แต่พอให้เพิ่มฟีเจอร์ลงในโค้ดเดิมแบบงานจริง มักใช้ abstraction แปลก ๆ หรือไม่ก็ต้องแก้หลายรอบกว่าจะได้คุณภาพตามต้องการ
    คนที่ไม่ใช่สายเทคนิคอาจคิดว่า “ใช้ได้ก็พอแล้ว” แต่วิศวกรรู้ว่านั่นยังไม่พอ

    • คำว่า ‘วิธีที่ถูกต้อง’ มีอยู่สองแบบ — แบบที่เหมาะกับบริบท กับแบบที่วิศวกรมักมองในเชิงทั่วไป
      จำได้ว่าเมื่อก่อนในทีมเคยทะเลาะกันเรื่อง “คำตอบที่ถูก” แล้วสุดท้ายต้องมีคนนอกเข้ามาเตือนว่าอะไรสำคัญในมุมธุรกิจจริง ๆ
      บางครั้งการทำแบบพอใช้ได้แต่เร็ว เพื่อพิสูจน์ว่าทิศทางถูกต้อง ก็อาจเป็นวิธีที่ ‘ถูกต้อง’ จริง ๆ
      ปัญหาเกิดเมื่อออกแบบมากเกินไปตั้งแต่แรก หรือในทางกลับกันเมื่อผู้จัดการขัดขวางการรีแฟกเตอร์ สุดท้ายแล้วหัวใจคือ ความสมดุล
    • พอเห็นโปรเจ็กต์แบบนี้ ก็รู้สึกว่าแค่ fork ตัวแปลงภาพหรือ Minesweeper clone ที่มีอยู่บน GitHub ก็น่าจะพอแล้ว การใช้ LLM ดูเหมือนมีไว้ เพื่อล้างประเด็นลิขสิทธิ์ มากกว่า
    • บางคนถึงขั้นบอกว่า “คุณภาพโค้ดไม่สำคัญอีกต่อไปแล้ว” ขอแค่วันนี้ผ่านเทสต์ก็พอ ถ้าพรุ่งนี้ต้องรีแฟกเตอร์ทั้งก้อน ก็แค่ใช้เครดิตเพิ่มแล้วให้มันสร้างใหม่ในไม่กี่ชั่วโมง
    • ฉันประทับใจที่ Opus 4.5 ทำตาม แพตเทิร์นที่เป็นธรรมชาติของโค้ดเบส เดิมได้ดีมาก
      ถ้าระบุชัด ๆ ให้มันอ่านโค้ดใกล้เคียงก่อน มันจะทำงานดีขึ้นมาก แค่เพิ่มคำสั่งอีกประโยคสองประโยคก็พอ
    • ตอนเพิ่มฟีเจอร์เข้าโค้ดเดิม ถ้าระบุ abstraction ที่ต้องการเอง มันจะค่อย ๆ ทำได้ดีขึ้น
      แต่ส่วนตัวฉันยังชอบ GPT‑5.2 มากกว่า
  • วิศวกรจำนวนมากยัง ประเมินความสามารถปัจจุบันของเอเจนต์ LLM อย่าง Claude Code ต่ำเกินไป
    ทีมของเราทำ automation ด้วย Claude Code ทั้ง code review, ESLint, PR checklist, การ sync เอกสาร และการตรวจสอบ test coverage
    แม้แต่การจัดหมวดหมู่ ticket ก็ทำอัตโนมัติ ทำให้พอวิศวกรเริ่มงาน งานก็เสร็จไปแล้วครึ่งหนึ่ง
    มีตัวอย่างรีโพอยู่ที่ claude-code-showcase
    มั่นใจว่าราวปี 2026 สิ่งนี้จะกลายเป็น workflow มาตรฐานของอุตสาหกรรม

    • ประสบการณ์การใช้ LLM ในงานฝั่งฟรอนต์เอนด์ (React, HTML, mobile) กับงานระดับล่าง (OpenGL, io_uring, libev ฯลฯ) ต่างกันมาก
      Opus 4.5 สร้างแอป JS ได้ดี แต่ถ้าให้ไปเขียนอัลกอริทึมเงาจากเปเปอร์ปี 2003 ด้วย C++ จะเละเทะทันที
      ต่อให้ป้อน รีวิว threading ของ Doom3 BFG โดย Fabien Sanglard ให้ด้วย ก็ยังได้แต่โค้ดไร้ประโยชน์
      สรุปคือไม่ใช่ว่าเราประเมิน LLM ต่ำไป แต่เป็นเพราะมัน ยังไม่ practical พอ เลยต้องรอ
    • หลายคนเคยลอง AI coding ตั้งแต่ช่วงแรก ๆ แล้วเลิกไปเพราะ error และความหงุดหงิด
      แต่ Opus 4.5 ขยับขึ้นไปอีกขั้นจริง ๆ ข้อผิดพลาดน้อยลงมาก และส่วนใหญ่เป็นความพลาดเล็ก ๆ น้อย ๆ
    • ฉันสอนนักศึกษาในมหาวิทยาลัยและลองใช้ Cursor, Claude Code, Codex
      ด้วย AI ทำให้โปรเจ็กต์ที่ปกติต้องใช้เวลา 2 สัปดาห์ เสร็จได้ใน 5 ชั่วโมง
      ถ้าไม่มี AI ก็คงไม่คิดจะลองทำตั้งแต่แรก
    • มันตลกดีที่ README ที่ AI สร้างยังชอบใส่โครงสร้างไดเรกทอรี ทั้งที่ใช้คำสั่ง tree ก็ดูได้หมดแล้ว
    • ต่อไปอาชีพ “โปรแกรมเมอร์” เองอาจลดลง และ ความสามารถในการสร้างสรรค์โดยใช้เครื่องมือให้เป็น จะสำคัญกว่า
  • ฉันใช้ Opus 4.5 มาเยอะพอสมควร มันยอดเยี่ยมมากในเรื่อง การวิเคราะห์โค้ดที่ซับซ้อน แต่ก็ยังไม่ใช่ความสามารถแก้ปัญหาระดับมนุษย์
    ตัวอย่างเช่น มันระบุอัลกอริทึมการจัด layout ของกราฟได้อย่างแม่นยำ แต่ไม่สามารถแก้บั๊กนั้นได้ด้วยตัวเอง
    มันยอดเยี่ยมสำหรับการวิเคราะห์โค้ดและเสริมความรู้ แต่ การแก้ปัญหาแบบซับซ้อนหลายชั้น ยังเกินความสามารถอยู่

    • Copilot มีข้อจำกัดเพราะ โครงสร้างของมันตัดบริบททิ้งเพื่อประหยัดโทเคน
      ถ้าอยากได้ประสิทธิภาพจริงต้องใช้ API โดยตรง และค่าใช้จ่ายอาจแตะเลขสามหลักต่อหนึ่ง PR
      อ้างอิง: models.dev
    • น่าตกใจที่ Copilot คิดโทเคนของ Opus 4.5 เป็น 3 เท่า จนใช้โควตาครึ่งเดือนหมดภายในสัปดาห์เดียว
    • ต่อให้ใช้ AI แค่เป็น เครื่องมือวิเคราะห์โค้ด ก็ยังมีมูลค่าสูง
      การสร้างเอกสารก็ดีกว่ามนุษย์ และอัตราความผิดพลาดก็มักต่ำกว่ามนุษย์ด้วย
    • ถ้าใช้ผ่านเครื่องมือ third-party พฤติกรรมจะต่างออกไป
      แนะนำให้ลองใช้ตรงใน VS Code หรือ Cursor ผ่านการสมัคร Claude Code
  • ช่วงวันหยุดฉันทำหลายโปรเจ็กต์ด้วย GPT‑5.x —
    ทั้ง เครื่องมือ automation สำหรับ Swift, การรวม ARM JIT engine, โปรโตไทป์ซินธิไซเซอร์ ฯลฯ
    GPT‑5.2 และสาย Codex ทรงพลังพอ ๆ กับ Opus ถึงขั้น จัด workflow ของ CI ทั้งชุดได้ในครั้งเดียว
    สำหรับคนอย่างฉันที่ชอบวางแผนและรีวิวโค้ด มันคือ เครื่องมือเพิ่ม productivity แบบคูณสอง

    • GPT‑5.2 มัก หลอน (hallucination) เรื่องการมีอยู่หรือความสามารถของ utility แบบ CLI
      ต้องไปคุ้ยดู source code จริงถึงจะยืนยันข้อผิดพลาดได้
    • Gemini 3 Pro (High) และเครื่องมืออย่าง Antigravity, Amp, Junie ก็น่าประทับใจเช่นกัน
      ฉันทำไลบรารี binding ของ Ratatui สำหรับ Ruby เสร็จในเวลา 2 สัปดาห์
      Antigravity รันหลายเอเจนต์แบบขนานเพื่อทำ context compression และการจัดการอัตโนมัติ
      เครื่องมือระดับสูงพวกนี้ให้ประสบการณ์ที่ต่างจากเวอร์ชันฟรีโดยสิ้นเชิง
      ถ้าใช้ร่วมกับเครื่องมือ Unix และ git CLI ก็จะคุมบริบทให้เล็กและเพิ่มประสิทธิภาพได้สูงสุด
    • LLM เก่งกับโค้ด backend และ CLI แต่ยังอ่อนในงานอย่าง HTML/CSS หรือ JS frontend ที่ ต้องการ feedback ทางภาพ
      มันเก่งกับ input/output ที่มีโครงสร้าง แต่ล้มเหลวกับงานที่ต้องการ “ความลงตัวเชิงสัมผัส”
  • ช่วงหลังรู้สึกว่าใน HN มี คอมเมนต์เชิงลบเกี่ยวกับ LLM ลดลงมาก
    แต่โปรเจ็กต์ที่แชร์กันส่วนใหญ่ก็ยังหยุดอยู่แค่ระดับ technical demo
    การสะสมบริบท หรือก็คือ การเข้าใจความต้องการของผู้ใช้ ยังเป็นหน้าที่ของมนุษย์อยู่ดี
    คุณอาจสร้างแอปได้หลายตัวในสุดสัปดาห์เดียว แต่แทบไม่มีใครอยากดูแลมันต่อ

    • คอมเมนต์เชิงลบที่ลดลงอาจเป็นเพราะคนเริ่มเบื่อการถกเถียงซ้ำ ๆ แนว “โมเดลใหม่ดีขึ้น 1000 เท่า” ก็ได้
    • หรือคนที่กำลังสร้างผลิตภัณฑ์ที่ทำเงินได้อาจ กำลังพัฒนาเงียบ ๆ เลยไม่เอามาแชร์
    • การ deploy production และการดูแลรักษาต้องใช้ ความพยายามมหาศาล
      Karpathy ก็แชร์ประสบการณ์คล้ายกัน — ทำ prototype นั้นง่าย แต่ deploy จริงยาก
      ถ้าเป็นเครื่องมือใช้ส่วนตัว การโฟกัสที่ การแก้ปัญหา มากกว่าความสมบูรณ์แบบก็เพียงพอแล้ว
    • ยิ่งใช้ AI มากเท่าไร ก็ยิ่งไปติดตรง 20% สุดท้ายที่ต้องใช้ การคิดเชิงบูรณาการ
      ถ้าปล่อยให้ AI คิดแทนมากเกินไป ความสามารถในการคิดด้วยตัวเองก็จะอ่อนลง
    • แม้แต่การพัฒนาเกม กฎ 80/20 ก็ยังใช้ได้เหมือนเดิม
      ทดสอบไอเดียได้เร็วก็จริง แต่การไปให้ถึงผลิตภัณฑ์ที่สมบูรณ์ยังต้องอาศัยความอดทนของมนุษย์
  • Opus 4.5 ไม่ได้แค่มีความรู้มากขึ้น แต่ ความสามารถในการแก้ปัญหาแบบอัตโนมัติ ก็ดีขึ้นมาก
    ถ้าเป็นปัญหาที่นิยามชัด มันแทบแก้ได้ทั้งหมด และยังทำ reverse engineering ได้ด้วย
    ช่วงหลังฉันแทบไม่ค่อยเขียนโค้ดเองแล้ว แต่เขียนสเปกและคอยกำกับให้ Opus ลงมือทำและปรับปรุงแทน

    • ตัวอย่างที่เผยแพร่ไว้มี coding-agent-benchmark และ
      โปรเจ็กต์ reverse engineering เกม C64
    • อยากรู้ว่ามีวิธีป้องกัน “การออกแบบเกินจำเป็น” อย่างไร
    • สำหรับฉัน การใช้เว็บแอป Claude เพื่อทำ rubber duck debugging มีประสิทธิภาพมาก
      Claude Code ทรงพลังกว่าเพราะเห็นทั้งโค้ดเบส แต่ กินโควตาเร็วเกินไป
      เลยกลับมาใช้เวอร์ชันเว็บ
    • ตอนนี้ฉันก็ทำ side project แทบทั้งหมดด้วยวิธีนี้เหมือนกัน
  • ฉันเคยใช้ Opus 4.5 ลองทำทั้ง JavaScript interpreter ที่เขียนด้วย Python, WebAssembly runtime, และ การพอร์ต string search routine ของ Rust ไปเป็น C
    ส่วนใหญ่ทดลองบนสมาร์ตโฟน และผลลัพธ์ก็น่าทึ่งมาก

    • ถ้า “interpreter สำหรับ JS ที่เขียนด้วย Python” นั้นอิงจาก MQJS ของ Bellard ก็ควรระบุที่มาไว้ด้วย
      อ้างอิง: micro-javascript
    • มันยังอ่อนกับปัญหาที่ต้องใช้การให้เหตุผลเชิงภาพ เช่น อัลกอริทึมเส้นทางของ slime mold
    • ฉันอยากรู้ผลลัพธ์ของการ “พอร์ต routine จาก Rust ไป C แล้วทำให้เร็วขึ้น”
    • ฉันเคยบอกมันว่า “เขียน Python 3 interpreter ด้วย JavaScript” แล้วมันทำจนผ่านเทสต์ได้ น่าทึ่งมาก
    • แต่ช่วงหลังฉันไม่ค่อยรู้สึกถึงความต่างมากนัก ตัวโมเดลเหมือนเริ่มนิ่ง ส่วนที่พัฒนาคือ agent framework มากกว่า
      วิดีโอตัวอย่าง: ลิงก์ Mastodon
  • เหตุผลที่นักพัฒนายังถูกจ้างจริง ๆ คือเรื่อง ความรับผิดชอบ
    แม้สมัยที่เราก๊อบโค้ดจาก StackOverflow หรือ GitHub ก็ยังมีเครื่องมืออยู่แล้ว
    แต่เมื่อมีปัญหา คนที่ต้องรับผิดชอบสุดท้ายก็คือมนุษย์

    • ทุกวันนี้ คนที่รับผิดชอบได้จริง คือทรัพยากรที่สำคัญที่สุด
      ถ้ามีเพื่อนร่วมงานที่ไว้ใจได้และกล้าเอาชื่อไปค้ำโค้ดที่ AI เขียน ก็ถือว่าโอเค
    • แต่ในอุตสาหกรรม คนที่สร้างของใหม่มักได้รางวัลมากกว่าคนที่รับผิดชอบดูแล
      งานบำรุงรักษาเลยมักถูกละเลย
    • ตอนนี้ การรีวิวโค้ดแบบเรียลไทม์ กลายเป็นโหมดปกติไปแล้ว
      สุดสัปดาห์ที่ผ่านมา ฉันทำ SaaS ไป 80% ด้วย AI และเขียนเฉพาะแกนสำคัญเอง
      แค่เอาสเปกภาษาที่ฉันเขียนไว้เมื่อ 22 ปีก่อนมาแปะ Opus ก็สร้าง parser กับเทสต์เสร็จใน 3 นาที
      สุดท้ายแล้วเรากำลังเข้าสู่ช่วงเวลาที่ต้อง ปรับตัวต่อการเปลี่ยนแปลงเหมือนอุตสาหกรรมเหมืองแร่
    • เพราะอย่างนั้นฉันจึงชอบใช้ AI เป็น บรรณาธิการหรือผู้รีวิว มากกว่าเป็นผู้เขียน
      ฉันเขียนโค้ดเอง ส่วน AI ช่วยหาปัญหาและเสนอแนวทางการทดสอบ
  • Opus 4.5 กำลังช่วยฉันสร้าง ภาษาโปรแกรมใหม่
    เราคุยกันถึงระดับ implementation ชั้นล่าง ร่วมงานกันเหมือน pair programming
    แต่ในโค้ดเบสขนาดใหญ่ มนุษย์ก็ยังต้องมี อำนาจควบคุมเชิงระบบ อยู่ดี
    ไม่อย่างนั้น Opus จะเปลี่ยนสเปกหรือเอาวิธีแก้เฉพาะหน้ามากลบปัญหา
    มันไม่ใช่เครื่องมือสารพัดนึก แต่ก็ดูเหมือนว่าจะเป็น ปีที่ productive ที่สุด ในชีวิตฉัน
    และในขณะเดียวกัน ถ้าเทคโนโลยีแบบนี้แพร่หลายจริง ก็หวังว่าจะได้เห็น การฟื้นคืนของชุมชนเว็บขนาดเล็ก ด้วย

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

    • ทางที่ดีกว่าคือให้มัน “เสนอไอเดียสำหรับการปรับปรุง” แล้วคัดอันที่ดี จากนั้น ให้ Claude อธิบาย ก่อนค่อยสั่งให้ลงมือทำ จะมีประสิทธิภาพกว่า
    • มันทำงานได้ดีที่สุดเมื่อเรารู้ชัดว่า อยากปรับปรุงอะไร
      คำสั่งแบบ “ลองปรับอะไรก็ได้ดู” คือพรอมป์ต์ที่แย่ที่สุด
    • กรณีแบบนี้เป็นตัวอย่างที่ดีในการเผยให้เห็น จุดอ่อนของโมเดล
      ก่อนหน้านี้ก็เคยมีคนปล่อยให้เอเจนต์ปรับปรุงงานทั้งคืน แล้วตื่นมาเจอ โค้ดขยะ 100,000 บรรทัด
      เพราะแบบนี้ การพัฒนาแบบมีแผน จึงสำคัญ
      อ้างอิง: The Highest Quality Codebase
    • โมเดลส่วนใหญ่รวมถึง Opus ไม่เก่งเรื่องปรับปรุงโค้ดเดิม แต่เขียนโค้ดใหม่ได้ดี
    • ข้อเสนอจาก AI ใน code review 90% ใช้ไม่ได้ แต่ 10% ที่เหลือจับปัญหาจริงได้
      มันอาจเสนอให้แก้ต่อไปเรื่อย ๆ แบบไม่สิ้นสุดเหมือนลูปอนันต์ก็ได้
 
[ความคิดเห็นนี้ถูกซ่อน]