Similar to aviation s marine safety. Both started with a bunch of prescriptive rules that were added to as various accidents and near misses occured. As you say.
Then, in the last couple of decades there has been a move to performance based standards.
These work by the designers trying to anticipate hazards specific to the design and it's intended duty, and then providing mitigation to reduce the risk down to sn acceptable level.
This has a number of poditive outcomes, but not least is the expenditure on mitigation is directed in the most economic manner.
All this requires a systrmd approach, and when properly applied has been shown to yield superiour results.
Humans don't really work any better, just fail in different ways. This is why certain workflows and practices have emerged.
We are now in the early days of working through a similar process with AI.
They most definately do work for some use cases, but how they are used is important.
Just because you apply human processes and systems to AI based workflows and don't get historically expected results, this is zero basis to claim the sky is falling with use of AI in coding.
I didn't claim the sky is falling with the use of AI in coding.
I claimed
> basic security features like asking for user confirmation for bash commands, or restricting commands to the current directory
Do not currently reliably work. Not to the point that anyone concerned with security or reliability/not-having-their-env-fucked-up should trust these safeguards as standalones.
Yes definately, I do a lot of OT devops and if you want determinstic results then the best use of AI is to get it to write scripts that solve your problems and that you run outside of AI.
Often, the use of AI is a lazy case of not wanting to spend the time to understand the essence of the problem and solve it directly, often far more efficiently. (Not always, but often).
The ability of getting results that surpass your understanding, and quickly, is seducing, but you invariably end up being capped on the usefullness.
AI generally seems to raise anyone with the basic skills to "expert beginner" in almost any field, but it is then a big struggle to get past this stage, without substantial extra work.
The problem isn't the AI writing the code, it is the specification - I assert much of the described problems could be rectified by improved specification with no hand coding.
Specification of software has been very weak for decades, and little effort has been put towards defining methadologies of specification that are both exhaustive and unambiguous.
It is possible, I know because I work in an exotic niche where being exhaustive and unambiguous isnot optional - Functional Safety. Here you might spend 90% or more of your time planning what and how to code, before writing the first line.
The cost - I have worked on projects where, across the duration of the project, the average production of code was less than two lines a day.
But when a single error could result in the death of 100, or 300, people, then this time worth it.
You can't get this kind of quality when you pivot twice a week, you need to have fairly fixed objectives.
The are ways to get better outcomes that are known, but not widely applied, and they could do with some development to make them accessible. Some has been done, eg Leslie Lamport and TLA+.
But, as you might have been told as a child, don't get upset that you did not get what you wanted when you failed to ask for it properly.
I would suggest that the 1000 line switch statement implies a state machine that has suffered from the "state explosion".
This usually results from an inadequate system-subsystem decomposition and/or not considering modes, both of which lead to hierarchal state machines instead of one big flat one.
This aspect of architecture is difficult to teach, it is one of the "black arts" that comes from experience and is difficult to codify.
Just one example why, is that often it might require the synthesis of state machines not directly evident as needed from the functionality, eg to perform a one to many or many to one functionality.
can't find the actual code, but its a look up table for what dialogue to use. The existence of a switch statement does not force the code to be a state machine.
it could still be some architectural deficit around making it harder to look up the dialogue rather than having it in place when uts triggered, but it makes it nice to understand all the dialogue in the game at once
While the two can be closely aligned, it is not neccesarily the case, if not often misaligned priorities.
Many pdfs are hard to read based on a consistant set of rules, reliance on edge cases and context and conventions.
reply