AI ช่วยเขียนโค้ดส่งผลต่อการทำงานของคุณอย่างไรบ้าง?

 (news.ycombinator.com)
10 คะแนน โดย GN⁺ 2026-03-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ถ้าคุณเคยลอง ใช้เครื่องมือ AI กับงานเขียนโค้ดระดับมืออาชีพ ในช่วงที่ผ่านมา ช่วยแชร์ประสบการณ์หน่อย
    • คุณใช้เครื่องมืออะไรบ้าง?
    • อะไรได้ผลดี และเพราะอะไร?
    • คุณเจอความยากลำบากอะไร และแก้ไขอย่างไร? (ถ้าแก้ได้)
  • จะขอบคุณมากถ้าคุณให้ บริบทที่มากพอ (tech stack, ประเภทโปรเจ็กต์, ขนาดทีม, ระดับประสบการณ์) เพื่อให้คนอื่นได้เรียนรู้จากประสบการณ์ของคุณ
  • เป้าหมายคือทำความเข้าใจสภาพความเป็นจริงของการพัฒนาที่ขับเคลื่อนด้วย AI ณ เดือนมีนาคม 2026 แบบเป็นกลาง โดยไม่เล่าเกินจริง

สรุปคำตอบจาก Hacker News

ปัญหาเอกสารและการสื่อสารที่ AI สร้างขึ้น

  • ผู้จัดการสร้าง เอกสารออกแบบ, PRD, และสไลด์เด็คยาว 50 หน้า ด้วย Claude แล้วส่งมาให้ “รีวิวด่วน” ทั้งที่ผู้เขียนเองก็ยังไม่ได้อ่าน
  • พนักงานบางคนสร้างสไลด์ไม่รู้จบ แต่ หลีกเลี่ยงการตอบคำถามที่เจาะจง
  • ปัญหาประสิทธิภาพ DB ที่เมื่อก่อนใช้ 30 นาทีก็แก้ได้ (เช่น เพิ่ม GSI) ตอนนี้กลับใช้ เวลาหนึ่งสัปดาห์ เพราะมีเอกสาร 37 หน้าที่ AI สร้างขึ้นมา (คำอธิบาย, การบรรเทา, แผน, รีวิว, ความเสี่ยง, การปล่อยใช้งาน ฯลฯ)
  • เริ่มเกิดรูปแบบการสื่อสารแบบ “AI คุยกับ AI” ที่เมื่อมีการส่งคอนเทนต์จาก AI ผู้รับก็ใช้ AI สรุปอีกที
    • ในกระบวนการ “แนวคิด → LLM ขยายความ → LLM สรุป → ผู้รับ” มีความเสี่ยงที่ บริบทและนัยสำคัญจะหายไปเหมือนเกมกระซิบ
  • มีเสียงวิจารณ์ว่าการที่ฝ่ายหนึ่งผลิตคอนเทนต์คุณภาพต่ำจำนวนมาก แล้วคาดหวังให้อีกฝ่าย รีวิวอย่างใส่ใจ เป็นความคาดหวังที่ไม่สมดุลและไม่ให้เกียรติ
  • มีกรณีที่ลูกค้าฟรีแลนซ์ส่งสเปกที่ละเอียดเกินจริงจาก AI มา แต่ความต้องการจริงคือแค่ ตาราง CSV 30 แถว เท่านั้น

ประสบการณ์เชิงลบในที่ทำงาน

  • นักพัฒนาระดับบนใช้ AI ทำทุกอย่าง แล้ว โยนงานเก็บกวาดให้รุ่นล่าง
    • โค้ดที่ AI สร้าง ไม่ทำตามการออกแบบ API ของโปรเจ็กต์หลัก และมีโค้ดจัดการ error กับ parsing ที่ไม่จำเป็นจำนวนมาก
    • แม้ต้องใช้เวลาจัดระเบียบเกิน 1 สัปดาห์ แต่เพราะทีมเดิมส่งงานได้แทบจะทันที จึงเกิดภาพลวงว่า กลับช้าลงกว่าเดิม
  • บริษัทจดทะเบียนขนาดใหญ่แห่งหนึ่งตั้งเป้าให้ 100% ของโค้ดถูกสร้างด้วย AI ภายใน 1 ปี และให้พนักงานทุกระดับที่คัดค้านออกจากงาน
  • ในวัฒนธรรมที่เน้น ความเร็วในการปล่อยฟีเจอร์ มากกว่าคุณภาพโค้ด วิศวกรที่ทำงานด้านคุณภาพกลับถูกมองว่า “ไม่มีประสิทธิภาพ” ซึ่งเป็นปัญหาเชิงโครงสร้าง
  • มีทีมเมตคนนำ โค้ดเมื่อหลายสัปดาห์ก่อนมาใส่ Claude แล้วส่งเหมือนเป็นงานเสร็จสมบูรณ์ ทั้งที่มีข้อผิดพลาดด้าน requirement ทางธุรกิจและบั๊กร้ายแรงจำนวนมาก
  • ในสภาพแวดล้อมที่บังคับใช้ AI ภาระ code review เพิ่มขึ้นอย่างมาก และต้องตรวจ PR คุณภาพต่ำยาวหลายพันบรรทัดทุกวัน
    • มีคนอธิบายว่า “ทุกอย่างที่ฉันเคยชอบถูกพรากไป เหลือไว้แต่สิ่งที่ฉันไม่ชอบ”

