> I missed the part where this has anything to do with saving time
It lets you put the non-car stuff closer together, so you're traveling less
distance to get to the same place. It requires urban design, not just a single person switching between modes of transit.
(Although switching to cycling can often make transit both faster for you and the people around you in a city because you aren't as affected by traffic and don't create as much traffic)
The boat itself rocks, but do you see the background changing to indicate the boat is progressing through the environment? I only see that in the 3.1 Pro example. I believe that's what the OP meant.
Agreed. I think the approach described here is promising. Most of the workflow is deterministic and includes safeguards, but an LLM is invoked in the one case where it's really useful.
I'm sure most folks run Claude without isolation or sandboxing. It's a terrible idea, but even most professional software developers don't think much about security.
There many decent options (cloud VMs, local VMs, Docker, the built-in sandboxing). My point is just that folks should research and set up at least one of them before running an agent.
I agree with most of this, with one important exception: you should have some form of sandboxing in place before running any local AI agent. The easiest way to do that is with .claude/settings.json[0].
This is important no matter how experienced you are, but arguable the most important when you don't know what you're doing.
0: or if you don't want to learn about that, you can use Claude Code Web
This is broadly true, but not comparable when you get into any detail. The mistakes current frontier models make are more frequent, more confident, less predictable, and much less consistent than mistakes from any human I'd work with.
IME, all of the QA measures you mention are more difficult and less reliable than understanding things properly and writing correct code from the beginning. For critical production systems, mediocre code has significant negative value to me compared to a fresh start.
There are plenty of net-positive uses for AI. Throwaway prototyping, certain boilerplate migration tasks, or anything that you can easily add automated deterministic checks for that fully covers all of the behavior you care about. Most production systems are complicated enough that those QA techniques are insufficient to determine the code has the properties you need.
This is a couple of years old now, but at one point Janelle Shane found that the only reliable way to avoid being flagged as AI was to use AI with a certain style prompt
I had the same experience as peer comments. I'm on Pixel 8 and Google Fi. When I check for updates, I'm told I'm up-to-date with the last update being over a month old.
You should see an "unvote" or "undown" link to the right of the timestamp (i.e. the opposite side from where the vote arrows were). It's fairly subtle.
Yeah, I never send a PR out without reviewing each commit myself and adding GitHub comments when I think it's relevant. Sometimes a PR is clear enough that I don't feel the need to add comments, though.
I'd say "good old days" thinking is probably involved, but not the full explanation. Over the past few decades, software has gone from a fairly obscure profession to being seen as a great way (maybe the best way) to make a lot of money. In absolute numbers, there are probably at least as many engaged, curious engineers as before. There are almost certainly drastically more uninterested engineers who are there partially or fully because of the money, though.
It lets you put the non-car stuff closer together, so you're traveling less distance to get to the same place. It requires urban design, not just a single person switching between modes of transit.
(Although switching to cycling can often make transit both faster for you and the people around you in a city because you aren't as affected by traffic and don't create as much traffic)