Salesforce Agentic Engineering: เมื่อ AI ไม่ได้ช่วยเขียนโค้ด แต่เริ่มรัน SDLC

Salesforce เพิ่งเผยแพร่บทความชื่อ “How Salesforce Engineering Became Truly Agentic”

ถ้าอ่านเร็ว ๆ อาจเห็นเป็นอีกข่าวหนึ่งว่าองค์กรใหญ่ใช้ Claude Code แล้ว productivity เพิ่ม

แต่ผมว่าเรื่องนี้น่าสนใจกว่านั้นครับ

เพราะ Salesforce ไม่ได้เล่าแค่ adoption ของ AI coding tool เขากำลังเล่าว่า engineering organization เปลี่ยนจาก copilot usage ไปเป็น agentic SDLC ได้อย่างไร

พูดง่าย ๆ:

จากเดิม AI ช่วยมนุษย์เขียนโค้ด กลายเป็น agent เข้ามาถือส่วนหนึ่งของ workflow software delivery จริง ๆ

เขียนโค้ด รีวิว PR สร้าง test อัปเดตเอกสาร ช่วย deploy ประสานงานที่เคยต้อง handoff กันหลายรอบ

นี่คือคนละเลเยอร์กับ autocomplete ครับ

1) เกิดอะไรขึ้น

Salesforce บอกว่าไม่กี่เดือนก่อน เขาเพิ่งผ่าน milestone สำคัญคือทำให้วิศวกรใช้งาน AI เกิน 90% adoption

แต่ adoption ไม่ใช่เส้นชัย

หลังจากนั้น Salesforce Engineering เลือกทำสิ่งที่แรงกว่าเดิม:

• standardize Claude Code เป็น primary AI agent tool สำหรับวิศวกร
• rollout ให้ engineers ทั้งองค์กร
• remove token limits เพื่อลด friction
• วาง governance, measurement, workflow และ guardrails ประกอบกัน

ผลที่เขารายงานจาก April 2026 เทียบกับ April 2025 คือ:

• work items completed per developer เพิ่ม 50.8%
• PRs merged per developer เพิ่ม 79%
• Effective Output เพิ่ม 151.3%
• total incidents ลดลง 5% แม้ PR เพิ่มขึ้น

ตัวเลขพวกนี้ต้องอ่านแบบระวังนะครับ

นี่คือตัวเลขภายในของ Salesforce ไม่ใช่ benchmark สากลว่าใครใช้ Claude Code แล้วจะได้ผลแบบเดียวกัน

แต่ในฐานะ signal มันแรงมาก เพราะเขาวัด output กับ quality คู่กัน

หลายองค์กรชอบวัดแค่ “เขียนได้เร็วขึ้นไหม” Salesforce พยายามวัดว่า “ของที่ส่งออกไปมีคุณค่าจริงไหม และ quality พังไหม”

นี่คือจุดสำคัญ

AI productivity ที่ไม่มี quality telemetry คือ vanity metric

2) ตัวอย่างที่ทำให้เรื่องนี้ไม่ใช่แค่ hype

บทความยกตัวอย่างทีม product ที่ต้อง migrate 33 API endpoints ไปสู่ cloud-native architecture ใหม่

ถ้าทำแบบเดิม Salesforce ประเมินว่าจะกินแรงประมาณ 231 person-days หรือเฉลี่ย 7 วันต่อ API

งานแบบนี้ไม่ได้ยากเพราะเขียนโค้ดไม่ได้ แต่มันเหนื่อยเพราะมีงานซ้ำเยอะมาก:

• manual schema mapping
• manual testing
• manual documentation
• review หลายรอบ
• coordination ระหว่างหลายส่วน

ทีมนี้ทำจบใน 13 วัน Salesforce เรียกว่าเร็วขึ้น 18 เท่า

วิธีที่เขาทำไม่ใช่ prompt เดียวแล้วรอปาฏิหาริย์

เขาสร้าง rule-based framework โดยใช้ Claude เอา markdown files รวมกับ reference implementations มาเป็นมาตรฐานให้ agent ทำงาน

ทุกครั้งที่มี PR feedback เขาเอา feedback นั้นกลับไปปรับ rule set ทำให้รอบต่อไป output ดีขึ้น

เขาปล่อย autonomous LLM loops ให้ทำ build, fix, validate โดยไม่ต้องรอมือคนทุกขั้น และ parallelize migration ใน isolated environments เพื่อสร้างหลาย PR พร้อมกัน

