Constraints are how AI stays useful

I use models every day for the work they are actually good at. Crossing a rename through a codebase. Drafting the first pass of a migration. Explaining a module I did not write. Turning a decision into a document while the decision is still fresh. I do not hand them the architecture. They are confident in both roles. Only one of those confidences is earned.

The failure mode is specific. The generated code typechecks, the screen renders, and a boundary you spent a year defending has been folded into a single file because that was the shortest path to a green check. Nothing in a model's training tells it that the boundary was the point.

Make the wrong shape expensive

A platform keeps generated code honest the same way it keeps human code honest. The right path has to be the one with the least resistance. A model is an extremely fast follower of whatever is easiest.

Typed clients at the edge do more than please the compiler. If the API is a function with a return type, there are fewer places to invent a fetch and a hand-written response. If the API is a URL and a hope, the model will build a third client and it will look plausible.

A design system with a small public surface gets reused. Four button variants and a documented way to compose them will show up in the diff. A folder of examples with no contract will be extended, and the extension will ship. Review can see a fifth variant. Review cannot reliably see thirty class names that almost match the system.

Tests should describe the behavior you care about. A test that says what the screen must do will drag generated code back toward the requirement. A snapshot of whatever was emitted only freezes the accident in place and congratulates you for it.

Generators, lint, and the dependency graph are the rest of the leash. Folder structure is a decision. Written only in a README, both people and models will improve it. If creating the wrong file fails the check, the improvement does not land.

Point it at exploration

The high-leverage uses are the ones where a person still owns the judgment. Explore two shapes for a module and throw one away. Draft the migration notes from the diff. Produce the codemod you are going to read line by line. Explain an incident timeline so the next person starts oriented.

The low-leverage use is “build the feature” against a platform that lives in people's heads. The model cannot see the conversation where you decided the shell owns the route. It will decide again, locally, and the result will look finished. Finished is the dangerous part. A rough draft invites a reader. A polished wrong file invites a merge.

Put the speed in the scaffold

There is a sentence I come back to whenever a tooling discussion gets abstract. The maintainable path has to be the fastest path. Models make that sentence operational. They take the fastest path every time, at a volume no review culture can skim.

So put the speed where you want the work to go. Tokens already imported. Routes already shaped. Tests already failing for the right reason. A typed call already the obvious way to talk to the server. Then a model multiplies the architecture. Leave those unset, and it multiplies whatever it guesses. That is how a platform grows a second, unofficial one inside a pull request.

I would rather spend a week on the scaffold than a quarter reviewing drift.