เส้นทางการนำ AI มาใช้ของผม

 (mitchellh.com)
38 คะแนน โดย GN⁺ 2026-02-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มิตเชลล์ ฮาชิโมโตะ ผู้ที่ exit จาก HashiCorp และกำลังสร้าง Ghostty ได้สรุปกระบวนการที่เขานำเครื่องมือ AI มาผสานเข้ากับงานจริง
  • แบ่งเป็น 3 ช่วงคือ ความไร้ประสิทธิภาพ → การปรับตัว → ผลิตภาพที่ดีขึ้น พร้อมบันทึกทั้งการลองผิดลองถูกและกระบวนการเรียนรู้อย่างเป็นรูปธรรม
  • หลังตระหนักถึงข้อจำกัดของการเขียนโค้ดผ่านแชตบอต เขาจึงเปลี่ยนไปใช้ เครื่องมือแบบเอเจนต์ และเริ่มเห็นคุณค่าอย่างจริงจัง
  • ผ่านการฝึกให้เอเจนต์ทำซ้ำคอมมิตที่เคยทำด้วยมือ เขาได้เรียนรู้ว่า การแยกงาน, การแยกการวางแผน/การลงมือทำ, การตรวจสอบอัตโนมัติ คือหัวใจสำคัญ
  • ใช้เวลา 30 นาทีสุดท้ายของวันทำงานกับ งานอัตโนมัติช่วงกลางคืน และ มอบหมายงานง่าย ๆ ที่ทำซ้ำได้ให้เอเจนต์ จนเกิด ผลิตภาพที่ดีขึ้นอย่างเป็นรูปธรรม
  • ปัจจุบันเขาอยู่ในขั้นที่ มีเอเจนต์หนึ่งตัวทำงานอยู่เสมอ ควบคู่ไปกับ “harness engineering” เพื่อป้องกันความผิดพลาดและเพิ่มประสิทธิภาพการทำงานร่วมกันระหว่าง AI กับมนุษย์สูงสุด

ภูมิหลังของการนำมาใช้และแนวทาง

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

Step 1: ออกจากแชตบอต

  • การเขียนโค้ดผ่าน อินเทอร์เฟซแชตบอต อย่าง ChatGPT หรือ Gemini พึ่งพาการเรียนรู้ล่วงหน้า และการแก้ข้อผิดพลาดก็ต้องอาศัยฟีดแบ็กซ้ำ ๆ จากมนุษย์ จึงไม่มีประสิทธิภาพ
  • “ช่วงเวลาที่น่าทึ่ง” ครั้งแรกคือการนำภาพหน้าจอ command palette ของ Zed ไปวางใน Gemini แล้วให้สร้างซ้ำด้วย SwiftUI ซึ่งต่อมากลายเป็นพื้นฐานของ command palette บน macOS ของ Ghostty
  • แต่ในบริบทของ โปรเจกต์แบบ brownfield (โค้ดเบสเดิม) แชตบอตมักสร้างผลลัพธ์ที่ไม่ดี และกระบวนการคัดลอก-วางโค้ดกับเอาต์พุตก็ไร้ประสิทธิภาพกว่าทำเอง
  • หากต้องการได้คุณค่า จำเป็นต้องใช้ เอเจนต์ โดยเอเจนต์คือเครื่องมือที่ทำให้ LLM เรียกใช้การกระทำภายนอกซ้ำ ๆ ได้ และอย่างน้อยต้องอ่านไฟล์ รันโปรแกรม และส่ง HTTP request ได้

Step 2: ให้เอเจนต์ทำซ้ำงานของตัวเอง

  • ตอนใช้ Claude Code ครั้งแรก เขาไม่พอใจกับผลลัพธ์ และการตามแก้งานก็ใช้เวลานานกว่าทำเอง
  • แทนที่จะยอมแพ้ เขาฝึกซ้ำด้วยการให้ เอเจนต์ทำซ้ำคอมมิตที่เคยทำด้วยมือให้เหมือนกัน
    • แม้จะเป็นกระบวนการที่เจ็บปวดเพราะต้องทำงานเดิมสองครั้ง (ทำเอง + ให้เอเจนต์ทำ) แต่แรงเสียดทานแบบนี้เป็นเรื่องธรรมชาติเมื่อเริ่มนำเครื่องมือใหม่มาใช้
  • จากกระบวนการนี้ เขาค้นพบหลักสำคัญ 3 ข้อด้วยตัวเอง:
    • แยก session ออกเป็น งานย่อยที่ชัดเจนและลงมือทำได้
    • หากคำขอยังคลุมเครือ ให้แยก session สำหรับวางแผน กับ session สำหรับลงมือทำ ออกจากกัน
    • หากให้ วิธีตรวจสอบงาน กับเอเจนต์ มันจะสามารถแก้ความผิดพลาดของตัวเองและป้องกัน regression ได้
  • การเข้าใจว่าเอเจนต์ ทำอะไรได้ไม่ดี และรู้ว่าเมื่อใด ไม่ควรใช้มัน ก็เป็นปัจจัยสำคัญที่ช่วยเพิ่มประสิทธิภาพ
  • ในช่วงนี้ยังไม่รู้สึกถึงประสิทธิภาพสุทธิที่ดีขึ้น แต่ก็ยอมรับเอเจนต์เป็นเครื่องมือได้อย่างน่าพอใจ

