Learning AI tools by building things
A real task, a clear result, and a closer look at what the tool actually did.
Dijedon Tahiri 3 min read
There are more AI tools I could try than hours I could give them.
I like exploring new ones. But when I want to understand whether a tool belongs in my workflow, I give it a small job with a result I can inspect.
A page. A form. One complete interaction. Something I can open, use, and judge for myself.
Give it a job you can finish
A big request gives a coding agent a lot of decisions to make. That can be useful when I’m exploring an idea. It becomes harder to review when I’m trying to understand a particular tool.
I prefer to start with a task I can explain clearly. Who will use it? What should they be able to do? What would count as a finished result?
Writing that down does some of the thinking before the tool starts. It also gives me a way to tell whether the output meets the need.
A small button can be a useful test
Take the theme switch at the bottom of this website.
The visible part is a small set of theme icons. The behavior takes a little more thought. It should follow the reader’s system preference until they choose a theme, remember that choice, and keep it when they open another page or reload.
The colors need attention too. The dark background here is charcoal gray. Text, links, photographs, and logos all need to remain readable against it. A theme that changes the background but makes part of the page disappear is unfinished.
That is a manageable feature to work through with an agent. It has a visible result and specific behavior to check. I can use the button on a phone, move between pages, reload, and see whether the choice stays.
It also shows why the first screenshot is only part of the review.
Open the result and use it
My workflow uses Codex and Claude Code for implementation. I own the product direction, design, architecture, review, testing, and release.
That means I need to read what comes back and try the experience. If I asked for a form, I want to submit it. If I asked for navigation, I want to follow the links and come back.
I also want to try the less comfortable cases: an empty result, a failed request, a missing field, or a narrow screen. Those are often where a feature that looked complete still needs work.
If I find a problem, I can describe what happened, what I expected, and the smallest change needed. The next attempt has a clearer target.
Take one lesson into the next task
I don’t need a new tool to do everything before I can learn something from it.
A small finished task can show me where the tool helps, where I need to explain the problem better, and which decisions still need close review. Sometimes it also shows me that the tool is a poor fit for the work.
That is useful information. I can adjust the next task instead of collecting more output that I haven’t checked.
I still enjoy the first moment of trying something new. Finishing a piece of work gives that excitement somewhere to go.
My first experiments with AI started with curiosity. Building real things is how I keep learning from it.