Cognitive Debt

แปลจาก Prevent cognitive debt by manually retyping LLM-generated code โดย Ankur Sethi

ปัญหาที่คนใช้ AI เขียนโค้ดทุกคนกำลังเจอ

สมมติว่าเรามี Coding Assistant (( โปรแกรม AI ที่ช่วยเขียนโค้ด เช่น Copilot หรือ Claude Code )) สักตัว แล้วปล่อยให้มันจัดการทุกอย่างในโปรเจกต์ ตั้งแต่ต้นจนจบ ฟังดูเหมือนฝันเลยใช่ไหม?

Ankur Sethi เล่าว่าเขาเคยคิดแบบนั้น แต่ทุกครั้งที่ปล่อยให้ AI เขียนฟีเจอร์ทั้งหมดให้เสร็จในครั้งเดียว เขากลับรู้สึก “ไม่พอใจและสับสน” วิธีที่เขาพบว่าใช้ได้ผลจริงคือการให้ AI เร่งงานส่วนที่น่าเบื่อ — งานที่เราไม่อยากนั่งทำเอง แต่ก็ยังอยากเข้าใจว่ามันทำงานอย่างไร

Just because a problem is boring doesn’t mean I want to fully offload my understanding of the solution to a machine.

ประโยคนี้คือใจความสำคัญของบทความทั้งหมด — การที่งานน่าเบื่อ ไม่ได้หมายความว่าเราอยากยกความเข้าใจ ในวิธีแก้ปัญหานั้นให้เครื่องจักรไปทั้งหมด

แล้วการรีวิวโค้ดที่ AI เขียนล่ะ ใช้ได้ไหม?

หลายคนอาจคิดว่า “ไม่เป็นไร แค่รีวิวทุกบรรทัดที่ AI เขียนก็จบ” — นี่คือสิ่งที่ developer (( นักพัฒนาซอฟต์แวร์ )) ส่วนใหญ่ในปี 2026 ถูกคาดหวังให้ทำ

แต่ Ankur บอกว่าการรีวิว PR (( Pull Request - คำขอรวมโค้ดที่ AI สร้างเข้าไปในโปรเจกต์ )) ที่ AI สร้างขึ้นไม่ใช่เรื่องสนุกนัก:

โค้ดที่ overly-defensive (( ป้องกันเกินเหตุ - เขียนโค้ดเผื่อกรณีที่ไม่น่าเกิดขึ้น ))
มี Comment (( ข้อความอธิบายที่เขียนแทรกไว้ในโค้ด )) เยอะ แต่ไม่ได้ช่วยให้เข้าใจโค้ดมากขึ้น
โค้ดที่ดูเหมือนถูกต้อง แต่จริง ๆ แล้ว subtly incorrect (( ผิดแบบเนียน ๆ - มองผ่าน ๆ แล้วจับความผิดพลาดไม่เจอ )) จนต้องตั้งใจอ่านทุกบรรทัดจริง ๆ

เขามองว่าโปรเจกต์ส่วนตัว ควรสนุกก่อนเสมอ — ความสุขของการทำงานอยู่ที่ process (( กระบวนการ - ระหว่างทางที่ลงมือทำ )) ไม่ใช่แค่ผลลัพธ์สุดท้าย ดังนั้นการนั่งไล่รีวิวโค้ดแย่ ๆ หลายร้อยบรรทัดจึงไม่ใช่คำตอบ

วิธีแก้ที่ฟังดูตลก: ให้ AI เขียนใน chat แล้วพิมพ์เองทั้งหมด

Ankur จึงคิดวิธีที่เขายอมรับเองว่า “ไม่ efficient (( ไม่มีประสิทธิภาพ )) เอาเสียเลย และอาจดูตลกนิดหน่อย” — ให้ AI generate โค้ดใน chat แล้วพิมพ์โค้ดนั้นลง editor เองทุกบรรทัด

เขาใส่คำสั่งเหล่านี้ไว้ใน agents file (( ไฟล์คำสั่งที่ใช้กำหนดพฤติกรรมของ AI ในโปรเจกต์ )) ของทุกโปรเจกต์ส่วนตัว:

