Calling work "AI slop" is easy. Doing it without naming the defect is lazy. A broken button, a bad API contract, and a dangerous system design are not the same problem.
You also need to know the alternative. Did AI help ship a useful product that would otherwise be delayed? Did it add a broad test suite where there was none? Imperfect work can improve the product. That does not excuse a dangerous defect. It means you must judge the work and the trade-off, not just its origin.
AI makes mistakes. So do junior engineers. You still work with both. You give them work they can check, and you review the decisions they cannot afford to get wrong. Refusing to use either is not a strategy.
Call it a risk budget: what can fail, for how long, and with what consequence?
A social app may survive an hour of downtime. That does not mean its users will like it. Surgical software may not survive a second. It must fail safely. Where operation must continue, an independent backup must take over. Copying the same design twice can copy the same failure.
Risk changes by layer:
- Product specs: Define what must work. A polished implementation of the wrong behavior is still wrong.
- Architecture: Review every consequential choice. Databases, data flow, and system boundaries are expensive to change.
- Service contracts: Review how systems talk. Write measurable reliability targets. If users depend on a service, specify its SLA.
- Modules: Require tests. Cover the boundaries with integration and end-to-end tests. Review critical components more closely.
- Functions: Review the ones whose failure matters. Test the rest.
Prototypes can carry more risk than systems with active users. Criticality matters more than the size of the code change. A one-line contract change can cost more than a messy internal module.
Good teams write these limits down. They write SLAs for services and clear acceptance criteria for behavior. Then they test against both. "AI slop" is not an argument. Name the defect, its impact, the check that should catch it, and the alternative to doing the work. Without that context, you cannot tell a useful compromise from a team that does not know what it is doing.