ประสบการณ์จาก FAANG และบริษัทใหญ่

  • พนักงาน FAANG รายหนึ่งบอกว่า ในงานจริง ไม่เคยได้ผลลัพธ์ที่ commit ได้เลยแม้แต่ครั้งเดียว แต่ในโปรเจ็กต์ส่วนตัวเร็วขึ้น 10 เท่า
    • เพราะ framework และ library ภายใน ของ codebase ขนาดใหญ่ไม่มีอยู่ในข้อมูลฝึก ทำให้โมเดลมองเห็นบริบทได้จำกัด
    • ในทีมแทบ ไม่รู้จักใครที่มีกรณีสำเร็จแบบเป็นรูปธรรม
  • วิศวกร Amazon ใช้ Kiro (เครื่องมือภายในของ AWS) กับ Opus 4.6 แล้วเพิ่มผลิตภาพได้ 2~4 เท่าในงานประจำ และมากกว่า 10 เท่าในธุรกิจเสริม
    • ใช้ไม่ใช่แค่เขียนโค้ด แต่ยังใช้กับ การวิเคราะห์ข้อมูล, การดีบั๊ก, และการจัดการ deployment loop
    • ฟีเจอร์ที่เดิมต้องใช้เวลาหนึ่งเดือน ทำได้ใน 2 สัปดาห์ — หัวใจสำคัญคือ ประหยัดเวลาศึกษาเทคนิคเฉพาะทาง ที่คงไม่ได้ใช้อีก
  • กรณี outage ของ Amazon: ข่าวที่ว่าห้ามใช้โค้ดจาก AI ไม่ตรงกับความจริง โดยระหว่างเหตุขัดข้อง มีประเด็นเกี่ยวกับ AI เพียง 1 กรณี ที่เป็นคำแนะนำจาก internal wiki เก่า
  • วิศวกร Microsoft ใช้ GitHub Copilot พร้อม Opus แบบไม่จำกัด งานเร็วขึ้นแต่ ความคาดหวังสูงเกินจริง (จากเดิม 2 สัปดาห์ กลายเป็นคาดว่าจะเสร็จใน 2 วัน)
  • ฝ่าย R&D ของบริษัทใหญ่พบคุณค่าสูงสุดจาก การติดตามบั๊กและการสร้างโค้ด logging แบบใช้ครั้งเดียว และความเร็วในการทำ prototype ก็เพิ่มขึ้นอย่างมาก
    • แต่เมื่อค่าใช้จ่ายในการลงมือลดลง การแข่งขันเรื่อง “จะสร้างอะไร” ก็รุนแรงขึ้น ต้องคิดให้เร็วและตัดสินใจให้ชัดเจนกว่าเดิม

