A startup is building an AI-powered code assistant using a large language model (LLM). They want to ensure the model generates syntactically correct code and avoids security vulnerabilities. Which technique should they prioritize?
Few-shot examples steer the LLM toward secure coding patterns and unit-test structure within the prompt itself, requiring no retraining or architectural change. This directly satisfies the startup's constraints of syntactic correctness and vulnerability avoidance, since the model conditions on concrete secure snippets rather than relying on its base pretraining alone.
Why this answer
Few-shot prompting with examples of secure coding practices and unit tests directly shapes the model's output distribution toward syntactically valid, security-conscious code by conditioning on concrete in-context demonstrations. This is a prompt-engineering technique that requires no retraining and can be updated instantly as new vulnerability patterns emerge. It simultaneously addresses both stated goals: syntactic correctness (via code examples) and security (via secure-coding exemplars).
Exam trap
AIF-C01 often tests the misconception that model configuration knobs (max tokens, temperature) or fine-tuning are the primary levers for output quality, when prompt engineering with targeted examples is usually the fastest, most controllable fix.
How to eliminate wrong answers
Option B is wrong because max tokens only caps output length and has no bearing on code correctness or security — a 4096-token limit could even truncate code mid-function. Option C is wrong because fine-tuning on generic open-source code often propagates the very vulnerabilities (e.g., hardcoded secrets, SQL injection) present in public repositories, and it is costly and slow to iterate. Option D is wrong because chain-of-thought improves reasoning transparency but does not guarantee syntactic validity or security; the model can reason correctly and still emit insecure code.