สร้างแอป Mac ด้วย Claude Code

 (indragie.com)
29 คะแนน โดย GN⁺ 2025-07-07 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เปิดตัวแอป macOS ขนาดมากกว่า 20,000 บรรทัดที่สร้างโค้ดแทบทั้งหมดด้วย Claude Code โดยโค้ดที่เขียนเองมีไม่ถึง 1,000 บรรทัด
  • การมาถึงของ AI coding agent ทำให้ได้ประสบการณ์การพัฒนาแบบเน้นพรอมป์ต์ แทนการใช้ IDE แบบเดิม
  • แม้การสร้างโค้ด Swift และ SwiftUI จะยังมีข้อจำกัดอยู่บ้าง แต่สามารถยกระดับคุณภาพได้ด้วยการออกแบบ priming, context engineering และ feedback loop
  • Claude จัดการได้แทบทั้งหมดตั้งแต่ automation, deployment, documentation และ testing ช่วยลดงานทำมือซ้ำ ๆ และเวลาที่สูญเสียไปได้อย่างมาก
  • IDE แห่งอนาคต จะวิวัฒน์ไปเป็น UX รูปแบบใหม่ที่เน้น การใช้งาน agent และการจัดการ context แทน code editor

ประสบการณ์การเปิดตัวแอป macOS ด้วย Claude Code เพียงอย่างเดียว

ภาพรวมโปรเจกต์

  • เมื่อไม่นานมานี้ได้เปิดตัวแอปเนทีฟบน macOS ชื่อ Context ซึ่งเป็น เครื่องมือสำหรับนักพัฒนาเพื่อดีบัก MCP server
  • แอปนี้ถูกสร้างขึ้นเกือบ 100% ด้วย Claude Code จากโค้ดประมาณ 20,000 บรรทัด มีโค้ดที่เขียนเองไม่ถึง 1,000 บรรทัด
  • การสร้างซอฟต์แวร์ด้วย Claude ยังคงต้องอาศัยทักษะของนักพัฒนา การทำซ้ำ และความสามารถในการเขียนพรอมป์ต์
  • บทความนี้อธิบายอย่างละเอียดถึงกระบวนการทั้งหมดในการสร้างแอปด้วย Claude Code การเลือกเครื่องมือ ข้อดีข้อเสีย และวิธีสร้างโค้ดคุณภาพสูง

1. จาก Copilot ไปสู่ Claude Code และการเปลี่ยนแปลงของสภาพแวดล้อมการพัฒนา

  • เครื่องมือ AI สำหรับเขียนโค้ดตัวแรกที่ใช้คือ GitHub Copilot และรู้สึกได้ทันทีว่าประสิทธิภาพการพัฒนาเพิ่มขึ้นมากแม้จะเป็นเพียงระบบ autocomplete ธรรมดา
  • หลังจากนั้นก็มีเครื่องมือแบบ agent จำนวนมากออกมา เช่น agent mode ของ Cursor และ Windsurf ซึ่งเป็น เครื่องมือแบบ agent ที่รวบรวม context จาก codebase และทำซ้ำขั้นตอน build·test ให้อัตโนมัติ
  • Claude Code ต่างจาก editor แบบเดิม (เช่น VS Code) เพราะมุ่งไปที่ สภาพแวดล้อมแบบ agent ล้วน ๆ ที่ทำงานบน terminal และเน้นการป้อนพรอมป์ต์
  • เป็น UX ที่เรียบง่าย โดยตัดฟังก์ชันส่วนใหญ่ของ IDE แบบเดิมออกไป เหลือเพียงกล่องพรอมป์ต์กับผลลัพธ์
  • ไม่ได้เป็นแค่ตัวช่วยเสริม IDE เดิม แต่เป็นความพยายามที่จะให้ coding agent เข้ามาแทนที่ IDE ไปเลย
  • แม้ตอนแรกจะสงสัยใน UX เพราะต่างจากเครื่องมือเดิมมาก แต่ก็รู้สึกว่าวิธีการใหม่นี้น่าสนใจจึงตัดสินใจลองใช้

2. กลับมาเริ่ม side project อีกครั้ง

  • เช่นเดียวกับนักพัฒนาหลายคนที่ทำงานประจำควบคู่กันไป side project ที่ทำไม่เสร็จก็มักสะสมเพิ่มขึ้นเรื่อย ๆ
  • แม้จะทำ prototype ได้อย่างรวดเร็ว แต่ช่วงสุดท้ายอีก 20% ที่ต้องเก็บงานให้เสร็จมักขาดทั้งเวลาและพลังงาน จึงไปไม่ถึงการเปิดตัวจริง
  • ระหว่างการทดสอบ MCP server จึงรู้สึกว่าจำเป็นต้องมีแอปเนทีฟ และตัดสินใจสร้างแอปขึ้นมาเอง
  • ในกระบวนการนี้เริ่มใช้ Claude Code อย่างจริงจัง และ สัมผัสได้ว่า AI agent ช่วยงานได้มากแค่ไหนในโลกจริง

