GOLDEN RULES FOR BUILDING WITH A.I.

Golden Rule 1 · DO NOT MAKE A.I. GUESS

If you already know something important about the product, tell A.I.

If there is a source that can answer the question, provide the source.

If there is an industry standard, identify the standard.

If there is a hard requirement, state it clearly.

If something must not change, make it a hard rule.

Do not leave important decisions open and expect A.I. to somehow know what you meant.

The principle: Reduce assumptions wherever possible. A.I. should reason deeply about the product, but it should reason from a strong foundation instead of inventing the foundation while it builds.

Open-book answer:Do not make A.I. guess. Give it the important facts, sources, standards, hard requirements, and non-negotiable rules so it can reason from a strong foundation instead of inventing missing decisions.

Golden Rule 2 · FIND THE REAL TOP EXPERTS

Do not simply tell A.I.: “Act like an expert.”

Research the actual people who are recognized as top experts in the field. Use their real names.

Find out:

• who they are
• what they specialize in
• what they are known for
• the research, methods, principles, standards, or practices publicly associated with their work
• which part of your product matches their actual expertise

Then use those named experts as the quality standards for the product.

Example: If you are building a fitness product, do not create one generic “fitness expert.” Research strong people in exercise science, strength training, nutrition, sports medicine, physical therapy, behavior change, product design, user experience, privacy, and security. Different parts of the product should be held to different expert standards.

The principle: Do not invent what world-class means when you can research the people who already represent world-class standards in that field.

Open-book answer:Research the real top experts in the field by name, learn what each is known for, and use their publicly documented research, methods, principles, and standards as quality benchmarks for the part of the product that matches their expertise.

Golden Rule 3 · BUILD AN EXPERT TEAM — AND GIVE EVERY EXPERT A JOB

Once the experts and disciplines have been identified, create the A.I. expert team.

Every specialist must have a clearly defined responsibility. Do not create a group of experts who all comment on everything.

Each expert should have:

ROLE

Who this expert represents inside the build.

MISSION

What this expert is responsible for accomplishing.

SOURCE OF TRUTH

What information, research, standards, and approved product decisions this expert must follow.

WHAT YOU OWN

The exact part of the product this expert controls.

WHAT YOU DO NOT OWN

Areas this expert must not change or override.

REQUIRED OUTPUT

What this expert must produce.

HANDOFF

Who receives the work next.

PASS / FAIL STANDARD

What must be true before that expert's part is considered complete.

The principle: Expertise must have boundaries. A security expert should not redesign the user interface. A user-experience expert should not make medical decisions. A database specialist should not rewrite the business model. Every expert owns their lane.

Open-book answer:Build an A.I. expert team with clearly defined roles, missions, sources of truth, ownership boundaries, required outputs, handoffs, and pass/fail standards so each expert owns only their lane.

Golden Rule 4 · ASK EVERY IMPORTANT QUESTION BEFORE YOU BUILD

Before A.I. starts building the product, have it determine: What are all of the important questions that must be answered to build this product correctly?

Do not settle for a few obvious questions.

Have the expert team examine the product from every important angle and develop the questions that a serious professional team would need answered before development.

Questions may involve:

The exact questions will depend on the product.

The principle: Find the unknowns before the unknowns become bugs.

Open-book answer:Before building, have A.I. identify every important question that must be answered about the user, problem, workflows, safety, data, privacy, business rules, design, accessibility, authentication, payments, APIs, failures, mobile, deployment, testing, security, legal needs, industry requirements, and future expansion.

Golden Rule 5 · HAVE THE EXPERTS ANSWER THE QUESTIONS

Do not stop after generating the questions.

Assign each question to the expert whose specialty actually covers it.

Then have A.I. develop the strongest supported answer using:

• the named expert's publicly documented standards
• reliable research
• industry standards
• the product's goals
• the user's requirements
• the approved hard rules
• the other approved foundation decisions

If evidence is missing, A.I. should identify the missing information instead of pretending it knows.

The principle: The foundation should contain expert answers, not assumptions.

Open-book answer:Assign each important question to the expert whose specialty covers it and have A.I. produce the strongest supported answer using named-expert standards, reliable research, industry standards, product goals, user requirements, hard rules, and approved foundation decisions.

