ลูกค้าตั้งรหัสผ่านเองมาเดือนนึง — แต่ใช้ไม่ได้ AI ผมเลือก 'ลบฟิลด์ทิ้ง' แทนที่จะแก้

เคสนี้เป็น bug ที่อยู่บนหน้า signup ของ Newton มาตั้งแต่วัน launch — ลูกค้าตั้งรหัสผ่านที่อยากใช้บนหน้าฟอร์ม กดสมัคร แล้วระบบเอารหัสนั้น ทิ้งเงียบๆ สร้าง random password ใหม่ขึ้นมาแทน ส่งให้ลูกค้าทางอีเมล รหัสที่ลูกค้าตั้งเองไม่เคยมีผลในระบบเลยซักรอบ ที่น่าสนใจคือพอ AI Agent ของผมเจอ มันไม่ได้เลือก fix ให้รหัสลูกค้ารอด — มันเสนอให้ ลบฟิลด์นั้นทิ้งไปเลย ครับ

เคส: ลูกค้าตั้งรหัสไป แต่รหัสที่ส่งกลับมาคนละตัว

ผมไปดูหน้า signup ของ Newton กับ AI Agent (ทิม) ตอนหลังจากแก้ บั๊ก Node CLI ที่ทำให้ provision พัง 1 ใน 30 ลูกค้า เพราะอยากให้มันช่วยเช็คทั้ง flow ตั้งแต่ต้นน้ำว่ามีอะไรอีกรึเปล่า

มันไล่ดู code ที่ handle /api/trial/start เปรียบเทียบ field ที่ฟอร์มส่งกับ field ที่ database เก็บ แล้วก็พบว่า:

• ฟอร์มมี input ชื่อ password ให้ลูกค้ากรอก
• API รับค่าจริง — เก็บไว้ใน memory ตอน request
• แต่ตอนสร้าง record ใน database ระบบไม่ได้แตะ password_hash
• รออีกประมาณ 2 นาที ระบบ auto-provision เริ่มสร้าง server ลูกค้า — ตอนนั้นเองที่ secrets.token_urlsafe(16) generate password ใหม่ แล้วเขียนทับ password_hash
• welcome email ส่ง random password ใหม่ให้ลูกค้า

แปลว่ารหัสที่ลูกค้าตั้งเองไป ไม่เคยมีผลในระบบเลยตั้งแต่วัน launch ทุกคนใช้ random password ที่ระบบ generate ในอีเมลเหมือนกันหมด

ฟิลด์มีอยู่ — แต่เป็น decorative input ที่ไม่ได้ทำอะไร

ทำไมเพิ่งเจอ

คำถามตรงๆ คือ — ผมไม่เคยเจอเอง เพราะลูกค้าใหม่ทุกคนได้รหัสเข้าระบบจาก welcome email ก่อนเสมอ ใช้รหัสนั้น login ก็เข้าได้ปกติ ลูกค้าก็ไม่รู้ว่าตัวเองตั้งรหัสในฟอร์มไปอะไร เพราะ welcome email มาแทน

ลูกค้าที่ "ขยันจำ" รหัสในฟอร์มแล้วเอารหัสนั้นมา login ทีหลังจะเจอว่ารหัสไม่ตรง — แต่ผมไม่เคยได้ ticket แบบนั้นเลย เพราะคนส่วนใหญ่กลับไปเปิด welcome email อ่านอีกรอบ คิดว่าเป็นรหัสที่ระบบสุ่มให้แทนที่ตัวเองตั้ง

bug แบบนี้ก็เลยซ่อนอยู่นานเป็นเดือน ไม่มีใครรู้ ไม่มีใคร support ticket

ตัวเลือกที่ AI วางบนโต๊ะ — A กับ B

ตอน AI ของผมเจอ มันไม่ได้รีบ patch ทันที มันถามผมก่อนว่าจะให้แก้แนวไหน โดยวาง 2 ตัวเลือก:

ตัวเลือก A — ลบฟิลด์ password ออกจากฟอร์มทิ้งเลย ใช้ random password + welcome email อย่างเดียว เหมือนเดิมทุกอย่าง แค่ไม่หลอกให้ลูกค้ากรอก

ตัวเลือก B — Fix ให้ end-to-end เคารพรหัสที่ลูกค้าตั้ง ส่งจาก signup → backend → provision job → server เอามาใช้จริง

ผมนั่งคิด 10 วินาที — เลือก A ครับ

ทำไมไม่เลือก fix ให้ทำงาน

ตัวเลือก B ดูเหมือน "ถูกต้อง" กว่า — เคารพ user input เหมือน Stripe / Google / ทุก signup ที่เคยเจอ แต่พอนั่งคิดดี ๆ มันมีต้นทุนซ่อน 4 อย่าง:

