I’ll have to try again later on desktop. The content looks interesting but it’s literally impossible to read. I cannot get past the section that introduces Ernst and Young.

Why?

I'm pushing the need for basic engineering principles across whole organisations.

You wouldn't give an engineer 1000 lines of code to review without the original spec of what you're trying to achieve for context (at a minimum, ideally the reviewer was in the room when the work was introduced, and has full context).

So, these docs, they're given as an all or nothing.

Do you push back on the 39th metric that is defined to the utmost detail? Or just resign yourself to the fact that it is what it is?

A one (6 is the goto if we're talking Amazon?!) pager.. "this is what I am proposing" at least gives the skeleton of the idea to push back at the general shape of the idea, refine it, before all the emotional investment of your precious report being complete.

Y'know.. the traditional product running through the spec in a SCRUM* environment.. the engineers doing proper code reviews..

* Yes SCRUM is dead, but that's another thing.

I think their audit work is in a downwards spiral. Audit has become so competitive that they are struggling to find ways to make it cheaper. They have become slaves to reducing the hours booked, and the rate of those hours. To do this they substitute less experienced people all the time. You used to be able to chat with your partner about an issue you have coming up, now you get their assistant if you are lucky. By chasing 'efficiency' they have lost their value-add. Now the first time the partner has looked at your file is right before the clearance meeting, and they spot issues that should have been picked up earlier and tested on the day you should be signing. So you end up doing it all again. I'm trying to coin a term for the inneficiency caused by chasing efficiency.

I think this may be part of the problem. The actual humans creating the report don't have the expertise to know which one to trust. At least that was what consulting was like in my experience in a similar firm.

Yes, this technique and its variations[1][2] "work" but it's still not 100% perfect. And it's not as widely used it might be because, among other reason:

a. it takes longer to implement

b. it costs more (more tokens spread across multiple llm calls)

c. higher latency (getting an answer takes longer due to multiple llm calls involved)

d. the final answer is probabilistically more likely to be correct, but is still not guaranteed to be error free, so you can never fully escape the need for Human in the Loop.

[1]: https://en.wikipedia.org/wiki/LLM-as-a-Judge

[2]: https://github.com/karpathy/llm-council