อังคารที่แล้วฉันสั่งให้ Claude Code refactor service ตัวหนึ่ง แผนชัดเจน prompt ดี และฉันบอกตัวเองว่าจะคอยดูมันทำงานแล้ว review diff ภายใน 15 นาที
ฉันมามองที่ strip อีกทีหนึ่งชั่วโมงต่อมา Claude Code มี foreground time 18 นาที Twitter (เอ้อ X น่ะ) มี 27 นาที Slack มี 11 นาที ส่วน code review จริง ๆ เกิดขึ้นในช่วง 4 นาทีสุดท้าย ในสภาพตื่นตระหนกพอประมาณ เพราะฉันสัญญาว่าจะส่ง diff ก่อนมื้อเที่ยง
นี่คือปัญหาของ developer time-tracker สรุปในย่อหน้าเดียว AI ทำงาน คุณมีหน้าที่ supervise แต่ในทางปฏิบัติ "supervise" แปลว่า "เฝ้าดู progress indicator สัก 2 นาที เริ่มเบื่อ เริ่ม scroll เสียไป 40 นาที กลับมาพบว่างานเสร็จแล้วและยังไม่ได้ review" Tracker ที่ดีจะบอกคุณว่าเรื่องนี้เกิดขึ้น Tracker ที่เยี่ยมจะบอกคุณว่ามันเกิดขึ้นทุกวันอังคาร
Tracker ส่วนใหญ่ที่มีอยู่ไม่ได้ categorize developer workflow มันจึงบอกคุณเรื่องนี้ไม่ได้ มันเห็น "Chrome" "Slack" และ "editor ของคุณ" เป็น bucket แบน ๆ นั่นทำให้พลาดรูปร่างจริง ๆ ของวันทำงาน developer ในปี 2026
วันของ developer หน้าตาเป็นยังไงตอนนี้
องค์ประกอบของ screen time ของ developer เปลี่ยนไปมากในสองปีที่ผ่านมา วันปกติของฉัน แยกตาม app หน้าตาประมาณนี้:
Ghostty — 4h 04m (terminal — Claude Code lives here too)
Octoweb — 1h 34m (browser — docs, GitHub, Hacker News)
Break — 41m (Timex break overlay)
Firefox Dev Ed — 39m (the work browser)
Slack — 27m
Chrome — 27m (work meetings, Notion, AI vendor consoles)
loginwindow — 12m (the lock screen — yes, we track it)
Spark Desktop — 6m (email)
นั่นคืออังคารจริง ๆ จาก log ภายในของเรา รูปร่างคร่าว ๆ คือ: งาน terminal/IDE 60% browser-as-tool 25% communication 10% และ lock screen ระหว่าง session อีก 5%
สิ่งที่น่าสนใจไม่ใช่ยอดรวม มันคือ การแบ่งย่อยภายใน terminal time ในบรรดา 4 ชั่วโมงใน Ghostty นั้น มีเท่าไหร่ที่เป็น Claude Code ถามคำถามแล้วรอคำตอบ? เท่าไหร่ที่เป็นฉันพิมพ์ command จริง ๆ? เท่าไหร่ที่เป็นฉันอ่าน output? Developer tracker ที่ซื่อสัตย์ต้องแยกพวกนี้ออกจากกันได้
Timex มองเห็น terminal-based AI tool ยังไง
Ghostty (และ iTerm2, Terminal.app, Warp, Alacritty — idea เดียวกัน) ส่ง window title ของตัวเองไปให้ macOS ในแบบที่มีประโยชน์ Terminal สมัยใหม่ส่วนใหญ่สะท้อน shell prompt ปัจจุบันหรือ command ที่รันอยู่ไว้ใน title bar Claude Code เมื่อเป็น process ที่ active จะตั้ง title เป็นอะไรประมาณนี้:
~/Work/dev/muvon/timex — claude-code (Sonnet)
นั่นคือ row ที่ Timex เก็บไว้ Window title คือตัวแยกแยะระหว่าง "ฉันกำลังพิมพ์ใน shell" กับ "Claude Code กำลังรัน" App เดียวกัน title ต่างกัน งานต่างกันมาก
SQL query ที่ยิงไปที่ SQLite database ในเครื่องทำให้เห็นชัดเป็นรูปธรรม:
-- Real coding (claude-code in title) vs everything-else terminal time, today
SELECT
CASE WHEN window_title LIKE '%claude-code%' THEN 'Claude Code'
WHEN window_title LIKE '%codex%' THEN 'Codex CLI'
WHEN window_title LIKE '%git%' THEN 'git'
ELSE 'shell' END AS bucket,
SUM(1) AS seconds
FROM activity_samples
WHERE date(ts, 'unixepoch', 'localtime') = date('now', 'localtime')
AND app_name = 'Ghostty'
GROUP BY bucket
ORDER BY seconds DESC;
คุณรัน query นั้นเองได้ที่ ~/Library/Application Support/io.muvon.timex/timex.sqlite output ของฉันเมื่ออังคารที่แล้วคือ:
Claude Code 8412 (2h 20m)
shell 5217 (1h 27m)
Codex CLI 408 (7m)
git 188 (3m)
สองชั่วโมงยี่สิบนาทีของ Claude Code time ในจำนวนนั้นฉันมีส่วนร่วมอย่างมีสติแค่ราว ๆ 40 นาทีของ review ที่มีความหมาย ช่องว่างนั้น — ระหว่าง clock time ที่ใช้ไปกับ AI tool กับ active engagement กับ AI tool — คือสิ่งที่ developer ส่วนใหญ่ประเมินขนาดต่ำเกินไป
Cursor กรณี IDE-as-AI
Cursor โผล่มาเป็น app ของตัวเอง (Cursor) จึงเห็นได้ง่ายกว่าในระดับ app สิ่งที่ยากกว่าคือการแยก "Cursor ที่มี Composer รัน agent อยู่" ออกจาก "Cursor ในฐานะ code editor" ทั้งสองมี window title ที่สะท้อน file ปัจจุบัน
ตอนนี้ Timex เห็น Cursor เป็น bucket เดียว การ split agent-vs-editor ไม่ใช่อะไรที่ window title เผยให้เห็นได้อย่างน่าเชื่อถือ (Cursor ไม่ได้ update title ตาม agent state) ถ้าอยากเห็นการแบ่งนั้น คุณต้องเอา data ของ Timex มารวมกับ usage stat ของ Cursor เองจาก settings panel ของมัน เราอาจเพิ่ม integration เฉพาะของ Cursor ใน v1.1 — แต่ก็ต่อเมื่อมี public API ที่สะอาดให้อ่านได้ ซึ่งตอนนี้ยังไม่มี
Codex CLI: idea เดียวกับ Claude Code
Codex CLI ของ OpenAI ทำตาม pattern เดียวกับ Claude Code — รันอยู่ใน terminal update title ด้วย model และ working directory SQL query ด้านบน filter หามันได้โดยตรง
ถ้าคุณ A/B-test Claude Code กับ Codex CLI (ซึ่ง developer หลายคนที่ฉันรู้จักกำลังทำกันอยู่ตอนนี้) นี่คือจุดที่ data เริ่มมีประโยชน์ เอาเวลาที่ track ไว้ของสัปดาห์ที่แล้วมา split ตาม tool ที่ active แล้วคุณจะเห็นอะไรประมาณนี้:
Claude Code (Sonnet 4.7) — 6h 12m total, 4h actively engaged
Codex CLI — 3h 41m total, 2h 50m actively engaged
"Actively engaged" ตรงนี้หมายถึง non-idle อัตราส่วนของ Codex มักจะสูงกว่าใน data ของฉัน เพราะ Codex มักถามคำถามขอความกระจ่างมากกว่า ซึ่งทำให้คุณอยู่ใน loop ตลอด Auto-run ที่ยาวกว่าของ Claude Code เปิดช่องให้คุณ drift ไป Twitter ได้มากกว่า สำหรับงานที่ focus และ scope ชัดเจน นั่นไม่เป็นไร แต่สำหรับอะไรที่ปลายเปิด มันคือ liability
Octomind agent run
Octomind เป็นสัตว์อีกพันธุ์ เมื่อคุณ kick off agent run มันจะไปทำงานเองอยู่เบื้องหลังขณะที่คุณทำอย่างอื่น Octomind ปรากฏใน Timex เป็นเวลาที่คุณใช้ไปกับ การมองที่ dashboard ของมัน ไม่ใช่เวลาที่ agent กำลังรันอยู่บน server ที่ไหนสักแห่ง
นั่นคือ behavior ที่ถูกต้อง ถ้า agent ทำงานเองได้อัตโนมัติ มันก็ไม่ได้กิน attention ของคุณ ถ้าคุณนั่งจ้อง dashboard รอมันอยู่ นั่น คือ attention ของคุณ และมันก็แสดงผลออกมาถูกต้อง
Pattern ที่โผล่มาซ้ำแล้วซ้ำเล่าใน data ของฉัน: เวลาที่ใช้กับ Octomind dashboard correlate กับความวิตกกังวลแบบเกือบสมบูรณ์แบบ Run ที่ฉันเช็คทุกห้านาทีคือ run ที่ฉันไม่ค่อยไว้ใจ prompt เต็มที่ Run ที่ฉัน kick off แล้วลืมไปเลยคือ run ที่เวิร์ค Data กำลังสอนฉันว่าควรเดินจากไปตอนไหน
Browser tab กับตำนาน "research"
Browser tab tracker เมื่อคุณให้ Accessibility permission จะ capture title ของ tab ที่ active สำหรับ developer นี่คือ feed ที่น่าสนใจที่สุดในบรรดาทั้งหมด
อังคารที่แล้ว เวลา Octoweb (browser) ของฉัน 1h 34m แยกย่อยคร่าว ๆ ได้ว่า:
github.com/muvon/... 45m
docs.anthropic.com 18m
news.ycombinator.com 12m
stackoverflow.com 11m
twitter.com (or whatever) 6m
docs.python.org 4m
... long tail ...
สิ่งที่ฉันอยากชี้ตรงนี้: สังเกตว่า Hacker News + Twitter + Reddit ไม่ใช่พาดหัว พาดหัวคือ GitHub กับ docs เรื่องที่ฉันเล่าให้ตัวเองฟัง ("วันนี้วอกแวก") ไม่ตรงกับ data ("วันนี้ส่วนใหญ่อยู่กับงานพร้อม scroll นิดหน่อย") ถ้าไม่มี data ระดับ tab ทั้งสองเรื่องก็น่าเชื่อพอ ๆ กัน แต่พอมีมัน เรื่องหนึ่งคือเรื่องจริง
อีกอย่างที่ฉันอยากชี้: ฉัน crop long tail ออกไป ในนั้นมีราว ๆ 18 นาทีที่เป็น context switching ล้วน ๆ — Gmail 30 วินาที แล้วกลับไป GitHub แล้ว Notion อีกหนึ่งนาที แล้วก็กลับ Micro-cost นั้นคือสิ่งที่ developer ส่วนใหญ่พลาดเวลาประเมิน focus time ของตัวเอง มันไม่ใช่ tab ใหญ่ ๆ บน Twitter — มันคือการเช็คครั้งละ 30 วินาทีอีกเป็นโหล
SQL ของ "ฉัน ship อะไรไป"
ถ้าคุณจะรัน query ไปที่ Timex database แค่ตัวเดียว ให้รันตัวนี้:
-- Longest contiguous focused-on-real-coding block in the last 7 days
SELECT
date(ts, 'unixepoch', 'localtime') AS day,
app_name,
window_title,
COUNT(*) AS duration_seconds
FROM activity_samples
WHERE is_idle = 0
AND app_name IN ('Ghostty', 'Cursor', 'Xcode', 'Visual Studio Code', 'Zed')
AND ts > strftime('%s', 'now', '-7 days')
GROUP BY day, app_name, window_title
HAVING duration_seconds > 600
ORDER BY duration_seconds DESC
LIMIT 20;
นั่นจะให้ session การ coding แบบ focus ยาวเกิน 10 นาทีที่ยาวที่สุด 20 อันดับของสัปดาห์ที่แล้ว group ตามสิ่งที่คุณทำอยู่จริง ๆ (window title) Output มันซื่อสัตย์แบบโหดร้าย สัปดาห์ที่ฉันรู้สึกว่า productive แต่ query กลับมาด้วย session เกิน 10 นาทีแค่ 6 อัน คือสัปดาห์ที่ฉันต้องยอมรับว่าจริง ๆ แล้วมันคือสัปดาห์ที่ meeting เยอะพร้อมภาพลวงตาของ focus
สิ่งที่ developer อยากรู้จริง ๆ
ความรู้สึกของฉัน calibrate เทียบกับวันก่อนยุค Claude Code ตอนที่ "อยู่ใน editor 6 ชั่วโมง" แปลว่า "เขียน code 6 ชั่วโมง" นั่นคือเหตุผลที่ฉันกลับไปหา data แทนที่จะเชื่อความรู้สึก แต่ workflow ไม่ได้ทำงานแบบนั้นอีกแล้ว "อยู่ใน editor 6 ชั่วโมง" อาจแปลว่า:
- 2 ชั่วโมงของ Claude Code ที่ supervise แล้วได้ code 700 บรรทัด
- 1 ชั่วโมงของ drift แบบไม่ได้ supervise ขณะที่ Claude Code กำลังรัน
- 1.5 ชั่วโมงของ code review และแก้ไข
- 30 นาทีของการสู้รบกับ git
- 1 ชั่วโมงของ context switching กลับเข้ามาในงาน
อันแรกกับอันที่สามคือส่วนที่ผลิต code ที่ ship ได้ อันที่สองคือส่วนที่ต้องลดลง Data แสดงให้ฉันเห็นว่าอันไหนเป็นอันไหน ความรู้สึกอย่างเดียวทำไม่ได้
ขีดจำกัดอย่างซื่อสัตย์
มีอยู่ไม่กี่อย่างที่ tracker แบบนี้บอกคุณไม่ได้:
มันวัดคุณภาพของสิ่งที่ ship ไม่ได้ Claude Code 4 ชั่วโมงกับ PR ที่สะอาด นั่นเยี่ยม Claude Code 4 ชั่วโมงกับ PR ที่ต้องเขียนใหม่ใน sprint หน้า นั่นคือภาษีที่ต้องจ่าย Tracker เห็นแค่เวลา ไม่เห็น outcome
มันมองไม่เห็นงานที่เกิดขึ้นในหัวคุณ ครึ่งชั่วโมงที่เดินวนในห้องคิดเรื่อง architecture ก่อนจะนั่งลงเขียนสิ่งที่ถูกต้อง — นั่นไม่อยู่ใน data Data เห็น "loginwindow + idle" คุณจะคิดผิดถ้าอ่านมันว่า "เสียเปล่า"
มันไม่สามารถ categorize ได้ถ้าไม่มี window-title cue ถ้า shell prompt ของคุณไม่แสดงว่า tool ไหนกำลังรัน Timex ก็เห็นแค่ "Ghostty" แค่นั้น ความละเอียดเป็นฟังก์ชันของ data ที่ tool ของคุณเผยออกมา
สิ่งที่มันทำได้คือให้ภาพที่แม่นยำที่สุดเท่าที่เป็นไปได้ในตอนนี้ว่าวันของ developer แยกย่อยออกมายังไงจริง ๆ — รวมถึงส่วนที่คุณไม่อยากเห็น อย่าง 27 นาทีบน Twitter ตอนที่ Claude Code กำลังทำงานอยู่
ถ้าคุณใช้ตัวใดตัวหนึ่งใน Claude Code, Codex CLI, Cursor หรือ Octomind — และคุณอยากเห็นว่าวันจริง ๆ ของคุณหน้าตาเป็นยังไงเมื่อมองผ่าน tool พวกนี้ — คว้า trial มาเลย Strip สีนั้นซื่อสัตย์ในแบบที่เถียงยาก