3. ความสามารถในการสร้างโค้ดอันยอดเยี่ยมของ Claude Code

  • Claude Code ที่ใช้โมเดล Sonnet 4 และ Opus 4 ล่าสุดนั้น สร้างโค้ดดี ๆ ได้เร็วจริง
  • มันสามารถอ่านบริบทของโปรเจกต์ เข้าใจสไตล์โค้ด อ่านเอกสารและสเปกที่เกี่ยวข้องเพื่อพัฒนาฟีเจอร์ รวมถึงเขียนเทสต์โค้ดให้อัตโนมัติ
  • แทบทุกอย่างตั้งแต่การ build การทำซ้ำของการทดสอบ การวิเคราะห์ console log·screenshot ไปจนถึงการแก้บั๊ก ถูกทำให้เป็นอัตโนมัติ
  • ใช้เวลาเขียนโค้ดจริงของนักพัฒนาเพียงเศษเสี้ยว แต่สามารถ สร้างผลลัพธ์คุณภาพสูง ได้
  • ให้ผลลัพธ์ในระดับที่แม้พนักงานใหม่จะถูกโยนเข้ามาในโปรเจกต์โดยไม่มีบริบทเลย ก็ยัง ทำฟีเจอร์เสร็จได้ภายในไม่กี่นาที

4. คุณภาพจริงของการรองรับ Swift และ SwiftUI

  • ใช้ Swift 6.1, macOS 15.5 และ SwiftUI เวอร์ชันล่าสุด
  • Claude จัดการ Swift 5.5 ได้ดีเป็นส่วนใหญ่ แต่ยังไม่แข็งแรงนักกับการเปลี่ยนแปลงใหม่ ๆ เช่น concurrency
  • บางครั้งก็พลาดโดยผสม API สมัยใหม่กับ API แบบ legacy หรือผสม Objective-C กับ SwiftUI
  • สำหรับโค้ด SwiftUI แม้ร่างแรกจะยังไม่สมบูรณ์หรือค่อนข้างหยาบ แต่ถ้าสั่งซ้ำและปรับต่อก็สามารถขัดเกลาให้ดีได้มาก
  • เมื่อโค้ด UI ซับซ้อน มักเกิด compiler error (เช่น type inference ล้มเหลว) และ Claude สามารถรีแฟกเตอร์โค้ดเหล่านี้ให้เป็นฟังก์ชันย่อยที่เล็กลงได้อัตโนมัติ
  • หากระบุแนวทางไว้ในไฟล์ CLAUDE.md ก็สามารถยกระดับคุณภาพโค้ดของ Claude ขึ้นไปอีกขั้นได้
    • เช่น: ให้ใช้ SwiftUI ก่อน, ปฏิบัติตาม Apple Human Interface Guideline, ใช้ความสามารถล่าสุดของ macOS และ Swift6 อย่างเต็มที่ เป็นต้น
  • นอกจากนี้ หากนำแนวทางจากรีโพซิทอรี agent-rules มาใช้ ก็จะช่วยให้สร้างโค้ดคุณภาพสูงได้ดียิ่งขึ้น

5. ขอได้เลยว่า "ทำให้สวยขึ้นหน่อย"

  • สามารถสั่ง Claude ด้วยพรอมป์ต์ง่าย ๆ เช่น "ทำให้สวยขึ้น/ดูดีขึ้น/ใช้งานง่ายขึ้น" เพื่อ ปรับปรุงดีไซน์ UI ได้
  • บั๊กหรือจุดที่ควรปรับปรุงใน UI สามารถ วาง screenshot ให้ Claude แล้วให้ feedback แบบวนซ้ำ เพื่อให้แก้ไขได้ทันที
  • หากอยากทำอย่างเป็นระบบมากขึ้น ก็อาจเริ่มจากถามว่า "มีข้อเสนออะไรบ้างที่จะทำให้ UI สวยขึ้น" แล้วค่อยเลือกเฉพาะการเปลี่ยนแปลงที่ต้องการให้มันนำไปใช้

6. ความสำคัญของ context engineering

  • โมเดล AI ยุคนี้ เข้าใจได้ค่อนข้างดีแม้พรอมป์ต์จะไม่สมบูรณ์หรือมีข้อผิดพลาดทางไวยากรณ์
  • สิ่งที่สำคัญจริง ๆ คือ การวางเฉพาะข้อมูลที่จำเป็นที่สุดลงใน context window ที่มีจำกัด (200k token)
  • เมื่อบริบทของบทสนทนาเต็ม Claude จะทำการสรุปอัตโนมัติ (compaction) แล้วรีเซ็ต context ใหม่ ซึ่งในขั้นตอนนี้มีความเสี่ยงที่รายละเอียดบางส่วนจะหายไป หรือคุณภาพจะลดลง
  • ดังนั้น 'context engineering' ที่ดึงค่าคุณภาพสูงสุดออกมาจากบริบทที่มีจำกัด จึงเป็นโจทย์สำคัญที่สุดของการใช้งาน AI agent

7. Agent priming

  • เพราะในกระบวนการ compaction นี้บริบทสำคัญอาจตกหล่นได้ จึงมีประสิทธิภาพมากกว่าหากสั่งให้สรุปด้วยตนเองเมื่อจำเป็น หรือทำ priming โดยป้อนข้อมูลเพิ่มเติมล่วงหน้า
  • นอกจาก CLAUDE.md แล้ว หากเขียนพรอมป์ต์ให้มันอ่าน source code หรือเอกสารสเปกบางส่วนล่วงหน้าและสรุปออกมา คุณภาพของผลลัพธ์ก็จะดีขึ้น
  • แม้แต่ไลบรารีใหม่หรือ API ล่าสุดที่เกิดขึ้นหลัง knowledge cutoff ของ Claude ก็สามารถแปลงเอกสารด้วยเครื่องมือบางอย่าง เช่น Context7 หรือ llm.codes เพื่อให้ Claude เข้าใจได้ง่ายขึ้น
  • Priming คือกระบวนการทำให้ Claude เข้าใจบริบทอย่างครบถ้วนก่อน โดยสั่งประมาณว่า "อ่าน source file·document·spec เหล่านี้ทั้งหมดแล้วสรุปให้หน่อย"

