Still incorrect. And I would urge you to read one of these books you reference - they ALL aim to achieve that agent's action ON ITS OWN - i.e., by learning from its environment, and NOT by being explicitly programmed.
Yes, there are many explicit if-else style programs in Russel & Norvig, & other books - but those are the 'training wheels', until better methods are developed. For actual AI, the training wheels are supposed to come off, and the agent learns and acts on its own.
Every program that has ever existed does this. So, you're saying that all programs that have ever existed, then, are all AI. You make no distinction whatsoever.
I would say that the more a program thinks on its own which actions to take to maximize its chances of success, the closer to AI it is.
If it's doing exactly what it's explicitly told, then it's not really intelligent, is it?
A* search, any kind of heuristic estimation, learning, or simulated reasoning. All of those things would count.
We don't need mathematical optimization to call it "AI", but there SHOULD be more than a simple if-then.
At least show me that you're path-finding. That's not even being done here - this is just path-following.
"I leave a trail, you follow it." Explain to me how that qualifies as AI. Simple BFS/DFS achieves a lot more than this - which is considered by most to not even really be AI.
> the (possibly unattainable) ideal would be having everything expressed as "pretty much an if-then statement" indeed.
This is flatly incorrect - the point of AI is to have a machine achieve intelligent behaviors without explicit programming.
If an "if-then" must be written by a programmer for every single behavior, then this is called "programming". It is not called "artificial intelligence".
The origin of the "standup" is just a regular daily coordination meeting - like thousands of organizations have always had.
Ever heard of a "morning sales meeting"? They've existed for decades - short, to the point, 15-20 min. No one's ever heard of scrum in sales meetings. This kind of thing exists in hundreds of other businesses as well.
Much like everything else in scrum, they are just trying to take credit for something people already did - so they can package it and sell it back to people as if it were a novel idea.
There's nothing new or special about scrum - except a reduction in productivity because of the additional overhead and meetings.
The think I don't like about scrum is that they teach that you literally don't need to know a single thing about the underlying business - in fact, that is discouraged - following the process to the letter is what counts.
It is sold as a one-size-fits-everything process model, which can be run by non-programmers with zero experience who took a few workshops and got a scrum "certification".
It applies to any business - now including finance, accounting, and more ...
So I'd say by definition, a scrum company can achieve level -1 or 0 at best. It fits the Level 0 description PERFECTLY.
An actual formalized process which could be optimized would have to be set by subject matter experts after some deliberation. And would be designed to make an impact on product and quality.
Scrum can never achieve this - because the fundamental idea is that you can manage any business with the same established process - it will fix all of them ... no matter what the problem is ...
Yeah, I read this link also - before posting above. There is no 'username' or 'password' term on that page - nor any positive checkmark in any security column for the open-source tier.
'Basic' tier does have 'File and Native Authentication'. But it is far from clear what that means.
More importantly, in several different places that _are_ clear about security in the Elastic documentation, it repeatedly says "there is no security", "assume anyone who can reach elastic is a superuser" ... and more ...
So if that is not true, the documentation should probably change ...
No - I'm trying to say that people often don't even know what the DE really needs to do. They know they have back-end problems, and need someone to clean them up.
But often the hiring manager believes it's probably mostly SQL or mostly python, and advertises that. They really don't know - because someone left, and they are trying to replace them.
So you get there, and talk to the hiring manager, and they're like "are you good in SQL?".
Then you talk to someone closer to the problem, and they're like "most of it's in Java - how's your Java?".
Then someone even closer to the position says, "well, most of the work we need done is really in Scala".
It's your job to just take it over, and make it happen. "Fix the data" - using our existing patchwork of tools ...
This isn't always the case - but given the nature of the problem, this happens a hell of a lot more often than with Soft Eng's.
Yes, there are many explicit if-else style programs in Russel & Norvig, & other books - but those are the 'training wheels', until better methods are developed. For actual AI, the training wheels are supposed to come off, and the agent learns and acts on its own.