ตอนเป็น Engineer ผมชอบความรู้สึกตอนงานจบ

รับ requirement → เขียน code → ทำ test → เปิด PR → แก้ comment → แล้ว merge

ถึงระหว่างทางจะมี requirement เปลี่ยน มี bug แทรก หรือ production issue เข้ามา งานก็ยังมองเห็นได้เป็นชิ้นๆ มี branch มี commit และมีจุดที่บอกไดชัดเจนว่าเสร็จแล้ว

พอขยับมาเป็น Development Lead ความชัดแบบนั้นค่อยๆ หายไป เวลาส่วนหนึ่งเปลี่ยนไปอยู่กับ requirement ที่ยังไม่ลงตัว การช่วยแตก task ให้ทีมเริ่มทำงานได้ การเคลียร์ dependency กับทีมอื่น รวมถึง decision ที่อาจกระทบทั้ง sprint

หลายวันจบลงโดยไม่มี commit หรือ PR ของตัวเอง ช่วงแรกผมรู้สึกเหมือนวันนั้นไม่ได้ส่งมอบอะไร แต่พออยู่กับบทบาทนี้นานขึ้นก็เริ่มเห็นว่างานไม่ได้หายไปไหน เพียงแต่มันย้ายจากการปิดงานของตัวเอง ไปเป็นการช่วยให้ทีมส่งมอบงานได้ดีขึ้น

ช่วงที่ Vega ยังเป็นทีมใหม่

สมาชิกแต่ละคนมาจากคนละ background และมีความถนัดไม่เหมือนกัน บางคนแข็งแรงเรื่อง code บางคนเข้าใจ business flow มากกว่า ขณะที่ payment domain ก็ยังเป็นเรื่องใหม่สำหรับหลายคน หลายอย่างเลยเป็นสิ่งที่พวกเราเรียนรู้ไปพร้อมกัน

ช่วงนั้นผมใช้เวลาอธิบายค่อนข้างเยอะ ทั้งเรื่อง TrueMoney domain, product, engineering standard และความเสี่ยงของระบบที่ทีมต้องมองให้เห็น

ในระบบ payment gateway เรื่องเล็กๆ ใน code มักโยงไปไกลกว่าที่เห็นใน backlog ปลายทาง timeout แล้ว transaction ควรอยู่สถานะอะไร การ retry จะทำให้เกิดรายการซ้ำหรือไม่ ทีม Operation จะตามรายการจากข้อมูลไหน และเมื่อ reconciliation ไม่ตรง ใครจะเป็นคนเห็นก่อน

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

พอเวลาผ่านไป สิ่งที่ผมเริ่มสังเกตไม่ใช่แค่ว่าทีมถามน้อยลงหรือไม่ แต่เป็นลักษณะของคำถามที่เปลี่ยนไป ทีมเริ่มเห็น risk ก่อนที่ผมจะถาม เริ่มเสนอทางเลือกมาก่อน และเรื่องที่เคยต้องให้ผมอธิบายก็เริ่มมีคนอื่นช่วยอธิบายแทนได้

พอเริ่มเห็นสิ่งเหล่านี้ ผมรู้สึกได้ว่าความรู้เริ่มกระจายออกจาก Lead ไปอยู่กับทีมแล้วจริงๆ

จากการส่งต่องาน ไปสู่การส่งต่อ Decision

ผมเปิดให้ทีมมีส่วนร่วมกับการตัดสินใจมาตั้งแต่แรก เวลาเจอปัญหา แต่ละคนจะได้เสนอทางเลือก คุยข้อดีข้อเสีย และ challenge ideas หรือ proposed solutions กันก่อน แทนที่จะรอให้ผมเลือกแล้วทุกคนทำตาม

วิธีนี้ช่วยให้ทีมเห็นมุมที่กว้างขึ้น แต่สิ่งที่ผมประเมินต่ำไปคือ การเปิดพื้นที่ให้คุยไม่ได้แปลว่า discussion จะจบได้เองเสมอไป หลายครั้งทีมเลือกแนวทางแล้ว แต่เรื่องเดิมยังถูกนำกลับมาถก จนการ challenge solution ค่อยๆ กลายเป็นการพยายามพิสูจน์ว่าทางของใครดีกว่า

แม้ตัวเรื่องจะไม่ได้ใหญ่เมื่อเทียบกับผลกระทบต่อระบบ แต่กลับใช้เวลาของทีมมาก และบางครั้งก็เริ่มกระทบทั้งคนในวงสนทนาและการทำงานร่วมกัน ตรงนี้ทำให้ผมเริ่มมองการปิด decision มากกว่าแค่เรื่องเวลา เพราะเรื่องที่จบใน meeting อาจยังค้างอยู่กับบางคน และเมื่อเกิดซ้ำๆ ก็อาจกระทบทั้ง team health และ well-being ได้ การคุยแบบ 1-on-1, Retro และ team health check ช่วยให้ผมเห็นสิ่งที่อาจไม่ได้ถูกพูดออกมาในวงใหญ่

ช่วงนี้ผมลองใช้ 1–2–4-All เพื่อให้แต่ละคนได้คิดก่อน แล้วค่อยแลกเปลี่ยนเป็นคู่ เป็นกลุ่มเล็ก และกลับมาคุยรวมกัน วิธีนี้ช่วยเปิดพื้นที่ให้หลายเสียงมากขึ้น โดยไม่ปล่อยให้ discussion ถูกนำไปโดยคนเพียงไม่กี่คน

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

หลายเรื่องเริ่มมี owner ช่วยพาไปต่อ

เมื่อทีมทำงานร่วมกันมาระยะหนึ่ง หลายเรื่องก็ไม่จำเป็นต้องผ่านผมเหมือนช่วงแรก คนในทีมเริ่มอธิบาย flow ให้กันได้ มองเห็น risk ก่อนที่ผมจะถาม และเสนอทางเลือกพร้อมข้อดีข้อเสีย แทนที่จะรอคำตอบจาก Lead

สำหรับ Senior ผมเริ่มมอบบทบาทที่กว้างกว่าการรับงาน technical ที่ยากขึ้น สิ่งที่ผมเริ่มเห็นคือการช่วย shape งานตั้งแต่ต้น ทั้งการมองว่า requirement ยังขาดตรงไหน ควรดึง QA หรือทีมอื่นเข้ามาเมื่อไร และ decision ที่กำลังเลือกจะกระทบ delivery หรือ production อย่างไร

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

อีกด้านหนึ่ง ต่อให้หลายเรื่องไม่ต้องผ่าน Lead แล้ว ทีมก็อาจเพียงเปลี่ยนไปพึ่ง Senior คนเดียวแทน ซึ่งสุดท้ายก็กลายเป็น bottleneck จุดใหม่

ตอนนี้สิ่งที่ผมกำลังลองทำเลยไม่ใช่แค่ส่งต่องาน แต่พยายามส่งต่อทั้งบริบท สิทธิ์ในการตัดสินใจ และพื้นที่ให้ owner ของเรื่องนั้นช่วยพา discussion ไปข้างหน้าด้วย

Technical Detail ยังสำคัญ แต่เหตุผลเปลี่ยนไป

ผมยังคงให้เวลากับ technical detail อยู่มาก เพียงแต่เหตุผลไม่เหมือนตอนที่ผมโฟกัสกับ implementation ของตัวเอง

หลายครั้งปัญหาไม่ได้อยู่ที่ใครเข้าใจผิด แต่อยู่ที่แต่ละฝ่ายเห็นระบบคนละส่วน Business เห็น customer flow, QA เห็น test scenario, Operation เห็นสิ่งที่จะเกิดหลัง release ส่วน Engineer เห็น implementation ตรงหน้า แม้แต่ละฝ่ายจะเข้าใจถูกในส่วนของตัวเอง แต่เมื่อนำทุกส่วนมาต่อกันก็ยังมีช่องว่างได้

ผมเคยเจอทั้ง API ที่ทำงานได้แต่ตามรายการไม่ได้ Test ที่ผ่านแต่ยังไม่ชัดว่าควร alert เมื่อไร และ error code ที่ถูกต้องในเชิง technical แต่คนรับช่วงต่อไม่รู้ว่าต้องทำอะไร สถานการณ์เหล่านี้ทำให้ผมยังต้องลงไปดูรายละเอียดทางเทคนิค ไม่ใช่เพื่อเป็นคนที่ตอบได้ทุกเรื่อง แต่เพื่อช่วยเชื่อมมุมมองของแต่ละฝ่าย และมองหาส่วนที่อาจไม่ได้เขียนไว้ใน backlog

บาง solution ดูถูกต้องเมื่อมองเฉพาะ code แต่ยังไม่ตอบปัญหาของระบบจริง งาน review ของผมจึงไม่ได้หยุดอยู่แค่ว่า code เขียนถูกหรือไม่ แต่ต้องย้อนกลับไปดูด้วยว่า สิ่งที่ทีมกำลังทำตอบโจทย์ของทั้ง flow จริงหรือเปล่า

จากสิ่งที่ผมทำ ไปสู่สิ่งที่ทีมทำได้

เมื่อก่อนผมมองงานจากสิ่งที่ทำเสร็จด้วยตัวเอง แต่หลังจากขยับมาเป็น Lead ผมต้องมองสิ่งที่เกิดขึ้นกับทีมมากขึ้น ทั้งความชัดเจนก่อนเริ่มงาน การมองเห็นความเสี่ยงได้เร็วขึ้น คุณภาพของการตัดสินใจ และความสามารถของทีมในการเดินหน้าต่อได้ด้วยตัวเอง ช่วงหลังผมเริ่มมีทั้ง OKRs และ engineering metrics เช่น planning lead time, PR cycle time และระยะจาก development ไปถึง production มาช่วยดูภาพเหล่านี้มากขึ้น ไม่ใช่เพื่อแทนสิ่งที่เห็นจากการทำงานร่วมกัน แต่เพื่อไม่ให้ผมต้องประเมินทุกอย่างจากความรู้สึกเพียงอย่างเดียว

วันนี้ผมยังชอบเขียน code และยังรู้สึกดีกับ PR ที่ทำออกมาเรียบร้อย เพียงแต่ PR ของตัวเองไม่ใช่ตัวชี้วัดหลักอีกต่อไป

การเปลี่ยนจาก Code Ownership ไปสู่ Team Ownership ไม่ได้หมายความว่าผมเขียน code น้อยลง แต่มันคือการที่ความรู้ การตัดสินใจ และความรับผิดชอบค่อยๆ กระจายออกไปอยู่กับทีมมากขึ้น

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

From Code Ownership to Team Ownership วันที่ผมเริ่มวัดงานจากทีม ไม่ใช่ Pull Request was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

สวัสดีครับ สำหรับใครที่ยังไม่รู้จักผม จิตพัฒน์ หรือจะเรียกว่า ไอเดียก็ได้ครับ วันนี้ผมอยากจะพาทุกคนมาเจาะลึกเรื่องการสร้าง Skills สำหรับงาน QA/Tester กันครับ!!

อย่างแรกมารู้จัก Skills กันก่อน?

ให้สมมุติว่า เรามี “น้อง Junior ที่เก่งมาก” อยู่คนหนึ่งที่สามารถช่วยงานเราได้ทุกอย่างแต่ทุกวันที่เริ่มทำงาน น้องดันลืมทุกอย่างที่เคยเรียนรู้มาหมดเลย เราเลยต้องนั่งอธิบายวิธีทำงานให้เขาใหม่ทุกวัน มันน่าเบื่อใช่มั้ยล่ะ นี่แหละคือปัญหาของการใช้ AI แบบเดิมๆ ที่เราต้องเขียน prompt ใหม่ทุกครั้ง

Skill จึงถือกำเนิดขึ้นมา โดยมันเป็นโครงสร้าง Standard ของระบบ AI Agent ยุคใหม่ (เช่น Claude Skills ของ Claude เป็นต้น) ที่ช่วยจัดระเบียบ/เพิ่มทักษะให้ AI โดย Skill หรือ Agent Skills คือ “ชุดความสามารถเฉพาะทาง” ที่เราสร้างขึ้นเพื่อสอนให้ AI ทำงานตามที่เรากำหนด (Task) ได้อย่างแม่นยำและตรงกับบริบทของทีมมากขึ้น เหมือนเรามี Guideline สำหรับการทำงานให้ Junior คนนั้นอ่าน แล้วเขาก็จะทำตามได้เลยโดยไม่ต้องอธิบายซ้ำทุกครั้งที่เราต้องการนั้นเอง

โครงสร้างของ Skill

Skill หนึ่งตัวจะประกอบไปด้วย 1 Folder ที่มีส่วนประกอบดังนี้

my-skill/
├── SKILL.md          ← ไฟล์หลักที่มีคำสั่งอยู่ (บังคับต้องมี)
├── scripts/          ← สามารถเพิ่มโค้ดที่จะให้รันเมื่อใช้ skill ได้ (ถ้ามี)
├── references/       ← สามารถเพิ่มแหล่งข้อมูล/เอกสารอ้างอิงได้ (ถ้ามี)
└── assets/           ← สามารถเพิ่ม template, รูปภาพ ฯลฯได้ (ถ้ามี)

โดย ไฟล์ SKILL.md จะเป็นไฟล์ Markdown ที่ประกอบด้วย
- YAML frontmatter เป็น Metadata ที่ระบบใช้ตัดสินใจว่าควรเรียกใช้ Skill นี้ตอนไหน
- Instructions คือชุดคำสั่ง (Prompt) ที่ระบุขั้นตอนการทำงานอย่างละเอียด รวมถึงการกำหนดคำสั่ง (Scripts) และตัวแปร (Parameters) ต่าง ๆ ที่จำเป็น
- Additional files เช่น scripts ที่จะให้รัน, เทมเพลต หรือรูปภาพ, แหล่งอ้างอิงหรือ เอกสารอ้างอิงที่ใช้เป็น ข้อมูล, ซึ่งจะช่วยให้ AI ของเราเข้าใจงานได้มากขึ้น

ทำไมต้องใช้ MCP ควบคู่กับ Skills?

ลองจินตนาการว่า AI ของเราเป็นช่างซ่อมบ้าน 🏠

MCP คือตัวเชื่อมต่อกับระบบภายนอก เปรียบเสมือน “กล่องเครื่องมือ” ที่ช่างพกไปด้วย (ข้างในก็จะมี ไขควง, ค้อน, มิเตอร์วัดไฟ) ถ้าไม่มี MCP ช่างก็จะได้แต่ยืนมอง เพราะไม่มีอุปกรณ์ชิ้นไหนเข้าถึงหน้างานได้เลย เปรียบ MCP เหมือนเป็นมือของ Copilot ที่ไว้จับเครื่องมือ

ส่วน Skills คือ “ทักษะและประสบการณ์” ในหัวของช่าง ที่บอกว่าเมื่อหยิบไขควงมาแล้ว ต้องไขน็อตตัวไหนก่อนหลังตามลำดับ

