ทุก Context มีน้ำหนัก: AI, Mobile Builds และ SSD 512 GB

บันทึก 001 ของอนรรฆ: 19 ตุลาคม 2026

สวัสดีครับทุกคน ยินดีต้อนรับกับบ้านใหม่ของผมที่เพิ่ง deploy เสร็จสดๆร้อนเมื่อไม่กี่วันก่อน ผมเลยขอยกบทความนี้ให้เป็นโพสต์แรก 001 เลยละกัน ขอหนี Medium กับ Dev dot to มาทำที่สิงสถิตให้กับตัวเองสักที จะได้มีที่ให้ได้จดๆได้เต็มที่ ทั้งที่มีสาระและไม่มีสาระ ฮ่าๆ

มาเข้าเรื่องเลยละกัน ช่วงหลังๆอย่างที่ทุกคนพอจะรู้กัน AI เข้ามาช่วยเราลงมือทำงานได้หลายส่วนมากๆ สำหรับผมเองนั้น ผลที่เห็นได้ชัดอย่างหนึ่งก็คือการเริ่มงานใหม่แบบที่มีแรงเสียดทานน้อยลง ไม่รู้ผมใช้คำถูกไหมนะ ที่เรียกมันว่า “แรงเสียดทาน” แต่ผมจะเรียกแบบนี้… ใครจะทำไม (หยอกๆคร้าบ)

ผมยกตัวอย่างแบบนี้ละกัน นึกภาพระหว่างที่กำลังปั่น ticket feature อะไรสักอย่างบน iOS ผมสามารถส่งอีก ticket ให้ agent ช่วยทำ, แยก worktree, ปั่น feature ฝั่ง Android ได้อีกโดยไม่ต้องหยุดงานแรกเพื่อสลับ branch ไปมา ไหนจะงานอื่นๆอีก เยอะแยะอย่างกะแยกร่างได้

เมื่อก่อนถ้าจะเริ่มหยิบงานใหม่ ผมมักต้องคิดก่อนว่าจะพักงานที่ทำอยู่ตรงไหน เก็บสถานะไว้อย่างไร แล้วค่อยย้ายความสนใจไปอีกเรื่อง อย่างมากก็อาจ 1-2 เรื่องพร้อมกัน แต่พอมี agent ช่วยทำบางส่วน งานอีกชิ้นก็เดินต่อได้ระหว่างที่ผมยุ่งๆหรือดูงานเดิมอยู่ การมี AI มาช่วยทำงานจึงเปลี่ยนจังหวะการเริ่มงานของผม คือมันไม่จำเป็นต้องรอให้งานตรงหน้าจบก่อนทุกครั้ง ผมสามารถเปิด 3-4-5 งานพร้อมๆกันได้เลย

แต่การเริ่มงานได้ง่ายและที่ผมเรียกว่าแรงเสียดทานน้อยแบบนี้เนี่ย ไม่ได้แปลว่างานเดิมหายไป งานหนึ่งอาจกำลังรอ test อีกงานรอ review และอีกงานรอ agent ทำต่อ หรืออีกงานก็ยังรอเราตัดสินใจอะไรบางอย่างอยู่ ผมยังต้องจำว่าแต่ละงานค้างอยู่ตรงไหนและสมองก็ยังต้องจำอยู่, เครื่องก็ยังเปิด context, worktree หรือ build state บลาๆที่เกี่ยวข้องไว้

ผมไม่ได้จะบอกว่า AI บังคับให้ทุกคนต้องทำงานแบบนี้นะ เพราะผมเองก็ไม่ได้อยากบอกว่าที่ถูกที่ควรจริงๆมันควรเป็นยังไง ผมแค่รู้สึกว่ามันเป็นสิ่งที่เริ่มเกิดกับ workflow การทำงานของผมเอง เมื่อเริ่มงานใหม่ได้ง่ายขึ้น ผมก็เริ่มถามตัวเองว่า ผมกำลังสลับ context ได้ดีขึ้น AI กำลังพาผมฝึก context switching แบบเนียนๆเหรอ? สมองน้อยๆของผมไหวแน่นะ? หรือผมกำลังสะสมงานที่ยังไม่ได้ปิดไว้มากขึ้น.. แต่ผมก็ปิดไปได้หลายงานอยู่นี่นา?