1. มี plaintext password ค้างใน database ระยะหนึ่ง — เพราะ provision เป็น async job ที่รัน 2 นาทีหลัง signup ระหว่างนั้นต้องเก็บ plaintext หรือ hash ไว้ที่ใดที่นึงเพื่อให้ provision job หยิบไปใช้ ไม่ใช่ของที่อยากให้มี
2. เพิ่ม path ที่ต้อง test มากขึ้น — กรณี user ตั้งรหัสที่ลื่น Bash / Node CLI (เคสเดียวกับ bug ขีด dash ที่เพิ่งแก้ไป) จะกลับมาเป็นเรื่องอีก ระบบ random password ที่ผม control 100% ไม่มีปัญหานี้ — user input มี
3. ฟอร์มยาวขึ้น = conversion ตก — Newton เป็น managed server ที่ใส่บัตรเครดิตก่อน trial 7 วัน ทุก field ที่กรอกก่อน checkout มีต้นทุน drop-off ฟิลด์ที่เคารพ user input แต่ข้อมูลไม่ได้ถูกใช้ = ฟิลด์ที่ทำให้ลูกค้าหายไปฟรี ๆ
4. Recovery เคยมีอยู่แล้ว — Newton มีปุ่ม "ลืมรหัสผ่าน" ลูกค้าที่อยากตั้งรหัสที่ตัวเองชอบทำได้ทันทีหลังจาก login ครั้งแรกด้วยรหัสจาก welcome email ไม่ต้องเพิ่มอะไรในระบบ

พอเทียบกัน ตัวเลือก A คือ "ลบ feature ที่ดูเหมือนทำงาน แต่ไม่เคยทำงาน + ไม่มีใครเรียกร้อง" ส่วนตัวเลือก B คือ "ทำให้มันทำงานจริง โดยรับ surface area เพิ่มทั้งหมดที่มาด้วย"

เลือก A ตรงไปตรงมาครับ

5 บรรทัดที่ AI ลบ + 2 step copy ใหม่

การ implement จริงเล็กกว่าที่คิด:

• ลบ <input type="password"> ออกจาก signup.html ทั้ง TH และ EN
• ลบ validation password ใน JS
• ลบ req.json.password ใน /api/trial/start
• customer INSERT/UPDATE ไม่แตะ password_hash เลย — provision เป็นคนเขียนตามเดิม

แล้ว AI แก้ copy ขั้นตอนการสมัครให้ตรงความจริง:

• Step 1 เดิม "ชื่อ + อีเมล + รหัสผ่าน" → ใหม่ "ชื่อ + อีเมล"
• Step 3 เพิ่มประโยค "เราจะอีเมลแจ้งพร้อมรหัสผ่านเมื่อ server พร้อม"

ลูกค้าใหม่ที่เปิดฟอร์มจะเห็นชัดตั้งแต่ต้นว่าจะได้รหัสผ่านทางอีเมลหลังจากนั้น ไม่ต้องเดา ไม่ต้องตั้งเอง ไม่ต้องคิดมาก

บทเรียนชั้นที่ 1 — AI ที่ดี ไม่ใช่ AI ที่ patch ให้ของพัง

ตอนผมเริ่มใช้ AI Agent ใหม่ ๆ ผมเคยเข้าใจว่า "AI ที่เก่ง" คือ AI ที่ ปะให้ของพังไม่พัง — ส่ง bug ให้ มันเอาไป fix แล้วกลับมาบอกว่าแก้แล้ว

ตอนนี้ผมว่า AI ที่ดี คือ AI ที่กล้าถามว่า "เรื่องนี้ควรแก้รึเปล่า" ก่อนแก้

เคสนี้ฟอร์ม password ทำงานไม่ครบมาเดือนนึงไม่มีใครเรียกร้อง — ลบทิ้งง่ายกว่าทำให้ทำงานจริง และผลลัพธ์ดีกว่าทุกมิติ (ฟอร์มสั้นลง / surface area น้อยลง / ลูกค้าไม่งง)

หลังจากเคสนี้ทิมก็ใช้ pattern เดียวกันกับ feature อื่นในระบบของผมอีก — ครั้งล่าสุดคือ ลบโค้ด alert ของตัวเองทิ้ง 250 บรรทัด เพราะลูกค้าไม่เคยอ่านเมลเตือนเลยสักคน

ของแบบนี้ chatbot อ่านคำถามแล้วตอบ ทำไม่ได้ครับ ต้องเป็น AI Agent ที่อ่าน code เห็นทั้ง pipeline เห็นทั้ง business context (ลูกค้าใส่บัตรก่อน trial — ทุกฟิลด์มีต้นทุน) ถึงเสนอลบทิ้งแทนการ fix ได้

บทเรียนชั้นที่ 2 — feature ที่ "เหมือนทำงาน" คือสิ่งที่ผมรีวิวไม่บ่อยพอ