ผลคือ 33 endpoints, 5 PRs PR ใหญ่สุดส่ง 21 endpoints พร้อม 100% test coverage

บทเรียนตรงนี้ชัดมากครับ

ที่เวิร์กไม่ใช่เพราะ agent เก่งลอย ๆ แต่เพราะ workflow ถูกออกแบบให้ agent ทำงานได้:

• มี rule
• มี reference
• มี environment แยก
• มี feedback loop
• มี validation
• มี PR เป็น artifact
• มี test coverage เป็น proof

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

3) Agentic engineering ไม่ใช่ prompt engineering

คำว่า agentic ถูกใช้เยอะจนเริ่มเบลอ

แต่ในเคส Salesforce ผมว่ามีความหมายค่อนข้างชัด:

AI ไม่ได้แค่รอคำสั่งทีละ prompt AI ถูกใส่เข้าไปในระบบทำงานที่มี context, tools, rules, review, deployment, telemetry และ feedback loop

Salesforce พูดถึง Claude Code skills เป็น artifact ใหม่ของทีม engineering

skills เหล่านี้ไม่ได้เป็น prompt สวย ๆ แต่เป็น reusable capabilities ที่ encode สิ่งที่ทีมต้องใช้ซ้ำ เช่น:

• team context
• naming conventions
• workflow patterns
• Salesforce-specific coding tasks
• วิธีทำงานที่ผ่านการพิสูจน์แล้ว

เขายังพูดถึง AI Expert Suite และ Salesforce Foundation Plugins เป็น library ภายในที่ให้ developer มีพื้นฐานร่วมกัน

นี่สำคัญมาก

เพราะถ้าแต่ละคน prompt เอง เก่งเอง เก็บเทคนิคเอง องค์กรจะได้ productivity แบบกระจาย ไม่ได้ compounding

แต่ถ้าสิ่งที่เวิร์กถูกเก็บเป็น skill และ shared library ความรู้จะเริ่ม compound ระหว่างทีม

ในภาษาธุรกิจไทย:

อย่าปล่อยให้ AI knowledge อยู่ในหัวคนเก่งคนเดียว ทำให้มันกลายเป็น SOP, template, skill, playbook, checklist, context file ที่ทีมใช้ซ้ำได้

4) Subagents เปลี่ยนวิธีแตกงาน

Salesforce ยังพูดถึง subagents และ agent teams

ความหมายคือ agent ที่ scope ชัด ทำงานย่อยใน workstream หนึ่งของงานใหญ่

ก่อนหน้านี้ engineer หนึ่งคนอาจต้องเปิด 5 ระบบ สลับ context หลายรอบ เพื่อดัน task เดียวให้จบ

แต่เมื่อมี subagents งานเริ่มเปลี่ยนเป็น:

• อธิบาย outcome
• แตก workstream
• ให้ agent แต่ละตัวดูแลส่วนที่ scope ชัด
• รอ proof กลับมา
• review และ merge เฉพาะจุดที่สำคัญ

นี่คือ craft ใหม่ของ engineer

ไม่ใช่แค่เขียน code เก่ง แต่ต้องรู้ว่า:

• งานแบบไหน delegate ได้
• งานแบบไหนต้องอยู่ใน loop เอง
• context ไหนต้องให้ agent ก่อนเริ่ม
• proof แบบไหนถึงถือว่าเสร็จ
• pattern ไหนควรเก็บเป็น reusable skill

สำหรับทีมเล็กและ SME นี่แปลว่าอะไร

ไม่ได้แปลว่าต้องมี agent 20 ตัวพรุ่งนี้

แปลว่าเวลาเริ่มใช้ AI agent ให้เลิกคิดเป็นแชทเดี่ยว ๆ แล้วเริ่มคิดเป็น workflow:

• agent ตัวหนึ่งสรุป requirement
• agent ตัวหนึ่ง inspect code หรือข้อมูล
• agent ตัวหนึ่ง draft change
• agent ตัวหนึ่งตรวจ test หรือ QA
• มนุษย์อนุมัติก่อนปล่อยจริง

รูปแบบนี้ทำให้ AI เริ่มเป็น coworker ไม่ใช่กล่องแชท

5) ทำไม Salesforce ถึงวัด incident ด้วย

จุดที่ผมชอบที่สุดในบทความนี้คือ Salesforce ไม่ได้บอกแค่ว่า output เพิ่ม เขาบอกด้วยว่า total incidents ลดลง 5%

