ChatGPT, GitHub Copilot, Cursor และเครื่องมืออื่นๆ ในกลุ่มเดียวกัน ตอนนี้สามารถสร้าง React component ออกมาให้คุณได้ก่อนที่คุณจะพิมพ์ prompt เสร็จเสียด้วยซ้ำ จะเชื่อมต่อ Next.js route เข้ากับ Supabase งั้นหรือ? เสร็จได้ในไม่กี่วินาที จะรีแฟกเตอร์ (Refactor) TypeScript utility ที่พันกันยุ่งเหยิง? นี่คือสามทางเลือก พร้อมด้วย type guards แบบครบถ้วน สำหรับใครก็ตามที่ทำงานกับ modern web stack ประสบการณ์นี้อาจให้ความรู้สึกที่แทบจะเหมือนเวทมนตร์
ผมใช้เครื่องมือเหล่านี้ทุกวัน Stack ของผมคือ Next.js, TypeScript และ Supabase โดยมี AI นั่งอยู่ตรงนั้นใน editor ของผม พร้อมที่จะสร้างโครงสร้าง custom hooks, สร้าง database queries หรือจัดระเบียบ logic เงื่อนไขที่ยุ่งเหยิง ในแง่ของการทำงานเล็กๆ น้อยๆ มันทำหน้าที่ได้เหมือน junior developer ที่ทำงานเร็วมาก มันแม่นยำเรื่อง syntax อย่างยิ่ง มันจำขอบเขตของ API ที่ผมต้องคอย Google ได้ และมันไม่เคยเหนื่อยกับการเขียนโค้ดที่เป็น boilerplate
แต่ซอฟต์แวร์ก็ยังคงพังอยู่ดี แอปพลิเคชันเริ่มรู้สึกช้าลง แดชบอร์ดของลูกค้าเริ่มหน่วง เคสแปลกๆ (edge cases) ทำให้ฟอร์มพัง ถ้า AI ทำให้การเขียนโค้ดง่ายขึ้นขนาดนี้ ทำไมการใช้งานซอฟต์แวร์ถึงให้ความรู้สึกแย่กว่าเมื่อไม่กี่ปีที่ผ่านมา?
คำตอบคือ การสร้าง syntax กับการสร้างซอฟต์แวร์นั้นไม่ใช่เรื่องเดียวกัน
Syntax ไม่ใช่สถาปัตยกรรม
AI จัดการกับ token ได้ดีอย่างน่าทึ่ง ลองสั่งให้มันเขียน useEffect hook ที่คอยฟัง Supabase real-time channel ดู แล้วคุณจะได้โค้ดที่คอมไพล์ผ่าน มันสามารถแปลงไฟล์ JavaScript ที่ไม่มี type ให้เป็น TypeScript แบบเข้มงวด หรือสร้างฟอร์ม component พร้อม Zod validation ให้คุณได้ก่อนที่คุณจะดื่มกาแฟเสร็จเสียอีก
แต่สิ่งที่มันทำไม่ได้คือการเข้าใจบริบทเฉพาะของแอปพลิเคชันคุณ ซอฟต์แวร์ที่ดีต้องการการจัดการ state อย่างมีชั้นเชิง การจัดการ race conditions อย่างระมัดระวัง และแผนผังที่ชัดเจนว่าข้อมูลถูกเก็บไว้ที่ไหนและที่ไหนที่เป็นเพียงการนำมาแสดงผล AI มองเห็นแค่ไฟล์ที่อยู่ตรงหน้า แต่มันไม่ได้มองเห็นทั้งระบบ มันปฏิบัติกับ codebase ของคุณเหมือนเป็นทางเดินข้อความแบนๆ แทนที่จะเป็นโครงสร้างที่มีชีวิตและมีผนังรับน้ำหนัก
ลองนึกถึงสถาปนิกที่ไม่เคยอาศัยอยู่ในบ้านจริงๆ พวกเขาสามารถวาดแปลนบ้านที่สวยงามได้ พวกเขารู้ว่าห้องนอนควรมีหน้าต่างกี่บาน แต่พวกเขาไม่รู้ว่าท่อน้ำมักจะรั่วตรงไหนในเดือนกุมภาพันธ์ หรือโถงทางเดินไหนจะใช้งานไม่ได้ในช่วงอากาศร้อนของฤดูร้อน ความรู้จากการใช้งานจริงต่างหากที่ทำให้สิ่งปลูกสร้างยังคงตั้งอยู่ได้ โค้ดก็ทำงานในลักษณะเดียวกัน
จุดติดขัดสองประการ
เมื่อผมปล่อยให้ AI เขียนโค้ดชุดใหญ่โดยไม่มีกฎเกณฑ์ (guardrails) ที่เข้มงวด ผมสังเกตเห็นปัญหาเดิมๆ สองอย่างที่เกิดขึ้นซ้ำแล้วซ้ำเล่า
อย่างแรก มันเพิกเฉยต่อ design patterns ที่คุณได้วางรากฐานไว้แล้ว บางทีทีมของคุณอาจจะแยกการดึงข้อมูลทั้งหมดไปไว้ในเลเยอร์เฉพาะของ custom hooks หรือคุณอาจจะมีข้อกำหนดที่เข้มงวดว่านโยบาย Supabase RLS จะต้องแมปกับ frontend helpers อย่างไร แต่ AI ไม่สนใจ มันจะโยน supabase.from().select() แบบดิบๆ ลงไปใน onClick ของปุ่มทันทีถ้ามันช่วยตอบโจทย์ prompt นั้นได้ โค้ดทำงานได้ และดูสะอาดตาด้วย แต่มันคือสิ่งที่แปลกแยกออกมาจาก codebase ของคุณ และทุกสิ่งที่แปลกแยกคือ "ภาษีในการรีแฟกเตอร์" ในอนาคต อีกหกเดือนข้างหน้า ใครบางคนจะต้องมาตามหาเข็มเล่มนั้น ทำความเข้าใจว่ามันมาอยู่ตรงนี้ได้อย่างไร และค่อยๆ ดึงมันกลับเข้าที่เข้าทางอย่างระมัดระวัง
อย่างที่สอง มันเลือกใช้ความซับซ้อนเกินความจำเป็นในขณะที่ความเรียบง่ายก็น่าจะเพียงพอแล้ว เครื่องมือนี้ถูกฝึกฝนมาด้วย repository ที่ใหญ่พอที่จะต้องใช้ abstract factories, reducer patterns ที่ซับซ้อน และ higher-order components หลายชั้น เมื่อคุณสั่งให้มันสร้างฟอร์มติดต่อแบบง่ายๆ มันอาจจะส่ง state machine, context provider และการทำ abstraction ของ custom hook ที่กินพื้นที่ถึงสามไฟล์มาให้คุณ คำตอบนั้นไม่ได้ผิดในทางเทคนิค แต่มัน "หนัก" เกินไป แต่ละเลเยอร์ที่ไม่จำเป็นจะเพิ่ม "หนี้ทางความคิด" (cognitive debt) คุณไม่ได้ข้ามขั้นตอนการทำงาน แต่คุณแค่เลื่อนมันออกไปพร้อมกับดอกเบี้ย
กับดักแห่งความเร็ว
มันมีวงจรป้อนกลับที่อันตรายเกิดขึ้นที่นี่ AI ช่วยให้คุณสร้างฟีเจอร์ได้เร็วขึ้นสองเท่า แต่ความใส่ใจของมนุษย์ไม่ได้เพิ่มขึ้นในอัตราเดียวกัน หากคุณส่งมอบงานได้เร็วขึ้นครึ่งหนึ่ง คุณต้องใช้เวลาในการทำ code review นานขึ้นเป็นสองเท่าหรือเปล่า? คุณเขียนเทสต์มากขึ้น หรือน้อยลง?
ในทางปฏิบัติ มันง่ายมากที่จะเชื่อใจโค้ดที่ถูกสร้างขึ้นเพราะมันดูน่าเชื่อถือ มันใช้ syntax ที่ทันสมัย มีคอมเมนต์แทรกอยู่ในจุดที่เหมาะสม ชื่อตัวแปรฟังดูเป็นมืออาชีพ แต่บั๊กเล็กๆ น้อยๆ มักซ่อนอยู่ภายใต้ความเนี้ยบนั้น เช่น dependency array ใน hook ที่ลืมใส่ setter, TypeScript type ที่ถูกต้องตามหลักการแต่ยอมให้เกิด null state ที่คุณลืมจัดการ หรือ query ของ Supabase ที่ลืมคำนึงถึงแถวที่ถูก soft-delete ใน schema เฉพาะของคุณ คุณเลือกที่จะอ่านผ่านๆ แทนที่จะอ่านทุกบรรทัด เพราะความเร็วในการส่งมอบงานมันบีบบังคับ ความเร็วอาจจะให้ความรู้สึกดีในวันจันทร์ แต่เซสชันการดีบั๊กในวันศุกร์อาจลากยาวไปจนถึงเที่ยงคืน
ต้นทุนที่แท้จริง
คนที่ต้องจ่ายราคาให้กับเรื่องนี้ไม่ใช่เหล่านักพัฒนา แต่คือผู้ใช้งานจริง
Software feels clunkier because complexity is growing faster than teams can steward it. We are building bigger applications with smaller crews, armed with tools that make us feel invincible. When one developer can scaffold an entire dashboard in an afternoon, the organization expects three dashboards by Wednesday. Scale without care produces fragile systems. State balloons. Bundle sizes creep up. Race conditions multiply. The interface might look modern, but it resets itself when a user hits the back button, or it takes four seconds to hydrate because nobody had time to profile the waterfall of AI-generated data fetches.
Work With the Machine, Not For It
None of this means you should throw AI out of your editor. It means you need boundaries.
Use it for what it is good at. Let it write the dull stuff: repetitive TypeScript interfaces, boilerplate Supabase queries, Jest setup