Building good products with AI

I’m a software developer who likes building products. AI has expanded the kinds of things I can make, and how much of an idea I can take from a sketch to something people can use.

A lot of my earlier writing focused on verification: checking citations, evaluating extraction, and deciding when a system should decline to answer. I still care about that work. It’s one part of making a good product, alongside the interface, the underlying data, performance, and all the small decisions that make an experience feel considered.

Start with what someone wants to do

With NoeticMap, I wanted to make accounts and research about consciousness easier to explore. That meant building an extraction pipeline, but it also meant deciding how people would find material, move between related ideas, and return to the original source. The pipeline gives the interface something useful to work with. The interface determines whether anyone can actually use it.

PermitCheck asks a more practical question: what does someone need to understand before moving ahead with a permit application? Enacted helps people follow changes to legislation. Each needs a different experience, even when some of the underlying engineering overlaps.

Give AI a clear role

In Enacted, code computes the changes to legislation and the model explains them in plain English. Keeping those responsibilities separate makes it easier to investigate a mistake. I can check the diff and the explanation independently.

In a research pipeline, I need to think about extraction schemas, source references, retries, and how partial results become searchable records. A model call is part of that process. The work also includes queues, storage, data contracts, and a way to inspect what happened when a job failed.

I enjoy this part of building: turning a capability into a system that fits the product.

Make the uncertain parts understandable

An answer can look polished and still be wrong. When something matters, I want a person to be able to inspect its source and understand its limits. That affects what I store, what I test, and what the interface shows.

Small evaluation sets have helped me catch regressions and mistakes in my own rules. They’re useful feedback while I’m changing a pipeline. They don’t replace trying the product, watching where it gets confusing, or noticing when a technically correct result is hard to use.

Keep working on the experience

I care about how software looks and feels. Typography, motion, loading states, and the way information is arranged all affect whether a product is pleasant to spend time with.

AI helps me build more ambitiously. My job is still to decide what’s worth making, put the pieces together, and keep improving the result.