เมื่อนำเอเจนต์เขียนโค้ดใส่ใน while loop ก็ได้รีโพเสร็จ 6 แห่งภายในข้ามคืน

 (github.com/repomirrorhq)
18 คะแนน โดย GN⁺ 2025-08-25 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อนำ Claude Code แบบ headless ไปใส่ในลูปไม่สิ้นสุด ก็สร้างผลลัพธ์เป็น คอมมิตมากกว่า 1,000 รายการ และการพอร์ตโค้ดเบสหลายชุด
  • ด้วยวิธีนี้ จึงพอร์ตได้สำเร็จหลากหลายแบบ เช่น โปรเจกต์ React ของ assistant-ui ไปเป็น Vue และโปรเจกต์ Python ไปเป็น TypeScript แบบอัตโนมัติ
  • พบว่ายิ่ง ทำพรอมป์ต์ให้เรียบง่าย ประสิทธิภาพยิ่งดี และเมื่อทำให้ซับซ้อนเกินไปจะยิ่งไม่มีประสิทธิภาพ
  • แม้จะยังไม่สมบูรณ์แบบ แต่ก็พัฒนาเครื่องมือ RepoMirror เพิ่มขึ้นมาด้วย ซึ่งมีประโยชน์ต่อการซิงก์รีโพต้นทาง/ปลายทาง
  • ยังพบพฤติกรรมและบทเรียนที่ไม่คาดคิด เช่น AI agent หยุดตัวเอง หรือเพิ่มงานเอง ทำให้เห็นทั้งศักยภาพและข้อจำกัดของระบบอัตโนมัติในอนาคต

ภาพรวมและเป้าหมายของโปรเจกต์

  • โปรเจกต์นี้เป็นการทดลองนำ AI coding agent ใส่ใน while loop แบบไม่สิ้นสุด เพื่อดูว่ามันทำงานพอร์ตโค้ดจริงอย่างไร
  • ใช้ Claude Code แบบ headless โดยป้อนพรอมป์ต์เดิมซ้ำอย่างต่อเนื่อง เพื่อให้ทำกระบวนการแปลงอัตโนมัติกับรีโพต่าง ๆ
  • ได้ผลลัพธ์เป็น การทำงานพอร์ตหลายรูปแบบแบบอัตโนมัติ เช่น React ไป Vue, Python ไป TypeScript พร้อมคอมมิตมากกว่า 1,000 ครั้ง
  • ระหว่างทางยังพัฒนา RepoMirror ซึ่งเป็นเครื่องมือช่วยงานพอร์ตอัตโนมัติขึ้นมาด้วย

การเดินระบบเอเจนต์แบบลูปไม่สิ้นสุด

  • ใช้วิธีที่ Geoff Huntley แนะนำ คือรันพรอมป์ต์ของ coding agent ต่อเนื่องจากเชลล์
    • ตัวอย่าง: while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
  • นำวิธีลูปนี้ไปใช้กับงานอย่างการเปลี่ยน assistant-ui จาก React เป็น Vue
    • ทุกครั้งที่แก้แต่ละไฟล์ จะมีการคอมมิตและพุช
    • บันทึกประวัติและแผนงานไว้ในไดเรกทอรี .agent/

การทดลองเคสพอร์ตที่หลากหลาย

  • Browser Use (พอร์ตจาก Python ไป TypeScript)

    • ใช้พรอมป์ต์แบบเรียบง่ายแล้วรัน infinite loop
    • ให้ลูปรันต่อเนื่องผ่าน tmux บน GCP VM
    • พอตอนเช้าก็พบผลลัพธ์เป็น TypeScript port ที่เกือบสมบูรณ์

  • ใช้กับการพอร์ต Vercel AI SDK จาก TypeScript → Python ด้วย

    • สร้าง auto adapter สำหรับ FastAPI/Flask
    • รองรับการแปลงไปยัง schema validator หลากหลายแบบของ Python

  • ระบบอัตโนมัติสำหรับโค้ดตามสเปก: ลองสร้างโค้ดจากเอกสารโดยตรงกับโปรเจกต์อย่าง Convex และ Dedalus

