ผมกำลังเขียนโค้ดด้วยมือต่อเนื่องมาหลายเดือนแล้ว

 (miguelconner.substack.com)
23 คะแนน โดย GN⁺ 11 일 전 | 6 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วงเวลาที่ AI coding agent กลายเป็นเรื่องแพร่หลาย นักพัฒนาคนหนึ่งกลับเข้าร่วมรีทรีต 3 เดือนที่ เขียนโค้ดด้วยมือโดยไม่ใช้ LLM และบันทึกประสบการณ์เอาไว้
  • ระหว่างใช้สัปดาห์ที่ 6 ที่ Recurse Center ใน Brooklyn เขากำลังสร้าง LLM ขึ้นมาเองตั้งแต่ต้น ฝึกฝนทักษะ Python และเสริมความเข้าใจต่อชั้นนามธรรมต่าง ๆ ของคอมพิวเตอร์ไปพร้อมกัน
  • แม้ coding agent จะทำให้การวนรอบพัฒนาและการ deploy รวดเร็วขึ้น แต่การเขียนโค้ดด้วยมือตรง ๆ คือการทำสองอย่างพร้อมกันคือ ถ่ายทอดสิ่งที่ต้องการ และเรียนรู้ codebase ไปพร้อมกัน
  • โดยอ้างอิงอุปมา "การเขียนก็เหมือนการออกกำลังกาย" ของ Cal Newport ผู้เขียนมองว่าความพยายามทางความคิดในการสร้างโค้ดคือองค์ประกอบสำคัญของทักษะ
  • จากข้อสังเกตที่ว่าวิศวกรที่ใช้เครื่องมือ AI ได้เก่ง มักเป็นคนที่มีความรู้เชิงลึกอยู่แล้ว เขาจึงเน้นว่า แม้ในยุค AI ความสามารถพื้นฐานก็ยังเป็นตัวสร้าง leverage

LLM และประสบการณ์การเขียนโค้ด

  • ตลอด 2 ปีที่ผ่านมา ผู้เขียนสร้าง AI agent ที่ Aily Labs ใน Barcelona
    • ต้นปี 2024 เขาสร้าง web search agent สำหรับใช้ภายใน ซึ่งเกิดก่อนบทความ "Building Effective AI Agents" ของ Anthropic ราว 6 เดือน และก่อน DeepResearch ของ OpenAI ราว 1 ปี
    • เขาเป็นผู้ใช้ยุคแรกของ Cursor และเข้าไปมีส่วนร่วมตั้งแต่เนิ่น ๆ กับ การสร้าง knowledge graph โดยใช้ LLM
  • เขาเป็นผู้นำ journal club รายสัปดาห์ และนำเสนอเปเปอร์เกี่ยวกับการสร้าง open-source LLM
    • ครอบคลุมงานอย่าง DeepSeek R1, Olmo 3 ของ Ai2 และ Llama 3 ของ Meta
    • สิ่งนี้ช่วยให้เข้าใจ trade-off ระหว่างการฝึกโมเดลภายในองค์กรกับการสร้าง workflow บนโมเดลปิดระดับ SOTA
  • นับตั้งแต่เริ่มใช้ LLM ครั้งแรกในปี 2023 เขาก็สนใจกลไกการทำงานและการประยุกต์ใช้อย่างต่อเนื่อง

การเขียนโค้ดด้วยตนเองในฐานะองค์ประกอบหลักของทักษะ

  • สิ่งที่เขาตระหนักได้จากการศึกษา LLM ควบคู่กับการนำมาใช้เขียนโค้ด
    • เมื่อเขียนโค้ด "ด้วยมือ" เรากำลังทำสองอย่างพร้อมกัน คือ เขียนสิ่งที่ต้องการ และเรียนรู้ codebase ไปพร้อมกัน
    • เมื่อใช้ coding agent เราจะได้สิ่งที่ระบุไว้ใน prompt อย่างแม่นยำเท่านั้น และถ้ายังไม่ชัดเจนว่าต้องการอะไร agent ก็จะช่วยตัดสินใจแทนด้วย สมมติฐาน (assumption) จำนวนมาก
    • ในกรณีนี้การเรียนรู้จะลดลง และความเข้าใจต่อ codebase ก็ถดถอยลง
  • ในขณะเดียวกัน coding agent ก็ช่วยให้วนรอบงานได้เร็วและ deploy ซอฟต์แวร์ที่เสถียรได้ อีกทั้งยังเป็น ติวเตอร์ชั้นยอด
  • อ้างอิง คอลัมน์ NYT ของ Cal Newport
    • "งานเขียนของคุณควรเป็นของคุณเอง ความตึงเครียดที่จำเป็นต่อการเขียนบันทึกหรือรายงานให้ชัดเจนนั้น เป็นกิจกรรมทางความคิดที่เทียบได้กับการฝึกในยิมของนักกีฬา ไม่ใช่ความน่ารำคาญที่ควรถูกกำจัดออกไป แต่เป็น องค์ประกอบหลักของทักษะ"
    • เขามองว่าอุปมานี้ใช้กับการเขียนโค้ดได้เช่นกัน
  • โปรแกรมเมอร์ฝีมือเยี่ยมที่เขาเคยร่วมงานด้วยที่ Aily มักเป็นคนที่ ใช้ AI ได้เก่งมาก เช่นกัน และความรู้เชิงลึกนี่เองที่สร้าง leverage ให้กับเครื่องมือ AI

