AI and TypeScript strict mode migration

End-of-lesson check

15 questions · take it digitally for instant feedback at tendril.neural-forge.io/learn/quiz/end-ai-coding-llm-ts-strict-mode-rollout-creators

1. Why do strict TypeScript migrations often stall or fail to complete?

   1. The runtime behavior of the application changes in unpredictable ways
   2. The migration tools available are incompatible with modern JavaScript features
   3. The error count becomes overwhelming and developers lose motivation to fix them all
   4. TypeScript's type checker crashes when encountering too many violations

2. What is the primary advantage of using an LLM when migrating to strict TypeScript?

   1. The LLM can categorize similar errors and fix them in batches
   2. The LLM writes all new feature code while you watch
   3. The LLM automatically deploys the fixed code to production
   4. The LLM guarantees zero runtime bugs after migration

3. When using an LLM to fix TypeScript errors, what is the recommended batch size?

   1. All errors at once for maximum efficiency
   2. Only 5 errors to ensure accuracy
   3. Exactly 100 errors to match TypeScript's default limit
   4. Approximately 30 errors of a single error code at a time

4. Which type of TypeScript error is an LLM particularly good at fixing in batches?

   1. Database connection timeouts
   2. Syntax errors in JavaScript code
   3. CSS styling conflicts
   4. Implicit any occurrences throughout a codebase

5. What should a developer ask an LLM to do when requesting type fixes?

   1. Propose minimal type fixes that preserve runtime behavior and flag any type casts used
   2. Convert the codebase to a different programming language entirely
   3. Rewrite the entire application using functional programming patterns
   4. Remove all comments to reduce file size

6. What specific TypeScript feature can an LLM generate to help with type narrowing?

   1. User interface mockups
   2. Database schema definitions
   3. Entire new unit test suites
   4. Type guards that check types at runtime

7. What is a critical limitation of LLMs when handling type casts during migration?

   1. LLMs can safely remove all type casts without any consequences
   2. LLMs refuse to work with any code containing type casts
   3. LLMs tend to overuse `any` casts to silence errors rather than designing proper types
   4. LLMs always choose the most type-safe approach automatically

8. Which decision should a human developer always make during strict TypeScript migration, not an LLM?

   1. How many coffee breaks to take during the day
   2. How many characters are in the variable names
   3. Which color scheme to use for the code editor
   4. Whether to use a type cast as an escape hatch or design a proper type

9. What aspect of the migration should remain under human ownership, not LLM control?

   1. The rollout schedule and when changes are deployed
   2. The number of files the LLM processes simultaneously
   3. The exact syntax of every semicolon in the code
   4. The specific keyboard shortcut used to save files

10. Why must every type cast suggested by an LLM be reviewed by a developer?

    1. Casts are escape hatches that bypass TypeScript's type safety and may hide bugs
    2. Casts automatically improve application performance
    3. Casts are required by TypeScript for all variable declarations
    4. LLMs never suggest casts, only proper types

11. What error category is related to accessing object properties that may not exist?

    1. Syntax errors
    2. Index signature errors
    3. Memory leak warnings
    4. Network timeout errors

12. When migrating, which error category requires handling values that could be null or undefined?

    1. Null check errors
    2. Environment variable errors
    3. Import statement errors
    4. Package version conflicts

13. What utility type can an LLM generate to handle nullable values more safely?

    1. A SQL database query
    2. A complete CSS stylesheet
    3. An HTTP request handler
    4. A custom type guard function

14. What is a key strategy for maintaining safety when using LLM-generated type fixes?

    1. Ensure the fixes preserve existing runtime behavior
    2. Disable TypeScript's strict mode temporarily
    3. Change as many things as possible at once
    4. Remove all error handling code

15. What happens when an LLM encounters a difficult type problem during migration?

    1. It will refuse to continue working on the project
    2. It may suggest using `any` to silence the error without addressing the root cause
    3. It will automatically refactor the entire architecture
    4. It will delete the problematic code entirely