ผมเริ่มบล็อกเทคนิคโดยไม่มีแผนหารายได้ แล้วเว็บไซต์สายวิศวกรรมจากญี่ปุ่นก็มาเจอมัน

อยู่นานมากเหมือนกันที่ผมไม่แน่ใจด้วยซ้ำว่าเว็บไซต์นี้จำเป็นต้องมีบล็อกหรือไม่

เวลาทำงานส่วนใหญ่ของผมก็หมดไปกับการแก้ปัญหาอยู่แล้ว บางอย่างเป็นงาน frontend หรือ backend ปกติ แต่บางอย่างลงลึกมาก เช่น image encoding, พฤติกรรมของ browser, การทดลอง SEO, ปัญหา infrastructure, การพัฒนาด้วย AI, media processing หรือปัญหา production แปลก ๆ ที่เริ่มจากคำถามง่าย ๆ แล้วกลายเป็นการไล่หาคำตอบอยู่หลายวัน

หลังจากนั้น การเขียนเพิ่มอีกหลายพันคำก็ดูเหมือนไม่จำเป็น

ใครจะอ่าน?

ผมได้อะไรจากมัน?

ทำไมไม่แก้ปัญหาให้เสร็จแล้วไปต่อ?

สุดท้ายผมได้คำตอบที่เพียงพอสำหรับตัวเอง งานบางอย่างใช้ต้นทุนมากเกินกว่าจะปล่อยทิ้งไปเฉย ๆ

ปัญหายากหนึ่งเรื่องอาจมีบทความทั้งบทซ่อนอยู่ก่อนที่ผมจะรู้ตัว

บทความของผมมักไม่ได้เริ่มจากความคิดว่า “สัปดาห์นี้ต้องเขียนบล็อกหนึ่งบท”

มันเริ่มจากปัญหา

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

งานประมวลผลภาพพาผมลงหลุมลึกแบบนี้หลายครั้ง

ตอนแรกโจทย์อาจฟังดูง่ายแทบจะเกินจริง:

เอารูปพวกนี้ไป แล้วทำให้ไฟล์เล็กลง

คุณขอ script จาก AI model แล้วได้คำตอบแทบจะทันทีได้

แต่นั่นไม่ได้หมายความว่าคุณมี image-processing pipeline ที่ดีแล้ว

เวอร์ชันแรกอาจไม่สนใจความแตกต่างของ JPEG, PNG, WebP และภาพเคลื่อนไหว อาจใช้ค่า quality เดียวกับทุกอย่าง ทำ upscale โดยไม่จำเป็น จัดการ transparency ไม่ดี เก็บ metadata ที่อยากลบ หรือทำลาย metadata ที่ตั้งใจจะเก็บ อาจลดแค่ขนาดไฟล์โดยไม่วัดความเสียหายทางภาพเลย และอาจทำงานสมบูรณ์แบบกับไฟล์ทดสอบ 10 ไฟล์ แต่กลายเป็นความผิดพลาดที่แพงมากเมื่อใช้ในสเกลใหญ่กว่านั้นมาก

script ที่รันสำเร็จไม่ใช่สิ่งเดียวกับ system ที่ผมไว้ใจ

บทความจำนวนมากของผมเกิดจากความแตกต่างตรงนี้

workflow ที่ผมใช้กับ AI ช้ากว่า “ถาม ChatGPT ให้ตอบ” มาก

เวลาทำงานกับปัญหาแบบนี้ ผมใช้บัญชี ChatGPT แบบเสียเงินค่อนข้างหนัก

conversation เดียวอาจอยู่ต่อเนื่องหลายวันหรือหลายสัปดาห์ ผมถามคำถาม ทดลองข้อเสนอ ส่งผลลัพธ์กลับไป ท้าทายสมมติฐาน ตรวจ code หา edge case ใหม่ ปรับ implementation รันใหม่ เปรียบเทียบผล แล้วทำซ้ำ

