Agile Thailand 2026

BBL Journey towards AI-driven delivery

BBL ใช้ Agile delivery ตั้งแต่ปี 2019 เริ่มจาก Bualuang mBanking (launch 2020, >90% ของธุรกรรมผ่าน mBanking, ออกเวอร์ชันใหม่ทุก 2 เดือน) และขยาย Agile ไปโปรเจกต์อื่นๆ ในธนาคาร

การเตรียม scale AI adoption เน้น "educate คน" ตั้งแต่ผู้บริหารลงมา — ทีม delivery ใช้ AI coding assistant ดัน unit test coverage จาก 16.7% → 85.7% (เม.ย. 2025 – พ.ค. 2026) ส่วนพนักงานทั่วไปใช้ Tech Adoption Challenge ที่ทำต่อเนื่อง 6 seasons (971 คน, 20 divisions) ปีนี้ Season 6 ธีม "Powering the Future with Agentic AI"

ขั้นถัดไปคือ AI integration ทั้ง PDLC ด้วย Spec-Driven Development + human-in-the-loop: AI ร่าง PRD/user stories, gen plan จาก spec.md, ทำ test cases, มี QA sign-off — ถ้าจะแก้อะไร กลับไปแก้ที่ Spec ไม่แก้ code ตรงๆ ทั้งหมดอยู่ใต้กรอบ AI Risk Management Guidelines ของ ธปท. และการ redesign operating model (อ่านเพิ่ม: The Asian Banker)

ประโยคปิด: "Intelligence is free, judgement is priceless"

T-REX Sovereign AI Master Action Plan

นำเสนอแนวคิด Sovereign AI ของไทย — ระบบปิดแบบ Localized Sandbox ประมวลผลในประเทศ ใช้ข้อมูลชุมชนจาก 77 จังหวัด โดยชูจุดขายด้านอธิปไตยข้อมูล การควบคุม hallucination ด้วยขีดจำกัดทางสถิติ (ε ≤ 0.15%) และ Eco-Mode ประหยัดพลังงาน 60%

กระบวนการ 4 ขั้น: Ingest & Isolate → Math Core → Filter & Flag → Safe Output พร้อมเปิด Sandbox Simulator ให้ผู้เชี่ยวชาญทดสอบเจาะระบบ — ช่วงบ่ายผู้พูดแจกไฟล์ HTML ให้ผู้เข้าร่วมลองรัน stage-0/stage-1 ด้วยตนเอง

หมายเหตุ: สรุปจากสไลด์ของผู้พูด ตัวเลขและ claim ต่างๆ (เช่น "ปลอดภัย 100%") เป็นของผู้นำเสนอ

How we use AI in an Agile Team

ทีมสร้างรากฐาน Agile (XP + Scrum) ก่อน AI จะมา: ATDD, Test Strategy ตาม Fowler, Trunk-based, Feature Flags, TDD — และใช้เวลา 60% กับ Design / 40% กับ Development

พอ AI เข้ามา ทีมสร้าง tool ภายในชื่อ trust-me-bro-ai (ตั้งชื่อเสียดสีตรงๆ): AI เป็น "New Member in Team" ที่ต้อง install + learn context ของ repo ก่อน โดยมีโครง Tech-stack / Context / Work (requirements, scenarios, tasks, test data) ให้ AI ยึด

Work Tempo: 3 Engineers เขียน Spec, 1 Engineer คุม AI (Develop & Review) — หมุนเวียนกัน "No one Engineer take all" และทีมจงใจไม่ใช้ AI ใน Requirements Phase เพราะเป็นจุดที่ human context สำคัญที่สุด ต่อยอดเป็น A-Dapt + Agent Flow, SaaS Factory (XP-driven multi-skill agent framework 28 stages), UX Copilot และ QA assistant

ปิดท้าย: "It's not that engineering is dead, but rather that responsibility is changing."

Strategies that drove AI coding adoption to 95% in KBTG

North Star คือ 4 stages: Initiation (+10%) → Foundation Human-in-the-loop (+20%) → Transformation Human-over-the-loop (+40%) → Scale-up AI-driven delivery (+100%) — ธีมหลัก: "Technology selection is the first mile, behavior change is the real journey"