ทั้งสองอย่างนี้ทำงานเสริมกัน MCP ให้ความสามารถในการเข้าถึง ส่วน Skills ให้ความรู้ในการใช้งาน เวิร์กโฟลว์ที่ดีคือการใช้ทั้งสองอย่างร่วมกัน เช่น มี MCP เชื่อมต่อกับ Jira แล้วมี Skill ที่สอน Copilot ว่าเมื่อเจอข้อนี้จากใน Jira แล้วต้องวิเคราะห์และสรุปตอบมายังไง

มาลองดูตัวอย่างการใช้งานจริงกัน เพื่อให้เห็นภาพว่า Skills สามารถช่วยอะไรเราได้บ้าง ?

จากตัวอย่างด้านล่างนี้คือ Skill ที่ชื่อว่า “testcase-generator” ซึ่งถูกสร้างขึ้นมาเพื่อให้ สร้าง Test Case ตาม requirements ที่มาจาก Jira cards หรือ Confluence specs

ซึ่งนี่คือตัวอย่างการทำงานร่วมกันระหว่าง MCP และ Skills ที่ชัดเจนมาก โดยใน skill นี้เราจะใช้ “mcp-atlassian” จะทำหน้าที่เป็นสะพานเชื่อมเข้าไปยัง Jira หรือ Confluence ส่วน Skill จะเป็นตัวออกคำสั่งและไกด์ทางให้ Copilot รู้ว่าต้องไป Analysis และออกแบบ Testcase อย่างไงบ้าง?

---
name: "testcase-generator"
description: >
  Generate comprehensive backend API test cases from Jira cards and Confluence specs.
  Fetches requirements via mcp-atlassian, analyzes API specifications, and produces
  structured Markdown test case tables covering happy paths, edge cases, and negative
  testing scenarios. Invoke when the user asks to "generate test cases", "create test
  cases from Jira", "write API tests", or provides a Jira/Confluence link and asks
  for test coverage.
capabilities:
  - Fetch and parse API specifications from Jira issues and Confluence pages
  - Identify RESTful endpoints, request/response schemas, status codes, and business rules
  - Generate test cases for happy paths, edge cases, and error/negative scenarios
  - Output results as a structured Markdown table
---

# Test Case Generator

You are a **Senior QA Engineer** specializing in backend API testing. Your job is to
produce comprehensive, implementation-ready test cases from API specifications stored
in Jira and Confluence.

---

## 1. Input Acquisition

When the user provides a **Jira issue key** (e.g., `PROJ-1234`) or a **Confluence page
URL/title**, use the **mcp-atlassian** MCP server to retrieve the content:

### Jira

Use the `jira_get_issue` tool to fetch the issue. Extract:

- **Summary** and **Description** (may contain API spec or acceptance criteria).
- **Acceptance Criteria** or **Definition of Done** sections.
- **Attachments** or **linked Confluence pages** that contain detailed API specs.
- **Labels, Components, Fix Version** for context on scope.

If the Jira issue references a Confluence page, follow the link.

### Confluence

Use the `confluence_get_page` or `confluence_search` tool to fetch the page content.
Extract:

- Endpoint definitions: **method**, **path**, **query/path parameters**.
- **Request body schema** (field names, types, required/optional, constraints).
- **Response body schema** and **HTTP status codes**.
- **Business rules**, validation logic, and authorization requirements.
- **Data models** and enum/allowed values.

---

## 2. Specification Analysis

Before generating test cases, perform a structured analysis of the extracted spec.
Identify and mentally catalog:

### 2.1 Endpoints

For each endpoint, record:

| Attribute         | Details                                              |
| ----------------- | ---------------------------------------------------- |
| Method & Path     | e.g., `POST /api/v1/users`                           |
| Authentication    | Bearer token, API key, none, etc.                    |
| Authorization     | Required roles/permissions                           |
| Path Parameters   | Name, type, constraints                              |
| Query Parameters  | Name, type, required/optional, defaults, constraints |
| Request Body      | Schema with field types, required flags, constraints |
| Response Codes    | 200, 201, 400, 401, 403, 404, 409, 422, 500, etc.   |
| Response Body     | Schema per status code                               |

### 2.2 Business Rules

- Field validation rules (min/max length, regex patterns, allowed values).
- Cross-field dependencies (e.g., `endDate` must be after `startDate`).
- State-machine constraints (e.g., cannot cancel an already-completed order).
- Rate limits, pagination rules, idempotency requirements.

### 2.3 Edge-Case Indicators

Flag anything that commonly produces edge cases:

- Nullable vs. required fields.
- Boundary values (0, 1, max, max+1).
- Empty collections vs. missing fields.
- Unicode / special characters in string fields.
- Concurrent access or duplicate submission scenarios.

---

## 3. Test Case Generation Rules

Generate test cases organized into **three categories**. Use the following ID
convention:

| Category    | ID Prefix | Description                                           |
| ----------- | --------- | ----------------------------------------------------- |
| Happy Path  | `HP-XXX`  | Valid inputs producing expected successful outcomes    |
| Edge Case   | `EC-XXX`  | Boundary, unusual-but-valid, or tricky-but-valid cases|
| Error Case  | `ERR-XXX` | Invalid inputs, unauthorized access, constraint violations |

### 3.1 Happy Path (`HP-XXX`)

Generate test cases for:

- **Basic CRUD** success for each endpoint.
- All **optional fields** present vs. only required fields.
- Each valid **enum/status value**.
- Successful **authentication and authorization** with correct credentials/roles.
- Pagination with default and custom page sizes (if applicable).
- Filtering/sorting with valid parameters (if applicable).

### 3.2 Edge Cases (`EC-XXX`)

Generate test cases for:

- **Boundary values**: minimum, maximum, and just-within-range values for numeric
  fields, string lengths, array sizes, and date ranges.
- **Empty vs. null**: empty string `""` vs. `null` vs. field omitted entirely.
- **Special characters**: Unicode, emojis, SQL-injection-like strings (as data, not
  as attacks), HTML entities in string fields.
- **Large payloads**: maximum allowed collection sizes, deeply nested objects.
- **Concurrent operations**: duplicate submissions, race conditions (describe
  scenario; actual concurrency testing is out of scope for the table).
- **Idempotency**: repeated identical requests where the API should be idempotent.
- **Default values**: verify server-assigned defaults when optional fields are
  omitted.

### 3.3 Error / Negative Cases (`ERR-XXX`)

Generate test cases for:

- **Missing required fields** (one at a time, then all at once).
- **Invalid data types** (string where number expected, number where boolean, etc.).
- **Constraint violations**: too short, too long, out of range, invalid format
  (e.g., bad email, invalid date).
- **Invalid enum values**.
- **Unauthorized access**: missing token, expired token, invalid token.
- **Forbidden access**: valid token but insufficient role/permissions.
- **Resource not found**: valid format ID that doesn't exist.
- **Conflict / duplicate**: creating a resource that already exists (409).
- **Method not allowed**: using wrong HTTP method on an endpoint.
- **Unsupported media type**: wrong `Content-Type` header.

---

## 4. Output Format

Present **all** generated test cases in a single Markdown table with these columns:

```
| ID       | Description                                         | Input                                                    | Expected Result                                    |
| -------- | --------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------- |
| HP-001   | Create user with all valid fields                   | POST /api/v1/users { "name": "John", "email": "..." }   | 201 Created; response body contains user ID        |
| EC-001   | Create user with name at max length (255 chars)     | POST /api/v1/users { "name": "<255 chars>", ... }        | 201 Created; name stored and returned in full      |
| ERR-001  | Create user without required email field             | POST /api/v1/users { "name": "John" }                    | 400 Bad Request; error message indicates email required |
```

### Column Guidelines

| Column          | Content Rules                                                        |
| --------------- | -------------------------------------------------------------------- |
| **ID**          | Prefixed category + sequential number: `HP-001`, `EC-001`, `ERR-001`|
| **Description** | One-line summary of what is being tested and why                     |
| **Input**       | HTTP method, path, and relevant request body / query params (use     |
|                 | concise JSON; abbreviate large payloads with `<description>`)        |
| **Expected Result** | Expected HTTP status code + key assertions on the response body  |
|                 | or headers. Include error message patterns where applicable.         |

---

## 5. Execution Workflow

Follow these steps in order:

1. **Receive input** — The user provides a Jira key, Confluence link, or raw API spec.
2. **Fetch spec** — Use `mcp-atlassian` tools to retrieve the full specification.
3. **Analyze** — Parse endpoints, schemas, rules, and constraints (Section 2).
4. **Generate** — Produce test cases per the rules in Section 3.
5. **Format** — Output the complete Markdown table (Section 4).
6. **Summarize** — After the table, provide a brief summary:
   - Total test case count broken down by category.
   - Any assumptions made due to ambiguous or missing spec details.
   - Suggested areas that need clarification from the product owner or developer.

---

## 6. Quality Checklist

Before presenting the final output, verify:

- [ ] Every endpoint in the spec has at least one happy-path test.
- [ ] Every required field has a missing-field error test.
- [ ] Every field with constraints has boundary/edge-case tests.
- [ ] Authentication and authorization are covered (if applicable).
- [ ] Error response structures match the documented API error format.
- [ ] IDs are sequential within each category and do not repeat.
- [ ] Descriptions are specific enough that another QA engineer can implement
      the test without referring back to the spec.
- [ ] Input column contains enough detail to reproduce the request.

---

## 7. Assumptions & Conventions

- If the spec is ambiguous about a constraint, **generate the test case anyway**
  and note the assumption in the summary.
- Use realistic but fictional data in examples (e.g., `john.doe@example.com`).
- Do not generate security penetration tests (SQLi, XSS payloads as attacks);
  only test that the API properly rejects malformed input.
- When the spec mentions pagination, always include tests for first page, last
  page, page beyond range, and invalid page number.
- For date/time fields, test ISO 8601 format compliance and timezone handling
  unless the spec says otherwise.

โอเคมาถึงตรงนี้ หลายท่านคงบอกว่า ‘โอ้โห ทำไมมันดูวุ่นวายจัง ดูเหมือนต้องไปใส่นู่นนี่นั่นเยอะแยะเต็มไปหมด’. ข่าวดีคือเราไม่ต้องเขียน SKILL.md จากศูนย์เอง — เราบอก Copilot ได้เลยว่าอยากได้ Skill แบบไหน แล้วให้มันช่วยร่างให้

แล้วสำหรับ QA/Tester เราควรสร้าง Skill อะไร ? 🧐

ก่อนจะเริ่มทำกัน ผมเชื่อว่าในบริษัทที่มีทีมอยู่มากมาย ก็คงมีความต้องการ Skill ที่เเตกต่างกันไปตามแต่ละทีม ดังนั้น Skill ที่ดีคือ skill ที่ตอบโจทย์บริบท หรือความต้องการของผู้ใช้ได้ โดยเราควรเน้นให้แต่ละ skill มีความเฉพาะเจาะจง โดย 1 skill ควรทำหน้าที่เดียว (Single Responsibility) และกำหนด คำอธิบาย (Description) ให้แม่นยำเพื่อช่วยให้ AI ตัดสินใจเรียกใช้ได้อย่างถูกต้อง

เราลองมาสร้าง Skill เเรก ด้วย Copilot กันดีกว่า 😙

ก่อนที่เราจะ prompt ให้ Copilot สร้าง skill ให้เรา ผมอยากจะเเนะนำหนึ่งในวิธีที่จะทำให้ Skill ที่ Copilot สร้างดียิ่งขึ้น นั้นก็คือ การใช้ Skill สำหรับสร้าง Skill นั้นเอง โดยเราสามารถหา Skill เหล่านี้มาได้จาก Web อย่าง https://www.skills.sh/ ซึ่งเป็นแหล่งรวบรวม Skill มากมาย โดยเราสามารถ Search หา Skill ที่ต้องการเเล้ว ดาวน์โหลดมาติดตั้งใช้งานใน Copilot ของเราได้นั้นเอง

หลักการเขียน prompt สำหรับสร้าง Skill มี 3 ส่วนสำคัญ
(ทุกคนสามารถเอาไปปรับต่อได้)

1. บอกว่าคุณ หรือ AI เป็นใครเเล้วทำงานอะไร? (Role)
   “ฉันเป็น QA Engineer ในทีม backend เราทำงานกับ REST API และ ใช้ Jira เป็น Tool สำหรับแบ่งงาน มี Confluence ใช้อธิบายรายละเอียดของ API เส้นต่างๆ ว่ามันมีไว้ทำอะไร? ”
2. บอกว่าอยากให้ skill นี้ทำอะไร? (Task)
   “อยากได้ skill ที่ ช่วยดู API spec จาก Jira และ Confluence แล้ว Suggest test case ให้อัตโนมัติ โดยครอบคลุม happy case, error case และ edge case”
3. บอก output ที่ต้องการ? (Format)
   “output ควรอยู่ในรูปของ markdown table ที่มี คอลัมน์ Features, Testcase ID, Name, Objective, Test Data, …. ,Expected Result”

โดยเราจะเรียก prompt framework แบบนี้ว่า RTF ย่อมาจาก Role + Task + Format (นอกจาก framework นี้ยังมี framework อื่นๆอีกซึ่งทุกท่านสามารถไปหาเพิ่มเติมได้)

ตัวอย่าง Prompt

จำไว้ว่าสิ่งสำคัญคือ ยิ่งบอก Context มากเท่าไร skill ที่ได้ก็จะ fit กับการทำงานจริงมากขึ้นเท่านั้น

Act as an AI Assistant expert in creating MCP (Model Context Protocol) skills. 
Please create a skill.md file for a custom GitHub Copilot skill designed for a QA Engineer focusing on backend systems.

Goal:
Automate test case generation from API specifications found in Jira and Confluence.

Requirements:
1. Integration: The skill must be configured to use the mcp-atlassian server to fetch requirements from Jira and Confluence links provided as input.
2. Logic: Analyze the API specs and generate comprehensive test cases covering: Happy paths,Edge cases, Error cases (negative testing)
3. Output Format: Present the output as a Markdown table with the following columns: ID, Description, Input, and Expected Result.

