คิดถึงช่วงเวลาที่ได้คิดอย่างลึกซึ้ง
(jernesto.com)- การมาถึงของเครื่องมือเขียนโค้ดด้วย AI ทำให้ประสบการณ์ของการ คิดอย่างลึกซึ้ง ลดลงอย่างรวดเร็ว จนรู้สึกว่า การเติบโต ในฐานะวิศวกรเริ่มชะงักงัน
- ในบรรดาตัวตนสองด้านในตัวเอง คือ 'Builder' และ 'Thinker' นั้น Builder ได้รับการเติมเต็มด้วย AI แต่ Thinker กำลังอดอยาก
- ด้วย "vibe coding" เราสามารถเปลี่ยนไอเดียให้เป็นความจริงได้อย่างรวดเร็ว แต่ โอกาสในการแก้ปัญหาอย่างสร้างสรรค์ กลับลดลงอย่างมาก
- เมื่อ AI มอบโซลูชันระดับ 70% ที่ “ดีพอใช้ได้” มาให้ ก็ยากที่จะปฏิเสธมันได้ด้วยนิสัยแบบ ปฏิบัตินิยม
- ผู้เขียนพยายามมองหาความพึงพอใจจากการคิดลึกนอกโลกการเขียนโค้ด แต่ไม่สำเร็จ และยัง ไม่แน่ใจ ว่าจะเติมเต็มความต้องการทั้งสองอย่างพร้อมกันได้หรือไม่
การตั้งคำถามต่อภาวะขาดแคลนการคิด
- ก่อนอ่านบทความนี้ ลองถามตัวเองว่า “ครั้งสุดท้ายที่คุณได้คิดอย่างจริงจังคือเมื่อไร”
- บทความนี้ไม่ใช่คำตอบหรือคำแนะนำ แต่เป็นเพียง การระบายความอัดอั้นที่รู้สึกอยู่ในช่วงนี้
นิสัยสองแบบ: Builder และ Thinker
- Builder: นิสัยที่อยากสร้าง ปล่อยใช้งาน และสร้างผลลัพธ์ที่ใช้งานได้จริง
- ถูกขับเคลื่อนด้วยความเร็วและประโยชน์ใช้สอย
- ได้รับความสุขจากโดพามีนของการ deploy สำเร็จ จากความพอใจเมื่อสร้างระบบที่แก้ปัญหาจริงได้ และจากการรู้ว่ามีใครบางคนกำลังใช้เครื่องมือที่ตัวเองสร้าง
- Thinker: นิสัยที่ต้องการการต่อสู้ทางความคิดอย่างลึกและยาวนาน
- ตอนเรียนมหาวิทยาลัยในสาขาฟิสิกส์ เคยได้รับโจทย์การบ้านที่ยากเกินระดับเฉลี่ยไปมาก
- แม้จะเข้าใจแนวคิดแล้ว แต่ก็ยังมีโจทย์ที่ยากแม้แต่จะนึกวิธีเข้าหา
นักศึกษาสามประเภทเมื่อเผชิญปัญหาที่ยาก
- ประเภท 1 (คนส่วนใหญ่): ลองอยู่ไม่กี่ครั้งแล้วก็ยอมแพ้ จากนั้นไปขอความช่วยเหลือจากอาจารย์หรือผู้ช่วยสอน
- ประเภท 2 (สายวิจัย): ไปหาปัญหาคล้ายกันหรือคำใบ้ในห้องสมุดจนทำให้ตัวเองอยู่ในสภาพที่แก้โจทย์ได้ และโดยมากก็ไปถึงคำตอบ
- ประเภท 3 (สาย Thinker): ใช้วิธีคิดล้วน ๆ ในการเข้าหาโจทย์
- ใช้เวลาเกือบทั้งหมดของสมองในโหมด non-I/O ตลอดหลายวันหรือหลายสัปดาห์ไปกับความเป็นไปได้ในการแก้ปัญหา
- แม้ตอนนอน การคิดก็ยังดำเนินต่อไป
- วิธีนี้ไม่เคยล้มเหลวเลยแม้แต่ครั้งเดียว และทำให้ตระหนักว่า การคิดลึกและยาวนานคือจุดแข็งของตัวเอง
- แม้จะไม่เร็วหรือมีพรสวรรค์โดยกำเนิดแบบคนระดับท็อป 1% แต่ก็มั่นใจว่าถ้ามีเวลามากพอ จะสามารถแก้ปัญหาอะไรก็ได้
ความขัดแย้งกับ AI
- เหตุผลที่วิศวกรรมซอฟต์แวร์เคยน่าพึงพอใจอย่างมากตั้งแต่แรก ก็เพราะมันมอบ ความพึงพอใจสองชั้น นี้เอง
- ได้เติมเต็มทั้ง Builder (สร้างสิ่งที่มีประโยชน์ จึงรู้สึกมีประสิทธิผลและใช้งานได้จริง) และ Thinker (ได้แก้ปัญหาที่ยากจริง ๆ)
- โปรเจกต์ที่ทำให้เติบโตมากที่สุดในฐานะวิศวกรมักมี ปัญหาที่ยากและต้องการวิธีแก้แบบสร้างสรรค์ อยู่มากเสมอ
- แต่ช่วงหลังมานี้ จำนวนครั้งที่นั่งจับปัญหาเดียวแล้วคิดอย่างจริงจังเกินสองสามชั่วโมงลดลงอย่างรวดเร็ว
- ผู้เขียนคิดว่าต้นเหตุของเรื่องทั้งหมดนี้คือ AI
- แม้ตอนนี้จะเขียนซอฟต์แวร์ได้มากขึ้นและซับซ้อนขึ้นกว่าที่เคย แต่กลับรู้สึกว่าไม่ได้เติบโตในฐานะวิศวกรเลย
- เมื่อย้อนดูสาเหตุของความรู้สึกว่า “ชะงักงัน” ก็พบว่า ตัวเองกำลังปล่อยให้ Thinker อดอยาก
- "vibe coding" ช่วย เติมเต็ม Builder อย่างชัดเจน
- การที่ไอเดียถูกแปลงเป็นของจริงแทบจะทันทีในเวลาอันสั้นนั้นให้ความรู้สึกสะใจในทันที
- แต่ในทางกลับกัน ช่วงเวลาที่ต้องคิดหาวิธีแก้ปัญหาทางเทคนิคด้วยความสร้างสรรค์ของตัวเองกลับลดลงอย่างมาก
- สำหรับคนที่เป็น Builder ล้วน ๆ ยุคนี้คือช่วงเวลาที่ดีที่สุด
- แต่สำหรับผู้เขียน ยังชัดเจนว่ามีบางอย่างขาดหายไป
กับดักของปฏิบัตินิยม
- ผู้เขียนคาดว่าจะมีคนโต้แย้งว่า “ถ้าแก้ได้ด้วย vibe coding แปลว่าเดิมทีมันก็ไม่ใช่ปัญหาที่ยากจริง”
- แต่ข้อโต้แย้งนี้พลาดประเด็นสำคัญไป
- AI ไม่ได้เก่งเป็นพิเศษกับปัญหายาก และก็ไม่ได้ให้คำตอบที่ดีเสมอไปแม้กับปัญหาง่าย
- ถ้าต้องเขียนโมดูลเดียวกันขึ้นมาใหม่ด้วยตัวเองเป็นครั้งที่สาม ผู้เขียนก็ยังมั่นใจว่าจะทำได้ดีกว่าผลลัพธ์ใด ๆ ที่ AI สร้างขึ้น
- แต่ในขณะเดียวกัน ผู้เขียนก็เป็น นักปฏิบัตินิยม
- ถ้าใช้เวลาและแรงเพียงเสี้ยวเดียวแล้วได้วิธีแก้ที่ “ใกล้เคียงพอ” การ ไม่เลือกใช้ AI กลับดูไม่สมเหตุสมผล
- ปัญหาที่แท้จริงคือ ไม่สามารถปิดโหมดปฏิบัตินิยมนี้ได้อย่างมีสติ (หรือเมินมันไปได้)
- โดยเนื้อแท้แล้วเป็น Builder และชอบการสร้างอะไรบางอย่างด้วยตัวมันเอง หากทำได้เร็วขึ้น มันก็มักจะรู้สึกดีกว่าเสมอ
- ต่อให้พยายามปฏิเสธ AI และอยากย้อนกลับไปยังยุคที่ความต้องการของ Thinker ได้รับการเติมเต็มอย่างเป็นธรรมชาติผ่านการเขียนโค้ด Builder ก็ทนความไร้ประสิทธิภาพนั้นได้ยาก
- แม้ AI จะไม่ได้ให้คำตอบที่น่าพอใจ 100% อย่างแทบแน่นอน แต่ คำตอบระดับ 70% ที่มันไปถึงได้ก็มักผ่านเกณฑ์ว่า “ดีพอ”
แล้วต่อจากนี้ควรทำอย่างไร?
- พูดตามตรง ผู้เขียนยังหาคำตอบไม่เจอ และยังคงครุ่นคิดเรื่องนี้ต่อไป
- ไม่มั่นใจอีกต่อไปแล้วว่านิสัยสองแบบนี้จะยังได้รับการเติมเต็มพร้อมกันได้ภายในพื้นที่เดียวกันอย่างการเขียนโค้ดหรือไม่
- ทางเลือกหนึ่งคือเล็งไปที่โปรเจกต์ที่ยากขึ้น เพื่อจงใจหาปัญหาที่ AI ล้มเหลวโดยสิ้นเชิง
- แม้จะยังเจอปัญหาแบบนั้นเป็นบางครั้ง แต่ก็รู้สึกว่าปัญหาที่ต้องการวิธีแก้เชิงสร้างสรรค์อย่างลึกซึ้งกำลังลดลงอย่างรวดเร็ว
- ผู้เขียนยังพยายามเรียกความรู้สึกของการเติบโตทางความคิดกลับมาจากนอกโลกการเขียนโค้ดด้วย
- ถึงขั้นหยิบตำราฟิสิกส์เก่า ๆ ขึ้นมาเปิดอีกครั้งเพื่อกลับไปเชื่อมโยงกับฟิสิกส์
- แต่ก็ไม่ได้ต่อยอดไปสู่ความพึงพอใจที่แท้จริง
- ในสถานการณ์ที่สามารถลงมือสร้างอะไรบางอย่างได้ การจะให้เหตุผลกับตัวเองว่าควรใช้เวลาและพลังทางความคิดไปกับปัญหาฟิสิกส์ที่ไม่เกี่ยวข้องโดยตรงกับปัจจุบันหรือไม่ทันสมัยแล้ว เป็นเรื่องยาก
- ด้าน Builder ไม่ยอมให้ตัวเองเพียงนั่งอยู่กับปัญหาที่ยังไม่คลี่คลายแล้วครุ่นคิด
- ด้าน Thinker ก็ยังคงอดอยากต่อไปตราบใดที่ vibe coding ยังดำเนินอยู่
- ผู้เขียนไม่แน่ใจว่าช่วงเวลาที่ความต้องการทั้งสองด้านจะได้รับการเติมเต็มพร้อมกันจะกลับมาอีกหรือไม่
> “บัดนี้ เราได้รับสิทธิที่จะเรียกสิ่งมีชีวิตนี้ด้วยชื่อนั้น ชื่ออันคุ้นเคยซึ่งเคยใช้ชี้ไปยังสิ่งที่ไม่มีพลังแห่งจินตนาการใด การทะยานของความเพ้อฝันอันห้าวหาญที่สุด ความศรัทธาอันเคร่งครัดที่สุด ความคิดเชิงนามธรรมที่ลึกซึ้งเพียงใด หรือแม้แต่จิตที่ตกอยู่ในภวังค์ ก็ไม่อาจเอื้อมถึงได้ นั่นคือ พระเจ้า (God). แต่เอกภาพพื้นฐานนี้เป็นของอดีต และบัดนี้มันไม่มีอยู่แล้ว มันได้ฉีกทำลายตัวเองจนแหลกละเอียดอย่างสิ้นเชิงในกระบวนการเปลี่ยนแปลงการดำรงอยู่ของตัวเอง พระเจ้าตายแล้ว และความตายของพระองค์เองคือชีวิตของโลกใบนี้”
> — Philipp Mainländer
9 ความคิดเห็น
ประเภท 1 กับ 2 นี่หมดหวังไปนานแล้ว
เป็นโปรแกรมเมอร์ที่ไม่มีคุณสมบัติ
แล้วก็มีแต่คนที่แค่ทำงานไปตามสำนึกของอาชีพ
ถึงค่อยรู้สึกถึงวิกฤตกัน... ตั้งแต่แรกก็เป็นพวกที่ขี้เกียจ
จะคิดอยู่แล้ว..
แต่สำหรับคนประเภท 3 นี่เป็นของขวัญที่น่ายินดีเลย
คนประเภท 3 ก็ใช้งานมันได้ดีอยู่แล้วไม่ใช่เหรอ?
พอมีเครื่องมือใหม่ออกมาก็ตื่นเต้นแล้วใช้มันได้ดีไม่ใช่หรือ?
ตอนแรกผมลองทดสอบโค้ด win32 ดู
แต่ก็อย่างที่คิด... มันอยู่แค่ระดับ Automation Interface
เท่านั้น
ผมเลยคิดว่าด้วยของแบบนี้คงหมดหวังที่จะออกแบบซอฟต์แวร์คุณภาพดีได้แล้ว
ก็เลยคิดว่าจะหาวิธีใช้ประโยชน์จากมันให้ได้มากที่สุดอย่างไร
แต่ในระดับนี้ก็ยังมีอะไรให้ใช้อีกเยอะ
เรื่องนี้ก็เหมือนกัน ถ้าคิดและครุ่นคิดก็เหมือนได้แขนขาเพิ่มขึ้น... แต่ผมว่าปัญหาคือคนจำนวนมากไม่คิดจะทำแบบนั้นเลย
ในวันทำงาน 5 วัน ผมจะมีอยู่ 1 วันที่ทำงานโดยไม่ใช้ LLM เลยระหว่างเวลางาน และในวันอาทิตย์ก็ไม่ใช้ LLM เลยด้วย แต่ก็ทำได้สบายครับ
ก็แค่หลงคิดไปเองนั่นแหละ ในเมื่อสิ่งที่ลองทดลองได้เร็วแล้วเก็บข้อมูลไปด้วยมันได้ประโยชน์กว่า การพูดประมาณว่า “อ้า~ไม่รู้ล่ะ ฉันเป็นสายทฤษฎี~” มันต่างกันตรงไหนล่ะ 555
ที่เห็นก็มีแต่เหมือนกำลังคร่ำครวญ เพราะตอนนี้มันกลายเป็นสถานการณ์ที่พิสูจน์แล้วว่าทฤษฎีของตัวเอง ซึ่งก่อนหน้านี้ทำให้เป็นจริงไม่ได้เลยเลยพิสูจน์ไม่ได้ แท้จริงแล้วไร้ประโยชน์มาก
ถ้าเป็น thinker ตัวจริง ป่านนี้คงกำลังค้นหาว่าจะแก้ปัญหาอะไรได้ในสถานการณ์นี้ผ่าน AI และยังคงขบคิดเพื่อหาทางออกที่ดีกว่าอยู่แน่
ดูเหมือนว่าจะไม่ใช่คอมเมนต์ที่มีท่าทีให้ความเคารพนะครับ
ถ้าจะทำให้โค้ดที่ AI สร้างมาดีขึ้นกว่าเดิม เราก็เพิ่มขั้นตอน build และ thinking ควบคู่กันไปได้ไม่ใช่เหรอ?
ผมคิดถึงช่วงเวลาที่เราได้คิดกันอย่างลึกซึ้ง
ในระบบขนาดใหญ่ระดับองค์กร กระบวนการเลือกโมเดลการประมวลผลที่เหมาะสมและเลือกแนวทางแบบ pipeline นั้น AI ก็ยังแสดงให้เห็นถึงข้อจำกัดด้านความสมบูรณ์อยู่มาก เลยดูเหมือนว่าหันไปให้ความสำคัญกับงานสถาปัตยกรรมจะดีกว่า
แน่นอนว่าก็ไม่รู้เหมือนกันว่ามันจะไปได้ไกลแค่ไหน...
ไม่ก็ระบายความอยากด้วยการแก้โจทย์อัลกอริทึมยาก ๆ แล้วฝั่งธุรกิจก็เข้าหาแบบปฏิบัติจริง เท่านี้ก็คงไม่มีทางเลือกอื่นแล้ว
เหมือนกับที่แม้จะเป็นยุคที่เครื่องจักรถักทอเสื้อผ้าได้แล้ว การเขียนโค้ดในฐานะงานอดิเรกก็น่าจะยังคงเป็นไปได้เหมือนกันนะ
ในความเห็นส่วนตัวอย่างยิ่ง
รู้สึกว่าน่าจะเลือกหยิบเอาความสนุกของการเป็น builder กับ thinker มาได้
ตอนนี้เราสามารถสร้างบางสิ่งที่ใช้งานได้ด้วยต้นทุนที่ต่ำมากอย่างสมบูรณ์ (ใช้เวลาน้อย)
พร้อมทั้งยังได้เก็บเอาความสุขที่เกิดจากการที่ผู้ใช้ใช้งานสิ่งนี้ และความสุขจากการได้แก้ปัญหาในชีวิตจริงไปด้วย
ถ้านำเวลาที่ประหยัดได้ไปทุ่มให้กับปัญหาที่ต้องใช้การคิดอย่างลึกซึ้ง (ซึ่งในความเป็นจริงก็ทำอยู่แบบนั้น)
มันก็มีความหมายในแบบของมันเอง และน่าจะมีความสุขในอีกแบบด้วยเหมือนกัน
ความเห็นจาก Hacker News
โพสต์ ของ Aral Balkan เมื่อเดือนมีนาคม 2025 น่าประทับใจมาก
การเขียนโค้ดก็เหมือนการปั้นก้อนดินเหนียวให้เป็นรูปร่างที่ต้องการ ระหว่างกระบวนการนี้เราจะได้เรียนรู้ ข้อจำกัดและคุณลักษณะ ของวัสดุ
ก่อนจะลงมือสร้างคือช่วงที่เรายังไม่รู้มากที่สุดว่าอยากสร้างอะไร การออกแบบไม่ได้เป็นแค่การแก้ปัญหา แต่คือการ ค้นพบปัญหาที่ถูกต้อง
ถ้าข้ามกระบวนการสร้างไป เราก็จะสูญเสียองค์ประกอบความเป็นมนุษย์ของการเรียนรู้และการค้นพบไป ผลงานที่เราขัดเกลาด้วยตัวเองเราจะเข้าใจมันอย่างถ่องแท้ แต่ผลลัพธ์ที่ได้จากตู้กดอัตโนมัตินั้นเป็นเพียงของเลียนแบบที่แค่หน้าตาคล้ายกันเท่านั้น
ยิ่งเป็นไอเดียใหม่ เครื่องมือก็ยิ่งพยายาม “ทำให้เป็นมาตรฐาน” จึงต้องใช้แรงต้านเพื่อเอาชนะสิ่งนั้น
ในกระบวนการนี้เราจะนิยามได้ชัดขึ้นว่าอะไรคือไอเดียของเรา และอะไรไม่ใช่ พอหยุดผลักดันเมื่อไร LLM ก็จะกลบความเป็นต้นฉบับของโปรเจกต์ทันที
งานของฉันคือการประกอบเครื่องมือที่มีอยู่แล้วเพื่อสร้างสิ่งใหม่
การข้ามกระบวนการสร้างไม่ได้ทำให้คุณค่าของผลงานลดลง
ยกตัวอย่างเช่น Zelda ที่ใช้ Havok physics engine หรือเกมที่สร้างด้วย Unreal ก็ไม่ได้แปลว่าไม่ยอดเยี่ยมเสียหน่อย
ช่วง 3 สัปดาห์ที่ผ่านมา ฉันทำงานโดยใช้ Codex, Claude และรัน test session ไปพร้อมกัน และก็ภูมิใจกับผลลัพธ์ที่ได้
แต่ก่อนเป้าหมายคือทำให้ไอเดียเป็นจริง ทุกวันนี้เป้าหมายคือทำให้ลูกค้าพอใจและรักษากำหนดการกับงบประมาณ
แบบนี้จะทำให้สร้างระบบซับซ้อนที่มีองค์ประกอบนับพันชิ้นได้
ในอดีตบทบาทแบบนี้เคยถูกทำแทนโดยโครงสร้างองค์กรของบริษัท — ฝั่งบนเป็นคนออกสเปก แล้วฝั่งล่างเป็นคนสร้างชิ้นส่วน
สมัยก่อนคุณดูออกได้ทันทีว่าเว็บไหนสร้างด้วย Ruby on Rails
ถ้ามอบงานให้คนหรือ agent โดยไม่เข้าใจคุณลักษณะของสื่อนั้น ก็จะเกิดความต่างระหว่าง โค้ดที่สะอาดกับโค้ดที่บำรุงรักษาไม่ได้
สุดท้ายแล้วความรับผิดชอบอยู่ที่คนสั่งงาน ถ้าไม่มีประสบการณ์กับสื่อนั้น ก็แปลว่ายังไม่พร้อมจะประเมินผลลัพธ์
สำหรับฉันมันแค่ พิมพ์น้อยลงเท่านั้น แต่ยังคิดแบบเดิมอยู่
เครื่องมือดีขึ้นก็จริง แต่การเขียนโปรแกรมก็ยังเป็นการเขียนโปรแกรม
จะขี่อูฐข้ามทะเลทรายหรือขึ้นเฮลิคอปเตอร์ไป สุดท้ายการเดินทางก็คือการเดินทาง
แค่เครื่องมือพัฒนาไป ไม่ได้แปลว่าแก่นแท้เปลี่ยน
เหมือนลืมไปว่าประสบการณ์ที่ต่างกันสามารถอยู่ร่วมกันได้
คอมเมนต์ที่ว่า “ไม่อยากคิด” นี่สะดุดตามากเป็นพิเศษ
การก้าวไปสู่ชั้นนามธรรมถัดไปเป็นเรื่องดี แต่ก็ควรยอมรับด้วยว่ามีคุณค่าบางอย่างที่สูญหายไประหว่างทาง
LLM เป็นเพียงวิวัฒนาการของเครื่องมือก็จริง แต่การหายไปของ กระบวนการคิดอย่างละเอียดลออ ก็น่าเสียดาย
มันใกล้เคียงกับการ สั่งงานคนอื่นแล้วคอยตรวจงาน มากกว่า
คนที่ไม่ชอบการเขียนโปรแกรมคงยินดีต้อนรับสิ่งนี้ แต่จะเรียกมันว่า ‘การเขียนโปรแกรม’ คงไม่ได้
ถ้าเขียนโค้ดเอง เราจะมองเห็นโครงสร้างข้อมูลในหัว แต่พอให้ agent ทำแทน ความรู้สึกนั้นก็หายไป
การ commit โค้ดโดยไม่เข้าใจมันไม่มีคุณค่าสำหรับฉัน
การมองว่าการเขียนโค้ดด้วย LLM เหมือน abstraction แบบเดิมๆ เป็นการเปรียบเทียบที่ผิด
compiler หรือ framework ตั้งเป้าจะเป็น abstraction ที่ไม่รั่ว แต่ LLM นั้นมีการรั่วไหลโดยเนื้อแท้
สุดท้ายคนก็ยังต้องเป็นฝ่ายหาบั๊กและแก้มันอยู่ดี
LLM เหมือนนำ ความไม่แน่นอนและความเสี่ยง ที่เราพยายามหลีกเลี่ยงกลับเข้ามาอีกครั้ง
ถ้าไม่ได้ระบุตัวแปรทั้งหมดไว้ใน prompt ผลลัพธ์ที่ได้ก็จะออกมากลางๆ
จึงมีคำถามว่าภาษาธรรมชาติเหมาะกับการบรรจุข้อมูลลักษณะนี้จริงหรือไม่
นี่ไม่ใช่ abstraction แต่เป็นการสร้างโค้ดแบบไม่กำหนดแน่นอน
ในแง่นี้ LLM จึงส่งผลต่อวิธีคิดของมนุษย์ต่างออกไปด้วย
ฉันเป็นพวก ‘นักคิด (thinker)’ เลยไม่ค่อยสนใจ AI coding มากนัก
การได้สร้าง OS kernel หรือ graphics engine เองคือความสนุก
มากกว่าผลลัพธ์ ฉันให้ค่ากับ กระบวนการแก้ปัญหา ในฐานะงานอดิเรกและความภาคภูมิใจ
ส่วนพวก ‘builder’ กลับตื่นเต้นกับ AI เพราะทำให้สร้างของได้เร็วขึ้น
วิศวกรทุกคนล้วนเป็นนักคิด เพียงแต่จุดประสงค์ของการใช้เครื่องมือต่างกันเท่านั้น
ในมุมของคนที่เขียนโค้ดมาหลายสิบปี เครื่องมือ AI มอบ อิสระ ให้
มันช่วยให้ทดลองไอเดียที่เมื่อก่อนแทบไม่มีโอกาสได้ลองได้อย่างรวดเร็ว
จึงทำให้สามารถใช้ เศษเวลาสั้นๆ มาทำโปรเจกต์ส่วนตัวได้
AI ทำให้เราโฟกัสกับการคิดจริงๆ ได้มากขึ้น
ตอนนี้รู้สึกว่า singularity กำลังใกล้เข้ามาแล้ว
ถ้าล้มเหลวก็ยังได้เรียนรู้ ถ้าสำเร็จก็ไปโฟกัสกับการตรวจสอบคุณภาพต่อได้
“การคิด” เองก็มีหลายรูปแบบ
มีทั้งการคิดแบบจดจ่อเข้มข้น และการคิดที่ค่อยๆ หมักบ่มอยู่เบื้องหลัง
ทั้งสองแบบล้วนเป็นรูปแบบหนึ่งของการจมดิ่งอย่างลึกซึ้ง และเป็นสิ่งที่สูญหายได้ง่ายในยุค AI
ไม่ว่าจะเป็นการแก้ปัญหาคณิตศาสตร์ การคิดเชิงปรัชญา หรือข้อจำกัดซับซ้อนในการทำงานจริง ต่างก็สร้าง ความตึงเครียดทางปัญญา คนละแบบ
สุดท้ายสิ่งสำคัญคือไม่ว่าจะเป็นรูปแบบไหน ก็ต้องเป็นประสบการณ์ของ การจดจ่ออย่างลึกซึ้ง
พอมองไปรอบตัวในกลุ่มวิศวกรอาวุโส ฉันเห็นอยู่สองแบบ
บางคนได้ productivity เพิ่มขึ้นเล็กน้อย แต่บางคนก็สูญเสีย ความลึกของการคิด ไป
หลายครั้งพวกเขาแค่คัดลอกคำตอบที่ LLM ให้มาแล้ววางลงไปตรงๆ
ปัญหาที่แท้จริงคือการขาด ความสามารถในการตั้งคำถามให้ถูกต้อง
ยิ่งระบบมีความเป็นผู้ใหญ่มากเท่าไร สัดส่วนนี้ยิ่งกินเกิน 90%
น่าเสียดายที่วิศวกรร่วมงานหลายคนคลั่ง AI จนเหมือน ขายแก่นแท้ของอาชีพตัวเองทิ้งไป
เราเคยถือครองปัจจัยการผลิตไว้ แต่กลับยอมปล่อยมือเอง
ถ้า AI ทำให้การพัฒนาถูกลงและเร็วขึ้น ตลาดก็อาจยิ่งขยายใหญ่ขึ้นด้วยซ้ำ
ความก้าวหน้าทางเทคโนโลยีทำให้บางอาชีพเสียเปรียบเสมอ แต่ก็พา ความก้าวหน้าของสังคมโดยรวม มาด้วย
เมื่อก่อนพวกเราเองก็ลดงานของอุตสาหกรรมอื่นผ่านระบบอัตโนมัติ ตอนนี้ก็แค่ถึงตาของเราเท่านั้น
ผลลัพธ์จึงเหลือเพียงความว่างเปล่า แต่บางทีสำหรับพวกเขา นั่นอาจเป็นเป้าหมายอยู่แล้วก็ได้
วิธีคิดแบบ “ทำได้ก็เลยทำ” ทำให้ความเป็นมนุษย์ค่อยๆ เลือนหายไป
AI ไม่ได้ทำให้การคิดหายไป ปัญหาคือ บริษัทธรรมดาๆ และวิธีคิดแบบธรรมดาๆ
เราควรไปหาบริษัทที่ให้คุณค่ากับการคิดอย่างแท้จริง
ฉันก็เขียนโค้ดด้วย LLM เหมือนกัน แต่ก็ยัง คิดลึก อยู่
ฉันยังคิดเรื่องสถาปัตยกรรม ความเสี่ยง ข้อจำกัด technical debt และทางเลือกต่างๆ
มันใกล้กับการคิดแบบผู้จัดการที่ต้องคอยบริหารหลายบริบทไปพร้อมกัน
ไม่เหมือนการคิดแบบนักวิทยาศาสตร์ที่หมกอยู่กับปัญหาเดียวหลายวัน
โดยเฉพาะ PR ของ junior ที่ใช้ AI นั้นยาวและซับซ้อนกว่าเดิม และตอนนี้งานส่วนใหญ่ของฉันก็กลายเป็น งานรีวิว ไปแล้ว
มันมีประโยชน์กับการทำ prototype เร็วๆ, helper function, code autocomplete และการสำรวจไลบรารี
กลับกัน ยิ่งงานจิปาถะลดลง ก็ยิ่งได้คิดมากขึ้น
เมื่อก่อนการเขียนโค้ดทำให้เราย้อนกลับไปทบทวนการคิดเชิงออกแบบระดับบนได้ แต่ตอนนี้กระบวนการนั้นลดลง จึงทำให้คิดได้ ‘ไม่ลึกเท่าเดิม’