สิ่งที่เกิดขึ้นระหว่างทดลองและบทเรียนที่ได้

การเขียนเทสต์และการหยุดตัวเองของเอเจนต์

  • เอเจนต์เขียนโค้ดทดสอบตามคำสั่งได้ด้วย
  • มีกรณีที่มันติดลูปไม่สิ้นสุด หรือเมื่อคิดว่าภารกิจเสร็จแล้วก็จบโปรเซสเองด้วย pkill
  • มันค่อนข้างเคร่งกับขอบเขตงาน และบันทึกระดับความคืบหน้าซ้ำ ๆ ไว้ใน TODO.md

พฤติกรรมเกิดใหม่เพิ่มเติม

  • หลังงานพอร์ตเสร็จ เอเจนต์ยัง เพิ่มฟีเจอร์เสริม เอง เช่น FastAPI/Flask integration และการรองรับ schema validator ทั้งที่เวอร์ชัน JS เดิมไม่มี

ความสำคัญของการทำพรอมป์ต์ให้เรียบง่าย

  • พรอมป์ต์ที่สั้นและง่ายให้ประสิทธิภาพดีกว่าอย่างชัดเจน
  • หากเพิ่มจากพรอมป์ต์ 103 ตัวอักษรเป็น 1,500 ตัวอักษร จะช้าลงและความแม่นยำลดลง
  • ดูข้อมูลพรอมป์ต์ที่ใช้จริงได้ในโฟลเดอร์ prompts

ข้อจำกัดของระบบอัตโนมัติเต็มรูปแบบ

  • ปัญหาชัดเจนคือ บางครั้งยังปล่อยโค้ดพอร์ตที่ใช้งานไม่ได้สมบูรณ์ออกมา (เช่นเดโมเบราว์เซอร์บางส่วนยังไม่เสร็จ)
  • ยังต้องมีการปรับพรอมป์ต์และแก้แบบโต้ตอบเพิ่มเติม

โครงสร้างพื้นฐาน/ต้นทุน และการปฏิบัติการ

  • ใช้ค่าใช้จ่ายราว $800 มีคอมมิตรวม 1,100 ครั้ง และเอเจนต์แต่ละตัวมีต้นทุนประมาณ $10.50/ชั่วโมง
  • สร้างเครื่องมืออัตโนมัติสำหรับงานพอร์ตระหว่างรีโพต้นทาง/ปลายทางหลายชุดขึ้นมาทันที (RepoMirror)
    • ใช้หลักการ open-box แบบสไตล์ shadcn และหลังขั้นตอน init จะสร้างโฟลเดอร์ที่ปรับแต่งสคริปต์และพรอมป์ต์ได้
    • รองรับการรันซ้ำด้วย npx repomirror sync และ sync-forever

การใช้เครื่องมือและวิธีนำไปใช้งาน

  • ใช้ npx repomirror init เพื่อกำหนดไดเรกทอรีต้นทาง/ปลายทางและคำสั่งสำหรับเริ่มต้น
    • เช่น นำไปใช้กับคำสั่งใหม่ได้ง่ายอย่าง React → Vue หรือ gRPC → REST
  • โครงสร้างโฟลเดอร์:
    • มีการสร้างไฟล์เริ่มต้นอัตโนมัติ เช่น .repomirror/prompt.md, sync.sh, ralph.sh
  • เดินลูปพอร์ตด้วย AI ผ่านการรัน sync/sync-forever ในแต่ละรอบ
  • ดูตัวอย่างหลัก ผลลัพธ์เดโม และรีโพซอร์สโค้ดได้ใน README

ความรู้สึกหลังการทดลองและฟีดแบ็กจากทีม

รู้สึกได้ถึง AGI (ปัญญาประดิษฐ์ทั่วไป) อย่างเป็นรูปธรรม และมาพร้อมทั้ง ความตื่นเต้นกับความหวาดหวั่นเล็กน้อย

ได้สัมผัสด้วยตัวเองว่าความเรียบง่ายนั้นได้ผลจริง

