Write the Problem Before You Write the Code

A client calls on a Monday. They want guest checkout. "Users are dropping off at the account creation screen," they say. "Can we let them buy without registering?"

The developer says yes, takes notes, ends the call. By Tuesday morning, they have a task in the sprint board: "Add guest checkout — allow purchases without account." By Tuesday afternoon, they have an AI agent running. By Wednesday, there's a working implementation.

It's only on Thursday, when the client asks about returns for guest orders, that the conversation surfaces the constraint nobody wrote down: guest returns are handled by the support team via order ID plus email. No account login. That means guest orders need to be readable by orderId plus email without authentication — which means the access control rules need to change in a very specific way — which means the schema needs to accommodate a nullable userId alongside a guestEmail field — which means the original implementation, which stored guest orders in a separate guest_orders collection, is wrong in a way that wasn't obvious until someone asked about returns four days later.

The developer goes back to the AI. The AI revises the implementation. The PR is reopened. The test suite is partially rewritten. Two days of work, undone and redone, because the conversation that surfaced the constraint happened after the code was already built.

---

This is the most common failure in AI-assisted development, and it's not really a technical failure. It's a sequencing failure. The information needed to build the right thing existed on Monday. It just wasn't written down before Tuesday's code ran.

A business intent document exists to prevent exactly this. Not a spec, not a requirements file — those come later, and they're more specific. A business intent is a pre-code conversation made permanent. It captures the problem in the client's own terms, the constraints the implementation must respect, and what success actually looks like for the user. It's written before requirements are drafted. Before the ADR is considered. Before the AI opens a file.

For the guest checkout feature, a well-formed business intent includes:

Problem: 34% of users abandon the cart at the account creation screen. We are losing customers who want to buy once and are not ready to commit to an account.

Success looks like: A user can complete a purchase without creating an account. Post-purchase, they are offered account creation with their order details pre-filled — not required, genuinely optional.

Business constraints:

• Guest orders must appear in the admin order management panel identically to registered-user orders. Operations cannot have two workflows.
• Returns and refunds for guest orders are handled via order ID + email, not account login. This is a legal requirement in some markets.
• Marketing cannot email guest customers unless they explicitly opt in at checkout. Non-negotiable for GDPR compliance.

User expectations:

• "Continue as guest" must be at least as prominent as "Sign in." It cannot be a small link below the sign-in form.
• Guest users expect a confirmation email immediately — not eventually.

Reading this document, the AI — and the developer, and the reviewer — knows things it could never have inferred from "add guest checkout." It knows that a separate guest_orders collection is incompatible with the operations requirement. It knows that the access control rules must allow reads by orderId plus email without an authenticated session. It knows that the marketing email opt-in is non-negotiable. It knows that "Continue as guest" can't be a small secondary link.

None of those constraints come from the code. They come from the business. And they're only useful if they're written down before the code runs.

---

The business intent document does something else that's easy to underestimate: it forces the right conversation.

When a developer sits down to write the problem statement — not the solution, the problem — they often discover they don't fully understand it yet. They know the client wants guest checkout. But do they know the 34% abandonment figure? Do they know which markets have the legal requirement for order ID plus email returns? Do they know the GDPR constraint on marketing emails? Do they know the ops team's single-workflow requirement?

These questions come out when you try to write the problem down. The business intent document is structured specifically to surface them: four sections — Problem, Success looks like, Business constraints, User expectations. Each section asks a question the developer has to answer before they can fill it in.

If they can't answer it, they call the client back. Before any code runs.

That call is fast. Fifteen minutes. Maybe thirty. The information it surfaces is the information that would have taken a full sprint cycle to discover if it came out during code review instead.

The cost of writing a business intent: two hours, including the client call. The cost of missing a constraint from the business intent: depends when you find it.

Found at planning: an hour to update the document. Found during generation: a day to rework the implementation. Found at code review: a full rework cycle, PR closed and restarted. Found in production: an incident, a hotfix, a post-mortem, and a conversation with the client you don't want to have.

The number compounds dramatically the later it appears. The constraint doesn't change — it was always true that guest returns use orderId plus email. The only thing that changes is when you know about it.

---

There's a version of this failure that's subtler and more common. The constraint exists in the business intent. It just wasn't clear enough to produce the right implementation.

"Guests can view their order" is different from "guests can view their order by orderId plus email without an authenticated session." The first is in the requirements. The second is what the access control rule needs to implement. Writing the constraint precisely enough that an AI — and a junior developer, and a reviewer who wasn't on the Monday call — can implement it correctly is the actual work of the business intent.

This is not about documentation for its own sake. It's about the specificity of the constraint being high enough to produce the right implementation without a human in the room to clarify it. An AI that reads "guest orders must be viewable by the guest" will make a reasonable interpretation. An AI that reads "guest order reads are allowed by orderId plus guestEmail pair — the guest does not need an authenticated session" will make the correct implementation.

The difference is one sentence. It's in the business intent, or it's discovered in an access control rule bug six months after launch.

---

The business intent is the first gate in a sound AI-assisted process. Scope is locked by a human before generation begins. Not locked in someone's head — locked in writing, reviewed, and agreed. Everything downstream — the requirements, the architectural decision record, the implementation plan — is derived from it. The files that get touched, the services that get involved, the constraints that govern every decision: all of it traces back to one document written before any code ran.

The question it answers is deceptively simple: what problem are we actually solving?

You'd be surprised how often that question hasn't been answered before someone opens an AI chat window.

---