ปี 2025 เดิน 3 phases: Organic Adoption 7 เดือนได้แค่ 30% (adoption hit a ceiling — เจอ 2 barriers: First-Use Friction ของคน กับ Context Gap ของ AI) → Company-Wide Activation จัด event วันเดียว ใช้การแข่งขัน + peer pressure ดันเป็น 70% แบบ sustained (เขียนโค้ด 1 ล้านบรรทัดในวันเดียว) พร้อมรวม knowledge 447 applications / 14,000 interfaces เป็น Centralized Knowledge → Last Mile เปลี่ยนจาก encourage เป็น mandatory certification จนแตะ 95%

ปี 2026 ขยับสู่ Agentic AI: DevFlow Agent (launch พ.ค. 2026) — 97% ของทีมใช้, โค้ด 41.5 ล้านบรรทัด (+95%), 1,000+ tasks ที่ agents ทำเองใน background โดยมี Classification Agent แยกงาน autonomous vs human-led

บทเรียน 3 ข้อ: Core Team First · Different Stages, Different Strategies · Knowledge is King

Behind the Scene: AI Adoption + Extreme Programming

เล่าต่อจาก session ของ Nat ว่า XP (Test First, User Stories, SDD) + แผนภาพ A-Dapt ช่วยเรื่องการสื่อสารอย่างไร จนกลายเป็น internal tools: Canvas visualize workflow (react flows + Bruno + dbdiagram), Frontend + Mock API, และ Shelob ที่อ่าน microservice diagram จาก GitOps yaml แบบ deterministic (Ver 3 = Vibe + Spec Driven + ไม่ใส่ AI ใน app)

อ่านฉบับเต็มได้จาก chips ↗ Part 1 / ↗ Part 2 บนการ์ด

ใช้แต่ AI……………แล้วกูหละ!

เซสชันนี้ไม่ใช่เลกเชอร์ แต่คือการล้อมวงระบายความในใจของคนทำงานในยุคที่หันไปทางไหนก็มีแต่คำว่า AI

1. "ฮีโร่สายพรอมต์" กับกองขยะที่ซ่อนอยู่ — ใครหยิบ AI มาใช้ก่อนกลายเป็น Hero ประจำออฟฟิศ แต่สิ่งที่ต้องระวังที่สุดคือ Quality: พอ AI เสกงานง่าย "งานขยะ" ทะลักเข้าระบบ Reviewer แทนที่จะสบายกลับต้องตรวจละเอียดกว่าเดิม บทสรุปในห้อง: จะใช้ AI เก่งแค่ไหนก็ได้ แต่อย่าเพิ่มงานให้คนรีวิว และอย่าสร้างขยะทิ้งไว้ให้ทีมตามแก้

2. วิกฤตศรัทธา: เมื่อเรากลายเป็นแค่ "เครื่องจักรผลิตของ" — น้องคนหนึ่งแชร์ว่า "เริ่มรู้สึกหมดคุณค่าในตัวเอง... สะกิดสั่ง AI เพื่อให้ได้ของออกมาส่งตามสั่ง แต่ในใจกลับกลวงมาก" ทั้งห้องเงียบกริบ พี่คริสแชร์วิธีรับมือในมุมผู้นำ: ตั้งกฎกับตัวเองว่าจะไม่ชม AI ต่อหน้าทีม แต่จะชม "คนทำงาน" ชมไอเดียและการควบคุมของคนแทน — มนุษย์ผูกคุณค่าตัวเองกับงานที่ทำ (Mastery, Honor, Purpose ตาม Management 3.0) พอ AI เสกงานใน 10 วินาที กลไกความภูมิใจถูก "แฮ็ก" ไป

3. การวิ่งไล่ตามที่ไม่มีวันสิ้นสุด — "วงการพัฒนาตัวเอง มันมีเส้นชัยไหมวะ?" พี่ต่อตอบว่า คีย์เวิร์ดคือพัฒนาตัวเองโดยไม่วิ่งแข่งกับ AI และไม่แข่งกับคนอื่น — ทำเพื่อขยายศักยภาพของตัวเราเอง เส้นทางจะไม่ใช่การวิ่งหนีสัตว์ร้าย แต่เป็นการเติบโต

4. ความจริงทุนนิยม + 4 ทักษะทองคำ — ในสมการธุรกิจคำตอบสั้นมาก: ความอยู่รอด กำไร การส่งมอบ ถ้าตัวเลขคุ้มเขาก็เปลี่ยน สิ่งที่มนุษย์ใช้ชนะ: Fundamentals แน่น · Deep Understanding · Application · Critical Thinking ตรวจสอบสิ่งที่ AI พ่นออกมาได้