ฉันต้องการเข้าใจทุกบรรทัดของโค้ดที่จะเข้าไปอยู่ในโปรเจกต์นี้ ห้าม สร้าง แก้ไข ย้าย เปลี่ยนชื่อ หรือลบไฟล์ในโปรเจกต์ เว้นแต่ฉันจะขอโดยตรง — ให้แสดงการแก้ไขทั้งหมดใน chat เพื่อให้ฉันพิมพ์เอง

ห้าม รันคำสั่งที่แก้ไขไฟล์ ติดตั้ง dependency (( แพ็กเกจที่โค้ดต้องใช้ )) หรือเปลี่ยนสถานะ repository (( คลังเก็บโค้ดของโปรเจกต์ )) เว้นแต่ฉันจะขอโดยตรง — ให้แสดงคำสั่งใน chat เพื่อให้ฉันเป็นคนรันเอง

ฉันเป็น developer ที่มีประสบการณ์ — ไม่ต้องอธิบาย syntax (( รูปแบบการเขียนโค้ด )), API (( ช่องทางที่โปรแกรมใช้สื่อสารกัน )), แนวคิด หรือรายละเอียดการ implement (( การลงมือทำให้แนวคิดนั้นเกิดขึ้นจริง )) เว้นแต่ฉันจะถาม

ช้าลง แต่ได้ความเข้าใจที่ลึกกว่าเดิม

ผลลัพธ์คือทำงานได้เร็วขึ้นประมาณ 2 เท่า แทนที่จะเร็วขึ้น 10 เท่า — แต่ความเร็วที่เสียไปแลกกลับมาด้วย ความเข้าใจโค้ดที่ลึกขึ้น ซึ่งคุ้มค่ากว่ามาก

ตอนที่พิมพ์โค้ดทุกบรรทัดด้วยมือ เราจะค่อย ๆ สร้าง mental model (( แบบจำลองในหัว - ภาพความเข้าใจว่าโค้ดทำงานอย่างไรและเชื่อมกับส่วนอื่นอย่างไร )) ขึ้นมาโดยอัตโนมัติ — ถ้าเจอ API หรือ algorithm (( ขั้นตอนวิธีแก้ปัญหา )) ที่ไม่เข้าใจ ก็หยุดเพื่อค้นคว้าหรือถาม AI ได้ทันที

การพิมพ์เองยังทำให้เรา ช้าลง ซึ่งเป็นเรื่องดี เพราะ:

มีโอกาสจับ hallucination (( การแต่งข้อมูลขึ้นมาเอง - โค้ดที่ AI สร้างขึ้นฟังดูถูกต้อง แต่จริง ๆ แล้วผิด )) และ design ที่แย่ได้มากขึ้นเมื่อเทียบกับการอ่านผ่าน ๆ
จัดระเบียบโค้ดระหว่างทางได้ ทั้ง refactor (( ปรับโครงสร้างโค้ดโดยไม่เปลี่ยนพฤติกรรม )) เพิ่ม comment และปรับโค้ดให้เข้ากับสไตล์ของตัวเอง

ข้อดีที่คาดไม่ถึง: ได้แผนที่ของ codebase

ประโยชน์ที่สำคัญที่สุดของวิธีนี้คือการได้ spatial map ของ codebase (( แผนที่เชิงตำแหน่ง - ความรู้ว่าโค้ดแต่ละส่วนอยู่ตรงไหนของโปรเจกต์ )) — เราจะรู้ว่าฟังก์ชันแต่ละตัวอยู่ที่ไหน และควรแก้ตรงไหนเมื่อต้องเปลี่ยนแปลงอะไรสักอย่าง

มันช่วยเราได้สองทาง:

ทำงานในโปรเจกต์ได้เร็วขึ้น — ไม่ต้องเสียเวลาไล่หาไฟล์ที่ต้องแก้
เขียน Prompt (( คำสั่งที่ใช้บอก AI ว่าต้องการให้ทำอะไร )) ได้ดีขึ้น — เพราะเรารู้จัก codebase ของตัวเองดีพอที่จะสั่ง AI ให้แก้ถูกจุดตั้งแต่แรก

It not only helps me work faster within my projects, it also makes it easier for me to better prompt and instruct the LLM in the future.

เหมือนคำสอนสมัยเรียนโค้ดเป๊ะ ๆ

