If they can’t do it themselves then they have no idea if the output is good. If they want to run it through the bullshit machine they shouldn’t post the output unless they know it is accurate.

I am saying that coining it as a term was stupid and intended to make it sound intelligent when it isn’t.

Those are examples of actual hallucinations where something did not happen.

Quoting a joke reddit thread as factual is not hallucinating. There was such a thread, but it wasn’t factual and an LLM is wrong to present it as factual.

We don’t need a fancy word that makes it sound like AI is actually intelligent when talking about how AI is frequently wrong and unreliable. AI being wrong is like someone who misunderstood something or took a joke as literal repeating it as factual.

When people are wrong we don’t call it hallucinating unless their senses are altered. AI doesn’t have senses.

We further argue that describing AI misrepresentations as bullshit is both a more useful and more accurate way of predicting and discussing the behaviour of these systems.

Bullshit is a far better description for sure.

People think it AI intelligence is comparable to how a hovercraft hovers, as in the word is taken literally, but it is actually comparable to a Hoverboard.

Did they replace the writers from season 11?

That is the only season I skip on my eternal rewatching loop for relaxing before bed.

I’ve used a wrench to hanmer in a nail more than once, but that doesn’t mean it was the best tool for the job.

It isn’t that agile can’t be used for something big, but that the design will likelyntun into hard requirements that must be approached certain ways and at thst point you are using agile to do waterfall. If it improves communication earlier in the process (which waterfall does not prohibit) that is great!

If you write it down it is documentation. When requirements are written down, they are documented! Requirements are not the same thing as specifications either, but both are documentation!

You are saying that only technical documentation counts as documentation.

A large and complex system with an API and interacts with multiple other systems that is maintained over multiple years will be killed by agile through scope creep and inconsistent implementation when there is staff turnover. People will get great ideas that break other things snd without a cohesive vision across the team, things will be missed and unfinished because people focus on their part and not the whole.

You can add the structure to keep things coherent and spend more time doing documetation up front so people can review the API and do it right the first time instead of redoing it multiple times.

Agile is great for some projects, but ataff turnover, coordination, and meeting any kind of complex external requiirements means it isn’t a great fit for all projects.

Being able to adapt does not require all of the other parts of agile.

So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.

The details on HOW to authenticate are ALSO documentation. Not all documentation describes functionality.

Requirements ≠ Documentation.

They are part of documentation, but not all documentation.

The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.

It sucks for any large group that requires a lot of coordination. Some parts of it are still helpful as part of a blended process, like more collaboration with the customer and responding to change, but those can easily derail a project if not everyone is on the same page through scope creep or losing sight of long term goals.

So ninjas could sneak in along as they don’t use bluetooth?

You are making a comparison of a groundbreaking first attempt at a new type of open world game to the later versions that improved on the model. That means the first one wasn’t trash, because you enjoyed it at the time, it just isn’t as good as what followed.

2. All the (unneeded) secrecy around the compensation package - you are not allowed to talk about your salary and stock options with other employees, and in some places not even with your manager.

That is illegal even in the US, although it happens all the time.

I assume it is also illegal in other countries with better worker rights laws than the US.

I always thought it was just the arm Bender had around at the time, and since severed arms go bad…

Removed by mod

As someone involved in software development on the requirements, testing, and project management side, that was the best summary I have ever read about the entire process. I recognize all of the examples of failures/learning experiences and how they can be avoided.

Just a great read, thank you!

Off to see if I can get a few coworkers to read it.