Maybe I'm just not aware enough to notice any quality degradation, but I've been using Claude Code in repos that only have AGENTS.md and it just generally seems to know to read it when getting its bearings.

I have one and it's such a fantastic design. When I need to travel I just throw a tiny puck in my bag and it charges off the same brick that charges everything else I bring.

I spent a few months doing some coarse time tracking at work - basically I'd retroactively add and edit events on my calendar to reflect what I had actually done during the workday, down to 15 minute increments. I binned them into IC work, meetings, interruptions, and non-work stuff. While I did get some insights about where my time was going, it mostly just made me really anxious and input-oriented about my productivity and made feel guilty if I didn't end up working a full 8 hours on a given day. Stopping the time tracking was good for my mental health.

Regarding the 8 hour, I've just come to realise that I can't get 8 productive hours in a day (I want to say most people can't but maybe I'm projecting). I track every day and the good days have around 5 hours tracked. The bad days around 2

Good to hear I'm not the only one.

I've tried it for a few months for 1-hour intervals and it wasn't as stressful, and was a useful exercise to understand how I'm using my time.

I feel like there's a few lessons here, depending on what your goal is: if you're mostly working, are those hours useful, and if you're not, do you care about it?

> made me really anxious and input-oriented about my productivity

Yes, exactly! Even if I got a bunch done I'd still feel like I didn't accomplish anything if I had "wasted" too much time.

Raw throughput and time efficiency should be treated as separate metrics. They should not be conflated with productivity, nor are they all that correlated to begin with. I define productivity as an abstract goal. The time tracking is information to satisfy my curiosity and gain insight. There's no place for quotas in my approach. There are only ever relative comparisons for me.

Time efficiency is just percent of the time range you arbitrarily defined filled by the tasks you explicitly defined. If it seems low it doesn't necessarily mean you aren't tracking enough things, but that your subtask definitions are too narrow.

Raw throughput is either the number of tasks completed or "points" redeemed, but often your subtask estimates are too "lumpy" or just flat out wrong.

I get that it's not for everyone, but there's nothing wrong with time tracking in itself. It's its own skill. Discomfort is usually a sign you need to try new techniques. Don't give up.

I'm a little skeptical of claims like this that involve migrating things like libraries, etc. I've done big refactors like this multiple times (albeit, in an "only" 500k-1m LOC codebase) with less powerful models and it is usually just 99% the same edits, with 1% requiring a close human eye to resolve a particularly painful breaking change.

EDIT: to be clear, it's still quite a helpful thing in terms of time saved, I just don't think it's necessarily the best indication of value-added from making models smarter when cases like this can often be handled by well-directed swarms of smaller ones.

Mostly I was not an "I have a script for that" guy before AI, except for the occasional VERY simple or VERY high ROI thing. Now I've got more oddball scripts that do things I couldn't be bothered to automate before, including: workarounds for buggy software, stitching tmux together with other tools, automating common operations so I don't have to use the god awful GitHub UI, etc.

Not an "oh shit" per se, but Gemini is a complete leap in terms of actual smarts over Google Assistant.

I was having problems getting it to parse my speech correctly when I was asking about "autolyse" (I was attempting to bake bread). All I had to do to fix it was add this to the system prompt: " I primarily interact with you via a speech to text mechanism. You should consider ways in which my words may not be accurately transcribed and attempt to infer the correct reading in context. When you do this, do not mention it - just proceed as if my words were recorded properly."

Never had that problem again. With Assistant though, if I had any issue like that I'd be waiting months or years for a fix, if it ever came.

For straightforward coding tasks I use gpt-5.3-codex on high or xhigh. Sometimes I try 5.5 but overall 5.3-codex is more than capable enough for most of my needs and quite a bit cheaper.

For more interactive/discussion/planning or orchestration stuff, I find myself going back and forth between Opus 4.7 and GPT 5.5. Still not sure which one I prefer.

I bought AMD as my last GPU purely because it meant I didn't have to stress out about how I was actually going to acquire one. I just walked into Microcenter, picked one off the shelf, and checked out. It was the crypto craze then, and I get the impression that this hasn't changed much today with AI sucking all the oxygen out of consumer electronics. Didn't care very much about DLSS or any other Nvidia specific features. That AMD works well on Linux only sweetened the deal.

FWIW I usually don't structure my Go projects this way unless they're very very small. This is what I usually do for anything larger than 2-3 files:

  ├── cmd
  │   └── binary-name
  │       └── main.go (may subpackage for things like CLI porcelain, etc)
  ├── go.mod
  └── internal
      └── app.go (and subpackages, etc)

I started seeing this a lot more with GPT 5.4. 5.3-codex is really good about patiently watching and waiting on external processes like CI, or managing other agents async. 5.4 keeps on yielding its turn to me for some reason even as it says stuff like "I'm continuing to watch and wait."