Deliverables:
- Please provide the full skill.md content, including the necessary frontmatter (name, description, capabilities) and detailed instructions for the LLM.
- Ensure the instructions are clear, technical, and ready to be implemented.
- Output the final response as a downloadable Markdown file.

 Act as an AI Assistant expert in creating MCP (Model Context Protocol) skills.
 Please create a skill.md file for a custom GitHub Copilot skill designed for a QA Engineer focusing on backend systems.
 
 Goal:
 Automate test case generation from API specifications found in Jira and Confluence,
 following the team's established conventions defined in the reference files below.
 
 Requirements:
 1. Integration: The skill must use the mcp-atlassian MCP server to fetch requirements
    from Jira (via `jira_get_issue`) and Confluence (via `confluence_get_page` or
    `confluence_search`) when the user provides a Jira issue key or Confluence URL/title.
 
 2. Logic: Analyze the fetched API specs and generate test cases covering:
    - Happy paths / success scenarios
    - Input validation / edge cases
    - Error / negative testing scenarios
    - Business rule violations
    - Service unavailability scenarios
 
 3. Output Format: Generate test cases in an Excel-compatible table structure following
    the 16-column format defined in the Test Case Structure reference. Each column must
    be populated according to the rules in that reference.
 
 4. Naming Conventions: Follow the Test Case ID format and Test Case Name patterns
    exactly as defined in the Naming Patterns reference.
 
 5. Expected Results Format: All expected results must use the [CHK##] checkpoint format
    defined in the Expected Results reference. Each checkpoint must have a descriptive
    header and bullet-point assertions.
 
 6. Tagging & Priority: Apply tags and priority following the taxonomy in the Tags and
    Priorities reference. Every test case must have test type, service, feature, and
    priority tags.
 
 7. Scenario Coverage: Use the Scenario Coverage Checklist from the Test Scenarios
    reference to ensure completeness before finalizing output.
 
 Reference Files (include these as-is in the skill's references/ folder):
 
 --- references/test-case-structure.md ---
 {paste content of test-case-structure.md here}
 
 --- references/naming-patterns.md ---
 {paste content of naming-patterns.md here}
 
 --- references/expected-results.md ---
 {paste content of expected-results.md here}
 
 --- references/tags-priorities.md ---
 {paste content of tags-priorities.md here}
 
 --- references/test-scenarios.md ---
 {paste content of test-scenarios.md here}
 
 Deliverables:
 - Provide the full skill.md content including frontmatter (name, description, capabilities).
 - The skill instructions must reference the above files using relative paths
   (e.g., [Test Case Structure](references/test-case-structure.md)) so the LLM can
   load them at runtime.
 - Include a Workflow Decision Tree so the LLM knows when to fetch from Jira/Confluence
   vs. when to proceed from a raw spec.
 - Include a Quality Checklist the LLM must self-verify before presenting output.
 - Ensure instructions are clear, technical, and implementation-ready.

วิธีนำ Skill ของเราไปติดตั้งเข้ากับ Copilot CLI

เมื่อเราได้ Folder Skill ของเรามาเเล้วเราสามารถเอาไปใส่ใน copilot CLI ของเราได้

#1 ไปเอาไฟล์มาใส่ตรงๆ
~/.copilot/skills/<ชื่อ skill ของเรา>/

วิธีเรียกใช้ Skill ในการทำงานจริง สามารถทำได้ 2 แบบครับ:

1. เรียกใช้งานโดยตรง (Explicit Intent): บน Copilot CLI เราสามารถพิมพ์ชื่อ Skill ได้ทันที เช่น code-review หรือ create-report วิธีนี้ Copilot จะเข้าใจทันทีว่าเราต้องการเจาะจงใช้ทักษะไหนโดยไม่ต้องเดา
2. เรียกใช้ผ่านภาษาธรรมชาติ (Natural Language): วิธีนี้ง่ายและเป็นธรรมชาติที่สุด เพราะเราแค่พิมพ์สั่งงานตามปกติ แล้วระบบจะวิเคราะห์ให้เองว่าคำสั่งของเราตรงกับ Skill ไหนที่มีอยู่ จากนั้นจะโหลดมาทำงานให้อัตโนมัติ เช่น หากเราพิมพ์ว่า “ช่วยรีวิวโค้ดนี้หน่อย” และในเครื่องเราติดตั้ง Skill code-review เอาไว้ Copilot ก็จะหยิบมาใช้จัดการให้เราทันทีครับ

Tips/ข้อผิดพลาดที่มักเจอ 😣

สิ่งที่คนมักสะดุดตอนสร้าง skill ครั้งแรก

1. Frontmatter ไม่ชัดทำให้ AI ไม่ trigger skill เลย
   ปัญหาที่เจอบ่อยที่สุด คือเขียน description กว้างเกินไป เช่น “ช่วยเรื่อง QA” แบบนี้ Copilot ไม่รู้ว่าจะเรียก skill นี้ตอนไหน ควรระบุให้ชัดว่า trigger เมื่อไหร่ เช่น “ใช้เมื่อผู้ใช้ส่ง API endpoint มาและขอให้ช่วยเขียน test case”
2. Instructions ยาวเกินไปโดยไม่มีโครงสร้าง
   เขียน instructions แบบ paragraph ยาวๆ ทำให้ AI งง ควรแบ่งเป็น step หรือ bullet ชัดๆ ว่าให้ทำอะไรก่อนหลัง
3. ไม่ได้ทดสอบหลังสร้าง
   เมื่อสร้างเสร็จแล้วต้องลองจริงๆ ด้วยการส่ง input ที่หลากหลาย ดูว่า output ตรงกับที่ต้องการไหม แล้วค่อยปรับ instructions ให้แม่นขึ้น
4. สร้าง skill เดียวให้ทำทุกอย่าง
   อย่างที่กล่าวไปข้างต้น skill ที่ดีควรมีความเฉพาะเจาะจง เราไม่ควรสร้าง skill ตัวเดียวและให้มันช่วยทำทุกๆ อย่างเพราะมันอาจทำให้ ผลลัพธ์ที่ได้ออกมาไม่ดีนั้นเอง

สรุป

ถ้าอ่านมาถึงตรงนี้ คิดว่าทุกคน น่าจะพอเห็นภาพรวมของการสร้าง skill ด้วย Copilot กันเเล้วสิ่งที่ควรทำต่อจากนี้คือ ลองเอา skill ไปใช้งานจริงในงาน QA ของคุณสัก 1 สัปดาห์ แล้วสังเกตว่ามันช่วยตรงไหนได้บ้าง ตรงไหนยังขาด แล้วค่อยกลับมาปรับ instructions ให้ดีขึ้น Skill ที่ดีไม่ได้เกิดจากการเขียนครั้งเดียวแล้วสมบูรณ์ แต่เกิดจากการทำซ้ำไปเรื่อยๆ นั่นเองครับ

ขอบคุณที่อ่านจนจบครับ 🙏🏻

แหล่งอ้างอิง

• Claude Skills คืออะไร? คู่มือ Agent Skills ฉบับเจาะลึก | Saeree ERP
• Agent Skill: สอน AI Agent ให้ทำงานที่มันทำไม่ได้ | Thada W.
• Prompt Engineering: Complete Guide (2026)
• skill-creator - anthropics/skills

สอน Copilot ให้เข้าใจงานด้วย Skills was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

“ทำไมพวกเราชาว QA ถึงต้องรู้เรื่อง Infrastructure บ้างล่ะ? ทำไมไม่ปล่อยให้คนอื่นเค้าทำไป?”

ยอมรับตรง ๆ เลยค่ะว่าเป้เองก็เคยโดนคำถามนี้มาเหมือนกัน (หัวเราะ) และสารภาพตามตรงว่าคำตอบในใจ (หรือเปล่านะ) ตอนนั้นคือ “เดี๋ยวเถียงกับคนอื่นไม่ได้ค่ะ! 😂”

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

จากเดิมที่หลายคนมองว่าเรื่อง Infrastructure, การตั้งค่าคลาวด์ (Cloud Config) หรือระบบเน็ตเวิร์กหลังบ้าน เป็นหน้าที่ของฝั่ง CloudOps, Network, System, DevOps หรือ Site Reliability Engineer (SRE) ฝ่ายเดียว (ที่เยอะอยู่) แต่จากเซสชันในงาน AWS รอบนี้ และจากสิ่งที่เป้ได้เรียนรู้จากการทำงานที่ Ascend หลายปี มันทำให้เป้ตกผลึกเลยว่า:

“หาก QA ไม่รู้เรื่องพวกนี้เลย เวลาเจอ Performance Drop หรือแอปสตาร์ทไม่ขึ้น เราก็อาจจะหลงทางและมุ่งเป้าไปงมแก้แค่ที่ตัวโค้ดแอปพลิเคชันอย่างเดียว ทั้งที่จริง ๆ มันอาจจะเป็นเรื่องของการปรับจูนระหว่างตัวแอปกับ Infrastructure ให้สอดคล้องกัน ซึ่งการที่เราพอมีความรู้ในส่วนนี้บ้าง จะทำให้เราดีไซน์แผนการเทสได้แม่นยำขึ้น คุยภาษาเดียวกับทีมอื่นได้เข้าใจ และช่วยกันอุดรอยรั่วเพื่อหาส่วนผสมที่ลงตัวที่สุดให้กับระบบ โดยไม่ต้องปล่อยให้เป็นหน้าที่ของฝั่งใดฝั่งหนึ่งฝ่ายเดียวค่ะ”

และในฐานะคนที่คุมภาพรวมด้านคุณภาพของระบบ การเทสในยุคนี้ไม่ได้จบลงแค่การตรวจสอบว่าฟังก์ชันทำงานถูกหรือยิง API ผ่าน แต่คือการการันตีว่าระบบจะยังคงเสถียร ทนทาน และสามารถรองรับผู้ใช้งานในพฤติกรรมต่าง ๆ ได้ดีด้วย

ในงาน AWS รอบนี้เป้ได้เข้าไปฟังอีกหนึ่งเซสชันที่น่าสนใจมาก ๆ คือ “Developer Considerations for Overcoming Multi-Region Deployment Challenges” ซึ่งเป็นเรื่องการจัดการระบบแบบ Multi-region

เรื่องนี้ประจวบเหมาะกับที่ปัจจุบันทีมของเป้ที่ Ascend ก็มีงานเปลี่ยนจากการใช้ RDS เป็น Aurora database เพื่อรองรับการทำระบบ Multi-region นี้อยู่เหมือนกัน ที่ช่วยลดผลกระทบเมื่อเกิดกรณีที่ Site ใด Site หนึ่งล่มหรือใช้งานไม่ได้ ระบบของเราจะได้ยังมีอีก Site คอยสแตนด์บายทำงานต่อได้ทันที มันก็ทำให้เข้าใจเบื้องลึกมากขึ้นว่า ทำไมทีมถึงเปลี่ยนจาก RDS มาใช้ตัว Aurora DB รวมไปถึงดีเทลการตั้งค่า Config โหมดต่าง ๆ ของ Aurora เพื่อรองรับการสเกลข้าม region รวมทั้งได้เห็นตัวอย่างการเซตดีไซน์ระบบการทำ Multi-region ที่ทาง AWS แนะนำเป็นอย่างไร

และจริง ๆ แล้วทาง Ascend เองมีการวางระบบ Infrastructure หลังบ้านที่ดีมาก ๆ อยู่แล้ว ซึ่งพี่เต้ Head of platform Engineering ที่ Ascend money ได้มาแชร์ในงาน AWS ปีนี้เช่นกันในหัวข้อ “4 AWS EKS Configurations That Unlock Scale” ทุกคนสามารถตามไปอ่านแบบ Full Detail ได้จากโพสต์ของ พี่เต้ ตามลิงก์นี้ได้เลยนะคะ 👉 https://www.facebook.com/share/p/1Lm2ycMRdF/

การที่ทีม Infra ของเราวางโครงสร้างที่ยอดเยี่ยมไว้ให้ตั้งแต่แรก ส่งผลให้ทั้ง Developer และ QA สามารถนำมาใช้ต่อยอดในการสร้างและส่งมอบ Application ได้อย่างมีประสิทธิภาพ

แต่สิ่งสำคัญคือ ในฐานะ QA เราจะมั่นใจได้อย่างไรว่าค่าที่เรา Setting ไว้นั้นทำงานได้ถูกต้องตรงตามทฤษฎี?

เป้ขอยกตัวอย่างเทส Test Scenario: Probe Behavior Testing ที่ได้มีทำเพื่อพิสูจน์และตรวจสอบการตั้งค่าระบบ healthcheck ของ Kubernetes ทั้งในส่วนของความถี่ (periodSeconds) และเกณฑ์ขั้นต่ำที่ยอมให้ล้มเหลว (failureThreshold) ว่ามีความเหมาะสมกับ Service ของเราหรือไม่ โดยเราสามารถดูข้อมูลผ่าน Kube log ได้ เพื่อเช็กพฤติกรรมหลังบ้านได้ค่ะ จริง ๆ อันนี้มี work กับ Devopsให้ช่วยเอา Kubernetes log จาก Cloud Watch ออกมาให้ดู

เป้าหมายสำคัญของการทำ Probe Behavior Testing ในสเตปนี้คือ:

1.เช็กความถูกต้องของการตั้งค่า (Probe Configurations): เมื่อระบบทำงานภายใต้ภาวะไม่ปกติ เช่น กรณี Database ล่ม ระบบต้องมีการจัดการทราฟฟิกและฟื้นฟูระบบได้อย่างถูกต้องและเหมาะสมตามเงื่อนไขที่กำหนด โดยจะตรวจสอบดังนี้

• Readiness Probe: ในช่วงที่ Container ยังไม่พร้อมใช้งาน ระบบจะส่ง Probe ไปตรวจสอบตามความถี่ (periodSeconds) และจำนวนครั้ง (failureThreshold) ที่ตั้งค่าไว้

หากผลการตรวจสอบเป็น Fail ระบบจะต้องหยุดจ่ายทราฟฟิกไปยัง Pod นั้นทันที

ผลลัพธ์ที่คาดหวัง: หากมีการส่ง Traffic เข้ามาในช่วงที่ Pod ไม่พร้อมใช้งาน ระบบจะต้องตอบกลับด้วย HTTP Status 503 Service Unavailable

• Liveness Probe: ตรวจสอบว่าระบบมีการสั่งรีสตาร์ท (Restart) Pod เพื่อฟื้นฟูการทำงานโดยอัตโนมัติทันทีเมื่อ Probe เกิดสถานะ Fail ครบตามเงื่อนไข

2.วัดเวลาการ Startup ของแอปพลิเคชัน: เช็กว่าเวลาที่แอปใช้ในการเปิดระบบขึ้นมา (Application Startup Time) มันช้าเกินกว่าค่า startupProbe ที่เรา Setting ไว้หรือไม่ เพราะถ้าแอปใช้เวลาโหลดชิ้นส่วนภายในช้าเกินไป หรือตั้งค่าตัวเลขที่ไม่เหมาะสม ตัว Kubernetes จะมองว่าแอปตาย แล้วสั่งรีสตาร์ทวนไปรัว ๆ ตามที่พี่เต้ได้เตือนไว้ในบทความค่ะ

ซึ่งหากเราทำการทดสอบแล้วพบว่าแอปพลิเคชันของเราใช้เวลาสตาร์ทช้าเกินไปจริง ๆ สิ่งนี้จะเป็นสัญญาณเตือนให้ทีมต้องมาเช็กหาสาเหตุ และทำ Tuning เพื่อให้แอปพลิเคชันทำงานได้ดีขึ้นค่ะ

นอกจากนี้ บางทีในการทำ Performance Test แล้วแอปเกิดอาการ OOM (Out of Memory) หรือใช้ Memory น้อยหรือมากเกินกว่าที่ขอ หากพวกเรามีความรู้เรื่องการเซตค่า JVM Heap ต่าง ๆ บ้าง ก็จะทำให้เรามีข้อกังวลในเรื่องที่ตรงจุดมากขึ้นเวลาไปพูดคุยหรือช่วยกันวิเคราะห์ปัญหาร่วมกับเดฟและทีม Infra ค่ะ

🎯 สรุป

ยาวเลยใช่ไหมคะ? 😂 แต่เป้พยายามเล่าเพื่อให้ทุกคนเห็นภาพตรงกันค่ะว่า ทำไมเราถึงต้องรู้เรื่องเหล่านี้

การมางาน AWS ในครั้งนี้มันทำให้เราได้เห็นมุมมองหรือเรื่อง Infrastructure มากขึ้นเยอะ และย้ำว่าเราไม่จำเป็นต้องปล่อยให้มันเป็นเรื่องของคนอื่นอย่างเดียว การที่ QA มีความรู้ความเข้าใจในส่วนนี้ติดตัวไว้บ้าง จะทำให้เราเกิด Concern ที่คมขึ้น คุยกับทีมอื่นรู้เรื่อง (แถมแอบเอาไว้ใช้ Challenge คัดค้านได้อย่างมีเหตุมีผลด้วยนะ! 😉) เพื่อร่วมกันทำให้แอปพลิเคชันของเรามีคุณภาพและสเกลได้อย่างปลอดภัยที่สุดค่ะ! ✌️😊

ถอดรหัส AWS Summit ทำไม QA ต้องรู้เรื่อง Infrastructure? was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

ในปี 2026 นี้ คงไม่มีใครไม่ใช้ AI ในการทำงานแล้วใช่ไหมคะ? ปีนี้ก็เป็นอีกครั้งที่เป้ (ผู้เขียน) ได้มีโอกาสมาร่วมงาน AWS Summit Bangkok และแน่นอนว่าเป้าหมายหลักในใจรอบนี้ คือการมาพยายามมองหามุมมองและไอเดียการทำงานคู่กับ AI จากในงานเพื่อเอามาประยุกต์ใช้กับงาน QA ที่ทำอยู่

ซึ่งเทรนด์ AI ในปีนี้จะรู้เลยว่ามันขยับไปไกลกว่าปีที่ผ่าน ๆ มามาก จากที่เราเคยมองมันเป็นแค่ผู้ช่วยคิด ช่วยเจนเทสเคส หรือเทสสคริปต์สั้น ๆ หยิบมาช่วยเป็นครั้งคราว แต่ในงาน AWS ปีนี้ ชัดเจนมากว่ามันได้เข้ามาแทรกซึมในทุก ๆ กระบวนการพัฒนาซอฟต์แวร์ (SDLC) ตั้งแต่ต้นน้ำจนถึงปลายน้ำ จนกลายเป็น AI-Driven Development Lifecycle (AI-DLC) เต็มรูปแบบ

สิ่งนี้ทำให้เห็นภาพชัดขึ้นเลยค่ะว่า งานของพวกเราชาว QA ขยับขึ้นมาเป็น “QA Orchestrator” หรือผู้ควบคุม วางทิศทาง และตรวจรับงานจาก AI อีกทีหนึ่ง ลองนึกภาพตัวเราเป็น “วาทยกร (Conductor)” ที่ยืนคุมอยู่หน้าเวที เราไม่ได้ลงไปเล่นเครื่องดนตรีเองทุกชิ้น (หน้าที่ทำของถึก ๆ ปล่อยให้ AI จัดการ) แต่หน้าที่ของเราคือคอยโบกไม้คุมจังหวะ สั่งงาน และตรวจสอบว่าผลลัพธ์ที่ออกมาถูกต้อง ไพเราะ และไม่มีจุดไหนหลุดคีย์

ในบทความนี้ เป้เลยตั้งใจจะพาทุกคนมาส่องแนวคิด AI-DLC ไปด้วยกัน มาดูกันว่าเราจะทำ “Left-shifting QA” (คำฮิตในวงการช่วงนี้ ที่หมายถึงการย้ายกระบวนการเทสและตรวจสอบคุณภาพขึ้นไปไว้ตั้งแต่ต้นน้ำ) ด้วยพลังของ AI ได้ยังไงบ้าง รวมทั้ง Real world use cases จาก 2 sessions ในงานมารีวิวให้ฟังกัน ดังนี้ค่ะ:

• Use cases 1: จาก Tackling Anti-patterns with AI-Driven Development Lifecycle (AI-DLC) Session โดย คุณ Anan Phupengjai, Expert QA Engineer, Axons / CP Foods: ที่เขาหยิบเอาแนวคิด AI-DLC ไปประยุกต์ใช้กับงาน QA จนเกิดเป็น Autonomous Testing ในสเกลงานจริง
• Use cases 2: จาก Effectively using AI Assistants to Accelerate Development Session โดย คุณ Phuwadon Potithong, CTO, WiPay: มาแชร์การ workflow การทำงานกับ AI เจาะลึกเทคนิคการสร้าง AI Agent Instruction พร้อมเคล็ดลับการประหยัด Token ไม่ให้บอท Burn เงินโดยเปล่าประโยชน์

ก่อนที่เราจะเข้าเรื่อง AI-DLC อยากจะมาแชร์เรื่อง Anti-pattern กันก่อน มันเป็นพฤติกรรมที่คนทำงานมักจะพลาดเวลาใช้ AI (ซึ่งสารภาพว่าเป้อาจจะจำได้ไม่ครบร้อยเปอร์เซ็นต์นะคะ 😅) ที่ทาง AWS รวบรวมมา และตัวโมเดล AI-DLC นี้ทาง AWS ก็พัฒนามาเพื่อแก้ไขปัญหาพวกนี้ด้วยค่ะ แต่จะมีอะไรบ้างมาดูกันเลยค่ะ…

AI Anti-pattern

1. Avoid Vibe Code: ให้ ‘พยายามเลี่ยง Vibe Code’ อ้าว… ฟังตอนแรกแอบงงใช่ไหมคะ? เป้ก็งงค่ะ! แต่ที่งงไม่ใช่อะไรนะ… คือไม่รู้ว่ามันคืออะไร ฮ่า ๆ ๆ

สำหรับใครที่ไม่รู้เหมือนกัน ไปหาข้อมูลมาให้ละค่ะ มันคือสไตล์การพัฒนาซอฟต์แวร์ที่ปล่อยให้ AI เขียนโค้ดรัว ๆ จนได้แอปขึ้นมา โดยที่เราแค่นั่งบอกไอเดียชิล ๆ สั่งงานตามมู้ด (Vibes) แบบที่ไม่ต้องลงไปเข้าใจโค้ดอะไรขนาดนั้น… สบายไปเลยดิ!

แต่พออ่านความหมายลึก ๆ แล้วแอบกลัวเหมือนกันนะคะ เพราะถ้าเราปล่อยให้ AI เขียนโค้ดไปเรื่อย ๆ โดยที่เราไม่รู้จักหรือไม่ได้เข้าใจการทำงานของมันจริง ๆ น่าจะเจอบั๊กเยอะแน่ค่ะ! แล้วความน่ากลัวนี้ไม่ได้อยู่แค่ฝั่งเดฟนะคะ ในมุมของ QA อย่างเรา ๆ ถ้ายืมมือ AI มาช่วยเขียนเทสสคริปต์แบบปล่อยใจตาม Vibe โดยไม่ตรวจเช็กตรรกะ (Logic) ให้ดี บอกเลยว่ามีหลุดแน่นอน! เพราะ AI มันก็เนียนเจนสคริปต์หลอกตาเราได้เก่งเหมือนกัน ดังนั้นงานจะรีบแค่ไหนก็อย่ารีบค่ะ 😂

2. Ask AI to do small, simple tasks: ก็ตามชื่อเลยค่ะ เวลาสั่งงาน AI อย่าโยนงานใหญ่ ๆ หรือโปรเจกต์ยักษ์ให้มันทำทีเดียวทั้งหมด ไม่งั้นตอนมันแก้กลับมาทีเราต้องมานั่งรีวิวกันหนักหน่วงมากเลยนะ ให้พยายามแตกเป็น Task ย่อย ๆ ง่าย ๆ ให้มันทำทีละสเตปดีกว่าค่ะ อย่าไปคิดเอาเองว่ามันเก่ง เดี๋ยวโยนไปตู้มเดียวมันจะทำสำเร็จแน่ ๆ

3. Manage Context window careful: ข้อนี้อยากชวนทุกคนมาลองสังเกตตัวเองกันดูค่ะว่า เวลาที่เราคุยงานกับ AI เนี่ย… เราคุยสลับไปสลับมาหลาย ๆ เรื่องในห้องแชทเดิมกันอยู่หรือเปล่า? แล้วเคยได้กด Reset หรือเริ่ม New Chat ใหม่กันบ้างไหมคะ? ซึ่งการที่ไม่ทำมันทำให้ AI เริ่มสับสน ถือบริบทเก่ามาปนเรื่องใหม่ และทำให้เราได้คำตอบที่ไม่ถูกต้องเยอะขึ้นเรื่อย ๆ เป็นสิ่งที่ต้องระวัง

4. Don’t trust AI as you trust a Sr. Engineer: ให้เรามอง AI เป็นแค่ “Intern ที่เก่งมาก” ก็พอ แต่อย่าเพิ่งไปไว้ใจมันระดับ Senior Engineer สิ่งที่เราต้องทำคือ ‘ต้องระบุเงื่อนไขให้ชัดเจน’ ไปเลยค่ะว่าอยากให้ทำแบบไหน ผลลัพธ์ต้องออกมาหน้าตาเป็นยังไง มีข้อห้ามอะไรบ้าง อย่าปล่อยให้ AI มันเดาหรือแอบคิดไปเองเด็ดขาดค่ะ! เพราะถ้าเราสั่งงานแบบกว้าง ๆ หรือกำกวมเมื่อไหร่ AI มันจะเริ่มใช้จินตนาการตรรกะของมันเองทันที

อ้อ! แล้วในเซสชันเค้าแชร์เคล็ดลับอีกอันที่ดีมาก ๆ คือ ให้สั่งกำชับมันไว้เลยว่า “อันไหนไม่แน่ใจให้มาถามเราก่อนทุกครั้ง ห้ามคิดไปเอง” ซึ่งในมุมของงาน QA ถ้าปล่อยให้ AI เดาสเปกหรือปล่อยมันคิด logic การเทสแบบที่ไม่ถูกต้องขึ้นมา… บอกเลยว่าบันเทิงแน่นอนค่ะ ฮ่า ๆ

สุดท้ายแล้ว “เราคือเจ้าของงาน” ดังนั้นเราต้องทำการรีวิวทุกครั้ง ย้ำ! อย่าลืมรีวิวนาจา และที่สำคัญคืออย่าปล่อยโค้ดหรือสคริปต์ที่ AI เจนออกมาดุ่ย ๆ แล้วโยนให้คนอื่น (Team Reviewer) รีวิวให้อย่างเดียวด้วยนะคะ ไม่งั้นจะกลายเป็นสร้างงานหยาบและเพิ่มภาระให้ PR Reviewer แทนค่ะแถมอาจจะโดนบ่นด้วยนะ 🤣

ซึ่งจาก Anti-pattern ข้างต้น ทาง AWS เลยพัฒนามาเป็น AI-DLC คอนเซปต์หลัก ๆ ของมันคือ อยากให้ AI ทำอะไรเราบอกมันไปได้เลย แต่กระบวนการทำงานจะเปลี่ยนไป คือ เราจะขยับมาเป็นคนคุมและคอย ‘Validate’ (ตรวจสอบ) สิ่งที่ AI ทำในทุก ๆ สเตป ไม่ปล่อยให้มันคิดเองเออเอง

ในเซสชันเค้าได้โชว์ภาพ The Operating Model for AI

ถ้าดูจากแผนภาพวงกลมในรูป จะเห็นเลยว่าลูปการทำงานร่วมกับ AI จะเริ่มจาก AI Creates Plan ➡ Humans Verify the Plan ➡ AI Refines the Plan ขั้นตอนนี้สะท้อนเรื่องห้ามปล่อยใจไปกับ Vibe สุด ๆ ค่ะ เพราะเริ่มแรก AI จะยังไม่เขียนโค้ดทันที แต่มันจะไปคิดและเขียนแผนงาน (Plan) มาให้เราดูก่อน จากนั้น มนุษย์ (ซึ่งก็คือพวกเรา) ต้องเป็นคน Verify ตรวจสอบแผนงานเสมอ ถ้าตรงไหนยังไม่เคลียร์หรือไม่ตรงสเปก เราก็บอกมันได้ ให้มันไปเขียนแผนมาใหม่ วนลูปแบบนี้ไปค่ะจนกว่าจะได้ Final Plan ที่สมบูรณ์ร่วมกัน

หลังจากนั้น AI Executes the Plan ➡ Humans Verify the Outcome พอแผนนิ่งปุ๊บ AI มันก็เริ่มรันงานตามแผนทันที และเมื่อมันทำเสร็จ หน้าที่สำคัญที่สุดของพวกเราก็คือการกลับมา Verify ผลลัพธ์สุดท้าย ว่าทำงานได้ถูกต้อง ปลอดภัย และไม่มีอะไรหลุดค่ะ

ย้ำกันอีกทีจากสไลด์ของ AWS เลยค่ะว่า ไม่ว่า AI จะเก่งและ Autonomous แค่ไหน ‘มนุษย์ก็ยังต้องอยู่เป็นศูนย์กลางในฐานะ Verifier เสมอ’ ยิ่งในมุมของ QA หน้าที่สแกนความถูกต้องตรงนี้ยิ่งทวีความสำคัญขึ้นไปอีกในยุค AI-DLC เพื่อขยับตัวไปเป็น QA Orchestrator ที่คุมภาพรวมได้อย่างมั่นใจค่ะ

หลังจากที่เราเข้าใจกติกาการอยู่ร่วมกันใน Operating Model แล้ว ทีนี้เรามาดูภาพกว้างของขั้นตอนการทำงานจริงที่ทาง AWS นำเสนอในสไลด์ AI-Driven Development Lifecycle (AI-DLC) นี้กันค่ะ

วงจรนี้ถูกแบ่งออกเป็น 3 ช่วงหลัก (Inception, Construction, Operation) ดังนี้ค่ะ:

1.Inception: จุดนี้คือที่มาของคำว่า ‘Context’ กระบวนการจะเริ่มจากการป้อน Input ต่าง ๆ ไม่ว่าจะเป็นไฟล์โจทย์ ความต้องการของระบบ หรือถ้าเป็นการแก้ไขระบบเดิม AI ก็จะเข้าไปศึกษาทำความเข้าใจกับซอร์สโค้ดเดิมที่มีก่อนหน้า จากนั้นหน้าที่สำคัญของพวกเราคือการเข้าไป Clarify สิ่งต่าง ๆ ร่วมกับ AI ค่ะ พอคุยกันจนเคลียร์ปุ๊บ AI มันก็จะเจน User Stories ออกมา ที่เหมือนเป็นชุด Requirement ชุดนึงและแตกเป็น Units of Work เล็ก ๆ ออกมา

ซึ่งเฟสนี้แหละค่ะที่เป้มองว่า ถ้าทีมเราเอาแนวคิดนี้มาใช้ มันจะเป็นจุดที่ QA อย่างเราต้องรีบกระโดดเข้าไปเช็กความถูกต้องตั้งแต่ต้นน้ำ เป็นการทำ Left-shifting QA ของจริง เพื่อให้แน่ใจว่า Tasks ย่อย ๆ ที่ได้ออกมานั้น มันถูกต้อง ตรงสเปก และมีคุณภาพตั้งแต่วันแรกที่ยังไม่ได้เริ่มเขียนโค้ดเลยค่ะ ทั้งนี้ก็เพื่อป้องกันและสกัดกั้นให้บั๊คเกิดน้อยที่สุดเท่าที่จะเป็นไปได้นั่นเองค่ะ

2. Construction: เมื่อแผนนิ่ง AI ก็จะเริ่มสร้างแล้ว ตั้งแต่การ เขียนโค้ด, การ Generate Tests รวมไปถึงการวางโครงสร้างระบบ (Infra) เพื่อเตรียม Deploy จุดนี้งานเราคือการรีวิวสิ่งที่มันเจนออกมาว่า ‘เทสที่ AI เขียนให้เนี่ย มันครอบคลุมจริงไหม?’ หรือมันแอบข้ามขั้นตอนอะไรไปหรือเปล่า

3. Operation: สุดท้ายคือการนำงานที่สร้างเสร็จไปรันบนโปรดักชันจริงด้วยและมีระบบ AI คอยช่วยจัดการเวลาเกิดปัญหา (Incidents) ให้ด้วยค่ะ

เอาล่ะค่ะ ทีนี้เราลองมาดูของจริงในชีวิตจริงกันบ้างดีกว่าค่ะ ว่าในชีวิตการทำงานจริง เค้าหยิบเอาแนวคิด AI-DLC ไปประยุกต์ใช้กับหน้างาน QA จนเกิดเป็น Autonomous Testing ได้อย่างไร… มาดูกันเลยค่ะ! 👇

🚀มาเริ่มกันที่ Use Case แรก กันเลยค่ะ

โดยเซสชันนี้คุณ Anan Phupengjai, Expert QA Engineer, Axons / CP Foods ได้เริ่มต้นด้วยการลิสต์ปัญหาคลาสสิกที่เจอจากการทำงานในชีวิตประจำวัน มันเป็นปัญหาที่พวกเราชาว QA น่าจะเจอคล้าย ๆ กันหมด นั่นคือ

ปัญหาที่ 1: การเขียน Test Case ที่ใช้เวลานาน ปกติหลังจากเปิด Sprint มา เรามักจะต้องใช้เวลาปั้นเทสเคสกันไปแล้ว 1–2 วัน

หรือขอยกตัวอย่างตัวเองบ้างที่เป้พยายามทำในหลาย ๆ สปริ้นเลยคือ การเร่งดราฟต์เทสเคสให้เสร็จเท่าที่จะทำได้ให้ทันก่อนเริ่ม Sprint Planning ซึ่งเอาจริงๆ ในทีมก็ไม่ได้มีใครมาบังคับนะคะ แต่คือพยายามอยากให้งานเทสมันวิ่งควบคู่ไปพร้อม ๆ กับงานเดฟให้ได้ และที่สำคัญคือ การที่เราคุยเรื่องเทสเคสทั้ง Unit test และเคสที่เอาไปเขียน Automate script กันตั้งแต่เนิ่น ๆ มันช่วยทำให้เดฟและเราเองด้วยไม่ตกหล่นเคสสำคัญตอนเขียนโค้ด แถมยังเปิดโอกาสให้ทีมได้เข้ามา discuss สเปกและข้อกังวลต่าง ๆ ร่วมกันตั้งแต่งานยังไม่ทันเริ่ม Dev เลย มันคือการทำ Shift-Left QA เพื่อคุมคุณภาพตั้งแต่ต้นน้ำ …แต่ก็นั่นแหละค่ะ กว่าจะเค้นดราฟต์ออกมาให้ทันก่อนแพลนนิ่งได้ในแต่ละรอบ บอกเลยเหนื่อยเหมือนกันค่ะ 😭

ปัญหาที่ 2: การทำ Automate test script ที่เขียนออกมาได้ช้าถ้าประสบการณ์ยังไม่เยอะ

ปัญหาที่ 3: UI change ที่ต้องใช้เวลาแก้ไข script หรือใช้เวลา maintain มาก

ซึ่งจากปัญหาทั้งหมดนี้ทางทีม Axons เค้าได้เซ็ตลูปการทำงานกับ KIRO + MCP ออกมาเป็นสเตปตามนี้เลยค่ะ:

• Step 1: เริ่มจากการให้บอทเข้าไปอ่านตัวงานโดยตรงจาก PBI (Product Backlog Item) Board ผ่าน MCP
• Step 2: จากนั้นให้ AI ปั้นและเขียน Test Case ออกมาให้ โดยมันจะเขียนตามโครงสร้างที่เราได้สั่งและล็อกสเปกกำชับเอาไว้ใน Instruction File
• Step 3: เมื่อ AI เจนเสร็จ หน้าที่ของ QA คือเข้ามาตรวจสอบความถูกต้อง

ซึ่งวิธีนี้ทำให้ QA เขาไม่ต้องเริ่มสร้างเทสเคสจากหน้าเปล่า เปลี่ยนเป็นเริ่มจากเทสเคสที่ไปใช้งานได้ตั้งแต่วันแรกของ sprint กันเลยค่ะ

หลังจากนั้นการสร้าง automate test script ก็ใช้ Doc ต่าง ๆ ป้อนให้ AI เขียนเทสสคริปต์ให้และจบด้วยให้ QA รีวิวตัวสคริปต์

จากตัวอย่าง Use Case แรกนี้ ทุกคนจะเห็นภาพได้ชัดเจนมากเลยใช่ไหมคะว่า เราได้ทำการลดบทบาทจากการเป็น ‘ผู้เขียนสคริปต์เองทั้งหมด’ ขยับขึ้นมาเป็น ‘ผู้ควบคุมและดูแลภาพรวมแทน (QA Orchestrator)’ งานถึก ๆ งานเขียนสคริปต์ยาว ๆ ที่เคยสูบพลังชีวิตเราไป ปล่อยให้เป็นหน้าที่ของ AI-DLC ลุยไปเลยค่ะ ส่วนเราใช้ประสบการณ์และ Logic ในการคุมทิศทางเพื่อการันตีคุณภาพแทน!

แต่ใด ๆ ก็ตาม… ท่ามกลางความสะดวกสบายของ Use Case แรกนี้ มันก็แอบมีเรื่องน่ากังวลแฝงอยู่เหมือนกันนะ ‘อย่าปล่อยให้ความสบายนี้ มาทำให้ Base Skills ที่เราควรจะมีในฐานะ QA หายไปเด็ดขาดนะคะ’ เพราะอย่าลืมว่า ถ้าเราไม่มีทักษะพื้นฐานในการคิด Logic ไม่มีสกิลการออกแบบ Test Case หรืออ่านสคริปต์ไม่แตกด้วยตัวเองตั้งแต่แรก… เราจะขยับขึ้นมาเป็น QA Orchestrator ที่คอยคุมบอทและคอยตรวจรับงานให้ถูกต้องได้อย่างมั่นใจได้ยังไงจริงไหมคะ? บอทเจนไม่ถูกต้องมาเราก็ดูไม่ออกพอดี ดังนั้น ใช้ AI เป็นผู้ช่วยได้ แต่อย่าทิ้งสกิลติดตัวของเราเด็ดขาดค่ะ!

🚀 ไปต่อกันที่ Use Case ที่สอง!

Session นี้ทางคุณ Phuwadon Potithong, CTO, WiPayได้มาร่วมแชร์แนวคิดและเทคนิคการสร้าง AI Agent Instruction ที่ดีค่ะ

ก่อนที่จะไปดูแนวทางการเขียนคำสั่งคุมบอท ทาง WiPay ได้แชร์ให้เห็นถึง Developer Bottleneck (คอขวดในฝั่งพัฒนาซอฟต์แวร์) ในยุคที่ทีมยังไม่ได้ใช้ AI โดยสไลด์นี้ได้สรุปความท้าทายหลักออกเป็น 3 ด้าน

อันแรกคือการรอคิว Developer ไม่ว่าจะเป็นการขอฟีเจอร์ใหม่ การทำระบบออโตเมชัน หรือการเขียนสคริปต์จัดการข้อมูล ต่อมาคือปัญหาเรื่องช่องโหว่ด้านความปลอดภัยต่าง ๆ ที่หลุดรอดไป และสุดท้ายการปล่อยของที่ล่าช้า

เพื่อแก้ปัญหาคอขวดดังกล่าว WiPay ได้นำเสนอโมเดลการทำงานรูปแบบใหม่ที่เรียกว่า ‘Codified Standards + AI’ ซึ่งเป็นการเปลี่ยนจากเดิมมาเป็นการบันทึกและแปลงให้อยู่ในรูปแบบของ Instruction Files เพื่อให้ AI สามารถนำมาตรฐานเหล่านี้ไปปรับใช้ในสเกลใหญ่ได้กับทุกทีม โดยแบ่งหน้าที่ความรับผิดชอบออกเป็น 3 ส่วนสำคัญตามสไลด์ดังนี้ค่ะ:

1. Developer กำหนดกฎเหล็กและมาตรฐานระบบ
2. QA / Analyst แปลงมาตรฐานเหล่านั้นให้เป็นไฟล์ Structured Markdown เพื่อให้ AI สามารถอ่านและนำไปทำตามได้อย่างถูกต้องแม่นยำ
3. AI Agent อ่านไฟล์คำสั่ง (Instruction File) แล้วรับหน้าที่เจนโค้ดที่ถูกต้องตามมาตรฐานและเงื่อนไขความปลอดภัย

ทาง WiPay ได้แบ่ง Instuction file ออกเป็นหลาย ๆ ไฟล์โดยครอบคลุมทุก ๆ งาน

มาถึงตรงนี้แล้วไม่แน่ใจว่ามีใครเคยสงสัยคล้าย ๆ กับเป้ไหมคะว่า แนวทางการเขียนและจัดการไฟล์ Instruction นั้น เราควรจะเขียนกฎทุกอย่างรวมกันไว้ในไฟล์เดียว หรือควรจะแยกไฟล์ดี? แล้วถ้าแยก… ควรมีเกณฑ์ในการแยกอย่างไร? ซึ่งทาง WiPay เลือกที่จะ ‘แยกไฟล์ Instruction ออกตามโมดูลงาน และตั้งเงื่อนไขให้ AI เลือกอ่านเฉพาะเท่าที่จำเป็น’ ซึ่งวิธีนี้นอกจากจะช่วยให้ AI ทำงานได้โฟกัสและมีประสิทธิภาพแล้ว ยังเป็นคีย์สำคัญในการช่วยประหยัด Token (ลดค่าใช้จ่าย) ได้ดีเยี่ยมอีกด้วยค่ะ

นอกจากเทคนิคการจัดโครงสร้างไฟล์แล้ว ทาง WiPay ยังแชร์แนวทางปฏิบัติที่ดีในการเขียน Instruction สำหรับควบคุม AI ออกเป็น 4 ข้อสำคัญ โดยเปรียบเทียบสิ่งทีควรทำและสิ่งที่ควรหลีกเลี่ยงไว้ดังนี้ค่ะ:

1. Be Specific, Not Vague

✅ Do: ระบุความต้องการและรูปแบบที่ชัดเจน

❌ Avoid: ใช้คำกว้าง ๆ ที่ไม่มีทิศทางชัดเจน

ตัวอย่างถ้าเราสั่ง AI แค่ว่า ‘อยากได้ระบบที่ปลอดภัย’ สิ่งที่เกิดขึ้นคือ AI จะพยายามประโคมดึงฟีเจอร์ความปลอดภัยทุกระบบเท่าที่มันคิดได้ใส่เข้ามาแบบจัดเต็ม ซึ่งนอกจากจะเกินความจำเป็นแล้ว ผลลัพธ์คือมันจะแอบ Burn Tokenโดยเปล่าประโยชน์ ดังนั้นเราควรระบุไปเลยว่าต้องการระบบความปลอดภัยและการทำ Encryption แบบไหนที่เฉพาะเจาะจงไปเลย

2. State Non-Negotiables Explicitly

✅ Do: ประกาศกฎห้ามฝ่าฝืนเป็นข้อ ๆ อย่างตรงไปตรงมา เช่น “กฎเหล็กที่ยอมความไม่ได้: 1. ห้ามทำ… 2. ต้องทำ… เสมอ” โดยเฉพาะเรื่องของมาตรฐานระบบ ความปลอดภัย หรือเงื่อนไขสำคัญ อะไรที่ไม่ควร Compromise ก็ต้องระบุห้ามเด็ดขาดตั้งแต่แรก เพื่อไม่ให้ AI มีช่องว่างในการคิดยืดหยุ่นเอง

❌ Avoid: ใช้คำขอร้องหรือคำที่ดูลังเล เช่น “พยายามหลีกเลี่ยงการส่งข้อมูล PII ไปยังบราวเซอร์” เพราะเมื่อไหร่ที่เราใช้คำที่ดูอ่อนข้อ AI จะตีความว่าเป็นเพียงคำแนะนำสไตล์ Option เสริม ไม่ใช่ข้อบังคับที่ต้องทำตาม 100% ค่ะ

3. Show Code Examples

✅ Do: แนบตัวอย่างแพทเทิร์นโค้ดที่ถูกต้องเวลาเรารีวิวโค้ดกันอันไหนดีไม่ดีเขียนไปเลยให้ AI มันเห็นว่าแบบนี้เรียกว่าดีนะให้ AI เห็นภาพชัดที่สุด

❌ Avoid: อธิบายเป็นความเรียงหรือตัวอักษรยาว ๆ เพียงอย่างเดียว เพราะ AI อาจจะตีความข้อความเหล่านั้นคลาดเคลื่อนได้

4. Version and Maintain

✅ Do: คอยอัปเดตไฟล์ Instruction ทุกครั้งเมื่อมาตรฐานระบบมีการเปลี่ยนแปลง และ ให้ QA ทำหน้าที่เป็นเจ้าของในการควบคุมเวอร์ชัน เพื่อรักษามาตรฐานให้ใหม่อยู่เสมอ

❌ Avoid: เขียนครั้งเดียวแล้วปล่อยทิ้งไว้ (Write once and forget) เพราะไฟล์คำสั่งที่ล้าสมัย จะส่งผลให้ AI เจนโค้ดที่ตกรุ่นและสร้างปัญหาตามมาในภายหลัง

🎯 สรุป

ภาพรวมทั้งหมดจากทั้ง 2 Use Cases ในงาน AWS Summit รอบนี้ ทำให้เราได้เห็นปลายทางของการทำงานร่วมกับ AI ในยุค AI-DLC อย่างชัดเจนค่ะ สังเกตได้ว่าหน้าที่ของ QA ไม่ได้ถูกลดทอนลงไปเลย เพียงแต่เปลี่ยนรูปแบบจากการลงแรงทำงานซ้ำ ๆ มาเป็นการใช้ทักษะและประสบการณ์ในฐานะ QA Orchestrator เพื่อกำหนดทิศทาง ควบคุมมาตรฐาน และตรวจรับงานแทน

และสิ่งสำคัญที่สุดที่จะทำให้เราก้าวขึ้นมาทำหน้าที่นี้ได้อย่างมั่นใจ คือการไม่ละทิ้งทักษะพื้นฐานของตัวเอง ควบคู่ไปกับการฝึกฝนทักษะใหม่อย่างการออกแบบ Instuction file เพื่อควบคุม AI ให้ทำงานได้อย่างมีประสิทธิภาพและคุ้มค่าที่สุดนั่นเองค่ะ! 😊

ถอดรหัส AWS Summit เมื่อเราต้องขยับสู่บทบาท ‘QA Orchestrator’ was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design infrastructure for multi-region deployment

There were 2 sessions I joined about this topic, which I was interested in because my company is also starting to do multi-region deployment. The first one in the morning explained how creating multi-AZ or multi-region workload to support high availability is not as simple as copying your workload to another AZ. For Active-standby setup, you need to have lots of manual work to switch over if your data is not synced between 2 zones. It is better to aim for active-active setup where you can switch over with no hassles.

First, we need a database that can replicate between 2 sites automatically, and Aurora is the suggested solution. Aurora have a shared storage that copies data between each AZ automatically and can sync data to other region too. The session goes further to explain the difference between the eventual consistency and strong consistency mode in Aurora, which you can pick according to your needs. For example, in Social Network applications, it is still acceptable to not see the latest updates in your news feed instantly. This means eventual consistency in data is ok in this case. The higher consistency comes with a higher cost of the time required to replicate the data.

For managing session, it is suggested to use stateless session management like JWT. And for caching, when you use ElastiCache (which do async replication) and you want to ensure strong consistency, you can attach metadata, like a timestamp or a flag, that indicate whether the local read has the latest data you want or not. If not, then you can direct to read directly from the actual DB or primary ElastiCache node.

A simple example for one-time data update:

At Region A, app update the data in DB and then update the cache of key A in ElastiCache with flag is_data_replicated=true.

Then there 2 scenarios that can happen:

Lagging: At Region B, app read data of key A from local ElastiCache, but the flag is not available or is_data_replicated=false, then it knows it does not have the latest data yet, then it can go read data from DB directly.

Caught Up: At Region B, app read data of key A from local ElastiCache and found flag is_data_replicated=true then it knows the data is latest.

In the second session in the afternoon, I learned about Aurora and Aurora DSQL which is a serverless solution that is highly-scalable and has even better support for active-active multi-region. We have in-depth details about how Aurora DSQL storage replication works with a special clock that help keeps time highly synchronized between regions, a write/read timestamp technique that helps ensure your read session get the consistent data at the time you read, and the 3 regions quorum setup that help failover the master node to another region correctly. And since it’s a managed solution, you don’t need to be concerned about any maintenance works.

Architecture patterns and AI-DLC

First part is about all the architecture patterns like microservices, event driven, SAGA, orchestrator.

Then comes to the highlight. AI-DLC which stands for AI development life cycle, from the classic software development life cycle (SDLC), is the new process that involves AI agent in every steps (Inception — Construction — Operation). In the demo, you start with a requirement document. The agent will read it and generate some questions with predefined choices to clarify the design, for example: what is the tech stack you’d like to use? which architecture patterns? You answer the questions and then it will generate a design document for you to review. After that you approve the design, it will generate the task plans for implementation. You review it again and proceed to the code generation steps, then review again. And so on, until the deployment and operate steps.

By this approach, AI can have precise context on the requirements and design by involving human as a reviewer in each steps of the life cycle. It helps prevent some anti-pattern when using AI agents which is talked about in another session. Some of examples : giving AI agent too much or too less context, agent got misled by not starting with new context, trusting the agent too much, etc. By using AI-DLC, this should lead to the output that is more accurate to what you have in mind when asking AI agents to generate codes.

I have already joined a one-day workshop about AI-DLC at my company 2 months ago. And we’re testing this approach on a real project with my team. Still waiting to see how it can help us deliver faster. The sessions here give me some confirmation on how big a change this will be on how we develop software.

And I should note that you don’t even need Kiro to use AI-DLC. You can try AI-DLC on any AI coding platforms by following the instructions here: https://github.com/awslabs/aidlc-workflows#ai-dlc-ai-driven-development-life-cycle

Modernize Legacy apps with Kiro and AWS Transform

This session began with some outlines on how legacy apps can be modernized in the scale from the basic moving to the overhaul: rehost, replatform, refactor and reimagine. Then it went on to demonstrate the approach of using Kiro, the AI-driven IDE and AWS Transform which is a CLI tool that use AI agent to analyze your legacy codes, create documents and upgrade your service from old version of language and frameworks to the modern one. For example, this can help ease the burden of migrating your old services from Java7/Spring Boot 2 to Java 21/Spring Boot 3.

Then this is backed up by the sharing from the architect at Gosoft. They shared their approach for modernize legacy services by first using AI tools to generate more documents and unit tests for the service first. After the service is modernized, they can run the unit tests to ensure nothing breaks.

Overall

There are many more interesting sessions. And these are just some glimpse from the one that I have a chance to attend with my limited time. Some might think AWS is more about infra team than developers. But that gap should have already been less and less since the DevOps culture is promoted. And now with the new era of AI, there are even more powerful tool and services catering to devs than ever. The event is full of topics about new developer tools that can empower you to build things faster and better.

In all, it is a joy to be able to participate in this AWS Summit. Many fun activity throughout the day. The catering also provides great food, snack and drinks. The venue is convenient and clean. The topics shared are useful and presented very well.

My Notes from AWS Summit Bangkok 2026 was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Consider the situation when transaction 1 (T1) is trying to update the account balance from the database, while transaction 2 (T2) is also trying to update the balance at the same time. Without a locking mechanism after T1 and T2 updates, the account balance might be incorrect. This is because both Transactions have queried the same account balance. So both transactions are updated based on the same initial balance, which will result in the incorrect update of the account balance

Let’s write some code to see the behavior of the account balance without locking

Account Entity

@Entity
@Table(name = "accounts")
@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
public class Account {

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

  @Column(nullable = false)
  private BigDecimal balance;
  
}

Service layer code implementation of no lock deductBalance

@Transactional
public Account deductBalance(Long accountId, BigDecimal amount) {
  String ThreadName = Thread.currentThread().getName();

  log.info("Thread={} | Fetching account id ={}", ThreadName, accountId));
  Account account = accountRepository.findById(accountId)
                    .orElseThrow(() -> new IllegalArguementException(
                            "Acount not found: " + accountId));

  log.info("Thread={} | Read Balance ={}", ThreadName, account.getBalance()));

  // Simulate processing delay - makes the race window wide enogh to observe
  simulateDelay(100);

  if (account.getBalance().compareTo(amount) < 0) {
    throw new IllegalStateException("Insufficient balance: ", account.getBalance());
  }

  BigDecimal newBalance = account.getBalance().subtract(amount);
  account.setBalance(newBalance)
  
  Account saved = accountRepository.save(account);

  log.info("Thread={} | Updated balance ={}", ThreadName, saved.getBalance()));

}

