Galleries

มีโจทย์ให้ต้องนำเรื่องการเขียน Code ด้วย AI และ Vibe Coding ไปแชร์ความรู้

หลังได้รับโจทย์มา สิ่งแรกที่คิดได้คือ Technical Debt ก่อนเลย เพราะขนาดเราทำแอพฯด้วย AI เอง ยังต้องแก้ตั้งหลายรอบ แล้วหากเราไปแชร์ให้คนที่คิดเอา AI Coding เหล่านี้ไปทำธุรกิจจริงหล่ะ เขาจะไม่เสียค่า Cost ไปกับการแก้ไขหรอ สุดท้ายก็ได้นำสิ่งเหล่านี้ไปแชร์ก่อนรอบที่หนึ่ง

หลังผ่านการแชร์ไปหนึ่งรอบ พูดเรื่องเทคนิคแบบ E2E , Technical Debt ว่ามีอะไรบ้าง และกว่าเราจะได้แอพมาหนึ่งตัวเราต้องรู้เรื่องอะไรบ้างเท่าที่ความรู้ผมนั้นมี

อาทิตย์ถัดไปก็คือเอาเรื่อง AI Vibe Coding ไปเสนอนี่แหล่ะ ว่ามันทำงานอย่างไร

ส่วนตัวเราที่ทำงานกับ AI ได้ แต่ยังรู้สึกว่าเราขาดความรู้อยู่เลย เลยเป็นที่มาให้ได้มาเทคคอร์สสั้นไป 2 บทเรียน

หลังจบได้เทคนิคประยุกต์ AI Coding ได้ในระดับหนึ่ง เหลือเรื่องการทำให้ App คุยได้ดีระหว่าง Frontend , API , Backend – DB.

หลังจบคอร์สนี้หากผู้เรียน Happy คงเปิดคอร์สเรียนแบบนี้ขึ้นมาจริงจังแน่นอน

ตอนนี้ขอไปเรียนต่อก่อน

วันนี้เพิ่งได้ลอง Kiro – Ide Tools เพราะพึ่งได้ code การใช้งานที่ส่งมาใน Email

(ทำให้นึกถึงสมัยเรียน ป.ตรีเลย ที่ต้องได้ invite ก่อนใช้ Gmail…

ยุคนั้นใครมี Gmail ขนาด 1 GB นี่โก้จริง ๆ )

ก่อนหน้านี้เคยอ่านผ่าน ๆ ว่า Kiro เก่งเรื่อง context – spec driven และช่วยเราสั่งงานแบบมีระบบ

แต่ถึงจะอ่านมาแล้ว ถ้าไม่ได้ลองทำจริงก็ยังคิดไม่ออก ว่าน้องจะทำงานยังไง

จนวันนี้ได้ลองจริง ถึงได้รู้ว่าน้อง Kiro มันเก่งจริงๆ

ในภาพก่อนมาหน้านี้ ผมให้ Kiro ออกแบบฟีเจอร์ขึ้นมาฟีเจอร์หนึ่ง

สิ่งที่เกิดขึ้นคือ…น้องจัดการทุกขั้นตอนให้ครบลูปเลย ตั้งแต่ Requirement → Design → Task Breakdown

โดยทำตั้งแต่

1.Requirement (requirement.md)

น้องสกัดสิ่งที่ผมเล่า ออกมาเป็น requirement file

ระหว่างทำก็มีถามซ้ำ เพื่อยืนยันว่าตรงกับที่ผมอยากได้จริง ๆ

ส่วนตัวผมชอบตรงนี้ดีนะ เพราะกันความ “คิดไปเอง” ของ AI ได้ระดับนึง

คือให้เชื่อสิ่งที่เราออกแบบจริง Requirement นี้จริงๆเท่านั้นนะ

2.Design (design.md)

ออกแบบในมุม Dev เหมือนส่งให้ทีมอ่านต่อได้ทันที

เท่าที่อ่านในไฟล์ น้องออกแบบมีโครงชัด ฟังก์ชันชัด พออ่านเสร็จแล้วแอบขนพองสยองแทน SA , BA จริงๆ เพราะน้องเขียนละเอียด เก็บทุกส่วนเป๊ะเว่อร์ หากเราจัดทำเอกสาร เอาสิ่งที่น้อง Kiro เขียน ก็ไปทำงานแทนได้เลย