ประสบการณ์เชิงบวกและกรณีเพิ่มผลิตภาพ

  • วิศวกรประสบการณ์ 10 ปี ในทีมเล็ก สร้างและดูแล แอปผู้บริโภคที่มี 100K DAU ด้วยคน 3 คน ซึ่งก่อนหน้านี้คาดว่าต้องใช้ 10 คน
    • ไม่มี bug list ค้างไว้, มีแค่ 2 คนที่เข้าใจ codebase เกือบทั้งหมด, และ ทำ refactoring ได้บ่อยขึ้นมาก
  • Simon Willison: ตั้งแต่เดือนพฤศจิกายน 2025 เป็นต้นมา เขียนโค้ดส่วนใหญ่ด้วย agent และทำงานผ่าน Claude Code บน iPhone ด้วย
    • โปรเจ็กต์ที่คิดมาหลายปีถูกสร้างได้ในไม่กี่ชั่วโมง เป็นการ ปรับกรอบความเป็นไปได้ของนักพัฒนาเดี่ยว ใหม่
    • เขียนแอป Go ด้วย Claude Code และเรียนรู้ภาษาใหม่ผ่าน การซึมซับไปพร้อมการทำงาน
  • ฟรีแลนซ์สายเทคนิคที่ชำนาญ ใช้ Claude Code แล้วได้ความแม่นยำของ Terraform ถึง 95% และในโปรเจ็กต์ประมวลผลข้อมูล เร็วขึ้นมากกว่า 5 เท่า
    • “สิ่งที่เคยทำไม่ได้ ตอนนี้ทำได้ สิ่งที่เคยยากกลายเป็นง่าย และสิ่งที่เคยง่ายก็ทั้งเร็วและง่ายขึ้น”
  • สตูดิโอเกมขนาดเล็กใช้กับเครื่องมือภายในและการปรับปรุง workflow โดย ยิ่งใกล้ระดับไอเดียมากเท่าไร AI coding ยิ่งได้ผล
  • เจ้าของโรงเบียร์ขนาดเล็กใช้สร้าง เครื่องมือภายในมากกว่า 5 ตัว เช่น ระบบอัตโนมัติสำหรับบัญชี (16 ชั่วโมง/เดือน → 3 ชั่วโมง), รายงานการผลิตและการขาย, แอปติดตามรีวอร์ด

การใช้ทำความเข้าใจ codebase และการดีบั๊ก

  • ใน codebase ขนาดใหญ่หรือระบบเก่า มีประโยชน์กับคำถามอย่าง “มีฟังก์ชันไหนบ้างที่แตะตารางนี้?”
  • การสำรวจ monolith ขนาดใหญ่: ถามว่า “API endpoint นี้มีวิธี auth กี่แบบ?” แล้ว AI สามารถ หาและสรุปได้ 4 แบบใน 5 นาที
  • การดีบั๊ก: เก่งมากในการหาว่าทำไม regex ซับซ้อนถึงไม่ match รวมถึง การวิเคราะห์ stack trace และ log
  • เวลา onboarding กับ codebase ที่ไม่คุ้นเคย ลดจากหลายวันเหลือไม่กี่นาที
    • กระบวนการที่เดิมต้อง “ถามเพื่อนร่วมงานที่อินเดียหรือยุโรปตะวันออกแล้วรอข้ามคืน” ตอนนี้ AI เข้ามาแทนได้เกือบทั้งหมด

ความกังวลเรื่องคุณภาพโค้ดและการบำรุงรักษา

  • ปัญหาที่พบอย่างสม่ำเสมอในโค้ดจาก AI คือ ความซับซ้อนเกินจำเป็น, การจัดการ error มากเกินไป, logic ซ้ำซ้อน, และไม่ใช้ฟังก์ชันเดิมที่มีอยู่แล้ว
  • ถ้าเป็นโค้ดที่ต้องบำรุงรักษาต่อ การเขียนเอง มักเร็วกว่าในระยะยาว — เพราะเมื่อกลับมาแก้ทีหลัง โค้ดจาก AI ไม่มี mental model รองรับ
  • มีกรณีที่ Claude พยายามเปลี่ยน HTML sanitizer เป็น custom regex — แม้เทสต์ผ่าน แต่เปิดช่องโหว่ด้านความปลอดภัย
  • มีกรณีสร้าง API ที่มีระบบยืนยันตัวตน แต่ดันเพิ่ม route ที่ใครก็ PUT API key ใหม่ได้
  • AI แทบไม่ทำ refactoring เชิงรุก เพื่อลดความซับซ้อนของ codebase แต่กลับสะสม logic ซ้ำ, abstraction ที่ไม่จำเป็น, และ dependency cycle ต่อไปเรื่อย ๆ
  • แม้จะมีกรณี codebase 200K LOC ที่เขียนด้วย AI ถึง 99.5% แต่เงื่อนไขคือ ใช้ TDD อย่างเข้มงวดและรีวิวทุกบรรทัด

