1 Overview

Code is where prompt engineering pays its clearest dividends — and exposes its sharpest failure modes. A well-built coding prompt produces code that compiles, fits your codebase, and respects your standards; a lazy one produces tutorial-grade snippets with invented APIs and generic naming that costs more to adapt than writing from scratch would have.

This tutorial is the craft manual for that difference. It covers the seven coding tasks developers prompt for most: scaffolding new code, refactoring existing code, explaining legacy code, writing clean and optimized logic, building algorithms, understanding data structures, and enforcing coding standards. For each, you get the prompt shape that works, the context it needs, and the verification it demands.

The through-line is one idea: the model has never seen your codebase. Every quality gap between 'generic code' and 'your code' is context you failed to supply — conventions, signatures, examples, constraints. Coding prompts are context engineering.

2 Learning Objectives

After completing this tutorial, you will be able to:

• Write scaffolding prompts that produce code fitting your codebase — correct signatures, conventions, and dependencies.
• Drive behavior-preserving refactorings with prompts, backed by tests that prove nothing changed.
• Get layered, trustworthy explanations of legacy code before touching it.
• Prompt for clean, optimized logic with specific criteria instead of vague adjectives.
• Build algorithms collaboratively: approach first, implementation second, edge cases always.
• Use the model as a data-structure advisor that reasons about trade-offs for your actual use case.
• Encode team coding standards into a reusable standards profile, and know where analyzers must take over.
• Recognize coding-specific failure modes: hallucinated APIs, outdated idioms, and unverified optimization claims.

3 Prerequisites

• Tutorial 3 (Prompting Patterns) — especially Ask → Review → Improve and Explain → Generate → Refine, which this tutorial applies constantly.
• Solid intermediate C#: interfaces, generics, LINQ, async/await, and familiarity with reading others' code.
• Helpful but optional: a codebase of your own to practice against — the techniques land hardest on real code.

4 What Makes Coding Prompts Different

Coding prompts inherit the standard anatomy — instruction, context, input data, output constraints — but the weights shift hard toward context and constraints. Prose tolerates approximation; code does not. A summary that is 90% right is useful; code that is 90% right does not compile, or worse, compiles and is wrong. So coding prompts must close every degree of freedom that matters: language version, framework, signatures, error handling, naming, and the surrounding code the result must mesh with.

The most valuable single technique is grounding with your own code. Pasting the interface to implement, the class the new code will call, or one existing class that exemplifies your house style converts the request from 'write generic C#' to 'extend this specific codebase'. An example class is few-shot prompting in its most natural coding form — the model imitates its structure, naming, and idioms with remarkable fidelity.

Verification also changes character with code: you have a compiler, analyzers, and tests — deterministic judges the model's output must face. The workflow that works everywhere in this tutorial is: prompt with rich context, review against acceptance criteria, then let the toolchain confirm. Generated code that hasn't compiled and passed tests is a draft, not a deliverable.

5 Prompts for Code Scaffolding

Scaffolding — generating the skeleton of a service, controller, entity set, or test fixture — is where models save the most keystrokes, because structure is exactly what they imitate best. The quality lever is what you pack into the prompt before asking. A scaffolding prompt has four context layers: the requirement (what to build), the contracts (interfaces and types it must fit), the exemplar (one existing class showing house style), and the constraints (framework version, DI registration style, error policy).

Scope the ask deliberately: skeleton first, logic second. 'Generate the class with method stubs, XML docs, and TODO comments; do not implement the logic yet' produces a reviewable frame you approve before any behavior exists — a two-stage prompt sequence in miniature. Then fill methods one at a time with focused prompts, each carrying the approved skeleton as context.

6 Refactoring and Explaining Legacy Code

Refactoring with a model starts from one iron rule: the change must be behavior-preserving, and the model must be told so explicitly — 'refactor for readability; observable behavior, public signatures, and side effects must remain identical'. Without that constraint, models happily 'improve' behavior while restructuring, fixing what they perceive as bugs and thereby creating real ones. With legacy code, safety comes from the Explain → Generate → Refine pattern plus tests: first have the model explain what the code does, verify that explanation against the source, write (or generate) characterization tests that pin current behavior, and only then refactor.

