The question working professionals ask most is some version of "what should I be learning?" It is usually the wrong question. Most people asking it are not short of things to learn. They are short of a reason to choose.
A four-question diagnostic
1. What do I actually do, in tasks, over a normal week? Write ten of them down.
2. Which three of those would matter most if they took half the time or had fewer errors?
3. For those three, can I tell when the output is wrong without help? If not, that task is not where to start.
4. What has my employer already approved that I am not using?
The task that scores highest on questions 2 and 3, using a tool from question 4, is your starting point. Not the most interesting technology. The task.
What not to do
- Do not start with a course on prompting. Prompting is a small skill you will pick up in a week of real use.
- Do not collect certificates. A certificate shows that you completed a course. A working automation with a measured result shows that you can apply AI to a real problem. In professional settings, the second is usually the stronger evidence of capability.
- Do not invest deeply in agents, RAG or fine-tuning until you have a problem that needs them. Know what they are and which problem each solves. Chapter 8 covers that. Learn to use or master them when the work requires it.
- Use demos for orientation, not as evidence. A demo is usually a task selected to show the technology at its best.
The first thirty days, for someone who does not write code
Week 1. Pick the task. Do it the current way once more and record the time and any errors. This is your baseline. Without it you cannot claim improvement.
Week 2. Do it with the approved tool, following the data-boundary rules in chapter 3. Write a reusable instruction for it. Keep every wrong output in a file with a note on what was wrong.
Week 3. Fix the instruction based on the failures. Add a structured output, a list of fields, if the task produces something repeatable. Try it on ten fresh examples.
Week 4. Compare against the baseline honestly, including review time. Write half a page: what improved, what still fails, whether you would use it. Show it to one person who would benefit.
That half page is worth more than any certificate. If you do write code, follow the same shape, but week 2 goes through an API with a schema and a validation step, and week 4's deliverable is a small service with ten test cases, including two that should refuse. Part C is the depth material once that exists.
When to stop learning and start finishing
Ask, every month: if I learned nothing new for six months, what would I be unable to deliver? If the answer is "nothing I am asked for," the gap is not knowledge. Spend the time finishing the automation or improving the domain skill.