แน่นอน ตัวเลขนี้ต้องดูในบริบทของเขา แต่การเอา incident เข้ามาอยู่ในบทสนทนาเดียวกับ productivity สำคัญมาก

เพราะคำถามที่ผู้บริหารควรถามไม่ใช่:

“AI ทำให้ทีมส่งงานเร็วขึ้นไหม”

แต่ควรถามว่า:

“AI ทำให้ทีมส่งงานเร็วขึ้น โดย quality, security, reliability ไม่แย่ลงไหม”

Salesforce มี Engineering 360 เป็น platform ที่รวมข้อมูล engineering จากหลายร้อยระบบ เพื่อดู security, availability, quality และ developer productivity

นี่คือสิ่งที่หลายองค์กรไม่มี

พอไม่มี telemetry ก็จะเกิดปัญหาเดิม:

• AI ทำให้ PR เยอะขึ้น แต่ bug เยอะขึ้นด้วยหรือเปล่าไม่รู้
• AI ทำให้ code เร็วขึ้น แต่ incident เพิ่มหรือเปล่าไม่รู้
• AI ทำให้ทีมรู้สึก productive แต่ customer experience ดีขึ้นไหมไม่รู้

ดังนั้นบทเรียนไม่ใช่ “ให้ซื้อ Claude Code”

บทเรียนคือถ้าจะใช้ agent ในงานจริง ต้องมี measurement surface ที่ดู speed กับ quality พร้อมกัน

6) AgentScript บอกอีกชั้นว่า agent ต้องมี authored authority

Salesforce มีอีกชุดบทความที่เกี่ยวข้องกับ AgentScript และ Agent Script

ตรงนี้ช่วยเติมมุมสำคัญให้ Deep Dive นี้

ในงาน enterprise agent ปัญหาไม่ใช่แค่ model ฉลาดพอไหม แต่คือ decision ไหนควรถูก pin และ decision ไหนปล่อยให้ model คิดได้

ตัวอย่างง่าย ๆ:

ลูกค้าถามเรื่อง return สินค้า

ให้ model เลือกคำพูดเองได้ไหม ส่วนใหญ่ได้

ให้ model ตัดสินใจเองว่า customer verified แล้วหรือยังได้ไหม อันนี้เริ่มอันตราย

ให้ model เรียก refund หรือเปิดข้อมูลบัญชีโดยไม่มี gate ได้ไหม ยิ่งอันตราย

Agent Script ของ Salesforce วางแนวคิดแบบ per-decision control

บางจุด deterministic บางจุด agentic อยู่ในไฟล์เดียวที่ review, diff, test, ship ผ่าน CI ได้

นี่คือ concept ที่ดีมากสำหรับธุรกิจทั่วไป

อย่าถามว่า “จะให้ AI autonomous แค่ไหน”

ให้ถามว่า “decision ไหน load-bearing”

• authentication
• money
• permission
• sensitive routing
• customer data
• legal/compliance
• production deploy

สิ่งเหล่านี้ต้อง pin, gate, approve หรือ test ได้

ส่วนที่ model ควรมีอิสระคือสิ่งที่ความเสี่ยงต่ำกว่า เช่น phrasing, summarization, draft, exploration, parameter extraction ที่ยังมี validation ตามหลัง

agent ที่ดีไม่ใช่ agent ที่อิสระที่สุด agent ที่ดีคือ agent ที่รู้ว่าจุดไหนถูก authored authority ครอบไว้แล้ว

7) สิ่งที่ Salesforce ยังบอกว่ายาก

บทความนี้น่าเชื่อขึ้นเพราะ Salesforce ไม่ได้บอกว่าทุกอย่างจบสวย

เขาบอกว่ายังมีเรื่องยากหลายเรื่อง

หนึ่งคือ context management ใน agentic session ยาว ๆ

สองคือคุณภาพของ CLAUDE.md files ที่ต่างกันมากในแต่ละทีม

สามคือ security model เมื่อ agent ลงมือทำกับระบบจริง ไม่ใช่แค่ suggest

สี่คือ blast radius ของ tool ที่ config ผิดจะใหญ่ขึ้น

ห้าคือ role evolution

ถ้า agent ทำ execution layer ไปเยอะมาก junior engineer จะเติบโตยังไง product manager และ designer จะเปลี่ยนบทบาทยังไง unit of execution ยังเป็น scrum team แบบเดิมไหม หรือจะมี one-person units, three-person units มากขึ้น

คำถามพวกนี้สำคัญกว่าที่คิด