3.Task Breakdown (task.md)

น้องแตกงานออกมาเป็นข้อ ๆ รอให้ผมเป็นผู้กดเริ่ม (Start Task)

เหมือนมี PM ย่อม ๆ มาช่วย list สิ่งที่ต้องทำก่อนเริ่มโค้ด

เมื่อผมกด Start Task น้องก็ทำหน้าที่เป็น Dev ให้ด้วย

จากใน Task จะเห็นว่ามีเขียน Unit Test แถมมาให้ด้วย อ่านแล้วประทับใจดี

คิดว่าหากจุดนี้ผมเขียน Widget Test , Integration Test , Golden Test

สำหรับ Flutter ไว้ด้วย น้องน่าจะทำงานได้

ปิดท้าย Day 1

เขียนมาถึงตรงนี้ คืออยากจะบอกว่างานฟีเจอร์ที่สั่งยัง Run ไม่จบ เพราะน้องมัน Unit Test กระจาย ถ้าไม่ผ่าน มันก็ไม่หยุด

และจากความรู้สึก ผมคิดว่าน้อง Kiro ตัวนี้มันน่ากลัวจริง การควบคุมสิ่งที่ทำด้วย context – spec driven มันทำให้ดู “ระบบเป็นระบบ” อย่างที่ควรจะเป็นจริงๆ

ขอไปลอง Widget Test , Integration Test , Golden Test สำหรับ Flutter กับน้องเพิ่มอีกหน่อย

หากน้องมันยังเก่งทำงานได้ดีอีก ผมสัญญาจะตั้งใจทำงานไม่มีปาก มีเสียง ขยันทำงานเก็บเงินเลย

นั่งทำแอพฯระบบลงทะเบียนสถานปฏิบัติธรรมบ้านเพชรบำเพ็ญ (บ้านแม่ผมเอง) ตอนนี้อยู่ที่ประมาณ 80-90% แล้ว

ที่เริ่มต้นทำ เพราะจากปัญหาที่เคยเห็นมาหลายๆที่คือ…

-ผู้มาปฏิบัติธรรมต้องเขียนฟอร์มใหม่ทุกครั้ง แม้จะมาเป็นประจำ
-บางท่านต้องฝากบัตรประชาชนไว้ แล้วก็มีลืมรับคืนบ้าง หรือกังวลว่าข้อมูลจะถูกนำไปใช้อะไรหรือเปล่า
-ลายมืออ่านยากทำให้เจ้าหน้าที่ต้องมานั่งเดาอีกว่า “นี่เขียนว่าอะไรนะ”
-และที่สำคัญ…ถ้าถามว่า “สัปดาห์นี้มีคนมากี่คน” ไม่มีตัวเลขชัด ๆ ที่ตอบได้

ผมเลยคิดว่า…”เรานี่ก็น่าจะพอทำ ระบบลงทะเบียนให้สะดวกและปลอดภัยขึ้นได้นะ”
และเพราะผมคลุกคลีกับระบบเดิมมานาน เลยมั่นใจว่าพอจะออกแบบอะไรให้ตอบโจทย์วัดได้แหล่ะ (เป็นเด็กวัด โตมากับวัดเลย)

Tech Stack ที่ใช้ก็จะประมาณนี้
-Flutter รับผิดชอบ UI ต่างๆของหน้าแอพฯ
-SQFLite รับผิดชอบเก็บข้อมูลในฐานข้อมูล หากข้อมูลนั้น Sensitive ก็ให้ระบบนั้น Mark Sensitive Data ไว้
-ChatGPT + Cursor + Claude Code รับผิดชอบเรื่อง QA , Junior Dev , Senior Dev แตกต่างกันไป

ตอนแรกก็อยากจะเล่าว่า “เอ้อ นี่เรานั่งทำแอพฯมานะ ได้แอพนั่นนี่มา” อารมณ์แบบอวดๆหน่อยว่าข้าทำแอพฯได้
แต่ก็ไม่ดีกว่า เพราะว่ามาคิดๆดู เราก็ไม่ใช่คนทำหลัก ที่หลักก็น่าจะเป็น AI เองซะมากกว่า
เลยขอเปลี่ยนเป็นมาเล่าเรื่องการทำงานกับ AI แทน ว่ามันเป็นยังไง