การถดถอยของทักษะและผลกระทบทางจิตใจ

  • “เพราะฉันรู้สไตล์ความขี้เกียจของตัวเองดี ทักษะคงถดถอยแน่” — จึงเลือกไม่ใช้การสร้างโค้ดด้วย AI เลย
    • มีเพื่อนร่วมงานคนหนึ่งยอมรับว่าพึ่งพา AI มาตลอด 6 เดือนที่ผ่านมา และแม้อยากเลิกก็ เผลอหยิบมาใช้ง่ายเหมือนการเสพติดยา
    • นักพัฒนาจูเนียร์คนหนึ่งตลอดปีที่ผ่านมา ส่ง MR ที่แปลกขึ้นเรื่อย ๆ และพบร่องรอยการใช้ AI
  • วิศวกรอาวุโสคนหนึ่งบอกว่า “รู้ว่าทักษะการเขียนโค้ดกำลังถดถอย แต่ก็ไม่แน่ใจว่าส่วนที่ชอบจริง ๆ คือการเขียนโค้ดหรือเปล่า” — จึง ใช้เวลากับการออกแบบและสถาปัตยกรรมมากขึ้น
  • ในโปรเจ็กต์ส่วนตัว แม้ AI จะทำให้สร้างได้เร็วขึ้น 10 เท่า แต่กลับ ไม่รู้สึกผูกพันเพราะไม่เหมือนเป็นสิ่งที่ตัวเองสร้าง และหมดแรงจูงใจจะทำให้เสร็จ
  • “AI ทำส่วนที่เคยชอบได้ดี และทำให้ต้อง ใช้เวลากับส่วนที่ไม่ชอบหรือทำให้เหนื่อยมากขึ้น” — ความเครียดโดยรวมเพิ่มขึ้น
  • วิศวกรปีที่ 3 บอกว่า AI ทำได้ 90% ก็จริง แต่ถ้าจะทำ อีก 10% ที่เหลือ ต้องมี mental model ของ 90% แรก ซึ่งจะเกิดขึ้นได้ก็ต่อเมื่อเขียนเอง

workflow ที่มีประสิทธิภาพและ best practices

  • ลำดับ สเปก → แผน → วิจารณ์ → ปรับแผน → ลงมือทำ ให้ผลลัพธ์คุณภาพสูงที่สุด
    • ใช้ Plan Mode ก่อนลงมือ และหลังเขียนเสร็จให้ใช้โมเดลเดียวกัน เพิ่ม code review อีกชั้น (แนะนำให้แยกเซสชัน)
  • ใช้ไฟล์ AGENTS.md / CLAUDE.md บันทึก style การเขียนโค้ด, pattern, และข้อห้าม — แล้วอัปเดตเมื่อจบแต่ละเซสชัน
  • ให้ agent มี ความสามารถดีบั๊กและตรวจสอบด้วยตัวเอง เช่น รันเทสต์, เช็ก log, ตรวจ screenshot
  • ถ้าระบุข้อจำกัดล่วงหน้า (“ใช้แค่ standard library, ไม่สร้างไฟล์ใหม่, ไม่เกิน 50 บรรทัด”) คุณภาพผลลัพธ์จะดีขึ้นอย่างมาก
  • ใช้ state file (mechanical ledger) ระหว่างหลาย agent เพื่อบันทึก commit, test, และ patch ที่ล้มเหลว ทำให้เซสชันใหม่ สร้างบริบทจากสถานะจริง แทนการพึ่งความจำ
  • ใช้ Git worktree เพื่อ ทำหลายงานแบบขนาน พร้อมแยกบริบทของแต่ละงาน

บทบาทที่ไม่ใช่สายเทคนิคและการขยายตัวของ AI

  • PM/ผู้อำนวยการฝ่ายปฏิบัติการ: ในบริษัทเล็กที่ไม่มีโปรแกรมเมอร์ สามารถ สร้างเครื่องมือภายใน 12 ตัวในปีที่ผ่านมา และเรียนรู้แนวคิดการพัฒนาได้เร็วอย่างน่าทึ่ง
  • ผู้ร่วมก่อตั้งที่ไม่ใช่สายเทคนิค: สร้าง functional prototype ได้ แต่ การยกระดับสู่ production ยังต้องการวิศวกร — การ pair programming มีประสิทธิผลมากกว่าเอกสารออกแบบ
  • ผู้จัดการที่ไม่ใช่สายเทคนิคใช้ MS Copilot สร้างโค้ด ESRI Arcade แล้วต้องใช้ pair session 3 ชั่วโมงเพื่อดีบั๊ก — บทบาท “ผู้เชี่ยวชาญด้าน AI debugging” เริ่มกลายเป็นงานใหม่ที่คิดค่าบริการได้

