Most AI coding conversations begin with a prompt. The strongest ones begin with a codebase.

A general-purpose model can explain a language feature, draft a function, or suggest a migration. But it does not automatically understand why your checkout flow treats a failed payment differently from a cancelled subscription, why an “active” customer may still be ineligible for a feature, or which reporting numbers finance considers authoritative. Those rules are often encoded across types, tests, database schemas, naming conventions, and the unglamorous comments around edge cases.

That is why code should be treated as the AI’s business tutor. The prompt sets the assignment; the repository supplies the vocabulary, constraints, and evidence needed to do useful work safely.

Business context is already hiding in technical artifacts

Teams sometimes describe business knowledge as something that lives exclusively in product documents or in the heads of experienced colleagues. Those sources matter, but working software also contains a substantial portion of that knowledge.

Consider a service that grants access to a paid capability. A model asked to “add an entitlement check” might produce a plausible condition based on a subscription status. A model shown the relevant domain types, policy tests, event handlers, and existing authorization checks has a better chance of recognizing that access depends on several factors: account status, billing grace periods, plan limits, feature flags, and organization-level exceptions.

The difference is not merely more context. It is the difference between generating code that looks reasonable and proposing a change that fits the operating model of the system.

Useful business signals in a repository often include:

• Domain types and enums that define the language of the product.
• Tests that document expected behavior at boundaries and failure cases.
• Database constraints and migrations that reveal what the system considers valid.
• API contracts that show promises made to clients and other services.
• Audit fields, event names, and error messages that expose operational concerns.
• Configuration and deployment definitions that reveal runtime dependencies.

None of these artifacts is perfect on its own. Together, they form a practical curriculum for an AI assistant.

Give the model a bounded learning path

“Read the whole repository” is rarely a good instruction. It can create noise, expose irrelevant material, and make it harder to verify the assistant’s reasoning. Instead, assemble context around a specific decision.

Suppose a team needs to add a rule: accounts on a trial may export reports only when an administrator enables the capability. A focused context package might include the account model, the feature-flag abstraction, the export endpoint, related authorization tests, and the API response schema. It should also state what is unknown or undecided.

That last point matters. AI systems tend to complete patterns. If the business rule is incomplete, ask the model to identify missing decisions rather than silently choose one.

Use the codebase to teach established rules, and use explicit questions to surface rules that have not yet been made.

Ask for an evidence-based reading before asking for a patch

A productive workflow has two phases. First, ask the assistant to explain the current behavior and cite the supplied artifacts. Then ask it to propose a minimal change. This makes assumptions visible before they become implementation details.

Based only on the supplied files:
1. Describe the current export authorization rule.
2. List each condition and the evidence for it.
3. Identify ambiguities or conflicting signals.
4. Propose the smallest change for the new trial-account rule.
5. List tests that should pass, fail, or be added.

This request encourages a distinction that is easy to lose in fast-moving work: observed behavior is not the same as intended policy. The model can summarize the former; a responsible human still confirms the latter.

Use tests as a conversation about consequences

Tests are especially valuable because they turn business language into executable examples. A well-named test can explain more than a paragraph of generic documentation:

it("denies trial exports until an administrator enables exports", () => {
  const account = trialAccount({ exportsEnabled: false });
  expect(canExport(account, adminUser())).toBe(false);
});

The test does not answer every policy question. It does, however, establish a concrete consequence. When asking an AI to modify behavior, provide adjacent tests and ask it to enumerate the cases affected. This is often where hidden requirements emerge: What happens when the flag service is unavailable? Does an already-running export continue? Is the setting scoped to an organization, a workspace, or an individual user?

For changes with meaningful risk, ask the assistant to produce a decision table before implementation. A short table of inputs and expected outcomes is easier for a product owner, reviewer, or support lead to inspect than a large patch.

Build retrieval around meaning, not volume

As repositories grow, a developer cannot manually attach every relevant file to every request. This is where retrieval and tooling help, but the goal is not maximal context. It is relevant context with clear provenance.

Good retrieval starts with the product language used in the task: concepts such as “invoice,” “workspace,” “approval,” “retention,” or “entitlement.” Search for those terms, then expand through call sites, type references, tests, and schemas. Prefer authoritative definitions over duplicated helpers or stale examples.

A useful context selection order is:

1. Find the domain model and public contract.
2. Find the decision point where behavior is enforced.
3. Find tests for normal, denied, and error paths.
4. Find persistence or event artifacts that constrain the change.
5. Include only the operational configuration needed to understand deployment behavior.

If your AI tooling can attach repository context automatically, establish boundaries. Exclude secrets, credentials, customer data, and unrelated projects. Treat access control for AI context with the same care applied to source control and production observability.

Make uncertainty an explicit output

The most useful AI assistants are not the ones that always sound certain. They are the ones whose output makes verification efficient.

Ask for assumptions, confidence boundaries, and alternatives when the task touches money, permissions, compliance, destructive actions, or customer communication. Ask the model to distinguish facts found in the code from inferences it made. Then require normal engineering controls: review, tests, static analysis where applicable, and a deployment plan appropriate to the blast radius.

For example, a change to a billing rule may compile and pass unit tests while still being unsafe to deploy if it changes historical records or causes retries to create duplicate charges. The assistant should be prompted to inspect idempotency, migration safety, rollback behavior, and failure handling—not just the happy path.

Turn every change into better teaching material

The long-term opportunity is not simply to make an AI better at writing code. It is to make the system easier for everyone to understand.

When a rule is clarified, encode it in a test, a type, a validation rule, or a concise decision record near the code that enforces it. When terminology is confusing, improve names. When two services disagree about a concept, resolve the contract rather than teaching the assistant both incompatible versions.

Over time, this creates a virtuous loop: clearer software gives AI assistants better evidence; better-assisted changes make the software clearer. The prompt remains important, but it should not carry the entire burden of explanation.

AI can generate syntax in seconds. The durable advantage comes from teaching it what the syntax is for. When your code expresses the business clearly, it becomes more than an implementation: it becomes a tutor that helps both humans and machines make better decisions.