ตอนแรกก็กลัวมากกว่า AI จะมาแย่งงานโปรแกรมเมอร์ + QA หรืองานต่างๆที่เราเคยทำได้
หรือกลัวอีกแบบก็คือ ใครๆก็เขียนโปรแกรมได้นะ ต่อไปได้ตกงานแน่ๆ
แต่พอได้ใช้ AI จริง ๆ ผมกลับมองอีกแบบ

เพราะถ้าเรา พื้นฐานไม่แน่นหรือภาพรวมไม่ชัด ก็เสี่ยงที่จะทำโปรเจควนไปแบบไม่จบ
แม้ AI จะช่วยให้เราเร็วขึ้นก็จริง แต่ถ้าเราไม่รู้ว่ามันทำงานยังไง ก็จบเห่ได้เหมือนกัน

ยกตัวอย่างเช่น
-เวลาผมสั่งให้เพิ่มโค้ดทีละจุด มันก็จะใส่ทุกอย่างลงในหน้าเดียวก่อน เน้นให้ทำงานได้
(Model , View , Controller มาครบ จบในหน้า Screen)
แต่ไม่คิดเรื่อง Reuse เลย จนผมต้องมานั่งบอกว่า “แบบนี้ใช้ซ้ำไม่ได้ ต้องแยก Refactor นะ”
หลังจากโดนดุหลายรอบ น้องก็เริ่มเข้าใจขึ้น

-ปล่อยให้น้อง AI จัดการไฟล์เอง โครงสร้างการเก็บไฟล์เป็นอย่างไร น้องไม่สนใจ น้องจะเก็บแบบตามใจ
สุดท้ายไฟล์อยู่คนละมุม! ทำให้ตอนโปรเจคใหญ่ขึ้น จุดนี้เริ่มทำให้เราเสีย Token ไปกับการค้นหาไฟล์โดยเปล่าประโยชน์(แรกๆก็ไม่อ่านสิ่งที่น้องทำนะ ให้น้องทำ Auto เลย หลังๆเริ่มเสียเวลาไปกับการแก้ไฟล์เอง ถึงได้รู้ว่าน้องนี่หนา!!)

-หลายครั้งน้อง AI พยายามย่อสิ่งที่เคยทำมาให้สั้นลงเพื่อเข้าใจง่าย (compact) แต่พอย่อแล้ว…ทำงานช้าลง แถมลืมความรู้เดิมอีก
เหมือนพยายามจะสรุป Lecture ให้เรา แต่ดันลืมบอกประเด็นสำคัญ สุดท้ายอ๊องๆไปเลยก็มี

-ยังไม่นับรวมกับการพยายามสร้าง Class ใหม่เพิ่มเสมอ Screen เก่ามีผมก็ไม่สน ผมเน้นทำใหม่ดีกว่า

จากจุดนี้เริ่มทำให้รู้สึกว่า
-การวางแผน Prompt ในปัจจุบันสำคัญพอ ๆ กับการเขียนโค้ด
-ต้องเข้าใจพฤติกรรม AI เพื่อรู้ว่าจะให้มันทำอะไรต่อ
-ใช้น้อง ก็ควรอำนวยความสะดวกให้น้อง เช่น บอกน้องไปเลยว่าทำงานที่ไฟล์ไหน
-น้องชอบ Compact บ่อย ให้วางเช็คพอยต์ของงาน เช่น ไฟล์ md สรุปโครงสร้างและความคืบหน้าไว้เสมอ
เมื่อน้องเอ๋อ ให้น้องไปอ่านไฟล์นั้นๆ ใหม่ในครั้งถัดไป

หากไม่ได้เริ่มทำ(prompt กับ AI) จริง คงคิดไม่ออกจริงๆนะว่า AI นั้นทำงานอย่างไร

แล้วก็มีประโยคหนึ่งที่ผมชอบ จากหนังสือ “ไอน์สไตน์” (walter isaacson)
ที่อัลเบิร์ต ไอน์สไตน์ (Albert Einstein) ได้กล่าวไว้ว่า “God doesn’t play dice with the universe”
แต่หลังผมลองเล่น AI เสร็จ ก็ได้คำตอบละว่า “พระเจ้าทอยลูกเต๋าแน่นอน !!!”