8. Agent ต้องการสเปกที่ชัดเจน

  • เวลาจะให้ Claude พัฒนาฟีเจอร์ ต้องป้อน สเปกที่เฉพาะเจาะจงและละเอียด จึงจะได้ผลลัพธ์ตามต้องการ
  • สิ่งที่มักเห็นในเดโมอย่าง "สร้างแอปจากพรอมป์ต์ประโยคเดียว" นั้น ทำได้จริงแค่ในระดับ prototype เท่านั้น
  • แม้สเปกจะยังไม่ประณีตมาก ก็สามารถอธิบายด้วยวิธีที่ถนัด เช่น พูดด้วยเสียงหรือพิมพ์ตามสะดวก

9. "Ultrathink and Make a Plan"

  • หาก Claude รีบลงมือทำทันทีแบบไม่วางแผน คุณภาพของผลลัพธ์จะลดลง ดังนั้นกลยุทธ์ที่ได้ผลคือขอให้มันเริ่มจากการวางแผนก่อนด้วย โหมดคิดแบบขยาย เช่น 'think' หรือ 'ultrathink'
  • หากให้มันทบทวนแผนทีละขั้นและรับ feedback ก่อนลงมือทำ คุณภาพจะสูงขึ้น
  • แนะนำให้อ่านเอกสาร Claude Code: Best practices for agentic coding ของ Anthropic แบบไม่ควรพลาด

10. การสร้าง feedback loop

  • จุดแข็งที่แท้จริงของ Claude Code จะถูกขยายสูงสุดเมื่อ มันสามารถขับเคลื่อน feedback loop ได้อย่างอิสระ
  • กล่าวคือ หัวใจสำคัญคือการสร้างวงจรอัตโนมัติที่ Claude แก้โค้ดเอง (change) build เอง (test) วิเคราะห์สาเหตุของความล้มเหลว (เก็บ context) แล้ววนซ้ำอีกครั้ง
  • ยิ่งออกแบบลูปนี้ได้ดีเท่าไร Claude ก็จะยิ่งทำโค้ดคุณภาพสูงได้อย่างเป็นอิสระมากขึ้นเท่านั้น
  • 1. Build (บิลด์)
    • Claude ต้องสามารถ build (compile) แอปได้ด้วยตัวเอง
    • สำหรับ Swift package สามารถ build ได้ง่ายด้วยคำสั่ง swift build และ Claude ก็จัดการได้อย่างเป็นธรรมชาติ
    • แต่ในกรณีของ macOS app target (เช่น Xcode project) Claude มักสับสนว่าควรใช้คำสั่ง xcodebuild แบบใด
    • เพื่อแก้ปัญหานี้ จึงใช้เครื่องมือชื่อ XcodeBuildMCP ที่ให้ interface แบบง่ายขึ้นเพื่อช่วยให้ Claude build และรันแอปได้สะดวกกว่าเดิม
  • 2. Test (ทดสอบ)
    • หลังจาก build โค้ดแล้ว Claude ควรสามารถ รันการทดสอบโดยอัตโนมัติและวิเคราะห์ผลลัพธ์ได้
    • สำหรับ Swift package สามารถทดสอบได้อย่างเป็นธรรมชาติด้วย swift test และ Claude ก็จัดการกระบวนการนี้ได้ดี
    • แม้จะยังไม่ได้ทดลองให้ Claude รันการทดสอบทั้งแอปหรือ UI test โดยตรง แต่คาดว่างานลักษณะนี้ก็น่าจะต้องใช้เครื่องมืออย่าง XcodeBuildMCP เช่นกัน
    • จากผลลัพธ์ของการทดสอบ (log ความสำเร็จ/ล้มเหลว) Claude จะวนลูปแก้ไขโค้ดต่อไป
  • 3. Fix Bugs (แก้บั๊ก)
    • Claude สามารถไล่ปัญหาได้ด้วย วิธีเพิ่ม log เพื่อใช้ในการดีบัก
    • แต่ Claude ไม่สามารถโต้ตอบกับแอปโดยตรงเพื่อทำให้เกิด log ขึ้นมาเองได้
    • จึงจำเป็นต้องมี ขั้นตอนที่ผู้ใช้ควบคุมแอปด้วยตนเอง แล้วคัดลอก log จาก console มาวางให้ Claude
    • วิธีนี้ก็ใช้ได้ผลดีในทางปฏิบัติ แต่หาก ไม่ได้เขียน unit test หรือ UI test ไว้ให้เพียงพอล่วงหน้า ก็ยังยากที่จะทำให้การแก้บั๊กเป็นอัตโนมัติอย่างสมบูรณ์
    • สำหรับเว็บแอปมีโซลูชันด้าน browser automation เช่น playwright-mcp แต่ในโลกของแอปเนทีฟยังขาดทางเลือกที่ชัดเจน
  • 4. Fix UX Issues (แก้ปัญหา UX)
    • การปรับปรุงปัญหา UI/UX สามารถทำได้ด้วย การวาง screenshot ให้ Claude โดยตรงแล้วให้ feedback แบบวนซ้ำ
    • แม้จะสามารถใช้เครื่องมืออย่าง Peekaboo เพื่อทำ screenshot automation ได้ แต่ก็ยังมีข้อจำกัดว่า ต้องควบคุมแอปให้ไปอยู่ในสถานะที่ต้องการก่อนจึงจะจับภาพได้
    • กล่าวคือ แม้แต่ automation ด้าน UX ก็ยังต้องอาศัยการมีส่วนร่วมของผู้ใช้อยู่ดี

