When I say I use Claude Code and Codex as part of product work, I do not mean that I treat them as magic or that I think the interesting part is pure code generation. I mean they are part of how I shorten the loop between a rough idea, a workflow question, and something real enough to evaluate.

A better question than “do you use Claude Code or Codex?” is usually: what have you actually built with them, and what kind of judgment did that work require?

Some concrete examples from my recent work:

1. A recruiting and outreach workspace with real operating structure. I built a one-target recruiting workspace that turns a company or role into a grounded package: context, dossier, goal pack, proof assets, outreach drafts, and next steps. The important part is not that an LLM can write copy. The important part is deciding how much should be deterministic, how the artifacts should stay reusable, and how the system should push toward a real conversation instead of a pile of prompts.

2. A live weather dashboard using real public data. I built Forecast Desk, a real-time weather dashboard on top of National Weather Service data. That is not an AI product in the usual sense, which is partly why it is useful proof. The same tools are helpful outside explicitly AI-branded products when the job is to reason about a workflow, shape an interface, turn messy data into something legible, and ship.

3. This site’s AI-facing profile and discoverability layer. I used these tools to build and refine pages around AI product builder, AI product operator, AI labs, and product people using Claude Code and Codex. That included first-person writing, schema cleanup, canonical fixes, llms.txt, and a machine-readable profile JSON route. Again, the hard part was not merely writing markup. It was deciding what claims were honest, what proof mattered, and how to package the story so both people and machine readers could understand it.

4. Small workflow and research products that make an idea testable. Projects like Compounder, Bookmark, and The List are useful because they turn an instinct into a visible system. Some are more AI-shaped than others. What they share is that they compress the time between “I think there is something here” and “now we can see what the product, interface, or workflow actually wants to be.”

The through-line across all of this is not a particular prompt. It is workflow judgment. It is deciding what deserves to become a tool, where speed is genuinely useful, when a rough artifact is good enough to learn from, and when it still needs operator judgment.

It is also worth being explicit about what I am not claiming. I am not claiming that every project was produced automatically, that these tools replace thinking, or that the point is to generate as much output as possible. The value is that they help me iterate faster on real systems, especially when the work sits between product direction, ambiguous workflows, and hands-on execution.

That is why the labels that fit me best are still things like AI product builder, AI product operator, workflow-minded operator, or product person using Claude Code and Codex. Those phrases are only useful if they point back to real artifacts and real judgment. That is the standard I am trying to keep.

If you want the quicker index of shipped work, start with Projects, Work, and the AI profile.