ความแตกต่างของประสิทธิผลตามโดเมน

  • การพัฒนาเว็บ/API: ระดับ A มีประสิทธิภาพทั้งสแต็กตั้งแต่สถาปัตยกรรมไปจนถึงการดีบั๊กปัญหา compatibility ของแพ็กเกจ
  • Unity/การพัฒนาเกม: ระดับ C- ไม่เข้าใจ scene graph, component model, และพฤติกรรมที่ขึ้นกับฮาร์ดแวร์
  • ภาพถ่ายทางการแพทย์: ล้มเหลวเพราะขาดความรู้เฉพาะทาง และ ข้อเสนอการปรับ performance ไม่ได้ช่วยอะไรกับข้อมูลจริงเลย
  • แอปพลิเคชัน Rust: ใช้ได้ผลกับ Python/เว็บแบบ greenfield แต่กับ แอป Rust ขนาดต่ำกว่า 100K LOC workflow แบบ agent กลับไม่มีประสิทธิผล
  • signal processing, embedded, HPC: หลอนข้อมูลบ่อย และเมื่อทำงานกับ external API ที่ไม่มีเอกสาร แทบใช้ไม่ได้เลย
  • อัลกอริทึมกราฟ C++: ผลลัพธ์ ไม่เป็นเชิงเส้นอย่างมาก — ไม่ถูกตั้งแต่ครั้งเดียวก็พังไปเลย ไม่มีตรงกลาง

มุมมองต่ออุตสาหกรรมและความกังวล

  • มีการคาดการณ์ว่า “ภายใน 5~7 ปี ความหลงใหล AI แบบไร้เหตุผลของระดับ CEO/CFO จะนำไปสู่ การขาดแคลนบุคลากรอย่างหนักและเงินเดือนเพิ่ม 3 เท่า”
  • มีความกังวลว่า “คนระดับกลางจะหายไป เหลือแค่ ซีเนียร์จำนวนน้อยที่ตั้งทิศทาง ประสานงาน และลงมือทำ”
  • AI กำลังเข้าสู่ช่วง recursive self-improvement และไม่มีใครคาดเดาได้ว่าอีก 6 เดือนจะไปถึงไหน
  • งานวิจัยของ MIT ยืนยันข้อจำกัดของการ scale ความกว้าง (width) ของโมเดล และยังมีปัญหาข้อมูลฝึกใกล้หมดกับคุณภาพของข้อมูลสังเคราะห์ที่ลดลง
  • “ไม่ก็ทุกคนตกงาน ไม่ก็ตลาดจะพังครั้งใหญ่ในไม่ช้า หรือไม่ก็ทั้งสองอย่าง” — เป็นยุคที่ น่าตื่นเต้นแต่ก็น่ากังวล
  • ตลาดฟรีแลนซ์: คนที่ทำงานจากความสัมพันธ์ระยะยาวยัง ไม่รู้สึกถึงการชะลอตัว แต่โปรเจ็กต์เล็กแบบครั้งเดียวมีโอกาสถูกแทนที่ด้วย AI

