Prompt engineering deliberately shapes and revises instructions to steer a large language model toward useful output. Treat the model like a capable junior teammate: give it context, constraints, a role, and a concrete task, then inspect what it returns. Broad requests tend to yield broad results; specific requests yield more targeted ones. section 2.1.1 section 2.0
Useful prompting patterns include:
- Refinement Pattern: start broad, then iteratively add requirements or correct omissions until the response is accurate, relevant, and sufficiently detailed. section 2.1.1 section 2.5
- Persona Pattern: assign a role, such as computer science intern or software architect, to guide the response’s context, consistency, and expected level of responsibility. section 2.1.1 section 3.2
- Audience Persona Pattern: describe the intended users so responses can be tailored to their needs and expectations. section 2.5
- Step-by-step rationale: request reasoning through a problem and its rationale when exploring requirements or a design direction. section 3.2
Refining a generated depreciation strategy
An incomplete prompt can produce code that looks correct while omitting essential rules. A depreciation request initially generated a straight-line calculation without salvage value or useful life. Adding the actual formulas to the prompt corrected the requested behavior; pseudocode-level calculations were enough for Copilot to produce Python code. Review generated output against the domain rules rather than accepting it on first appearance. section 4.1.4 section 4.1.4
Moving from a linked-list question to an implementation
Ask the model to reformulate a question, establish a computer-science-intern persona, and request a singly linked list with named operations. Follow-up prompts can switch from pseudocode to Python and then ask for a reverse method. Outputs may differ between runs, so use the interaction as a guided starting point, not a fixed script. section 2.1.1 section 2.1.1
# Define an interface called DepreciationStrategy. # It should have four concrete implementations of the interface: StraightLineDepreciationStrategy, DecliningBalanceDepreciationStrategy, DoubleDecliningDepreciationStrategy, and NoDepreciationStrategy. # Each implementation overrides the calculate_depreciation() method to provide a specific way of calculating depreciation for an asset based on its funding details. # The calculate_depreciation() method should take a FundingDetails object as a parameter and return a float value representing the depreciation amount. # NoDepreciationStrategy should return 0 for all assets. # The other three strategies should return the depreciation amount based on the following formulas: # - Straight Line: (cost - salvage value) / useful_life # - Declining Balance: cost * (1-rate/100)^(current_year - purchase_year) # - Double Declining: Declining Balance * 2
Compare the revised prompt with the earlier incomplete version: explicit formulas turn missing business rules into testable implementation constraints. section 4.1.4
For larger work, refine prompts from a high-level system request into requirements, package structure, and individual source files. Generated designs can help overcome an empty-file start, but they remain dependent on prior conversation context and may need architectural review or revision. section 3.2 section 3.2
