I care more about the AI product I can use

When I choose a tool, I care about the work I can finish with it today.

That sounds obvious. AI makes it surprisingly easy to forget. A demonstration appears, people speculate about what the company has behind closed doors, and the conversation moves to the next release before anyone has used the last one.

I enjoy seeing what people are building. But a company’s future research and my current development tools belong to different decisions.

I can be curious about the first while choosing the second from what is available.

A demonstration leaves questions open

Imagine a coding tool that completes a difficult task in a video.

The video gives me a reason to investigate. To decide whether I can use the tool, I still need to know whether I can get access, what it costs for my work, and whether the result holds up on my project.

Those questions become more useful as they become more specific.

Can it run the checks my project needs? Can I inspect the files it changed? What happens if the session stops halfway through? If I reach a usage limit, can I finish the task another way?

A good demonstration can coexist with an answer that makes the product unsuitable for me. That doesn’t make the demonstration fake. It means the product has a boundary the demonstration didn’t explain.

The drawing separates a promised capability from a completed job. Access and verification sit between them, because those are steps the person using the product still has to take.

Waiting has a cost too

Suppose I need to investigate a slow build.

One available agent can read the project, run measurements, and help me compare the results. Another product promises a much more capable system soon.

I would use the available one if it can do the investigation. I can reconsider when the other product becomes available.

Waiting for a better tool would leave the slow build untouched. And rebuilding my workflow around a promised feature would create work before I know whether the feature fits.

This applies to small software companies too. If I announce an integration, people need to know whether it exists, whether they need an invitation, and what they can use while they wait. An announcement that mixes these states makes it harder to plan around the product.

I would rather give someone a clear limitation than let them discover it halfway through their job.

Judge the part you depend on

The tool doesn’t need to win every comparison.

If I mainly use an agent to work on local applications, local file access and a reviewable result deserve more attention than a benchmark for an unrelated task. Someone using a hosted environment will have different requirements.

That is why I find broad arguments about which company is ahead less useful than trying the same task with the tools I can access.

The trial can stay small. Choose one ordinary job. Keep the starting files and instructions. Record what you had to correct, including work you did outside the tool. Inspect the final application yourself.

An impressive answer that takes an afternoon to repair belongs in that record too.

There is room to change your mind later. I don’t need a prediction about a company’s next year to choose what helps me finish this afternoon. When a new product arrives, I can give it the same job and compare the result.

Want me to talk about your product? You can sponsor this site.