Agentic coding still needs product taste

Agentic coding changes the speed of implementation, but it does not remove taste.

The fastest draft can still choose the wrong hierarchy, flatten a real workflow into a generic pattern, invent component APIs the team will regret, or pass tests while the product feels off. The tool can write code. It cannot own the promise the product makes to the person using it.

That is why I do not think the strongest AI-assisted engineers are the ones who generate the most code. The strongest ones build a loop around the code: context, intent, constraints, draft, critique, verification, and release proof. They know when to accept generated momentum and when to slow down because the product decision is still unresolved.

For my site, this matters because I want the work to read like someone who can operate in modern engineering teams without outsourcing judgment to the machine.

ContextWhat exists

Repo patterns, product promise, user state, design system, data contracts, and risk.

DraftWhat changed

Generated code, copy, components, migration, tests, and local assumptions.

TasteWhat holds

Hierarchy, scope, system fit, recovery path, and verification that proves the work.

Start with product intent

Before asking an agent to code, I want the product intent written in plain language. The prompt should not only describe files; it should describe the promise being improved.

I would pressure-test that decision with four questions:

• What should users understand or do?
• What product pressure created the task?
• Which behavior must remain stable?
• Which tradeoff is acceptable?

The failure mode here is starting with implementation details before the product decision is clear. In AI-assisted implementation where code speed, product judgment, interface taste, and verification all have to stay connected, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a prompt header with product intent, invariant behavior, and explicit non-goals. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is generated code that can be judged against a real product target. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a prompt header with product intent, invariant behavior, and explicit non-goals beside the question “What should users understand or do?” before the first implementation review. The next pass would use “What product pressure created the task?” to test the boundary, then “Which behavior must remain stable?” to expose the state most likely to be missed. I would keep “Which tradeoff is acceptable?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports generated code that can be judged against a real product target.

Feed the local system to the agent

AI output gets weaker when it is asked to invent in a vacuum. The task should include the local component patterns, styling rules, data shape, and testing habits.

The practical review starts here:

• Which components already exist?
• Which helpers are preferred?
• Which design tokens matter?
• Which tests or scripts prove the work?

Those questions keep letting the agent create a parallel style because it did not see the system from becoming the default. I would capture the decision in a context bundle that names local patterns before code generation begins, then use it while the work is still cheap to change. For AI-assisted engineering judgment, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like work that feels native to the codebase. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a context bundle that names local patterns before code generation begins part of the working surface. I would use it to answer “Which components already exist?” while scope is still flexible, and “Which helpers are preferred?” before code or content becomes expensive to unwind. During QA, “Which design tokens matter?” and “Which tests or scripts prove the work?” become concrete checks rather than discussion prompts. That sequence turns AI-assisted engineering judgment into something the team can operate and gives me a specific outcome to report: work that feels native to the codebase.

StateDoes it recover?

Empty, loading, stale, failed, restricted, and partial states.

SystemDoes it belong?

Local components, tokens, helpers, event names, and release habits.

ReaderCan it be reviewed?

Small scope, clear intent, receipts, and a PR story humans can trust.

Keep taste decisions human

The agent can suggest hierarchy and copy, but I want the human to own the final product taste decisions.

Before implementation, I would answer:

• What hierarchy should lead?
• Which state needs the most care?
• What copy sounds like the product?
• What should feel restrained?

The artifact is a human decision note for hierarchy, copy, density, and interaction tone. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is accepting plausible generated taste because it looks polished enough; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is a product surface that feels authored instead of assembled. That connects agentic coding as a product craft loop, not an outsourcing trick to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “What hierarchy should lead?” easy to answer. The boundary should force a decision about “Which state needs the most care?” and “What copy sounds like the product?.” I would record both in a human decision note for hierarchy, copy, density, and interaction tone, including the part that stayed unresolved after the first pass. The final check, “What should feel restrained?,” is where the artifact earns its place: it either supports a product surface that feels authored instead of assembled, or it shows exactly why another iteration is needed.

Use generated critique, not generated confidence

After the first draft, I prefer asking another pass to attack the work. The useful output is not praise; it is missing states and weak assumptions.