private void simulateDelay(long millis) {
  try {
    Thread.sleep(millis);
  } catch(InterruptedException e) {
    Thread.currentThread().interrupt();
  }
}

To properly test for a race condition in this code, we need to simulate concurrent execution by using a thread pool and submitting multiple tasks that operate on shared resources simultaneously, with the following code

private List<String> runConcurrently(int threadCount, Callable<String> task) {
  ExecutorService executor = Executors.newFixedThreadPool(threadCount);
  List<future<String>> futures = new ArrayList<>();

  for (int i = 0; i < threadCount; i++) {
    futures.add(executor.submit(task));
  }
  
  executor.shutdown();
  
  List<String> results = new ArrayList<>();
  for (Future<String> f: futures) {
    try{
      results.add(f.get());
    } catch(Exception e) {
      results.add("Error: " + e.getMessage());
    }
  }
  
  return results;
}

Let’s run with 5 threads, trying to deduct balance from the account with ID equal to 1, and each thread deducts $100 from the account. With the initial account balance of $1,000

List<String> results = runConcurrently(5, () -> {
  Account a = noLockService.deductBalance(1, 100);
  return "OK -> balance=" + a.getBalance();
})

After running the following code, let's see the result

{
  "results" : [
    "OK -> balance=900.00",
    "OK -> balance=900.00",
    "OK -> balance=900.00",
    "OK -> balance=900.00",
    "OK -> balance=900.00"
  ]
}