Step 3: ใช้เอเจนต์ตอนจบวันทำงาน

  • เขานำรูปแบบการทำงานที่ใช้ 30 นาทีสุดท้ายของทุกวัน เพื่อเริ่มงานให้เอเจนต์มาใช้
    • สมมติฐานคือ หากเอเจนต์สร้างความคืบหน้าได้ในช่วงที่เราไม่ได้ทำงาน ก็จะเกิดประสิทธิภาพเพิ่มขึ้น
  • งาน 3 ประเภทที่ได้ผลดีคือ:
    • deep research session: สำรวจไลบรารีที่มีไลเซนส์เฉพาะในภาษาใดภาษาหนึ่ง พร้อมสรุปหลายหน้าเกี่ยวกับข้อดีข้อเสีย กิจกรรมการพัฒนา และเสียงตอบรับจากชุมชน
    • สำรวจไอเดียที่ยังคลุมเครือด้วยเอเจนต์แบบขนาน: ไม่ใช่เพื่อปล่อยออกสู่ผู้ใช้ แต่เพื่อค้นหาตัวแปรที่ยังไม่รู้ก่อนเริ่มงานจริงในวันถัดไป
    • คัดแยกและรีวิว issue กับ PR: ใช้ gh (GitHub CLI) ให้เอเจนต์แบบขนานช่วย triage issue โดยเอเจนต์จะไม่ตอบกลับเอง แต่สร้างรายงานไว้ให้อ้างอิงในวันถัดไป
  • เขาไม่ได้ปล่อยให้เอเจนต์วนทำงานทั้งคืน และส่วนใหญ่จะเสร็จภายใน 30 นาที
  • การเปลี่ยนช่วงเวลาที่เหนื่อยล้าในครึ่งหลังของวันให้เป็นงานของเอเจนต์ ทำให้ได้ผลแบบ “warm start” ในเช้าวันถัดไป

Step 4: มอบหมายงานที่มั่นใจได้

  • หลังรู้แล้วว่างานแบบไหนที่เอเจนต์มีแนวโน้มทำได้ดีมาก เขาก็มอบหมายงานเหล่านั้นให้ background agent และตัวเองไปโฟกัสกับงานอื่น
  • ทุกเช้าเขาจะกรองผล triage จากเมื่อคืนด้วยมือ เพื่อคัดเลือก issue ที่เหมาะให้เอเจนต์ทำ แล้วรันทีละรายการ
  • ในช่วงเวลานี้ เขาจะทำ งานคิดเชิงลึกแบบก่อนยุค AI ด้วยตัวเอง แทนการเล่นโซเชียลหรือดูวิดีโอ
  • สิ่งสำคัญคือ ปิด desktop notification ของเอเจนต์: เพราะต้นทุนของการสลับบริบทสูง จึงมีประสิทธิภาพกว่าถ้าเอเจนต์ไม่ขัดจังหวะมนุษย์ แต่ให้ไปตรวจเมื่อถึงจังหวะพักตามธรรมชาติ
  • สำหรับประเด็นจาก งานวิจัยเรื่องการก่อตัวของทักษะของ Anthropic: เขายอมรับว่าจะไม่ได้สร้างทักษะจากงานที่มอบหมายให้เอเจนต์ แต่ทักษะจะยังคงก่อตัวตามธรรมชาติในงานที่ยังทำด้วยมือ
  • ในขั้นนี้ เขาไปถึงระดับที่ “กลับไปแบบเดิมไม่ได้แล้ว” และข้อดีที่สุดคือได้โฟกัสกับงานที่ตัวเองชอบ

