7 วิธี De-slop UI ในยุค AI Agent, จากวิศวกรที่ทำ Ref.tools

โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 29 สิงหาคม 2026

บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจากบทความ "How I Design with AI" ของ Matt Dailey (@reactiverobot)

ก่อนอื่น, ทำความเข้าใจศัพท์

ก่อนเข้าเรื่อง ขอปูศัพท์ 3 คำที่คนอ่านบทความนี้ต้องรู้ก่อน:

• Slop: ผลงาน AI ที่ "เยอะแต่ไร้คุณภาพ", ดูเหมือนกันหมด ไม่มีความคิดสร้างสรรค์ เหมือนของถ้วนโมฆะที่ผลิตมากๆ
• Prototype Gravity: แรงดึงดูดของ "ต้นแบบแรก", เมื่อสร้างเวอร์ชันแรกใน codebase แล้ว จะรู้สึก "ขี้เกียจเริ่มใหม่" ทำให้ติดอยู่กับทางเลือกแรกที่อาจไม่ดีที่สุด
• Design Constraints: กฎเกณฑ์ที่ "บังคับ" การออกแบบ, เช่น ขนาดฟอนต์, workflow, business logic

ถ้าให้อุปมา: ให้ AI ออกแบบ UI เหมือน "จ้างช่างรีโนเวทบ้าน", ช่าง (AI) ทำงานเร็วมาก แต่ถ้าไม่มีแบบ (constraints) ก็จะ "ต่อเติมมั่ว" จนบ้านกลายเป็น slop

เรื่องนี้คืออะไร

Matt Dailey (@reactiverobot), วิศวกรที่ทำ Ref.tools และเคยทำงานที่ Figma กับ Palantir, เขียนบทความ "How I Design with AI" แบ่ยปันวิธีออกแบบ UI ร่วมกับ AI agent โดยไม่ให้ผลงานกลายเป็น slop 1

ปัญหาที่เขาชี้:

"Every landing page, app and tui look the same. They're slop and most of them are incomprehensible."
(ทุก landing page, แอป และ tui ดูเหมือนกันหมด พวกมันคือ slop และส่วนใหญ่อ่านไม่รู้เรื่อง)

แก่นของบทความ: เขาไม่ได้บอกให้ "เลิกใช้ AI" แต่บอกว่า "วิศวกรต้องเป็นคนคุมกระบวนการออกแบบ" ผ่าน 7 หลักการ

7 หลักการ De-slop

1. มองภาพรวมเสมอ (Always consider the whole)

กระบวนการออกแบบมี 3 ขั้น [1]:

ขั้น	ทำอะไร
1	วาง constraints ทั้งหมดที่ออกแบบให้
2	คิดชุดของ solutions ที่ตอบโจทย์ constraints
3	ถ้าพบว่าต้องเพิ่ม/ลบ constraint → กลับไปขั้น 1

อ้างอิงจากหนังสือ Notes on the Synthesis of Form ของ Christopher Alexander

กับดักที่คนตกบ่อย: ข้ามขั้น 3, เล่น "design wackamole" (แก้หน้าแก้หลัง), แก้ปัญหาเฉพาะจุดจนงานกลายเป็น "ผ้าปะ"

2. ลบ (Remove stuff)

"Agents love to add stuff. Your job is to remove the unnecessary parts."
(Agent ชอบเพิ่มของ งานของคุณคือลบส่วนเกิน)

AI agent มีนิสัย "เพิ่ม", copy เยอะ, เส้นเยอะ, ไอคอนเยอะ [1]

วิธีทำ: มองทุก element แล้วถาม: "จำเป็นจริงหรือเปล่า?", ลบขยะของ agent ทิ้ง

3. Iterate ในเครื่องมือออกแบบ (Iterate in a design tool)

"Do not iterate on design in the product."
(อย่าปรับแก้ดีไซน์ในตัว product)

ใช้ Figma, Cursor Design Mode, หรือ Claude Design แทน [1]

เหตุผล, "Prototype Gravity" คือฆาตกรเงียบ:

• สร้างเวอร์ชันแรกใน codebase → รู้สึก "ผูกมัด" กับมัน → ขี้เกียจสำรวจทางเลือกอื่น
• วิธีแก้: ให้ AI สร้าง 3-4 variants ใน design tool ก่อนเสมอ แล้วค่อยเลือก

4. ใช้ Components และ Libraries

แยก views ออกจาก logic สร้าง reusable components [1]

แนวทางของ Ref: เขาดูแลหน้า /showcase ที่สร้าง UI components ก่อนเล่นกับมัน แล้วค่อยเชื่อมกับแอปหลัก

5. ใช้ Preview Deploys

