The safest AI coding workflow looks more like pair programming with a very fast junior colleague than like an autonomous commit button.
Work through the path
Open a card when you need it. Marking a lesson complete is optional and stays only in this browser.
1Give the assistant a map before asking for a change
Start with architecture, entry points, constraints and the specific files in scope before asking for implementation.
Ask for a concise repository map and list assumptions. Then provide the relevant project files rather than dumping the entire repository into every request.
Keep a decision record when the assistant proposes a design that affects boundaries, data or operations.
Try it
Ask for a plan and file list, review it, then start a new step with only the approved scope.
Context:
- API: Orders.Api
- Persistence: EF Core / SQL Server
- Rule: handlers must accept CancellationToken
- Scope: add GET /orders/{id}
First: list the files you expect to change and why. Do not write code yet.2Turn an example into tests before implementation
Examples and acceptance cases give the assistant an executable target and make generated code easier to review.
Write normal, boundary, invalid and authorization cases. Ask the assistant to identify missing cases before it writes the implementation.
Run the tests locally; a passing generated test suite can still encode the wrong requirement, so review the assertion itself.
Try it
Give the assistant one failing test and ask for the smallest implementation that makes it pass.
[Fact]
public async Task Rejects_an_empty_order()
{
var response = await client.PostAsJsonAsync(
"/orders", new { lines = Array.Empty<object>() });
response.StatusCode.Should().Be(HttpStatusCode.BadRequest);
}3Ask for small diffs and explain every changed line
Small changes preserve reviewability, reduce accidental scope and make it easier to revert an AI mistake.
Ask the assistant to modify one concern at a time and show a diff. Review imports, error paths, logging, allocations, authorization and configuration—not only the happy path.
Keep generated code in the same formatting and architectural conventions as the repository.
Try it
After each small diff, compile and run the narrow test set before asking for the next step.
Request: 1. Add the validator only. 2. Show the diff and explain each changed line. 3. Do not change public method names. 4. Stop before touching persistence.
4Use evidence in the debugging loop
AI is most useful in debugging when you provide the exact symptom, reproduction, logs, expected behavior and what has already been tried.
Ask for hypotheses ranked by evidence, not a list of random fixes. Add one diagnostic or test that would distinguish each hypothesis.
Redact secrets and personal data before sharing logs. Keep the original evidence locally so the investigation remains reproducible.
Try it
Give the assistant a failing test or redacted trace before asking it to rewrite code.
Symptom: POST /orders returns 409 only after two concurrent requests. Expected: one succeeds and one returns a conflict. Evidence: response bodies, timestamps, SQL log excerpt. Ask: propose two hypotheses and one test for each.
5Use a security review pass before merging AI code
Generated code needs a deliberate review for authorization, injection, secrets, dependency changes, data exposure and failure behavior.
Ask for a threat model and review the result yourself. Check whether the assistant introduced a new trust boundary or copied an unsafe pattern from an example.
Use static analysis, tests and human review. Do not send production secrets or proprietary code to a provider without an approved data policy.
Try it
Run the checklist against one generated endpoint and record one change you made because of it.
Review checklist: - Who can call this path? - What input reaches SQL, HTML or a shell? - What data enters logs or model context? - What happens on timeout and retry? - Can a user trigger a write tool?
No lesson matches that phrase.
Related tools
Turn the concept into a working example with the browser-based tools.