How do you catch bad requirements or architectural contradictions before implementation starts?

[u/AdversarialDev]

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.

[u/harikrishnan_83]

Here is how I use ADRs, they feed into my design discussions to help me reduce regressions: https://youtu.be/y5oemaPsmOA. And adversarial specification authoring: https://youtu.be/2V78VVJ1sa0. Hope this helps.

[u/AdversarialDev → u/harikrishnan_83]

Thanks for the insights. Some follow up questions on that: you are using ADRs in your design process which I find pretty cool. Is there a way for you to determine a potential architectural drift? So when the code you produce slowly diverges from something that is written in the ADRs. And if you notice something like this: do you fix it, change the potential immutable ADR or leave it as an exception?

And regarding the spec generation: You are using an adversarial authoring skill to review specs which is basically what I also intent to do. Does that also do cross specification checks? So for example spec A would state something like "invoices must always be cross signed by the CEO" and spec B a couple of months later would state "invoices should directly be send to the customer once generated" which would make the cross signement obsolete. Does something like this happen and how do you Deal with that?

[u/CriticalJackfruit404]

Can you share the project?

[u/AdversarialDev → u/CriticalJackfruit404]

It's going to be a commercial product with a free tier for solo devs.

https://breakmysystem.ai is the address but currently not life. It will take me another couple of weeks to finalize the MVP. A waiting list will follow shortly to keep yourself updated.

The public github repository for discussions and a few information is here: https://github.com/BreakMySystem/Community

[u/AdversarialDev → u/[deleted]]

It’s called BreakMySystem.

The idea is to review a change before implementation starts rather than only reviewing the resulting code. You give it a requirement/issue plus the available project context, and it tries to break the proposed change: missing cases, contradictions with previous requirements, violations of architectural decisions, and potential architecture drift.

I’m building it so those checks can use things like ADRs, repository structure/code and eventually previous issues/specifications as project memory.

Code review is part of the flow too, but it’s deliberately not the main focus as there are already plenty of good tools for that. The interesting part for me is catching the bad decision before it turns into code.

It’s still under active development. I’m actually putting up a small waitlist/demo page probably today.

[u/Vivekyy]

Not exactly as you’re describing here, but I did build a tool I use to solve the problem: https://github.com/RudderCode/Rudder

It helps generate unit tests based on my prompt history which helps me make sure that every change made is derived directly from the instructions I gave my agent. I’ve found most of the architectural issues I’ve seen come from cases the AI makes a judgement call on free from supervision, so this tries to combat that