ในงานที่ลงลึกมาก ๆ ผมเคยสะสมเวลาทำงานมากกว่า 100 ชั่วโมงรอบปัญหาใหญ่เรื่องเดียว

ไม่ได้หมายความว่าผมนั่งรอ 100 ชั่วโมงให้ AI model ค้นพบคำตอบแบบมหัศจรรย์

กระบวนการเป็นแบบ iterative

โดยทั่วไปจะประมาณนี้:

1. ผมอธิบายปัญหา
2. model เสนอวิธีแก้เบื้องต้น
3. ผมนำไปทดลองกับข้อมูลจริง
4. พบว่าบางอย่างอ่อน ประสิทธิภาพไม่ดี หรือผิดไปเลย
5. ผมนำหลักฐานกลับไป
6. เราเปลี่ยนแนวทาง
7. ผมทดสอบอีกครั้ง
8. มี edge case ใหม่โผล่ขึ้นมา
9. วนซ้ำ

วงจรนี้เกิดขึ้นได้หลายรอบ

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

AI ทำให้การสร้างจุดเริ่มต้นถูกลง แต่ไม่ได้ทำให้การตรวจสอบถูกลง

นี่เป็นเหตุผลหนึ่งที่ผมมองว่าการถกเถียงทั่วไปเรื่องคอนเทนต์เทคนิคที่เขียนด้วย AI นั้นง่ายเกินไป

ใช่ AI model สามารถสร้าง tutorial ที่ดูสมเหตุสมผลได้เร็วมาก

แต่มันก็สามารถสร้าง code ที่ดูถูกต้องทุกอย่างและผิดพอดีในสถานการณ์ที่สำคัญที่สุดได้เช่นกัน

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

ถ้าผมกำลังสร้าง image pipeline ผมอยากดูขนาด output และคุณภาพของภาพ อยากรู้ว่า source format แบบต่าง ๆ เป็นอย่างไร อยากทดสอบ dimensions แปลก ๆ, alpha, animation และ input ที่เสีย และอยากเข้าใจด้วยว่า implementation ตั้งอยู่บน assumption อะไร

ถ้า script จะต้องไปแตะ collection ขนาดใหญ่มาก งานพวกนี้ยิ่งสำคัญ

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

ต้นทุนของการ generate code ลดลงอย่างมาก

แต่ต้นทุนในการพิสูจน์ว่า code นั้นสมควรรันในสเกลใหญ่หรือไม่ไม่ได้ลดตาม

แชตคือวัตถุดิบในการวิจัย ไม่ใช่บทความสำเร็จรูป

หลังจาก investigation ยาว ๆ แบบนี้ history ของแชตอาจมีข้อมูลมหาศาล

อาจมีทั้ง:

• แนวทางที่ล้มเหลว
• code ที่ภายหลังถูกแทนที่
• ผล benchmark ที่มีประโยชน์
• log
• ความเข้าใจผิด
• การแก้ไข
• คำอธิบายพฤติกรรมที่ไม่ชัดเจน
• การเปรียบเทียบทางเลือก
• edge case ที่ตอนแรกผมไม่ได้คิดถึง
• และกฎสุดท้ายที่ผมลงเอยด้วยการเชื่อถือ

ปล่อยทั้งหมดนี้ไว้ใน private conversation เพียงแห่งเดียวรู้สึกเสียของ

ผมจึงดึงส่วนที่มีประโยชน์ออกมาแล้วทำเป็นบทความ

บทความไม่ใช่ transcript ของการสนทนา เนื้อหาส่วนใหญ่ในแชตไม่ควรถูกเปลี่ยนเป็นบทความ

บทความเทคนิคที่มีประโยชน์ต้องผ่านอีกขั้นหนึ่ง ลบทางตันที่ไม่สอนอะไร เก็บทางตันที่อธิบายเรื่องสำคัญ ตรวจสอบ claim สร้าง chronology ใหม่ แยก observation ออกจาก explanation และเปลี่ยนผลลัพธ์สุดท้ายให้เป็นสิ่งที่ developer คนอื่นนำไปใช้ได้จริง

