เราอยู่ตรงไหนของแผนที่#

ขั้นที่ 3 จาก 5 คือ Build Requirements กับ Design เติมแล้ว

ชิ้นจิ๊กซอว์ของตอนนี้คือเรื่องที่ 4 กับ 5 บนแผนที่ agent ที่ใช้ และรันกี่ตัว กับบริบทและกฎของบ้าน อยู่ในวงสร้าง

ทำไมสำคัญ

agent ไม่มีความจำข้าม session แผนที่ดีแค่ไหน ถ้าไม่มีอะไรบังคับ มันก็เป็นแค่กระดาษ

แฟ้มที่หนาขึ้นทุกรอบ#

ภาค 1 เราเคยเห็นภาพนี้

แก้ code สองวัน แต่เขียนเอกสารสามสัปดาห์ (ตัวอย่าง)

ยุค agent ยังต้องมีทั้งหมดนี้อยู่มั้ย

คำตอบสั้นๆ ของผมคือ กฎยังต้องมี แฟ้มหนาไม่ต้อง

ทำไม agent ลืมแผนทุก session?#

ต้นเปิด session ใหม่

agent เขียนวันที่เป็น string อีกรอบ ผิด DR-01

อีกตัวเพิ่ม database client ตัวที่สอง ผิด DR-02

ต้นต้องคอยแปะข้อความเตือนทุกครั้ง

กฎที่ต้องเตือนทุกครั้ง ไม่ใช่กฎ เป็นแค่คำขอ

ผู้ตรวจอยากเห็นอะไร?#

ผมลองถามตัวเองแบบผู้ตรวจ ถ้าวันหนึ่งต้องพิสูจน์ว่าบ้านนี้มีกฎจริง ต้องโชว์อะไร

คำตอบมีสามอย่าง

1. กฎที่เขียนไว้ บอกว่าตั้งใจทำอะไร
2. ระบบที่บังคับกฎนั้น
3. log ที่ระบบเขียนเอง ต่อเนื่องเป็นช่วงเวลา

log อย่างเดียวไม่พอ

log บอกว่าเกิดอะไรขึ้น แต่ไม่ได้บอกว่าควรเกิดอะไร และไม่ได้บอกว่ามีอะไรกันไม่ให้ผิด

อย่างที่ 1: กฎเขียนไว้ สั้น และไม่ค่อยเปลี่ยน#

ใน ISO/IEC 27001:2022 ข้อ 7.5 เขียนไว้ว่าเอกสารที่ต้องมี นอกจากที่มาตรฐานบังคับ คือ “documented information determined by the organization as being necessary”

และมีหมายเหตุว่าปริมาณเอกสาร “can differ from one organization to another” ส่วนหนึ่งเพราะขนาดองค์กร

รูปแบบเป็นได้ทั้ง “(e.g. paper, electronic)” ต้องผ่าน “review and approval for suitability and adequacy” และต้องคุมการแก้ไข เช่น “version control”

บริษัทคนเดียวไม่ต้องมีแฟ้มเท่าบริษัทพันคน

ของต้นคือ AGENTS.md กับไฟล์ DR อยู่ใน git มีชื่อ มีวันที่ ทุกการแก้ผ่าน commit

เว็บ agents.md อธิบายว่าให้คิดถึงไฟล์นี้ “as a README for agents”

ผมให้มันสั้นไว้ ยิ่งยาว agent ยิ่งข้าม

อย่างที่ 2: ระบบที่บังคับกฎ#

DR แต่ละใบต้องกลายเป็นอะไรสักอย่างที่ fail ได้

• DR-01 วันที่เป็น Date type ไม่ใช่ string
• lint rule ห้าม string วันที่ดิบๆ และห้าม database client ตัวที่สอง (DR-01, DR-02)
• CI รัน type check, lint และ test ทุก PR
• branch protection ไม่ให้ merge ถ้า CI ยังแดง

lauren ตอบคนที่ถามว่าจะเริ่มยังไง ว่า “codify them into skills when they repeat. even better, write lint rules or structure your codebase so certain mistakes are impossible.”

อีก โพสต์ เธอเขียนว่า strong type systems กับ compiler diagnostics “has far greater impact than AGENTS.md and tweaking your skills” และปิดว่า “the best rules are in your code.”

ผมเรียงเป็นบันได

ข้อความเตือน → AGENTS.md → lint หรือ type → CI block

ยิ่งขึ้นบันได agent ยิ่งหนีไม่ได้

อย่างที่ 3: log เป็นหลักฐาน ระบบเขียนเอง#

PR, ผล CI และบันทึก merge คือหลักฐานที่ระบบเขียนให้ทุกครั้ง

Polara Labs เขียนไว้ว่าผู้ตรวจ SOC 2 อยากได้ record ที่ “pulled from the systems that hold them rather than written up afterwards”