11. Claude Code ทำได้มากกว่าการเขียนโค้ด

  • Claude Code ทำงานบนพื้นฐานของ LLM แบบใช้งานทั่วไป จึงสามารถใช้กับ งานนอกเหนือจากการเขียนโค้ดได้หลากหลาย
  • ตัวอย่างเช่น สามารถขอให้ Claude ช่วยในงานที่ไม่ใช่งานพัฒนาโดยตรงได้อย่างเป็นธรรมชาติ เช่น แก้ไขข้อความภายในแอป วางแผนการปล่อยเวอร์ชัน หรือเสนอทิศทางการปรับปรุงฟีเจอร์
  • สิ่งหนึ่งที่มีประโยชน์มากเป็นพิเศษคือ ความสามารถในการสร้าง mock data อัตโนมัติในช่วงเริ่มต้นที่ยังไม่มีข้อมูลจริง
    • ตอนพัฒนาแอป Context ยังทำ MCP client library สำหรับ Swift ไม่เสร็จ แต่ก็อยากเดินหน้าทำ UI prototype ต่อ
    • ถ้าเป็นปกติ งานสร้าง mock data ที่ดูสมจริงด้วยมือจะยุ่งยากและกินเวลามาก จนแทบจะไม่ได้ลงมือทำเลย
    • แต่ Claude สามารถ สร้าง mock data ที่น่าเชื่อถือมากได้ภายในไม่กี่วินาที ทำให้ได้สถานะ UI ที่แทบแยกไม่ออกจากของจริง
    • เวลานำ UI ไปแชร์ให้เพื่อนดู ก็ใช้ screenshot ที่อิงจาก mock data นี้ ซึ่งให้ความรู้สึกไม่ต่างจากบริการจริง
    • สำหรับ MCP server ในตอนนั้น หลายส่วนยังรองรับเพียงฟีเจอร์บางส่วนของสเปกอย่างเป็นทางการ จึงเป็น สถานการณ์ที่ยากจะดึงข้อมูลจริงมาใช้
    • ถึงอย่างนั้น Claude ก็ยังช่วยให้ ตรวจสอบ flow ของ UI ทั้งหมดและการทำงานของฟีเจอร์ ได้ผ่าน mock data ที่สร้างขึ้น

12. ยุคที่การทำ automation คุณภาพสูงกลายเป็นสิ่งที่แทบจะฟรี

  • หนึ่งในส่วนที่เจ็บปวดที่สุดของการปล่อยซอฟต์แวร์ในช่วง 20% สุดท้าย คือ การทำ automation ของขั้นตอน release แอป
  • โดยเฉพาะแอป macOS ที่มีขั้นตอน deployment ซับซ้อนมาก เช่น code signing, notarization และ packaging (การสร้าง DMG) ทำให้การเปิดตัวมักล่าช้าเพราะต้องทำมือหรือพึ่งสคริปต์ที่ไม่เสถียร
  • ที่ผ่านมาเคยต้องฝืนเซ็ตเครื่องมือ automation อย่าง fastlane หรือไม่ก็เขียน Python script ขั้นพื้นฐานขึ้นมาใช้เอง
  • แต่ในโปรเจกต์นี้ Claude สามารถสร้าง release automation script ที่สมบูรณ์ได้ด้วย การทำพรอมป์ต์ซ้ำและดีบักเพียงไม่กี่ชั่วโมง
  • งานหลักที่สคริปต์นี้รับผิดชอบ ได้แก่:
    • ตรวจสอบการตั้งค่าสภาพแวดล้อม: เช็กว่าเครื่องมือที่จำเป็นถูกติดตั้งไว้อย่างถูกต้องหรือไม่
    • สร้าง changelog อัตโนมัติ: ดึงประวัติการเปลี่ยนแปลงจาก git commit แล้วรวมเข้ากับรายการที่เขียนด้วยมือเพื่อสร้าง release note แบบ HTML
    • build และ packaging ของแอป: ทำอัตโนมัติทั้งกระบวนการตั้งแต่ build แอป → code signing → notarization → packaging เป็น DMG
    • สร้าง Sparkle update feed (appcast): ส่งอัปเดตอัตโนมัติให้ผู้ใช้เดิม
    • แท็ก release และเผยแพร่: เพิ่มแท็กบน GitHub และเผยแพร่ release
    • อัปโหลด Sentry symbol: อัปโหลด debug symbol อัตโนมัติเพื่อใช้วิเคราะห์ crash report
  • หลังสคริปต์เสร็จแล้ว เพียงใช้ พรอมป์ต์บรรทัดเดียว ว่า "ทำให้ CLI output ดูสวยขึ้นหน่อย" ก็สามารถปรับปรุง CLI UI ได้อีกด้วย
  • ผลลัพธ์สุดท้ายคือ โค้ด Python ยาวราว 2,000 บรรทัด ซึ่งถ้าต้องทำด้วยมือคงทำได้แค่ฟีเจอร์ที่จำเป็นเท่านั้น แต่ด้วย Claude จึงปิดงานออกมาได้อย่างมีคุณภาพสูง
  • สคริปต์ automation นี้ช่วย ประหยัดงานซ้ำ ๆ ได้หลายสิบนาทีในทุกครั้งที่ปล่อยเวอร์ชัน
  • แค่บรรยายสเปกด้วยภาษาธรรมชาติ แล้วให้ Claude แก้จาก error ที่เจอระหว่างรัน งานส่วนใหญ่ก็เสร็จได้

