สำหรับงานปีนี้ Theme หลักคงเป็น AI แต่มีอีกหลาย Track ให้เข้าไปฟังอย่างส่วน Fundamental / TalkX หรือ Serious Disscussion ครับ ของผมที่ฟังมาจดๆมาตามหัวข้อนี้ครับ
Table of Contents
ปล จะเลี่ยง AI รู้สึกว่ามันเยอะไปแล้ว 555
Vibe Coding with Qwen Coder
Speaker Jaru Nartboon

Alibaba Cloud มี DC ในไทยด้วยนะ รวมถึง AI Infra ซึ่งตอนแรกตัวทำขึ้นมาใช้กันเอง ของเครือ Alibaba AMap / Taobao เห็นว่ามันมีอะไรที่เสริมกัน รองรับ Req /Tx มาก ช่วงวันคนโสด 1111 ถ้ามองในตัว Taobao มีหลาย Service มา Serve มีเบื้องหลังเป็น AI อย่างตัว Image Search / Smart Logistic / Intelligent Customer Service (Chat Bot ลดการใช้คนได้เกือบๆ 98% 7 แสนคน) / Visual identity / Smart Home และ Realtime Transalation
เห็นว่าในแต่ละ Service จะเอา Know How ของแต่ละ Biz มาเสริมกัน ให้เกิด Product ใหม่ โดยเอาข้อมูลที่มีมาทำ Model ใช้งานกันเอง โดยมี 2 กลุ่ม

- Qwen เป็น LLM Model ที่ทำงานในส่วน
- Generalize - qwen3-turbo เล็ก / qwen3-Plus กลาง และ qwen3-max ตัวเต็ม
- หรือ Specialize อย่าง qwen3-coder / qwen3-math
- หรือ แบบ Multi Modal อย่างตัว qwen3-VL เน้นด้านงาน Vision - นอกจากนี้มี Model อีกกลุ่ม อย่างตัว Wan เอามาชนกับพวก Nano Banana Veo / Sora / Grok พวก Gen ภาพ Video ต่างๆ
จากนั้นเอา Model มาใช้กับ Product ตัวเอง อย่างตัว Quark AI Glasses S1 แว่นตาที่มีจอ + AI ช่วยบอกว่าข้อมูลที่เห็น คือ อะไร หรือ เอามาใช้การประชุม อย่าง realtime transalate เป็นต้น นำทาง หรือ ช่วยจัดการ task ใน ชีวิตประจำวัน เป็นต้น และมีเบื่องหลัง Qwen3 / อีกมุมตัว Wan 2.6 ตัว Video / Image มันทำแบบ Film Production Grade
Garther Emering Market Quadrant จะเห็นตัว Model ของ Alibaba Cloud อยู่ในกลุ่ม ผู้นำ ทั้งด้าน Gen AI Model / Gen Ai Spcilized Cloud Infra / AI Engineering / AI Kniwledge Managenent App / General Productivity
หากต้องการ Deploy AI Model มี 3 แบบ
- Model as a Service Per Token / Call -
- Manage GPU (Paas / Iaas) Per Resource Hour
- Private AI Stack ซื้อ HW + SW มาตั้ง


- ถ้ากังวลเรื่อง Data + AI มี ISO 42001 และมี Product CloudShield.ai ที่ช่วยทำ Guardrail / ตรวจการหลอกถาม เป็นต้น
- ถ้าทำ AI App มี Layer แนะนำนะ
- ตัว Qwen และ Wan เป็น Open Source (Version -1) เลยทำให้มีการเอา Model ไปใช้ ตัว Sea-Lion v4 อันนี้ Model ที่ Gov SG เอา Qwen และ Fine Tune ต่อยอดด้วย
Qwen3-Coder

ก่อนมาถึง Qwen3-Coder ต้องอธิบาย Qwen3 ก่อน ขยายจากส่วนแรกอีกทีนึง โดยเจ้า Qwen3 มี Thinking Mode แล้ว ตัว Model มี 2 แบบด้วย Dense (ใช้ Param ทั้งหมด) / MoE (ใช้ Param เท่าที่จำเป็น)
ตัว Qwen3 เก่งหลายด้วย โดยผ่านการทดสอบ CodeForce. LiveBench / LiveCodeBench / SWEBench คะแนนที่ใช้ได้ ถ้าเทียบกับค่ายดังๆ Gemini / GPT

และเพื่อให้ทำงาน ให้มี Specialize อย่างตัว Coding เลยมีการ Fine Tune - Reinforce Learning ต่อ และวัดผลเพิ่มกับ SWEBench (ข้อสอบSW Eng) / Aider Polyglot (หลายหลายภาษา)
สำหรับการใช้งาน Qwen3-Coder มี Pattern Integrate ได้หลายแบบ ผ่าน Tools - CLI / IDE / API SDK หรือ จะถูกเรียกใช้ผ่าน AI ตัวอื่น ตัว Qwen ทำตัวเป็น MCP นอกจากนี้มีตัวที่ชนกับ Claude Code ด้วยนะ Qwen Code แต่มี Platform ยอดอีกทีนะ เห็นว่าเปิดตัวเดือนหน้า
อ๋อ แล้วใน VS Code มี Extension ของ Qwen Code Companion
จากนั้นเป็น Demo แล้ว - Key
- บอก Req ให้ชัดเจน มี Step ที่ดี ลดการ Re prompt แก้ซ้ำ
- อีกแบบ Structure การกำหนด Qwen.md / Skill.md ลองดู Sample เพิ่มได้นะ https://github.com/QwenLM/qwen-code-examples
และมีงาน Qwen Meetup 2026-01-26 ด้วยนะ
ปกติผมใช้ Qwen กับ OpenWebUI เดี๋ยวต้องมาลองตัว Qwen Code เพิ่ม
A Developer's Pain Is Not Always a Bug
Speaker Kittikorn Prasertsak