code retreat คืออะไร

  • Recurse Center (RC) คือโปรแกรมรีทรีตเขียนโปรแกรมแบบเต็มเวลาและขับเคลื่อนด้วยตนเองใน Brooklyn
    • Retreat: "ช่วงเวลาที่ถอยออกจากชีวิตประจำวันชั่วคราวเพื่อจดจ่อกับกิจกรรมอย่างใดอย่างหนึ่ง"
    • เข้าร่วมหลังผ่านใบสมัครและ coding interview จากนั้นใช้เวลา 6 หรือ 12 สัปดาห์จดจ่อกับการเขียนโปรแกรม
    • จุดเด่นคือ สภาพแวดล้อมการทำงานร่วมกันแบบ cohort ที่มีผู้เข้าร่วมหลากหลายความเชี่ยวชาญ รวมถึงโปรแกรมเมอร์ที่มีประสบการณ์หลายสิบปีจำนวนมาก
    • เปิดให้เข้าร่วมฟรี
  • เป้าหมายที่ Recurse Center

    • เรียนรู้ LLM ตั้งแต่ต้น

      • ตั้งเป้าจะเขียน Transformer ขึ้นมาเอง แทนการ fork codebase ที่มีอยู่แล้ว โดยครอบคลุมทั้ง pre-training และ post-training

    • เขียน Python ด้วยมือให้เก่งขึ้น

      • แม้จะทำงานกับ Python มาหลายปี แต่ยังรู้สึกว่ามีเรื่องให้เรียนรู้อีกมาก และอยากลดการเปิดเอกสารหรือถาม LLM ให้น้อยที่สุด เพื่อสร้างสัญชาตญาณต่อการจัดโครงสร้างโปรเจกต์

    • เข้าใจคอมพิวเตอร์ให้ลึกขึ้น

      • เขามองว่าคอมพิวเตอร์เป็นเครื่องจักรที่ซับซ้อนมากซึ่งทำงานอยู่บนชั้นนามธรรมหลายระดับ
      • เพราะไม่ได้เรียน Computer Science อย่างเป็นทางการ เขาจึงอยากสร้าง mental model ที่ดีขึ้นว่าชั้นเหล่านี้ทำงานร่วมกันอย่างไร
      • แม้จะยังไม่มีแผนที่เป็นรูปธรรมมากนัก แต่เขามองว่า RC เป็นสถานที่ที่เหมาะ

ความคืบหน้า

  • 1. ฝึก LLM ตั้งแต่ต้น

    • เขาทำการบ้านชิ้นแรกของคอร์ส CS336: Language Modeling from Scratch ของ Stanford โดยไม่ใช้เครื่องมือช่วยเขียนโค้ดสำหรับ LLM
      • การบ้านยาว 50 หน้า ทำร่วมกับ Recurser อีกคน
      • เขียน tokenizer ที่ optimize ด้วย Python และสร้าง สถาปัตยกรรมแบบ GPT-2 เวอร์ชันปรับปรุงด้วย PyTorch
      • หลังทำ ablation จำนวนมากเพื่อ tune hyperparameter บนชุดข้อมูล Tiny Stories แล้ว จึงนำไปใช้กับ OpenWebText ราว 9 พันล้านโทเค็น
      • จากการทำ learning rate sweep กับโมเดล 17M พารามิเตอร์ที่เขาเขียนเอง พบว่า learning rate ที่สูงทำให้เกิดความไม่เสถียร ใช้เวลาฝึกประมาณ 1 ชั่วโมงบน A100
    • แผนต่อจากนี้
      • ทำการบ้านที่เหลือของ CS336: การ optimize language model, การประเมิน/คำนวณ scaling law, การแปลงข้อความดิบเป็นข้อมูล pre-training และ model post-training
      • เขาเริ่มการบ้านชิ้นที่สองแล้ว ซึ่งเป็นเรื่อง GPU profiling และ การ implement FlashAttention2 ใน Triton
      • เป้าหมายสุดท้ายคือมีโมเดลที่ผ่าน post-training ด้วยตัวเอง

  • 2. พัฒนาทักษะ Python

    • ฝึกด้วยการเขียน agent และ neural network ขนาดเล็กจำนวนมากด้วย Python และ PyTorch
    • สิ่งที่ช่วยมากที่สุดคือ pair programming กับคนที่มีประสบการณ์ Python มากกว่า 10 ปี
      • คู่หนึ่งของเขา เมื่อจำ syntax หรือพฤติกรรมการทำงานไม่ได้ จะ เปิด terminal ทันทีแล้วพิมพ์ตัวอย่างสั้น ๆ เพื่อตรวจสอบพฤติกรรมภายในไม่ถึง 1 นาที
      • กระบวนการแบบฝังเป็นความจำกล้ามเนื้อนี้ ที่แก้ปัญหาได้โดยไม่ต้องค้น Google หรือถาม LLM ช่วยปลดล็อกอาการติดขัดได้มาก
    • เขาวางแผนจะเดินหน้าแนวทางนี้ต่อด้วยการแก้โจทย์อย่าง Advent of Code แบบ pair programming
      • แม้การร่วมมือกันแบบเรียลไทม์จะทำให้รู้สึกกดดันในช่วงแรก แต่ก็ทำให้สัมผัสได้ถึงการเติบโตอย่างรวดเร็ว

  • 3. เข้าใจคอมพิวเตอร์ให้ลึกขึ้น

    • เขียน fizzbuzz ด้วย BASIC บนคอมพิวเตอร์ Apple IIe ปี 1983
      • ได้สัมผัสกระบวนการแก้ไขและรันโค้ดแบบ manual โดยตรง และมองเห็นทั้งความต่างและความคล้ายกันของคอมพิวเตอร์ในอดีตกับปัจจุบัน
    • พัฒนาทักษะ Unix/terminal ผ่านการเข้าร่วม CTF Fridays
      • แก้โจทย์ "war games" อย่าง Bandit ผ่าน terminal เพื่อเก็บรหัสผ่านและไต่ระดับ
      • ตอนนี้เขาจึงพอเข้าใจได้ว่า Claude Code กำลังพยายามรันอะไรบนเครื่องของตนเอง
    • เขียน perceptron ชั้นเดียวด้วยมือใน Vim
      • ช่วงแรกน่าเบื่อมาก แต่ดีขึ้นหลังได้ทิปและเรียนรู้คีย์ลัดจาก Recurser คนอื่น
      • มันมีประโยชน์มากเวลาต้องแก้ไฟล์ช่วงท้าย ขณะรันงานฝึกโมเดลบน cloud GPU
    • เข้าร่วม เวิร์กช็อป Clojure (นำโดยผู้มีประสบการณ์กว่า 15 ปี)
      • เขามีประสบการณ์กับภาษาเชิงฟังก์ชันไม่มาก จึงรู้สึกว่าหัวข้อนี้น่าสนใจมาก
      • หลังบทเกริ่นนำสั้น ๆ ก็ดำเนินต่อด้วย mob programming โดยให้ผู้เข้าร่วมผลัดกันช่วยแก้ปัญหาคนละ 1-2 นาที
    • เข้าร่วม การนำเสนอเทคนิครายสัปดาห์ 5 นาที
      • มีหัวข้อหลากหลาย เช่น "Running Rust Code", "GPUs for Dummies", "Typesafe APIs for Type B Personalities", และ "Some Useless Agents" (หัวข้อของเขาเอง)
      • จนถึงตอนนี้เขาพูดไปแล้ว 2 ครั้ง (สถาปัตยกรรม agent แบบเรียบง่าย และการขยายเครื่องมือ MCP อย่างมีประสิทธิภาพ) และสัปดาห์นี้จะพูดเรื่อง วิธี optimize GPU
    • แค่ได้ฟังโปรเจกต์และเส้นทางอาชีพของผู้เข้าร่วมคนอื่น ๆ ก็ทำให้ความเข้าใจต่อขอบเขตของปัญหาที่คอมพิวเตอร์แก้ได้กว้างขึ้น

