Almost everyone has the same first month. It is more disorienting than the demos suggest, and less mysterious than it feels at the time. Knowing the shape in advance is most of the difference between someone who keeps going and someone who concludes they are not technical.
It will feel like magic, then it will feel confusing
The first twenty minutes are genuinely impressive. You ask for something, it appears, and it works. Then you bring your own problem to it, and it gets harder, because a demo is built to be easy and your problem has your own mess in it: the inconsistent spreadsheet, the document only half of which is current, the process that lives in someone's head.
Neither reaction is wrong. The magic is real, and so is the slog. The gap between them is the actual work, and it is the part that transfers to every project you do afterwards.
It will sound certain when it is wrong
A model that does not know something will often answer anyway, in the same confident tone it uses when it is right. There is no hesitation to listen for. In the workshop this is called hallucination, and it is not a bug that will be fixed before you start. It is a property of the tool, which means the checking has to be done by a person.
The practical default: treat anything you did not ask to be sourced as unverified, and anything you do ask to be sourced as unverified until you have opened the source. Checking the work is the whole next page.
Things that worked will break
A change gets made in one place and not in another. A new request quietly contradicts an earlier one. A file gets renamed and something else still expects the old name. None of this means you did something wrong; it means you changed a system, and systems have parts.
This is the real argument for keeping a history. Not discipline for its own sake: the ability to go back to the version that worked ten minutes ago is what makes experimenting cheap.
Your prompts will be vague at first, and that is the skill you are actually learning
Early prompts tend to describe a mood rather than a task: "make it better", "clean this up", "can you fix this". Later prompts get shorter and more specific: "the second column is wrong when the value is blank, fix that only, and do not change anything else". The improvement is not in the tool. It is in how precisely you can describe the goal and the failure.
That skill is worth more than knowing any particular tool, because it survives every change of model, product, and price. It also happens to be the skill that makes you useful to colleagues: most people cannot describe what they actually need.
Progress is not linear
There will be a day when something works, followed by two days when nothing does. This is normal, and it is not a sign that you peaked on Tuesday. The two flat days are usually the days you learned what your data really looks like, or found the limit of the approach, which is knowledge you needed.
Keep the parts that work. Half-finished experiments are not wasted work. They are your own library of pieces you already understand.
It costs something, in two different ways
The first cost is visible. Every conversation has a meter running, measured in tokens (small pieces of text). Long documents, long conversations, and long answers all add to it. You do not need to track this closely at the start, but you do need to know it is there, so that a surprising bill does not arrive as a mystery. It is also the reason "paste in everything you have" is usually the wrong instinct.
The second cost is not on a bill. Before you paste something into a hosted model, ask what you have just handed over, and to whom: member lists, financials, personal information, anything covered by an agreement. Running a model on your own computer (local models) is one answer to this, and keeping sensitive material out of the chat is often a faster one.
Ethics is weekly homework, not a philosophy seminar
The workshop's ethics section is best used as five questions you ask before pressing send, not as a debate about the future. They take about a minute.
- What data leaves my control when I do this?
- Who owns the material I am putting in, and do I have the right to?
- Whose consent is involved, and have I got it?
- What could this cause harm to, if it is wrong or leaked?
- What must be verified by a person before anyone acts on it?
Written down like that, most of them are the same questions you already ask before sending an email to the wrong list. The pressure is new: these tools make it fast to move information without thinking about where it goes.
You will build things before you can explain them
This is the strangest part of learning to work this way. You will get something running, be pleased with it, and then realise you cannot explain how. That gap is normal, and it closes slowly, mostly by changing things and seeing what happens.
It only becomes a problem when something depends on a tool you cannot explain: a colleague, a member, a payment, a report to a funder. So the useful rule is not "never use what you do not fully understand". It is: be honest about which parts are experiments and which are tools, and do not let anyone else depend on an experiment.
Do not let anything depend on something you cannot explain. That is the line, and it is worth holding from the beginning.
What a month of this looks like
Roughly, if you keep at it in small pieces:
- You can get a small tool running from an empty folder.
- You can usually tell when an answer is being bluffed, and you know how to check.
- You have a folder of half-finished experiments, and at least one thing you actually use.
- You can fix a small breakage without starting over.
- You can describe a problem precisely enough that someone else could act on it.
- You have stopped expecting the first attempt to be the last one.
That last one arrives later than the others, and it is the one that makes the rest sustainable.