Yordja | Santiphap Utta

Blog

  • Vibe Coding ทำให้ใครๆ ก็สร้าง Software ได้ แต่คำว่า “ใช้ได้” กับ “พร้อมขึ้น Production” เป็นคนละเรื่องกัน

    ช่วงนี้ผมเห็นคนรอบตัวเริ่มทำ Software ใช้เองกันเยอะขึ้นมาก

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

    เมื่อก่อนโจทย์แบบนี้อาจต้องหา Developer หรือ Software House มาช่วยทำ

    แต่วันนี้เราสามารถเปิด AI Coding Tool แล้วอธิบายว่า

    “ผมมีปัญหาแบบนี้ อยากได้ระบบประมาณนี้ ช่วยสร้างให้หน่อย”

    จากนั้นค่อยๆ คุย ค่อยๆ แก้ จนสุดท้ายได้ Software ที่ใช้งานได้จริง

    นี่เป็นสิ่งที่ผมมองว่าน่าสนใจมากของ Vibe Coding

    และผมคิดว่าเราควรใช้มันให้เยอะด้วย

    ถ้าเป็น Internal Tool เล็กๆ Vibe Coding มีประโยชน์มาก

    สมมติบริษัทมีพนักงาน 10 คน

    มีงานหนึ่งที่ทุกสัปดาห์ต้องเอา Excel 3 ไฟล์มารวมกัน ตรวจข้อมูล แล้วสร้าง Report ซึ่งใช้เวลา 2 ชั่วโมง

    ถ้าเราสามารถใช้ AI ช่วยสร้าง Web App เล็กๆ ขึ้นมา ให้พนักงาน Upload ไฟล์ แล้วระบบประมวลผลออกมาให้เลย

    ถึง Code จะไม่ได้สวยที่สุด
    Architecture อาจไม่ได้ Perfect
    UI อาจไม่ได้ออกแบบโดย UX Designer

    แต่ถ้ามันลดงานจาก 2 ชั่วโมงเหลือ 5 นาทีได้

    สำหรับผม Software ตัวนั้นมี Value แล้ว

    นี่คือจุดที่ AI Coding มีพลังมาก

    คนที่เข้าใจปัญหาหน้างานสามารถสร้าง Solution ให้ตัวเองได้ โดยไม่จำเป็นต้องรอให้ทุก Requirement ผ่านกระบวนการพัฒนา Software แบบเต็มรูปแบบเสมอไป

    เราจะเริ่มเห็นสิ่งที่ผมคิดว่าน่าสนใจมากขึ้นเรื่อยๆ คือ

    Software ที่ไม่ได้ถูกสร้างมาเพื่อขาย แต่ถูกสร้างมาเพื่อแก้ปัญหาเฉพาะของคนหรือบริษัทนั้นๆ

    และ AI ทำให้ต้นทุนในการสร้าง Software ประเภทนี้ลดลงอย่างมาก

    แต่ปัญหาเริ่มเกิดเมื่อคิดว่า “ในเครื่องผมรันได้ = พร้อมขาย”

    ตรงนี้เป็นเส้นแบ่งที่สำคัญมาก

    สมมติเราสร้างระบบด้วย AI

    เปิดบนเครื่องตัวเอง ใช้งานได้
    Deploy ขึ้น Server ได้
    Login ได้
    เพิ่มข้อมูลได้
    ลูกค้าทดลองแล้วบอกว่าโอเค

    มันง่ายมากที่จะรู้สึกว่า

    “เสร็จแล้ว”

    แต่ถ้าจะเปลี่ยน Software ตัวนั้นจาก Internal Tool ไปเป็น SaaS ที่เปิดให้ลูกค้าจริงใช้งาน คำว่า “เสร็จ” มีความหมายต่างออกไปมาก

    เพราะตอนนี้เราไม่ได้รับผิดชอบแค่ Feature แล้ว

    เรากำลังรับผิดชอบ ข้อมูล ระบบ และธุรกิจของคนอื่น

    1. Security — Code ทำงานได้ ไม่ได้แปลว่า Code ปลอดภัย

    AI เก่งมากในการสร้าง Code ที่ “ดูเหมือนทำงานได้”

    แต่สิ่งที่เราต้องถามต่อคือ

    • Authentication ถูกออกแบบอย่างไร
    • Authorization ตรวจตรงไหน
    • User A สามารถเข้าถึงข้อมูลของ User B ได้หรือไม่
    • API มี Rate Limit หรือไม่
    • Input ถูก Validate หรือไม่
    • Password เก็บอย่างไร
    • Token หมดอายุและ Refresh อย่างไร
    • Secret และ API Key อยู่ตรงไหน
    • Database เปิดออก Internet หรือไม่
    • Dependency ที่ AI เพิ่มเข้ามามีช่องโหว่หรือไม่
    • Upload File แล้วมีการตรวจสอบอะไรบ้าง

    ปัญหาคือสิ่งเหล่านี้จำนวนมาก มองไม่เห็นจากหน้า UI

    ระบบสามารถทำงานได้อย่างสมบูรณ์ในสายตาผู้ใช้ แต่ข้างหลังอาจมีช่องโหว่เต็มไปหมด

    OWASP เองก็พูดถึงความเสี่ยงของการเชื่อ AI-generated code มากเกินไป และแนะนำว่า Code ที่ AI สร้างยังต้องมีคนรับผิดชอบ อ่าน Review และใช้ Security Tool ตรวจสอบ ไม่ควรถือว่า AI-generated code ปลอดภัยโดยอัตโนมัติ

    ดังนั้นคำว่า

    “AI เขียนให้”

    ไม่สามารถใช้แทนคำว่า

    “เราเข้าใจว่า Code นี้ทำอะไร”

    ได้

    2. PDPA และ Privacy — ตอน Test ใช้ Dummy Data แต่ Production คือข้อมูลคนจริง

    อีกเรื่องที่ต่างกันมากคือข้อมูล

    ตอนพัฒนาเราอาจมีข้อมูลแค่

    Name: Test User
