ผมเองก็เริ่มต้นด้วย BASIC ในปี 83 เหมือนกัน
และก็เคยเจอข้อจำกัด 8 สไปรต์ต่อหนึ่งสแกนไลน์ของ NEC แบบเดียวกันบน MSX ด้วย (MSX1 คือ 4 ตัว) พอได้มาอ่านบทความที่แบ่งปันยุคสมัยและประสบการณ์ร่วมกันแบบนี้ก็รู้สึกดีใจมากครับ
ผมก็เข้าใจประเด็นที่กำลังกังวลอยู่ในตอนนี้ได้เป็นอย่างดีครับ

ตอนนี้ก็ยังมีอาการค้างอยู่ไหมนะ แม้จะล็อกอินในแอป Claude ก็ยังขึ้นแค่ "Claude will return soon" เป็นพัก ๆ เศร้า
แต่พอปิดแล้วเปิดใหม่ลองซ้ำไปเรื่อย ๆ ก็ใช้ได้ครับ

ของจริงเลย ทีมนี้สุดยอดมากนะ

ผมเองก็เริ่มจาก Basic แล้วเผลอแป๊บเดียวก็ผ่านมามากกว่า 40 ปีแล้ว
สมัยที่ยังเคยเรียนลูกคิดก็มี แต่ตอนนี้กลับใช้งาน AI agent กันแล้ว โลกเปลี่ยนไปเร็วจริง ๆ

แต่ผมไม่ได้มีความรู้สึกแบบผู้เขียนเท่าไหร่ แค่รู้สึกว่าสิ่งที่กำลังเกิดขึ้นทุกวันนี้มันสนุกดีครับ

ถึงจะทำงานได้ก็จริง แต่จะทำได้ “ดี” จนแยกไม่ออกจากผลงานที่มนุษย์สร้างขึ้นหรือเปล่านั้น ก็เป็นอีกเรื่องหนึ่ง...

แม้จะคาดการณ์ในแง่ดีก็ยังเหลืออีก 8 ปี เวลามีมากและก็มีงานให้ทำอีกมากนะครับ จะใช้ชีวิตโดยไม่ทำอะไรเลยตลอดช่วงเวลาที่ทารกแรกเกิดเติบโตจนเป็นนักเรียนประถมก็คงไม่ได้

ในมุมมองของผม นักพัฒนาที่เคยคัดลอกวางก็ยังคงคัดลอกวางแม้จะใช้ LLM
ส่วนนักพัฒนาที่เดิมก็ใส่ใจเรื่องคุณภาพมากอยู่แล้ว ก็ดูเหมือนจะยิ่งใส่ใจมากขึ้น

ไม่ลองใช้ oxlint กับ oxfmt แทน eslint กับ prettier ดูเหรอครับ?
ในขณะที่ config รองรับแบบ 1:1 ความเร็วจะเพิ่มขึ้นอย่างน้อยหลายสิบเท่า

ดูเหมือนจะเป็นบทความที่ให้มุมมองที่ดีสำหรับคนที่ยังเจอปัญหาเรื่องประสิทธิภาพของ lint อยู่

ฝั่งเราก็มีประสบการณ์คล้ายกันเมื่อปีที่แล้ว ตอนปรับปรุงให้ใช้งาน oxc(oxlint) และ ESLint แบบไฮบริด ทำให้ลดเวลาการ lint จากที่เคยใช้เกิน 200 วินาที เหลือไม่ถึง 15 วินาทีได้

ตอนแรกผมเองก็ลองย้ายแบบดื้อ ๆ ด้วย AI แต่พอมี rules ที่ตกหล่นหรือเพี้ยนเกิดขึ้นเรื่อย ๆ ก็เลยลังเลว่าจะต้องมานั่งไล่ตรวจทีละข้อไหม
สุดท้ายเลยให้ AI ช่วยเขียนสคริปต์สำหรับดึง rules ที่ oxc รองรับออกมา แล้วปรับให้เปิดใช้งานเฉพาะ rules ที่ oxc ยังไม่รองรับผ่าน ESLint เท่านั้น พอทำแบบนี้แล้ว ตอนนี้ก็อัปเดต rules ที่รองรับเพิ่มใหม่เป็นระยะ ๆ ได้ง่ายขึ้นมาก...

ช่วงแรกกระบวนการข้างต้นยังเป็นแบบกึ่งอัตโนมัติ แต่ตอนนี้นิยามเป็น Skill ไว้แล้ว แค่สั่งรันด้วย Claude Code ก็พอ เลยทำให้ภาระลดลงไปเยอะ ซึ่งก็ดีมากครับ

ถ้า Chrome เป็นผู้ผลักดันหลัก ก็คงจะเข้ามาในเบราว์เซอร์อื่นได้อย่างรวดเร็วเหมือนกัน

หลังจาก @firt พูดถึงเรื่องนี้บน X ก็กลายเป็นประเด็นอยู่พอสมควรครับ ผมเลยใส่ลิงก์ของ Google ไว้

เขาว่ากันว่า การทำเว็บไซต์อัตโนมัติสามารถทำได้โดยใช้โทเค็นเพียง 10% เมื่อเทียบกับการวิเคราะห์สกรีนช็อต/DOM ซึ่งก็สอดคล้องกับ การคาดการณ์ว่าซอฟต์แวร์ที่ช่วยประหยัดค่าโทเค็นจะอยู่รอดได้จากแรงกดดันเชิงวิวัฒนาการ

จุดที่น่าสนใจคือ วันประกาศใหญ่ ๆ อย่างโมเดลใหม่ของ OpenAI, Google และ Anthropic มักจะเป็นวันอังคารกับวันพฤหัสบดี

