If you build guardrails on what is generated, verification is done at the same time as generation.
Think embezzlement. Think someone with a political agenda who changes the homepage on the way out the door.
Having a single point of control is asking for trouble.
Of course, since AI will be doing the writing and maintaining, there's really no reason for that any more. Let the AI do it all and wait for management to realize they're paying senior salaries to people that are little more than entering prompts, a job that really only requires someone to be able to read and write English.
if there are many of them (e.g. unit tests), who generates those guardrails and who verifies their correctness?
if they are a few, then how can they cover vast product capability surface?
Guard-rails are totally ineffective
If you're just knee-jerk anti-AI, then you probably need to sit down because some of us are taking serious evidence-based paths with GenAI.
If you have real data on guardrail ineffectiveness, that would be excellent material to share.
This is why those of us that follow DDD principles are successful. We know how to manage complexity whether we’re doing it manually or by using GenAI.
There are plenty of non AI security analysis tools we still use and add review gates for security gaps.
There is a huge misunderstanding about understanding the code. It implies knowledge of the classes, interfaces, and even internal logic.
If you design a modular system and generate code under strict rules, no one needs to know any of those things. We only need to understand the design and the results.
If we miss things, iteration is cheap.
Doubt!
Sounds like utter bull-crap!
But I’m lying and nothing I say could possibly be true.
Except it is and I have receipts.
"Strict rules" does so much heavy-lifting in what you said that it basically decides whether it applies to any reasonable complex system or is pointless and just worked on your constrained system and wouldn't translate to much else that isn't like directly related or analogous.
In my own works, I've been using a home grown harness called DevArch for about 10 months.
Visit https://genai.cornelson.net/ if you want a detailed rundown of my experiences.
https://martinfowler.com/articles/harness-engineering.html
https://milvus.io/blog/harness-engineering-ai-agents.md
I personally follow Domain-Driven Design principles and old enough to have designed software through the old Anderson Consulting Method/1 practices.
Some of the results of my practices are documented at https://genai.cornelson.net
Speed replaces pragmatism by allowing design flaws to be refactored N times where in the past we’d design around tech debt.
DDD leads to modularity and smaller bounded contexts has a significantly lower risk of being incorrect and significantly higher ability to refactor quickly.
And no you still have to understand how to construct software. We’re just skipping the coding skills and pushing everyone to be architects.
If you give up on trying to reduce the number of permutations you need to test, you're gonna also (even if not intentionally) give up on testing them.
We knew this, of course. But everything old is new again.