ตรงนี้คือเหตุผลที่ log อย่างเดียวไม่พอ

ใน คู่มือของ AICPA รายงาน SOC 2 Type 1 ดูว่ากฎและระบบออกแบบไว้เหมาะสม ณ จุดเวลาหนึ่ง

Type 2 ดูเพิ่มอีกเรื่อง คือ “whether controls operated effectively throughout the period of time”

กฎบนกระดาษอย่างเดียวคือความคิดแบบ Type 1

log ต่อเนื่องหลายเดือน ที่ชี้กลับไปหากฎกับระบบที่บังคับ คือสิ่งที่พิสูจน์ว่ามันทำงานจริง

ส่วนบันทึกว่า agent ทำอะไรไปบ้าง เก็บไว้ตอน 10

เอกสาร 6 ชั้น ยุค agent ใครทำ?#

EXTRA เคยทำตารางตัวอย่าง “บ้านของเรา” ไว้ ผมชอบเพราะเห็นภาพเลย

แฟ้มบางลงเพราะชั้นกลางกลายเป็น automation

ชั้นบนยังสั้นเหมือนเดิม ชั้นล่างเขียนตัวเอง

งานเปลี่ยนวันละหลายรอบ กฎเปลี่ยนนานๆ ที#

งานของต้นเปลี่ยนวันละหลายครั้ง ทุกครั้งได้ record ของตัวเองอัตโนมัติ

ส่วนกฎเปลี่ยนนานๆ ที และเปลี่ยนผ่าน PR เหมือน code

ใน ISO/IEC 29110 ฉบับปี 2011 เขียนไว้ว่า “The selection of the techniques or methods is left to the VSE or project team.”

agile กับมาตรฐานเลยไม่ได้เป็นเรื่องให้เลือกข้าง

กับดักที่ผมเห็น#

ทางลัดที่ไม่ได้จดไว้ บทความ บน dev.to เขียนว่า “A documented emergency change procedure with post-hoc review is an entirely acceptable control. An undocumented one that three engineers know about is a finding.”

ให้ AI เขียน policy เกินจริง AuditBadger เขียนว่าความเสี่ยงคือ “a model writes a good policy describing controls you do not operate.”

กฎของผมคือ เขียนเฉพาะสิ่งที่ระบบบังคับจริง

ต้นอนุมัติ PR ตัวเอง เรื่องนี้ยังไม่แก้ในตอนนี้ เก็บไว้ตอน 7 กับตอน 10

มาตรฐานว่ายังไง

29110 Basic เก็บผลงานทั้งหมดไว้ใน project repository และปล่อยให้เลือกวิธีทำงานเอง

ฝั่ง 12207 บริษัทใหญ่แยกเป็น process ของตัวเอง เช่น Life cycle model management, Configuration management และ Knowledge management

27001 ข้อ 7.5 อย่างที่เล่าข้างบน

ข้อนี้ผมเทียบเอง ไม่ใช่คำของมาตรฐาน git repo ของต้นก็คือ project repository ของเขานั่นแหละครับ

จิ๊กซอว์ชิ้นที่เติมแล้ว#

ชิ้นกฎของบ้านเติมแล้ว แถบ 5 ขั้นตอนนี้มี Requirements, Design และกฎของ Build

ต้นมี AGENTS.md สั้นๆ, types, lint, CI ขั้นต่ำ และ branch protection

แต่กฎทั้งหมดนี้คิดว่าทุกคนที่ push คือต้น

ชิ้นถัดไปคือตัวตนและสิทธิ์ของ agent

สิ่งที่ผมได้จากตอนนี้#

ตอนต่อไป#

ต้นไปเปิดดูสิทธิ์ของ token ที่ให้ agent ใช้

token นั้น push ได้ทุก repo

และทุก commit ขึ้นชื่อต้น 555+

agent ไม่ใช่เรา

คำถามที่พบบ่อย#

ต้องมี policy ยาวๆ ไหม?

ไม่ต้องครับ สั้นแต่มีระบบบังคับดีกว่ายาวแต่ไม่มีใครทำตาม

มี AGENTS.md อย่างเดียวพอไหม?

ไม่พอ agent ข้ามได้ ใส่กฎลงใน code ด้วย ทั้ง type, lint และ CI

ต้องทำ SOC 2 ตอนนี้เลยไหม?

ยังไม่ต้อง แต่ออกแบบให้ log เกิดขึ้นเองตั้งแต่วันนี้ วันที่ต้องใช้จะมีหลักฐานย้อนหลังให้

ให้ AI เขียน policy ได้ไหม?

ได้ ถ้าตรงกับสิ่งที่ระบบทำจริง และคุณเป็นคนอ่านแล้วอนุมัติเอง

Next → ภาค 2 ตอนที่ 5: agent ไม่ใช่ตัวเรา