I would use these prompts during the working review:

• Which state is missing?
• What is vague?
• Where did it ignore local patterns?
• What could regress?

If the team slips into asking whether the output is good and receiving generic reassurance, the product can still look complete while its operating rule stays ambiguous. I would make a critique prompt that asks for findings with location, impact, and fix the shared reference and keep it small enough to update as evidence changes.

The standard is a stronger second draft with visible review pressure. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a critique prompt that asks for findings with location, impact, and fix, review it against “Which state is missing?,” implement the narrowest useful path, and then return with evidence for “What is vague?.” I would use “Where did it ignore local patterns?” to inspect product consequence and “What could regress?” to decide whether the result is stable enough to ship. This keeps asking whether the output is good and receiving generic reassurance visible as a known risk and makes a stronger second draft with visible review pressure the release receipt rather than a hopeful conclusion.

Must keepInvariants

Routes, contracts, public copy, accessibility, analytics, and product behavior.

Can changeImplementation

Helpers, structure, naming, tests, and internal composition.

Must proveReceipts

Build, route checks, screenshots, migration checks, and reviewer focus.

Narrow the diff before polish

Agentic coding makes it easy to accumulate adjacent improvements. The diff should be narrowed before anyone debates polish.

I would pressure-test that decision with four questions:

• Which files are necessary?
• Which edits are unrelated?
• What can wait?
• What makes review cheaper?

The failure mode here is shipping a PR that mixes feature, refactor, copy rewrite, and format churn. In AI-assisted implementation where code speed, product judgment, interface taste, and verification all have to stay connected, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a scope trimming pass before final QA. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is a reviewable change that earns trust. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a scope trimming pass before final QA beside the question “Which files are necessary?” before the first implementation review. The next pass would use “Which edits are unrelated?” to test the boundary, then “What can wait?” to expose the state most likely to be missed. I would keep “What makes review cheaper?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports a reviewable change that earns trust.

Check production-shaped states

Generated UI often handles the ideal case first. Product taste shows up when the ugly states get the same attention.

The practical review starts here:

• What happens with long content?
• What happens when data is missing?
• Can the user recover?
• Does mobile still work?

Those questions keep checking only the screenshot the agent made look clean from becoming the default. I would capture the decision in a fixture set that covers ideal, damaged, empty, restricted, and failed states, then use it while the work is still cheap to change. For AI-assisted engineering judgment, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like an interface that survives real product pressure. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a fixture set that covers ideal, damaged, empty, restricted, and failed states part of the working surface. I would use it to answer “What happens with long content?” while scope is still flexible, and “What happens when data is missing?” before code or content becomes expensive to unwind. During QA, “Can the user recover?” and “Does mobile still work?” become concrete checks rather than discussion prompts. That sequence turns AI-assisted engineering judgment into something the team can operate and gives me a specific outcome to report: an interface that survives real product pressure.

Make verification part of the prompt

The prompt should name the expected proof before the implementation starts. That keeps the work tied to behavior.

Before implementation, I would answer:

• Which command must pass?
• Which route must be opened?
• Which asset should exist?
• Which migration must be listed?

The artifact is a verification checklist inside the task prompt. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is deciding after the fact what proof might be enough; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is a workflow where generated code arrives with an expected QA path. That connects agentic coding as a product craft loop, not an outsourcing trick to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Which command must pass?” easy to answer. The boundary should force a decision about “Which route must be opened?” and “Which asset should exist?.” I would record both in a verification checklist inside the task prompt, including the part that stayed unresolved after the first pass. The final check, “Which migration must be listed?,” is where the artifact earns its place: it either supports a workflow where generated code arrives with an expected QA path, or it shows exactly why another iteration is needed.

Write PRs for human reviewers

A PR created with AI should be easier to review, not harder. The description should explain what changed, why it changed, and where the reviewer should look.

I would use these prompts during the working review:

• What is mechanical?
• What needs product judgment?
• What was verified?
• What risk remains?