ปิดท้าย: อนาคตจะเป็น Quantum หรือ AI+Robot ก็ไม่มีใครตอบได้ 100% — สิ่งที่ทำได้ดีที่สุดคือกอดคอพยุงจิตใจกันไป เรียนรู้เท่าที่ไหว และอยู่รอดไปด้วยกัน

What not to do in AI Adoption, please please

"อันนี้ผมฝากนิดนึงนะครับ เห็นในงานหลายท่านพยายามผลักดันองค์กรไปสู่ระบบ multi-agent ว่าเป็นแนวทางข้างหน้า เลยอยากฝากเรื่องนี้ไว้ครับ

เปเปอร์นี้กับบทความ (ซึ่งตรงกับประสบการณ์ส่วนตัวของผม) พบว่าตั้งแต่โมเดลรับ context ได้มากขึ้น ไม่พบความแตกต่างในประสิทธิภาพ และไม่ได้มีหลักฐานประจักษ์ว่า multi-agent system จะดีกว่า single-agent system หลายๆ ครั้ง single agent ดีกว่าเยอะก็มีครับ

Multi agent ดีกว่าหรือแย่กว่า single agent นี่ it depends มากๆ ครับว่าทำอะไร และโมเดลตอนนี้เป็นแบบไหน

ส่วนตัวถ้าเอาแบบกว้างๆ นะ ในแต่ละงานหรือทีม ผมจะแนะนำว่าควรทำ evaluation ก่อน แล้วจะรู้ว่างานนี้ ทีมประมาณนี้ ลักษณะแบบนี้ ใช้ multi agent ดีกว่าหรือแย่กว่า single agent

มีเครื่องมือแบบ skill eval ในกลุ่ม Claude Code ก็ใช้ได้ หรือจริงๆ สร้างเองก็ไม่ยากมากครับ

และถ้าลงลึกไปหน่อย อาจจะต้องเข้าใจธรรมชาติของงาน ว่างานไหนแตก context ออกไปแล้วดีกว่า งานนี้ถึงตรงจุดนี้มันจะ context rot หรือยังครับ"

อ้างอิงที่คุณคริสแนบมา:
→ arXiv 2505.18286 (paper, PDF)
→ Single-Agent vs Multi-Agent Systems: When Coordination Helps, Hurts, and Pays Off (Medium)

When Agile Meets Agents: How Agile and AI Redefine the Way of Work

ยุคแรกเราใช้ Generative AI ตอบคำถามหรือสรุปเอกสาร ตอนนี้เข้าสู่ยุค Agentic AI ที่ต่างกันตรง "ลงมือทำได้" เปรียบเหมือนช่วงเปลี่ยนจากรถม้าเป็นรถยนต์ — ตัวโมเดลอาจไม่สำคัญเท่าไรเพราะเก่งขึ้นเรื่อยๆ แต่ Operating Model และ workflow คือสิ่งที่ต้องออกแบบ

การแบ่งงานคนกับ AI: AI Led สำหรับ research และ draft · AI + Human สำหรับ test · Human Led สำหรับ decide, trust, lead เพราะคนคือผู้รับผิดชอบผลลัพธ์

Be quick but don't hurry — ถ้าไม่มี feedback จะได้ waste, ถ้าไม่มี customer value จะเคลื่อนไหวแบบไร้ทิศทาง และถ้าไม่มีสิทธิ์ตัดสินใจที่ชัดเจน คนจะกลายเป็นแค่ตรายาง AI ตรวจงานกันเองได้ แต่ไม่เข้าใจบริบทโดยเฉพาะเชิงวัฒนธรรม

สมการหลัก: AI = Execution (scale, speed, consistency) · Agile = การรับ feedback และปรับตัว · Human = Judgement คนต้องขยับจากผู้ผลิต output ไปเป็น Verify → Frame → Decide → Accountability

กรอบที่ใช้ได้กับทุกคน: Frame ตีกรอบปัญหาให้ถูก · Judge ตัดสินในสถานการณ์ไม่แน่นอนที่ต้องใช้อารมณ์และ empathy · Own รับผิดชอบ เพราะ AI ยังรับผิดชอบทางกฎหมายแทนเราไม่ได้ ผู้นำจึงต้อง redesign operating model พร้อมวาง governance และ learning path

Multiple AI Teams Orchestration in Production