"The best way to evaluate a design is with real data."
(วิธีที่ดีที่สุดในการประเมินดีไซน์คือด้วยข้อมูลจริง)

ต่อให้ agent สร้างตามที่บอกทุกอย่าง ก็อาจ "รู้สึกไม่ใช่" เมื่อได้ลองกับข้อมูลจริง [1]

ทำไมสำคัญ: Preview deploys ทำให้แชร์และ verify การเปลี่ยนแปลง frontend ได้ง่าย

6. ขโมยไอเดีย (Steal stuff)

"Most UX problems have been solved already."
(ปัญหา UX ส่วนใหญ่ถูกแก้ไปแล้ว)

ใช้เวลาดู products ที่แก้ปัญหาคล้ายกัน เก็บ screenshots มาเป็น context ส่งให้ agent [1]

7. สำรวจรสนิยม (Explore your taste)

"Taste is reflecting on your own reaction to something."
(Taste คือการสะท้อนความรู้สึกของตัวเองต่อสิ่งนั้น)

วิศวกรเก่งเรื่อง "รู้ว่าดีไซน์ไม่เวิร์ก" แต่มักขาด "คลังทางแก้" [1]

วิธีฝึกของ Ref, "agricultural threshing approach": โยนดีไซน์กลางวง แล้ว "ตีมันด้วยไม้" จนกว่าจะดี (ตีความ: วิจารณ์ตรงๆ หลายรอบ)

ทำไมเรื่องนี้ถึงสำคัญตอนนี้

เหตุผล	คำอธิบาย
AI สร้าง UI ได้เร็วมาก	ความเร็วไม่ได้แปลว่า "ดี", ยิ่งเร็ว ยิ่งเสี่ยง slop
ทุกคนใช้เครื่องมือเดียวกัน	ผลลัพธ์เลย "เหมือนกันหมด", ความต่างอยู่ที่คนคุม
Skill ที่แพงขึ้นคือ "taste"	คนที่มี taste + รู้วิธีคุม agent = ได้เปรียบ

ข้อควรระวัง: มุมที่ต้องสมดุล

ก่อนสรุป ขอวางมุมให้ตรง:

ข้อดี (ของแนวทางนี้)	ข้อควรระวัง
เป็น "ปฏิบัติการจริง" จากคนทำ product จริง	เป็นมุมมองคนเดียว, ไม่ใช่กฎเหล็ก
แก้ปัญหา "slop" ที่หลายคนเจอ	บางข้อ (เช่น Figma) ผูกกับ workflow ของ Ref
อ่านง่าย + ลงมือทำได้	"Taste" ยังเป็นเรื่อง subjective

สรุปมุมมองของผม

ผมมองว่าบทความนี้ "คม" ที่สุดตรงหลักการข้อ 2 และ 3, เพราะมันจับ "จุดอ่อน" ของ AI agent ได้ตรงที่สุด:

AI agent ชอบ "เพิ่ม" ไม่ชอบ "ลบ", และมันชอบ "ทำใน codebase" ทันที ทำให้เราติดกับดัก "prototype gravity" โดยไม่รู้ตัว

และสิ่งที่ผมชอบที่สุดคือคำว่า "de-slop", เพราะมันสื่อว่า ปัญหาไม่ใช่ "AI ทำงานไม่ได้" แต่คือ "AI ทำงานได้เยอะเกิน", งานของวิศวกรจึงเปลี่ยนจาก "สร้าง" ไปเป็น "คัดกรอง"

มันสอดคล้องกับสิ่งที่ผมเขียนมาตลอด: เครื่องมือ AI ไม่ได้แทนที่ taste ของคน, มันแค่ทำให้คนที่ไม่มี taste สร้างของเยอะขึ้นเร็วขึ้น (ซึ่งก็คือ slop ที่แท้จริง)

คุณเคยโดน "prototype gravity" กันไหมครับ, เริ่มอะไรครั้งแรกแล้วขี้เกียจเริ่มใหม่? แล้วคุณใช้วิธีไหน "ลบส่วนเกิน" จากงาน AI? คอมเมนต์แลกเปลี่ยนกันได้ครับ

ถ้าชอบบทความแนว AI + design แบบนี้ ติดตาม Nokka ได้ที่ dev.to/sarantoon

แหล่งอ้างอิง

[1] Dailey, Matt (@reactiverobot). "How I Design with AI". X. 2026. https://x.com/reactiverobot/article/2092638003789439075

[2] Alexander, Christopher. "Notes on the Synthesis of Form". Harvard University Press. 1964.

---

บทความนี้วิเคราะห์จากบทความ "How I Design with AI" ของ Matt Dailey ข้อมูล ณ 29 สิงหาคม 2026 Nokka