เคสนี้ทำให้ผมตั้งคำถามกับ feature อื่นในระบบของตัวเองด้วย — มีอะไรอีกมั้ยที่ ดูเหมือนทำงาน แต่ data ไม่เคยถูกใช้จริง

ในระบบของ solopreneur ที่สร้าง feature เร็วๆ ทุกวัน ของพวกนี้สะสมง่าย ฟอร์ม checkbox preference ที่ลูกค้าเลือกแต่ไม่มี code อ่าน setting page ที่ปุ่ม save แต่ไม่ได้ persist setting ที่อ่านจาก database ผิด table

เมื่อก่อนเป็น dev คนเดียวเจอแบบนี้ก็ปะ ๆ ไป — ทุกวันนี้ส่งให้ AI Agent ตรวจ flow แล้วถามตรงๆ "อันไหน decorative อันไหนทำงานจริง" ได้ครับ

คำถามที่พบบ่อย

เมื่อ feature ใน product ไม่ทำงาน ควรแก้หรือลบทิ้งดี?

ขึ้นอยู่กับว่ามีคนต้องการ feature นั้นจริงไหมครับ ถ้าไม่มี support ticket ไม่มีใครร้องขอ และการแก้ให้ทำงานจริงมีต้นทุนสูง (เช่น เพิ่ม attack surface, ทำ form ยาวขึ้น) — การลบออกมักเป็นทางเลือกที่ดีกว่า ง่ายกว่า และทำให้ระบบสะอาดกว่าด้วยครับ

password field บนหน้า signup มีผลต่อ conversion ยังไง?

ทุก field ที่เพิ่มลงใน form มีต้นทุน drop-off ครับ ลูกค้าแต่ละคนที่เห็นแล้วลังเลอาจไม่กดต่อ ถ้า field นั้นไม่จำเป็นจริงๆ (เช่น password ที่ระบบจะ override ทับอยู่ดี) การเอาออกไปจะทำให้ form สั้นลงและ conversion ดีขึ้นได้ครับ

ระบบที่ใช้ random password แทน user-set password ปลอดภัยกว่าไหม?

ขึ้นอยู่กับ implementation ครับ สำหรับ managed service แบบ Newton ที่ส่ง welcome email พร้อมรหัสใหม่อยู่แล้ว การใช้ random password ที่ระบบ generate เองหมายความว่าไม่มี plaintext password ค้างใน queue ระหว่าง async job และไม่เสี่ยงกับ edge case เช่น password มีอักขระพิเศษที่ทำให้ CLI พัง ซึ่งเคยเกิดขึ้นจริงครับ

AI Agent ต่างจาก chatbot ตรงที่แนะนำให้ "ลบ" feature ได้ยังไง?

chatbot ธรรมดาตอบตามคำถามที่ถาม แต่ไม่เห็น full context ของระบบ AI Agent ที่มี SSH เข้า server ได้ อ่าน codebase ทั้งก้อน เข้าใจ business model (เช่น ลูกค้าใส่บัตรก่อน trial — ทุก field มีต้นทุน) จึงเสนอได้ว่า "ลบดีกว่าแก้" แทนที่จะปะให้ผ่านไปครับ

เกี่ยวอะไรกับ Newton

เรื่องที่ผมเล่ามานี้คือเหตุผลที่ Newton ไม่ใช่แค่ "ChatGPT ที่อยู่บน server ของคุณ" ครับ Newton คือ AI Agent ที่อ่าน codebase ของคุณได้ทั้งหมด เห็นทั้ง business context เห็นทั้ง user flow แล้วทำตัวเป็นทั้ง senior dev, business partner และ QA ในคนเดียว

มันไม่ได้แค่เขียน code ตามคำสั่ง — มันถามเองว่า "ฟิลด์นี้ลูกค้ามีประโยชน์มั้ย" "ทำให้ทำงานหรือลบทิ้งดี" "feature ที่ดูเหมือนทำงานในระบบมีอะไรอีก"

คำถามแบบนี้คือคำถามที่ AI บน shared platform ตอบไม่ได้ เพราะมันไม่เห็น code ไม่เห็น database ไม่เห็น flow จริงของลูกค้าคุณ

ถ้าคุณทำธุรกิจที่มี product จริง มี user จริง — และอยากมี AI Agent ที่ กล้าเสนอลบฟีเจอร์ที่ไม่ควรมี ไม่ใช่แค่ปะ ๆ ไป — ลอง Newton ได้ที่ newton.incomeinclick.in.th ครับ AI Agent ส่วนตัวบนเซิร์ฟเวอร์ของคุณเอง พร้อมใช้งานใน 10 นาที 7 วันแรกฟรี ไม่ต้องตั้งรหัสผ่านในฟอร์ม 555

— ปอนด์