ความท้าทายที่ผู้พูดลองทำ: ให้ AI เข้าไปแทนทุกตำแหน่งของ full-stack dev แล้วพบว่าทำได้จริง — ภายใน 6 เดือนสร้างระบบใช้เองหลายตัว เช่น ระบบ Zoom ของตัวเอง (เพราะ subscription สำหรับ 3,000 user แพงเกิน), ระบบร้านขายยาหลายภาษา, ระบบจัดเวรพยาบาลฟอกไตที่ต้องจับคู่ความหนักของคนไข้กับ skill พยาบาล และระบบบัญชีสหกรณ์

เส้นทางที่เดินผ่าน: Vibe Coding (มีปัญหาเรื่อง accountability) → Spec-Driven Development ช่วยได้ระดับหนึ่งแต่ AI ยังเดา ทำแต่ละรอบไม่เหมือนเดิม → จึงต้องใช้ Acceptance Test เป็นตัวคุม เพราะ unit test ผ่านแต่พังตอน UI ได้ ตอนนี้เอา UAT spec ให้ AI ทำ e2e ด้วย Playwright

เคล็ดลับที่แชร์ในวง: เลี้ยง AI ด้วย knowledge และ context ของ product ให้ชัด · แบ่ง role ของ agent แต่ละตัวเหมือนคนเพื่อลด switching cost · งานที่คำนวณแน่นอนให้เขียนเป็น script แทนปล่อยให้ AI เดา · ถ้า plan สำคัญให้หลายโมเดลช่วยกัน refine 2–3 รอบ

สำหรับเด็กจบใหม่: หาจุดแข็งและคุณค่าของตัวเอง มี fundamental แน่น เสริม soft skill และ critical thinking — คนที่ใช้ AI เก่งและพลาดมาเยอะเข้าใจงานได้ดีกว่าคนที่ไม่เคยลงมือทำ

True Agility: Why AI Changes Everything

Agile ในยุค AI ยืนบนสามเสา: Highly Collaborative เลิกทำงานแบบ silo · Customer First รู้ว่างานของเรา trace กลับไปหาลูกค้าอย่างไร · Speed is Value เร็วและวางแผนรับความไม่แน่นอน

ทีมใช้ TDD และ Spec-Driven Development เป็นตัวช่วย พร้อมปรับกรอบ 5R จากหนังสือ Agility Shift มาใช้ — Resilient, Responsive, Reflective, Resourceful, Relevant

AI ทำให้คนร่วมมือกันมากขึ้น เพราะมันกำจัดงานน่าเบื่อและลด friction ที่เคยทำให้ dev ไม่อยากทำ test, peer review หรือเอกสารส่งต่อ — เมื่อ AI รับ execution ไป คนจึงมีเวลาไปอยู่กับ empathy ที่ซับซ้อน, critical thinking, judgement และ strategic oversight

ข้อสังเกตปิดท้าย: องค์กรกำลังเคลื่อนไปสู่ skill-based organization ที่เส้นแบ่งตำแหน่งเบลอลง และถ้าคนไม่ขยับขึ้นไปเป็นผู้กำกับ AI ตัวเราเองจะกลายเป็นคอขวด

Building Creative Desktop Applications with Claude Code: Slop or Not

เล่าการสร้าง Ymir แอปโอเพนซอร์สสำหรับสร้าง world/terrain 3D (ภูเขา น้ำ หมอก) สำหรับ game developer export เข้า Unreal Engine, Blender หรือ Unity ได้ เขียนด้วย Rust + GPU

คำถามหลักคือทำอย่างไรให้ vibe coding ไม่กลายเป็น AI slop (ดูดีแต่ใช้จริงไม่ได้) คำตอบคือวินัย: ใช้ agent เดียวไม่ orchestrate, มีไฟล์ claude.md กำหนดข้อตกลง, Definition of Done ชัดเจน (test/clippy/fmt ต้องเขียวหมด), spec มาก่อนแล้วย่อยเป็น issue ใน GitHub — ถ้าไม่มี issue ให้ Claude ปฏิเสธงาน และมีคน judge ทุกขั้นตอน

ที่น่าสนใจคือ แอปสร้างด้วย AI แต่ไม่มี AI อยู่ในตัวแอป — เน้น deterministic ล้วน แยก logic กับ ui/gpu เพื่อเทสได้สะดวก