Golden Rule 6 · USE THE APPROVED ANSWERS AS THE PRODUCT FOUNDATION

Once the important questions have been answered and approved, those answers become part of the official product foundation.

The build should now follow that foundation.

A.I. should not quietly change those decisions later because it found another way to build something.

If a future requirement conflicts with the foundation, identify the conflict. Then decide whether the foundation itself should be updated.

Do not allow the build to drift silently.

The principle: Think first. Approve the foundation. Then build from it.

Open-book answer:Once the important questions and answers are approved, use them as the official product foundation and do not let A.I. silently change those decisions later; identify and resolve any conflict before changing the foundation.

Golden Rule 7 · CREATE HARD RULES

Some product requirements are preferences. Others are non-negotiable. Separate them.

Hard rules should cover anything that must remain true throughout the build.

Examples:

• A working feature must not be removed.
• A.I. must not invent missing user information.
• A particular database must remain separate from another product.
• A user must never see internal code.
• A specific workflow must remain intact.
• Private information must never appear in an error message.
• An existing production feature must not be changed while fixing an unrelated feature.

The principle: If something cannot be violated, do not leave it as a suggestion. Make it a hard rule.

Open-book answer:Separate preferences from non-negotiable requirements and make anything that must remain true a hard rule so A.I. cannot treat it like an optional suggestion.

Golden Rule 8 · DEFINE WHAT “FINISHED” MEANS BEFORE THE BUILD

Do not let “it looks good” become the definition of complete.

Define the conditions that must be satisfied.

A serious product may need to prove:

• the main workflow works
• authentication works
• data saves correctly
• permissions work
• mobile rendering works
• APIs work in production
• failure states work
• Retry works
• navigation works
• security checks pass
• accessibility is acceptable
• deployment works
• previous working features still work

The principle: A product is finished when the evidence says it is finished.

Open-book answer:Define what finished means before building by listing the evidence the product must prove, including its main workflow, authentication, data, permissions, mobile behavior, APIs, failure states, Retry, navigation, security, accessibility, deployment, and regression.

Golden Rule 9 · BUILD A.I. AUDIT AGENTS — DO NOT LET THE BUILDER AUDIT ITSELF

Do not rely on the same A.I. process that built the product to decide whether the product is correct.

Build separate A.I. Audit Agents whose job is to inspect the product independently.

Your Audit Agent should have its own:

ROLE

Act as an independent auditor, not the builder.

MISSION

Find defects, missing requirements, broken workflows, weak decisions, inconsistencies, risks, and anything that does not meet the approved product foundation.

SOURCE OF TRUTH

Use the approved foundation, hard rules, expert standards, requirements, and completed build as the standard.

WHAT THE AUDIT AGENT MUST CHECK

Functionality, user workflow, mobile behavior, visual rendering, authentication, permissions, APIs, data saving, security, accessibility, error states, Retry behavior, deployment, performance, regression, and industry-specific requirements.

HARD BOUNDARIES

The Audit Agent does not quietly fix its own findings. Its job is to identify and prove the problem.

EVIDENCE REQUIRED

Do not fail something because it “looks suspicious.” Show the evidence.

PASS / FAIL RULES

Define exactly what must be true for the product to pass.

BUILD A SEPARATE FIX AGENT

After the Audit Agent finds a confirmed problem, use A.I. to build a separate Fix Agent.

The Fix Agent should receive the confirmed finding, find the root cause, repair only what needs to be repaired, preserve everything already working, avoid unrelated changes, document what changed, and return the product for another independent audit.

The Fix Agent should not declare the product passed. The Audit Agent decides whether the fix actually worked.

USE THE A.I. AUDIT LOOP

BUILD → AUDIT AGENT → FIX AGENT → RE-AUDIT → REPEAT UNTIL PASS

If the re-audit finds another confirmed problem, send it back to the Fix Agent, then audit again. Continue until the Audit Agent reports no confirmed failures under the approved pass/fail standard.

The principle: Do not ask A.I. to simply “check its work.” Build independent A.I. agents whose specific jobs are to audit, fix, and verify the product.

Open-book answer:Build separate A.I. Audit and Fix Agents. The Audit Agent independently proves defects against the foundation and pass/fail rules; the Fix Agent repairs confirmed root causes without unrelated changes; then re-audit until PASS.