Developer's Pain Fact 3 ข้อ
Fact แรก 80% ของ Professional Dev ไม่ Happy กับงาน
Ref: shiftmag.dev
1/3 ไม่ชอบงานตัวเอง รองลงมาการทำงานแบบ survive mode อาจจะงานเยอะ เปลี่ยนเต็มไปหมดจับโยนลงน้ำ แก้กันหน้างาน เจอ Code เน่าๆ หรือ การแก้แบบไม่บอกใครแล้วมี impact ที่ต้องมาตามเก็บ เป็นต้น
AI Adoption มันพุ่งไปไกลมา จนทุกคนกลัวตามไม่ทัน
ตอนนี้ส่วนใหญ่เกือบ 80% เอา AI มาช่วยแล้วนะ แต่เกือบครึ่งยังไม่ได้มั่นใจถึง Quality ที่ใช้งานได้นะ
ตลาดงาน Entry ลดลงหนักจนเด็กรุ่นใหม่ท้อ
ข้อมูลจากหลายแหล่ง The Hacker New ? Guadian / Stack Overflow งานบอกตรงกันว่างานมันลดลง 25% โดยปัญหาที่พบเจอแยกเป็น 3 ประเด็นตามแต่ละ Gen
- Junior ประตูมันแคบลง เพราะ AI มันเข้ามาแทนได้ระดับนึง
- Mid ทำงานเร็วขึ้น แต่ทำไมมันไม่จบ ของเพิ่ม หรือ แก้ A แล้ว impact B ลองดู Blog เพิ่มได้
- ประสบการณ์สอนให้เจอกับความเจ็บปวด ต่างกับช่วงเรียนที่ที่ one night miracle ตอนสอบ ทำ term project
- แรงกดดันแบบแซนวิช จากน้อง และจากข้างบน - Senoir / Lead คุณไม่ใช่ Dev แต่เป็นกันชน เรื่องคน และผลประโยชน์ล้วนๆ แล้ว Technical หละ ?
ปัญหาพวกนี้ทำให้เปิดปัญหาใหญ่ จริงเป็นกันทุกอาชีพนะ นั้น คือ
- เรื่อง Burnout เพราะงานไม่มีวันจบในหัวเรา
- Knowledge Silo & Commnucation Tax วุ่นวายเรื่องของคน เช่น ต้องไปเดินคุยเอง หลาย Hop เพื่อหาข้อมูล
- Mentorship ลดลง เพื่อเส้นระหว่างวัย และระยะทางเพิ่มขึ้นจากการ remote
ทำให้ junior ไม่กล้าถาม กลัวทำลาย productivity ของคนอื่นในทีม - Performance Review ทำดีแค่ไหน คนที่ไม่เห็นความพยายามของเรา ทำให้คนลาออก อาทิ เช่น Coverage คนกลุ่มนึงทำแทบตาย กับอีกคนที่ไม่ได้สนใจเลย ได้คะแนนเท่ากัน บางทีเอาออกได้ด้วย
การเยียวยา Pain นั้นมองว่าไม่ใช่ Bug นะ เป็น Trigger ที่บอกว่าเราต้อมาปรับปรุงบางอย่าง
จากนั้น Ad เปรมแนะนำหนังสือ Business Made Simple, Donald Miller(แปล)
- ถ้าเราเป็นคนทำงาน มองว่าเราเองเป็น ฺBusiness unit อันนึงใน บ ใหญ่ๆ ให้คิดเลยว่า Requestor ต้องการอะไร หรือลองคิดว่าเราสร้างผลตอบแทนได้ 5 เท่าได้บ้าง แล้วตรงนี้มาหาต่อว่าทำอย่างไร เพิ่ม Productivity + Quality
- ถ้าเราพัฒนาตัวเองดี เราสามารถ fade ตัวเอง ไปใช้งานที่อื่นต่อได้ ความเจ็บปวดอาชีพ ทีม องค์กร เราเลือก fade ได้
- 10x Growth หา pain ของลูกค้าให้เจอ มองว่าเราเป็นตัวเองของงานนั้นๆ ในเส้นของเราเอง ลูกค้า user เป็นส่วนเสริมใน timeline เรา
Pain Stack หารู้ปัญหาถูกจุด สามารถเอายามาแก้ได้ตรงใจ