Testing strategy สามชั้น: test ทุก node (30+ nodes) · Golden Test ใช้ hash ผลลัพธ์จับความเปลี่ยนแปลงระดับพิกเซลที่ตามองไม่เห็น · Property Test สุ่ม input จำนวนมากเพื่อหา edge case พร้อมคุม technical debt ด้วย Rust compiler, Clippy และ fmt

บทสรุปที่ตรงธีมงาน: Agile ยังใช้ได้ดี ไม่ต้องสร้าง methodology ใหม่ มันคือสิ่งที่กันไม่ให้เกิด AI slop — และในโฟลว์แบบนี้ คนกลายเป็น bottleneck

Agility ในสนามแผน AI ชาติ

บริบท — Field notes จากการร่างแผนปฏิบัติการเพื่อการพัฒนาระบบนิเวศ AI แห่งชาติ พ.ศ. 2570–2575 (แผนระดับ 3 · 4 ยุทธศาสตร์ EQUIP · IGNITE · GROW · GOVERN · 10 กลยุทธ์) เป้าหมายคือขยับประเทศจาก model taker → model maker

ทำไมต้องเร่ง — AI adoption ขององค์กรไทยอยู่ที่ 17.8% (2024) ประชากรวัยทำงานใช้จริง 12.4% เทียบเวียดนาม 23.5% และสิงคโปร์ 60.9% แม้ไทยจะโตเร็วเป็นอันดับ 2 ของโลกก็ตาม (Oxford GARI อันดับ 34, IMD อันดับ 38) และเหตุการณ์ 12 มิ.ย. 2026 ที่โมเดล frontier ถูกสั่งปิดข้ามคืน คือเหตุผลเรื่อง sovereignty ที่จับต้องได้

สิ่งที่ work — Agile ที่เกิดขึ้นโดยไม่ได้เรียกชื่อ

1. Iterate ที่ระดับ artifact — แม้แต่ชื่อแผนยังผ่านการแก้ 3 รอบ (emergent design)
2. Prototype ด้วยภาพก่อนลงทุนเขียนเอกสาร — ภาพคือ "working software" ของงานนโยบาย
3. ประชุมกรรมการ = timebox ตามธรรมชาติ ทุกวาระบังคับให้มี increment ที่ demo ได้

สิ่งที่ตึง — Agile ที่อยู่ในกรอบ waterfall iterate ได้แค่ก่อนถึง gate · bus factor = 1 · มี feedback แต่ไม่มี retrospective เชิงระบบ

เคส IGNITE — ออกแบบ working group แบบ stream-aligned โดยยึดหลัก delegated outcome ≠ delegated task และเป็น network ไม่ใช่ hub-and-spoke

คำถามเปิดถึง community
1. leading indicators อะไรที่ไม่ต้องรอ 3 ปีถึงจะรู้ผล
2. จะกันไม่ให้ศูนย์กลางกลายเป็นคอขวดอนุมัติได้อย่างไร (align ≠ authorize)
3. ritual แบบไหนที่ทำให้ peer sync เกิดขึ้นจริง
4. เมื่อ thematic ชนกับ sector ใครตัดสิน — ข้อเสนอคือ thematic กำหนด minimum standard แล้วให้ sector เลือกวิธี

ปิดท้าย — แผนที่ agile ไม่ใช่แผนที่ "เสร็จ" แต่คือแผนที่ถูกออกแบบให้ "เรียนรู้" ได้ และเป็นการชวน community มาร่วมสร้าง ไม่ใช่แค่เป็นผู้ชม

Better Quality with AI: เมื่อ QA เอา AI มาช่วยทำงาน เค้าทำยังไงนะ

ประสบการณ์จริงของ QA ที่นำ AI เข้ามาอยู่ในเนื้องานคุณภาพ ตั้งแต่การวิเคราะห์ requirement ไปจนถึงการออกแบบการทดสอบ — จุดเด่นที่จับต้องได้คือ "น้องบีคิว ผึ้งน้อยวิเคราะห์ Requirements" Custom GPT ที่ผู้พูดสร้างขึ้นเพื่อช่วย QA ตรวจความครบถ้วนของ requirement ก่อนเริ่มเขียน test (ลองใช้ได้จากปุ่ม ↗ MyGPT บนการ์ด)

อ่านฉบับเต็มพร้อมตัวอย่างการใช้งานได้ที่ ↗ Blog แทน

Real Case: Agile Transformation Upside Down — จาก Tools สู่ Mindset