6 สัปดาห์ที่เหลือ

  • หลังจบรีทรีต เขาวางแผนจะกลับไปทำงาน deploy agent สู่ production และรัน eval ด้วยทักษะและเทคโนโลยีใหม่ที่ได้มา
  • เขากังวลว่า 6 สัปดาห์ที่เหลืออาจไม่พอทำทุกอย่างในรายการให้เสร็จ
  • แต่คุณค่าที่แท้จริงของ RC ไม่ได้อยู่ที่การทำทุกอย่างให้ครบ แต่อยู่ที่ การได้ใช้เวลากับการเขียนโค้ดเอง

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

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

 
nemorize 10 일 전

โค้ดสำหรับงานให้ AI agent จัดการทั้งหมด โดยพยายามให้มันวิ่งเป็นลูปได้นานที่สุด
ส่วนโปรเจกต์ส่วนตัวที่ทำเป็นงานอดิเรก ผมพัฒนาเองโดยไม่ใช้ทั้ง AI assistant และ AI autocomplete เลย (...)
 
hhcrux 10 일 전

นึกถึงโพสต์ขำ ๆ ที่เพิ่งเห็นเมื่อไม่นานนี้เลย
พอลองเขียนโค้ดด้วยมือตรง ๆ แล้วให้ AI ช่วยปรับปรุงให้
ก็ขึ้นมาว่า
Phase 1: ลบโค้ดขยะ
5555
 
savvykang 10 일 전

ผมปิดฟีเจอร์ AI ของ VSCode แล้วใช้ Claude Code แทน ซึ่งรู้สึกลื่นและใช้งานสบายกว่าชัดเจน
 
loblue 11 일 전

ฉันเลิกใช้ vim แล้วเปลี่ยนไปใช้ vscode เพราะ AI
แต่รู้สึกเหมือนทำให้ความสุขในการพัฒนาหายไป เลยกลับมาใช้ vim อีกครั้ง
ตอนนี้ใช้ AI เป็นผู้ช่วยอยู่ และดูเหมือนว่าจะได้ความสุขในการพัฒนากลับคืนมาอย่างชัดเจน
 
overthinker1127 10 일 전

ผมกลับมาใช้ nvim หลังจากลองใช้ AI Agent เสียอีกครับ
เพราะการดูซอร์สด้วย nvim สะดวกกว่ามาก..
 