• Name the target smell: 'extract the duplicated validation into one method' beats 'clean this up' — naming the code smell focuses the transformation.
• Small steps over big bangs: one refactoring per prompt (extract method, replace conditional with polymorphism), each verified, exactly like manual refactoring discipline.
• Paste the dependencies: the types the code touches, or the model will guess at members that don't exist.
• Demand a diff-sized answer: 'output only the changed method' keeps review tractable and prevents drive-by rewrites of untouched code.
• Run the tests after every step — each green regression test, not the model's confidence, is what proves behavior held.

For explaining legacy code, ask in layers rather than all at once: first a two-paragraph overview (purpose, inputs/outputs, side effects), then a walkthrough of the specific path you care about, then targeted questions — 'what happens when this dictionary is empty?', 'which callers observe this static field?'. Layered explanation matches how you'd onboard a human, and each layer is verifiable before you rely on the next. Ask explicitly for risks: 'list anything fragile, surprising, or order-dependent in this code' surfaces the landmines refactoring might trip.

7 Clean Logic, Optimization, and Algorithm Building

'Make it clean' and 'optimize this' are the two laziest coding prompts, and both get lazy results. Clean code is specific or it is nothing: name the criteria — guard clauses over nested ifs, methods under 20 lines, intention-revealing names, no boolean parameters. Optimization is measured or it is folklore: ask for the time complexity of current and proposed versions, the specific bottleneck addressed, and a statement of what got worse (allocation? readability?) — and treat every performance claim as unverified until a benchmark says otherwise.

Algorithm building is where chain-of-thought prompting and the design-first habit pay off most. Don't ask for code; ask for an approach: restate the problem with concrete input/output examples (including edge cases — empty input, duplicates, boundaries), request candidate approaches with their time complexity trade-offs, choose one, and only then request the implementation against your chosen approach. The examples double as test cases for the result.

This sequence protects you from the classic failure: a fluent implementation of the wrong approach. It also produces reviewable artifacts at every stage — a stated approach is checkable by reading; a 60-line method's correctness is not.

8 Data-Structure Guidance and Enforcing Coding Standards

As a data structure advisor, the model shines when you supply the workload, not just the question. 'Dictionary or List?' gets a textbook answer; 'I have 50k items, lookups by ID thousands of times per request, inserts rare, iteration order irrelevant — which collection and why?' gets engineering. Ask for the costs that matter — lookup, insert, memory, ordering guarantees — expressed as time complexity for your operations, and for the break-even point where the answer would flip. For learning, ask for the structure explained through your domain's objects rather than abstract Ts; concrete beats generic for retention.

Enforcing coding standards through prompts works at three levels. Level one: a standards profile — a compact, reusable prompt fragment encoding your conventions (naming, nullability, async suffixes, error policy, forbidden patterns) — included in every generation request, ideally via the system message so it survives the whole session. Level two: an exemplar class, because demonstrated style beats described style. Level three: a standards-review prompt — 'review this code against the profile; list violations with line references' — which turns the model into a first-pass reviewer of its own or humans' code.

The table's last row is the honest one: prompts raise compliance; only the toolchain enforces it. Encode your standards in a style guide and analyzers, and let the standards profile exist to minimize the friction between what the model generates and what the build accepts. When the analyzer and the profile disagree, fix the profile — drift between them wastes an Improve turn on every generation.

9 Where Coding Prompts Run in the .NET Ecosystem

• GitHub Copilot completions: implicit prompts — your open files and comments are the context; you steer by writing intent comments and keeping exemplar code visible (tutorials 8–9 go deep).
• Copilot Chat in Visual Studio / VS Code: explicit coding prompts with workspace context — the natural home for refactor/explain/review conversations about code you have open.
• Chat models via Azure AI Foundry playground: best for algorithm design sessions and prompt-shape experimentation before encoding anything.
• Azure OpenAI from application code: coding prompts as versioned prompt templates — scaffolding generators, standards reviewers, migration assistants — with output validated before use (tutorial 11 onward).
• The deterministic backstop: .editorconfig, every static analyzer you run (Roslyn analyzers, StyleCop), and CI builds — the enforcement layer that judges all generated code, regardless of which surface produced it.

One budget note that bites in practice: pasting code costs tokens, and whole-file pastes of large classes can crowd the context window until your instructions lose force. Paste the relevant members, not the file; link the rest by describing it ('the class also implements IDisposable; disposal is not relevant here'). Precision of context beats volume of context.