// SELECT id, balance FROM accounts
-------------------
|  id  |  balance |
-------------------
|  1   |   900    |
-------------------

Even though five threads attempted to deduct $100 simultaneously, the final persisted balance is $900 instead of the expected $500. This happens because each thread fetches the account state concurrently and observes the same balance value of $1000. Without any locking strategy, every thread computes the updated balance as $900 and writes it back to the database, causing later writes to overwrite earlier ones. This demonstrates the lost update problem

Pessimistic Locking

When using pessimistic locking, we prevent another transaction from updating data by locking the related rows or table. This operation will be done at the database level. So, in case another transaction tries to update the data, it must wait until the lock is released.

Pessimistic Locking Flow

1. T1 select data from the database to update the new balance
2. T1 acquires the database lock to prevent other transactions from updating the account balance data
3. T2 selects data from the database to update the new balance
4. T1 commits the updated balance to the database and releases the lock
5. T2, continue to update the new balance after T1 releases the lock

Let’s write some code to see the behavior of the account balance with pessimistic locking

Repository layer code implementation with pessimistic locking

@Repository
public interface AccountRepository extends JpaRepository<Account, Long> {

  // Generates: SELECT ... FOR UPDATE 
  // The DB places an exclusive row lock; all other writers 
  // on the same row block
  @Lock(LockModeType.PESSIMISTIC_WRITE)
  @Query("SELECT a FROM Account a WHERE a.id = :id")
  Optional<Account> findByIdWithPessimisticLock(@Param("id") Long id);
}

