If you lead a business function, an analytics team or a data science initiative, you may already know how to frame a problem and challenge a conclusion. The next step with AI is to connect that judgment to something you can build, inspect and explain.
I would start with one coding assistant, one familiar business problem and three weeks of focused practice. Each week should leave you with something concrete: a working tool, evidence about its quality and a decision about what to do next.
This roadmap is for someone in a leadership role, or preparing for one, who wants to learn Claude or Codex well enough to guide technical work and make informed decisions. It assumes some comfort with spreadsheets or analytical work. If you are starting from scratch, use the 90-day AI roadmap for non-IT professionals for a gentler pace.
What you are working towards
At the end of this practice cycle, aim to have:
- A small business prototype you can run and demonstrate.
- A short record of the design choices you made and the alternatives you considered.
- A set of checks showing what works, what fails and what you verified yourself.
- A one-page decision memo explaining whether the idea deserves a further pilot.
Plan for roughly 45 to 60 minutes on most days, with longer sessions when setup or debugging needs them. Repeat a day when necessary. These are milestones to work through, not a deadline for becoming an AI engineer.
Choose your starting workspace
Pick one tool for the first two weeks. I suggest Claude Code as a starting point if you want to learn within the Claude desktop app. If you already prefer Codex, follow the same exercises there. The learning comes from making requirements clear, reviewing changes and checking results.
With Claude: use Claude chat to discuss the business problem, then use Claude Code for work on project files. Claude Code is available through the desktop app's Code workspace; follow the official desktop guide. Ordinary chat and a coding workspace serve different purposes.
With Codex: follow the official quickstart, choose Codex for software development and select a dedicated project folder. Keep the first task small enough to inspect the resulting files and changes.
A separate code editor is optional at the beginning. Your project may still require Python or another runtime and a few libraries. Ask the assistant to explain what is needed, why it is needed and how to run the result. Check current access and plan requirements in the official guides before subscribing.
Use one project throughout: a business review assistant
Build a small tool that helps a leader prepare for a weekly business review. Use a fictional dataset with two periods, a few product categories and fields such as revenue, cost of goods sold, units sold and customer feedback. Define gross profit as revenue minus cost of goods sold, keeping operating expenses separate.
The question is simple: What changed, what can we verify and what should the team investigate next?
Your first version should calculate revenue, gross profit and period-over-period changes; display a clear table or chart; and provide an evidence summary you can use to draft a decision brief.
Keep calculations in code. Ask Claude or Codex to help build and review that code. A model's explanation should refer to the calculated results and distinguish an observation from a possible explanation. A fall in revenue, for example, does not establish why customers bought less.
For someone comfortable with Python, a small Python app with pandas and a simple interface is a reasonable starting point. Ask the assistant to compare a lightweight option such as Streamlit with an alternative, then choose one. You do not need to add every framework it suggests.
One distinction matters: using Claude or Codex to build software does not automatically make the finished software an LLM application. You can keep interpretation as a separate, manual conversation with the assistant for this first version. Embedding an LLM inside the app is a later extension with its own API setup, costs and evaluation needs.
Week 1: build something you understand
- Day 1. Choose your workspace and create a dedicated project folder. Write the user, business question and boundaries. Keep: A one-page project brief.
- Day 2. Create a small fictional CSV. Define each column, its unit and the two periods being compared. Manually calculate a few expected totals. Keep: A data dictionary and known answers.
- Day 3. Ask for a plan before code. Review the proposed files, libraries, data flow and simplest useful interface. Keep: A small architecture sketch and your choices.
- Day 4. Build only the CSV input and core calculations. Run the result and compare it with your manual totals. Keep: A working calculation step.
- Day 5. Add one useful table or chart and a plain evidence summary. Keep: A small interface you can use.
- Day 6. Ask the assistant to explain the main files. Make one small change yourself with its help, then inspect the difference. Keep: A change you can explain.
- Day 7. Run the tool again from the written setup instructions and demonstrate it in two minutes. Keep: A README and a short walkthrough.
Start with this prompt:
I am building a learning prototype for a weekly business review.
Use fictional data only. The user is a leader reviewing performance.
The tool should compare two periods and show verified changes.
Before writing code, propose the smallest useful version.
Explain the data flow, dependencies and two reasonable design options.
Tell me which decisions I need to make and what information is missing.
Keep external services and paid APIs out of this first version.
Wait for my choice before implementing the plan.Leadership checkpoint: Can you explain where the numbers come from, why you chose this design and what the tool cannot answer? If you cannot, spend another session there before adding features.
Week 2: learn to evaluate and challenge it
A convincing screen is only the beginning. This week, find out whether the tool behaves sensibly when its inputs are incomplete, inconsistent or misleading.
- Day 8. Write ten checks covering calculations, input handling and the claims in the brief. Define the expected result before running each one. Keep: A small evaluation sheet.
- Day 9. Try an empty file, missing values, invalid numbers and a zero value in the comparison period. Decide how each should be handled. Keep: Expected versus actual results.
- Day 10. Try duplicate rows and an extreme value. Choose whether to reject, flag or retain each case and explain why. Keep: Explicit data-quality rules.
- Day 11. Give the assistant only verified metrics and fictional feedback. Ask it to draft a short brief with evidence for each finding. Keep: A traceable draft brief.
- Day 12. Challenge the brief: ask what it cannot conclude and which alternative explanations fit the evidence. Keep: Corrections and unanswered questions.
- Day 13. Compare the workflow with a spreadsheet or manual review using the same inputs. Record effort, errors and usefulness. Keep: A baseline comparison.
- Day 14. Fix the most important failure and rerun the affected checks. Decide whether the first version is useful enough to continue. Keep: An evaluation summary.
Ten checks are a starting exercise, not proof of reliability. Include both ordinary inputs and cases where the correct response is to flag a problem or say there is insufficient evidence.
Use this review prompt:
Review this business brief against the supplied metrics and notes.
For every numerical claim, identify the supporting calculation.
Separate verified observations, assumptions and proposed actions.
Flag unsupported causal claims and missing information.
Do not invent an explanation to fill a gap.
Suggest the next evidence a leader should ask the team to collect.Leadership checkpoint: What evidence would persuade you to trust the output for this task? What would cause you to pause its use? Record both before moving on. Keep the final business decision with the person responsible for it.
Week 3: turn the prototype into leadership evidence
- Day 15. Choose one weakness from your evaluation and improve it. Resist adding unrelated features. Keep: A clear before-and-after example.
- Day 16. Review the main code changes and ask for an explanation of error handling, dependencies and sensitive-data risks. Keep: Questions for a technical reviewer.
- Day 17. Optionally ask the other coding assistant to review one bounded task using the same requirements. Check its suggestions yourself. Keep: A comparison based on correctness and clarity.
- Day 18. Sketch what a limited pilot would need: users, data access, permissions, hosting and a usage budget. Keep: A pilot plan with unresolved questions.
- Day 19. Consider failures after launch: bad inputs, a changed data format, unavailable services and misleading outputs. Assign an owner and a fallback. Keep: A short operational checklist.
- Day 20. Write your one-page decision memo and rehearse a five-minute demonstration. Keep: A memo and a demo outline.
- Day 21. Show the prototype to a colleague or mentor. Collect feedback and choose the next learning goal. Keep: A reviewed backlog and next-step decision.
Your memo should answer five questions:
- What problem does this solve, for whom, and how is it handled today?
- What did you build, and why did you choose this approach?
- What did your checks show, including failures and limitations?
- What value did you actually observe, and what remains an estimate?
- Would you stop, improve the prototype or propose a limited pilot? Why?
This is useful evidence in a project review or an interview because you can show your reasoning alongside the result. Present it honestly as a learning prototype and describe the work still needed before a real deployment.
Where RAG, agents and deployment fit next
Once the first project works, choose the next topic according to the problem you need to solve.
| Your next need | Topic to explore | Main check |
|---|---|---|
| Answers from documents | RAG | Evidence and citations |
| Repeatable tasks | Defined workflows | Checks between steps |
| Model-selected tools | Constrained agents | Permissions and approval |
| A tool for real users | Controlled deployment | Access and monitoring |
RAG, or retrieval-augmented generation, means finding relevant document passages before generating an answer. Check whether the system retrieves the right evidence, cites it correctly and declines unsupported questions.
A defined workflow follows a planned sequence. Before using an agent, ask whether a fixed sequence would solve the task more predictably.
An agent can let the model choose which tools to use. Decide what it may do, when it must stop and which actions need human approval.
Deployment brings operational responsibilities. Decide who can access the data, who handles failures, how you will monitor quality and costs, and how to roll back.
You do not need to implement all four in three weeks. Anthropic's guide to building effective agents explains the distinction between defined workflows and model-directed agents, and why simpler approaches are often a useful starting point.
If you are aiming to lead AI engineering work, plan further practice in model APIs, evaluation, retrieval, security and deployment with technical feedback. The three-week project gives you concrete questions to take into that learning.
Build accountability into the routine
At the end of each session, write five lines:
- What I built.
- What failed or confused me.
- What I verified myself.
- What I decided, and why.
- The next small task.
Arrange a short weekly review with a colleague, peer or mentor. Bring the working project and one unresolved decision. If you are stuck, reduce the task until you can finish and check it in one session.
Use fictional or approved public data while learning. Before using workplace information, check your organisation's rules and the tool's data controls. Our guide to keeping data private covers questions to ask before uploading it.
Your first step today
Choose Claude Code or Codex. Create a project folder. Write one business question and ask for the smallest plan that could help answer it.
By the end of the first week, aim to show something you can run. By the end of the third, aim to explain what it does, how you checked it and whether it deserves further investment. That is a useful foundation for making AI decisions as a leader.
If you would value help choosing a project or reviewing your progress, explore 1:1 mentorship at The Arthi AI Collective. You can also begin independently with this roadmap and bring the questions that emerge from your practice.