Directing and reviewing AI

I still need fundamentals because generated code can compile while violating business rules. A compiler cannot tell whether a customer owns an order, whether two requests can oversell stock, or whether a retry charges twice. I use AI to accelerate exploration and implementation, then apply my understanding of databases, concurrency and security to review the result. I only accept code I can explain and support. The team remains responsible for what it ships, regardless of who produced the first draft.

I start with a spec describing observable behavior, constraints, failure cases and explicit non-goals. I review a plan that maps those requirements to data changes, transaction boundaries and tests, then implement small vertical slices. Review compares the resulting behavior and diff with the spec rather than merely checking whether the code looks sensible. When a requirement changes, I update the spec and tests together. I keep the ceremony proportional to the risk and size of the change.

I check that every acceptance criterion has an implementation step and meaningful verification. Then I inspect the data model, constraints, ownership checks, transaction boundaries and external side effects. I walk through duplicate requests, concurrent changes, timeouts and partial failure. I also ask whether each new package and abstraction solves a present requirement. If the plan is much larger than the feature, I request a simpler alternative. A plan is ready when its important assumptions and recovery paths are explicit.

I provide the current requirement, non-goals, relevant files, repository conventions and the versions already in use. I include a working example from the codebase and the exact checks needed for the change. Stable guidance belongs in a short repository instruction file, while task-specific decisions belong with the spec. I avoid secrets and customer data, and prefer focused context over dumping the whole repository. I also ask the assistant to identify missing information rather than invent APIs or requirements.

A build checks syntax, references and type rules, but it cannot prove the intended behavior. An endpoint can compile and still leak another customer's data, issue an N+1 query pattern or return success after swallowing a failure. I require acceptance tests for the business behavior, integration tests where database semantics matter, and review of security and failure paths. I inspect the actual diff and relevant runtime evidence. A model's claim that everything is correct is not an independent check.

I inspect loops and navigation access, then verify generated SQL and command counts with representative data. I usually project the response shape in the database rather than loading entire graphs. For read-only entity queries, AsNoTracking avoids unnecessary change tracking. I do not add it mechanically to scalar projections, which do not track entities anyway, or to workflows that intentionally update tracked entities. The important evidence is bounded database work and the correct update behavior, not simply the presence of a particular method call.

I look for .Result and .Wait, async void outside event handlers, missing awaits and cancellation tokens that stop at an intermediate method. I also check for fire-and-forget work using request-scoped services and concurrent operations on one DbContext. In ASP.NET Core, blocking tasks can starve the thread pool even without the classic synchronization-context deadlock. I use genuine async I/O throughout the call chain and durable background processing for work that must survive the request or process.

A captive dependency occurs when a longer-lived service retains a dependency that should have a shorter lifetime. A singleton holding a scoped DbContext is a common example: the context can outlive its intended unit of work and be accessed concurrently. I review registrations as well as constructors. A request service can become scoped, while a singleton background worker can create a scope or use a context factory per operation. Making the DbContext singleton does not solve the problem.

I check whether untrusted values are concatenated or interpolated into a string passed to FromSqlRaw. That makes them part of SQL syntax and creates an injection risk. I use a parameterizing API such as FromSql with an interpolated string, or explicit parameters for raw SQL. Dynamic identifiers cannot be parameterized as values, so they need a strict allowlist. Parameterization does not replace authorization: the query still has to restrict results to the authenticated user's permitted data.

I allow broad exception handling at a responsible boundary, such as an API exception handler or a background job runner, when it records failure and applies a clear policy. Inside business logic I prefer specific exceptions only when I can recover or translate a known outcome. I do not turn an unknown payment failure into a decline, because the payment may have succeeded. Cancellation should be handled deliberately, and exceptions should not be swallowed or logged repeatedly at every layer.

I inject TimeProvider instead of reading machine time throughout the code. For timestamps representing instants, I normally use GetUtcNow and DateTimeOffset, then control the clock in tests for expiry boundaries and retries. I distinguish that from local civil schedules, such as a booking at nine in a particular time zone, which need zone and daylight-saving rules. Replacing every time value with UTC mechanically can lose business meaning; the representation should match the domain.

I verify proposed packages against official documentation, trusted registries and the publisher's repository before adding them. I check the exact version, transitive dependencies, security advisories and license terms rather than assuming a familiar library remains free under every version. An invented package name can become a supply-chain risk if someone publishes it. I keep changes explicit in the dependency diff and escalate unclear licensing requirements to the appropriate reviewer. Successful compilation alone does not establish provenance or acceptable terms.

I define non-goals and ask how each new layer, abstraction or dependency supports a current requirement. I prefer a small working slice with observable behavior before generalizing. If there is only one implementation and no meaningful boundary, a direct method may be clearer than a factory and strategy hierarchy. I still preserve existing architectural boundaries where they serve real consumers. The goal is a change that is easy to review and maintain, with complexity justified by evidence rather than hypothetical future flexibility.

I write acceptance criteria around observable outcomes and important invariants. For order cancellation, that includes ownership, repeated requests, incompatible states, concurrent payment and rollback of related writes. Tests should fail if those rules break, without mirroring private helper calls or the current class layout. I use the real database provider where transactions or query translation matter. I also review test assertions, because generated tests can pass while checking nothing important or reproducing the same misunderstanding as the implementation.

I measure delivery time including review and rework, alongside acceptance quality, escaped defects and operational outcomes. I include tool spend and maintenance effort rather than counting only the time to generate a draft. Comparisons need similar task size and risk, with enough observations to avoid drawing conclusions from one easy change. I also check whether the team can explain and modify the result. More generated lines or more accepted suggestions can coexist with worse engineering outcomes.