Ankur เล่าว่า ตอนที่เขายังเป็นวัยรุ่นและกำลังเรียนเขียนโค้ด คนเก่ง ๆ มักสอนกันเสมอว่า “อย่า copy-paste โค้ดเข้าไปในโปรเจกต์ของตัวเอง” — ถ้าเรียนจากหนังสือ ก็ให้พิมพ์ตัวอย่างทั้งหมดลงเครื่องแล้วลองรันให้ได้ ถ้าเรียนจาก blog (( บทความบนเว็บไซต์ )) ก็ให้พิมพ์ตาม แล้วปรับให้เข้ากับ codebase ของเรา

การพิมพ์โค้ดที่ AI เขียนให้ใหม่ทุกบรรทัดด้วยตัวเอง ก็คือ กระบวนการเรียนรู้แบบเดียวกันเป๊ะ

มันอาจไม่ใช่วิธีทำงานกับ AI ที่ efficient (( มีประสิทธิภาพ - ได้ผลลัพธ์มากโดยใช้ทรัพยากรน้อย )) ที่สุด แต่เขาบอกว่า “ผมให้ค่ากับความเข้าใจมากกว่าความเร็ว” — เขาทำแบบนี้มาหลายเดือนแล้ว และผลลัพธ์ก็ออกมาดีพอที่จะทำต่อไปเรื่อย ๆ

สุดท้าย: Cognitive Debt ของวงการทั้งหมด

Ankur ปิดท้ายด้วยความกังวลต่ออุตสาหกรรมโดยรวม — เขาเชื่อว่าวงการซอฟต์แวร์กำลังสะสม cognitive debt (( หนี้ทางปัญญา - การพึ่งเทคโนโลยีโดยไม่เข้าใจมัน และต้องจ่ายคืนภายหลังด้วยต้นทุนของความไม่รู้ )) ก้อนใหญ่ขึ้นเรื่อย ๆ และสักวันหนึ่งเราจะต้องจ่ายคืนพร้อมดอกเบี้ย

วันหนึ่งเราอาจไปถึงจุดที่ ไม่มีใครเข้าใจ ว่าโครงสร้างพื้นฐานดิจิทัลส่วนใหญ่ของโลกทำงานอย่างไร หรือประกอบขึ้นจากอะไรบ้าง

เขาอาจเปลี่ยนทิศทางของอุตสาหกรรมทั้งหมดไม่ได้ แต่เขาทำได้อย่างน้อยหนึ่งอย่าง — ทำให้แน่ใจว่า ตัวเองเข้าใจซอฟต์แวร์ทุกชิ้นที่ปล่อยออกไปสู่โลก

Anything else would be professional malpractice.

หรือพูดง่าย ๆ คือ ถ้าไม่เข้าใจซอฟต์แวร์ที่ตัวเองปล่อยออกไป ก็ถือว่าเป็นการละเลยหน้าที่ในฐานะมืออาชีพ

บทสรุป: ใช้ AI ได้ แต่อย่ายกความเข้าใจให้มันทั้งหมด

บทความนี้ให้ข้อคิดที่ดีมากสำหรับคนที่ใช้ AI ช่วยเขียนโค้ดเป็นประจำ — ประเด็นสำคัญไม่ใช่ “ใช้ AI หรือไม่ใช้” แต่คือ เรายังเข้าใจสิ่งที่เราสร้างอยู่หรือเปล่า

แน่นอนว่าในงานบริษัทที่ต้องส่งงานไว ๆ คงไม่มีใครพิมพ์โค้ดทีละบรรทัดแบบนี้ทั้งโปรเจกต์ — แต่เรานำเทคนิคนี้มาประยุกต์ใช้กับ โค้ดส่วนสำคัญ ได้ เช่น payment (( ระบบชำระเงิน )), security (( การรักษาความปลอดภัย )) หรือ business logic (( กฎและเงื่อนไขหลักของระบบ )) ซึ่งเป็นส่วนที่เราต้องรับผิดชอบความถูกต้องด้วยตัวเองจริง ๆ

ลองดูครับ ครั้งหน้าให้ AI เขียนโค้ดใน chat จนจบ แล้วลองพิมพ์เองสักครั้ง — ช้าลงหน่อย แต่รับรองว่าได้อะไรกลับมาเยอะกว่าที่คิด ^__^