Review AI-Generated Features for Product Coherence

Product review for AI-generated features asks whether a change solves a real customer problem, fits a clear scope, works through the complete customer journey, and has someone responsible for checking its result. Technical verification still matters. These questions help you decide whether the change belongs in your product before you release it.

An agent can produce a convincing demo before you have settled that decision. You can click the new button, inspect the implementation, and approve the tests. Yet you may still be adding a second way to perform an existing task, a setting nobody understands, or a handoff that leaves someone else doing more work.

In Someone behind the software, published on October 15, Linear cofounder Karri Saarinen describes his concern about individually sensible changes weakening a shared product perspective. The essay prompted an active Hacker News discussion. It is a practitioner’s argument, not evidence that agents generally make products worse.

The useful question is what to inspect when implementation outpaces a settled product decision. Here is a proposed review process with four gates. It draws on customer discovery advice from YC and project practices from Basecamp’s Shape Up. The combined process is our recommendation; it has no measured success rate or claim of scientific validation.

Why can a working feature still weaken a product?

A feature can meet its specification while making the surrounding task harder. Product coherence means the parts support an understandable way of getting something done, including what happens before and after the new interaction.

Imagine adding a shortcut to change an interview time. The shortcut works. But the candidate receives a different message from the one the recruiter sees, and an old link still points to the previous time. Each screen can look reasonable while the overall experience leaves people unsure which arrangement is current.

Saarinen connects product judgment with experience, customer conversations, and attention to how the pieces fit. That gives you something more concrete to discuss than whether a feature feels right. Ask which existing expectations it changes and whether the people affected can still finish their task.

You can apply that question to work produced by a person, an agent, or both. The relevant trigger is a proposed product change. The author of the code does not determine whether it belongs.

Keep the review proportional. A corrected label may need a brief explanation and a screenshot. A new scheduling route needs evidence of the interactions it touches. The four gates below are prompts for that decision, rather than a new approval committee for every edit.

What customer problem does this change address?

Start with an actual episode in which a user struggled. Record what they were trying to do, where the task broke down, and how they handled it with the current product.

In YC’s Startup School recap and transcript, Eric Migicovsky recommends asking about a past encounter with a problem and what the person has already tried. Those questions give you material to examine beyond a reaction to your proposed solution.

For a feature review, attach a support conversation, an observed session, or a clearly described customer example. Separate the observation from your interpretation. “The recruiter copied a new time into two messages” describes behavior. “We need an AI scheduling assistant” proposes a solution with a much wider scope.

Name the affected person as precisely as the task requires. A candidate changing their own booking has different needs from a recruiter coordinating a panel. Treating both as “the user” can conceal the handoff you need to understand.

Your evidence may support a narrow improvement while leaving the broader opportunity uncertain. One customer episode can expose a confusing interaction; it cannot establish how common the problem is across your market. Say what you know, what you infer, and what remains unanswered.

If the feature began with a demo, you can still investigate it. Watch someone attempt the existing task before showing the proposed change. You may discover that clearer wording or an existing link solves the problem. You may also discover a deeper need that the demo missed.

The gate: can you describe the customer’s difficulty without mentioning the feature? If the answer depends entirely on describing what the agent built, investigate the problem before expanding the implementation.

Which tradeoff keeps the feature in scope?

Define the useful outcome and the complexity you are prepared to accept. Include an explicit exclusion so the review has a boundary.

Shape Up’s Set Boundaries chapter describes setting an appetite for a project and narrowing the problem within it. Its calendar example distinguishes the need to see available spaces from the much larger idea of building everything a calendar might do.

Use the same distinction when reviewing a feature. “Help a candidate find the existing rescheduling flow” is a bounded outcome. “Make scheduling effortless” leaves room for new calendars, permissions, reminders, preferences, and exceptions without telling you which part matters now.

Write down the alternative you considered. Could you improve the current route, remove a confusing step, or fix the message that sends people to it? Comparing a new feature with the unchanged product gives the feature an easy opponent. Comparing it with a smaller useful correction makes the tradeoff visible.

Then state what you are declining. For the scheduling example, you might exclude changes to interviewer assignment or notification policy. An exclusion becomes useful when an attractive adjacent idea appears during implementation: you can decide whether the new evidence warrants reopening scope.

Also consider the ongoing cost. Someone must explain the feature, maintain its states, translate its messages, and handle its failures. You do not need a speculative financial model for every button. You do need to notice when a shortcut creates another interaction that your team must keep consistent.

The gate: can you explain why this version is worth maintaining compared with the smaller alternative? If that remains unclear, narrow or reshape the proposal. A working implementation is still available to learn from even when you decline to ship it.

Does the complete workflow still make sense?

Try the change as part of a real task, including saved state and the next person’s experience. A polished screen or isolated component cannot show you the whole interaction.