เคสจริงของการทำ agile transformation แบบ "กลับหัว" — แทนที่จะเริ่มจากปรับ mindset แล้วค่อยหาเครื่องมือตามตำรา ทีมนี้เริ่มจาก Tools ก่อน แล้วให้ mindset ตามมา จากการได้ลงมือใช้จริง และเมื่อรากฐานติดแล้ว AI จึงเข้ามาต่อยอดเป็นลำดับถัดไป (AI after that)

เรื่องเต็มพร้อมรายละเอียดของแต่ละช่วงอยู่ที่ ↗ Blog WarM

Blockchain 4.0, B2B2B DAO และวิศวกรรมโทเคน

หัวข้อนอกสาย AI หนึ่งเดียวของบอร์ด — ว่าด้วย Blockchain ยุค 4.0, โมเดล B2B2B DAO และการทำ วิศวกรรมโทเคน (Token Engineering) โดยยกกรณีการประยุกต์ระดับ TRL3 กับอุตสาหกรรมโรงแรม

รายละเอียดเต็มอยู่ในสไลด์ (ปุ่ม 📊 Slides)

What Not to Do in AI Adoption / AI Transformation

รวมความเข้าใจผิดที่เจอบ่อยเวลาองค์กรทำ AI adoption:

1. Over-producing Artifacts — หลายที่วัดความสำเร็จด้วยจำนวน (stories, lines of code, merge requests) แต่ของที่ AI เสกมาเยอะๆ มักไม่รู้ทำไปเพื่ออะไรและหาไม่เจอทีหลัง ควรวัด Quality มากกว่า Quantity เช่น rework จากความเข้าใจผิด, ความยากง่ายที่พนักงานใหม่ onboard ด้วยเอกสารเหล่านั้น — ตัวเลขจำนวนใช้วัด "อัตราการ adopt" ได้ แต่อย่าเอามาวัด productivity

2. Prompt ละเอียด = ดี? — ถูกแค่บางส่วน ยัดทุกอย่างเข้าไปทีเดียว AI จะเบลอเพราะ context rot ทางแก้คือป้อนทีละนิด (bottom-up) และทำ evaluation วัดผล

3. ใช้ SDD โดยไม่เข้าใจ — Spec-Driven Development มี 3 โหมด: Spec First (ทำแล้วทิ้ง เชื่อ code), Spec Anchored (แก้แล้ว sync ทั้งคู่), Spec as Source (gen code ใหม่จาก spec ทุกรอบ — เปลือง token และ commit ใหญ่) ต้องตอบให้ได้ก่อนว่าใครดูแล spec และอะไรคือ source of truth

4. เอา AI automation มาก่อน test automation — บริษัทที่เคลมว่า AI agent ลดงานได้จริง เบื้องหลังมี automated test + coverage สูงอยู่แล้ว ถ้าไม่มี ของที่ได้จะเป็น waste ให้ QA ตรวจ fail วนกลับมาแก้ ใช้ DORA metrics (Change Failure Rate, Rework Rate) ช่วยส่องได้

5. Tokenmaxing — จำนวน token วัดได้แค่ adoption ไม่ใช่ productivity · 6. สื่อสารผิดมุม — เหมือนคำว่า Agile ที่ไม่ได้แปลว่าเร็วขึ้น AI ก็เช่นกัน เล่ามุม "ชีวิตง่ายขึ้นยังไง" ลดแรงต้านได้ดีกว่า · 7. Cost — ราคา AI เปลี่ยนเร็วมาก เลือก tool ที่เข้ามือทีมจริงสำคัญกว่าถูกสุด

Leading Change ในยุค AI — AI พร้อม… แล้วองค์กรเราพร้อมหรือยัง?

จุดตั้งต้น — ช่วงเช้าของงานมีหลาย session พูดถึง AI ในมุม Technology ทั้ง tools, Agentic AI, use cases และแนวทางนำไปใช้ ซึ่งทำให้เห็นว่า AI เปลี่ยนวิธีทำงานเร็วแค่ไหน แต่คำถามที่ session นี้ชวนคุยต่อคือ ถ้า AI พร้อมแล้ว… องค์กรเราพร้อมหรือยัง? เพราะต่อให้มี AI เก่งที่สุด ถ้าคนยังไม่พร้อมเปลี่ยน ผลลัพธ์ที่องค์กรคาดหวังก็ไม่เกิด