ขั้นตอน editing นี้สำคัญ

AI สามารถช่วยได้ แต่ evidence ยังคงมาจากงานที่ทำจริง

งานประมวลผลภาพทำให้ผมเห็นว่าปัญหา “ง่าย ๆ” ลึกได้แค่ไหน

image optimization น่าจะเป็นตัวอย่างที่ชัดที่สุดจากงานของผมเอง

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

คำถามเปลี่ยนไปเร็วมาก

กำลังทำงานกับ source format อะไร?

เป็นภาพเคลื่อนไหวหรือไม่?

ควรเปลี่ยน dimensions หรือไม่?

จะเลือก quality อย่างไร?

metric ไหนควรตัดสินว่า quality loss ยอมรับได้หรือไม่?

quality threshold เดียวใช้กับภาพที่ต่างกันมากได้หรือไม่?

จะหลีกเลี่ยง upscaling อย่างไร?

metadata ไหนควรอยู่ต่อ?

transparency จะเกิดอะไรขึ้น?

จะ validate output อย่างไร?

ไฟล์ที่เล็กลงคุ้มกับ encoding cost เพิ่มเติมจริงหรือ?

จะเกิดอะไรขึ้นเมื่อ input population เปลี่ยน?

เพราะแบบนี้ผมจึงระวัง script “ultimate image optimization” 5 บรรทัด

มันประมวลผลภาพได้แน่นอน

แต่นั่นไม่เหมือนกับการสร้าง pipeline ที่คุณเข้าใจ trade-off ของมัน

สำหรับ workload ปัจจุบันของผมที่มีภาพจำนวนมาก AVIF มักเป็น format แรกที่ผมนึกถึง นี่เป็นกฎที่เกิดจากลักษณะของโปรเจกต์ที่ผมทำ ไม่ใช่การบอกว่าเว็บไซต์ทุกแห่งในโลกควรลบ format เก่าทั้งหมดทิ้งพรุ่งนี้ ความต้องการด้าน compatibility, source material, latency, encoder cost และ delivery architecture อาจทำให้คำตอบเปลี่ยนไป

สิ่งที่น่าสนใจไม่ใช่การประกาศว่า format ไหนชนะ

แต่เป็นการเข้าใจ workload มากพอที่จะตัดสินใจอย่างตั้งใจ

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

จากนั้นเว็บไซต์ญี่ปุ่นก็มาเจอบล็อกนี้

ผมไม่ได้คาดหวังผลตอบแทนแบบใดเป็นพิเศษจากการเผยแพร่บทความเหล่านี้

บล็อกนี้ไม่ได้ให้ผลตอบแทนทางการเงินที่มีนัยสำคัญกับผม ผมทำเพราะชอบกระบวนการ และอยากเก็บงานที่มีประโยชน์ไว้มากกว่าปล่อยให้หายไปในแชตเก่ากับ history ของ terminal

แล้วก็มีบางอย่างเกิดขึ้นที่ผมไม่ได้คาดคิดจริง ๆ

เมื่อวันที่ 17 กันยายน 2026 เว็บไซต์ญี่ปุ่น Levtech Freelance เผยแพร่บทความรวมที่มีชื่อโดยประมาณว่า “บล็อกแนะนำสำหรับวิศวกรที่อยากพัฒนาทักษะ”

บทความของ Levtech Freelance ใส่ JSVar ไว้ร่วมกับบล็อกสาย engineering อีกหลายแห่ง

Levtech เป็นส่วนหนึ่งของ ecosystem ด้านอาชีพ IT ขนาดใหญ่ในญี่ปุ่น ส่วน Levtech Freelance เน้นช่วยเหลือและจับคู่ freelance IT engineer กับโอกาสงาน สิ่งที่น่าสนใจสำหรับผมไม่ใช่แค่การได้ backlink แต่คือการเห็นว่าทีม editorial ภายนอกมองว่างานส่วนไหนของผมมีคุณค่าพอที่จะเอาไปเล่า

