I think presuming that humans don't act "as instructed" is a bit too generous an assumption.

LLMs are capable of declining to do things. They're also capable of trying to do things and getting them subtly (or very) wrong.

A lot of this hinges on defining consciousness. I think there is more to the story than what human beings experience.

Do LLMs have an experience very similar to human beings that we would describe as consciousness? No, I don't think that.

I think the bar for consciousness is something more like experiencing a dream. You have a "mind's eye". The experience of existing, rather than nothing. Does that exist somewhere under an LLM? I don't know, but I think confidently claiming that the answer is no seems a bit of a rush judgment.

When I go to sleep, I dream sometimes. There is "a place" somewhere that I can see and hear things in my mind. It's not physical, but it's real.

If a collection of GPUs had something like that, would it be conscious?

I don't know that is true. I'm saying it seems absurd to strongly claim that it is absolutely false.

Our brain is matter and electrical signals. So are GPUs. We're just not made of silicon.

If those things are left unsaid and everyone still understands what's being referred to (even generally) there can be some alignment on the issue.

Some people with ideological axes to grind like to pick fights on particular points, even (perhaps especially) when it is not constructive.

But then, one small detail changed everything. And it wasn't something I'd have thought of until I was writing the code.

I shudder thinking about the number of these issues hiding in LLM-generated code.

The power of your vote is proportional to the value you bring.

A while back I threatened to quit because I had a team dynamic that was untenable. I made a management change mandatory.

I got a new boss. The old boss was later terminated.

One of the major benefits of a shell-based approach is your env vars could be generated from the output of a command.

Which can be trivially used to populate secrets from whatever your secret store of choice is.

Now we've also cleanly solved secret distribution for developers with one less dependency!

Direnv is the right way to go if you want a tool for this. Otherwise dotenv's implementation in bash is essentially `set -a; source .env`. Look ma, no custom parser!

Seems really silly to have a library do what two lines of shell can reasonably accomplish.

It's low priority in the sense that people in charge tend not to value it.

That's different from saying it is not impactful, or wouldn't lead to a good business outcome, if the software were built better.

Software that needs to be babysat is an ongoing opportunity cost.

You state this so confidently, like every person who walks through the door to interview will be 100% honest about their level of experience.

Have you ever interviewed? Nobody _wants_ a software engineer on their team who is awful.

Sometimes they slip through the cracks for a variety of reasons.

Using your personal experiences and the personal experiences of people you trust as an anchor is a good thing. It keeps you from falling for propaganda. Note that this DOES NOT mean studies conflicting with your personal experience are all wrong.

The tricky part here is understanding the limit of what your own experience can tell you.

The entire point of slowing down is so you don't do this. Understand the problem well first, so you don't waste time building something that was never viable in the first place.

The author isn't advocating for perfect. You have to understand the problem well enough to know what all of the critical assumptions are. Some assumptions will derail an entire project if you get them wrong. Others will be a minor inconvenience, at worst.

In software, having a solid handle on future architecture means you can speak to how unanticipated new features fit in. You know what parts you can skip for now, and have it not be a big deal.

I've started to wonder if many of the people obsessed with speed lack capability. If you can't build something well, you can try building something poor quickly. This certainly applies to my current employer.

So many businesses are pushing AI hard. People with varying levels of job (in)security want to be seen as "leading the charge" into a post-AI era.

LLMs can do some really impressive things, don't get me wrong. But I regularly find massive blunders in the code it produces.

And that actually makes sense if you understand how LLMs operate and the quality of software on GitHub.

Dark matter is a great example.

Our understanding of gravitation didn't cleanly apply at ultra-large scales so we had to add a massive fudge factor.

You can't "go faster" than the speed of light, but space in between things can expand faster than the speed of light.

It seems like things that are "settled" regularly get an "ope, but except for this special case..." treatment.

The PR reviewer isn't the only person who will ever review your code, you know.

The first thing that came to mind for me: how do you change a single site's password? The article doesn't say. It only mentions that changing the master password would require changing all passwords. That also seems like a complete non-starter.

There is an array of useful functionality that modern password managers provide, too: password sharing, saving select file content securely, password history, storage of security questions and answers, storing username (when you use something atypical for anonymity).

I can't help but feel like this idea is a dud. It's neat in an academic sense but it can't seriously compete with what already exists.

Where in the US do you find it's difficult for people to get an ID? Where is it not? What percentage of the population has an ID in a place where it's difficult to get one vs somewhere it is easier?

What constitutes an ID being expensive?

Nearly every country in the world requires proof of citizenship to vote. How is the rest of the world dealing with this problem? Do you think that their democratic processes might be compromised because of it?