**จากในภาพเป็นเวอร์ชั่นใส่ Requirement เผื่อไว้เยอะไปหน่อยนะ มีจองห้องพักได้ด้วย

อนาคตหากมีสถานปฏิบัติธรรมไหน มี logic การลงทะเบียนคล้ายๆกัน น่าจะนำไปต่อยอดได้

หลังเห็นข่าวพนักงานที่เป็น Dev ของ Microsoft โดนปลดออก (ย้ำว่า Developer ของ Microsoft โดนปลดออก)

ก็สร้างความกังวลให้พนักงาน QA ธรรมดาๆเช่นผมสั่นคลอนเลย

แต่ก็นะ หากสถานการณ์อะไรในอนาคตจะผ่านเข้ามา เราเปลี่ยนมันไม่ได้อยู่แล้ว เห็นเหตุการณ์ที่เกิดขึ้นแล้ว เป็นเหมือนสัญญาณที่บอกให้เราระวังตัวไว้ไม่ให้ประมาทกันดีกว่า

==============================================

จากที่ก่อนหน้า ความ Popular เกี่ยวกับ Automation Workflow ได้ผ่านตามาให้ได้รู้จักบ้าง ตัวอย่างเช่น make ที่เพียงแค่เราลากวางอะไรแต่ละอย่าง ก็สามารถทำงานได้อย่างอัตโนมัติเลย ก็ได้สร้างความสนใจเรียกร้องให้เราลองหามาเล่น เพึยงแต่เรายังไม่มีเวลาไปศึกษามันอย่างจริงจังในตอนนั้น

จนตอนนี้ได้เวลากลับมาจึงได้ทดลองอย่างจริงๆจังๆ จึงได้เลือก Tool ที่ชื่อ “n8n” แล้วพบว่า

“ดีใจที่ได้รู้จักกันตอนยังมีงานทำอยู่” 555

หลังลองเล่น n8n เพียงไม่กี่ชั่วโมง
ถึงตอนนี้ห้องทดลองในความคิดก็ยังไม่หยุดพักเลย

ยกตัวอย่างสักสองสามตัวอย่าง ที่น่าจะทำได้ด้วย n8n ได้ดังนี้

Scenario: ผมเป็น Content Creator ที่ต้องผลิตคอนเทนต์จำนวนมาก โดยใช้ข้อมูลจาก Google Sheets
จึงสร้าง Workflow ด้วย n8n เพื่อให้ ChatGPT สร้างเนื้อหาให้โดยอัตโนมัติ พร้อมจัดการเอกสารและบันทึกผล

Flow:

⏰ Trigger:
ใช้ Schedule Trigger ให้ระบบทำงานทุกวัน (หรือเวลาที่ตั้งไว้)
และสามารถกดปุ่ม Test workflow เพื่อเรียกใช้แบบ manual ได้ด้วย

📊 Node: Google Sheets
ดึงข้อมูลจาก Spreadsheet ที่เก็บไอเดีย/หัวข้อที่ต้องการให้ AI ช่วยเขียน
เช่น “นิทานจักรวาล”, “คอนเทนต์ให้แรงบันดาลใจ”, ฯลฯ จากตัวอย่าง 10 รายการ

🔢 Node: Limit
จำกัดจำนวนแถวที่อ่าน เช่น 1–3 แถวแรก เพื่อลดภาระของระบบ และให้ทำงานแบบ Batch

🤖 Node: Gen Content (Tools Agent)
ส่งข้อมูลเข้า AI (เช่น ChatGPT) เพื่อสร้างเนื้อหาตามที่กำหนด
โดยต่อเข้ากับ Node OpenAI Chat Model ซึ่งกำหนด Prompt หรือ Context ที่ใช้

📄 Node: Create doc (Google Docs)
สร้างเอกสารใหม่จากเนื้อหาที่ได้จาก AI โดยกำหนด Format ตามที่ต้องการ เช่น ใส่หัวข้อ ชื่อเรื่อง หรือวันที่