ชน limit?

ชน limit คืออะไร? ผมไม่รู้จักเรียกมันยังไงเหมือนกัน แต่มองว่ามันคงประมาณนี้ งานในแต่ละวันของผมมัน everything jingle bell สุดๆ แบบทำ feature, แก้ bug, เขียน automation test, ทำ tool บลาๆ ละพอ 80% มันเป็นงานที่ผมต้องใช้ simulator หลายๆตัว มันเลยยิ่งต้องใช้ทรัพยากรของเครื่องเยอะขึ้น แต่ก่อนเอาจริงๆผมก็ไม่ค่อยเจอหรอก ไอ้คำว่าชน limit แบบ hdd เต็ม, เครื่องอืดอะไรแบบนี้ แต่พอมี AI เข้ามาแบบที่ผมเล่าตอนต้น มันก็เหมือนคนอยากลองของอะ เปิดไปดิ terminal 8-9 tabs ซัดเข้าไป ทำนู่น ทำนี่ สลับหัวไปมาฉ่ำๆ

มานึกๆดูผมนี่ก็ด้วยตัวดีเลย บางทีก็อยากลองว่าตัวเองนี่ context switching ได้แค่ไหน จนมาวันนึงมันวิ่งมาชนขอบนี่แหละ

แล้ว limit ที่ผมบอกมันคืออะไรบ้างหละ ผมคงแยกแบบขี้เกียจๆเป็น 2 อันก่อน อันแรกก็คือเรื่อง resource แบบเจ้า hdd สุดที่รักของผม มันฟ้องว่ากรูจะตายละคร้าบ แน่นเอี๊ยดสุดๆ จะ build หรือทำงานอะไรต่อไม่ได้แล้ว ถ้าไม่ clear space อะไรให้หน่อย มันก็ไปต่อไม่ได้ แรกๆเอาจริงผมก็แอบเซ็งๆนะ จะทำงานต้องมาคอยเคลียร์ที่ เคลียร์โต๊ะ แบบเรากำลังทำงานไหลๆ แต่ hdd เต็มละ build ของไม่ได้

แต่ผมมาลองนึกดูดีๆ แบบไม่มีดราม่าเข้าแทรก ผมก็พบว่า อ่าโอเค limit ตรงที่ผมบอกมันไม่ได้มีแค่ resource ของเครื่องหรอก มันมีเรื่องของ energy ที่ถือเป็นอันที่ 2 ที่ผมต้องคอย switch สมองน้อยๆของผมไปมาระหว่างงานแต่ละงานด้วย ถ้าจะลงรายละเอียดเรื่องพลังงานสมองก็คงวัดยากหน่อย ไว้หาเวลามาเขียนอีกทีละกัน

ผมเลยคิดว่าเราต้องมาคลายข้อสงสัยที่บอกว่า hdd มันชอบเต็มเนี่ย มันเต็มเพราะอะไรกันนะ? ผมเองก็ไม่ได้เก็บไฟล์อะไรมั่วซั่วไว้ในเครื่องสักหน่อย งานที่ทำอยู่ทุกวันก็เป็น mobile app ทั้ง iOS และ Android ซึ่งต้อง build ต้องรัน test แล้วก็เปิด simulator วนไปมา ของพวกนี้มันสร้างไฟล์อะไรทิ้งไว้บ้าง แล้วมันสะสมกันตรงไหน?

สาระจะเริ่มจากตรงนี้… จิบเบียร์ละไปกันต่อ

Mobile build เก็บอะไรไว้บ้าง

ถ้าอยากรู้เราก็ต้องไปหาข้อมูลมาใช่ไหมหละ คือว่าพื้นที่ hdd สุดที่เลิฟมันไม่ได้หายไปกับ source code อย่างเดียวหรอก งาน mobile เวลา build เนี่ย มันสร้างข้อมูลที่เอาไว้ประกอบร่างให้แอพของเราหลายชนิดมาก บางส่วนช่วยให้ build รอบถัดไปเร็วขึ้น บางส่วนใช้กับการทดสอบหรือ simulator และบางส่วนเป็นผลลัพธ์ที่อาจยังอยู่หลังจากที่เราหยุดสนใจงานนั้นไปแล้ว