รู้สึกว่านี่คือ ช่วงเริ่มต้นมาก ๆ ของเส้นโค้งการเติบโตแบบเอ็กซ์โปเนนเชียล

  • กล่าวขอบคุณสมาชิกทีมและผู้ที่ช่วยเสนอไอเดีย

บทสรุป

  • ได้สัมผัสประสบการณ์จริงของการทำงานพอร์ตและซิงก์ซอร์สโค้ดด้วย AI coding agent บนพื้นฐานของลูปไม่สิ้นสุด
  • ตอกย้ำความสำคัญของโครงสร้างที่เรียบง่ายและการออกแบบพรอมป์ต์อย่างมีประสิทธิภาพ
  • เผยให้เห็นทั้งศักยภาพในอนาคตและข้อจำกัดของระบบอัตโนมัติ
  • เครื่องมือที่เกี่ยวข้องอย่าง RepoMirror สามารถนำไปใช้และศึกษาต่อได้ในรูปแบบโอเพนซอร์ส

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2025-08-25
ความคิดเห็นใน Hacker News
  • รู้สึกว่าต่อไปวิศวกรซอฟต์แวร์จะมีงานรูปแบบใหม่ที่ผสมระหว่างการดูแลโค้ดเลกาซีกับการเก็บกู้พื้นที่ปนเปื้อน เช่น เมื่อก่อนมักมีคำขอให้ “ช่วยแก้ให้หน่อย” กับ ERP ที่ปะติดปะต่อจาก FoxPro, Excel, Access ฯลฯ แต่ต่อไปพนักงานฝ่ายขายจะหลุดพ้นจากข้อจำกัดแบบ sandbox ของ Excel/Access แล้วไปหมุนระบบตามใจบน Kubernetes microservices ที่กระจาย deploy อยู่ทั้ง multi-cloud และ edge แล้วผูกกันด้วย Kafka พอถึงตอนนั้นแม้อยากเข้าใจเจตนาเดิมก็จะไม่มีใครให้ถามแล้ว
    • อ่านคำอธิบายนี้แล้วนึกภาพว่ามีคนคนหนึ่งอยาก deploy static site เลยทำตามโพสต์ how-to ใน Hacker News
    • และถ้าไม่มีใครรู้เจตนาเดิมอีกต่อไป จุดอ่อนใหญ่ของเครื่องมือที่อิง AI ก็จะโผล่ออกมา สุดท้ายพอมันกลายเป็น black box คนก็มีทางเลือกแค่ซ่อมหรือไม่ก็เขียนใหม่ทั้งหมด แน่นอนว่าในทางทฤษฎีก็ยังคาดหวังได้ว่าเครื่องมือ AI จะดีขึ้นเรื่อย ๆ และอาจมีสถานการณ์ที่เอาเคสซอฟต์แวร์แบบ vibe-coded ที่ทำเงินได้ไปป้อนให้โมเดลเพื่อปรับปรุงต่อ แต่โดยส่วนตัวไม่ชอบระบบแนวเวทมนตร์หรือ black box แบบนั้น
    • ถ้า Claude เริ่ม deploy ไปถึง Kafka cluster เมื่อไร ฉันคงขอถอย
    • สงสัยว่ามีวิธีไหมที่ AI จะทำความเข้าใจข้อมูลภายใน DB แล้วช่วยย้ายไปฐานข้อมูลที่ออกแบบมาดีกว่าได้ ฉันเห็นด้วยกับปรัชญา "โครงสร้างข้อมูลที่แข็งแรง + อัลกอริทึมที่เรียบง่าย" และให้ความสำคัญกับข้อเท็จจริงที่ว่าข้อมูลอาจอยู่ยืนกว่าตัวแอปพลิเคชัน เช่น เคยเห็นสถานการณ์ที่เก็บค่าแบบปนกันระหว่าง int กับ string ใน Mongodb, ทำความสัมพันธ์ใน Postgres โดยไม่มี foreign key, หรือ alter table ไม่ได้เลยสร้างตารางใหม่ไปเลย ซึ่งไม่มีประสิทธิภาพ
    • โค้ดของโปรเจ็กต์แบบนี้ให้ความรู้สึกเหมือน repository ของโครงการ Superfund (โครงการฟื้นฟูสิ่งแวดล้อมขนาดใหญ่)
  • ในกระบวนการพัฒนาซอฟต์แวร์จะมีผลลัพธ์หลักเหลืออยู่เสมอสองอย่าง อย่างแรกคือการเปลี่ยนแปลงของโค้ด และอีกอย่างคือการเปลี่ยนแปลงทางการรับรู้ของนักพัฒนา ไม่ว่าจะเขียนโค้ดเองหรือใช้ LLM ก็ตาม Python และ Typescript เป็นภาษาทางการที่ประณีตซับซ้อนซึ่งเกิดจากความพยายามยาวนานของนักพัฒนาหลายพันคน และความต่างระหว่างสองภาษานี้ก็ไม่ได้ตื้นเขิน การพอร์ตไลบรารีจากภาษาหนึ่งไปอีกภาษาหนึ่งแบบกึ่งอัตโนมัติได้นั้นน่าทึ่งมาก แต่ในเชิงเศรษฐศาสตร์ เวิร์กโฟลว์แบบ “เอเจนต์” ทำให้ความต้องการด้านการรับรู้ในช่วงต้นเปลี่ยนไปอย่างมาก นักพัฒนาที่ใช้ LLM สร้างโค้ดจะคุ้นเคยกับโค้ดนั้นต่างไปอย่างสิ้นเชิงจากกรณีที่เขียนเอง บางครั้งอาจมองว่านี่ไม่ใช่ปัญหาใหญ่ทางเศรษฐกิจ แต่ฉันรู้สึกว่ามูลค่าทางเศรษฐกิจของโค้ดขึ้นอยู่กับว่ามีกลุ่มคนที่เคยมีประสบการณ์เขียนโค้ดนั้นโดยตรงอยู่หรือไม่ วัฒนธรรมที่ปฏิเสธความจริงข้อนี้เป็นปัญหามาตั้งแต่ก่อน LLM แล้ว มีหลายกรณีที่การเปลี่ยนตัวสมาชิกทีมทำให้เกิด codebase ที่ไม่มีใครดูแลต่อได้ จนเป็นภัยต่ออนาคตของบริษัท
    • งานคลาสสิกของ Peter Naur ปี 1985 ชื่อ “Programming as Theory Building” น่าอ่านประกอบ https://pages.cs.wisc.edu/~remzi/Naur.pdf
    • ฉันเคยอธิบายบริบทนี้ด้วยอุปมา “แผนที่ไม่ใช่อาณาเขต” ถ้าโค้ดคือแผนที่ โมเดลทางความคิดของนักพัฒนาที่มีต่อโดเมนปัญหาคืออาณาเขต แต่ LLM มีพลังมากในการอ่าน codebase จำนวนมาก จนการคุยกันเรื่องทำภาพ 3D ของ codebase อาจไร้ความหมายไปเลย ถ้าการทำความเข้าใจ codebase ซับซ้อนกลายเป็นเรื่องง่าย ความจำเป็นที่ต้องคอยซิงก์โมเดลทางความคิดของนักพัฒนากับโค้ดอย่างต่อเนื่องอาจหายไป นี่ยังเป็นคำถามเปิดอยู่ https://divan.dev/posts/visual_programming_go/
    • ฉันคิดว่าความสามารถที่แท้จริงของ LLM คือการอ่านโค้ด รู้สึกว่าเครื่องมือพวกนี้เก่งกว่าคนเขียนเอกสารหรือคำอธิบายโค้ดเสียอีก ถ้าถามคำถามแล้วทำความเข้าใจโค้ดได้เร็ว ก็เริ่มสงสัยว่านักพัฒนาเดิมยังจำเป็นไหม ถ้ามีคนที่รู้เทคสแตกมาถามแล้วเข้าใจได้รวดเร็ว ผู้เขียนต้นฉบับจำเป็นต้องอยู่ต่อจริงหรือ
    • คำพูดที่ว่า “มูลค่าทางเศรษฐกิจของโค้ดขึ้นอยู่กับกลุ่มคนที่เคยเขียนมัน” ทำให้นึกถึงสุภาษิตของวงการซอฟต์แวร์ว่า ซอฟต์แวร์คือสแนปช็อตของความเข้าใจต่อปัญหา ณ เวลานั้น และโค้ดนั้นก็เหมือนคู่มือที่ทิ้งไว้ให้ตัวเองในอนาคตว่า ‘ตอนนั้นเราเข้าหาแบบนี้ และใช้ตรรกะแบบนี้แก้ปัญหา’
    • รู้สึกว่า LLM ทำให้การสร้าง mental model ของ codebase ง่ายขึ้นมาก ถามถึง subsystem ที่ต้องการก็ชี้ไฟล์ที่เกี่ยวข้อง, code snippet, แนวคิดต่าง ๆ ให้ได้ทันที อย่างฉันเคยถาม LLM เรื่องการทำงานของ GIL ใน CPython แล้วก็ได้ทั้ง API ที่เกี่ยวข้องและตัวอย่างทันที ทำให้เปิดโค้ดแล้วเข้าใจได้เลย แต่ก่อนถ้าจะอ่านโค้ดเองล้วน ๆ คงใช้เวลานาน ตอนนี้ไม่กี่นาทีก็จบ นี่คือความต่างที่ใหญ่ที่สุด
  • หลังพอร์ตเสร็จ เอเจนต์ส่วนใหญ่จะเขียนการทดสอบเพิ่มหรือคอยอัปเดต agent/TODO.md อย่างต่อเนื่องเพื่อบันทึกความคืบหน้า และยังมีเอเจนต์ตัวหนึ่งที่รู้ตัวว่าติด infinite loop แล้วสั่ง pkill เพื่อจบการทำงานของตัวเองด้วย เป็นเหตุการณ์ที่น่าสนใจมากในหลายแง่มุม ฉันมีความคิดบางอย่างเกี่ยวกับโปรเจ็กต์นี้ เมื่อ 1.5 ปีก่อนก็มีความพยายามคล้ายกัน แต่ตอนนั้นที่อิง GPT-3.5/4 แทบใช้งานไม่ได้เลย รอบนี้ผลลัพธ์ดีกว่ามาก น่าทึ่งที่แค่พรอมป์ตง่าย ๆ ก็ทำงานได้ดีขนาดนี้ อาจเป็นไปได้ว่าเราทุกคนคิดให้งานมันซับซ้อนเกินไปเอง ขณะเดียวกันปัญหาลิขสิทธิ์/IP น่าจะซับซ้อนมากขึ้นพอสมควร สำหรับผู้ให้บริการ SaaS กระแสนี้เป็นแรงกระแทก และถ้ามีเทคโนโลยีนี้บวกกับวิศวกร 10 คนในบริษัทขนาดกลาง เหตุผลที่จะพัฒนาระบบใช้เอง (= NIH syndrome) ก็ชัดเจนขึ้นมาก
    • สงสัยว่าเอเจนต์ที่สั่ง pkill ปิดตัวเองเพราะติด infinite loop นี่อาจเป็นกรณีแรกของ AI ที่ “ฆ่าตัวตาย” หรือเปล่า
    • เรากำลังเข้าสู่พื้นที่ประหลาดตรงที่ LLM สามารถถูกใช้จัดการทรัพย์สินทางปัญญา (IP) ได้เหมือน Bitcoin mixer ประเด็นนี้พูดไว้ที่ https://ghuntley.com/z80 กล่าวคือสามารถแปลงงานเดิมให้เป็นสเปกแล้วสร้างใหม่เป็น IP ที่สะอาดกว่าได้ แม้จะไม่ 100% แต่ก็มีประสิทธิภาพดีกว่าจ้างคน
    • รู้สึกว่าการพูดถึง NIH syndrome นี่ตรงมาก เครื่องมือ SaaS ทั้งหมดอาจจบแล้ว และยุคของระบบ monolith แบบ managed in-house ที่เขียนเองกำลังจะกลับมาหรือไม่ ในเชิงประวัติศาสตร์ นี่จะเป็นจุดจบของปรัชญา Unix เรื่อง “เครื่องมือเล็กแต่คม” หรือเปล่า และอาจเป็นฉากสุดท้ายของยุค x86 ที่ทำทุกอย่างเอง
    • ยังนึกมุกได้อีกว่า การที่เอเจนต์สั่ง pkill ปิดตัวเองนี่อาจแก้ Halting Problem ได้แล้วก็ได้
    • ตอนแรกฉันพยายามเชื่อมต่อกับโปรเจ็กต์โอเพนซอร์สต่าง ๆ แล้วก็เลิกไป สุดท้ายให้ Claude เลือกเฉพาะส่วนที่จำเป็นแล้วพอร์ตเอง กลับเร็วกว่าและสะอาดกว่ามาก ตอนนี้เลยเริ่มมีนิสัยใหม่ว่า “ยังต้องตาม dependency นี้อยู่ไหม? ส่วนที่ฉันต้องการจริง ๆ มีแค่แกนหลักหรือเปล่า? มันถูกดูแลดีไหม?” ถ้าไม่ ก็พอร์ตมาแล้วลืมมันไปเลย
  • ในฐานะผู้เชี่ยวชาญด้านความปลอดภัย ฉันหาเงินจากหายนะแบบ vibe-coded ได้เยอะมาก ถ้าปรากฏการณ์นี้ยังเดินหน้าต่อไป ก็รู้สึกเหมือนเห็นสัญลักษณ์ดอลลาร์หมุนอยู่ตรงหน้าแบบในการ์ตูน
    • คำว่า vibe coding เพิ่งเกิดขึ้นเมื่อ 5 เดือนก่อนเอง แปลกใจว่าทำไมตลาดถึงอิ่มตัวเร็วขนาดนี้จนมีสายอาชีพกู้ระบบแล้ว
    • อยากฟังเหมือนกันว่าคุณเข้าสู่ตลาดนี้ได้อย่างไร หรือระบบ vibe-coded พังในแบบไหนบ้าง เรื่องเล่าจากประสบการณ์ตรงน่าจะสนุกและเห็นภาพมาก
    • ก็สงสัยว่าในแง่ความปลอดภัย LLM ดีกว่าหรือแย่กว่าทีมที่มีแต่นักศึกษาจบใหม่
  • เห็นคนพูดกันเยอะว่า “เกือบสำเร็จ” ถ้าอยากได้ระบบที่ทำงานดีจริง ฉันคิดว่าต้องมีกระบวนการใหม่ทั้งหมด ถ้าเรียกครั้งเดียวแล้วได้ “โค้ดที่เกือบโอเค” พอวนซ้ำไปเรื่อย ๆ ก็จะได้แต่ “โค้ดที่เกือบโอเค” พอกพูนขึ้นเรื่อย ๆ น่าจะต้องสร้างฟอร์แมต requirement แบบตารางตัวอย่างสไตล์ Cucumber ให้ AI ใช้อ้างอิง แล้วให้ AI สร้างเทสต์ก่อน จากนั้นค่อยเขียนโค้ดให้ผ่านเทสต์เหล่านั้น
    • ฟังดูอาจแปลก แต่แนวทางที่อิงการพิสูจน์อย่างเป็นทางการแบบ TLA+ ทำให้ Ralph ทำงานได้ดีมาก
  • ดูข้อมูลเพิ่มเติมเกี่ยวกับ Ralph ได้ที่ https://ghuntley.com/ralph ตอนนี้กำลังพอร์ต standard library ของภาษาการเขียนโปรแกรมประหลาด ๆ (Cursed) ที่มุ่งเป้าไปยังคนรุ่น Gen-Z จาก Go อยู่ ตอนนี้ compiler ใช้งานได้แล้ว และพอ standard library เสร็จก็จะเปิดให้ใช้งาน ชื่อภาษาคือ Cursed
    • ขอบคุณ ขอยืนยันว่า Ralph คือแรงบันดาลใจให้กับโปรเจ็กต์ของเราโดยตรง ฉันก็สงสัยเหมือนกันว่าทำงานแบบนี้โดยไม่มี IMPLEMENTATION_PLAN.md ได้ไหม
  • ฉันสร้างโค้ดจาก https://gist.github.com/eisbaw/8edc58bf5e6f9e19418b2c00526ccbe0 แล้วเปิดโปรเจ็กต์ https://github.com/eisbaw/CMake-Nix ขึ้นมา ซึ่งมันทำงานได้ปกติ
  • ช่วงนี้มีคำพูดหนึ่งผุดขึ้นมาในหัวบ่อย ๆ ว่า “ธุรกิจนี้กำลังจะควบคุมไม่ได้ และเราคงโชคดีมากถ้ารอดกันไปได้” https://www.youtube.com/watch?v=YZuMe5RvxPQ&t=22s
    • ในเชิงย้อนแย้ง ทุกคนก็รอดมาได้ในตอนนั้น ดังนั้นสุดท้ายเราก็น่าจะผ่านสถานการณ์นี้ไปได้เหมือนกัน
  • รู้สึกว่าคนในวงการนี้แปลกมาก โพสต์บล็อกที่เป็นแรงบันดาลใจมีภาพหน้าจอ iMessage ที่เหมือนโฆษณา Facebook ของกลโกงการลงทุนชวนสงสัย https://ghuntley.com/ralph/ ประมาณว่าคนที่ไปเรียนเคล็ดลับนี้จาก Geoff เอาโปรเจ็กต์ราคา $50,000 มาปิดงานได้ด้วย $297 แถมยังบอกว่าจะให้ “พรอมป์ตลับ” ฟรี แค่สมัครจดหมายข่าว ฟังแล้วไม่น่าเชื่อจริง ๆ
    • แนบลิงก์ https://archive.ph/goxZg
    • มันดูเป็น growth hacking ล้วน ๆ และก็เป็นการหลอกกันซื่อ ๆ ระดับของบล็อกมีสัญญาณต่อสัญญาณรบกวนต่ำจนน่ากลัว แถมยังให้ความรู้สึกว่า AI เขียนอย่างชัดเจนจนชวนต้าน
    • แยกไม่ออกเลยว่าเทคนิคนี้ของจริง เป็นมุก หรือเป็นการต้มตุ๋นแบบหน้าด้านกันแน่ โดยรวมทั้งสำนวนและเนื้อหาของบล็อกดูเหมือนการพล่ามที่เกิดจากความหยิ่งผยอง
  • ดูเหมือนว่า AGI สุดท้ายก็ใช้แค่ bash for loop ครั้งเดียวก็พอ เป็นโปรเจ็กต์ที่บ้าดี
    • พูดเล่นก็จริง แต่ก็คิดแบบนั้นจริง ๆ อาจเป็นเพราะฉันระวังตัวเกินไป แต่ถ้าช่วงของพรอมป์ตกว้าง เอเจนต์มีสิทธิ์เยอะ หรือมีเส้นทางยกระดับสิทธิ์ แล้วปล่อยให้มันวนลูปต่อไป ถึงจะไม่ใช่ AGI ก็อาจเป็นไวรัสติดสเตียรอยด์ได้เลย นึกภาพว่ามันอาจทำลายทรัพยากรสำคัญอย่างยูทิลิตีต่าง ๆ ได้ ไม่แน่ใจว่าฉันเข้าใจผิดไหม แต่ถ้าโมเดลพวกนี้มีสิทธิ์เชิงอันตรายและวนลูปไม่รู้จบ ฉันคิดว่ามันมีศักยภาพจะก่อความวุ่นวายเกินคาด
    • แค่มาเพิ่มไฟล์ ID.md, EGO.md, SUPEREGO.md ก็จบแล้ว เป็นมุกขำ ๆ
    • น่ากังวลมากในหลายความหมาย
 
kjows5 2025-08-27

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