13. IDE ในอนาคตจะเปลี่ยนไปอย่างสิ้นเชิง

  • ระหว่างทำโปรเจกต์นี้ เครื่องมือที่ใช้จริงตั้งแต่ต้นจนจบมีเพียง Claude Code กับ GitHub Desktop (สำหรับดู diff) เท่านั้น
  • ฟังก์ชันหลักของ IDE แบบดั้งเดิม เช่น file tree, code editor, extension และ plugin แทบไม่จำเป็นเลย
  • แม้จะมีบางครั้งที่เปิด Xcode เพื่อแก้โค้ดด้วยตัวเอง แต่ก็แทบไม่ได้ใช้ความสามารถเฉพาะของ Xcode (เช่น SwiftUI Previews, View Debugger เป็นต้น)
  • ตอนนี้ถือเป็นช่วงที่ ความสามารถของ AI coding agent ยังอยู่ในระดับต่ำที่สุดเมื่อเทียบกับอนาคต จึงรู้สึกได้ว่า IDE จะพัฒนาไปเป็นรูปแบบใหม่อย่างสิ้นเชิง
  • Copilot, Cursor, Windsurf และเครื่องมืออื่น ๆ ต่างเริ่มจาก VS Code แล้วค่อยเติมฟีเจอร์เพิ่มเข้าไป แต่ ตัว VS Code เองก็แทบไม่ต่างจาก JetBrains IDE เมื่อ 20 ปีก่อน
  • โปรเจกต์อย่าง Warp พยายามทำ terminal ให้ทันสมัยเพื่อเปลี่ยนให้เป็นสภาพแวดล้อมการพัฒนาแบบ agent แต่ก็ประเมินว่า UX ที่ยึด terminal เป็นศูนย์กลางก็ไม่น่าใช่คำตอบสุดท้ายของอนาคต
  • หัวใจของ IDE แห่งอนาคตคือการช่วยให้นักพัฒนาสามารถเตรียม context ให้ agent ได้อย่างมีประสิทธิภาพ (priming) และออกแบบ·จัดการ feedback loop ได้
  • กล่าวอีกอย่างคือ ศูนย์กลางจะไม่ใช่ code editor อีกต่อไป แต่จะเปลี่ยนไปเป็น UX ที่เน้นการใช้งาน agent และการจัดการ context อย่างมาก

14. กลับมาปล่อย side project ได้อีกครั้ง

  • สิ่งที่น่าประทับใจที่สุดในเส้นทางครั้งนี้ไม่ใช่แค่ การได้สร้างแอปที่ยอดเยี่ยม แต่คือการ กลับมาสามารถปล่อย side project ของตัวเองได้จริงอีกครั้ง
  • เหมือนได้เวลาเพิ่มวันละ 5 ชั่วโมง โดยมีค่าใช้จ่ายเพียง $200 ต่อเดือน
  • ด้วย AI coding agent อย่าง Claude Code จึงได้แรงขับและความมั่นใจกลับมาอีกครั้งในการเปลี่ยนไอเดียที่เลื่อนมานานให้กลายเป็นของจริง

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

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

 
geek12356 2025-07-08

ทำเยอะๆ
 