10 The Coding-Task Catalog: Which Prompt Shape for Which Job

Two composite use cases deserve mention. Code review assistance: paste the diff and the standards profile, ask for issues ranked by severity with line references — a strong pre-filter before human review, never a replacement. And migration work (say, .NET Framework to .NET 8): sequence it — inventory of incompatibilities first, then file-by-file migration prompts each grounded in the target idiom, with the compiler arbitrating every step.

11 Code Examples in C#

A standards profile as a reusable constant — included in every coding prompt your team or tooling sends:

public static class CodingPrompts
{
    // v4: added async suffix + ConfigureAwait rule (2026-09).
    public const string StandardsProfile = """
        Coding standards (apply to ALL generated code):
        - .NET 8, C# 12, nullable reference types enabled.
        - Async methods end in 'Async' and accept a CancellationToken.
        - Guard clauses over nested ifs; max 2 levels of nesting.
        - Constructor injection only; no service locator, no statics for state.
        - Throw ArgumentException/ArgumentNullException for bad inputs;
          never catch-and-ignore.
        - Names: intention-revealing; no abbreviations; bools ask questions.
        - Use only existing project dependencies; propose no new packages.
        """;
}

A scaffolding prompt template that packs the four context layers, with the profile riding along:

public static string BuildScaffoldPrompt(
    string requirement, string contracts, string exemplarClass) => $"""
    {CodingPrompts.StandardsProfile}

    Task: scaffold the following. Generate the class skeleton ONLY:
    method stubs with XML docs and TODO comments — no logic yet.

    Requirement:
    {requirement}

    It must implement/consume these contracts exactly as declared:
    ```csharp
    {contracts}
    ```

    Match the style of this existing class from our codebase:
    ```csharp
    {exemplarClass}
    ```
    """;

And a refactoring prompt that encodes the iron rule and keeps the answer diff-sized:

public static string BuildRefactorPrompt(
    string method, string smell, string dependencies) => $"""
    {CodingPrompts.StandardsProfile}

    Refactor the method below. Target exactly one issue: {smell}.

    HARD CONSTRAINTS:
    - Behavior-preserving: observable behavior, public signature,
      exceptions, and side effects must remain identical.
    - Output ONLY the changed method (plus any new private helpers).
    - Do not 'fix' anything else you notice; list observations separately.

    Types this method depends on (do not invent members):
    ```csharp
    {dependencies}
    ```

    Method:
    ```csharp
    {method}
    ```
    """;

12 Step-by-Step: Scaffolding a Service Into a Real Codebase

This walkthrough scaffolds a `ProductImportService` into an existing ASP.NET application using the full technique stack. Replay it on your own codebase with your own feature.