Golden Rule 10 · FIX THE ROOT CAUSE

A visible problem may only be the symptom.

Do not automatically patch what appears on the screen.

Find out why it happened.

Ask:

• What actually failed?
• Where did it fail?
• What evidence proves that?
• What else depends on that component?
• Could the same defect appear somewhere else?

Then fix the underlying cause.

The principle: Do not make the symptom disappear while leaving the defect alive.

Open-book answer:Fix the root cause, not only the visible symptom. Determine what failed, where it failed, what evidence proves it, what depends on it, and whether the same defect can appear elsewhere before repairing it.

Golden Rule 11 · REGRESSION-TEST EVERY IMPORTANT FIX

A fix can repair one feature while damaging another.

After meaningful changes, test what was fixed and what was already working.

Do not assume that because Feature A now works, Features B through F remained untouched.

The principle: A fix is not complete until the surrounding system still works.

Open-book answer:After every important fix, regression-test both what changed and what was already working so one repair does not silently break another part of the product.

Golden Rule 12 · NEVER HIDE USEFUL ERROR INFORMATION

The user-facing message should remain clean.

But clean messaging must never destroy the safe information needed to find a failure.

The friendly message is for the user. The safe reference is for troubleshooting.

Preserve specific structured error codes when they exist. An error code is a short label that identifies the kind of failure. Preserve the real HTTP status when it is available. An HTTP status is the number a web request returns, such as 404, 500, or 502, that helps show what happened. Never replace useful error information with generic wording.

Never expose passwords, keys, tokens, private user information, raw stack traces, or other sensitive information. A raw stack trace is the detailed technical developer readout showing where software failed; keep that private while preserving a safe reference for troubleshooting.

The principle: Make errors understandable without making them invisible.

Open-book answer:Keep user-facing error messages clean, but never hide or erase useful safe error codes and HTTP status. Preserve structured codes and real status when available without exposing secrets, private data, or raw stack traces.

Golden Rule 13 · NEVER CLAIM SOMETHING WAS TESTED WHEN IT WAS NOT

There is a difference between:

Keep those differences.

If an environment does not allow a test to run, do not call it PASS.

If production has not been checked, do not say production works.

If evidence is unavailable, say the result is unverified.

The principle: Evidence beats confidence.

Open-book answer:Never call something tested or working unless the evidence proves it. Keep PASS, FAIL, NOT TESTED, SKIPPED, and UNVERIFIED separate.

Golden Rule 14 · DOCUMENT IMPORTANT PROBLEMS AND FIXES

When a difficult problem is solved, do not throw away everything you learned.

Document:

• what failed
• what users saw
• what the real root cause was
• what theories were ruled out
• what finally fixed it
• what should be tested next time
• what regression tests should remain
• what should never be repeated

Then package that knowledge so it can be reused.

The principle: A solved problem should make the next product smarter.

Open-book answer:When a difficult problem is solved, document what failed, what users saw, the real root cause, ruled-out theories, the final fix, future tests, regression checks, and what should never be repeated.

Golden Rule 15 · TURN DOCUMENTATION INTO REUSABLE A.I. KNOWLEDGE

Important documentation can become much more than a report.

Package it so a new A.I. conversation can read it and immediately inherit the lessons.

A package may contain:

• root-cause reports
• known-good architecture
• hard rules
• testing standards
• decision trees
• bug histories
• expert standards
• release procedures
• regression requirements
• ready-to-use instructions

That package effectively becomes a reusable specialist for future builds.

The principle: Do not make every new A.I. conversation start from zero.

Open-book answer:Package important documentation so a new A.I. conversation can inherit root-cause reports, known-good architecture, hard rules, testing standards, decision trees, bug histories, expert standards, release procedures, regression requirements, and ready-to-use instructions.

Golden Rule 16 · CARRY PROVEN KNOWLEDGE FORWARD

When something has already been researched, decided, tested, and approved, carry it forward.

Do not repeatedly rediscover the same information.

Do not make learners or builders reconstruct foundations that already exist.

New products should benefit from what earlier products taught you.

The principle: Your development system should become smarter every time you build.

Open-book answer:Carry forward knowledge that has already been researched, decided, tested, and approved so new products and new A.I. conversations do not repeatedly start from zero.