ฝั่ง Xcode มี build products และ intermediate files ที่ build system สร้างตาม targets และ settings ของโปรเจกต์ นอกจากนี้ยังมี index data, test results, logs, .xcresult และข้อมูลของ simulator ส่วน DerivedData ที่เอะอะเราก็บอกไปลบตรงนี้สิ เป็นตำแหน่งหนึ่งที่เกี่ยวข้องกับข้อมูลจากการ build และ index แต่รายละเอียดและขนาดจริงขึ้นกับการตั้งค่าและ workflow ของเครื่อง

ฝั่ง Android หละ เป็นยังไง, Gradle เก็บข้อมูลไว้ทั้งใน Gradle User Home เช่น dependencies และ caches และใน project root เช่น .gradle/ กับ build/ ซึ่งอาจมีข้อมูลชั่วคราวและ artifacts ของ project ส่วน Android SDK, emulator system images และข้อมูล emulator ก็อยู่นอกเหนือจาก project build outputs และอาจใช้พื้นที่เพิ่มได้

นึกถึงตอนเราทำงาน ทั้ง iOS/Android ตัวแอพเรามีหลาย targets, modules, configurations และ test destinations ละแต่ละชุดมันอาจสร้าง outputs และ test data ของตัวเอง cache บางชนิดใช้ร่วมกันได้ บางชนิดผูกกับ project หรือ build configuration ขนาดที่เห็นบนดิสก์จึงไม่ได้เท่ากับขนาด source code และไม่ได้เพิ่มขึ้นแบบคูณตรง ๆ ตามจำนวน worktree เสมอไป ต้องดู path ที่ build tool ใช้จริงด้วย

ถ้าจะไล่หาว่าพื้นที่มันหายไปอยู่ตรงไหน เรามาส่องจากดูขนาด directory หลักก่อน

# พื้นที่ว่างของ volume ที่เก็บ home directory
df -h ~

# Xcode build data และข้อมูล simulator
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator 2>/dev/null

# Gradle global caches/configuration
du -sh ~/.gradle 2>/dev/null

# project-local Gradle data (รันจาก root ของ repo)
du -sh .gradle build 2>/dev/null

# build directories ของ subprojects (รันจาก root ของ repo)
find . -type d -name build -prune -exec du -sh {} + 2>/dev/null

คำสั่งที่ผมแปะไว้ ตัว du -sh จะให้ขนาดรวมของ directory ที่ระบุ ส่วน df -h แสดงความจุและพื้นที่ว่างของ filesystem ที่ path นั้นอยู่ ขนาดที่วัดได้เป็น snapshot ณ ตอนนั้น และอาจรวมของที่ใช้ร่วมกันหรือข้อมูลซึ่งสร้างใหม่ได้ ละมันก็ไม่ได้บอกว่าอะไรบ้าง ไฟล์ไหนบ้างปลอดภัยที่จะลบ

ตัวเลขในเนื้อหาต่อจากนี้ผมขอเรียกเป็น GB นะ จะได้อ่านง่ายๆ ส่วนภาพเก็บหน่วยตามที่คำสั่งแสดง (du -h ใช้ G, df -h ใช้ Gi) ซึ่งเป็นการแสดงขนาดแบบฐาน 1024 จึงถือเป็นค่าประมาณเมื่อเขียนเป็น GB

ก่อนเทียบตัวเลข ควรจดวันวัดและ volume ด้วยนะ อย่าเผลอไปเอาขนาด directory ที่ซ้อนกันมาบวกซ้ำ เช่น นับทั้ง repo root แล้วบวก build/ ข้างในอีกครั้งโต้งๆไม่ได้ ส่วนตำแหน่งจริงของ Xcode Derived Data หรือ build output อาจถูกเปลี่ยนจากค่าเริ่มต้นได้ อันนี้ก็ให้ดูดีๆก่อน ว่าเราตั้งค่าใน project ไว้ยังไงก่อนสรุป

เดี๋ยวตัวอย่างใน part ต่อไป ผมขอยกตัวอย่างที่ผมจัดการไปแค่บางส่วนฝั่ง iOS อย่างเดียวก่อนนะครับ

ไปส่อง Simulator มา เอ้า 91 GB!