📝 Node: Update doc
เขียนเนื้อหาเพิ่มเติมลงในเอกสาร เช่น ใส่ Metadata, หรือลงท้ายชื่อผู้เขียน

✅ Node: Update done (Google Sheet)
เขียนค่ากลับไปยัง Google Sheet ต้นทาง เช่น

• อัปเดตสถานะ “✅ เสร็จแล้ว”
• หรือเขียน URL ของ Google Doc ที่สร้างไว้ เพื่อเก็บลิงก์ (จากตัวอย่างที่กำลังนั่งเรียน เขาจะพาไปสร้างเป็นวิดีโอนิทานเลย)

Scenario: QA ที่ต้องตรวจสอบ API หลายระบบทุกวันเพื่อให้แน่ใจว่า endpoint ต่าง ๆ ยังใช้งานได้ พร้อมรายงานผลให้ทีม Dev,QA แบบรวดเร็วและอัตโนมัติ (ในขณะที่ pipeline ยังสร้างไม่เสร็จ)

Flow:

⏰ Trigger: รันทุกเช้า 08:00 น. ด้วย Cron จาก Scheduler

🌐 Node: ใช้ HTTP Request ยิง API ไปยัง endpoint ทั้งหมดที่ต้องทดสอบ (เช่น 10 จุด)

⚠️ Node: ตรวจ Response → ถ้า Response code ≠ 200 หรือ Timeout → บันทึก log + ระบุ endpoint ที่มีปัญหา + ถ้าผิดปกติ → ส่งแจ้งเตือน LINE / Email (Line ตอนนี้ยังส่งได้ไหมหว่า ?)

✅ Node: ถ้ากลับมาปกติ → แจ้งซ้ำอีกครั้ง ส่ง Summary Report ผ่าน LINE หรือ Email
→ พร้อม Highlight ว่า endpoint ไหนล้มเหลว
→ ระบุเวลาที่เกิด error

📊 Node: Log รายงานการล่ม + เวลาฟื้นกลับ ใน Google Sheet → เก็บเป็นสถิติประจำวัน
→ ใช้เทียบย้อนหลังหรือทำ Dashboard API health report ได้

👉 เหมาะกับ QA ที่ดูแลระบบ API หลายตัว , ทีมที่ต้องการรู้ปัญหาเชิงรุกก่อน User เจอ , ทีมที่กำลังเริ่ม Project ยังไม่มี Pipeline , คนที่อยากใช้เวลาเช้าไปกับ วิเคราะห์คุณภาพ แทนการไล่เช็คแบบ manual

Scenario: เจ้าของกิจการเปิดเว็บให้ลูกค้าเลือกสินค้า แล้วค่อยสั่งจาก 1688/เถาเป่าโดยอัตโนมัติ พร้อมสรุปรายงาน

Flow:

📩 Trigger: มีการ Submit คำสั่งซื้อผ่านหน้าเว็บที่ทำไว้ จากนั้นส่ง Webhook เข้า n8n ให้ทำงาน

📋 Node: อ่านข้อมูลสินค้าจาก DB หรือ Google Sheet

🚚 Node: ไปสั่งของในเว็บจีน หรือผ่าน API Shipping Partner

📊 Node: สรุปรายการสั่งซื้อของวันนั้น ลง Google Sheet

📧 Node: ส่งรายงานรายวันเข้า Email/LINE

👉 เหมาะกับพ่อค้าแม่ค้าออนไลน์ที่ต้องการลดงาน manual ในการสั่งของ + ตรวจสอบ + แจ้งยอด (อันนี้คิดเองว่าน่าจะได้ เพราะมีเพื่อนขายของแบบนี้อยู่ ไม่ต้องเสียเวลามากรอกข้อมูล ให้ n8n ทำงานกรอกให้)

ตอนนี้แค่ลองเล่นยังนึก Use Case ออกได้ขนาดนี้
เลยอดคิดไม่ได้ว่า…ถ้าศึกษา n8n ต่อไปอีกสักเดือนสองเดือน จะสร้างอะไรได้อีกเยอะแค่ไหนกัน?
เอาเป็นว่า…ถ้ามีอะไรใหม่ ๆ เดี๋ยวจะมาเล่าให้ฟังอีกแน่นอนครับ 😉