AI Foundations: AI-Powered Dev Tools Practice Questions

AI assistants are good at pattern-matching tasks. Two examples are spotting hardcoded secrets and credentials, and flagging well-known insecure patterns such as SQL injection or shell injection through unsanitized input. Both are text patterns you can recognize in a static code review. No AI tool can certify that code is free of all zero-day vulnerabilities, especially ones unknown when the model was trained, and believing it can is a dangerous misconception. AI coding tools work on source code text. They cannot run exploit attempts against a production server at runtime. Building and deploying a patch to staging is an operational CI/CD task, outside the scope of an AI code review assistant.

Copilot's inline completion relies heavily on the surrounding context: open files and the content near the cursor. Having the ESLint config and well-styled source files open shows Copilot the project's conventions and steers suggestions toward that style. Disabling and re-enabling the extension does not change suggestion style, because there is no suggestion cache that stores style preferences. Asking Copilot Chat to summarize the ESLint rules can explain them, but that summary is not fed back into the inline completion context. Copilot Enterprise offers features like knowledge bases and PR summaries, but it does not automatically parse ESLint rules or enforce them in generated suggestions.

The two best preventive practices work before the code is generated. First, clean up commented-out imports and dead code before they enter the AI's context window, which removes the misleading signals that lead the AI to infer unwanted dependencies. Second, instruct the AI to get explicit developer approval before adding any new external dependency, which stops the behavior up front. Accepting suggestions in full and auditing at sprint end is the opposite of safe practice. Turning the assistant off in any file with commented-out code is impractical and overcautious. An SCA tool in CI is a valuable detective control, but it runs after the code has been generated and committed, so it addresses a different layer of the problem.

Cmd+K makes inline edits based on the natural-language instruction you give it. A vague instruction like 'make this faster' tells the model almost nothing about what kind of optimization is needed: lower time complexity, fewer memory allocations, less redundant I/O, and so on. A precise instruction (e.g., 'Replace the O(n²) nested loop with a dictionary lookup to reduce time complexity') gives far better results. The claim that Cmd+K is limited to renaming and formatting, with performance rewrites needing Composer, is wrong: Cmd+K fully supports performance-related edits. The context-window claim is wrong because fifteen lines is tiny compared with any modern model's context window. The claim that Cursor is optimized only for multi-file changes is wrong: Cmd+K and Composer cover different scopes (inline vs. multi-file), and Cmd+K is the right tool for targeted single-selection edits.

AI coding assistants depend heavily on what is visible in the context window, including open tabs, nearby code, imports, and type definitions, to produce relevant suggestions. A rich codebase gives more signal about naming conventions, patterns, and interfaces. The git-history option is wrong because commit history is not fed to the model as real-time context during completion. The caching option is wrong because the model generates completions fresh; they are not literal cache lookups of earlier outputs. The model-tier option is wrong because tools like Copilot do not switch model tiers based on file size.