Email: test@example.com
Phone: 0800000000

    ไม่มีอะไรน่ากังวล

    แต่เมื่อเปิด SaaS จริง Database อาจเริ่มมี

    ชื่อ
    เบอร์โทร
    Email
    ที่อยู่
    Invoice
    เอกสาร
    ข้อมูลบริษัท
    ประวัติการใช้งาน

    และบางระบบอาจมีข้อมูลที่ Sensitive มากกว่านั้นอีก

    จาก Application ธรรมดา มันจึงเริ่มกลายเป็นเรื่องของ Data Governance และ Privacy

    ต้องเริ่มถามแล้วว่า

    ข้อมูลถูกเก็บที่ไหน?

    ใครเข้าถึงได้?

    Developer เปิด Production Database ได้หรือไม่?

    Backup อยู่ที่ไหน?

    Log มีข้อมูลส่วนบุคคลติดไปด้วยหรือเปล่า?

    ถ้าลูกค้าขอลบข้อมูล เราลบได้จริงหรือไม่?

    ถ้าข้อมูลรั่ว เรารู้หรือไม่ว่าเกิดอะไรขึ้น?

    และยิ่งเราใช้ AI Coding Agent ที่สามารถอ่านทั้ง Repository, Terminal หรือ Project Context ก็ต้องระวังเพิ่มอีกชั้นว่า เราเผลอส่ง Credential, Source Code หรือข้อมูลลูกค้าเข้าไปเป็น Context ให้ AI หรือไม่

    OWASP แนะนำให้แยก Secret ออกจาก Project Context, จำกัดสิทธิ์ของ Coding Agent และตรวจสอบว่าข้อมูลอะไรถูกส่งออกไปยัง AI Provider

    3. Performance — User 5 คน กับ User 5,000 คน ไม่ใช่ระบบเดียวกัน

    อีกกับดักหนึ่งของ Vibe Coding คือ

    ตอนเรา Test ทุกอย่างเร็วมาก

    แน่นอนครับ…

    เพราะมี User อยู่คนเดียว 😅

    Database มี 100 records
    API ถูกเรียกทีละ Request
    ไม่มี Concurrent User
    ไม่มี Bot
    ไม่มี Traffic Spike

    พอเปิด Production จริง โลกเปลี่ยนทันที

    Query ที่ใช้เวลา 300ms อาจดูไม่มีปัญหา

    แต่ถ้ามันถูกเรียก 20 ครั้งต่อ Page และมี User พร้อมกันจำนวนมาก เรื่องก็เปลี่ยน

    เราจึงต้องเริ่มคิดเรื่อง

    Database Index
    Caching
    Connection Pool
    Queue
    Background Job
    Rate Limiting
    CDN
    Horizontal Scaling
    Monitoring

    รวมถึง Cost ด้วย

    โดยเฉพาะ Application ที่เรียก AI API เพราะ Request หนึ่งครั้งไม่ได้มีต้นทุนแค่ CPU และ Database อีกต่อไป แต่อาจมี Token Cost ทุกครั้งที่ User กดปุ่ม

    ถ้าออกแบบผิด User คนหนึ่งหรือ Bot ตัวเดียวอาจสร้างค่าใช้จ่ายจำนวนมากได้

    4. Production ต้องคิดเรื่อง “ตอนมันพัง” ด้วย

    ตอนสร้าง MVP เรามักคิดว่า

    Happy Path ทำงานหรือยัง?

    แต่ Production ต้องคิดอีกแบบ

    ถ้ามันไม่ทำงาน จะเกิดอะไรขึ้น?

    Database ล่มทำอย่างไร?

    Deploy Version ใหม่แล้วมี Bug ทำอย่างไร?

    Migration Database ผิดย้อนกลับได้ไหม?

    Server Disk เต็มรู้ได้อย่างไร?

    API ภายนอกล่ม ระบบเราจะเป็นอย่างไร?

    Backup มี แต่เคยลอง Restore หรือยัง?

    Error เกิดขึ้นแล้วใครรู้?

    จึงเริ่มมีเรื่องที่ไม่ได้อยู่บนหน้าจอ Application เข้ามาเต็มไปหมด

    Monitoring
    Logging
    Alerting
    Backup
    Disaster Recovery
    CI/CD
    Rollback
    Incident Response

    สิ่งเหล่านี้ไม่ได้ทำให้ Demo ดูดีขึ้นเลย

    แต่เป็นสิ่งที่ทำให้ Software อยู่รอด

  • ลองสร้าง AI Chatbot บน AWS: จาก Bedrock ถึง Next.js แบบ Serverless

    ลองสร้าง AI Chatbot บน AWS: จาก Bedrock ถึง Next.js แบบ Serverless

    ช่วงนี้ผมกำลังทดลองสร้าง AI Chatbot โดยใช้ AWS เป็น Backend หลัก

    โจทย์ไม่ได้ซับซ้อนมาก

    ผมต้องการ Chatbot ที่รับคำถามจากหน้าเว็บ เช่น

    “IMOTIF ให้บริการอะไรบ้าง?”

    แล้วส่งคำถามไปให้ AI ประมวลผล ก่อนส่งคำตอบกลับมาแสดงบนหน้าเว็บ

    Architecture ที่ใช้ตอนนี้ประมาณนี้

    Next.js → API Gateway → AWS Lambda → Amazon Bedrock

    ข้อดีคือไม่ต้องเปิด Server รันตลอดเวลา และแต่ละส่วนสามารถแยกออกจากกันได้ค่อนข้างชัดเจน

    1. Amazon Bedrock ทำหน้าที่เป็น AI Engine

    Amazon Bedrock เป็นบริการของ AWS สำหรับเรียกใช้งาน Foundation Model ผ่าน API

    แทนที่จะต้องติดตั้งหรือ Host LLM เอง เราสามารถส่ง Prompt ไปยัง Model แล้วรับคำตอบกลับมาได้เลย

    Concept ง่าย ๆ คือ

    User Question
      ↓
