How do you catch bad requirements or architectural contradictions before implementation starts?
I've been thinking a lot about how much of our software quality process happens relatively late.
We review pull requests, run static analysis, write tests and maybe check architectural rules in CI. But by that point, an important decision has already been made: we decided what to build.
In larger or long-lived projects, I've repeatedly found the earlier stages more interesting:
- Does a new requirement contradict an earlier decision?
- Does it implicitly violate an architectural constraint?
- Is an important edge case missing?
- Does it conflict with something another team implemented six months ago?
- Is the proposed change locally reasonable but slowly pushing the system away from its intended architecture?
I'm currently building a side project called BreakMySystem around this idea. It combines adversarial requirement review with architecture-drift detection, with the goal of finding these problems before or during implementation rather than only reviewing the resulting code.
But I'm more interested in how other teams solve this today than in pitching the tool.
For people working on larger or older codebases:
Where in your development process do you catch these kinds of problems?
Architecture reviews? ADRs? Senior engineers knowing the system? Jira discussions? PR reviews? Automated tooling? Or, realistically, mostly when something eventually breaks?
I'd also be interested in talking to a few experienced developers, architects or tech leads about this for ~20 minutes. I'm specifically looking for critical feedback and real-world experiences rather than potential customers.
If you've dealt with this problem, feel free to comment or DM me.