- Tooling (เครื่องมือ อย่าง AI / Tech Dedt)
- Process (Scope creep / Meeting / Deadline (จิง / Check point)
- People (Silo Communucation Mentorship)
- Purpose (Fairness / Recognition / Performance Review)
นอกจากการเอา Pain Stack มาแก้แล้ว เราต้องเข้าใจคนด้วย โดย Ad เปรมแนะนำหนังสือ หนังสือ Radical Candor (บริหาร จริงใจแบบตรงไปตรงมา), kim scott (แปล) สรุปสั้นๆ

- Ruinous Empathy - เกรงใจกันจนไม่กล้าติชมอย่างตรง - มีข้อผิดพลาด แต่ไม่ได้บอกชัดเจน จนมีเหตุร้ายแรง / อีกอันใจดีเกินไป เช่น คนมาสาย หรือ กลับก่อน ไม่กล้าเตือน จนคนดีๆ ท้อเสียกำลังใจ เพราะทำตามกฏ (Blog1 / Blog2)
- Obnoxious Aggression - การก้าวร้าวที่น่ารังเกียจ ต้องการผลลัพธ์ โดยไม่ได้ใส่ใจ เช่น ประจานเลย หรือด่าเพราะงวดเก็บเงินไม่ได้ (Blog)
- Manipulative Insincerity - วงการบันเทิงอ่านะ ต่อหน้า พูดชม ลับหลังอีกแบบ แพร่ความ Toxic
ทั้งที่จริงๆแล้ว State ที่ควรจะเป็น Radical Candor - จริงใจตรงไปตรงมา - สร้างความไว้วางใจและการพัฒนาที่แท้จริง
3 Key Junoir Mid Senior
- Junior หาทาง improve เริ่มจากาการตั้งคำถาม และดูว่างานที่เราทำสร้าง Impact อะไรให้กับองค์กร
- Mid - วัดงานเป็น Outcome ที่ได้ ไม่ใช้ Output และพยายาม Improve documentation / automation แอะสุดการ boundary (กำหนดขอบงานให้ชัด)
- Senior/Lead - สร้าง Performance ที่ชัดเจน ลด Task บางอันที่ไม่จำเป็นอย่าง Meeting / Silo สร้างวัฒนธรรมที่ให้เกิดการ mentorship กล้าที่จะปฏิเสธ เห็นต่างได้
Build AI Agents at Scale with Microsoft Foundry,
Speaker Teerasej Jiraphatchandej
ทุกวันนี้ Application ผ่านมาหลายยุคเลยนะตั้งแต่ CLI > Desktop App > WebApp > AI App ซึ่ง Core ยังไม่เปลี่ยนนะ ตัว Business Requirement ที่ยังไม่เปลี่ยนแปลงไป ต่างกันแค่ส่วน Interaction กับเรา และแนวคิดการในทำงาน
- เดิม Rule Base ที่ต้องเตรียมข้อมูลให้ะร้อม และมี logic ข้างในที่ซับซ้อน
- Agent (AI App) ใช้ LLM มาช่วยให้ตอบธรรมชาติมากขึ้น และสามารถเติมข้อมูที่ซับซ้อนได้
ทาง Garner ได้คาดการณ์ว่าในปี 2026 40% จะไปทาง Agent มาขึ้น
Microsoft Foundary

มีของเข้ามาช่วยตอบโจทย์ อันนี้ ลองอ่านเพิ่มได้ dotnet conf th 2025
E2E Agentic AI life Cycle

📌 Build ช่วงการเลือก Model ตาม use case + cost ที่มี จากตัว Foundary Model Catelog ตอนนี้มีหลายค่ายนะ Open AI / Grok / Claude รวมถึงกลุ่ม open source
- สำหรับตัว Claude ตอนนี้สามารถใช้บน Azure เชื่อมกับ Claude Code / IDE Extension / SDK ด้วยนะ
- ในตัว Model มีตัว Compare ความาสามารถในมุมต่างๆ ทั้ง Quality / Speed / Safety หรือ Estimate Cost
- ถ้าใครกังวลเรื่อง Cost จะมีแนวคิด Auto Model แบบใน GitHub Copilot นั้นตัว Model Rounter ที่ช่วยประเมิน Prompt ให้เลือกว่างานไหนควรใช้ Model อะไร



- Multi Agent Workflow แบบตัว n8n เป็น Grahical Workflow ที่เป็น Defintion ต่างๆ ในรูปแบบ yaml
- Hosted Agents - เอา Agent มาฝาก Run บน Microsoft Foundary
📌 Deploy ตอนนี้ถ้าเรามี Agent เราสามารถ ให้มัน Auto Deploy ไปทั้ง API / M365 / MS Team ได้เลย
📌 Operate มี Control Pane ให้ Track ภาพรวมของ Agent เช่น จำนวนที่มี / Token ที่ใช้ / Error ที่เปิดขึ้น เป็นต้น แบบอีกค่ายตอนเมื่อเช้าน 555
และมี Live ที่อัดเกี่ยวกับ Microsoft Agent Framework - National Coding Day 2026 ของ อจ Surasuk Oakkharaamonphong สำหรับสาย Coding เข้าไปดูต่อกันได้
"Invariants"
Speaker Dave Rawitat Pulam
จากเมื่อหลายปีก่อน เรามักได้ยินว่าสาขานี้เรียนไป ไม่ตกงานแน่นอน แต่เวลาผ่านไป มันมี change log มากมายทำให้ fact เดิมนั้นเปลี่ยนแปลงได้ อย่างเช่น การมาของ AI ทำให้งานบางอันลดความสำคัญลงไป
There are some things in this world, Captain Niobe, that will never change.
Morpheus
มันมีบางอย่างที่มัน Invariants ไม้เปลี่ยนแปลงนะ การจะหามัน เราต้องมาไล่ดูเจ้า Change log ที่ผ่านๆมาในอดีต อย่าง อย่างพวก Quote คำที่ยังใช้ได้ เมื่อก่อน และปัจจุบันยังใช้งานได้อยู่ อย่าง
Programming หลายคนบอกการ thinking แต่จริงๆ ถ้ามองลึกไป problem soloving +++

A > B
Problem Gap A (Input) > B (Output / Desire Conclusion / ANS)
- ปัญหา A เข้าใจ กับ B เข้าใจ ตรงกันไหม เช่น ใช้งานง่าย ง่ายของฉัน กับของเธอเป็นอย่างไร
- ทำให้เส้นจาก A ไป B มันหลากหลาย มีหลายเส้นทาง
- เกิดการแตก Gap A > B แยกย่อยลงไปเรื่อยๆ หลายจุดอาจจะ A1 > B1 หรือ จริงๆแล้ว Gap ที่เราเจอ มันเล็กสุด มีคนหา Solution ไว้แล้ว เหลือแค่เราต้องมาดูว่าเหมาะกับฉันไหม หรือ เป็น Gap ใหม่ ฮ่าา ต้องดูบริบท หรือช่วงเวลานั้นๆที่มัน Work ด้วย
ตรงนี้งานของเราที่ต้องพยายามเชื่อมจุด A > B ที่ใช้ได้ ต้องมี Step ชัดเจน และ Break ปัญหาจาก A > B จนเป็นปัญหาย่อยๆ ที่ร้อยเรียงกันมาต้องเล็กลงจนมีวิธีการแก้ปัญหาที่ชัดเจน
ถ้า Code อาจจะหยิบ Algorithm ที่คนทำไว้ แต่งานจริงๆเราต้อง
First, Solve the problem, Then write Code
John Johnson
มันก็ตาม Quote เลยแหละ คิดก่อนทำ นี่แหละ ถ้าไปลุย Code ก่อน สิ่งที่เราได้มันจะเป็น Another Problem แทน
ดังนั้น ถ้าเราอยากทำอะไรที่มาช่วยช่วยแก้ปัญหาได้ ทำซ้ำได้ อย่างแรก แก้ปัญหาให้ได้ก่อน แล้วค่อยให้คอมพิวเตอร์มันเอาไปทำงานต่อ / scale ได้ ดังนั้นพอ AI เข้ามามันไม่ได้เปลี่ยนอะไรเลยจะ แค่เปลี่ยนเครื่องมือ ถ้าถามผมทื่ฟังคงมาจากคุย Turbo C/NotePad มาพวก IDE สมัยใหม่

นอกจากนี้แล้ว Data Strucure ไม่ใช้พวก Stack List Queue นะ มันเป็น Logical Model ของสิ่งของรอบตัวเรา ที่เราเอามาอธิบายปัญหา แสดงความเข้าใจของจุด A และ B คุยกัน ชอบ Quote ลุง Linus

สุดท้าย Algortihm มันการเอา Data Structure มาจัดการ Problem > Solution ตาม Domain ที่สนใจ ปิด Gap ได้จุดนึง ถ้าไม่ได้ไปหาทางใหม่ ถ้าได้ Output ของมันเป็น Deterministic / Non Deterministic ถ้ามันเป็นแบบหลักมันมีเรื่องของ Math ความน่าจะเปลี่ยนเข้ามาเกี่ยวข้องด้วย //หลบไม่พ้นจริงๆ

จริงๆมีหลาย Quote เลยนะ แต่จดไม่ทัน มี Repo ของ อจ Dave https://github.com/rawitat/gtypist_lessons ยิ่งมีเอไอที่ดีเท่าไหร่เรายิ่งต้องการอะไรครับ Empathizer / Problem-Solver / Communication
ปิดท้ายด้วย Quote นี้ และ

What is design part when we design an architecture?
Speaker Chakrit Riddhagni

📝When we have a problem with multiple solutions
พี่คริสได้ยกตัวอย่างง่ายๆ อยากได้บ้าน 4 ห้องนอน 2 ห้องน้ำ มีห้องครัว จะเห็นว่า Design ที่เป็นไปได้มีหลายแบบ Style หรูหรา / minimal / japanese
Software ก็เหมือนกัน จากโจทย์ที่ยกมา อันนี้เอา Tech Stack มาตอบได้หลายแบบ

อันนี้วางคร่าวๆได้หลายแบบเหมือนกัน
- Magento - เอา Tools ที่มีคนทำไว้แล้วใช้ได้จบทั้ง web
- หรือ ใช้ Redis (High scale) จริงๆเอา Kafka
- หรือ สุดท้าย Code แบบ Tier Layer นี้แหละ
- และมี Choice จุกจิที่ตามมากมาย เช่น Cloud ไหม
ดังนั้น Architectural design begins when you choose a solution และ Process Design มันจะเริ่มต่อเมื่อมี Solution ที่เป็นไปได้หลายๆอันเข้ามา และ เลือก Solution ที่ appropriate (เดี๋ยวจะมีขยายความต่ออีกที)
การที่เราไปหา Sample หลายๆ ที่มาตั้งต้นของเราเอง สิ่งที่เราต้องคิดต่อไป เหตุผลเบื่องหลังที่เค้าเลือก Stack แบบนั้น อาทิ เช่น Slack Supports Billions of Daily Messages / Robinhood ทำไมเลือกแบบนั้น เป็นต้น
Key Takeaway: We can only design when we can come up with multiple solutions
📝Human Decision Making ในเมื่อมีหลาย Solution ทำไม่ไม่เอามาเลยหละ
อันนี้ชอบตัวอย่าง แบบกินอะไรดี หรือ จะทานอาหารให้ได้ protein อย่างน้อย 80g ต้องทำยังไง สิ่งที่อยู่เบื่องหลังการตัดสินใจพวกนี้จะเรียกว่า Perference (bias)
- Perference/biases is crucial in decision making process
- ปกติแล้ว “Be rational (Logical ตรรกะ) and be unbiased” ดูมันขัดๆกับข้างบนใช่มะ
- แต่ถ้าเราเข้าใจทั้งสองส่วนนี้ Rational / Perference
กลับมาที่ Software จาก Req เดิม ถ้าเราเพิ่มบางคำลงไป เช่น
- High scale (Logical) + cost-effective (Perference) จะช่วยให้ตัด Choice ภาษาที่ใช้พัฒนาได้ระหว่าง Rust / Python
- ถ้าเพิ่ม ถ้าอยากให้ Team มี Collective Ownership (Perference) เราจะเลือก Arch ที่เหมือนสมกับ Enviroment / Team
Key Takeaway: Design work is essentially aligning preferences/bias
📝แล้ว Perference คือ อิหยัง ?
การจะตอบได้ ลองจากคำถามที่พี่คริสแนะนำ และคิดว่าใช้สมองส่วนไหน
- What color do you like? //Logical
- Given an integer array [3, 5, 7] What is the sum? //Perference
- What kind of customer you want to work with? //Perference
- Give two sorted list [2, 4, 6][1, 3, 5] combine two sorted lists into one sorted list //Logical
คำถามที่ได้ จะมี Logical / Perference ใช้สมองแต่ละส่วนมาตอบ
Key Takeaway: Use preference brain to design, use logical brain to figure out a solution
จาก Takeaway ที่เราเรียนมาทำให้ได้ตาม Business Value มันจะขัดกับ Perference ไหม ?
จริงแล้ว Perference มันทำให้เกิดเจ้า Business Value เช่น
- Strategy Quick wins vs Long term
- High Risk High Return vs Conservative (Low Risk)
- Branding อยากไปทาง Reliable / Creative
จากตัวอย่างมันทำเงินได้หมดนะ
📝How to find preferences ?

เอาง่ายๆ Trade off Slider เอามาเป็น Tools ใช้ตั้งต้น ให้เลือกมาคุยกับว่าที่มาของการเลือก มาจากไหน โดยอาจจะ
- ให้ลูกค้าไปเลือกเอง
- หรือ แกะจากการสัมภาษณ์ พูดคุยให้เค้าเล่าเรื่อง
- หรือ ผสมกัน
ตัวอย่าง - ต้องใช้สมองให้ถูกส่วนนะ จริงผมมองว่าเป็นการสื่อสารด้วยแหละ ถ้าไปคุยกับคนไม่ใช่ Non IT ไปถามแบบว่าช้านี่กี่ ms วัดยาก หรือ บอกว่าสนใจ isolation level ไหน เป็นต้น ใช้ Trade off Slider ช่วยบอก Scale ได้ และช่วยตัด Choice


สุดท้ายหลังคุยกัน เราจะได้ Artifacts บอกว่าทำไม เลือกตามนี้ แล้วสุดท้ายค่อยมาสรุปลงเป็นตัว Artitecture Decision Record
Key Takeaway: You can capture preferences using trade-offs slider
🚩สุดท้าย Design มัน คือ การเลือกการแก้ปัญหาที่มี Value สุดสุด เราสนใจมากกว่ากัน (Which problem really matters?) จากนั้นดู Solution ว่ามัน match กับ Problem ที่เราสนใจไหม
🚩ตอนนี้พวก AI ยังจัดการไม่ทำไม่ได้นะ problem มันควรทำก่อน เพราะ ?
SRE Deep Dive
Speaker Jirayut Nimsaeng
Monitoring / Obserablity / Site Reliability Engineer(SRE)
- Monitoring เก็บข้อมูลเยอะๆ แล้วมาไล่ดูเคสตรวจเกิดปัญหา
- Obserablity จากข้อมูลที่มี เรามาตั้งคำถามก่อนว่า อยากทราบอะไร เพื่อแก้อะไร แล้วใช้ข้อมูลอะไร ตอนนี้เราจะได้ Context
- SRE ผมเข้าใจว่าเป็น Implementation ของตัว DevSecOps ให่มองว่าเจ้า SRE คำนี้มาจาก Google เป็น Practices ที่ดี
SRE ทำให้ระบบของเรา Healthy โดยงานหลัก 50% Day to Day Operation อีก 50% Project ค่อยๆ Improve ลดสแต่ SRE มันไม่ได้เริ่มจาก 50% มันอาจจะเป็น Day to Day เต็ม 100% แล้วค่อยทำ Project มา Improve ลดเวลาส่วน Day to Day
Key SRE การทำ Reliability
เจ้า Reliability ต้องมีตัววัดที่ชัดเจน เข้าเว็บเร็ว เร็วเท่าไหร่ และรับประกันกับลูกค้ายังไง โดยมี Keyword SLO SLA และ SLI ต้องมากำหนด Design Reliablity
| Keyword | Description | Example |
|---|---|---|
| Service Level Objective (SLO) | เป้าหมาย เพื่อให้ทีมรู้ว่าควรจะรักษามาตรฐานไว้ที่ตรงไหน | 95% ส่วน Latency ของ Response ต้องน้อยกว่า 200ms |
| Service Level Indicator (SLI) | สูตร ที่เอามาวัด ตอนนี้ระบบดีแค่ไหน? | อันนี้จะเป็นวิธีการนับ นับจาก HTTP Response 200 |
| Service Level Agreement (SLA) | ข้อตกลง การรับประกันกับลูกค้า ถ้าไม่มี SLO > SLI แล้วไปทำ SLA เลยจะแปลก | 95% ส่วน Latency ของ Response ต้องน้อยกว่า 300ms |


100% Reliablity ไม่มีอยู่จริง ณ ตอนนี้น่าจะมี บ เดียวที่ยังไม่มีข่าวใหญ่ พี่เดียร์ บอกว่า netflix ยังไม่เจอล่มแบบ Global
ดังนั้นจะมีอีก Keyword Error Budget
Error Budget ระบบเราล่มได้เยอะแค่ไหน
- พวก 99.99 ซึ่งตัวเลขพวกนี้ส่งผลกับ Cost ที่ใช้รักษา เพิ่มที่นึงก็ x10 เท่าไป
- ช่วย Error Budget ที่เราเว้นไว้ เพื่อ Plan MA / HW Failure
- และช่วยที่เรามี Gap เสี่ยงเอา Release ใหม่ๆ ที่เปลี่ยนแปลงเยอะ เอาขึ้นได้ เป็นจุดที่ยอมรับได้ เพื่อให้เกิดความเร็วทาง Business
คิด SLO / SLI กันยังไง
เน้นวัด Reliablity ไม่ใช้ Business
✅ SLI = (Good Event / Valid Events ) x 100%
❌ SLI = (Buy Users / Total Users) x 100% อันน้ไม่ใช่นะ
วัดอะไรบ้าง

- อย่าวัดทุกหน้า วัดหน้าที่มีผลกับ Business เงินๆทองๆ อย่างพวกหน้า Help / Readme เอาไปวัดจริงมันจะแปลก (คหสต อันนี้ อาจจะเป็นเทคนิคผ่าน TOR ได้นะ)
เริ่มยังไง


- ถ้าตอนเริ่มต้น อาจจะเริ่มวัดจาก Availability / Latency จาก กับหน้าที่มีผลกับ Business Top3 ที่เลือกมา แล้วดู Flow System ที่เกี่ยวข้อง จากนั้นมาเขียน SLO > SLI
- จากนั้นค่อยมาทำ SLA
- จากนั้นค่อยขยายไปในส่วนอื่นๆ
AI เอามาใช้ได้นะ แต่ต้องตรวจได้นะ ว่า SLO ที่ลงมามันตอบ Business จริงไหม
นอกจากนี้บางที noise มี SLO มาช่วยลด Alert ที่ไม่จำเป็นได้ / ถ้ามี ตัววัดชัดเจน - SLO Dashboard ต้องมา ว่ามี Criteria วัดยังไง


แต่ถ้าเกิดเหตุไม่คาดฝัน Post mortem ถอดบทเรียน หาว่าเกิดจากรอะไร แล้ว แก้ปัญหายังไง ในระยะสั่นยาว ถ้าเริ่มต้นทำตาม 4 Step ด้านล่าง

The Craft of Software Engineering
Speaker AnuchitO Nong
ยุคนี้ Context Overload + Misconception + False Perspective ในหลายๆเรื่อง อย่าง AI แปบๆ Gen Code ได้
🚀 AI มันทำแค่ 1 service + User มันน้อยๆ มันทำงานได้นะ'
🚨ปัญหา
- คนเข้ามาเพิ่มขึ้น โดย DDOS
- หรือ ต้องมี API อื่นๆ ที่เราต้องรับ และส่งด้วย
- Workflow + UI รอบแรก 3 Click รอบ 2 ได้ 4 Click Flow ใหม่
User จะรู้สึกยังไง งานข้างหลัง Doc / MA ...
AI มันเหมาะกับ Single Process เหมาะกับการ POC
ปัญหามันอยู่ตอน Change / Integration ซึ่งตอนนี้ AI ยังทำไม่ได้
วิธีคิดของคนเราปกติแล้วมันเป็นLinear นะ
การที่เรา Prompt สร้าง App ขึ้นมา มันจะได้ส่วนนึงของระบบใหญ่ Feature ตัวอย่างที่คุณหน่องยกมา รถ กับชิ้นส่วนของรถคันนึง มันทำงานได้เหมือนกันไหม อันนี้แหละ Integration
อีกตัวอย่างที่ยกใน Talk เรื่องของถนนอันนี้ชอบนะ มี 3 ส่วน สีเทา 1 นาที จะผ่านได้ 100 คัน ส่วนสีเหลือง ไม่ว่าจะมีกี่คันมันใช้เวลา 1 นาทีเสมอ



- ที่นี่ ถ้ารถ 800 คัน Flow นี้มันจะได้ 17 นาที
- ซึ่งเรามองว่ามันข้างไป เลยถ้าถนนอ้อม แต่ไม่ว่าจะมีกี่คันมันใช้เวลา 11 นาทีเสมอ
- รถทั้ง 800 คัน มีจะไปทางไหนทางเดิม หรือลัด พอใช้งานจริง ปรากฏว่าใช้เวลา 19 นาที เพราะไม่รู้ Flow ว่าจะไปทางไหน
- แบบสุดท้ายตัดถนนส่วนสีเหลือง ไม่ว่าจะมีกี่คันมันใช้เวลา 1 นาทีออก พอทางเลือกลดลง Flow การไหลมันเป็น 50% สรุปใช้เวลาลดลงเหลือ 15 นาทีแทน
ปัญหา เวลามีระบบต่อกับเรื่อยๆ แล้วเราจะรู้ได้ว่ามันทำ Integrate Smooth มันไม่มีจุดที่ติดขัดแบบตัวอย่างของถนน มองลองมาเป็น Program ที่เราเขียน หรือ ลงไปมากกว่านั้น Problem-Solving ที่เราต้องหาแก้ปัญหาทืใช้ Cost ได้น้อยสุด
บางที อาจจะเจอว่าเอา AI มา Apply แล้ว บางทีงานเร็ว บางทีช้าลง แล้วทำไม
- เพราะไม่ได้คิดเพิ่มขึ้น หรือ เข้าใจสิ่งที่มันตอบกลับมา แล้ว Apply ใน รอบถัดๆไป ยังไง Fundamental สำคัญที่สุด เพราะได้รู้ How it work / Why การใช้ AI เราควรให้ AI มาสอนเรา และทำความเข้าใจเอ๊ะ เพื่อให้เกิด Skill ที่ตัวเราเอง
- พอเราเข้าใจแล้ว จากนั้นถอด practice / skill ที่เราคิดเอาเข้าไปใส่ใน AI ทำเหมือนที่เราทำ เหมือนเรา Onboard เด็กใหม่ ซึ่งเป็นสิ่งที่ต้องฝึกให้เกิดเป็นทักษะ รับปัญหาใหม่มาได้ มี AI แล้่ว ปัญหาใหม่มาเรื่อยๆอยู่ ถ้ามีเรา Set Skill ที่เตรียมไว้
สุดท้าย AI ยังต้องใช้เวลาอีกสักพัก เพื่อให้เกิดความเชื่อใจแบบยุคเปลี่ยนผ่านจาก A4 มาเป็นไฟล์ Digital หรือ ตัว Complier ที่เราไม่ต้องไปไล่การทำงานมันเอาตัว Build ไปใช้อย่างเดียว
TalkX: softskill for developer
Speaker Apipol Sukgler
ลองออกมาดูหัวข้อ และฟังแปบนึง ไม่แน่ใจว่าช่วงท้าย หรือป่าวนะ เลย Recap มานิดนึง
- งานต้องแบ่งซอยย่อยๆ ให้มี Progress คืบหน้า
- การหางานที่ดีที่สุด ไม่ต้องสัมภาษณ์ แต่ให้คนรู้จักเรา อย่างพี่ Somkiat cc รู้จากจาก Blog Git หรือสร้าง Connection
- Blog ทำไมถึงเขียนบล็อก
Beyond Redis Expire: Building a Custom Delay Queue
Speaker AnuchitO Nong
🚦Business Customer Follow Bot
ลูกค้าทัก > ตรวจเงื่อนไข > รอ xxx นาที > ให่ BOT ทำงาน
🚦First Design

- First Design Redis Key Space Notification แต่ใช้ไปสักพัก BOT Delay เกินจากเวลาที่ตั้งไว้ ส่งผล BOT ตอบเช้าลูกค้าไม่พอใจ เนื่องจาก Reqest เข้ามาเยอะ เข้ามาเยอะ
- Improve Redis 4 > 6 เค้ามี Change ปรับ Perf ในส่วนนี้ แต่ยังไม่ตอบโจทย์ ยังมี Delay อยู่
🚦Build you own solution - Delay Queue

สุดท้าย Build you own solution ทำตัว Delay Queue ส่ง job ที่เวลาการทำงาน เอาคิดมาจากพวก Game Score เรียงจากเวลาน้อย > มา ส่วนจะให้ทำอะไรยัด Call Back URL ที่กำนดไว้ใน Payload แล้วพอถึงเวลาให้ไปเรียก โดยมี architecture ตามนี้
- Delay Queue API
- GET POST PUT DELETE ข้อมูลจะเรียกตาม SoredSet เรียงตามเวลา
- ส่วน hash เอาไว้เก็บ payload callback url - Delay Queue Service
- process_due_timer() มาตรวจสอบของตาม ZRANGE ที่ตรงเงื่อนไข (Implement LUA) และยัดของที่ครบ Job + Payload เข้ามา ที่ใช้ LUA Script เพราะ Redis เปิดช่องให้เขียน และมี isolation ทีใ่ช้ได้ระดับนึง แต่ยังไม่ atomic - Delay Queue Consumer
- Execute Call Back
- จากนั้น Consume ดึงของฝากใน redis ไปทำงาน โดย exponential maxoff กำหนด max retry ไว้ ถ้าเกิน ก็แจ้งให้คนที่เกี่ยวข้องมาตรวจสอบ ผ่าน Sentry / Slack
🚦Key Take Away
- อย่าพึ่ง Tools มากไป ในที่นี้จะเป็นเคสของ Redis
- Build From Scratch ไม่ใช่สิ่งที่น่ากลัว แต่ต้องถึงจุดที่ควรทำ หรือ Scale ตาม Business จากนั้นทำความเข้าใจปัญหาและลงมือทำ
สำหรับผม OK ตั้งใจมาพัง เพราะเจอเคสคล้ายๆ Redis แต่สุดท้าย งานไม่เยอะใช้ PostgreSQL + pg_notify แทน
Software Evolution: The Complete Lifecycle
Speaker Karn Wong
ทางเลือก แต่ละอันที่เราเลือกมีผลกับการ Evolution ของ SW ตาม Biz ว่าทำไมแก้นิดเดียว หรือ แก้เยอะ หรือ ทุบทำใหม่เลย
💾Proof of Concept- POC
การ POC ทำได้จริงไหม ทั้ง Biz + Tech บางทีเราไม่ได้อยากลงทุนแบบ Production Scale ซึ่งมันจะกิน Cost เกินไป โดยช่วงนี้
- MVP(Minimum Viable Product) มี Feature เท่าที่จำเป็น
- Design ที่ไม่ Over Engineered การทำ HA Scale เป็นต้น เน้น Simple
- ยอมรับได้ว่ามี Tech Debts เพื่อเอาเวลาไปทำอย่างอื่นก่อน
💾POC > PROD จากของ Demo สู่ของที่ต้องใช้จริง เจ็บจริง
- Tech debts ต้องมาปรับ จุดไหนสำคัญ และไม่สำคัญ ถ้าไม่ทำตอนหลังเจ็บหนักไหม ต้องมาตกลงกัน
- เพื่อให้ได้เวลาจากของ Demo > พร้อมใช้จริง ปกติ 1-3 เดือนรวม Test
💾When Software Evolving
- มี Req ใหม่ แสดงว่าตัว SW ยัง Valid กับ Business มีคุณค่าอยู่ แต่ว่าการเปลี่ยนแปลงที่เกิดขึ้น เราทำยังไง ?
- มี Log การแก้ไข เปิด Ticket การแก้ไขที่ซ้อนๆมาเรื่อยๆ มันมี impact หรือ แก้ได้ช้าลง เพราะมาจาก Tech Debts ที่สะสมไว้ไหม
- ถึงจุดที่ Refactor (Yak Shaving - ถางออกให้หมด) ไหม เราจะกล้าปรับไหม ต้องมาตกลงกันอีกมีผลกับความช้า และ Quality ในอนาคต
💾If Not Refactor เรายอมรับได้
- ถ้ามันสะสมมานาน มันจะเกิดปัญหา Dev ท้อ เกิดการลาออก
- ทำให้ Knowledge ที่เก็บไว้ในรูปแบบของ Code ลำดับการทำงาน หายไป คนที่รู้ออกไปแล้ว
- และมันส่งผลกับ Speed Quality และกระทบไปรายได้ของ บ
ทางแก้ ต้องมาเพิ่มส่วน Code Review การทำ Automate / Linter มาช่วย
💾แต่สุดท้ายเมื่อเกิด เติบโต ต้องมีจุดที่ต้องลาจาก
- การลาจากเกิดจาก Business ที่ไม่ได้ไปต่อ
- หรือ มาจาก Tech ที่มันไปต่อได้ยาก เช่น Lib มันไม่ได้ทำต่อใน ARM Arch หรือ ใช้ท่ายากตอนไป Modern Arch ต้องทำ VM
✅จุดที่ต้องสนใจ ตอนทำ App ใช้ให้เหมาะสมกับ Use Case
- Storage Backend
- Disk
- Blob Storage พวก minio / S3
เลือกแบบไหนดูจากพวก latency / IOPS ถ้าเลือกผิด หรือ App มันไม่ยืดหยุ่นพอ ตอน Migrate มันมีท่าให้รอดได้แหละ แต่ต้องแลกกับ Overhead ที่ Map ซ้อนไปซ้อนมา
- Database Engine
- OLTP -Transaction / OLAP - Analytical / key-value /Document
- รวมถึงเคส Schema Migration ด้วยนะ เช่น Mongo เพิ่ม Field Record เก่ามันไม่มีด้วย ขา App ต้องทำยังไง ?
- Networking - CIDR Clash ?
- บน Cloud ถ้าทำตัว Landing Zone ไม่ดี ไปทำเอง จะเจอปัญหาว่า IP ชนคุยกันไม่ได้ หรือ ต้องยอมสร้าง Resource ใหม่
- Portability
- Solution ที่ใช้อยู่มี Vendor Lock ไหม พยายามไปแบบ Vendor Agnostic)
- ระบบตอนนี้ไป Container ได้ไหม
- เป็นไปได้ ควรคิดก่อน ตอนที่จาก POC > PROD
ถ้าเราไม่รู้ เป็นได้หาผู้เขี่ยวชาญในด้านนั้น เช่น Cloud Infra มาช่วยดู
เพราะ ทางที่เราเลือก ทุกอย่างล้วนมีค่าใช้จ่ายเงิน และเวลา
- ทั้งเคส Tech Debt ที่ยอมทิ้งไว้
- หรือ การ Refactor ในเวลาไหน
- และสุดท้ายต้อง Validate idea ให้เรียบร้อบก่อนทำ !!!
TalkX: Word.in.th
Speaker Manassarn Manoonchai