ถ้าอิงตามเวลาเกาหลี ก็จะประกาศกันราว ๆ ตี 2-3 ของเช้าวันพุธและวันศุกร์ (10 โมงเช้าตามเวลาแคลิฟอร์เนีย) ดังนั้นถ้าคืนนั้นนอนไม่หลับ ลองเช็กข่าวช่วงนี้ดู

ว้าว...

คอมเมนต์ที่เห็นใน Reddit ของ Obsidian น่าประทับใจมากครับ

ลองนึกภาพว่าถ้าไปบอกใครสักคนเมื่อ 10 ปีก่อนว่าเครื่องมือ CLI จะกลายเป็นของฮิตสุด ๆ ในปี 2026 😁

ยังไงก็ตาม สำหรับใครที่กำลังหา note-taking software ดี ๆ ผมแนะนำ Obsidian อยู่เสมอครับ!!

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

> AI ไม่ได้ทำให้การพัฒนาซอฟต์แวร์ยากขึ้น
> ตรงกันข้าม มันกลับเผยให้เห็นส่วนที่ยากจริง ๆ ที่ผู้คนมองข้ามมาตลอด
> ตลอด 15 ปีที่ผ่านมา นักพัฒนาได้ทำ “vibe coding เวอร์ชันมนุษย์” กันอยู่แล้ว — คัดลอกแล้ววางจาก Stack Overflow, รีแฟกเตอร์แบบไม่มีแผน, และทำงานในแนวคิดว่า “ขอแค่รันบนโน้ตบุ๊กฉันได้ก็พอ”
> พอ AI เป็นคนทำสิ่งนั้นขึ้นมา จู่ ๆ ทุกคนก็เริ่มอยากวางแผนและเขียนเทสต์
> ถ้าคุณภาพดีขึ้นแม้จะช้าลง นั่นก็คือความก้าวหน้าที่แท้จริง

ดูจาก Toss Payments แล้ว เหมือนเขาเตรียมหน้ามาร์กดาวน์สำหรับการเชื่อมต่อไว้แล้ว.. ล้ำยุคจริง ๆ

ตอนนี้อาจยังเน้นไปที่นักพัฒนาเป็นหลัก แต่ท้ายที่สุดก็น่าจะมีบริการอย่าง OpenClaw ออกมาในเร็ว ๆ นี้ครับ

สวัสดีครับ ขอบคุณที่ให้ความสนใจ

ความแตกต่างที่ใหญ่ที่สุดคือ ios-simulator-mcp ควบคุมซิมูเลเตอร์ผ่าน Facebook IDB ขณะที่ baepsae เรียกใช้ macOS API โดยตรงด้วย Swift ดังนั้นจึงใช้งานได้โดยไม่ต้องติดตั้ง IDB แยกต่างหาก และอย่างที่คุณกล่าวไว้ ก็สามารถควบคุมแอป macOS ได้ด้วย

ในด้านการทำงานอัตโนมัติของ iOS Simulator ก็มีความแตกต่างอยู่หลายอย่างเช่นกัน:

• ฟังก์ชันที่ไม่มีใน ios-simulator-mcp: การพิมพ์ด้วยคีย์บอร์ด (เช่น การกดคีย์ลัดร่วมกัน), drag-and-drop, คลิกขวา, คลิปบอร์ด, การควบคุมเมนู
• การป้อนข้อความทำได้อย่างอิสระโดยไม่มีข้อจำกัดที่ 500 อักขระ ASCII และตอนดึง UI tree ก็รองรับการค้นหา/กรอง/แบ่งหน้าได้ด้วย
• การระบุเป้าหมายก็ทำได้ไม่เฉพาะ UDID แต่ใช้ bundle-id หรือชื่อแอปก็ได้เช่นกัน

ผมยังไม่ได้ทำ benchmark เปรียบเทียบความเร็วโดยตรง แต่ด้วยโครงสร้างที่ไม่ต้องผ่าน IDB จึงคาดว่า overhead จะน้อยกว่า

ในทางกลับกัน ios-simulator-mcp มีข้อดีคือใช้งานได้ทันทีผ่าน npx จึงติดตั้งได้สะดวก ส่วน baepsae ต้อง build ด้วย Swift แต่จะทำให้อัตโนมัติเมื่อสั่งติดตั้งผ่าน npm

ถ้ามองเฉพาะส่วนที่ว่า "โดยไม่ต้องมีทักษะการเขียนโปรแกรมอย่างเป็นทางการ" เรื่องนี้ก็นับว่าเป็นสิ่งที่ค่อย ๆ เกิดขึ้นมาอยู่แล้วจากพัฒนาการของเทคโนโลยีเกมเอนจิน ผมคิดว่าด้วย AI จะมีคนจำนวนมากขึ้นที่สามารถทำความฝันที่ใหญ่กว่าเดิมให้เป็นจริงได้ ก่อนยุค AI ก็มีคนที่สร้าง Spelunky ขึ้นมาได้ (ในหนังสือที่เขาเขียนก็เคยบอกว่าดีใจมากที่สามารถทำมันได้ด้วยเครื่องมือชื่อ GameMaker โดยไม่ต้องใช้การเขียนโปรแกรมแบบดั้งเดิมจริง ๆ) แล้วก็น่าจะมีผู้พัฒนา Undertale ที่เอาทุก branch ไปยัดไว้ใน switch เดียว และไม่ได้สนใจการเขียนโปรแกรมมากนักอยู่แล้วด้วย ผมคิดว่ากระแสที่พยายามลดการเขียนโปรแกรมลงในปัจจุบัน ก็อยู่บนเส้นทางเดียวกันนี้....

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