ทีนี้ผมก็ไปลองไล่ดูจากเครื่องที่เจอปัญหาจริง ภาพแรกของผมพอลอง enter command แรกเท่านั้นแหละ โอ้ ชิทท เล่นเอาตกใจเหมือนกัน: ~/Library/Developer/CoreSimulator อันเดียวกินที่ไปประมาณ 91 GB บ้าแล้ววว พอแยกดูข้างในก็เจอว่า Devices นั่นเองที่กินไปประมาณ 91 GB ส่วน Caches กับ Temp ในเครื่องนี้ขึ้น 0 B

0B    .../CoreSimulator/Caches
0B    .../CoreSimulator/Temp
91G   .../CoreSimulator/Devices

ผมไล่ดู device directories ที่ใหญ่สุด แล้วเอา UDID ไปเทียบกับ xcrun simctl list devices unavailable ถึงเห็นว่าบางก้อนเป็น simulator ที่ unavailable แล้ว เพราะหา runtime profile ไม่เจอ:

ผมเช็กรายการ unavailable ทั้งหมดก่อนว่ามีเครื่องไหนที่ยังต้องเก็บไว้ไหม ตารางข้างบนเป็นแค่ตัวอย่างจากเครื่องที่กินพื้นที่เยอะ พอตัดสินใจแล้วผมก็ใช้คำสั่งนี้ลบ simulator ทุกตัวที่ simctl จัดว่า unavailable (ใช้คำว่าลองลบได้ไหมนะ เพราะมันลบจริง 555+):

xcrun simctl delete unavailable

ผมแคปภาพก่อน cleanup มาให้ดู จะเห็น Devices ใช้ประมาณ 91 GB ส่วน df -h ~ รายงานพื้นที่ว่างประมาณ 5.8 GB:

ผล du ก่อน cleanup: CoreSimulator/Devices ใช้ประมาณ 91 GB

ผล df -h ~ ก่อน cleanup: เนื้อที่เหลือประมาณ 5.8 GB

ยัง ยังไม่จบ ก้อนใหญ่ที่เหลือผมเอา UDID ไปค้นในรายการ simulator ต่อ แล้วเจอว่าเป็นเครื่องที่ยังใช้งานได้คือ iPhone 16 ใช้ไปประมาณ 24 GB, iPhone 17 Pro 15 GB, iPhone Duo 4.7 GB และ iPad Pro 13-inch (M5) 2.8 GB เลยไม่ใช่ของที่ผมจะลบทิ้งไปเลย เพราะก็ยังใช้ทำงานอยู่

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

xcrun simctl erase C2086598-35B4-403B-BB71-68FBE2D984F9
xcrun simctl erase FF0FAD20-7845-4B49-A918-B8FC6DE4E32B

หลัง cleanup ผมวัดอีกครั้ง CoreSimulator/Devices เหลือประมาณ 9.9 GB และ df -h ~ ก็บอกว่าเรามีพื้นที่ว่างประมาณ 78 GB!! เยสสส น้องกลับมาแล้ววววว

ผล du หลัง cleanup: CoreSimulator/Devices เหลือประมาณ 9.9 GB

ผล df -h ~ หลัง cleanup: พื้นที่ว่างประมาณ 78 GB

สองชุดนี้เป็นค่าจากคนละคำสั่ง: du วัดขนาด directory ส่วน df วัดพื้นที่ว่างทั้ง filesystem เลยขอเล่าตัวเลขตามที่เห็นในแต่ละภาพ ไม่เอามาลบกันเป็นยอดพื้นที่คืนก้อนเดียว

เคสนี้ทำให้ผมเห็นว่า 91 GB ในเครื่องนี้ไม่ได้มาจากก้อน cache ตามที่ผมเดาไว้ตอนแรก แต่หลัก ๆ อยู่ในข้อมูลของ simulator แต่ละเครื่องและการดู UDID คู่กับสถานะใน simctl ช่วยแยกได้ว่าก้อนไหนเป็น sim ที่ใช้ไม่ได้แล้ว กับก้อนไหนยังควรเก็บไว้

แล้ว Worktree หละ มันเพิ่มพื้นที่ตรงไหนไหม?

