You’re right, but the keyword in my post was “should”. If you have to look up “short selling” in the dictionary (as in OP’s case), naked options aren’t on the menu.
Regarding the multi-tasking induced by this new way of working (agentic coding), I've moved from quick and short iterations to a longer ideally one-shot prompt, optimizing for less reviewing and less context switching.
I used to send a prompt as early as possible, meaning that'd really just give the rough idea, barely a sentence, and see what the model would come up with, thinking that I'd save time if it got it right for the first time, and maybe I'd just need to correct what it got wrong (it's faster at typing than me). That means a lot of multitasking at a rather high pace, which takes its toll if you do it for too long.
I've recently switched to writing longer prompts (doing part of the planning myself), hoping to get better results and to have less to review: I'm realizing I'd rather write more and read less, past a certain threshold. I don't really want to iterate with an agent; I want to tell it, maybe in somewhat verbose terms, what I want, I want a quick confirmation that it'll indeed work, and I want the final output (e.g. a commit), that's it.
That's probably what some users have been doing since the beginning, but with all the hype around this tech, maybe I got caught by this idea that with just a few words, I can get stuff done. In my experience, it's indeed just a few words, but for useless units of work (iterations with a model) rather than what I really want (commit) which itself will often require non-trivial amount of input. In this case, I'd rather give it all in one go, in a somewhat focused state.
I would try to learn some new tech. Definitely not something you can do in a vacuum with no goal for months in a corporate setting, but e.g. learning more about a programming language you already use, or some libraries, some tooling, you can easily spend a few weeks.
After that, yes it'd make sense to find something else.
Not sure what you mean by spec and design, but around me, that's always been paid more than simply coding. If you have a clean technical spec that's detailed enough, the code naturally flows and is often left to more junior engineers, with more senior folks reviewing the code but rarely writing it.
That, and it also needs to be mentioned that if an engineer is given a tool like claude, they will be given _more_ work. As an example, you might give an intern the following task:
"we have service A that receives a request, it now has a new flag in it, we need you to pass it through to in the call A makes to service B, and then add it in the where clause of the query that B makes".
and expect it to take 2 days including manual testing.
Now you would expect the same much quicker. Any weird bug of the kind "flag not showing up in B because its another weird place where the request _actually_ goes through" that would before suck up 5 hours, would now be found out by the LLM in 2 minutes. "Oh because of this feature being activated in <random yaml file>, this new path is used, so you have to add the flag passing logic there". And the next day they get a new task.
This was an extreme example, and it's also not a silver bullet, since now you need to ensure that the intern does the task in a way that they still learn the codebase and the service structure (ideally, they learn quicker) and doesn't become completely beholden to the LLM. So that will also become a skill teams look to hone, how they use tools like this.
Same here, music is too important for me to give up this kind of control. I probably miss out on the discovery system of streaming services, but there are enough other sources (e.g. radio paradise).
If "things go catastrophic" your hard drive is not usable at all anymore. At the very least some files can't be recovered at all. So you need backups in any case. Once you have backups, you might as well encrypt your hard drives, especially if you store these in different locations (which you should).
An advantage of encryption is that it makes it easier to give away or resell devices. With recent encryption schemes (well the ones on Linux, given this article), I feel confident that overwriting the encryption keys gets me close enough to not leaking my data once I get rid of an old hard drive.
That’s not true. I’ve had many computers that refuse to turn on and I was able to recover the files by removing the drive and loading it into a USB hard drive reader and recover the files.
