How I use coding agents without giving up code ownership

I use coding agents regularly, but I do not treat their output as a handoff from another engineer. The agent can explore, implement, refactor, and test. I remain responsible for the product decision, the constraints, the diff, and the release.

That distinction matters because fast code generation can hide uncertainty. A convincing-looking interface can still misstate the product, break at a smaller viewport, or introduce a failure that never appears in the happy-path demo.

Start with a bounded brief

I give the agent the same context I would want before changing an unfamiliar system: the user goal, relevant files, existing conventions, acceptance criteria, and commands that define success.

The brief also says what must not change. On this portfolio, the goal was to make AI expertise visible without returning to broad "AI-native" positioning. The primary identity had to remain product engineer. AI needed one evidence-led section, support in the metadata and services, and no invented claims.

That boundary is more useful than a request to "make the site sound more AI."

Treat the diff as a proposal

I review generated work at three levels.

First is product meaning: does the copy say something I can defend? Second is implementation: does the code fit the system instead of introducing a second pattern? Third is behavior: does the page still work in the browser, across viewports, themes, and awkward states?

For the AI-practice section, the first rendered version used the accent orange for small labels on a dark surface. It looked intentional in a screenshot. The accessibility audit measured contrast ratios below the WCAG AA requirement, including 2.56:1 and 2.91:1 where the target was 4.5:1.

The fix kept orange as a structural border and moved the text to the high-contrast foreground token. The agent accelerated the implementation; the audit determined whether the implementation was acceptable.

Verification is part of the prompt

I do not consider "the code compiles" a complete result. The local portfolio gate checks TypeScript, unit behavior, a production build, public routes, structured data, accessibility, runtime errors, and desktop and mobile layouts.

The next layer adds screenshot baselines, Chromium/Firefox/WebKit coverage, performance budgets, and a live-production probe. Those checks make approval repeatable. They also make the agent easier to use well because the completion criteria are executable instead of subjective.

Where I do not delegate judgment

An agent can identify patterns and generate alternatives. It cannot decide which claim I am willing to make in an interview. It cannot observe whether a recruiter understands the page in fifteen seconds. It cannot approve its own visual changes merely because a screenshot test can be updated.

Those decisions stay with me. I use the tool to increase the amount of ground I can cover, then use evidence and human review to decide what survives.

The result I want is not code that looks AI-generated or code that hides the use of AI. It is work with clear ownership: the tool's contribution is visible in the speed and breadth of the process, while the product decisions and verification remain accountable.