Service layer code implementation of no lock deductBalance

@Transactional
public Account deductBalance(long accountId, BigDecimal amount) {
  log.info("Thread={} | Acquiring FOR UPDATE lock on account id={}",
    Thread.currentThread().getName(), accountId);

  // Acquire the Lock, Block another thread to execute the code
  Account account = accountRepository.findByIdWithPessimisticLock(accountId)
      .orElseThrow(() -> 
          new IllegalArguementException("Account not found: ", accountId));
  
  log.info("Thread ={} | Lock acquired. balance={}",
        Thread.currentThread().getName(), account.getBalance());

  // Simulate processing delay - other threads are BLOCKED at the SELECT above
  simulateDelay(100);
  
  if (account.getBalance().compareTo(amount) < 0) {
    throw new IllegalStateException("Insufficient balance: ", account.getBalance());
  }

  BigDecimal newBalance = account.getBalance().subtract(amount);
  account.setBalance(newBalance)
  
  Account saved = accountRepository.save(account);

  log.info("Thread={} | Updated balance ={}", ThreadName, saved.getBalance()));
}

private void simulateDelay(long millis) {
  try {
    Thread.sleep(millis);
  } catch(InterruptedException e) {
    Thread.currentThread().interrupt();
  }
}

Let’s run with 5 threads, trying to deduct balance from the account with ID equal to 1, and each thread deducts $100 from the account. With the initial account balance of $1,000

List<String> results = runConcurrently(5, () -> {
  Account a = pessimisticLockService.deductBalance(1, 100);
  return "OK -> balance=" + a.getBalance();
})

After running the following code, let’s see the result

{
  "results" : [
    "OK -> balance=800.00",
    "OK -> balance=600.00",
    "OK -> balance=700.00",
    "OK -> balance=900.00",
    "OK -> balance=500.00"
  ]
}
// SELECT id, balance FROM accounts
-------------------
|  id  |  balance |
-------------------
|  1   |   500    |
-------------------

As you can see, we have an initial account balance of $1,000 with a pessimistic locking strategy, which allows only one thread to access the resources at a time; these threads are deducting the balance sequentially. So no race condition occurs in this case. The balance is deducted correctly with the final balance of 500$.

Type of Locks

• Shared Lock

With a shared lock, we allow multiple transactions to read the same data at the same time, but do not allow transactions to update, modify, or delete it until the shared lock is released.

BEGIN;
-- lock row update, delete operation 
SELECT * FROM account WHERE account_id = 1 FOR SHARE;

• Exclusive lock

On the other hand, an exclusive lock prevents other transactions from reading or modifying the data; if another transaction tries to acquire a shared lock or exclusive lock, it will wait until the lock is released.

BEGIN;

SELECT * FROM account WHERE id = 1 
FOR UPDATE;  -- locks row not allow read, update, delete

-- do business logic
UPDATE account 
SET balance = balance - 100 
WHERE id = 1;

COMMIT;

When to use Pessimistic Locking

• Critical financial operations
• High chance of data conflict during update, write data to the database
• Data consistency is more important than performance

Optimistic Locking

Optimistic locking uses a technique that allows multiple transactions to read and modify the same data concurrently. Instead of locking transactions via the database, the Optimistic Locking approach detects conflicts at commit time by checking a version column. If the version has changed since it was read, the update will affect zero rows, indicating a conflict.

UPDATE account 
SET balance = balance - 70, version = version + 1 
WHERE id = 1 AND version = 1

Optimistic Locking Flow

1. T1 selects data from the database with version V1
2. T2 also selects data from that database with version V1
3. T1 updates the new account balance and updates the account version from V1 to V2
4. T2 updated the new account balance with version V1 and got no row affected because T1 has updated the version V1 to V2

Let’s write some code to see the behavior of the account balance with optimistic locking

Repository Layer Code

@Entity
@Table(name = "accounts")
@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
public class Account {

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

  @Column(nullable = false)
  private BigDecimal balance;

  /**
   * Used by JPA optimistic lockig.
   * Hibernate reads this value before UPDATE and adds a
   * {@code WHERE version = ?} clause - causing a 
   * {@link jararta.persistence.OptimisticLockException} when two
   * concurrent transactions try update the same row.
   */
  @Version
  @Column(nullable = false)
  private Long version;
  
}

Service Layer Code

@Transactional
public Account deductBalance(Long accountId, BigDecimal amount) {
  String ThreadName = Thread.currentThread().getName();

  log.info("Thread={} | Fetching account id ={}", ThreadName, accountId));
  Account account = accountRepository.findById(accountId)
                    .orElseThrow(() -> new IllegalArguementException(
                            "Acount not found: " + accountId));

  log.info("Thread={} | Read Balance ={}", ThreadName, account.getBalance()));

  // Simulate processing delay - makes the race window wide enogh to observe
  simulateDelay(100);

  if (account.getBalance().compareTo(amount) < 0) {
    throw new IllegalStateException("Insufficient balance: ", account.getBalance());
  }

  BigDecimal newBalance = account.getBalance().subtract(amount);
  account.setBalance(newBalance)
  
  Account saved = accountRepository.save(account);

  log.info("Thread={} | Updated balance ={}", ThreadName, saved.getBalance()));

}