GN⁺ 2025-07-07
ความคิดเห็นจาก Hacker News

  • เมื่อ 2 ปีก่อนผมยังมั่นใจว่าตัวเองเป็นวิศวกร Python ที่เก่งมากจริง ๆ แต่ตอนนี้ผมสามารถสร้างทั้งแอปมือถือเนทีฟ, แอปเดสก์ท็อปที่คุยกับ Slack, API ที่เขียนด้วย Go, ไปจนถึงเว็บแอปเต็มรูปแบบที่ใช้ React ได้ภายในไม่กี่วันหรือไม่กี่ชั่วโมง
    มันให้ความรู้สึกเหมือนได้พลังพิเศษ ทั้งประสิทธิภาพ ความเร็ว และความคิดสร้างสรรค์พรั่งพรูออกมา แต่ในอีกด้านก็รู้สึกเศร้าแบบประหลาด ๆ
    งานของผม ความหลงใหลของผม และทุกอย่างที่ผมใช้เวลานานมากในการฝึกฝนและเสียสละเพื่อมัน ตอนนี้ส่วนใหญ่กำลังถูกเครื่องจักรเข้ามาแทนที่
    บริษัทที่สร้างเครื่องมือพวกนี้ยังเพิ่งอยู่แค่จุดเริ่มต้นเท่านั้น
    ผมสงสัยว่ามันจะมีความหมายอย่างไรต่อวิศวกรรุ่นถัดไป และกระแสนี้จะไปไกลได้แค่ไหน
    เลยอยากรู้ว่ามีใครรู้สึกแบบเดียวกับผมไหม

    • การที่ผมสามารถรับมือกับเครื่องมือหลากหลายบนหลายแพลตฟอร์มได้อย่างมีประสิทธิภาพ ทั้ง native, mobile, Go, React ฯลฯ นั้น เป็นเพราะมีประสบการณ์พัฒนาซอฟต์แวร์ในฐานะวิศวกร Python มาก่อน
      สิ่งที่ LLM เข้ามาแทนคือความจำเป็นในการท่องจำรายละเอียดจุกจิกเฉพาะแพลตฟอร์มพวกนั้น
      ถึงผมจะจำ syntax ของ for loop ใน Go ไม่ได้ ผมก็ยังเขียนโค้ด Go ที่ใช้งานได้ทันที
      แต่ก็ยังต้องเข้าใจหลักพื้นฐานเหมือนเดิม ไม่ว่าจะเป็น loop, แนวคิดของ Go, structured programming, compiler, สคริปต์ build และ test เป็นต้น
      คนที่ไม่มีพื้นฐานด้านการเขียนโปรแกรมจะขาดส่วนนี้ไปมาก
      ผมรู้สึกว่า LLM เป็นทั้งตัวขยายและตัวเร่ง ที่ทำให้ความรู้แบบคลุมเครือซึ่งสั่งสมมาตลอดอาชีพของผม ถูกนำไปใช้กับภาษาและแพลตฟอร์มต่าง ๆ ได้ทันที
      ก่อนหน้านี้ผมแก้ทุกปัญหาด้วย Python, JavaScript และ SQL เป็นหลัก เพราะไม่อยากกลับไปเรียนรู้ความต่างเล็ก ๆ น้อย ๆ ของภาษาและแพลตฟอร์มใหม่อีกครั้ง
      แต่ตอนนี้ผมยินดีใช้ Go, Bash, AppleScript, jq, ffmpeg และกำลังคิดจะลองทำโปรเจกต์ Swift ด้วย

    • ผมเคยเห็นคนที่ไม่ได้มาจากสายนี้ใช้ LLM สร้างอะไรสักอย่าง แต่ส่วนใหญ่ช้ากว่ามากหรือแทบล้มเหลว
      ทักษะทางเทคนิคอาจไม่ได้จำเป็นแบบขาดไม่ได้ในท้ายที่สุด แต่ความสามารถในการสื่อสารอย่างชัดเจนนั้นจำเป็นแน่นอน
      แค่เข้าใจ HTML ในระดับหนึ่ง ก็ช่วยให้จัดวางข้อความได้เป็นระเบียบและทำให้ LLM เข้าใจได้ชัดขึ้น
      ผมยังคิดว่าพื้นฐานด้านเทคนิคยังเป็นข้อได้เปรียบอยู่ดี

    • ผมคิดว่าคนงานฝีมือก่อนยุคปฏิวัติอุตสาหกรรมก็น่าจะเคยรู้สึกคล้ายกัน
      แต่ก็ต้องไม่ลืมว่าคนส่วนใหญ่ในยุคนั้นแทบไม่ได้รับการศึกษา ลูก 1-2 คนอาจเสียชีวิตจากโรคเล็กน้อยก่อนอายุ 10 ขวบ และต้องใช้ชีวิตโดยไม่มีไฟฟ้า น้ำประปา ระบบท่อในอาคาร หรือแม้แต่ตู้เย็น
      การทำเครื่องมือด้วยมือตัวเองมันโรแมนติกดีอยู่หรอก (เหมือนเขียนโค้ด Python ด้วยมือ) แต่เมื่อยุคสมัยพัฒนาไป การใช้ชีวิตอยู่บนชั้นนามธรรมที่สูงขึ้นกลับเป็นประโยชน์ต่อบรรพบุรุษของเราด้วยซ้ำ
      ไม่มีใครห้ามคุณเขียน Python ด้วยตัวเอง และผมเชื่อว่าจะต้องมีคนที่ทำมันเป็นงานอดิเรกแบบเดียวกับงานหัตถกรรมเฉพาะทางอย่างแน่นอน

    • ผมไม่ค่อยเห็นด้วยกับความคิดที่ว่างาน อาชีพ ความหลงใหล และทักษะที่ผมสั่งสมมาถูกเครื่องจักรเข้ามาแทนที่แล้ว
      เครื่องจักรเป็นแค่สิ่งที่ทำตามคำสั่ง โดยไม่มีประสบการณ์ ลางสังหรณ์ การไตร่ตรอง ความสามารถในการวางแผน หรือความคิดสร้างสรรค์
      มนุษย์เท่านั้นที่มีไอเดีย ความคิดสร้างสรรค์ เป้าหมาย ความเห็นอกเห็นใจ และสามารถโน้มน้าวผู้อื่นด้วยไอเดียที่ดี หรือพิจารณาบริบทให้เหมาะกับสถานการณ์ได้
      ผมคิดว่าอาชีพโปรแกรมเมอร์ไม่ได้หายไป แต่กำลังย้ายขึ้นไปอยู่ในระดับนามธรรมที่สูงขึ้นมากกว่า
      สมัยก่อนคุณเป็นนักพัฒนาได้โดยไม่ต้องรู้เรื่อง bit, byte หรือ assembly ทีละบรรทัด ทั้งที่เคยมีช่วงเวลาที่ assembly เป็นสิ่งจำเป็น
      ตอนนี้เราเข้าสู่ยุคที่แทบไม่ต้องรู้ภาษาโปรแกรมเลย แค่รู้ภาษาอังกฤษและเข้าใจ requirement ก็สร้างโปรแกรมได้
      ถึงอย่างนั้น คนที่เข้าใจโครงสร้างหน่วยความจำ, assembly และแนวคิดระดับต่ำ ก็ยังเข้าใจได้ดีกว่าว่าเบื้องหลังเกิดอะไรขึ้น และถ้าจำเป็นก็ทำได้ "ดีกว่า"
      แต่นั่นไม่ได้แปลว่าชั้นนามธรรมระดับบนจะไร้ประโยชน์หรือหายไป

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

  • บทความนี้เขียนได้ดีมาก และอ่านเพลินมาก
    IDE ในอนาคตจะต่างจากตอนนี้โดยสิ้นเชิง
    ผมเองก็เริ่มจาก Cursor ใช้ IDE แบบ VS Code ที่เสริมพลังขึ้นมา ก่อนจะย้ายไปใช้ Claude Code ในที่สุด
    พอเป็นแบบนั้น ความสำคัญของเทอร์มินัลก็เพิ่มขึ้น เลยเปลี่ยน workflow ไปใช้ iTerm กับ Ghostty (เร็ว เบา และทันสมัย), Tmux, Tmuxinator และ NeoVim
    ผมใช้คำสั่ง cat หรือ bat เพื่อตรวจดูไฟล์ แก้ไขข้อความเป็นครั้งคราว และปล่อยให้งานหนักส่วนใหญ่เป็นหน้าที่ของ Claude Code
    กลายเป็นว่า NeoVim หรือ Emacs ใช้ไว้แค่เขียนสเปกกับพรอมป์ต์ และผมชอบ workflow แบบนี้มาก
    ไม่ใช่แค่สร้างโค้ด แต่เวลาจะแก้ config ของ zsh, neovim, ghostty ฯลฯ ผมก็โยนงานให้ Claude Code ทำเหมือนกัน
    แม้แต่การรีแฟกเตอร์ไฟล์ตั้งค่าก็เสร็จในไม่กี่นาที
    ทั้งการถามเกี่ยวกับ codebase, รีแฟกเตอร์โค้ด, ทำเอกสารโค้ด, สร้าง commit message ผมก็ให้มันทำหมด เรียกได้ว่าสุดยอดจริง ๆ

    • ตอนท้ายมีพูดถึงการถามเกี่ยวกับ codebase, การรีแฟกเตอร์, การทำเอกสาร และแม้แต่การเขียน commit ที่มีความหมาย ผมเองก็เคยใช้ CC สร้าง commit message ดี ๆ แล้วเอาข้อมูลกับตัวอย่างของ Conventional Commits ไปใส่ไว้ใน ไฟล์ CLAUDE.md

    • อยากรู้ว่า CC สำรองไฟล์ตั้งค่าส่วนตัวอย่าง .zshrc ให้อัตโนมัติก่อนแก้ไหม

  • Terminal + Claude Code + โฟลเดอร์โปรเจกต์
    ตอนนี้เพิ่งตระหนักว่าแค่นี้ก็เพียงพอจริง ๆ
    เดิมทีผมก็ไม่ชอบ full IDE setup อยู่แล้วเพราะมันยุ่งยาก และเวลาจะ cross-compile แยกตาม OS ก็ต้องตั้งค่า QT ซับซ้อน แต่ผมรู้สึกมาตลอดว่าชุดผสมระหว่าง editor กับ terminal สมเหตุสมผลที่สุด
    พอมี Claude Code เป็นอีกหน้าต่างเทอร์มินัลที่เปิดไว้คอยช่วยจัดการคำขอ ก็เหมือนเลเวลอัปจากนักพัฒนาไปเป็นหัวหน้าโปรเจกต์
    โดยไม่ต้องมีความเครียดจากการบริหารคน
    ตอนนี้ผมทำ side project ที่อยากลองมานานทั้งหมดสำเร็จภายในไม่กี่เดือน นับตั้งแต่ Claude ออกมาในเดือนมีนาคม

  • เมื่อ 1-2 ปีก่อนผมเคยคิดไว้ว่า LLM เป็นผู้ช่วยที่ยอดเยี่ยมสำหรับนักพัฒนาที่มีประสบการณ์ ถ้าพยายามให้มาแทนนักพัฒนามีประสบการณ์จะออกมาเละเทะ และสำหรับนักพัฒนาที่ประสบการณ์น้อย มันคือผู้ช่วยที่อันตราย
    พอลองเองแล้ว โดยรวมก็พบว่าความคิดนี้ยังตรงอยู่
    ตอนนี้ผมคิดว่า LLM อาจเป็นเมนเทอร์ที่ดีให้กับนักพัฒนาที่ประสบการณ์น้อยได้เหมือนกัน แต่ในโลกจริงที่เจอบ่อยกว่าคือคนแก้โค้ดแบบสุ่มไปเรื่อย ๆ โดยไม่เข้าใจว่าทำไมมันถึงทำงาน จนกว่าจะพอใช้ได้
    สุดท้ายเลยยิ่งทำให้ผมเชื่อในความคิดเดิมว่า ในสถานการณ์แบบนั้น LLM คือผู้ช่วยที่อันตราย
    บั๊กหรือปัญหาเล็ก ๆ ละเอียดอ่อนมักจะซ่อนอยู่ในโค้ดโดยไม่มีใครสังเกตเห็น และถึงจะเห็นก็มักไม่เข้าใจสาเหตุ

  • ข้อสรุปที่ว่าผู้ช่วย LLM ทำให้ 20% สุดท้ายของ side project เสร็จง่ายขึ้นมากนั้นน่าสนใจเป็นพิเศษ
    สำหรับผม สิ่งที่น่าสนใจที่สุดในการเดินทางนี้ไม่ใช่การสร้างแอปใหม่ แต่คือการได้กลับมาสนุกกับการเขียนโค้ด และสามารถปล่อย side project ที่สะอาดเรียบร้อยและสมบูรณ์ได้อีกครั้ง
    มันเหมือนมีเวลาเพิ่มขึ้นวันละ 5 ชั่วโมง และจ่ายแค่เดือนละ 200 ดอลลาร์ก็พอ

  • ผมใช้มันทำ utility เล็ก ๆ เป็นหลัก และมันทำงานได้ยอดเยี่ยมจริง ๆ
    ผมใช้ Claude ทำ utility ที่แสดงสถานะของ task ใน launchctl/launchd (กำลังทำงาน/ยกเลิกโหลด/ล้มเหลว ฯลฯ) ในลักษณะคล้ายไอคอนเมนูของ OrbStack ได้ตามที่ต้องการภายในไม่กี่ชั่วโมง

    • ผมเองก็เคยทำทั้งแอป iOS และปลั๊กอิน Wordpress ไว้ใช้เล่นสนุกส่วนตัว แล้วพอใจกับผลลัพธ์มาก
      จากนี้ไปน่าจะมีคนทำแบบนี้กันมากขึ้น เลยสงสัยว่าทุกคนน่าจะแชร์โค้ดลง github กันไหม

  • ถ้าเป็นคนที่ทำซอฟต์แวร์บน Mac มาตั้งแต่ปี 2008 ก็น่าจะจับได้เร็วว่า Claude พลาดตรงไหน และแก้ให้ถูกได้ทันที

    • เครื่องมืออย่าง Claude Code มีหน้าที่ขยายพลังให้กับทักษะและประสบการณ์ที่มีอยู่
      มันไม่มีทางมาแทนความเชี่ยวชาญได้

    • ท้ายที่สุด พอมาถึงตอนจบของบทความก็พบว่างานนี้มีค่าใช้จ่ายเดือนละ 200 ดอลลาร์ ซึ่งสำหรับผม แค่ Autodesk ที่จำเป็นกับงานอดิเรกหลักยังจ่าย 50 ดอลลาร์แบบเสียดายเลย
      บริษัท AI พวกนี้ยังไม่มีกำไร และถ้านักลงทุนเริ่มไล่หาผลตอบแทนจริงจัง ต้นทุนก็มีแต่จะพุ่งขึ้นหรือคุณภาพบริการก็ต้องลดลงอย่างเลี่ยงไม่ได้
      ถ้าโมเดลพวกนี้แพ้คดีเรื่องเอาโค้ดไปฝึกโดยไม่ได้รับอนุญาต ความสามารถของ Claude ในการสร้าง Swift ก็น่าจะตกฮวบในทันที
      ผมก็ไม่แน่ใจว่าเราควรคาดหวังจริง ๆ หรือว่า Disney จะแพ้คดี AI
      พูดตามตรงคอมเมนต์ของผมอาจไม่มีความหมายมาก แต่ความเหนื่อยล้าจาก AI นั้นรุนแรงจริง ๆ
      ณ จุดนี้ ผมคิดว่าโพสต์แบบนี้ควรถูกแบนจาก HN และเว็บบอร์ดเทคอื่น ๆ ด้วยซ้ำ
      ถ้ามีคนมาโพสต์ว่าตัวเองเขียนโค้ดได้ง่ายด้วย Google หรือ StackOverflow ทุกคนก็คงประชดว่าไร้สาระกันหมด และผมคิดว่าโพสต์แบบนี้ก็ไม่ต่างกัน
      ผมเริ่มเอือมกับเรื่องเล่าว่าใช้ AI "เกาะฟรี" กับงานอดิเรกหรืออาชีพ

  • ตอนนี้การสร้างเครื่องมือเฉพาะทางสำหรับตัวเองด้วยเครื่องมืออย่าง Windsurf และ CLI tools ง่ายกว่าสมัยก่อนมาก
    เป็นช่วงเวลาที่น่าตื่นเต้นจริง ๆ

  • รู้สึกว่าอีกไม่นานคงมีคนใช้ LLM ทำสำเนา MacOS ทั้งระบบได้

  • เมื่อไม่กี่สัปดาห์ก่อน ผมใช้ LLM tooling จนสามารถทำให้แอป system 6 (Classic Mac) ที่เขียนด้วย retro68 และ c++ บูต 6DOF wireframe renderer ขึ้นมาได้สำเร็จ