Ask Knox

You built a tool. You debugged it. You gave it a version history. Now it is time to put it to use — and to choose what comes next.

This lesson is about the final step most people skip: actually running their tool consistently, treating it as part of their workflow rather than a project on a shelf.

What "Shipping" Means for a Personal Tool

For the kind of tool you built in this track, shipping does not mean uploading to an app store or getting your code reviewed by a team. It means one thing: you run it, on real data, on a real schedule, and it saves you time.

That is the entire bar. A script you run every Monday morning is shipped. A script that sits on your laptop unused is not.

The Pre-Ship Checklist

Before you run your tool on a full dataset for the first time, go through these:

Test on a small sample. Take ten rows from your spreadsheet, five files from your folder, whatever the minimum is that reflects real data. Run the script on that subset. Review the output carefully. Does it look right? Are the columns correct? Is the filtering behaving as expected?

Save a commit. If the test looks good, commit the version you just tested. Label it something like "working version, tested on sample." This is your safety net.

Run it on the real dataset. Open the output file. Review it before doing anything with it. The first full run deserves your full attention.

Note anything to fix. Almost certainly there will be one small thing — a column format you did not expect, an edge case in the data, a label that could be clearer. Write it down. Fix it in the next session.

After two or three rounds of this, you will trust the output at a glance rather than line-by-line. That is when the time savings really compound.

Keeping the Tool Running

A script that works today might need a small update in three months when your data format changes, or when you want to add a new filter, or when a column is renamed. That is not a problem — it is just maintenance.

When that happens, go back to Claude, describe what changed, and ask for the update. The version history from the previous lesson means you can always revert if the update creates a problem.

A well-maintained tool improves over time. Each round of maintenance makes it a closer fit to how you actually work.

Where You Go From Here

You are now a builder. You have the foundation. Where you go next depends on what you want to build.

Three tracks extend from here, each going deeper in a different direction.

claude-code-basics is for builders who want Claude to write and edit code for them directly in the terminal. You describe what you want; Claude does the typing. This is the fastest path to building more complex tools without writing every line yourself.

building-with-claude is for builders who want to call the Claude API from their own Python scripts — building tools that use Claude's reasoning as a component, structuring prompts as reusable functions, and adding AI into existing workflows programmatically.

codex-basics is for builders who want tools that run in the cloud, connect to external services, and operate 24/7 without a laptop open. This is the agent-builder path.

All three build directly on what you learned here. None of them require you to become a full-time developer. They are designed for people who build tools for their own work — not for people who write software for other people.

How to Pick

If you want to build faster by letting Claude write code for you → claude-code-basics

If you want to wire Claude's AI into your own Python scripts and automations → building-with-claude

If you want tools that run in the cloud without your laptop → codex-basics

You can take all three eventually. Pick the one closest to your next goal and start there.

What You Accomplished

You started this track as someone who used AI tools. You are finishing it as someone who builds them. That shift — from user to builder — is the most valuable career move available right now, and you made it.