🔠 เวิดดิ้นเป็นเกม ที่คำจะเปลี่ยนจาก A > B ฝึกสมอง โดยมีเงื่อนไขของเกม คำที่แปลงระหว่าง A > B ต้องมีความหมายจิง หน้า > หนา ... > หลัง ถ้าใช้ Step น้อยสุด จะได้คะแนนเยอะ
🔠 Tech svelte / ts + / Levenshtein Distance / Test Idea TDD
🔠 ลองเข้าไปเล่นกันได้ครับ https://word.in.th/
TalkX: ถามลุง
Speaker Mahasak Pijittum/ Peerapat Asoktummarungsri/ Narudom Roongsiriwong/ ตาเล็ก วินโด้เก้าแปดเอสอี

📚Programmer ปรับตัวยุค AI ยังไง และ AI ในอนาคตจากนี้อีก 5 ปี
- เรื่องที่ AI ช่วยเขียน Code มากกว่า 50% อันนี้จริงนะ
- งานของ SW Eng ยังเหมือนเดิมนะ Problem-Solving โดยเครื่องที่มือที่ใช้ปรับเปลี่ยนไป ในตอนนี้จะเป็น AI Tools ต่างๆ - แก้ปัญหา > เลือก solution > implement มัน จากเดิมออก Task PRD (Requirement) ให้ Junior จะเป็น AI มาทำตาม Spec เราจะเป็นเหมือนพี่ตรวจงานน้อง AI
- ในอนาคตหลังจากนี้ Human In Loop ยังเหมือนเดิมนะ ถ้าปรับตัวต้องเข้าใจ Fundamental นอกจากงานที่ทำแล้ว จะเป็นตัว Tools ที่ใช้ และสื่อสารยังไงให้ AI มันมันชัดเจน Explicit ถ้าสั่งคนมัน implicit ให้น้องยังพอติต่างได้เอง
📚AI Agent ตัวไหนเทพสุด
- ไม่มีตัวที่เทพสุด แต่ต้องเอามาใช้ให้เหมาะกับ Use Case และ Enviroment ตัวเองทีม /การ maintain ณ เวลาและบริบทนั้นๆที่พบเจอ //เอาจริงคำถามนี่เปลี่ยน AI Agent เป็นคำอื่นตอบ Pattern นี้แหละ
- การจะ Compare ต้องตั้ง Criteria ที่ชัดเจน
📚สอนอาม่าใช้มือถือยังไง
- Damage Control เตรียมของให้ แต่ไม่ให้พวก Credential (User/Pass) แล้วเรามา Audit ตรวจ อารมณ์ผู้ปกครองดูเด็ก แต่กลับกัน ช่วยกันพวก Scammer ได้เยอะ อันไหนเสี่ยงก็ลบ Chat ทิ้ง
- ลด learning curve พวก App การเงิน / Line สอนพื้นฐาน ที่เหลือให้แกลองไปเรียนรู้ คุยกับเพื่อน
- แชร์เพิ่มเติมจาก ตาเล็ก วินโด้เก้าแปดเอสอี
📚หางานยังไงให้ได้งาน ?
- พื้นฐานต้องแน่จริงๆ และพวกการสัมภาษณ์นับว่าเป็น Skill พวกที่ไม่ได้คุยนานๆ ต้องฝึกนะ ไม่งั้นเราจะนำเสนอความสามารถตัวเองได้ไม่หมด
- ถามเพื่อตรวจ Knowledge ตามที่มีใน resume และ อาจจะถามลึกไปในสิ่งที่คนสัมภารณ์รู้ เพื่อวัดว่าเรารู้จริงนะ นอกจากนี้ อาจจะเจอบางคำถามที่อาจจะเอาคัดนิสัย ว่าเข้ากับทีมงานได้ไหมนะ
- ความแตกต่างของ ตปท กับ ไทย ตปท ลาออกไปเตรียมตัว LeetCode / Mock Interview บราๆ แต่คนไทยจะทำงานเดิมไปด้วย
📚มีประสบการณ์ที่งานพัง เพราะ AI ไหม ?
- ยังไม่เคยเจอ เจอแบบใช้ผิดแบบ
📚AI กับการ Design ระบบ ?
- key เราโยนความต้องการทั้งหมดให้ AI ไม่ได้ ตัว Context มันจะใหญ่มาก
- มอง AI เป็นการหา Option ให้เลือกได้ ดังนั้น ถ้าเรากำหนดจุด สงสัย แล้วถาม AI ไป มันจะเก่งตรงนี้ Fundamental ก็สำคัญสุดนะ
- ตอนนี้มีแนวคิด Multi Agent อีกมุมนึงเหมือนคนแหละ เอามาคอยเตือนกัน เผิ่อมีใครหลุด Context
- LLM ตอนนี้มันยังไม่ถึง AGI นะมันรู้เท่าที่รู้ รู้จากที่ Train
- Gartner บ Research ที่เดา Trend ได้แม่นมาอีก 4-5 ปี มันจะ mass จากเดิม LLM ซึ่งมีข้อจำกัด จะเป็นตัว Domain-Specific Language Models (DSLMs)
- นอกจากนี้ Keyword Deterministic Algorithm สำหรับ AI พวก ML บางอันที่คำตอบคงเส้นคงวา ส่วน NON (ถาม แต่ละรอบไม่เหมือนกัน) อีกอันส่วน Responsible AI เอา AI มาใช่เราต้องมีความรับผิดชอบด้วยตามวิชาชีพ
📚มีวิธีตรวจ AI ยังไงมันมาถูกต้องแน่นอน เพราะมีเคสที่เชื่อ AI
- ฝึกวิธีคิด และถามตัว AI ถึงที่มา และหัดเอ๊ะๆ อย่าเชื่อทั้งหมด
- ถ้าอยากลดเวลา เอา Model ที่เป็น Reasoning จะได้ลดเวลาในการตรวจสอบ
- สุดท้ายต้องเข้าใจ Use Case และ Limitation ของเครื่องมือ
📚การใช้ AI สำหรับ QA มียังไงบ้าง
- Code Review ตอน Push ให้ AI มา Review Code และวิเคราะห์ผลจาก CI
- มุม QA อาจจะเข้ามาตรวจที่ AI ทำ และเขียน Test เพิ่ม
- ใน ตปท ตัด QA ออกไปนะ แล้ว Shift ในส่วน Quality เข้ามาส่วน Dev หรือ ดันไปทาง Software Engineering In Test สุดท้าย Test เป็นหน้าที่ของทุกคนดัน Ownership Test ไปเป็นของทุก Role
- นอกจากนี้ อาจจะปรับส่วนของ Carreer ตัวจากเดิม Functional Test > Biz > Change Agent (คนผลักดันการเปลี่ยนแปลง ดัน Test เข้าไปทุก Role) และรู้ในส่วนอื่นๆ อย่าง infra เป็นต้น
- มีแนะนำ หนังสือ The leader who had no title
📚สะสมด้าน Discipline ยังไงให้มีความรับผิดชอบของวิชาชีพ
- มีความมุ่งมัน เลยเปิดการพยายามมา Code เพื่อทำ BOT Game นะ
- รู้ตัวเองด้วยว่าอยู่จุดไหน มาทำงานเพื่อให้ของดีที่สุด หรือ เพื่อหารายได้
- Work Hard แต่ต้อง Smart ด้วยนะ ยอมมีความเสี่ยงระดับนึง แต่เราได้เรียนรู้ Skill ใหม่ๆ
- อย่างหยุดเรียนรู้ เขียน Program + Problem Solving เพื่อ Refresh Skill update tech ใหม่ๆ
- เริ่มที่การอ่าน เอ๊ะ หา Fundamental ที่เกี่ยวข้องกับมัน
📚Maid Cafe - ความชอบส่วนบุคคล ไม่เขียนลง Blog นะ ถถถถ
Session นี้ฟังเพลินยาวจนจนเลยเวลาเลย ฮ่าๆ แต่คุ้มนะ ได้ฟังเบื้องหลังอะไรหลายๆอย่าง อย่างเมื่อก่อนตอนแรกไม่ค่อยมีงาน Tech Meetup พี่ Peerapat เลยลองมาจัด Java Meetup ในไทยยุคแรก เหมือนผมน่าจะได้ไปด้วยมั่ง มีเสื้อ THJUG แต่ใส่ไม่ได้แล้ว 555
Panel Discussion AI Shaping the Future timeless wisdom lasting forever
Speaker karn wong / Siriwat Kunaporn / Witthawin Sripheanpol / Krisada Vivek (Mod)
📚 ตอนนี้ AI เข้ามาทุก Step ของการพัฒนา SW อะไรที่เปลี่ยนไป และอะไรที่ยังคงอยู่เหมือนเดิม
- AI อย่างพวก Gemini ทำ Perference ให้นะ ถ้าเราถามบ่อยๆ แต่ถ้าเราถามแหวกไปเลย มันตอบแปลกๆ / ระวัง LLM Bias อาจจะแนะนำ React เพราะมี Code ให้ Train เยอะ
- งานด้าน Integration อันนี้ LLM จะหลุด ต่อข้ามระหว่าง System ไม่ได้ มัน Gen ได้ แต่มีโอกาสมโน งานเล็ก งานที่ทำซ้ำยังเหมาะกับส่วน LLM
- จากที่เราเน้น Review Code ในส่วน Structure หรือ Code ไม่สวย ตอนนี้จะไปเน้น Spec แล้ว Review ตัว Test
- ตัวที่ไม่เปลี่ยนเลย Mindset ในการคุม Quaity - สุดท้ายต้องมีคนมา Review + Optimize เพื่อให้เป็น Prod Grade
📚 Fundamental อย่าง Data Structure / System Design ยังจำเป็นไหม
- พอมีพื้นฐานจะช่วยให้เรา Prompt ได้ดีขึ้น แล้วเอ๊ะจากสิ่งที่ AI มันตอบ
- ช่วยตัด choice ได้นะว่า AI ถูกผิด
- Solution หลากหลาย อย่าง Tech Stack / Self Host / เน้น UX การเข้าใจ Fundamental เราจะได้ตอบคำถามว่าทำไมถึงเลือกของชุดนี้มาประกอบกัน แล้วเอาไป match กับโจทย์ constraint ที่ได้รับมา
📚 มีอะไรอยากแนะนำน้อง อะไร คือ timeless wisdom
- Fundamental ยังเป็นสิ่งที่สำคัญ การเรียนในมหาลัยจะเน้นภาพย่อยๆ กว่าจะเห็นภาพรวมจะเป็นปีที่สูงๆ ถามคนข้างๆก่อน AI ก็ได้นะ
- ฝึกการอธิบาย ชอบตัวอย่างช่างที่ทำตามสั่ง กับชางที่แย้ง และ Recommend เราตามความเหมาะสมของปัญหาได้ ดังนั้นเราเน้นการสื่อสาร และการรับฟังอีกฝ่าย
- การใช้ AI หรือ Lib หรือ Tools อย่างให้เอ๊ะ หรือ ดูข้างในของมัน จะได้พอตอบคำถามที่ทำไมมันทำได้ แบบพวก System Prompt หรือ เอาไปต่อยอด ไม่ต้องทำอะไรที่ซ้อนทับ
Blog ท่านอื่นๆ
- ความช้ำในใจ Developer - National Coding Day 2026 by Apipol Sukgler
- TalkX กับ session ถามลุง ที่งาน National Coding Day 2026 by MikkiPastel
- [Note] แบ่งปัน : AI as a Quality Partner หัวข้อที่ไปเล่าในงาน National Coding Day 2026 กับ สมาคมโปรแกรมเมอร์ไทย by Tan Kanteera Kongyuen
ปิดท้ายขอบคุณทีมงานทุกท่านที่ช่วยจัดงานดีๆแบบนี้ขึ้นมานะครับ ในงานมีบูธของ Sponser หลายเจ้าด้วย ที่สนใจตัว https://cortexai.studio/ มี AI + เข้ามาดูปัญหาว่าระบบเข้ามีปัญหา Perf ตรงไหน
ถ้าสนใจสรุป Meetup ลองเข้ามาใน Meetup Note/Share จะโยนให้ AI อ่านก็ได้ครับ เดือนที่แล้วจากจีนอ่านมากกว่าไทยอีกเลยคิดว่าน่าจะ AI
อ๋อเหมือนทาง สมค โปรแกรมมเมอร์ มีสำรวจตัว Thailand Developer / Data & AI Salary report ประจำปี 2025 ถ้าว่างๆลองไปกรอกได้นะ
และ Blog นี้ ผมไม่ได้จด Temp ลงใน Notion และใช้ตัว siyuan-note ถ้าในงานคนที่ถือ ThinkPad ไปรอบงานผมเองครับ ^__^
Reference
Discover more from naiwaen@DebuggingSoft
Subscribe to get the latest posts sent to your email.