Step 5: harness engineering

  • เอเจนต์จะมีประสิทธิภาพที่สุดเมื่อให้ผลลัพธ์ที่ถูกต้องตั้งแต่ครั้งแรก หรืออย่างน้อยก็ต้องแก้ไขเพียงเล็กน้อย
  • ทุกครั้งที่เอเจนต์ทำพลาด การ ออกแบบวิธีแก้เพื่อไม่ให้พลาดแบบเดิมอีก คือแนวคิดของ "harness engineering"
  • มี 2 รูปแบบ:
    • ปรับปรุง implicit prompting (AGENTS.md): หากเอเจนต์รันคำสั่งผิดหรือหา API ผิด ก็แก้ด้วยการบันทึกไว้ในไฟล์ AGENTS.md — มีตัวอย่างจริงในรีโปของ Ghostty
    • เครื่องมือที่เขียนโปรแกรมไว้: เขียนสคริปต์สำหรับจับภาพหน้าจอ รันเทสต์แบบกรอง เป็นต้น แล้วแจ้งให้เอเจนต์รู้ว่ามีเครื่องมือเหล่านี้อยู่ผ่าน AGENTS.md
  • ตอนนี้เขาอยู่ในขั้นนี้ และกำลังลงทุนอย่างจริงจังเพื่อป้องกันพฤติกรรมแย่ของเอเจนต์และตรวจสอบพฤติกรรมที่ดี

Step 6: ให้เอเจนต์ทำงานอยู่เสมอ

  • ควบคู่กับ Step 5 เขาตั้งเป้าให้ มีเอเจนต์หนึ่งตัวทำงานอยู่เบื้องหลังตลอดเวลา
  • เขาชอบโมเดลช้าที่ใช้เวลามากกว่า 30 นาทีแต่ให้ผลลัพธ์คุณภาพสูง เช่น deep mode ของ Amp (อิง GPT-5.2-Codex)
  • ตอนนี้ ยังไม่รันหลายเอเจนต์พร้อมกัน เพราะมองว่าสมดุลระหว่างเอเจนต์หนึ่งตัวกับงานที่ทำด้วยมือนั้นเหมาะสมแล้ว
  • ในความเป็นจริง ตอนนี้ background agent ทำงานเพียงราว 10~20% ของเวลางาน และเขากำลังพยายามเพิ่มสัดส่วนนี้
  • เป้าหมายไม่ใช่การรันเอเจนต์เพื่อรันมันเอง แต่ต้องรัน เฉพาะเมื่อมีงานที่ช่วยได้จริง และการสร้างเวิร์กโฟลว์งานคุณภาพสูงที่มอบหมายได้ก็สำคัญไม่ว่าจะมี AI หรือไม่ก็ตาม