Git worktree อันนี้ผมว่าของดี คือมันช่วยให้เรา checkout หลาย branch เป็น working directory แยกกันได้ โดยไม่ต้องสลับ branch ใน directory เดียว ข้อมูล repository บางส่วน เช่น object database และ refs ส่วนใหญ่ใช้ร่วมกัน ขณะที่ index และ HEAD แยกตาม worktree

แต่ของดีที่ผมบอก มันก็มีส่วนเกี่ยวข้องกับ build data ที่ผมเกริ่นๆไปเพราะมันเป็นอีกเรื่องหนึ่ง คือ build data มันอาจแยกตาม worktree หาก build directory หรือการตั้งค่าของเครื่องมือชี้ไปคนละ path และมันไม่ได้หมายความว่าทุก setup จะสร้างข้อมูลซ้ำทั้งหมด บาง cache อาจอยู่ในตำแหน่งส่วนกลางและใช้งานร่วมกันได้ ขึ้นกับ path, build settings และการตั้งค่า cache ของโปรเจกต์

ภาพตัวอย่างของกรณีที่แต่ละ worktree มี build data แยก:

worktree A
├── source
├── DerivedData หรือ .gradle
├── build outputs
└── test state

worktree B
├── source อีกชุด
├── build outputs อีกชุด
└── test state อีกชุด

และอีกหลายๆชุด 555

การแยก build data อาจช่วยให้งานขนานไม่รบกวนกัน อันนี้คือข้อดีที่ผมบอก แต่ก็นั่นแหละ เพราะแบบนั้นมันก็เลยจะใช้พื้นที่เพิ่มแน่ๆ ส่วนการแชร์ cache อาจลดงานซ้ำได้ แต่ต้องเข้าใจ path, invalidation และพฤติกรรมเมื่อหลายงานอ่านหรือเขียนพร้อมกัน

อีกอย่างที่ผมคิดว่าผมควรไปศึกษาเพิ่มคือการ cleanup เจ้า worktree เนี่ยแหละ คือการเอา worktree ออกจาก Git ไม่ได้แปลว่า cache หรือ artifacts ที่อยู่นอก directory ของ worktree มันจะถูกลบตามไปด้วย มันควรตรวจตำแหน่งจริงๆก่อนสรุปว่าพื้นที่ถูกคืนแล้ว

แล้วเราจะรอให้มันเต็มตอน build ทำไมหละ?

คือพอเรารู้การทำงานคร่าวๆ ผมก็มานึกออกว่า เห้ย ผมใช้ PreToolUse hook ใน Claude มาช่วยก็ได้นี่นา ก็เลยได้ไอเดียว่าให้มันตรวจคำสั่งก่อนให้ tool รัน ตัวที่ผมทำมันจะคอยดูว่าถ้าเป็นคำสั่ง build iOS หรือ Android ก็ให้เช็กพื้นที่ว่างก่อน ถ้าต่ำกว่า 10 GB ไม่ต้องสั่ง build และส่ง notification มาบน macOS แทน ถ้าผ่านเกณฑ์ก็ปล่อยให้คำสั่งทำงานตามปกติ

กำลังจะเรียก build tool
        │
        ├── ไม่ใช่คำสั่งที่ hook ดูแล → ปล่อยผ่าน
        │
        └── เป็นคำสั่ง build iOS/Android
                 │
                 ├── พื้นที่ว่าง < 10 GB → block + แจ้งเตือน
                 └── พื้นที่ว่าง ≥ 10 GB → ให้ทำงานต่อ

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

เจ้า hook ตัวนี้เลยช่วยไม่ให้ผมเสียเวลารอ build ที่มีโอกาสไปต่อไม่ได้ แล้วค่อยกลับมาเคลียร์พื้นที่และเริ่มใหม่อีกครั้ง ซึ่ง 10 GB ที่ผมตั้งเป็น threshold ไว้กับ workflow ของตัวเอง มันไม่ใช่ตัวเลขแนะนำสำหรับทุกเครื่องหรือทุก project นะ เป็นค่าที่ผมจูนๆมาจากการส่องๆ build แต่ละครั้งมากกว่า

แล้ว SSD 1 TB จะช่วยไหมหละเพื่อน?