GN⁺ 11 일 전
ความคิดเห็นบน Hacker News

  • เทอมนี้ฉันกำลังสอนนักเรียนอายุ 18 ปี ให้เรียน 6502 assembly บน Apple II Plus ที่จำลองขึ้นมา
    นักเรียนพวกนี้เคยเรียน Python, โครงสร้างข้อมูล และ OOP มาแล้วในสภาพแวดล้อมสมัยใหม่
    ใช้เวลาเรียนและแล็บราว 10 ชั่วโมงเพื่อทำความคุ้นเคยกับรีจิสเตอร์ คำสั่ง วิธีการอ้างแอดเดรส memory map และ Apple monitor routines จากนั้นก็ช่วยกันทำโปรแกรมวาดรูป ลูกบอลเด้ง ๆ สไปรต์ที่สร้างเอง และระบบตรวจชนแบบง่าย ๆ ด้วยกราฟิกความละเอียดต่ำ 40x40
    งานที่มอบหมายคือให้ทำเกมง่าย ๆ อย่าง Snake หรือ Tetris ขึ้นมาเองแล้วสาธิต พร้อมอธิบายว่ามันทำงานอย่างไร
    ตอนแรกพวกเขาเกลียด line editor แต่ไม่นานก็เริ่มวางแผนและถกกันก่อนจะลงมือเขียนโค้ด
    นิสัยที่เมื่อก่อนฉันย้ำในชั้นเรียนตลอดแต่ไม่ค่อยเกิดขึ้นจริง กลับฝังตัวได้เองอย่างเป็นธรรมชาติเมื่อไม่มีเครื่องมือทรงพลังให้พึ่ง
    หลังจากนั้นนักเรียนยังบอกด้วยว่า ต่อให้ไม่ได้เปิดโค้ดทั้งหน้าจอ พวกเขาก็ยังมีโค้ดอยู่ในหัว
    สุดท้ายพวกเขาก็คงกลับไปใช้เครื่องมือสมัยใหม่อีกอยู่ดี แต่ฉันรู้สึกว่าประสบการณ์แบบนี้มีความหมายมาก

    • สิ่งที่ฉันรู้สึกจากการสอนเขียนโปรแกรมคือ Python ยังไม่ค่อยเหมาะจะเป็นภาษาแรก
      เหตุผลใหญ่สุดคือการเขียนโปรแกรมต้องตระหนักเรื่อง type อยู่ตลอด แต่ Python กลับทำให้ส่วนนั้นพร่าเลือนไป
      เรื่องช่องว่างก็มีทั้งกรณีที่จำเป็นและไม่จำเป็น สำหรับคนที่คุ้นแล้วมันอาจธรรมชาติพอ ๆ กับการหายใจ แต่สำหรับมือใหม่อาจชวนสับสน
    • ฉันเองก็เคยเรียนคลาสที่แทบเหมือนกันนี้เมื่อ 9 ปีก่อน และมันเป็นหนึ่งในประสบการณ์ที่มีประโยชน์ที่สุดในหลักสูตรปริญญา CS ของฉัน
      ด้วยความเป็น สภาพแวดล้อมระดับล่าง และเครื่องมือที่จำกัด มันทำให้ฉันติดนิสัยคิดก่อนลงมือเขียนโค้ด
      ทุกวันนี้เวลาทำงาน greenfield ฉันก็ยังหยิบปากกากับกระดาษกราฟออกมาก่อน วาดฟังก์ชันหรือคลาสที่น่าจะใช้เป็นกราฟหลวม ๆ แล้วเชื่อมด้วยลูกศร
      แน่นอนว่าถ้าผลักแนวนี้สุดทางเกินไป มันก็กลายเป็น การวางแผนแบบ waterfall อีกรูปแบบหนึ่งได้ จึงต้องพอดี ๆ
      แค่ใช้เวลาคิดโครงสร้างล่วงหน้าไม่กี่ชั่วโมง เวลาลงมือเขียนจริงก็ลดลงมากแล้ว
      แทบไม่เคยมีครั้งไหนที่ผลลัพธ์สุดท้ายจะเหมือนแบบบนกระดาษเป๊ะ ๆ แต่กระบวนการคิดภาพใหญ่ก่อนนี่เองที่เพิ่ม productivity
      ถ้าเริ่ม scaffold ใน editor เราจะไหลเข้าสู่ implementation จริงได้เร็วมาก แต่บนกระดาษยังไงก็ต้องกลับมาพิมพ์ใหม่อยู่ดี เลยช่วยให้หลุดจากเรื่องจุกจิกอย่างการตั้งชื่อตัวแปรหรือเลือก method ได้
      ตอนที่ทำ vibe coding อยู่สองสามครั้ง วิธีนี้ก็ยิ่งมีประโยชน์ เพราะช่วยให้ฉันเขียนพรอมป์ต์ได้เฉพาะเจาะจงและมีโฟกัสกว่ามาก
    • ตอนแรกฉันก็สงสัยว่าทำไมต้องให้ใช้ line editor ทั้งที่น่าจะมี VS Code plugin ที่มี syntax highlighting อยู่แล้ว
      แต่พออ่านตรงที่ว่านักเรียนมีโค้ดอยู่ในหัว ฉันก็เปลี่ยนความคิด
      มันทำให้นึกถึงที่ Zed Shaw เคยพูดทำนองเดียวกันว่า โค้ดที่เขียน โดยไม่มี IDE ดูดีกว่าประหลาด
      ในบริบทคล้ายกัน ฉันเคยเรียนจากหนังสือ "From Nand to Tetris" ซึ่งช่วยให้เข้าใจอย่างมากว่าคอมพิวเตอร์ assembler และ compiler ทำงานอย่างไร
    • หนึ่งในประสบการณ์ที่น่าประทับใจที่สุดช่วงต้นอาชีพวิศวกรของฉัน คือการได้ทำงานกับวิศวกรอาวุโสมากคนหนึ่ง
      เวลาเขาได้รับปัญหามา เขาจะไม่เริ่มพิมพ์ทันที แต่จะคิดก่อน จดอะไรนิดหน่อยลงกระดาษ เดินเล่นสักรอบ แล้วค่อยกลับมานั่งหน้าคอม
      จากนั้นเขาก็แทบพิมพ์รวดเดียวจบ แล้วคอมไพล์แค่ตอนท้าย ซึ่งก็มักจะทำงานได้จริง
      แทบไม่มีแม้แต่คำพิมพ์ผิด
      ประสบการณ์นี้ทำให้ฉันรู้สึกชัดมากว่า ความสามารถในการสร้าง problem space และตัวโปรแกรมขึ้นในหัวก่อนแล้วค่อยใช้เหตุผลกับมัน สำคัญแค่ไหน
      เมื่อเป็นแบบนั้น ผลลัพธ์ที่คาดหวังก็ชัดขึ้น และถ้ามีอะไรผิดไปจากที่คิดก็สังเกตได้เร็วกว่า
    • ทุกครั้งที่ฉันพยายามใส่วิชา ภาษาแอสเซมบลี เข้าไปในหลักสูตรปริญญาตรี มันจะเป็นการต่อสู้ที่หนักเสมอ
      ผู้บริหารมักยกเลิกมันด้วยเหตุผลว่ามันยากเกินไป และเดี๋ยวนี้ไม่มีใครใช้แล้ว
      ถึงอย่างนั้นฉันก็ยังแอบสอดแทรกมันลงไปทีละนิดในวิชาอื่นอย่าง system programming, computer languages หรือ computer architecture
      ตอนฉันโตมา assembly เป็นส่วนหนึ่งของหลักสูตร และทำหน้าที่เชื่อมช่องว่างระหว่างภาษาระดับสูงอย่าง C/C++ กับฮาร์ดแวร์
      มันช่วยให้เข้าใจว่าทำไมฟีเจอร์บางอย่างของภาษาถึงมีอยู่ และองค์ประกอบหลายอย่างของภาษาจริง ๆ แล้วทำงานอย่างไร
      ที่สำคัญที่สุดคืออย่างที่คอมเมนต์ข้างบนบอก มันยอดเยี่ยมมากในฐานะการฝึกให้คิดตาม CPU ทีละบรรทัด
      แม้ฉันจะแพ้เรื่องการผลักดันให้เป็นวิชาเต็มรูปแบบอยู่บ่อยครั้ง แต่อย่างน้อยก็หวังว่าได้หว่านเมล็ดไว้ในตัวนักเรียนบ้าง
      ฉันเชื่อว่าทุกคนควรได้เรียน assembly สักแบบอย่างน้อยสักครั้ง

  • ฉันรู้สึกว่าอยากเห็นการลงทุนกับ AI autocomplete workflow มากกว่านี้
    มันเป็นจุดกึ่งกลางที่ค่อนข้างดี
    สิ่งที่ตอนนี้เรียกว่าแนวทางแบบเก่า ถ้ามองในภาพกว้างก็ยังแข่งขันได้สบายเมื่อเทียบกับ workflow แบบ agentic
    การพิมพ์เองช่วยให้รักษาความรู้เกี่ยวกับ codebase ได้ดีกว่ามาก และกระบวนการที่ต้องนึกเองกับตรวจสอบเองก็ทำให้เข้าใจแนวคิดลึกขึ้นด้วย

    • ช่วงนี้ฉันสนุกกับการ กลับด้าน agent workflow อยู่พอสมควร
      โค้ดฉันเขียนเอง แต่ให้ agent ทำ code review
      แบบนี้ฉันยังรักษาสัญชาตญาณการเขียนโค้ดและความเข้าใจ codebase ไว้ได้ ขณะเดียวกันมันก็ช่วยจับบั๊กก่อน commit ได้ดี
    • ฉันก็รู้สึกเหมือนกันทุกอย่าง
      Cursor ยุคแรกน่าทึ่งมาก แต่หลังจากนั้น autocomplete แทบเหมือนหยุดพัฒนาไปเลย และแม้แต่ Cursor เวอร์ชันล่าสุดก็เริ่มเอียงไปทาง agent มากขึ้นเหมือนเครื่องมืออื่น ๆ
      ฉันหวังว่าถ้า diffusion model เริ่มไปต่อได้จริง workflow แถว ๆ autocomplete อาจกลับมาคึกคักอีกครั้ง
      Mercury model ของ Inception Labs ตอบแทบจะทันทีจนยังให้ความรู้สึกเหมือนเวทมนตร์อยู่
      แค่น่าเสียดายที่ยังขาดความประณีตและการรวมเข้ากับ editor อย่างลึกแบบ Cursor
      อีกอย่างสาย diffusion ก็ดูเหมาะมากกับการใช้งานแบบ local แต่กลับแทบไม่มี open-weight model ที่มีนัยสำคัญเลย ซึ่งก็น่าเสียดาย
    • ประสบการณ์ฉันก็คล้ายกัน
      เวลาฉันเป็นคนเขียน glue code ที่น่าเบื่อเอง มันจะสร้างแผนที่ของโปรเจกต์ไว้ในหัว
      แต่ถ้าปล่อยให้ agent สร้างโครงมากเกินไป ถึงตอนนั้นมันจะรันได้ก็จริง แต่พอผ่านไปหนึ่งสัปดาห์ แค่จะปรับอะไรเล็ก ๆ ก็ต้องเริ่มจากไล่หาก่อนว่ามันเอาอะไรไปไว้ตรงไหน
    • ฉันไม่ค่อยชอบ AI autocomplete เท่าไร
      มันมีเหตุผลที่ทุกคนย้ายไปทางอื่นเร็วขนาดนั้น และสุดท้ายฉันมองว่ามันไม่ใช่ อินเทอร์เฟซที่มีประโยชน์
    • ฉันเข้าใจเหตุผลของการเขียนโค้ดด้วยมือ แต่สำหรับฉันมันให้ความรู้สึกเหมือนขับรถข้ามทวีปแทนที่จะนั่ง เครื่องบิน
      พอได้ขึ้นเครื่องบินแล้ว มันยากมากที่จะยอมกลับไปแบบเดิม

  • ชื่อนี้เป็นหนึ่งใน ชื่อที่หดหู่ที่สุด ที่ฉันเคยเห็นที่นี่

    • น่าสนใจตรงที่คอมเมนต์นี้อ่านได้ตรงกันข้ามเลย
      มันอาจหมายถึงหดหู่เพราะการเขียนโค้ดด้วยมือกลายเป็นเรื่องแปลกใหม่ถึงขั้นเอามาเขียนบล็อกก็ได้ หรืออาจหมายถึงพวก AI maximalist กำลังเหน็บแนมการเขียนโค้ดของมนุษย์ก็ได้
      พอดูประวัติผู้เขียนแล้ว ฉันว่าน่าจะเป็นความหมายแรกมากกว่า
    • ฉันเริ่มสงสัยว่าเดี๋ยวนี้คำว่า เขียน Python เอง จะหมายถึงเขียนโดยไม่ใช้ LLM ไปแล้วหรือเปล่า
      มันให้ความรู้สึกเหมือนคำฮิตสมัยหนึ่งอย่าง wild swimming ราวกับว่าเราไปไกลเกินไปแล้ว
      ดูเหมือนสถานการณ์จะ jumped the shark จริง ๆ
    • เดิมทีฉันคิดว่า Hacker News เป็นที่สำหรับแบ่งปันความคิดและถกเถียงกับคนอื่น แต่พอเห็นปฏิกิริยาแบบนี้แล้วก็รู้สึกเหมือนช่องคอมเมนต์ใน Facebook มากขึ้น
      ถึงอย่างนั้นฉันก็ยังรู้สึกว่านี่เป็นการมีส่วนร่วมที่น่าประทับใจมาก
    • ตอนแรกฉันก็คลิกเข้าไปเพื่อเช็กว่าเป็นมุกหรือเปล่า
      พออ่านแล้วก็ เหลือเชื่อจริง ๆ
    • ฉันรู้สึกว่านี่เพิ่งเริ่มต้นเท่านั้น
      อีกหน่อยก็ชักจะนึกภาพโลกที่คนถูกส่งเข้าโรงพยาบาลจิตเวชเพียงเพราะพูดถึง การเขียนโค้ดด้วยมือ แบบขำไม่ออกได้เลย

  • ช่วงหลายปีแรกของอาชีพฉันหมดไปกับการเขียนโค้ด Perl บน Solaris ที่ใช้ SPARC ผ่าน vi และเป็น vi ไม่ใช่แม้แต่ vim
    O’Reilly Perl Cookbook แทบจะเป็นคู่มือเดียว อินเทอร์เน็ตฟอรั่มก็ยังไม่ค่อยมี และ search engine ก็ยังดิบมาก เวลาเจอทางตันจึงหาความช่วยเหลือยากกว่ามาก
    แต่สภาพแวดล้อมนั้นเองทำให้ฉันซึมซับ syntax ของ Perl, เครื่องมือในเทอร์มินัล และโดยเฉพาะ คีย์สโตรกของ vi ได้ลึกมาก
    ไม่มี syntax highlighting หรือ IntelliSense อะไรทั้งนั้น และเพราะแบบนั้นมันถึงยิ่งติดตัวกว่า
    มองย้อนกลับไป ตอนนั้นสิ่งรบกวนและ noise มีน้อยกว่ามาก
    แน่นอนว่าอาจเป็นเพราะตอนนั้นฉันยังอยู่ต้นอาชีพ ผู้คนจึงคาดหวังจากฉันไม่มาก แต่ตอนนี้ฉันรู้สึกว่าทุกอย่างถูกซ้อนทับเป็นชั้น ๆ และซับซ้อนเกินไปแล้ว

    • ของฉันเริ่มจาก GW-BASIC และแทบไม่มี editor ในความหมายแบบทุกวันนี้เลย
      มันเป็นประสบการณ์ที่ค่อนข้างบริสุทธิ์ มี รางวัลตอบแทนทันที พัฒนาได้เร็ว และไม่มีเลเยอร์ที่ไม่จำเป็น ซึ่งนั่นแหละคือสิ่งที่ดึงฉันเข้ามาในสายนี้
      ที่น่าขำคือ agentic coding กลับทำให้ฉันได้ความตื่นเต้นแบบนั้นกลับมาบางส่วน
      เพราะฉันไม่ต้องไปปล้ำกับรายละเอียดซับซ้อนระดับ enterprise ทั้งหมดด้วยตัวเอง ทำให้ความเชื่อมโยงระหว่างความคิดกับผลลัพธ์กลับมาใกล้กันอีกครั้ง

  • การเปลี่ยนแปลงของวงการนี่น่าทึ่งจริง ๆ
    แค่เมื่อ 2 ปีก่อน นี่แทบเป็นสิ่งที่นักพัฒนาทุกคนคงพูดกัน แต่ตอนนี้คนที่พูดว่า ตัวเองเขียนโค้ดด้วยมือ กลับดูเหมือนสิ่งมีชีวิตใกล้สูญพันธุ์

    • ฉันกังวลเรื่อง muscle memory หายไปเป็นพิเศษ
      ยิ่งเป็นเทคโนโลยีและภาษาที่ฉันใช้ในปีที่ผ่านมา ฉันยิ่งรู้สึกว่าการได้ผลลัพธ์ง่ายเกินไปกำลังสร้างหนี้ความรู้ไว้ในตัวเอง
      ฉันกังวลมากว่าซอฟต์แวร์เอนจิเนียร์รุ่นต่อไปจะเรียนรู้ความเข้าใจเชิงลึกต่อสิ่งพวกนี้ได้อย่างไร หรืออาจจะเรียนรู้ไม่ได้เลย
    • สำหรับฉัน การเขียนด้วยมือ เมื่อ 2 ปีก่อน ให้ความรู้สึกเหมือนการเขียนโค้ดตอนนี้โดยไม่มี LLM
      ถ้าเทียบกับรุ่นก่อนหน้านั้นก็คงคล้ายการเขียนโค้ดโดยไม่มี IDE ซึ่งในความเป็นจริงก็กลายเป็นเรื่องที่พบได้น้อยไปแล้วเหมือนกัน

  • ฉันสนับสนุน AI โดยรวม โดยเฉพาะ GenAI ค่อนข้างมาก แต่ก็ยังใช้เวลาเขียนโค้ดด้วยมือต่อไปเยอะอยู่
    มากสุดก็แค่เปิด Copilot ช่วย ไว้
    บางทีก็ใช้เครื่องมืออย่าง SpecKit + OpenCode ทำ spec-driven development หรือไม่ก็ vibe code ไปเลย
    ถึงอย่างนั้นฉันก็ยังไม่คิดจะละทิ้งความรับผิดชอบในการเข้าใจโค้ด และยังไม่คิดจะทิ้งความสามารถในการเขียนมันด้วยตัวเอง
    เพราะงั้นช่วงนี้ฉันก็ยังซื้อหนังสือ LISP กับ Java มาใหม่หลายเล่ม ก่อนหน้านั้นก็ซื้อหนังสือ Forth ด้วย
    อย่างน้อยในช่วงหนึ่ง หรืออาจตลอดไป ฉันคงยังไม่คิดจะเลิกเขียนโค้ดโดยสิ้นเชิง

    • สำหรับฉัน ความรับผิดชอบไม่ได้อยู่ที่การตรวจดูโค้ดทีละบรรทัดด้วยตัวเอง แต่อยู่ที่การรับประกันว่าโค้ดนั้นตอบ ข้อกำหนดเชิงหน้าที่และข้อกำหนดที่ไม่ใช่เชิงหน้าที่ ได้
      แก่นสำคัญไม่ใช่ตัว implementation แต่คือ ความเข้าใจพฤติกรรม
      การตรวจสอบนั้นทำได้ด้วย unit test, integration test และ load test แบบอัตโนมัติ
      มีคนมองว่าฉันไร้เดียงสาที่บอกว่าตัวเองทำเว็บแอดมินภายในด้วย vibe coding โดยแทบไม่ดูโค้ดเลย แต่ยังมั่นใจว่ามันผ่านข้อกำหนดด้านความปลอดภัย
      แต่ข้อกำหนดคือคนที่มีสิทธิ์เข้าเว็บไซต์ต้องสามารถทำอะไรก็ได้อยู่แล้ว และการเข้าถึงถูกป้องกันด้วย credential ของ Amazon Cognito ขณะที่ Lambda ที่ให้บริการสิ่งนี้ก็ถูกกำหนด role แบบ least privilege
      ถ้าสอง invariant นี้พังลงจริง ฉันก็มองว่านั่นคงเท่ากับ Claude ไปค้นพบช่องโหว่ AWS ขนาดใหญ่เข้าแล้ว

  • ฉันใช้ AI ให้เต็มที่เพื่อสร้างของให้ได้มาก แต่ในขณะเดียวกันก็ต้องใช้เวลาตรวจดูด้วยว่าโค้ดที่ AI สร้างผ่าน เกณฑ์ภาระการรับรู้ ของฉันหรือไม่
    กระบวนการนั้นรวมถึงการเกลาโค้ดและทำเอกสารด้วย และฉันก็อาศัย ตัวอย่าง AGENTS.md นี้ เพื่อช่วยให้หลายอย่างง่ายขึ้นมาก
    ถึงอย่างนั้นฉันก็ยังจับได้ว่าเมื่อไรมันเริ่มออกทะเล แล้วตอนนั้นฉันจะกลับมาจับพวงมาลัยเอง
    และพอเครดิตหมด นั่นแหละถึงเวลาเข้ากะของฉันจริง ๆ
    ตอนนั้นโค้ดก็ถูกจัดระเบียบมาอย่างดี abstraction ก็สมเหตุสมผล คอมเมนต์ก็ช่วยได้ ทำให้ต่อยอด การเขียนโค้ดแบบมนุษย์อย่างเป็นธรรมชาติ ได้ง่าย
    ตอนนี้ยิ่งใกล้ชนลิมิต ฉันก็ยิ่งขอให้ AI ช่วยจัดเวทีไว้ล่วงหน้า
    เมื่อก่อนพอเครดิตหมด มันมักทิ้งโค้ดที่ฉันต้องไปนั่งศึกษาเองก่อนถึงจะเข้าใจ ซึ่งน่าหงุดหงิดมาก แต่ตอนนี้ฉันกลับเริ่มตั้งตารอ brain time hand-out ครั้งถัดไป
    ฟังดูอาจแปลก แต่สำหรับฉันนี่ก็เป็น teamwork อีกรูปแบบหนึ่ง
    ฉันอาจจ่ายแพ็กเกจที่แพงกว่านี้ก็ได้ แต่ฉันอยากให้สมองตัวเองยังได้ทำงานต่อ

    • หลักการที่ยกมานั้นมีข้อหนึ่งที่น่าสนใจคือ อย่าใช้ DRY มากเกินไป
      ฉันเห็นด้วยกับหลักการนี้ แต่ดูเหมือนอย่างน้อย Claude จะชอบก็อปปี้ logic บ่อยเกินไปอยู่แล้ว จนบางทีต้องชี้นำไปอีกทางแทน
    • ฉันรู้สึกยากที่จะเรียกสิ่งนั้นว่า teamwork
      เวลา LLM เขียนโค้ดแทนฉัน โค้ดนั้นดูเหมือนกล่องดำที่แทบแตะต้องไม่ได้
      ถ้ามันรันได้ฉันก็ใช้ แต่ไม่ได้ไว้ใจ และถ้ามันพังก็มีแต่หงุดหงิด
      สุดท้ายวิธีที่เหมาะกับฉันคือฉันต้องจับพวงมาลัยเองตลอด โดยให้ LLM เป็นผู้ช่วยคอยตอบคำถาม ช่วย brainstorm ไอเดีย และช่วยแปลงแนวคิดที่ฉันเข้าใจแล้วให้ออกมาเป็น syntax ของภาษานั้น
      เอาจริง ๆ ฉันมักลำบากกับ การถ่ายทอดเป็น syntax มากกว่าการเข้าใจแนวคิดเสียอีก
    • ขอบคุณที่แชร์
      ฉันเองก็กำลังคิดอยู่เหมือนกันเรื่องการมอบบางส่วนให้ agent แต่ตั้งใจเก็บงานบางอย่างไว้ทำเองเพื่อให้สมองยังได้ใช้งาน
      บางทีฉันน่าจะลองทำ skill หรือ hook สำหรับ Claude Code ดู

  • การได้ใช้เวลา 3 เดือนกับเส้นทางการเรียนรู้แบบขับเคลื่อนตัวเองอย่างลึกซึ้ง ฟังดูยอดเยี่ยมจริง ๆ
    ทักษะเชิงลึก แบบนี้น่าจะมีคุณค่าในระยะยาว และฉันยังไม่แน่ใจว่าการเปลี่ยนแปลงครั้งนี้เป็น abstraction ประเภทเดียวกับตอนย้ายจาก assembly ไป C แบบตรงตัวหรือไม่
    ทุกวันนี้โค้ดส่วนใหญ่ของฉันสร้างโดย LLM แต่พอจบวันแล้ว ฉันพูดตามตรงว่าแทบไม่รู้สึกสนุก ภูมิใจ หรือพึงพอใจเท่าไร
    แต่ในขณะเดียวกันมันก็ทำให้ฉันตระหนักว่า ส่วนที่ฉันสนุกกับการเขียนโค้ดจริง ๆ มีแค่ราว 5-10% เท่านั้น ที่เหลือเป็นงานน่าเบื่อกึ่งจักรกลซึ่งคอยค้ำส่วนแก่นที่น่าสนใจเอาไว้
    ถ้ามองทั้งประวัติศาสตร์มนุษย์ ช่วงเวลาที่เราทำงานด้วยคอมพิวเตอร์มันสั้นนิดเดียว และฉันก็สงสัยว่าอีก 100 ปีข้างหน้า ยุคของการเขียนโค้ดด้วยมือ จะถูกมองอย่างไร
    บางทีมันอาจเหลือแค่เชิงอรรถ หรือไม่ก็ถูกรวมเรียกเป็นยุคก่อนที่เครื่องจักรจะ automate ตัวเองได้ทั้งหมด

    • ฉันคิดว่าการเปลี่ยนแปลงตอนนี้อาจคล้ายกับ การเปลี่ยนจาก assembly ไปสู่ภาษาคอมไพล์ ในอดีต
      เมื่อก่อนเราต้องเขียน assembly เอง แต่หลังจากนั้นก็ย้ายไปใช้ภาษาคอมไพล์อย่าง C และ assembly ก็ยังมีประโยชน์แต่กลายเป็นทักษะเฉพาะทาง
      ตอนนี้ก็คล้ายกัน เราปล่อยให้ compiler ดูแลโค้ดและแทบไม่เคยไปดู output ภายในของมัน ดังนั้นต่อไปนักพัฒนาส่วนใหญ่ก็อาจย้ายขึ้นไปอยู่บน abstraction layer ของ LLM
      ทักษะหลักอาจย้ายไปอยู่ที่การเขียนพรอมป์ต์ที่ดี การจัดการ context window และการดูแล agent กับ memory
      นักพัฒนาบางคนอาจยังอ่านโค้ดที่ LLM สร้างแล้วจับปัญหาได้ แต่คนส่วนใหญ่อาจทำไม่ได้
      ฉันเองก็รู้สึกปะปนกันไป
      ตั้งแต่ ChatGPT ออกมาจนถึงไม่กี่เดือนก่อน ฉันยังค่อนข้างสงสัยเรื่องการเขียนโปรแกรมด้วย LLM อยู่มาก และต่อให้มีโมเดลใหม่ออกมา มันก็ดูเหมือนเป็นเพียงความแปรผันของผลลัพธ์คุณภาพต่ำแบบเดิม
      แต่ช่วงหลัง ๆ มานี้ โมเดลดูเหมือนจะข้าม จุดวิกฤต บางอย่างไปแล้ว และแม้ฉันจะยังใช้ Claude อย่างระมัดระวัง มันก็ช่วยฉันได้จริงทั้งในเรื่องทำฟีเจอร์ให้เร็วขึ้นมาก และช่วยหาตำแหน่งบั๊กจากการดู log อย่างเดียว
      ฉันยังไม่เห็นด้วยกับคำโอ้อวดทำนองว่า การเขียนโค้ดถูกแก้ปัญหาแล้ว แต่ก็คิดว่าอย่างน้อยเรากำลังเห็นหนึ่งในการเปลี่ยนแปลงครั้งใหญ่ที่สุดนับตั้งแต่การมาของภาษาระดับสูง

  • ฉันเริ่มใช้ Zed เป็นทางสายกลางแบบหนึ่ง
    ต่อไปฉันตั้งใจจะใช้ AI กับงานด้าน การวางแผนและการเสนอขั้นตอน มากกว่าตัว implementation
    ช่วงนี้แม้แต่คนสายงานที่ไม่ใช่เทคนิคก็เริ่มสร้างแอปด้วย Claude กันแล้ว และพอมองดูทั้ง Openclaw กับกระแสหมกมุ่นกับ agent ทั้งหลาย ฉันรู้สึกว่าการเดินหน้าบ้าคลั่งกับ AI ต่อไปไม่ใช่เรื่อง practical นัก
    ในด้านอื่นของชีวิต ฉันเป็นคนที่ใส่ใจถึงรายละเอียดภายในเสมอ และถูกประเมินค่าจากความสามารถในการลงมือแก้ปัญหาใหม่ ๆ ด้วยตัวเอง
    ฉันเลยสงสัยว่าตลาดจะปรับตัวยังไงต่อ และผู้คนจะถ่ายทอดหรือพิสูจน์ความสามารถในการจัดการ ความละเอียดอ่อนพวกนี้ กันอย่างไร

  • ตอนเห็นข้อความในเว็บไซต์ Recurse Center ที่ว่า “ไม่มีครู ไม่มีหลักสูตรตายตัว และสิ่งเดียวที่ต้องการคือการทุ่มเทเต็มเวลาในช่วง retreat” ฉันก็สงสัยขึ้นมา
    ฉันอยากรู้ว่าคนที่ทำงานเต็มเวลาปกติเข้าไปร่วม coding retreat แบบนี้กันอย่างไร
    แล้วมันเป็นโปรแกรมที่ออกแบบมาสำหรับคนเพิ่งเข้าวงการหรือคนที่กำลังอยู่ระหว่างเปลี่ยนงานเป็นหลักหรือเปล่า
    ตัวบทความจริง ๆ พูดถึงสิ่งที่ผู้เขียนสร้างใน retreat แต่กลับทำให้ฉันอยากไปลองด้วยตัวเองมากกว่า

    • ฉันขอตอบในฐานะผู้ร่วมก่อตั้ง Recurse Center ว่า คนส่วนใหญ่เข้าร่วมในช่วง เว้นว่างระหว่างงาน
      หลายคนลาออกเพื่อมา RC โดยเฉพาะ หรือสมัครหลังตกงาน
      บางคนใช้ช่วง sabbatical อย่างเป็นทางการ, garden leave หรือช่วงปิดเทอมฤดูร้อนของนักศึกษามหาวิทยาลัยและบัณฑิตศึกษา
      ฟรีแลนซ์ ผู้รับจ้างอิสระ และผู้เกษียณก็มีมาไม่น้อย
      มีบางคนมาที่นี่เพื่อเข้าวงการ แต่ผู้เข้าร่วมส่วนใหญ่เคยทำงานเป็นโปรแกรมเมอร์มาแล้ว
      อายุผู้เข้าร่วมมีตั้งแต่ 12 ปีจนถึงช่วงต้นวัย 70 แต่ช่วงหลัก ๆ จะอยู่ระหว่างวัย 20 ถึง 40
    • ใช่ โดยมากคนจะไปกันช่วง ระหว่างย้ายงาน
      ดูข้อมูลผู้เข้าร่วมเพิ่มเติมได้ที่ หน้าแนะนำ Recurse Center
      ไม่อย่างนั้นก็ต้องอยู่ในสถานการณ์ที่สามารถลางานแบบ sabbatical ราว 6 สัปดาห์แล้วกลับไปทำงานเดิมได้จึงจะสมจริง