Typed vs untyped
Ten dollars twice became 210
Alice sold handmade candles online and asked an AI to add a quantity box to her order form. The first test went fine. Then a real customer ordered two candles at ten dollars each, and the confirmation email said the total was 210 dollars. She checked the code and the arithmetic looked right. Alice couldn't see why the same line worked for her test and gave nonsense for a customer, and the customer had already paid.
- A typed language knows each value's kind. A checker catches many mix-ups before the app runs, even where nobody wrote the type.
- In plain JavaScript the text "2" times 10 gives 20, but the text "2" plus 10 gives "210", with no complaint.
- Types disappear before the app runs, so data from a form must be checked when it arrives.
- A lazy fix adds "as any", which switches the checker off for that value. Never accept it on money code.
A type checker catches Wrong kinds of value
Dos and don'ts
- When a type error appears, ask the AI to make the data correct.
- Ask that data from forms is checked when it arrives.
- Pay extra attention to any code touching money.
- Accept "as any" as a fix.
- Assume types protect you from bad form input.
Why the total went wrong
In plain JavaScript, "2" + 10 → "210", and nothing complains. TypeScript refuses to build if a number is declared but the form sends text. A type checker reads your code and flags values of the wrong kind.
Types stop at the door
The checker only reads your code. Once the app runs, the types are gone, so they can't check what a customer types into a form. Example: the form sends "42" as text — validate it on the server when it arrives.
"as any" turns the checker off
When the AI hits a type error, watch its fix. A good fix makes the data correct. A lazy fix writes "as any", which tells the checker to stop looking. On anything touching money, that silence is the bug.
Example below — read the comments; you do not need to write this code.
Search my project for as any, @ts-ignore and places where a form value is used as a number without conversion. For each one, tell me what mistake the type checker is being stopped from catching, and fix it properly rather than silencing it.
Example
Find where form or URL text is passed into something that expects a number. Fix those spots so a wrong kind of value can't slip through, then show me the type check passing with no errors.
Paste into your agent inside a project folder. Prompts that say "this project" are for the app you build in the Lab, or any app you already have. No project yet? Read them now and paste them later, in the Lab.
Find one place in this project where text might be used as a number. Show the TypeScript type that would have blocked it.
Stop this AI mistake: passing nothing where an order object is required. Show me the smallest change that makes the type check catch it, then prove the check passes.
You just used "as any" to silence a type error. Undo it and fix the real mismatch instead. Explain in plain words what was wrong with the data.