I wouldn't put it in past tense...

I’ve also been guilty of plugging at something, and squashing it all before publishing for the first time because I look at the log and I go “no way I can release this, or untangle it into any sort of usefulness”.

I have a similar process. Internal repo where work gets done. External repo that only gets each release.

That is totally fine... as long as you don't call it 'production grade'. I wouldn't call anything production grade that hasn't actually spent time (more than a week!) in actual production.

But if the initial commit contains the finished project then that suggests that either it was developed without version control, or that the history has deliberately been hidden.

Tbf, there is no one with a ‘serious DevSecOps background’. It’s an incredibly strong hint that the person is largely a goof.

Taking a best-faith approach here, I think it's indicative of a broader issue, which is that code reviewers can easily get "tunnel vision" where the focus shifts to reviewing each line of code, rather than necessarily cross-referencing against both small details and highly-salient "gotchas" of the specification/story/RFC, and ensuring that those details are not missing from the code.

This applies whether the code is written is by a human or AI, and also whether the code is reviewed by a human or AI.

Is a Github Copilot auto-reviewer going to click two levels deep into the Slack links that are provided as a motivating reference in the user story that led to the PR that's being reviewed? Or read relevant RFCs? (And does it even have permission to do all this?)

And would you even do this, as the code reviewer? Or will you just make sure the code makes sense, is maintainable, and doesn't break the architecture?

This all leads to a conclusion that software engineering isn't getting replaced by AI any time soon. Someone needs to be there to figure out what context is relevant when things go wrong, because they inevitably will.

This is especially true if the marketing team claims that humans were validating every step, but the actual humans did not exist or did no such thing.

If a marketer claims something, it is safe to assume the claim is at best 'technically true'. Only if an actual engineer backs the claim it can start to mean something.

the problem with "AI" is that by the very way it was trained: it produces plausible looking code

so the "reviewing" process will be looking for the needles in the haystack

when you have no understanding, or mental model of how it works, because there isn't one

it's a recipe for disaster for anything other than trivial projects

The learning is "they lied". After all, apart from marketing materials making a claim, where is the evidence?