How to Write AI Prompts for Code That Fits Your Project

Generic prompts produce generic code: the wrong framework version, invented helper classes, a different naming style and no error handling. The fix is the same as in any prompt (context, constraints, examples), but for code the details are specific.

What to always include

Detail	Example
Language and versions	".NET 9, C# 13, ASP.NET Core minimal APIs, EF Core 9"
Existing types	Paste the entity, DTO or interface the code must use
Conventions	"Async all the way, file-scoped namespaces, primary constructors, no AutoMapper"
Constraints	"No new NuGet packages", "must be thread-safe", "no breaking API changes"
Errors and edge cases	"Return 404 if the order is missing, 400 on invalid page size"
What done looks like	"Include xUnit tests for the happy path and two edge cases"

Weak prompt vs strong prompt

Weak:

Write an API to get orders with paging.

Strong:

.NET 9, ASP.NET Core controllers, EF Core 9 with SQL Server.
Existing entity:

public class Order
{
    public int Id { get; set; }
    public int CustomerId { get; set; }
    public DateTime CreatedAt { get; set; }
    public decimal Total { get; set; }
    public OrderStatus Status { get; set; }
}

Our DbContext is AppDbContext with DbSet<Order> Orders.
Write a GET /api/orders endpoint in OrdersController that:
- takes page (default 1) and pageSize (default 20, max 100)
- optionally filters by status
- returns newest first, as PagedResult<OrderDto> (define both records)
- uses AsNoTracking and a single query for the page plus one count query
- returns 400 with ProblemDetails for invalid paging values
Use primary constructors and file-scoped namespaces. No new packages.

The second prompt produces code you can paste with small edits, because the AI no longer has to guess your types, versions or rules.

Show an example from your codebase

The fastest way to get code that matches your style is to paste one existing piece as a pattern:

Here is our existing CustomersController (pattern to follow):
[paste ~40 lines]
Write an equivalent SuppliersController for this entity: [paste entity].
Follow the same structure, naming, validation and error handling.

This is few-shot prompting applied to code. One good example beats a page of style rules.

Ask for a plan before code

For anything bigger than one method, ask for the approach first:

Before writing code, list the files you would change or add, and the
approach in 5 bullet points. Wait for my OK.

Correct the plan ("don't add a repository layer, we use DbContext directly"), then ask for the code. This saves you from reviewing 200 lines built on a wrong assumption.

Ask it to state assumptions

At the end, list every assumption you made about my project that I should
check, such as package versions, existing methods or configuration.

This surfaces invented APIs and wrong guesses before you hit a compile error.

Iterate in small steps

Ask for one piece at a time (the DTOs, then the query, then the endpoint, then tests) and compile in between. Errors are far easier to fix when only 30 lines changed.

Practice task

Pick a feature you need to build. Write a prompt with all six details from the table and one pasted example from your codebase. Ask for a plan first, then the code, then a list of assumptions. Note how many edits you needed before it compiled and passed your review.

Key takeaways

Always give versions, existing types, conventions, constraints, edge cases and a definition of done.
Paste one existing class as a pattern to follow.
Ask for a plan before code, and a list of assumptions after.
Build in small steps and compile between them.