I'm a QA Engineer building an AI "Logic Auditor" to stop PRD rework. My first launch!
Hey IH,
I've spent my career in QA, and I've seen the same story a hundered times. A PM writes a PRD, Dev builds it, and then we find a logic contradiction during testing.
The result? Wasted weeks and "rework tax".
I decided to stop complaining and build a solution.
The Tool: PBrain
PBrain uses AI to audit PRDs and change request.It catches contradictions(Feb 31st in a to-do app kind edge cases) and generates Gherkin Acceptance criteria befor a developer even opens their IDE.
The Milestone:
I just updated my LinkedIn to "Founder"(scary!) and opened my "Egg Plan" for the first 25 founding users.
I'm looking for feedback from fellow builders. Does this " Logic Auditor" concept resonate with you? How do you handle requirement gaps in your own projects?
Waitlist:https://pbrain-peach.vercel.app/
Happy New Year's Eve, everyone. Let's build something great in 2026
Congrats on the first launch 👏 — and on updating LinkedIn to “Founder”, that’s a big step.
The idea definitely resonates. Catching logical contradictions before dev starts is a real pain point.
Quick question:
How are you planning to help users act on the audit results — especially when PMs and devs interpret requirements differently?
Curious how you're thinking about that.
Honestly, this is my first piece of genuine feedback so Thank you!
My background is in QA, so I’m building PBrain to be a PRD that's 'Test-Aware' . To answer your question on the interpretation gap:
The 'Contract' Approach: Instead of just writing prose, the tool generates Gherkin Acceptance Criteria (Given/When/Then) alongside the requirements. It’s much harder for a PM and Dev to interpret 'When I click X, Y happens' differently than a vague paragraph.
Flagging the 'Why': When the auditor finds a contradiction, it doesn’t just say 'this is wrong.' It explains the technical risk (e.g., 'Requirement A creates a race condition with Requirement B'). This gives the PM and Dev a concrete logical point to discuss rather than a 'he-said-she-said' debate.
Comparing the 'How': At times, in my experience I have noticed how we are stuck between choosing the best way to approach a scenario be it technical or simply design. One of the modes, offered by my tool helps in hinting which approach is best for which kind of scenarios. This might allow the PM and Dev to sit down and say 'Path A' has these risks, 'Path B' has this. It would help in bringing clarity and confidence for making a decision.
The Goal: It’s about moving the 'QA mindset' to the very first step. If we agree on how we will test the feature before we code it, the interpretation gap shrinks significantly.
I'm still figuring out the best way to present these so they trigger a healthy conversation. I'd love to know, In your experience how do you settle it when a requirement feels 'unfeasible' or logically broken?