Shape Up’s Get One Piece Done chapter advocates integrating a usable slice so people can try it. Apply that idea to review by following the task from its trigger through the resulting handoff.

For a rescheduling change, begin where the candidate actually encounters the invitation. Follow the link, choose a time, save it, and return to the booking. Then inspect what the recruiter sees and which messages each participant receives. Check that the result persists when you leave the page.

Choose the awkward cases according to the change. A slot may become unavailable before confirmation. A candidate may reopen an old link. An interviewer may cancel while another person has the page open. You cannot exhaust every possibility in a walkthrough, but you can expose the assumptions that deserve technical verification.

Look at the surrounding experience too. Does the new route use familiar labels? Can someone recover after an error? Can the relevant person perform the action on a small screen? Does access still depend on the right account or booking authorization?

Keep the evidence precise. A recording establishes what happened along the recorded path. Automated tests establish behavior within their assertions and setup. Neither justifies a broad statement that the entire product is correct.

This is related to the discipline in testing take-home assignment instructions with a fresh reader: watching someone follow the actual route can reveal gaps that the author no longer notices. Here, the decision extends to whether the feature fits the surrounding product at all.

The gate: can the intended person finish the promised task, and can the next person understand the result? If a handoff breaks, repair it or reduce the promise before release.

Who owns the result after release?

Assign someone responsibility for the change and specify what they will observe afterward. Ownership should continue through learning whether the change helped.

In Hand Over Responsibility, Shape Up describes assigning a whole bounded project to a team that works out its tasks. That supports autonomy within clear boundaries. Your founder does not need to approve each implementation choice to preserve a coherent product.

Name the person who can answer questions about the decision, bring the relevant people together, and act on what happens next. They might be a product lead, designer, engineer, or founder. The team can share the work while keeping the point of contact clear.

Choose an observation that connects to the original problem. If candidates could not find how to change a booking, inspect whether they can now complete that task and whether related support conversations change. Clicks on the new button alone leave the original question unanswered.

For low-volume products, direct follow-up with affected customers may tell you more than a dashboard. For busier flows, you may also examine completion and failure events. In either case, avoid treating a change after release as proof of causation when other conditions changed too.

Decide what would prompt another change or removal. Perhaps the shortcut adds confusion, duplicates an existing route, or shifts coordination work to recruiters. Those are reasons to reconsider the product decision even if the implementation remains technically sound.

If you are evaluating agent economics, keep that assessment explicit as well. Cost per accepted outcome concerns the pilot’s economics. The review here asks whether this particular outcome deserves acceptance.

The gate: who will return to the original customer problem, and what will they inspect? Assign that responsibility before release so the question survives the launch.

Use the four gates on a rescheduling change

Consider a hypothetical proposal: an agent adds a prominent reschedule button to an interview confirmation page. This is a worked example, not a report of a Kit incident or an announced feature.

Your starting evidence is a customer conversation describing difficulty finding the existing route. The proposal may address that problem. It does not yet establish a need for a new scheduling mechanism.

At the scope gate, compare the prominent button with a clearer existing link. Suppose both lead to the same current rescheduling flow. You can then evaluate discoverability without also redesigning how available times or participants are selected. Keep that choice in the review description.

At the workflow gate, follow the route through a successful change and a failed attempt. Inspect the stored booking, the candidate’s return visit, the recruiter’s view, and notifications. Check what an old invitation shows after the time changes. A button that reaches the right page has completed only the first part of this review.

These dependencies are concrete in Kit’s existing scheduling code. Rescheduling checks timing, booking state, host and participant availability, updates the stored booking and calendar sequence, and queues notifications. That describes responsibilities in the implementation; it does not guarantee that every external message is delivered. It explains why a seemingly small product change needs a view of the surrounding task.

At the ownership gate, identify who will inspect subsequent attempts and related feedback. They should know whether the candidate’s original difficulty was resolved and whether the new prominence creates another problem, such as people expecting to change a booking that is no longer eligible.

You can keep the review artifact compact:

Use dispositions such as accept, narrow, investigate, or decline. A numerical score would imply precision these prompts do not have. When you hold a change, state the missing evidence and the next action so the team can resolve the decision.

Apply the same discipline to your recruiting workflow

Recruiting makes product coherence tangible because a candidate’s action changes what a team needs to do next. Interview times, stage progress, participant expectations, and messages need to agree for the process to make sense.

Kit provides hiring and scheduling workflows where those connections matter. It does not supply the product review gates proposed here, validate customer research, or certify agent-produced features. Your team remains responsible for deciding which changes belong and checking their effects.

Before accepting your next feature, write down the customer problem, scope tradeoff, complete path, and owner. Bring evidence proportionate to the change, then make the decision. If you are exploring a recruiting workflow for your startup, you can try Kit and examine how its candidate and team interactions fit your process.