If the team slips into assuming the reviewer will infer intent from a generated diff, the product can still look complete while its operating rule stays ambiguous. I would make a reviewer-focus block in every AI-assisted PR the shared reference and keep it small enough to update as evidence changes.

The standard is a PR that respects human review time. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a reviewer-focus block in every AI-assisted PR, review it against “What is mechanical?,” implement the narrowest useful path, and then return with evidence for “What needs product judgment?.” I would use “What was verified?” to inspect product consequence and “What risk remains?” to decide whether the result is stable enough to ship. This keeps assuming the reviewer will infer intent from a generated diff visible as a known risk and makes a PR that respects human review time the release receipt rather than a hopeful conclusion.

Keep the paper trail small

Receipts do not need to become bureaucracy. They need to be small enough to maintain and specific enough to matter.

I would pressure-test that decision with four questions:

• What did the agent do?
• What did the human decide?
• What proof exists?
• What follow-up remains?

The failure mode here is creating giant process notes no one will read. In AI-assisted implementation where code speed, product judgment, interface taste, and verification all have to stay connected, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a four-part receipt: agent task, human decision, verification, follow-up. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is evidence that survives later questions. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a four-part receipt: agent task, human decision, verification, follow-up beside the question “What did the agent do?” before the first implementation review. The next pass would use “What did the human decide?” to test the boundary, then “What proof exists?” to expose the state most likely to be missed. I would keep “What follow-up remains?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports evidence that survives later questions.

Show the loop in candidate work

The strongest portfolio angle is not that I used AI. It is that I built a reliable human-in-the-loop workflow around it.

The practical review starts here:

• What did AI accelerate?
• Where did I correct it?
• What artifact proves judgment?
• What shipped safely?

Those questions keep presenting AI work as magic output without showing taste or ownership from becoming the default. I would capture the decision in a case-study sidebar showing prompt, critique, accepted change, rejected change, and QA receipt, then use it while the work is still cheap to change. For AI-assisted engineering judgment, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like a candidate signal that matches modern engineering reality. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a case-study sidebar showing prompt, critique, accepted change, rejected change, and QA receipt part of the working surface. I would use it to answer “What did AI accelerate?” while scope is still flexible, and “Where did I correct it?” before code or content becomes expensive to unwind. During QA, “What artifact proves judgment?” and “What shipped safely?” become concrete checks rather than discussion prompts. That sequence turns AI-assisted engineering judgment into something the team can operate and gives me a specific outcome to report: a candidate signal that matches modern engineering reality.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a prompt header with product intent, invariant behavior, and explicit non-goals
• a context bundle that names local patterns before code generation begins
• a human decision note for hierarchy, copy, density, and interaction tone
• a critique prompt that asks for findings with location, impact, and fix
• a scope trimming pass before final QA

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because agentic coding as a product craft loop, not an outsourcing trick becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

RejectToo broad

The agent expanded scope, invented patterns, or ignored local constraints.

RefineAlmost right

The draft works but needs hierarchy, copy, states, or system alignment.

ShipProved

The change is scoped, reviewed, verified, and connected to product intent.

Resource path

The practical follow-up I would build is an agentic coding taste checklist with intent, constraints, states, local patterns, verification, and reviewer notes. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• What should users understand or do?
• Which components already exist?
• What hierarchy should lead?
• Which state is missing?
• Which files are necessary?
• What happens with long content?
• Which command must pass?
• What is mechanical?
• What did the agent do?
• What did AI accelerate?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For AI-assisted engineering judgment, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• an interface that survives real product pressure
• a workflow where generated code arrives with an expected QA path
• a PR that respects human review time
• evidence that survives later questions
• a candidate signal that matches modern engineering reality

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• Agentic coding needs a taste loop around the generated diff.
• Taste shows up where generated code meets product reality.
• A useful agent task has boundaries before it has code.
• Product taste keeps AI work from becoming generic output.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to AI-assisted implementation where code speed, product judgment, interface taste, and verification all have to stay connected: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through agentic coding as a product craft loop, not an outsourcing trick. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

Agentic coding with product taste is a hiring signal because it shows I can use AI to move faster without losing the human judgment that makes product work worth shipping.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.