ในส่วนของ JSVar พวกเขาหยิบขึ้นมาเป็นพิเศษ 3 บทความ

บทความหนึ่งพูดถึงเหตุผลที่ผมมองว่า Codex และ TypeScript ทำงานร่วมกันได้ดีใน production development โดยเฉพาะเพราะ type ของ TypeScript และ compiler feedback ช่วยเปิดเผยปัญหาใน generated code ได้เร็ว

อีกบทความเป็นเรื่องการแปลบล็อกเป็น 20 ภาษาด้วย ChatGPT และเห็นผู้ใช้จาก search ในประเทศต่าง ๆ เข้ามายัง localized page โดยตรง

บทความที่สามคือการทดลองเผยแพร่ AI-generated SEO page จำนวน 10,000 หน้า ซึ่งสุดท้ายกลายเป็นเรื่องของความล้มเหลวมากกว่าเรื่องการเติบโตแบบง่าย ๆ

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

ทุกบทความมาจากสิ่งที่ผมทำจริง

ผมไม่รู้แน่ชัดว่า Levtech เจอผมได้อย่างไร

ตรงนี้มีเรื่องเล่าที่น่าดึงดูดมาก

ผมพูดภาษาญี่ปุ่นไม่ได้

เว็บไซต์ของผมมีเวอร์ชันภาษาญี่ปุ่น

สื่อสาย engineering ของญี่ปุ่นมาเจอเว็บไซต์

ดังนั้นการแปลบล็อกเป็นภาษาญี่ปุ่นจึงทำให้ Levtech พบมัน

ผมพิสูจน์ไม่ได้

อาจเป็นเพราะหน้าภาษาญี่ปุ่นช่วย

อาจเป็นเพราะ search พาพวกเขาไปยังบทความภาษาอังกฤษ

อาจมีคนแชร์ link

หรืออาจเจอเว็บไซต์ด้วยเส้นทางอื่นทั้งหมด

ผมไม่มี attribution data นั้น จึงไม่อยากสร้าง SEO case study ที่ดูสะอาดเรียบร้อยจากสิ่งที่ข้อมูลไม่ได้ยืนยัน

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

แค่นั้นก็เป็นผลลัพธ์ที่ดีแล้ว

และยิ่งรู้สึกดีเพราะ localization เองก็เป็นอีก experiment ที่ตอนแรกดูเหมือนใช้แรงเยอะเพื่อผลที่ไม่แน่นอน

การถูกพูดถึงมีความหมายเพราะเป็นการยืนยันจากภายนอก

คำว่า “validation” ในที่นี้ไม่ได้หมายความว่า Levtech พิสูจน์ว่าสิ่งที่ผมเขียนทุกอย่างถูกต้อง

พวกเขาไม่ได้ audit codebase ของผมและไม่ได้ reproduce ทุก experiment

สิ่งที่มีความหมายเรียบง่ายกว่านั้น

คนอีกฝั่งของโลกซึ่งเขียนให้กับ audience ที่ผมไม่สามารถพูดกับพวกเขาด้วยภาษาของเขาเอง มองเห็นคุณค่าในงานผมมากพอที่จะนำไปสรุปให้ผู้อ่านของตัวเอง

ผมไม่ได้ pitch ให้เขา

บทความต้นฉบับไม่ได้เขียนเพื่อ Levtech

ผมไม่คาดคิดว่าจะไปโผล่ในบทความรวมของญี่ปุ่น

นั่นทำให้ผลลัพธ์นี้มีความหมายสำหรับผม

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

มันต้องมีประโยชน์กับผู้อ่านที่ใช่

developer ควรเริ่มบล็อกในปี 2026 หรือไม่?

