How I use AI in product development

AI has changed how much time I spend writing a first implementation. I can ask for a starting point, inspect it, and try an alternative while the problem is still fresh.

The saving is real, but I don't have a useful multiplier for it. A small component can go quickly. A change involving permissions, migrations, or unfamiliar infrastructure can take longer to review than it took to generate.

I judge the workflow by whether the change is ready to ship, not by how quickly code appears.

Start with the repository

Before asking for a feature, I want the assistant to inspect how similar work is already done. Which components exist? Where are permissions enforced? How are errors handled? Which commands run the checks?

That context prevents a common failure: a plausible implementation that introduces a second way of doing something the project already handles.

I give it the intended behavior, relevant constraints, and a boundary. For example: add a filter using the current query state, preserve shareable URLs, and don't change the API. That's easier to review than an open-ended request to improve the dashboard.

I avoid sharing secrets, private customer records, or confidential material unless the tool and its data handling have been approved for that use.

Use it to explore a decision

I often get more value from comparing approaches than from asking for finished code.

For a slow screen, I'd ask which measurements would distinguish a network problem from expensive rendering. For a data model, I'd ask how each option handles the queries we already know we need. I want the assumptions written down so I can challenge them.

An answer can still invent an API or rely on an outdated convention. If the choice depends on a library's behavior, I check its current documentation or run a small test. A confident explanation isn't evidence that the code works in this version.

Keep the change reviewable

I prefer one coherent change at a time. A patch that mixes a feature with formatting, dependency upgrades, and a new abstraction is harder to assess.

After generation, I read the diff. I look for files changed outside the request, unnecessary dependencies, altered defaults, and error paths that silently return success.

I also ask whether I could maintain the result without the conversation that produced it. If the answer is no, the code needs simplifying or a comment explaining the constraint.

For database work, I review the migration and rollback implications separately. For authorization, I check what happens when someone requests another account's data directly. A control being hidden in the UI doesn't establish that the action is protected.

Tests are useful when the assertion is right

AI helps draft tests, especially repetitive cases. It can also write a test that reproduces the implementation's mistake.

I define the behavior I want to protect first. A successful request, a rejected request, an empty result, and a retry may all matter, depending on the feature. The tests should verify outcomes rather than merely confirm that a mock was called.

Then I run them. I also use the feature in the browser when it affects the interface. A passing test suite won't show that the focus ring disappeared or that the dialog is awkward on a phone.

Design still needs the actual product

Generated layouts can be useful sketches. I compare them against real content and the rest of the interface before keeping them.

A screen can look finished while hiding important controls, repeating unnecessary copy, or using animation that gets tiring in daily use. I need to try it with long text, slow loading, keyboard navigation, and the relevant device sizes.

AI can help identify these problems. It doesn't remove the need to decide which suggestions fit the product.

I keep using it because the short feedback loop is valuable. The responsibility for the shipped change stays the same: understand it, check it, and be able to fix it when the assumptions turn out to be wrong.