ช่วยแน่นอนครับโบร๋ แฮ่! โดยเฉพาะงานที่มี Xcode, Android Studio, simulators และหลายโปรเจกต์อยู่บนเครื่องเดียวกัน พื้นที่ 512 GB ที่ผมมีมันมีขีดจำกัดจริง พื้นที่เพิ่มช่วยให้เก็บเครื่องมือและข้อมูลที่ยังจำเป็นได้มากขึ้น โดยไม่ต้องคอยลบของเพียงเพื่อให้ build รอบถัดไปเริ่มได้

การมีพื้นที่เพิ่มช่วยเรื่อง capacity ทำให้เก็บเครื่องมือกับ build data ได้สบายขึ้น แต่ก็ต้องไม่ลืมว่าจำนวนงานที่เปิดค้างในหลายๆ context เป็นอีกเรื่องหนึ่งจ้า คือถ้ามีพื้นที่มากขึ้น เราอาจเลื่อนการ cleanup ออกไป หรือเปิด context เพิ่มขึ้นได้เหมือนกัน การมี storage ที่ใหญ่ขึ้นเลยช่วยเรื่องพื้นที่ แต่ไม่ได้ตอบว่าเรากำลังทำงานพร้อมกันมากกว่าที่จัดการไหวหรือเปล่า

สิ่งที่ผมกำลังลองปรับ

จริงๆ ผมก็พยายามจูน workflow ให้ประหยัดทรัพยากรเท่าที่ทำได้แล้วนะ ไม่ได้เปิด simulator ทุกตัวทิ้งไว้ เลือกใช้เฉพาะ simulator ที่จำเป็นกับงานหรือ test ที่กำลังทำอยู่ พยายามไม่ build หรือรันอะไรที่ยังไม่ต้องใช้ พยายามล้างนู่นนี่บ่อยๆ แต่ถึงจะจูนแบบนี้ งาน iOS กับ Android ที่สลับไปมา รวมถึง worktree และข้อมูลจาก build แต่ละชุดก็ยังสะสมพื้นที่ได้อยู่ดี

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

สิ่งที่ผมอาจลองเพิ่มคือ cleanup artifacts ตอนปิด worktree และจำกัดจำนวนงานที่ active พร้อมกัน ส่วนการจัดชื่อ worktree หรือ simulator ให้รู้ว่าเป็นของงานไหนก็น่าจะช่วยให้ตามเก็บง่ายขึ้น แต่ยังต้องลองดูว่าเข้ากับ workflow จริงแค่ไหน เพราะทุกวันนี้ผมก็มีของแนว handoff/pickup คอยปิด context, note เก็บไว้, กวาดโต๊ะทิ้ง ละค่อยหยิบมาลุยต่อ ซึ่งมันก็พอจะช่วยได้บ้างเหมือนกัน ก็ practical ประมาณนึง

คำถามที่ยังติดอยู่ในหัวของผม

ผมยังคิดอยู่ว่าตัวเองควรฝึกสลับ context ให้เก่งขึ้น…ไปอีก(ดีไหม) หรือควรฝึกปิดงานเป็นชิ้นๆให้เป็นก่อน เพราะว่าพื้นที่ 512 GB คงไม่ช่วยตอบคำถามนี้ให้ แต่ทุกครั้งที่ disk ใกล้เต็ม ทำให้ผมเห็นบางอย่างที่มองไม่เห็นตอนมีพื้นที่เหลือ (อันนี้ผมต้องขอบคุณนะ กราบ)

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

สุดท้าย ที่ผมเคยคิดว่าการเป็น software engineer ที่เก่งขึ้นคือการสลับ context ได้เร็วขึ้น ทำหลายงานพร้อมกันได้มากขึ้น หรือแบบ 10x Engineer อะไรนั่นที่เขาป้ายยากันมา ตอนนี้ผมเริ่มคิดว่าอาจเป็นการที่เรารู้ว่า context ไหนควรเปิด context ไหนควรปิด และ context ไหนไม่ควรถูกสร้างขึ้นมาตั้งแต่แรกตอนทำงานมากกว่า…

เอ้า จบเฉย ขอบคุณครับ

References

• Where did my disk go? Xcode, worktrees and AI agents
• Xcode Build System — Apple Developer Documentation
• Gradle-managed Directories and Caches — Gradle User Manual
• git worktree — Git Documentation
• How to Share DerivedData Across Git Worktrees in Xcode
• PreToolUse Hooks