สถานะปัจจุบันและมุมมอง

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

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2026-02-06
ความคิดเห็นจาก Hacker News

  • หัวใจสำคัญคือการแบ่งเซสชันออกเป็น หน่วยงาน ที่ชัดเจนและลงมือทำได้
    ถ้าให้คำสั่งละเอียดเกินไปก็ไม่มีเหตุผลที่จะใช้ LLM และในทางกลับกัน ถ้ากว้างเกินไปแบบ “ช่วยสร้างแอป Facebook สำหรับสุนัขให้หน่อย” ก็จะได้แค่โปรโตไทป์ที่ไร้ประโยชน์
    ท้ายที่สุด การใช้ LLM กับงานเขียนโค้ดให้สำเร็จก็คือการหาช่วง ขอบเขตที่พอดี นี้ให้เจอ

    • ส่วนที่ชอบที่สุดเวลาใช้เครื่องมือ AI ก็คือการสร้าง สัญชาตญาณ แบบนี้
      การจับความรู้สึกให้ได้ว่างานแบบไหนมอบหมายแล้วจะได้ผลดี และค่อยปรับขอบเขตให้เหมาะ สมความสนุกคล้ายกับการทำ modularization ในการเขียนโปรแกรม
    • เคยล้มเหลวเพราะโยนคำขอใหญ่เกินไปแบบตัวอย่าง “Facebook for dogs”
      ใน Lovable รู้สึกเหมือนตั้งแต่ onboarding ก็ชวนให้ไปสู่ความล้มเหลวแล้ว แต่พอใช้ Claude Code แล้ว แยกงานให้เล็กลงแล้วค่อยทำ กลับสำเร็จกว่ามาก
    • ถ้าใช้ LLM แค่เพื่อหาตัวอย่างไวยากรณ์ for ก็สะดวกดี เพราะช่วยลด การสลับบริบท
      ช่วงแรก ๆ ก็ใช้งานมันเป็นผู้ช่วยเขียนโค้ดง่าย ๆ แบบนี้บ่อย
    • ยิ่งโมเดลพัฒนาขึ้น ก็ยิ่งรู้สึกว่า เพดานบนของขอบเขตที่พอดี ขยับสูงขึ้นทุก ๆ 6~8 สัปดาห์
    • บางครั้งบอกว่า “ช่วยพิมพ์ output ออกมาหน่อย” แล้วมันก็ตอบสนองด้วยการเพิ่มแค่ print(output) จริง ๆ
      การทำงานไปมาระหว่างภาษาธรรมชาติกับโค้ดกลับให้ความรู้สึก สบายใจในทางจิตใจ มากกว่า

  • ปี 2025 เป็นปีที่เครื่องมือ AI สำหรับเขียนโค้ดเข้าสู่ช่วง ใช้งานได้จริง อย่างแท้จริง
    ก่อนหน้านี้โมเดลยุคแรกอย่าง GPT-3 แค่แสดงให้เห็นถึงความเป็นไปได้ และทำให้เกิดทั้ง กระแส hype และความกังขา ที่เกินจริง
    แต่ตอนนี้นักพัฒนาจำนวนมากกำลังผสาน AI เข้าไปใน workflow จริงแล้ว
    ถ้ายังเป็นนักพัฒนาสายกังขาอยู่ ก็อยากแนะนำให้อ่านบทความของ Mitchell และลองใช้ Claude Code ด้วยตัวเอง

    • ฉันก็คิดเหมือนกัน อีก 10 ปีข้างหน้าคงน่าสนใจว่าเราจะจดจำช่วงเวลาไหนว่าเป็น จุดเปลี่ยน
      ช่วงหนึ่งเคยมีคนพูดกันมากเรื่อง “ข้อจำกัดของข้อมูล” แต่พอ Claude Code, Sonnet 4.5, Opus 4.5 ออกมา บรรยากาศก็เปลี่ยนไปอย่างสิ้นเชิง
    • สงสัยว่ามีเหตุผลอะไรที่ควรใช้ Claude Code แทน Codex หรือ Gemini ไหม
      สองโมเดลนั้นก็คล้ายกัน แต่ยังไม่ได้ลอง Claude เพราะได้ยินว่า ลิมิตการใช้งานตามแพ็กเกจ หมดเร็ว
    • แต่ก็ยังเป็นห่วง โครงสร้างอุตสาหกรรมที่ขับเคลื่อนด้วย hype อยู่ดี
      กลัวว่าผู้บริหารจะสนใจแค่ความเร็วกับปริมาณ แล้วผลิตกองโค้ดที่ดูแลต่อไม่ได้ออกมาเต็มไปหมด

  • แนวทาง “Don’t draw the owl” ก็ตรงกับประสบการณ์ของฉันเหมือนกัน
    ปัญหาคือ LLM มักจะ ลอยออกจากข้อจำกัดของโลกจริงและ drift มากขึ้นเรื่อย ๆ
    เลยแยกให้แชตใช้คุยเรื่องการออกแบบ ส่วน agent ให้ทำเฉพาะ งาน diff ที่แคบและตรวจสอบได้
    พอทำให้ลูปนี้นิ่งได้ มันก็ไม่ใช่ของเล่นอีกต่อไป แต่กลายเป็น คานงัดที่ใช้ได้จริง และฉันก็ deploy ฟีเจอร์ในโปรเจกต์จริงมาแล้วหลายครั้ง

    • มีคนทักว่าสำนวนการเขียนในบทความคล้าย LLM
      เดี๋ยวนี้โครงสร้างประโยคแบบ เป็นแพตเทิร์น ลักษณะนี้ก็เริ่มเพิ่มขึ้นในหมู่คนจริง ๆ ด้วย ซึ่งก็น่าสนใจ
    • อีกมุมหนึ่งก็รู้สึกว่าวิธีนี้จริง ๆ แล้วไม่ได้ต่างจาก วิธีที่เราควรเขียนซอฟต์แวร์มาตั้งแต่แรก เท่าไร

  • มีการพูดถึง Opus 4.5 กันมากขึ้น เลยลองใช้เองดู และรู้สึกได้ชัดว่า แนวคิดแบบ agent เริ่มมีประโยชน์จริงแล้ว
    ตอนนี้ยังเหมาะกับงานง่าย ๆ เป็นหลัก แต่ก็พอใจมาก

  • LLM ไม่เหมาะกับฉัน
    ความสามารถในการคิดและความสร้างสรรค์ ของมนุษย์คือสิ่งที่ทำให้เราแตกต่าง และฉันรู้สึกว่าถ้ายกสิ่งนั้นให้เครื่อง ก็เท่ากับบั่นทอนตัวเอง
    ในฐานะนักพัฒนา Rails ฉันลองใช้ Zed กับ Claude Sonnet 4.x และ Opus มาแล้ว แต่รู้สึกได้ว่าความสามารถในการ เขียน RSpec ของตัวเองค่อย ๆ ลดลง
    สุดท้ายก็กลับไปใช้ neovim และทำงานโดยไม่มี agent
    ความสะดวกสบายท้ายที่สุดอาจนำไปสู่ การเสื่อมถอยของความคิด ได้
    LLM คือ เครื่องมืออำนวยความสะดวกที่ดีที่สุด ที่มนุษย์เคยสร้าง แต่ฉันเลือกจะรักษาทักษะและความคิดของตัวเองไว้

  • บทความนี้ให้ความรู้สึก ใช้งานได้จริงและพูดเกินจริงน้อยกว่า โพสต์หน้าแรกอื่น ๆ มาก

    • ในที่สุดก็มี ไกด์แบบทีละขั้นตอน ที่แม้แต่คนสายกังขาก็ลองทำตามได้
      เป็นแนวทางที่สมจริง แทนคำโอ้อวดทำนอง “ฉันเขียน OS ได้ด้วย vibe coding”

  • น่าสนใจที่ทุกคนดูจะผ่าน เส้นทางการใช้งาน AI คล้าย ๆ กัน
    ใช้หลายโมเดลควบคู่กันกับส่วนต่าง ๆ ของ codebase และให้โมเดล ตรวจสอบกันเอง
    ฉันก็ยังต้อง git reset บ่อยอยู่ แต่ก็กำลังเรียนรู้วิธีหลีกเลี่ยงมันได้อย่างมีประสิทธิภาพมากขึ้นเรื่อย ๆ
    รู้สึกเหมือนกำลังมีชีวิตอยู่ในยุคของ ระบบเติมคำอัตโนมัติให้สมอง

  • มีคนบอกว่า “agent ควรจะอ่านไฟล์ รันโปรแกรม และส่ง HTTP request ได้”
    ซึ่งมันแทบจะระดับเดียวกับ ‘สามประสานมรณะ’ ที่ Simon Willison พูดถึงเลย

    • เพราะงั้นฉันไม่มีวันคิดจะรันอะไรแบบนั้นบนเครื่อง local ของตัวเองแน่

  • การที่ต้องคอยบอกจุดให้ agent ปรับปรุงตลอดมัน น่าหงุดหงิด
    ต้องคอยแก้ agent.md ทุกครั้งเพื่อให้ฟีดแบ็ก ถ้ามันเรียนรู้เองและดีขึ้นได้ก็คงดี

    • แต่สิ่งที่เป็นการปรับปรุงสำหรับบางคน อาจเป็น code smell สำหรับอีกคนก็ได้
      การเพิ่มไม่กี่บรรทัดใน AGENTS.md ก็ไม่ใช่เรื่องใหญ่อะไร
      ถ้าสร้างคำสั่ง /fix ให้มันแก้อัตโนมัติและบันทึกเอกสารไว้ด้วย ก็ช่วย ประหยัดเวลา ได้มากทีเดียว
    • ฉันกลับชอบการให้ฟีดแบ็กนะ
      มันทำให้รู้สึกว่าฉันยัง กุมอำนาจนำทางวิศวกรรม ไว้อยู่
      โดยเฉพาะเพราะมันช่วยให้ทำซ้ำงานวิจัยและการพัฒนาฟีเจอร์ใหม่ ๆ ได้อย่างรวดเร็ว

  • ถ้าอยากเห็นว่าการทำแบบนี้ในทางปฏิบัติหน้าตาเป็นอย่างไร
    ก็ลองดูโพสต์เก่าในบล็อกของ OP “Non-trivial Vibing” และ
    การถกเถียงบน HN ที่เกี่ยวกับมันได้