การเลือกที่จะไม่ใช้ AI

  • ก่อนมี LLM ก็มีระบบอัตโนมัติเดิมจากเพื่อนร่วมงานอยู่แล้ว แต่ AI ให้ความรู้สึกเหมือน ต้องคอยดูแลจูเนียร์ที่ไม่เก่ง จนหมดความสนใจ
  • “มันเป็นกับดักที่ ไม่ได้แก้ปัญหาอะไร แต่เพิ่มปัญหาใหม่เท่านั้น” — จึง ห้ามใช้ AI ในงานของตัวเองเป็นนโยบาย
  • วงการหุ่นยนต์: ใช้ C++ และ Python แต่เมื่อทดลองใช้ AI เขียนโค้ด กลับได้แค่ ขยะที่พอทำงานได้ครึ่ง ๆ กลาง ๆ และการอธิบายด้วยภาษาธรรมชาติก็ทรมาน
  • กระบวนการคิดถึงสถาปัตยกรรมโค้ดและอนาคตทางเทคนิคผ่านการลงมือเขียนเอง เป็นคุณค่าที่ ไม่มีทางมอบหมายแทนได้

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

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

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

  • ทุกวันนี้สิ่งที่หนักใจที่สุดคือ ผู้จัดการใช้ Claude สร้างเอกสารออกแบบหรือ PRD ยาว 50 หน้า แล้วส่งมาบอกว่า “ช่วยรีวิวหน่อย”
    ไม่มีใครอ่าน และแม้แต่คนเขียนเองก็ยังไม่เข้าใจ บางคนในบริษัทสร้างสไลด์เด็คยาวไม่รู้จบ พอถามก็พูดอ้อมๆ ไม่ตรงคำถาม
    แถมคนที่ไม่ได้เขียนโค้ดมานานก็กลับมาเสนอโค้ดอีกเพราะ AI แต่ไอเดียหลายอย่างก็แปลกมาก
    ผมยังเขียนโค้ด production เองทั้งหมด และใช้ AI แค่ช่วยตรวจบั๊กเท่านั้น งานอย่างสคริปต์สำหรับโหลดเทสต์ง่ายๆ ค่อยปล่อยให้ AI ทำ

    • เมื่อก่อนแก้ปัญหา performance ของ DB ใช้เวลา 30 นาที ตอนนี้กลายเป็น เอกสาร 37 หน้า มีทั้งคำอธิบาย แผนงาน และการวิเคราะห์ความเสี่ยง ดูดีแต่เสียเวลา
    • ผมเองก็ลาออกเพราะเรื่องนี้เหมือนกัน ผู้จัดการน่าจะใช้ ChatGPT ฟรี เอกสารเลยกลายเป็น ข้อความยืดยาวที่จับความหมายไม่ได้ ทุกครั้งที่ถูกขอให้รีวิวคือทรมานมาก
    • ถ้าใครโยนเอกสารที่เห็นชัดว่า AI เขียนมาให้ผม ผมก็เอาไปให้ AI สรุปอีกที ไม่งั้นก็เดินไปให้เขาอธิบายเอง
    • จากประสบการณ์ผม LLM ใช้ได้ดีกับโค้ดที่ผมไม่ต้องกลับมาแก้ทีหลัง แต่ ความสามารถด้านการออกแบบแย่มาก
    • ผู้จัดการที่บริษัทผมก็ใช้ LLM สร้าง Jira ticket อัตโนมัติ เหมือนกัน แต่ใส่รายละเอียด implementation ที่ไร้สาระลงไปจน junior งง สุดท้าย senior ต้องมาเก็บงาน

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

    • เดี๋ยวนี้ฝั่งผู้ก่อตั้งหมกมุ่นกับ ความคลั่งไคล้ผลิตภาพ มาก พยายามทำให้ทุกอย่างเป็นอัตโนมัติ แต่หลายครั้งก็ไม่รู้ด้วยซ้ำว่าทำไปเพื่ออะไร
      ตอนนี้แม้แต่สิทธิ์ที่จะพูดว่า “ไม่รู้” ก็แทบไม่มีแล้ว เพราะแค่ใส่ prompt บรรทัดเดียวก็เหมือนต้องได้คำตอบ ทำให้ backend developer ต้องแบก frontend ไปด้วย
    • นี่ไม่น่าใช่ปัญหา AI แต่เป็น ปัญหาโครงสร้างทีม มากกว่า ทำไมเพื่อนร่วมงานถึงมารับผิดชอบงานของคุณแทน แล้วผู้จัดการทำอะไรอยู่?
    • ถ้ามีใครจะทำงานบนโค้ดเก่า ก็ต้องบอกไปตรงๆ ว่า “ใช้โค้ดล่าสุดสิ”

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

    • ถ้าอยู่ในสถานการณ์แบบนี้แล้วเอาแต่นิ่งเงียบคอยเก็บงาน คุณก็กลายเป็นส่วนหนึ่งของปัญหาได้เหมือนกัน ความรับผิดชอบต่อคุณภาพโค้ด AI ยังเป็นของคนที่ส่งมันมาอยู่ดี
    • กับงานแบบนี้ผมจะส่งลิงก์ “code proven to work” ไปเลย การโยนโค้ด AI ที่ยังไม่ผ่านการพิสูจน์ให้คนอื่นมาลำบากต่อเป็นเรื่องไม่เป็นมืออาชีพ
    • การตรวจสอบดีไซน์ API ควรถูกบังคับอัตโนมัติใน CI ถ้าไม่ผ่านก็ควรห้าม merge PR
    • ถ้าได้รับโค้ดพังๆ มาก็ถามกลับไปเลยว่า “อันนี้มันใช้งานไม่ได้ ต้องทำใหม่ใช่ไหม?”
    • โค้ดที่ AI สร้างมักมี การจัดการ error ที่ไม่จำเป็นหรือโค้ด parsing ซ้ำซ้อน ซึ่งสุดท้ายก็ต้องให้คนมานั่งเก็บ
    • งานเก็บกวาดแบบนี้คือ งานที่ทรหดที่สุด แก้ข้อบกพร่องเชิงโครงสร้างแต่แทบไม่ได้รับการยอมรับ

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

    • ผมก็ใช้ ChatGPT Pro เรียนคณิตศาสตร์ เหมือนกัน แต่จะไม่ใช้กับการเขียนโปรแกรมเด็ดขาด เพราะเสียสัญชาตญาณการเขียนโค้ดแน่ๆ
      ตอนรีบๆ ก็เปิดดูแค่ API reference ชั่วคราว
    • การ เสื่อมถอยของความสามารถในการเขียนโค้ดด้วยมือ เป็นเรื่องจริง เหมือนเลิกใช้แผนที่กระดาษแล้วพึ่ง Google Maps แทน
      แต่ข้ออ้างว่าโค้ดจาก AI ดูแลรักษาไม่ได้ ผมว่าฟังไม่ค่อยสมเหตุสมผล ถ้าไม่ชอบก็ generate ใหม่ได้
      ผมเคยเห็นเคสที่ AI เขียน framework ทั้งตัวใหม่หมดด้วยซ้ำ
    • ตอนแรกผมก็ไม่ชอบ แต่ตอนนี้กลายเป็นว่า ขาด AI ไม่ได้แล้ว ความเร็วเพิ่มขึ้น 5 เท่า แต่บางทีก็หลุดบริบทแล้วเสียเวลาไปทั้งสัปดาห์
    • ผมใช้ AI คุยเรื่องไอเดียหรือตัวทดสอบ แต่ ไม่โยนงานให้โดยไม่เข้าใจมัน
      คุณค่าของวิศวกรอยู่ที่ความเข้าใจ การทำ automation แบบไร้ความเข้าใจคือการทำให้ทุนมนุษย์เสื่อมลง

  • ผมเป็นวิศวกรที่ Amazon และใช้ Kiro harness ภายในกับ Opus 4.6
    ผลิตภาพเพิ่มขึ้น 2–4 เท่าในงานบริษัท และมากกว่า 10 เท่าในโปรเจกต์ข้าง
    เมื่อก่อนต้องทำโอที แต่ตอนนี้ทำงาน 9–5 ก็ปล่อยฟีเจอร์ได้มากกว่าเดิม
    AI ไม่ได้มีประโยชน์แค่กับการเขียนโค้ด แต่ยังช่วยเรื่อง deployment automation, data analysis และ debugging ด้วย
    ตัวอย่างเช่นหลังแก้โค้ดแล้ว AI จะวนลูป deploy ไปยังสภาพแวดล้อม gamma และตรวจสอบผ่าน CloudWatch logs ให้เอง
    ทำให้ผมทำงานปริมาณหนึ่งเดือนได้เสร็จในสองสัปดาห์ ผมไม่เข้าใจเหมือนกันว่าทำไมคนถึงบอกว่า SWE จะถูกทำให้เป็นอัตโนมัติก่อน
    แม้ LLM จะยังมีข้อจำกัด แต่แค่ระดับตอนนี้ก็ กำลังเปลี่ยนภูมิทัศน์ของ software engineering แล้ว

    • ช่วงนี้มีข่าวลือว่า ห้าม junior push โค้ดจาก AI ไม่รู้จริงไหม
    • ผมก็เคยใช้ AI ตอน deploy บริการ bridge ที่เชื่อม Linear กับ Coder.com เหมือนกัน การทำ automation ที่ผสาน kubectl กับ MCP มันเปิดโลกมาก
    • อยากรู้ว่าทำไมคุณถึงกำลังเตรียมหางานใหม่ และมีอะไรที่ทำไม่ได้ในงานปัจจุบันบ้าง
    • ผมเห็นด้วย เมื่อก่อนเสียเวลาไปกับการเรียนเทคโนโลยีที่ไม่ค่อยมีประโยชน์ แต่พอมี AI แล้ว ความเร็วในการเซ็ตอัปสภาพแวดล้อมและการเรียนรู้ ดีขึ้นมาก
      แค่ก็กังวลกับ การระเบิดของโค้ดคุณภาพต่ำ ที่ AI สร้างขึ้น
    • คำว่า “วิศวกร Amazon” นี่ถือเป็น คำพูดในนามบริษัทอย่างเป็นทางการ หรือเปล่า?

  • ผมทำงานที่ FAANG ในงานจริง AI แทบไม่ช่วยอะไรเลย
    ใช้ได้แค่สรุปเอกสารออกแบบหรือค้นหาโค้ดเท่านั้น ผม ไม่เคยได้ commit ที่ใช้งานได้จริง จากมันเลย
    รอบตัวก็ไม่เห็นใครใช้อย่างได้ผลจริงด้วย
    แต่กับโปรเจกต์ส่วนตัว ถ้าเป็น งานใหม่ชิ้นเล็กๆ มันเร็วขึ้น 10 เท่าจริง
    น่าจะเพราะ codebase ในบริษัทมันใหญ่และซับซ้อนเกินไป

    • ตรงกันข้ามเลย ผมใช้ AI เขียนตั้งแต่ Terraform ไปจนถึงโปรเจกต์ big data รวมเกิน 10,000 บรรทัดแล้ว
      95% ใช้งานได้สมบูรณ์ และส่วนที่จะมีปัญหาก็คาดเดาได้
      ตอนเพื่อนร่วมงานขอให้ช่วยเรื่อง data sampling ผมก็แก้ให้สดๆ ตรงนั้นได้เลย
      งานที่เมื่อก่อนใช้เวลาหลายชั่วโมง ตอนนี้จบได้ระหว่างคุยกัน
      สิ่งที่เคยทำไม่ได้ก็ทำได้ สิ่งที่เคยยากก็ง่ายขึ้น สิ่งที่เคยง่ายก็เร็วขึ้นอีก
    • สำหรับผมมันมีประโยชน์กับสคริปต์สั้นๆ แต่ถ้าเป็น โดเมนที่ไม่รู้จักกลับยิ่งช้าลง
    • ผมก็อยู่ FAANG เหมือนกัน และช่วงหลัง เครื่องมือ AI ภายในพัฒนาดีขึ้นมาก
      การทำ prototype เร็วขึ้น และ LLM ก็เคยชี้ข้อบกพร่องในการออกแบบ API ให้ผมด้วย
      แต่การ generate โค้ดเร็วเกินไปจะทำให้เร็วเกินกว่าความสามารถในการรีวิว ดังนั้นหัวใจคือ ให้มันสร้างทีละหน่วยเล็กๆ
      มันยังช่วยมากกับการแก้เทสต์หรือไล่หาสาเหตุของ build error จากภายนอกด้วย
      ผมไม่ได้สนุกกับงานแบบนี้มานานแล้ว แต่ขณะเดียวกันก็รู้สึกกังวลเรื่องงานมาก
    • codebase ของ FAANG มี framework ภายในแบบปิด เยอะมาก ซึ่งเป็นส่วนที่ LLM ไม่เคยถูกฝึกมา
      เพราะงั้นผลลัพธ์ที่ไม่แม่นก็เป็นเรื่องธรรมดา
    • ผมก็เห็นด้วยว่า ยิ่งงานเล็กยิ่งทำได้ดี งานขนาดใหญ่ไม่เหมาะกับมัน

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

    • การใช้แบบนี้เพื่อ ช่วยเสริมความเข้าใจ น่าจะปลอดภัยและได้ผลที่สุด
      สุดท้ายแล้วคนก็ยังต้องเข้าใจบริบทและเป็นผู้ตรวจสอบอยู่ดี

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

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

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

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

  • น่าแปลกที่บรรยากาศบน HN มอง AI ในแง่ลบ ซึ่งทำให้ผมค่อนข้างแปลกใจ
    ผมเป็นวิศวกรมา 10 ปีแล้ว และครึ่งหนึ่งของสิ่งที่พูดกันบน Twitter เป็นเรื่องจริง
    ทีมเรามี 3 คนแต่ดูแลแอปที่มี 100k DAU ได้อยู่ ซึ่งเมื่อก่อนเป็นงานที่ต้องใช้ 10 คน
    เราไม่มีรายการบั๊กค้าง และคุณภาพโค้ดก็ไม่ได้แย่กว่าสมัยเขียนมือ
    ความถี่ในการ refactor กลับเพิ่มขึ้นด้วยซ้ำ และความเร็วก็พุ่งมาก ผมพอใจมากจริงๆ

    • ผมเข้าใจว่าทำไม HN ถึงมองลบ แต่ AI ตอนนี้ เข้าใจโค้ดได้ดีกว่ามนุษย์แล้ว
      เพียงแต่ตอนนี้เรายังอยู่ในช่วงที่มันช่วยเพิ่มโค้ดเข้าไปเรื่อยๆ จนเสี่ยงให้ความซับซ้อนระเบิด
      ถึงอย่างนั้น อีก 6 เดือนข้างหน้าอาจต่างไปจากเดิมโดยสิ้นเชิง ตอนนี้ทั้งน่าตื่นเต้นและน่ากลัวในเวลาเดียวกัน
    • นักพัฒนาส่วนใหญ่ยังอยู่ในภาวะ กลัวและสับสน
      แต่ยิ่งเป็นทีมเล็กก็ยิ่งใช้ AI แล้วได้ ผลิตภาพแบบระเบิด
    • 100k DAU เลยเหรอ ขอลิงก์ดูหน่อย
    • ถ้าขนาดนั้น อีกไม่นานก็คงมี แอปก๊อปปี้โผล่มาเต็ม แล้วผู้ใช้ส่วนใหญ่ก็คงไหลออกไป