If you're paying for Claude, Cursor, or Codex and you're still pasting the same vague prompt into every new chat, the model isn't your bottleneck. Here's the tell: you type some version of "we don't do it that way" more than once a week. That correction is real engineering knowledge. Right now it lives in your head and dies when the conversation ends. Two things fix that. Knowledge is the context you make available; your architecture, your business rules, your API docs, your constraints, and the reasons behind the decisions you already argued about once. Skills are the recurring work written down once: the steps, not the explanation. Adding an API endpoint, concretely. Knowledge tells the agent how auth works, what the data model looks like, and why the team picked the conventions it did. The skill tells it what to do: read the two closest existing endpoints, follow the same validation pattern, update the API contract, run the tests that cover it. You still review the diff. You still own the decision. You've just stopped re-explaining your own codebase five times a week. Start with one task you repeat. Write the steps. Supply the context. Then check the thing that actually matters: did the rework go down, or does it only feel more organized? A subscription buys access. Getting useful work out of it is engineering.

The "we don't do it that way" test is a great way to put it. Every correction you repeat should end up in a rules file, not in the next chat. Making that a habit changed how I work with agents too.

Before adding AI to your SaaS, write the failure contract.Most AI feature briefs describe what should happen when the model works.Production problems begin when it doesn’t.Before adding AI to an existing SaaS product, I think the team should define: 1. LatencyHow long can the user wait before the product falls back, continues asynchronously, or offers another path?2. UncertaintyWhat happens when the output is incomplete or confidence is too low? Does the product ask for clarification, request human review, or refuse the action?3. PermissionsWhich records can the model access for this user, role, and organization? AI should inherit the product’s access rules rather than bypass them.4. Action boundariesCan the AI recommend, draft, or execute? Sending an email, changing a payment state, and updating a customer record should not share the same approval rules.5. CostWhat is the usage limit per user or tenant? Which model or workflow becomes the fallback when a request is too expensive?6. RecoveryCan the team see which model, prompt, data, and tool call produced the result? Can a failed workflow be retried without duplicating the action?Connecting an API is usually the easy part. The real product work is deciding how the feature behaves when reality does not match the demo.If you are building AI into a product, which part is hardest to define: latency, permissions, human approval, cost, or recovery?

Recovery is the one I find hardest to define. If an email goes out and the next step fails, I want the retry to know it was sent so the customer does not get it twice.