AI-first principles
Most AI advice is tactics: new tool, new prompt, new keyboard shortcut. The five below are different. They are how you get the most out of AI without things blowing up the second you turn your back, and they survive every model release and every UI redesign.
1. You are responsible
We mentioned this in the last course, and it is worth saying again. The point is not to be hard on yourself; the point is to put out work you can be proud of. When something feels too easy, sometimes it actually is too easy.
There is a phrase for AI work that is fast, plausible, and slightly off: AI slop. Internally, slop costs you credibility with the people you sit next to every day. Externally, it lands in front of a customer with your name on it. Sometimes it even looks like good work, which is the worst kind, because nobody catches it until it has done its damage. The model produced exactly what it was asked to produce. It cannot be accountable. The accountability comes back to you.
You read the model's draft, push back on a sentence, rewrite the conclusion in your own voice. The output is yours, signed by you, defensible if anyone asks.
You skim the draft, send it, and a colleague flags three vague claims and a wrong number. 'The AI wrote it' does not change whose name is on it.
2. Context is king
The biggest predictor of whether AI output is useful is how much real context the agent had when it started. The more detail and nuance you bring to what you are asking, the more likely the agent is to interpret you correctly. There is no prompt-engineering trick that beats this. The model is doing its best to read your mind, and it cannot.
The cheap ways are usually the best ways. Paste the document. Link the brief. Drop in the constraints. If you work a topic regularly, keep the source material somewhere you can grab fast. Later in the bootcamp we look at voice transcription as a way to drop a wall of context into a session in under a minute, since speaking is much faster than typing and you naturally add the kind of detail the agent needs.
You start a session by sharing the brief, the deck you are working from, the constraints from leadership, and a sentence on what you have already tried. The agent's first response is already useful.
You type 'help me with this report'. The agent guesses, asks two clarifying questions, you get bored, the answer is generic. Twenty minutes lost.
3. Focus
It is very easy to keep adding things to a session. One more polish, one more feature, one more nice-to-have. The trouble is that everything you add also adds complexity, and complexity makes the next change harder. The goals you tacked on become weights on the goal you actually came in for.
The discipline is keeping your eye on the original ask and protecting it. Not delivering less, but delivering the thing. Five highly focused projects beat one overstuffed project that fails to make a point. If you cannot describe what “done” looks like in one sentence, you are not ready to start.
You ask for one specific edit: 'Add a TLDR at the top of this doc, three sentences, plain language.' You read it, tweak one word, ship.
You ask the agent to 'tidy up the doc'. It rewrites your intro, drops a paragraph you actually needed, and changes the tone. You skim and send.
4. Start with a plan
It is much easier to steer an agent before it has walked a hundred metres in the wrong direction than after. A plan up front (what you want, what the agent thinks the steps are, what assumptions it is making) lets you catch the wrong assumption while it is still cheap, instead of unwinding an hour of work and a pile of tokens.
The nice side effect: when the plan is good, you can let your agent run for much longer without needing to jump back in. You front-load the thinking, then you trust the execution.
You ask for a plan first. The agent lays out six steps. Step three assumes the wrong audience for the doc; you correct it before any drafting starts.
You skip the plan. Twenty minutes later you have a polished version of the wrong thing, and now you have to argue your way back to the right shape.
5. Build for yourself first
This one is about resisting a very real temptation. You discover something fun, you build a thing, it works, and right away you want to share it with the world. The excitement is genuine, and it is also a trap. Until you have used the thing yourself a fair few times, it is very hard to tell whether anyone else would actually use it.
Maintenance is the part nobody warns you about. A tool you do not personally rely on tends to quietly stop working without anyone noticing, and you keep doing the upkeep anyway. Be your own first user. If it survives your own use, it has earned the right to leave the building. Otherwise you get all of the work and none of the value.
You build a thirty-minute version that solves your own version of the problem, use it for a week, and only then think about whether it generalises.
You spend two days building the polished general version of a tool you have never used. It ships. Nobody adopts it, including you.
The five stack on each other. Responsibility is the floor everything else stands on. Context turns vague prompts into useful sessions. Focus keeps the session small enough that you can defend the result. The plan turns focus into something the agent can actually execute. And building for yourself keeps all of the above grounded in work that matters to a real person, starting with you.
3 quick scenario questions. Pick the best fit, see why.
Hands-on
Pick a real task you have to do today. Something concrete: a section to revise, an email to draft, a small piece of code to write. One task only.
Write the prompt for it, but apply principle 2 first. Add the relevant context: what you have, what you have tried, what “done” looks like in one sentence. If it is faster, dictate this with voice and let the model clean it up.
Before letting the model produce the final answer, ask it for a plan: what it will do, in steps, with the assumptions it is making. Read the plan. Push back on at least one thing. Then let it execute.
Reflect
- Of the five principles, which one are you most likely to skip when you are in a hurry? What does that say about where the work most often goes wrong?
- “Don’t build your own agent” sounds obvious until you are mid-project and excited about your own creation. Where in your work this month are you closest to making that mistake?
View as plain markdown for LLMs and copy-paste