สำหรับผม คำตอบคือควร — แต่มีเงื่อนไขสำคัญ

คุณต้องอยากเขียนอะไรบางอย่างเก็บไว้จริง ๆ

ผมไม่แนะนำให้เริ่มบล็อกเทคนิคเพียงเพราะมีคนบอกว่า developer ทุกคนต้องมี “personal brand”

ผมก็ไม่เริ่มเพราะคาดหวัง passive income

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

แต่ถ้างานของคุณสร้างสิ่งที่คุณเองอยากค้นเจอตอนเริ่มต้นอยู่เรื่อย ๆ นั่นเป็นอีกเรื่อง

เขียนมันลงไป

เขียนเรื่อง production failure แปลก ๆ

เขียนเรื่อง optimization ที่ใช้เวลานานกว่าคาด 3 วัน

เขียนเรื่อง benchmark ที่ขัดกับ assumption ของคุณ

เขียนเรื่อง approach ที่ดูสวยแต่ล้มเหลว

เขียน final implementation และอธิบายด้วยว่าเหตุใด implementation ที่ดูชัดเจนจึงไม่เพียงพอ

สิ่งเหล่านี้เป็นส่วนที่สร้างขึ้นจาก generic knowledge ได้ยาก

AI ทำให้ผมมีเรื่องเขียนมากขึ้น ไม่ได้น้อยลง

AI ไม่ได้ทำให้ผมคิดว่าบล็อกเทคนิคล้าสมัย

สำหรับผมแทบจะตรงกันข้าม

ผมสำรวจไอเดียได้มากขึ้น เพราะการได้ initial implementation หรือคำอธิบายเร็วกว่าเดิม

แต่ iteration ที่เร็วขึ้นก็สร้าง evidence มากขึ้นเช่นกัน ทั้ง variant, log, benchmark, failed attempt และสิ่งที่ต้องตรวจสอบมากขึ้น

raw material เหล่านี้จะมีค่าก็ต่อเมื่อมีใครทำงานเพื่อแยกให้ออกว่าอะไรจริงและอะไรสำคัญ

conversation กับ AI ที่มี 500 ข้อความไม่ได้กลายเป็นความรู้โดยอัตโนมัติ

แต่ script ที่ผ่านการทดสอบจริงในที่สุด พร้อมคำอธิบาย 20 เวอร์ชันที่ไม่ผ่าน อาจกลายเป็นความรู้ได้

ความแตกต่างนี้คือสิ่งที่ผมอยากเก็บไว้ในบล็อก

การเผยแพร่คือวิธีที่ผมป้องกันไม่ให้งานที่มีประโยชน์หายไป

งานเทคนิคส่วนใหญ่มีอายุสั้นอย่างน่าประหลาดใจ

bug ยากถูกแก้

terminal ถูกปิด

deployment สำเร็จ

conversation เลื่อนลงไปในประวัติ

หกเดือนต่อมา แม้แต่ผมเองก็อาจจำไม่ได้แล้วว่าทำไม final implementation ถึงออกมาเป็นแบบนั้น

การเขียนเปลี่ยนเรื่องนี้

มันบังคับให้ผมสร้าง reasoning กลับขึ้นมาใหม่ตอนที่ evidence ยังอยู่

มันสร้างสิ่งที่ค้นหาได้

มันเป็น reference สำหรับงานของผมเองในอนาคต

และบางครั้งดูเหมือนมันจะไปถึงคนที่ผมไม่เคยคาดคิด รวมถึงสื่อ engineering ที่ใช้ภาษาที่ผมพูดไม่ได้

ผมยังไม่มีเหตุผลซับซ้อนอะไรในการทำบล็อกนี้ต่อ

ผมชอบเรียนรู้

ผมชอบสร้างของ

ผมชอบลงลึกเกินไปในปัญหาที่ตอนแรกดูง่าย

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

สำหรับผม แค่นี้ก็เป็นเหตุผลเพียงพอที่จะเผยแพร่

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