เพราะองค์กรที่ใช้ AI แค่เพื่อเร่งงานเดิม จะชนเพดานเร็ว

แต่องค์กรที่กล้าถามว่า role, workflow, quality gate, learning path และ team design ต้องเปลี่ยนอย่างไร จะได้ประโยชน์มากกว่า

8) บทเรียนสำหรับ SME ไทย

ถ้าอ่านแบบผิว ๆ Salesforce case อาจดูไกลตัวมาก องค์กรระดับนั้นมี engineer หลายพันคน มี platform วัด engineering เป็นร้อยระบบ มี resources ที่ SME ไทยไม่มี

แต่บทเรียนที่เอามาใช้ได้ไม่ได้อยู่ที่ scale

บทเรียนอยู่ที่ pattern

เริ่มจาก workflow ที่ชัดก่อน tool

เลือกงานที่:

• ทำซ้ำ
• มี input ชัด
• มี output ชัด
• มี proof ว่าเสร็จหรือไม่เสร็จ
• วัด speed กับ quality ได้
• ความเสี่ยงไม่สูงเกินไป

จากนั้นออกแบบ agent loop:

1. Goal

agent ต้องรู้ว่าผลลัพธ์คืออะไร ไม่ใช่แค่รับ prompt กว้าง ๆ

1. Context

agent ต้องเห็น source of truth, convention, example, previous output, docs หรือ data ที่จำเป็น

1. Rules and skills

สิ่งที่เวิร์กต้องถูกเก็บเป็น reusable skill หรือ SOP ไม่ใช่หายไปกับ chat history

1. Sandbox

ให้ agent ทำงานในพื้นที่แยกก่อนแตะ production

1. Approval

จุดเสี่ยงต้องมี human gate

1. Proof

จบงานต้องมี artifact เช่น PR, test result, screenshot, report, log, URL หรือไฟล์ที่ตรวจได้

1. Measurement

วัดทั้ง output และ quality ไม่ใช่วัดแค่จำนวนงาน

นี่คือ Data-Espresso / OPB Stack angle ที่ผมเห็นชัดมาก

AI coworker ที่ดีต้องมีบ้านของมัน มี workspace มี memory มี tools มี skills มี approval มี proof และมี rhythm ในการทำงานต่อเนื่อง

ไม่อย่างนั้นมันจะเป็นแค่ chatbot ที่เก่งขึ้น แต่ยังไม่กลายเป็นระบบทำงาน

9) มุมมองของผม

สิ่งที่ Salesforce ทำให้เห็นคือ AI transformation รอบนี้ไม่ควรถูกวัดด้วยคำถามว่า “พนักงานใช้ AI กี่คน”

คำถามนั้นตื้นไปแล้ว

คำถามใหม่ควรเป็น:

AI เข้าไปเปลี่ยน unit of work ขององค์กรหรือยัง

จาก task ที่มนุษย์ทำทีละขั้น เป็น outcome ที่มนุษย์กำหนด, agent ทำ, proof กลับมา, มนุษย์ตรวจจุดสำคัญ, แล้ว pattern ถูกเก็บใช้ซ้ำ

ถ้าองค์กรยังอยู่ที่ prompt ทีละคน productivity จะขึ้นบ้าง แต่ไม่ compound

ถ้าองค์กรเริ่มเก็บ context, skills, guardrails, approval, telemetry และ proof productivity จะเริ่มกลายเป็น operating advantage

นี่คือความต่างระหว่าง “ใช้ AI” กับ “ทำงานแบบ agentic”

และสำหรับทีมไทย ผมคิดว่าจุดเริ่มไม่ต้องใหญ่

ไม่ต้องเริ่มจากทั้ง SDLC ไม่ต้องเริ่มจากทั้งบริษัท ไม่ต้องเริ่มจากคำว่า transformation

เริ่มจาก workflow เดียวที่สำคัญพอ วัดผลได้ และมี proof ชัด

เช่น:

• content production ที่ต้องมี source, draft, cover, queue, publish proof
• support ticket ที่ต้องมี context, draft reply, approval, CRM update
• sales follow-up ที่ต้องมี lead context, message draft, next task, owner
• report ที่ต้องมี data source, definition, chart, summary, reviewer
• code change ที่ต้องมี issue, branch, test, screenshot, PR

ถ้าทำ workflow แรกให้มี agent loop จริง ธุรกิจจะเริ่มเข้าใจเองว่า AI ไม่ใช่แค่เครื่องตอบคำถาม

มันคือวิธีออกแบบงานใหม่