Amazon Bedrock
      ↓
AI Response

    แต่ในระบบจริง เราไม่ควรให้ Browser เรียก Bedrock โดยตรง

    เพราะจะมีเรื่อง Credentials, Security และ Business Logic เข้ามาเกี่ยวข้อง

    จึงต้องมี Backend คั่นกลาง

    2. ใช้ AWS Lambda เป็น Backend

    ใน POC นี้ผมเลือกใช้ AWS Lambda

    Lambda คือ Serverless Compute ของ AWS

    เราเขียน Function ขึ้นมา เช่น

    POST /chat

    เมื่อได้รับข้อความ

    {
  "message": "IMOTIF ให้บริการอะไรบ้างครับ"
}

    Lambda จะนำข้อความไปเรียก Amazon Bedrock

    แล้วคืน Response กลับมา

    ตัวอย่าง

    {
  "answer": "IMOTIF ให้บริการ Odoo ERP, Software Development, Cloud Service และ AI Integration"
}

    ข้อดีของ Lambda สำหรับงานลักษณะนี้คือ

    • ไม่ต้องดูแล Server
    • ไม่ต้องเปิด EC2 ทิ้งไว้
    • Scale ตาม Request
    • เหมาะกับ Prototype และ API ที่ไม่ได้มี Traffic ตลอดเวลา

    สำหรับการเริ่มทำ AI Application ผมมองว่านี่เป็น Architecture ที่ค่อนข้างน่าสนใจ

    3. ใช้ API Gateway เปิด Endpoint ให้ Frontend เรียก

    Lambda อย่างเดียว Browser ยังเรียกใช้งานได้ไม่สะดวก

    จึงใช้ Amazon API Gateway เป็นตัวรับ HTTP Request

    Architecture จึงกลายเป็น

    Next.js
   ↓
