Your app accepts a value from another service. AI writes a neat validation rule. The example works. You move on.
Then the service changes the value's format, and your app rejects something it should accept.
That is the beginner lesson I take from GitHub's October 2 update to GitHub App installation tokens. The rollout is complete: new installation tokens are roughly 520 characters instead of 40. Their prefix remains ghs_, while permissions, repository scope, and the one-hour lifetime are unchanged.
GitHub also says its temporary format-selection header will be deprecated November 30. Integrations should handle these values as opaque strings: pass them through without making assumptions about their internal structure.
You do not need a GitHub App to learn from this. Payment references, pagination cursors, storage keys, and outside record identifiers can create the same design question: which properties does the provider promise, and which did your code infer from an example?
I want you to make that distinction before asking AI to harden an integration. A stricter rule can be a worse rule if it rejects valid input.
Once you have identified one integration to inspect, my $1 AI App Builder Starter Prompts can help you turn a rough build task into a guided next action. Start with the checklist below; you can use it without buying anything.
The mistake: treating an example as a specification
Imagine a small app that imports project activity from another service. Its test fixture has a 12-character record ID.
AI suggests limiting the stored ID to 12 characters. That sounds tidy. But unless the provider documents that limit, your app now depends on an accidental property of one example.
The next record could have a longer ID. A storage layer might reject it. Worse, an intermediate layer could shorten it and leave you holding a different identifier.
I call this an assumption audit: find every place where your app interprets, limits, or transforms a value it does not own. You are checking the boundary, rather than deciding that all validation is bad.
Here are five prompts I would use.
1. Ask which rules have a documented owner
Give AI the relevant integration code and the provider's official documentation. Keep real credentials out of the prompt.
"List every assumption this code makes about external values. For each assumption, identify the supporting documentation or mark it unsupported. Separate our product rules from provider rules. Do not change code yet."
A useful answer names a specific operation: a length check, a prefix test, a conversion to a number, a split on punctuation, or a fixed-width field.
Reject an answer that merely says the integration follows best practices. You need to know why each restriction exists.
2. Trace one value through the whole path
"Trace this external identifier from receipt to its final use. Include validation, storage, serialization, transport, and diagnostic handling. Identify any step that could change or shorten it."
Use a made-up identifier. For a secret, inspect code and configuration with placeholders rather than fetching or printing a real value.
The result should be a short sequence you can check. For example: response field, application variable, saved record, outgoing request. A perfect input validator cannot protect a value that a later layer silently changes.
3. Build fixtures that challenge the assumption
"Create synthetic fixtures that vary the undocumented properties we found. Test whether the value remains identical through the integration boundary. Clearly separate local preservation tests from provider acceptance tests."
For an opaque identifier, useful variations might include a longer value, leading zeroes, and punctuation where the documented contract permits it. Select cases from the actual contract; do not invent a universal list of characters every service must accept.
A string such as 000123 is especially revealing if your app converts IDs to numbers. If those zeroes matter to the provider, converting it to 123 changes the identity.
These local checks prove your code preserves fixtures. They do not prove a fabricated token can authenticate. Never send made-up credentials to production to turn a unit test into a live experiment.
4. Keep security decisions in the right place
"Explain what this app can validate locally, what the provider must verify, and what our own authorization policy must enforce. Show how failures become safe user-facing states without exposing secrets."
Opaque does not mean trusted. A value can travel intact and still be expired, unauthorized, or invalid.
GitHub's installation-authentication documentation describes access in terms of installation permissions and repository access. Knowing a token's appearance does not establish either of those things.
In your app, keep identity, access decisions, and representation checks separate. Do not let a plausible-looking string become proof that someone owns a record.
5. Repair the smallest unsupported dependency
"Propose the smallest change that removes the unsupported format assumption. Preserve documented constraints, request-size protections, authorization, and secret handling. Show the failing synthetic case before the change and the passing case after it."
Do not ask AI to remove every length limit across your app. Size limits still protect resources, and user-created fields still need product rules.
The goal is to replace an unjustified constraint with a justified one. If a provider offers no explicit maximum, document your operational limit, choose it deliberately, and fail clearly when it is exceeded. Do not silently truncate.
A ten-minute task for your first app
Pick one value owned by an outside system. Find its documentation. Write down what your app needs to know about it and what it should simply preserve.
Then trace that value through your code with one synthetic fixture that breaks an unsupported assumption. You may discover there is nothing to repair. That is useful evidence too.
This checklist cannot guarantee compatibility with every future provider change. A service can change behavior as well as representation. But it removes one avoidable source of fragility: making your app depend on details the provider never promised.
For a guided immediate step, the $1 Starter Prompts help you structure the questions you give an AI builder. For the organized path from idea through testing and publication, my $9 AI App Builder From Zero e-book includes all 40 Starter Prompts as a free bonus inside its PDF and EPUB.
Review Radar is coming soon. It brings together research, tailored screens, and an AI-ready project folder to help you prepare a build; it does not promise revenue or a guaranteed app. See the existing preview and join the email waitlist.
My takeaway: when your app receives an outside value, understand the contract before teaching your code to understand its shape.
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim
Top comments (1)
The question "which properties does the provider promise, and which did your code infer from an example" is the useful one, and it reaches well past tokens. Contact fields hit the same trap: a phone rule an AI writes from one US example can end up assuming ten digits, and then a valid UK number fails. For your fixture step, putting +44 20 7946 0958 next to a US number in the 555-0100 to 555-0199 range gives you two formats that are both reserved for fiction, so they are safe to commit.