1. เริ่มจากให้ทุกคน "เห็น" ก่อน — Stand If…
ไม่เปิดด้วยการอธิบายว่า AI Transformation คืออะไร แต่ชวนลุกขึ้นยืนถ้า AI ทำให้งานเร็วขึ้น · ถ้า AI กำลังเปลี่ยนวิธีทำงานของคุณ · ถ้าคุณต้องช่วยทีมหรือคนรอบตัวเริ่มใช้ AI — เพียงไม่กี่คำถาม ทั้งห้องแทบยืนกันหมดโดยยังไม่ทันเปิดเนื้อหาหลัก ทุกคนเห็นภาพเดียวกันทันทีว่า AI ไม่ใช่เรื่องของฝ่าย IT อีกต่อไป

2. Co-Create Vision
คำถาม: "ภาพความสำเร็จขององค์กรและตัวเรา เมื่อ AI กลายเป็นส่วนหนึ่งของการทำงาน จะหน้าตาเป็นอย่างไร?" ให้แต่ละกลุ่มวาดภาพและเลือกสิ่งสำคัญที่สุดภายใน 15 นาที ภาพที่ถูกโหวตมากที่สุดคือ Growth · Happy People · Human + AI Working Together — ไม่มีใครบอกว่าคำตอบที่ถูกคืออะไร นี่จึงไม่ใช่แค่การสร้าง Vision แต่คือ Collective Ownership เมื่อคนรู้สึกว่า "นี่คืออนาคตที่เราอยากเห็น" เขาจะไม่ได้แค่ยอมรับการเปลี่ยนแปลง แต่อยากเป็นส่วนหนึ่งของมัน

3. หน้าที่ของ Change Leader
ไม่ใช่คนที่ผลักให้ทุกคนเปลี่ยน แต่คือคนที่เชื่อม "ความจริงของตอนนี้" กับ "ความเป็นไปได้ของวันข้างหน้า" — เข้าใจก่อนว่าคนกำลังกังวลอะไร ติดอะไร กลัวอะไร แล้วจึงช่วยให้เห็นว่าอนาคตที่คุยกันเป็นไปได้จริง

4. Psychological Safety — การเปลี่ยนแปลงไม่ได้ยากที่ AI เสมอไป
หลังกิจกรรมกลุ่ม บทสนทนาเรื่องนี้เกิดขึ้นเองอย่างเป็นธรรมชาติเกินคาด ทั้งมุมผู้นำ สมาชิกทีม คนที่นำการเปลี่ยนแปลง และคนที่ได้รับผลกระทบ พอคนหนึ่งเริ่มเล่า อีกหลายคนก็เชื่อมโยงกับประสบการณ์ตัวเอง จากนั้นใช้ Stand If… อีกครั้งว่า "ยืนขึ้นถ้าคิดว่า Psychological Safety คือการที่ทุกคนเห็นด้วยกัน" หลายคนยืน แล้วจึงเฉลยว่า
Psychological Safety ไม่ใช่ Everyone Agrees แต่คือ People Dare to Disagree
คือที่ที่คนกล้าคิดต่าง กล้าถาม กล้าพูดว่า "ไม่รู้" และกล้าลองสิ่งใหม่ เพราะนวัตกรรมไม่ได้เกิดจากการที่ทุกคนคิดเหมือนกัน แต่เกิดจากการที่ทุกคนกล้าแลกเปลี่ยนความต่างอย่างปลอดภัย

5. ปิดท้าย — Pair Share: STOP / START
จับคู่คุยกันว่าวันนี้จะ STOP อะไร และจะ START อะไร เพราะการเรียนรู้มีความหมายมากขึ้นเมื่อเชื่อมกับการลงมือทำจริง

สิ่งที่อยากฝากไว้ — ตลอด session แทบไม่ได้พูดถึง prompt ไม่ได้สอน AI tool ไม่ได้บอกว่า platform ไหนดีที่สุด เพราะ AI Transformation ไม่ใช่แค่เรื่อง Technology แต่คือการสร้างสภาพแวดล้อมที่ทำให้ผู้คนเห็นภาพอนาคตร่วมกัน รู้สึกเป็นเจ้าของการเปลี่ยนแปลง กล้าถาม กล้าลอง และกล้าเรียนรู้ไปด้วยกัน

AI ไม่ได้เปลี่ยนองค์กร — คนต่างหาก ที่จะพาองค์กรเปลี่ยนไปพร้อมกับ AI