POST /chat
   ↓
API Gateway
   ↓
Lambda
   ↓
Amazon Bedrock

    ในกรณีนี้ผมใช้ HTTP API

    สำหรับ API เล็ก ๆ แบบ Chat Endpoint ผมมองว่า HTTP API เพียงพอ และ Setup น้อยกว่า REST API

    เมื่อ Deploy แล้วจะได้ URL ลักษณะประมาณ

    https://xxxxx.execute-api.ap-southeast-7.amazonaws.com/default/chat

    เราสามารถ Test ด้วย curl ก่อนต่อ Frontend

    curl -X POST \
  https://xxxxx.execute-api.ap-southeast-7.amazonaws.com/default/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"IMOTIF ให้บริการอะไรบ้างครับ"}'

    ถ้าได้ Response กลับมา แปลว่า Backend Pipeline ทำงานแล้ว

    4. ทำไมต้อง Test ด้วย curl ก่อน

    จุดนี้สำคัญกว่าที่คิด

    ตอนแรกผมพยายามต่อ Frontend เลย

    ผลคือ

    Bad Request

    แล้วก็เริ่มไล่ดู Next.js
    ไล่ดู Environment Variable
    ไล่ดู API Gateway
    ไล่ดู Lambda

    ทั้งที่วิธี Debug ที่ง่ายกว่าคือแยกระบบออกเป็นชั้น ๆ

    เริ่มจาก

    Lambda → Bedrock

    ให้ทำงานก่อน

    จากนั้น

    API Gateway → Lambda → Bedrock

    แล้ว Test ด้วย curl

    เมื่อ Backend ทำงานแน่นอนแล้ว ค่อยต่อ

    Next.js → API Gateway

    วิธีนี้ลดพื้นที่ในการหา Bug ได้เยอะมาก

    เป็นหลักพื้นฐาน แต่พอทำระบบหลาย Layer พร้อมกัน เรามักลืมมัน

    5. ต่อ Next.js เป็น Chat UI

    เมื่อ API ใช้งานได้แล้ว Frontend ค่อนข้างตรงไปตรงมา

    Concept คือ

    const response = await fetch(`${apiBaseUrl}/chat`, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    message,
  }),
});

    รับ JSON กลับมา

    const data = await response.json();

    แล้วแสดง

    data.answer

    แค่นี้เราก็ได้ AI Chatbot พื้นฐานที่ Frontend และ Backend แยกออกจากกันแล้ว

    6. โครงสร้างนี้เหมาะกับ Production ไหม

    ถ้าเป็น POC หรือ MVP ผมคิดว่าเหมาะมาก

    แต่ถ้าจะใช้จริง ยังมีหลายเรื่องที่ต้องเพิ่ม

    เช่น

    Authentication

    ใครสามารถเรียก Chat API ได้บ้าง

    ถ้าเปิด Public Endpoint ทิ้งไว้ ใครก็สามารถเรียก API และทำให้เกิดค่าใช้จ่ายได้

    Rate Limit

    ควรกำหนดจำนวน Request ต่อ User หรือ IP

    Conversation History

    ตอนนี้แต่ละคำถามอาจเป็น Stateless

    แต่ Chatbot จริงควรเข้าใจ Conversation ก่อนหน้า

    Knowledge Base

    ถ้าอยากให้ Bot ตอบเรื่องบริษัทได้แม่นขึ้น ไม่ควรเอาข้อมูลทั้งหมดใส่ Prompt

    แต่ควรใช้แนวทางอย่าง

    RAG — Retrieval-Augmented Generation

    ให้ระบบค้นข้อมูลที่เกี่ยวข้องก่อน แล้วส่งเฉพาะ Context ที่จำเป็นให้ AI

    Logging

    ต้องรู้ว่า User ถามอะไร

    AI ตอบอะไร

    ใช้ Token เท่าไร

    และ Error เกิดที่ Layer ไหน

    7. ขั้นต่อไปคือทำให้ AI รู้จักข้อมูลของบริษัท

    Chatbot ที่เรียก LLM ได้ยังไม่ได้แปลว่าเป็น Business AI

    สิ่งที่น่าสนใจกว่าคือ

    ถ้า Chatbot สามารถเข้าถึง

    • Product
    • Service
    • FAQ
    • CRM
    • Sales
    • ERP
    • Inventory
    • Accounting

    ของบริษัทได้ จะเกิดอะไรขึ้น

    ตัวอย่างเช่น

    แทนที่จะถามว่า

    IMOTIF ให้บริการอะไรบ้าง

    อาจถามได้ว่า

    เดือนนี้มี Lead ใหม่กี่ราย

    หรือ

    ลูกค้ารายไหนมี Quotation ที่ยังไม่ได้ Follow up

    หรือ

    Product ตัวไหน Stock ต่ำกว่าระดับที่กำหนด

    ตรงนี้ทำให้ Chatbot เริ่มเปลี่ยนจาก

    AI Chat

    ไปเป็น

    AI Business Interface

    และนี่เป็นส่วนที่ผมคิดว่าน่าสนใจกว่า Chatbot ทั่วไปมาก

    เพราะเป้าหมายสุดท้ายของ AI ในองค์กรอาจไม่ใช่การมี Chatbot อีกหนึ่งตัว

    แต่คือการทำให้คนสามารถ คุยกับข้อมูลและระบบของตัวเองได้โดยตรง

  • Yordja กลับมาแล้ว: Technology, Business & Sound

    หลายปีที่ผ่านมา ผมใช้เวลาส่วนใหญ่อยู่กับการทำงานด้าน Technology และการสร้างธุรกิจ ตั้งแต่ Software Development, ERP, Cloud ไปจนถึง Artificial Intelligence

    ระหว่างทางมีหลายเรื่องที่ผมได้ลองทำ ได้เรียนรู้ และบางครั้งก็ทำพลาด แต่กลับไม่ได้เขียนหรือบันทึกมันเอาไว้มากนัก

    วันนี้เลยอยากกลับมาเขียนอีกครั้ง

    และนี่คือเหตุผลที่ Yordja.com กลับมา

    ทำไมถึงกลับมาเขียน Blog?

    ทุกวันนี้เวลาอยากรู้อะไร เราสามารถถาม AI แล้วได้คำตอบภายในไม่กี่วินาที

    ผมเองก็ใช้ AI แทบทุกวัน ทั้งในการเขียน Code, Research, วิเคราะห์ Business Idea ไปจนถึงช่วยคิด Architecture ของระบบ

    ยิ่ง AI เก่งขึ้น ผมกลับยิ่งรู้สึกว่า ประสบการณ์จริงของคนมีคุณค่ามากขึ้น

    AI สามารถอธิบายได้ว่า AWS Lambda คืออะไร

    แต่สิ่งที่ผมอยากอ่านมากกว่าคือ

    คนที่ลองเอา Lambda ไปสร้าง Product จริง เลือก Architecture อย่างไร เจอปัญหาอะไร และสุดท้ายมันเวิร์กหรือไม่เวิร์ก

    AI สามารถอธิบายว่า ERP คืออะไร

    แต่ประสบการณ์จากการ Implement ERP จริง ตั้งแต่คุย Requirement, Estimate, Customize, UAT จนถึงวันที่ระบบขึ้น Production เป็นเรื่องอีกแบบหนึ่ง

    ผมจึงอยากให้ Yordja เป็นพื้นที่สำหรับเรื่องเหล่านี้

    ไม่ใช่แค่ What is…

    แต่รวมถึง I tried this. Here’s what happened.

    Technology

    Technology เป็นเรื่องหลักที่ผมน่าจะเขียนมากที่สุด

    ช่วงนี้ผมสนใจเป็นพิเศษกับ AI, AI Agents, Software Development, ERP, Odoo, AWS และ Cloud

    ตัวอย่างหนึ่งคือช่วงที่ผ่านมา ผมเริ่มทดลองสร้าง AI Application ตั้งแต่ศูนย์

    จากการเขียน API ด้วย FastAPI ไปจนถึงการทดลอง AWS Bedrock, Lambda และ API Gateway

    สิ่งที่น่าสนใจสำหรับผมไม่ได้มีแค่ Code

    แต่เป็นคำถามว่า

    เราจะเอา Technology เหล่านี้ไปสร้างสิ่งที่มีประโยชน์กับธุรกิจจริงได้อย่างไร?

    นี่เป็นหัวข้อที่ผมน่าจะกลับมาเขียนอีกเยอะ

    Business

    อีกโลกหนึ่งของผมคือ Business

    การทำบริษัท Technology ทำให้ผมต้องสลับบทบาทอยู่ตลอดเวลา

    วันหนึ่งอาจกำลังคุย Requirement กับลูกค้า

    อีกวันหนึ่งกำลังดู Architecture กับ Developer

    บางวันคิดเรื่อง Sales, Marketing และ SEO

    และบางคืนกลับมานั่งคิดว่า Product ที่กำลังจะสร้างนั้น มีใครยอมจ่ายเงินจริงหรือเปล่า

    Technology ที่น่าสนใจจึงไม่ได้แปลว่าจะเป็น Business ที่ดีเสมอไป

    ผมอยากใช้พื้นที่นี้บันทึกเรื่องการสร้างบริษัท IT, Product, SaaS, ERP, Digital Transformation รวมถึงการทดลองสร้าง AI Product จากมุมของคนที่กำลังลงมือทำจริง

    ทั้งสิ่งที่ได้ผลและสิ่งที่ไม่ได้ผล

    แล้ว Sound มาเกี่ยวอะไรด้วย?

    นอกจาก Technology กับ Business แล้ว อีกสิ่งหนึ่งที่ผมชอบมานานคือดนตรี โดยเฉพาะ Synthesizers และ Keyboards

    ถ้ามองเผิน ๆ มันอาจไม่เกี่ยวกับ ERP หรือ AI เลย

    แต่สำหรับผมมันมีบางอย่างคล้ายกัน

    การนั่งอยู่หน้า Synthesizer แล้วเริ่มจากเสียงธรรมดา ๆ ก่อนจะปรับ Oscillator, Filter, Envelope และ Effect จนกลายเป็นเสียงใหม่

    ให้ความรู้สึกไม่ต่างจากการเริ่ม Project ด้วย Repository ว่าง ๆ แล้วค่อย ๆ สร้างบางอย่างขึ้นมา

    มันคือการทดลอง

    การเรียนรู้

    และการสร้าง

    เพราะฉะนั้นบางวัน Yordja อาจมีบทความเรื่อง AI Agent

    บางวันอาจเป็น Odoo หรือ AWS

    และบางวันอาจเป็น Synthesizer หรือ Keyboard ที่ผมกำลังเล่นอยู่

    ผมคิดว่านั่นแหละคือความเป็น Yordja

    แล้วต่อจากนี้?

    ผมไม่ได้ตั้งเป้าว่าจะทำ Yordja ให้เป็นเว็บไซต์ข่าว Technology หรือ Content Farm ที่ต้องมีบทความใหม่ทุกวัน

    ตรงกันข้าม

    ผมอยากเขียนจากสิ่งที่ กำลังทำจริง

    ถ้ากำลังทดลอง AI Agent ก็เขียนเรื่อง AI Agent

    ถ้ากำลัง Deploy ระบบบน AWS แล้วเจอปัญหา ก็เขียนสิ่งที่ได้เรียนรู้

    ถ้าเจอแนวคิดน่าสนใจจากการ Implement ERP ก็เอามาเล่า

    หรือถ้าวันนั้นกำลังสนุกกับ Synthesizer ตัวใหม่ ก็อาจเขียนเรื่องนั้นแทน

    เป้าหมายง่าย ๆ คือทำให้ Yordja กลายเป็น Digital Garden ของผมเอง

    พื้นที่สำหรับเก็บความคิด การทดลอง และสิ่งที่ได้เรียนรู้ระหว่างทาง

    และถ้าสิ่งเหล่านั้นเป็นประโยชน์กับคนอื่นด้วย ก็ยิ่งดี

    Technology, Business & Sound.

    Welcome to Yordja.