Freeze the data model before an AI coding sprint

An AI coding sprint goes wrong when the model invents records as it invents screens. You then spend the next week reconciling two ideas of a customer. Freeze the data model first, then let the assistant fill in the UI around it.

1. 01

   Suppose you are adding invoicing to an existing client portal. Write the objects before the prompt: Client, Invoice, LineItem, Payment. For each object, name the required fields, who may create or edit it, and which identifier other records must use. If a payment must point at one invoice, say so. If a client can have many invoices, say so. Put this in the repository as a short schema note the assistant is told not to change.

2. 02

   Give the sprint one workflow. “A staff user creates an invoice for an existing client and marks it paid” is a workflow. “Build billing” is not. The assistant can generate forms and lists for that path. It should not add subscriptions, tax engines or a second customer table because a tutorial mentioned them.

3. 03

   After the first generated slice, review the migrations and the API before reviewing colours. Check that records still use the identifiers you froze, that a second staff user cannot read another firm’s invoices, and that repeating the create action does not insert two invoices. If the assistant opened a new collection, stop and revert that part. A pretty screen on a forked model is a demo, not progress.

4. 04

   Keep a test around the boundary you care about. Creating an invoice for client A must fail when the session belongs to client B’s staff. Run that test after every generation pass. If the test cannot be written because the model is still moving, the sprint is too early.

5. 05

   Measure the slice by whether a person can complete the frozen workflow on staging, not by how many files the assistant touched. When the workflow holds, unlock the next object on purpose. That is slower than prompting “build the rest”, and it is why the codebase remains one product.