private void simulateDelay(long millis) {
  try {
    Thread.sleep(millis);
  } catch(InterruptedException e) {
    Thread.currentThread().interrupt();
  }
}

Adding the version annotation to the account entity will generate a where clause `WHERE version = ?` So when two concurrent transactions try to update the same row, it will cause an OptimisticLockException.

Let’s run with 5 threads, trying to deduct balance from the account with ID equal to 1, and each thread deducts $100 from the account. With the initial account balance of $1,000

List<String> results = runConcurrently(5, () -> {
  Account a = optimisticLockService.deductBalance(1, 100);
  return "OK -> balance=" + a.getBalance();
})

After running the following code, let’s see the result

{
  "results": [
    "OK -> balance=900.00",
    "ERROR: org.springframework.orm.ObjectOptimisticLockingFailureException: Unexpected row count",
    "ERROR: org.springframework.orm.ObjectOptimisticLockingFailureException: Unexpected row count",
    "ERROR: org.springframework.orm.ObjectOptimisticLockingFailureException: Unexpected row count",
    "ERROR: org.springframework.orm.ObjectOptimisticLockingFailureException: Unexpected row count"
  ]
}

// SELECT id, balance, version FROM accounts
-----------------------------
|  id  |  balance | version |
-----------------------------
|  1   |   900    |    2    |
-----------------------------

The result shows that with an optimistic locking mechanism, only one thread can update the account balance. While the other 4 threads are failing to update the account balance.

Retry Strategy with Optimistic Locking

With Optimistic Locking, the conflict is checked at commit time, causing the concurrent transaction to fail. In a real-life scenario, we might not want the transaction to fail during a concurrent update. So, to solve this problem, we need a retry strategy to retry updating the transaction, as shown in the following figure.

Instead of letting T2 fail when T1 has already updated the account, we add Step 5: Retry the account balance update multiple times to ensure the transaction completes.

In a high-contention scenario, multiple transactions attempt to update the data concurrently, which can lead to many failed updates and retries. This can cause a database performance problem. So, Using Optimistic locking might not be a good idea in a high contention environment

private static final int MAX_RETRIES = 5;

public Account deductBalance(Long accountId, BigDecimal amount) {
  int attempt = 0;
  
  while (attempt < MAX_RETRIES) {
    attempt++;
    log.info("Thread={} | Attempt={} for account id ={}", 
        Thread.currentThread().getName(), attempt, accountId);
    try {
      return tryDeductBalance(accountId, amount);
    } catch(ObjectOptimisticLockingFailureException ex) {
      log.warning("Thread={} | Version conflict on attempt {}. Retrying...",
        Thread.currentThread().getName(), attempt)
      if (attempt >= MAX_RETRIES) {
        throw new IllegalStateException("Could not deduct account balance for" 
          + MAX_RETRIES + "attempts due to concurrent update")
      }
    }
  // unreachable, but satisfies the complier
  throw new IllegalStateException("Unexpected state in deducting balance");
  } 
}

@Transactional
public Account tryDeductBalance(Long accountId, BigDecimal amount) {
  String ThreadName = Thread.currentThread().getName();

  log.info("Thread={} | Fetching account id ={}", ThreadName, accountId));
  Account account = accountRepository.findById(accountId)
                    .orElseThrow(() -> new IllegalArguementException(
                            "Acount not found: " + accountId));

  log.info("Thread={} | Read Balance ={}", ThreadName, account.getBalance()));

  // Simulate processing delay - makes the race window wide enogh to observe
  simulateDelay(100);

  if (account.getBalance().compareTo(amount) < 0) {
    throw new IllegalStateException("Insufficient balance: ", account.getBalance());
  }

  BigDecimal newBalance = account.getBalance().subtract(amount);
  account.setBalance(newBalance)
  
  Account saved = accountRepository.save(account);

  log.info("Thread={} | Updated balance ={}", ThreadName, saved.getBalance()));

}

private void simulateDelay(long millis) {
  try {
    Thread.sleep(millis);
  } catch(InterruptedException e) {
    Thread.currentThread().interrupt();
  }
}

Let’s try to run it again with a retry strategy, so we will test with MAX_RETRIES equal to 5, and try to run 5 concurrent threads to see the result

{
  "results": [
    "OK -> balance=700.00",
    "OK -> balance=900.00",
    "OK -> balance=500.00",
    "OK -> balance=800.00",
    "OK -> balance=600.00",
  ]
}

// SELECT id, balance, version FROM accounts
-----------------------------
|  id  |  balance | version |
-----------------------------
|  1   |   500    |    6   |
-----------------------------

When to use Optimistic Locking

• Low chance of data conflict during the update of data
• The application has more read operations than write operations
• Read latency is important
• Transactions take a long time to complete, and holding locks during the entire process isn’t feasible.

Reference

• https://dev.to/jszutkowski/pessimistic-vs-optimistic-locking-in-mysql-3hgc
• https://newsletter.systemdesigncodex.com/p/pessimistic-vs-optimistic-locking
• https://www.abstractalgorithms.dev/types-of-locks-explained-tips-for-maintaining-consistent-systems-and-avoiding-write-conflicts
• https://raigardastautkus.medium.com/optimistic-vs-pessimistic-locking-basics-of-concurrency-in-databases-2f3adb290b2f
• https://www.youtube.com/watch?v=lR6y-0RC5cc
• https://medium.com/@felipe.ascari_49171/concurrent-transactions-in-go-pessimistic-vs-optimistic-locks-part-1-2-33f866561feb
• https://medium.com/engineering-housing/optimistic-locking-overview-6b30315e759b

Manage Database Concurrency With Pessimistic and Optimistic Locking was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a software developer, we use the terminal a lot of the time, whether it is about running a backend service on a local machine, connecting to a remote server, or even finding the right file in some directory. So having a good terminal setup helps improve a lot of productivity. This article will walk through the tools and recommend setups that will help your software development productivity

Select the terminal you like

Nowadays, there are a lot of terminals tool in the market such as iTerm2, Alacritty, Wezterm, Warp, etc. So the question is “ Which terminal should we use?” Based on my experience, I found that you have to try it to find what terminal is suitable for you. If you like a terminal that enriches AI agents' tools, you might try Warp, But If you focus on simplicity and speed, you might want to try Alacritty. I recommend not using the default terminal app that comes with macOS because it offers little functionality.

Decorate your terminal

Decorating your terminal is not just about having a fancy terminal look, but need to give us information about the context of the directory you are working in. For example, when you are developing software, you want to know what git branch you are working with. So it will be great if you have a terminal plugin that tells you what branch you are on. There are a lot of ways to decorate your terminal; you can use tools like Oh my zsh, Oh my posh, and Starship.

Add an alias to your terminal

Sometimes when you has long command to type on the terminal, and you have to use it a lot of the time, it might be great if you have a way to make a shortcut of this long command using an alias

To add an alias to the terminal, open the file .bashrc ( if you use zsh, open.zshrc file instead) add alias by adding the following command

alias la='ls -a'

By adding the following command, this creates a shortcut la, for the shell command ls -a, which lists all files in the directory

To list alias that you have created, use the command alias

Recommend CLI tools

zsh-autosuggestion

zsh autosuggestion is one of the CLI tools I really like. This plugin auto- suggestion command you type in gray text, and if you press → on the keyboard, it means you accept the suggestion. This improves the speed a lot when you have to type a long command. By using zsh-autosuggestion, you just type a few letters on the terminal, then press →

To install zsh-autosuggestion in your terminal, you can use Homebrew with the following command,

brew install zsh-autosuggestions

then activate autosuggestion by adding the following at the end of the file .zshrc

source $(brew --prefix)/share/zsh-autosuggestions/zsh-autosuggestions.zsh

fd

fd is a program used for finding file, directory in your filesystem. It is similar to the command find, but much faster and simpler than the find command that comes up by default on Mac. In case you want to find a file in your system with fd, you can use the following command

fd "auth" -t f # finding a file that contain auth 

compared to the find command

find . -type f -name "*auth*"

If you are using the find command in a large project, this might take 2 minutes to list all of the files, while using fd might take less than a second

fzf

fzf (fuzzy finder) is a command line tool for filtering search list such as finding files in a directory, looking for git commits, and finding history commands that you been using. I use fzf for finding files and finding history commands. We can install Fzf using Homebrew with the following command

brew install fzf

To find a directory, I create a custom command, so when I use this command, it will change the directory automatically after completing the find from fzf. To achieve this functionality, we add the following command in file .zshrc

cdf() {
  local dir
  dir=$(fd --type d . | fzf) && cd "$dir"
}

ripgrep

ripgrep is a tool used for searching text similar to grep, but the difference is that it recursively searches in the current directory by default. To install ripgrep, use the following command

brew install ripgrep

One of my use cases is to identify the configuration in the project. For Example If you want to find which microservice is using this API. You can use it ripgrep with the following command.

rg --hidden /api/v1/user  # finding word /api/v1/user include hidden file

After running the ripgrep command, It show that 3 places contain the word /api/v1/user

jq

jq is a tool used for processing JSON in the terminal. One of the common usecase to use jq is to prettify the JSON payload. For example,

echo '{"fruit":{"name":"apple","color":"green","price":1.20}}' | jq '.'

with this command, the output will be the prettification of the JSON payload

bat

bat is a command-line tool that is enhanced from the cat command. It adds feature syntax highlight to the cat command. Install bat using the following command

brew install bat

lsd

lsd is similar to the lscommand, but lsd with more colorful and file, directory icons for a better experience. To Install lsd using the following command

brew install lsd

When installing lsd, I typically configure the following alias to facilitate more convenient usage.

alias ls='lsd' # use ls command as lsd 

alias l='ls -l'
alias la='ls -a'
alias lla='ls -la'
alias lt='ls --tree'

tmux

tmux is a program that runs on a terminal. It allow user to create multiple terminal session with in single window. This tool is very handy when we open a lot of terminals. For example In the software development process, you might have one terminal for running Docker, one terminal for running remote to the server, and one terminal for running the application. This might be chaos when we have a lot of terminals opening. So using tmux, we can combine those terminals in a single window.

To install tmux, we can use the following command

brew install tmux

Terminal tools for boosting productivity was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

สาเหตุที่ได้เลือกใช้ java.awt (Abstract Window Toolkit) ที่เป็น java library ทางด้าน GUI ของจาวา เพราะความสามารถหลากหลายทั้งสร้าง User interface หรือ การ planting image นอกจากนี้ ยังเลือกใช้งานตามข้อดีด้านล่างต่อไปนี้อีกด้วย

ข้อดีของการใช้ java.awt ยกตัวอย่าง เช่น

Lightweight

• ไม่ต้องพึ่งพา Library ภายนอก เพราะใช้เพียง library ของจาวาเองเลย ยกตัวอย่าง เช่น หากสร้าง image ด้วย jasper report ก็จำเป็นต้องมี library ของ jasper report เพิ่ม และจำเป็นต้อง manage library ที่เกี่ยวข้องให้ดีให้ไม่มี hotspot code จากการใช้งาน library ภายนอก ถ้าใครเคยใช้งาน jasper report จะทราบดีว่าหากใช้งาน library ของบาง version จะไม่ผ่าน sonar scan ต้องมี manage การ exclude และ include library

การระบุขนาดและตำแหน่งละเอียด

• เนื่องจากใน code สามารถระบุตำแหน่ง กำหนดขนาดของ image ได้อย่างแม่นยำเพราะสามารถระบุเป็นตัวเลขของตำแหน่ง และจุด pixel ได้เลย ยกตัวอย่าง เช่น สามารถกำหนดตำแหน่งของข้อความ รูปภาพ หรือเส้นแบ่งต่างๆ ได้ในระดับ pixel ผ่านคลาส Graphics2D ซึ่งเหมาะมากสำหรับสลิปที่ต้องมีหน้าตาคงที่

มี Performance ที่ดี

• เพราะการทำงานของ java.awt จัดอยู่ในระดับการทำงานที่เป็น low level Application Programming Interface ซึ่งใกล้ชิดกับฮาร์ดแวร์จึงทำงานได้ไว

Headless

• สามารถประมวลผล code ให้กลายเป็นรูปภาพโดยที่ไม่สนฮาร์ดแวร์ หรือคำนึงถึง os ที่ run เช่น run บน cloud หรือเครื่อง linux เป็นต้น

แต่ java.awt ก็มีข้อเสีย เช่น

ความยากในการเขียน Code

• คุณต้องคำนวณตำแหน่ง (x, y) เองทั้งหมด การขยับฟอร์มเล็กน้อยแต่ล่ะครั้งอาจจะหมายถึงแก้ไขโปรแกรมหลายบรรทัด ดังนั้นจึงไม่เหมาะกับรูปหรือเอกสารที่ซับซ้อน
• การใช้งานภาษาไทยจำเป็นต้องเขียน code เพื่ออ่าน font เอง เพื่อความถูกต้องของการแสดงผล

มาดูตัวอย่างของ code กัน

import java.awt.*;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;
import javax.imageio.ImageIO;

public class SimpleSlipGenerator {
    public static void main(String[] args) throws IOException {
        int width = 400;
        int height = 500;

        // 1. สร้าง Canvas ของ slip ที่เป็น BufferedImage
        //    กำหนดขนาดและประเภทของภาพ
        BufferedImage bufferedImage = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);

        // 2. รับ Graphics2D จาก BufferedImage เพื่อวาดรูป
        Graphics2D g2d = bufferedImage.createGraphics();

        // 3. set ให้ตัวอักษรและเส้นเนียนสวยไม่ดูหยาบเป็นพิกเซล
        g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
        g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_ON);

        // 4. พื้นหลัง เติมพื้นหลังสีขาวแบบเต็มพื้นที่
        g2d.setColor(Color.WHITE);
        g2d.fillRect(0, 0, width, height);

        // 5. ใส่ background สีส้มด้านบน
        g2d.setColor(new Color(255, 100, 0));
        g2d.fillRect(0, 0, width, 80);

        // 6. set ฟอนต์สำหรับหัวข้อ
        g2d.setColor(Color.WHITE);
        g2d.setFont(new Font("Tahoma", Font.BOLD, 22));
        g2d.drawString("Transfer Slip", 20, 50);
        int startY = 150;

        // 7. วาดเส้นแบ่ง
        g2d.setColor(Color.LIGHT_GRAY);
        g2d.drawLine(30, 100, width - 30, 100);

        // 8. เขียนข้อมูลการโอนเงิน
        g2d.setColor(Color.BLACK);
        g2d.drawString("From: นายร่ำรวย จ่ายเงินเยอะ", 30, startY);
        g2d.drawString("To: นายรวยกว่า นายร่ำรวย", 30, startY + 40);

        //9. วาดเส้นแบ่ง
        g2d.setColor(Color.LIGHT_GRAY);
        g2d.drawLine(30, startY + 70, width - 30, startY + 70);

        //10. เขียนจำนวนเงิน transaction Amount
        g2d.setColor(new Color(255, 100, 0));
        g2d.setFont(new Font("Tahoma", Font.BOLD, 15));
        g2d.drawString("transaction Amount 1,500.00 THB", 30, startY + 120);

        //11. เขียนวันที่และเลขที่อ้างอิง
        g2d.setColor(Color.GRAY);
        g2d.setFont(new Font("Tahoma", Font.PLAIN, 12));
        g2d.drawString("Ref: 20240327ABC123", 30, height - 50);
        g2d.drawString("Date: 27 Mar 2024, 14:30", 30, height - 30);

        //12. ปิด Graphics2D
        g2d.dispose();

        //13. สร้างรูปภาพ
        File file = new File("slip_output.png");
        ImageIO.write(bufferedImage, "png", file);

    }
}