1. Gather the context pack: the requirement (import products from uploaded CSV, validate, upsert), the contracts (IProductRepository, IFileParser, the Product entity — copied verbatim), one exemplar service (your cleanest existing service class), and the standards profile.
2. Request the skeleton only, using the scaffolding template: class, constructor with injected dependencies, method stubs with XML docs and TODOs. No logic.
3. Review the skeleton against the codebase: right namespace, DI-friendly constructor, CancellationTokens present, naming matches the exemplar. Fix by targeted Improve turns ('rename ImportData to ImportAsync; add IProgress<int> parameter').
4. Approve the skeleton — it is now verified context. Every following prompt pastes it back in.
5. Fill one method per prompt: 'Implement ValidateRowAsync per the TODO. Rules: SKU required and unique per file; price non-negative decimal. Return a RowValidationResult; do not throw for data errors.' Review each against its criteria.
6. Compile and run analyzers after each fill — invented members and style drift surface immediately, while the faulty prompt is still the last one you sent.
7. Generate tests for the completed service (next tutorial's craft, but the shape is: paste the finished class + the validation rules, ask for xUnit tests covering the rules and edge cases — empty file, duplicate SKU, malformed price).
8. Final human review of the assembled whole: seams between generated pieces are where inconsistencies hide — naming drift between methods, duplicated guard logic, missed cancellation propagation.

13 Limitations and Caveats

• Hallucinated APIs are the signature coding failure: plausible methods, overloads, or NuGet packages that don't exist. The compiler catches the loud ones; the quiet ones (wrong overload semantics, deprecated-but-compiling calls) need review and docs. A hallucinated API in a suggestion is a prompt-context smell: you probably didn't paste the real types.
• Training-data lag means idioms can be stale: pre-nullable patterns, old JSON libraries, obsolete hosting models. Pin versions in every prompt ('.NET 8, C# 12') and treat 'modern' as a claim to verify.
• Optimization claims are unverified until benchmarked: models assert performance improvements fluently; BenchmarkDotNet, not fluency, is the judge.
• Behavior preservation is claimed, not guaranteed: only tests prove a refactoring changed nothing — especially around exception types, culture-sensitive formatting, and ordering.
• Explanations of code are static analysis by reading: anything dependent on runtime data, configuration, or timing is a guess to be confirmed by execution.
• Standards profiles raise compliance probabilistically; analyzers and CI remain the only enforcement. Keep profile and analyzers in sync or pay an Improve turn per generation.
• Large pastes dilute instructions: context is a budget (see section 9) — paste relevant members, not whole files.

14 Best Practices and Common Mistakes

Practices that produce codebase-ready output:

• Ground every coding prompt in real code: contracts verbatim, one exemplar class, pinned versions.
• Skeleton first, logic second; one method per fill prompt; the approved skeleton travels as context.
• State 'behavior-preserving' explicitly for every refactor, and have tests green before and after.
• Explain before touching legacy code, in layers, verifying each layer; ask for risks explicitly.
• Replace adjectives with criteria: clean means your named rules; fast means measured complexity plus a benchmark.
• Design algorithms before implementing them; your examples become the tests.
• Maintain one versioned standards profile, mirror it in analyzers, and let CI be the enforcement.

Mistakes that produce adaptation debt:

• Prompting without context and then hand-porting the generic result into your codebase — slower than typing it yourself.
• Accepting refactors that 'also fixed' something — that fix is an unreviewed behavior change.
• Trusting an explanation of legacy code you didn't spot-check, then editing based on it.
• 'Optimize this' with no profile data — you'll get confident micro-optimizations of the wrong thing.
• Asking for the algorithm implementation before agreeing on the approach.
• Whole-file pastes that bury your instructions under 400 lines of context.
• Treating the standards profile as enforcement and skipping the analyzers.
• Letting generated code merge without the same review bar as human code — the bar is the point.

20 Summary & Key Takeaways

• Coding prompts are context engineering: the model has never seen your codebase, and every quality gap is context you didn't supply.
• Scaffold with the four-layer context pack — requirement, contracts, exemplar, constraints — and deliver skeleton-first, filling one method per prompt.
• Refactoring's iron rule is explicit behavior preservation, proven by tests green before and after; legacy work starts with verified explanation and characterization tests.
• Replace adjectives with criteria: clean is a checklist, fast is a measured claim. Design algorithms before implementing them; your examples become your tests.
• Data-structure advice is only as good as the workload you describe — supply counts, operation mix, and constraints; ask for costs and break-even points.
• Standards profiles and exemplars raise compliance; analyzers and CI enforce it. Keep them in sync.
• Know the coding failure modes: hallucinated APIs (missing context), stale idioms (pin versions), unverified optimization claims (benchmark), and 'also fixed' refactors (reject).
• Generated code that compiles is a draft. The merge bar — review, tests, analyzers — is identical to human code, and that identical bar is what keeps quality flat as volume grows.

You can now direct a model through the full coding workday: greenfield scaffolds, careful refactors, legacy archaeology, algorithm design, and standards-true generation. The next tutorial extends the craft to the artifacts around the code: tests and documentation.

21 Next Steps

Continue with the next tutorial in the path: Prompting for Testing & Documentation — generating xUnit test suites that actually test something, edge-case discovery, XML docs, READMEs, and the verification discipline that keeps generated tests honest.

• Practice: build your context pack for one real feature — contracts, exemplar, standards profile — and scaffold it skeleton-first; count the Improve turns saved versus your usual approach.
• Practice: take one smelly method you know, write characterization tests, then drive a one-smell-per-prompt refactor; verify green after every step.
• Practice: run the layered explanation on a module you inherited; verify layer one against source before requesting layer two.
• Practice: take a data-structure choice in your current code and ask the workload question — including the break-even; check whether your current choice survives it.
• Reading: the C# coding conventions on Microsoft Learn (raw material for your standards profile) and the Roslyn analyzers overview (your enforcement layer).