AI has made software development dramatically faster and cheaper. You can now build a working MVP in a week — sometimes in days — and validate an idea before committing real money to it. But that speed brought a new problem: keeping control of a process that now moves faster than the thinking behind it.
This article is about a client who didn’t sit on the sidelines of that shift and tried to push AI as far as it would go.
Even with AI on hand, there’s a question it can’t answer for you: what exactly do I want to build? How should the product look? What will I run into, and what contradictions am I sitting on without knowing it? Today’s ChatGPT or Claude is a general-purpose tool — limited autonomy, still leaning on you to drive every step.
So the client asked us to build a system that would take a business idea and force it into a clear structure — acting proactively, surfacing problems early, not waiting to be asked. Not another AI assistant, but a proactive agent that walks you from a two-sentence sketch to a structured spec you can hand off to be built. And having shipped a lot of products, the client already knew which problems always show up at this stage, and what the agent needed to do about them.
The Gap
Between that sentence and the first working screen sits the part nobody likes.
Discovery calls, requirements docs, entity diagrams, user-story spreadsheets, the estimation meeting where a senior dev stares at the ceiling and says “two weeks, maybe three, depends.”
This is where ideas leak. The founder knows what they want, the builder knows how to build. The layer translating between them is slow, expensive, and loses things along the way.
For decades that layer has been people — business analysts, PMs, consultants who sit with a non-technical person and turn fog into a spec.
BR Engine — Business Requirement Engine — was a bet that you could replace that layer with a machine. A thing that interviews you and structures the idea the way a good analyst would — built for a world where developers code with AI.
The Bet
A lot of AI tools are a chat box with a system prompt taped on — you talk, it talks, you get a wall of text back. BR Engine refuses to be that. It runs a process on you, the way a consultant runs a process on a client who doesn’t yet know what they’re asking for.
Instead of helping only when asked, BR Engine is aggressively proactive: it pushes you toward a coherent business idea from the start, drawing on everything the model was trained on.
Almost always, when we add a new element to an idea, we don’t immediately see that it touches other elements — and can even make the whole idea unviable.
Decisions like that, made early, tend to cost the most: we end up “fixing” them late in development, which is always expensive.
BR Engine is built to catch these problems on the spot and block further development until they’re resolved. And it doesn’t dump the problem back on you — it offers at least a few possible solutions.
Say the product already promises buyers they’re charged only once they confirm the item arrived — a core trust feature the whole marketplace is built on. A couple of days later the client brings a new idea: pay sellers the moment an order is placed, to attract more of them. Saved as-is, the two rules quietly contradict each other — the platform would be paying out money it hasn’t collected yet and eats the loss on every dispute or no-show. The client never meant to break anything; the conflict only exists in how the two rules meet. BR Engine catches it before it’s saved and lays out the options: drop the instant payout, front the cash and price the risk in, or allow instant payout only for sellers above a trust threshold.
The Structure
Most digital products look alike under the hood. There’s a server side and a front end the user sees. The server side usually talks to a database that stores data in some structured form; the front end is a set of screens the user moves through.
From that, you can pull out a handful of abstractions and turn them into data structures: entities, screens, user flows, test flows, and so on.
The structure shouldn’t depend on the tech stack — the stack is an implementation detail, irrelevant to what you’re actually trying to achieve.
For example, the moment you say the app needs a shopping cart, you’re already implying data structures with a clear shape:
- Entities: user (name, email), item (name, price, description)
- Flow: user browses catalog → adds item to cart → pays for order
- Screens: catalog screen, item screen, payment screen.
It doesn’t matter how those entities are expressed or where they’re stored — Postgres, MongoDB — or what renders them — React, Angular.
So as the idea takes shape, BR Engine turns scattered thoughts into a clearer definition and saves it into these structures automatically.
This matters because of the known limits of LLMs — hallucinations, context windows, and the rest. A structured form keeps the model focused and gives it a clear picture of what we’re working on right now.
From Structure to Implementation
When you work with modern AI coding agents like Claude Code or Cursor, it’s critical to know exactly what you want to build.
Because these models were trained on a huge slice of the internet, a vague prompt gets flattened into mediocre code — which usually isn’t what you set out to build in the first place.
Since BR Engine already turns the idea into a structured form, you can just hand that structure to the agent. Much of the vagueness is gone before the model starts, and the output is better for it.
At this stage you’re free to pick any stack you want. Any framework or database can consume this structured description and express it in technical terms.
Problems
There’s still no magic tool that solves every problem, and ours is no exception. Most of its weaknesses come from the current state of AI and of software development in general.
Limited Context and Hallucinations
Every AI tool today is prone to hallucinations and context loss, and ours is no exception. The further a project goes inside BR Engine, the larger the context grows. Even with modern techniques in place, you can’t fully eliminate the problem — so while BR Engine handled and verified information correctly most of the time, we still had to validate its output, especially in the later stages.
Changes
You almost never reach a point where all business requirements are frozen and fully defined. Even during implementation, individual pieces of logic shift, and that forces you to revise part of the spec — or rewrite it entirely. This is where BR Engine starts to struggle: a change that’s trivial in essence can leave the structure looking completely different from the one you’re currently building.
External Context
Even though everything now lives in digital form, we still talk to colleagues and owners out loud and reach new decisions almost every day. BR Engine can’t know about those offline conversations, so it can’t keep checking and correcting the idea against them — and we don’t always manage to sync those decisions back into it, automated or not.
So BR Engine is strong at the start of a project, but later on a gap inevitably opens between the idea it captured up front and how that idea actually evolved through development.
Results
Despite the problems, we still got solid results.
Faster Idea-to-Implementation
With BR Engine, the client could shape and structure ideas faster and hand them straight to us. Before, shaping an idea into something we could actually build meant at least two months of work and constant client calls. Now the client can structure the idea in about two days and hand it straight to us.
Pinned-Down Requirements
It used to be hard to hold a whole workflow or set of requirements in one place. With BR Engine we got a clear statement of what needed to be done, which cut the risk of missing something the client asked for down to a minimum.
Technical Implementation
Modern development is hard to imagine without AI — but it’s also hard to give an AI the full picture of what needs building. Too often you’re re-explaining how individual parts work just to rebuild context. With BR Engine we always had clear, well-formed requirements on hand, and the coding system — Cursor, in our case — always had access to them.
What’s Under the Hood?
We built BR Engine on Node.js and TypeScript. But since AI is the core of the tool, the most important decision was how to work with it.
We went with LangChain — an open-source framework that gives you convenient abstractions for building AI agents.
Because we were dealing with a huge context, we used RAG so the model searches only for what it actually needs, instead of drowning the context in junk.
We also leaned on a sub-agent approach: separate sub-agents handle narrow, specialized jobs — finding contradictions, rewriting the structure, and so on.
The front end is deliberately minimal — we used Next.js.
Summary
We met the client’s request and built a system that helps them turn ideas into working prototypes quickly — while our team got clearer technical specs as documentation, which sped up implementation on our side too.
And along the way, BR Engine surfaced a number of new problems that we’ll be working to solve next.