One JavaScript module per paid AI session

A small JavaScript project can become an expensive AI conversation if you ask for a complete TypeScript rewrite. The assistant changes several modules, guesses what your data looks like, and leaves you reviewing everything at once. I prefer a tighter rule: migrate one module, check it, and decide whether another paid request is necessary. Here is a walkthrough you can follow with a small browser app or Node application.

Start with behavior you can verify

Choose a project that already runs. Before changing anything, save a clean version in Git and run its existing tests. If it has no tests, write down a few repeatable checks: submitting a form, loading saved data, and handling an empty result, for example. Add a focused test when a calculation or transformation would be difficult to verify manually.

These checks give you a baseline. TypeScript can catch incompatible values, but it cannot prove that a total is calculated correctly or that a button still works. Keep the first migration focused on preserving behavior.

Ask the assistant to inspect before editing

Give your coding assistant the project’s package information, build setup, and one small module with its direct callers. Ask it to identify the smallest migration that leaves the application runnable. Request an explanation of required tooling changes before it edits anything.

State your limits in complete sentences: preserve runtime behavior, avoid dependency upgrades unless required, and leave unrelated cleanup for later. A narrow request reduces both review work and the amount of context you repeatedly pay to send.

Let JavaScript and TypeScript coexist

Have the assistant add TypeScript support through the project’s existing build tool. Keep JavaScript enabled during the transition, so each module can move independently. Enable strict checking for TypeScript, and make type checking a separate verification step if the build tool only removes type annotations.

Ask the assistant to explain how the browser or Node runtime will receive executable JavaScript. Renaming a source file does not establish that process. Run the application and the type checker before migrating more code, so you can distinguish setup problems from typing problems.

Convert a small module with predictable inputs

Start with a utility that has few dependencies, such as a function that totals expenses or filters a list. Ask the assistant to convert that module and update only the references needed to keep it working. Let TypeScript infer obvious local values; explicit types are most useful at function boundaries and shared data structures.

Then review the proposed types against actual callers. Does an amount arrive as a number or a string? Can a lookup return nothing? If the assistant cannot establish an answer from the available code, ask it to identify the uncertainty instead of inventing a convenient type.

Check data boundaries before trusting the types

Network responses, stored browser data, and user input deserve particular attention. A type annotation does not validate a value at runtime. Ask the assistant to treat uncertain external data as unknown and check its structure before using it, following any validation approach already present in the project.

Review uses of any and type assertions closely. They sometimes have legitimate uses, but they can also hide the exact mismatch you wanted TypeScript to reveal. Prefer a small validation check or a more accurate type when the evidence supports it.

Run checks before buying another round

After each module, run type checking, relevant tests, and the application checks you recorded earlier. Read the changes yourself. If something fails, send the assistant the specific error and relevant context rather than asking it to reconsider the whole project.

MyRelay provides one key and one pay-as-you-go budget across supported coding tools, with tokens and cost visible for every request. Create a MyRelay account if you want to track those costs while working through the migration. Review spending after each completed module, alongside whether the assistance actually saved you time.

Finish at a stable stopping point

Repeat with modules that depend on the ones already converted. Save each verified change separately so you can reverse it easily. When the intended scope is complete, remove temporary migration settings only after confirming that no remaining JavaScript depends on them. A useful stopping point is a runnable project with checked types, preserved behavior, and changes you understand.