ผลลัพธ์ของ code

จากตัวอย่างจะเห็นว่าในการใช้งานต้องมีการประกาศค่า BufferedImage และ Graphics2D มีการ set Font และสีสลับกันไปมาได้อย่างอิสระ แต่เนื่องจากการ generate slip image อาศัย codebase เพียงอย่างเดียวและเรียงข้อความจากบนลงล่างเพราะแบบนี้ผู้เขียนจึงนำ awt มาใช้เขียน slip image เพราะไม่ได้มีความซับซ้อนเพื่อให้ code มี performance ที่ดี

ข้อควรพิจารณาว่าควรใช้ awt ในการสร้างรูปนั้นๆ หรืองานนั้นๆหรือไม่ ต้องดูความซับซ้อนของรูปหรือเอกสาร เพราะยิ่งรูปมีความซับซ้อน นั้นหมายถึงการเขียน code ที่ซับซ้อนขึ้น และต้องมีการทำความเข้าใจการจดจำตำแหน่ง pixel จุด start ในการ planting image ของข้อมูลเป็นอย่างมาก อาจจะต้องพิจารณา tool หรือ libraty อื่นๆในการสร้าง image หรือไฟล์นั้นแทน

อ้างอิง

https://www.oracle.com/java/technologies/painting.html

Java AWT Tutorial - GeeksforGeeks

แนะนำการสร้าง Image Slip ด้วย java.awt was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

ปีนี้ปีม้าไฟ พลังงานมันพลุ่งพล่านจนหลายคนอยากจะรีบควบม้าออกไปสร้างเนื้อสร้างตัว แต่ในฐานะที่ผมควบม้า (และตกม้า) ในวงการ Dev มาเกือบ 10 ปี ผมเห็นน้องๆ สหายรุ่นใหม่หลายคนกำลังวิ่งเข้าหา “กับดัก” เดิมๆ ที่ผมเคยพลาดมาแล้ว วันนี้ผมไม่ได้จะมาชวน Code แต่จะมาทำ Life Review 6 ข้อที่ผมอยากให้คุณระวังก่อนจะแบกหนี้จนวิ่งไม่ออกในปีนี้

1. รถป้ายแดง: กับดักความโก้ที่แลกด้วยอิสรภาพ

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

2. คอนโด: เมื่อสินทรัพย์กลายเป็นภาระผูกพันถึงอายุ 60

พอเงินเดือนเริ่มขยับ ผมก็หาเรื่อง “ลงทุน” ด้วยการซื้อคอนโดใกล้ที่ทำงาน ผ่อนไป 30% ของเงินเดือนยาวๆ ยันเกษียณ โดยหวังว่ามันจะเป็นสินทรัพย์ชั้นดี แต่ความจริงที่ผมลืมคิดคือ “อาชีพเราย้ายงานบ่อย” พอผมเปลี่ยนที่ทำงาน คอนโดที่เคยว่าใกล้ก็กลายเป็นไกลโพ้น จะขายหรือปล่อยเช่าก็ยาก เพราะมีตึกใหม่ๆ ใหญ่กว่า ดีกว่า เปิดแข่งตลอดเวลา สุดท้ายผมต้องแบกค่าจิปาถะและหนี้ก้อนโตไปอีกหลายสิบปี

3. การลงทุน: อย่าหาทางลัดในโลก Crypto/Forex

ผมเคยเป็นคนหนึ่งที่อยากรวยทางลัด กระโดดเข้าใส่คริปโตและฟอเร็กซ์แบบไม่คิดชีวิต ผลคือ “ได้ไวแต่เสียไวกว่า” หัวใจจะวายทุกครั้งที่กราฟดิ่ง บทเรียนหลายปีสอนผมว่า สำหรับคนทำงานประจำอย่างเรา การ DCA ในหุ้นที่มั่นคง หรือกองทุนที่มีพื้นฐานดี คือการลงทุนที่ทำให้เรานอนหลับได้สนิท หรือการใส่เงินเข้า provident fund ก็เป็นอีกตัวเลือกที่มั่นคงให้ผลตอบแทนยั่งยืนในระยะยาวครับ

4. ประกัน: อย่าให้คำว่า “เงินออม” มาหลอกคุณ

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

คำแนะนำจากสหายโทนี่: ซื้อแค่ประกันชีวิตแบบชั่วระยะเวลา (Term Life Insurance) ในช่วงที่จำเป็นเพื่อกันความเสี่ยงพอครับ ส่วนเงินที่จะออม เอาไปลงทุนอย่างอื่นที่คุณคุมเองได้และผลตอบแทนสูงกว่า อย่าเอาเงินไปจมให้คนอื่นรวย

5. สุขภาพ: Hardware ชิ้นเดียวที่ไม่มี Git Revert

ในวันที่งานล้นมือ เรามักจะคิดว่าร่างกายเราคือเครื่องจักรที่ไม่มีวันพัง แต่เชื่อผมเถอะครับ 10 ปีผ่านไป หลังที่ปวด ตาที่เบลอ มันไม่มีอะไหล่เปลี่ยนนะครับ ต่อให้สหายเขียน Code เก่งแค่ไหน แต่ถ้าต้องเอาเงินทั้งหมดไปจ่ายค่าหมอ มันคือความพ่ายแพ้ในเกมชีวิตครับ เริ่มดูแลตัวเองตั้งแต่วันนี้ แบ่งเวลามาออกกำลังกาย เข้ายิม เดิน-วิ่ง วันละ 20–30 นาที หรือการจัดโต๊ะทำงานให้ถูกหลัก Ergonomics ก็ช่วยให้ห่างไกลจาก Office syndrome ได้ครับ

6. ครอบครัว: Commit ที่สำคัญที่สุดในชีวิต

สุดท้ายอย่าละเลยคนข้างหลังครับ เวลาเป็น Data Type ที่ “Write Only” เขียนลงไปแล้วลบไม่ได้ และไม่มีทาง Rollback กลับไปแก้ไขได้ ใช้เวลากับครอบครัวให้คุ้มค่าตั้งแต่วันนี้ อย่ารอจนวันที่ม้าไฟของคุณวิ่งจนหมดแรงแล้วถึงค่อยหันกลับไปมอง

บทสรุปจากสหายโทนี่: ปี 2026 นี้ ม้าไฟอาจจะร้อนแรง แต่อย่าควบจนลืมเช็กอานม้าและทางข้างหน้านะครับ หวังว่าบทเรียนราคาแพงของผม จะช่วยให้สหายทุกคนวิ่งไปสู่เป้าหมายได้อย่างมั่นคงและมีความสุข

ขอให้เป็นการวิ่งที่ยั่งยืนครับสหาย!

*** การลงทุนมีความเสี่ยงโปรดใช้วิจารณญาณในการรับชม ไม่ต้องเชื่อผมเพราะผมไม่ได้เรียนมา เป็นการแชร์ประสบการณ์ตรง ขอให้โชคดีและสนุกกับชีวิตครับ สวัสดีปีใหม่ ๒๕๖๙

HNY ปีม้าไฟ 2026 ~ 6 กับดักชีวิต ที่อยากให้คุณเลี่ยง was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reactive Programming ด้วย Spring WebFlux และ Project Reactor ช่วยให้เราสร้างระบบที่รองรับ concurrent workload ได้ดี ใช้ resource คุ้ม และ scale ได้ง่าย แต่ที่หลายคนบ่นเหมือนกันคือ

“ตอน Error มัน Debug ยากมาก”

Stacktrace ของ reactive pipeline มักไม่บอกเราตรง ๆ ว่า

• error เกิดจาก business logic จุดไหน
• operator ไหนเป็นต้นเหตุ
• หรือ reactive chain วิ่งมาถึงตรงนี้ได้อย่างไร

ผลลัพธ์คือ developer ต้องไล่เดา flow จาก .map() .flatMap() ที่ต่อกันยาว ๆ ซึ่งเสียเวลาและทำให้การแก้ปัญหาช้าลงอย่างมาก

บทความนี้จะพาไปทำความรู้จัก Reactor Debug Agent พร้อมเทคนิคสำคัญอย่าง .checkpoint() และ Hooks.onOperatorDebug()ผ่านตัวอย่างโค้ด และการอธิบายทีละบรรทัด เพื่อให้คุณสามารถ

• อ่าน stacktrace ของ reactive ได้เหมือน synchronous code
• pinpoint ตำแหน่ง error ได้เร็วขึ้น
• และ debug WebFlux application ได้อย่างมั่นใจมากขึ้น

เป้าหมายไม่ใช่แค่ “รู้ว่า error คืออะไร”
แต่คือ “รู้ว่ามันเกิดขึ้นได้อย่างไร และควรแก้ตรงไหน”

Step 1: เตรียมโปรเจกต์

เพิ่ม dependency ใน pom.xml

<dependency>
  <groupId>io.projectreactor.tools</groupId>
  <artifactId>reactor-tools</artifactId>
  <version>3.5.6</version>
</dependency>

Step 2: เปิด Debug Mode ตั้งแต่แอปเริ่มรัน

@SpringBootApplication
public class DemoApplication {
public static void main(String[] args) {
      Hooks.onOperatorDebug();
      ReactorDebugAgent.init();
      ReactorDebugAgent.processExistingClasses();

      SpringApplication.run(DemoApplication.class, args);
  }
}

• เรียกใช้ Hooks.onOperatorDebug() เพื่อเปิดโหมด debug ของ reactive operator ทุกตัวในแอปฯ สำหรับเก็บข้อมูล stacktrace
• เริ่มต้น Reactor Debug Agent ด้วย ReactorDebugAgent.init() เพื่อช่วยเพิ่มข้อมูล stacktrace ที่ชัดเจนและเชื่อมโยงข้อผิดพลาดกลับไปยังโค้ดต้นเหตุ
• สั่งให้ agent สแกน class ที่โหลดแล้วด้วย ReactorDebugAgent.processExistingClasses() เพื่อ instrument operator ที่ถูกโหลดก่อนหน้านี้ (ถ้าไม่เรียก อาจมี operator บางตัวไม่ถูก instrument)

Step 3: ตัวอย่าง Reactive Flow ที่จะเกิด Exception

@GetMapping("/calculate")
public Mono<String> calculate() {
    return Mono.just(10)
               .map(i -> i - 10)
               .map(i -> 10 / i)
               .checkpoint("Divide calculation")
               .map(String::valueOf);
}

อธิบายทีล่ะบรรทัด

Mono.just(10)

สร้าง Mono ที่ปล่อยค่าเดียวคือ 10

.map(i -> i - 10)

แปลงค่า 10 → 0
ตอนนี้ยังไม่มี error

.map(i -> 10 / i)

เกิดการคำนวณ 10 / 0
💥 เกิด ArithmeticException ที่บรรทัดนี้

.checkpoint("Divide calculation")

ใส่ป้ายชื่อให้ pipeline
ถ้าเกิด error Stacktrace จะบอกว่า
👉 “พังที่ checkpoint: Divide calculation”

.map(String::valueOf)

บรรทัดนี้ จะไม่ถูกเรียก เพราะ error เกิดก่อนหน้าแล้ว

Step 4: ดู Stacktrace แบบ “อ่านรู้เรื่อง”

❌ ถ้าไม่ใช้ Debug Agent

java.lang.ArithmeticException: / by zero
    at reactor.core.publisher.FluxMap$MapSubscriber.onNext
    ...

• ไม่รู้ว่า error มาจาก map ไหน
• ไม่รู้ logic ธุรกิจ
• แก้ยากมาก

✅ เมื่อใช้ Debug Agent + checkpoint

java.lang.ArithmeticException: / by zero
	at com.example.DemoController.lambda$calculate$1(DemoController.java:18)

Reactor operator stacktrace:
--- Operator checkpoint: Divide calculation

🎯 รู้ทันที

• พังที่ method ไหน
• พังใน business logic จุดไหน
• ไม่ต้องไล่เดา reactive chain

Step 6: ตัวอย่าง เพิ่มอีกหนึ่งเคส (DB / Service)

public Mono<User> findUser(String id) {
    return userRepository.findById(id)
        .checkpoint("DB: findUserById")
        .switchIfEmpty(Mono.error(new RuntimeException("User not found")));
}

ถ้าเกิด error จะเห็นว่า

--- Operator checkpoint: DB: findUserById

📍 แปลว่า error นี้มาจาก database layer
ไม่ใช่ controller
ไม่ใช่ downstream service

ปิดท้าย

Reactive Programming ไม่ได้ทำให้การ debug เป็นไปไม่ได้ แต่ต้องใช้วิธีคิดและเครื่องมือที่เหมาะสม

ปัญหาที่หลายทีมเจอไม่ใช่ Reactive เอง แต่คือ stacktrace ที่ขาด context ทำให้ไม่รู้ว่า error เกิดจาก business logic ตรงไหนของ pipeline

Reactor Debug Agent ช่วยเติมช่องว่างนี้ ด้วยการเชื่อม reactive operator กลับไปยังโค้ดจริงที่เขียนไว้
เมื่อใช้งานร่วมกับ .checkpoint() และ Hooks.onOperatorDebug() เราจะสามารถ

• pinpoint ตำแหน่งที่ error เกิดขึ้นได้เร็วขึ้น
• อ่าน stacktrace ของ reactive code ได้เหมือน synchronous code มากขึ้น
• ลดเวลาในการไล่ debug และการเดา flow ของระบบ

อย่างไรก็ตาม เครื่องมือเหล่านี้มี overhead และควรใช้งานเฉพาะใน development หรือ troubleshooting environment
การเลือกใช้ให้เหมาะสมในแต่ละสถานการณ์ จะช่วยให้ทีมได้ประโยชน์จาก Reactive Programming โดยไม่เพิ่มความซับซ้อนเกินจำเป็น

Reactive ไม่ได้ยากขึ้น
แค่ต้อง debug ให้ถูกวิธี

Debug Reactive Streams ใน Spring WebFlux ด้วย Reactor Debug Agent was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.