Effective AI collaboration rewards habits you won't discover by accident.
These seven principles emerged from a week-long project to restructure a large note collection with Claude Code. They apply to any serious, extended AI project — not quick tasks, but real ones that unfold over time and reveal themselves as you go.
I recently wrote a long piece about a project I completed with Claude Code, a week of working together to bring structure and consistency to almost six thousand notes I’ve been accumulating for fifteen years. The project involved automated scripts, category taxonomies, tag inventories, YAML metadata, and a few moments of genuine intellectual surprise. If any of that sounds interesting, you can read it here.
Writing that piece was its own kind of collaborative project, and somewhere in the process of trying to describe what the work had involved, a set of AI collaboration principles started to emerge. Not rules I’d followed, since I hadn’t known them at the start, but patterns I could see in retrospect, things I’d done or learned that seemed to matter.
I’m posting them separately because I think they’re useful independently of the project that produced them. If you’re thinking about taking on a serious, extended piece of work with AI (not a quick task, but a real collaboration over time), these are the things I wish I’d understood clearly before I started.
1. Start with the goal or vision, not the task. Before deciding what to do, be clear about what you’re trying to enable. A project defined only by its immediate task will struggle to make decisions about scope, quality, and trade-offs. A project defined by what it will make possible has a compass. This doesn’t need to be a perfectly formed idea; it might only be the shape of an idea but language models are perfectly capable of working within these messy contexts.
2. Understand what your collaborator can and can’t bring. A language model won’t accumulate understanding of you passively over time. Whatever context a long-term human colleague would carry in their head — your priorities, your constraints, the decisions you’ve already made and why — has to be constructed deliberately and written down. This isn’t a limitation to work around; it’s a design constraint to plan for.
3. Invest in the conversation before the work. The back-and-forth “thinking out loud” that’s required to converge on a shared understanding of what you’re doing, why certain distinctions matter, and what good output looks like is not preparation for the real work. It is the real work. The thinking that happens before any file is touched is often the most durable value a project produces.
4. Plan to adapt the plan. Complex projects reveal themselves as you do them. Phases you didn’t anticipate will emerge; requirements that were invisible at the outset will surface once you’ve mapped the territory. Build a plan that is designed to be updated, not a blueprint you’re committed to following.
5. Build safety nets before you need them. Version control, dry runs, named checkpoints before major operations — set these up before the project begins, not after something goes wrong. The discipline of testing every operation on a small batch before scaling it is what makes ambitious work feel safe rather than reckless. Anxiety is expensive; a little infrastructure removes most of it.
6. Treat everything the model produces as a draft. At every stage, the model’s output is a starting point for your judgement, not a result to accept. The model doesn’t know what your work is ultimately for, what distinctions matter in your field, or what your notes actually mean. You do. The collaboration only works if you stay in that loop. So push back often, and encourage the model to do the same.
7. Expect to learn something about yourself. The pressure a project like this places on you to be explicit — to define distinctions you’ve always left implicit, to articulate why certain things belong together and others don’t — produces something that outlasts the project. You’ll end up with a written account of how you think about your domain, not because that was the goal, but because the work demanded it. Go in expecting that, and you’ll be more ready to take it seriously when it happens.
These emerged from one project, which means they’re provisional. I’d be curious whether they hold up for people working in different contexts, on different kinds of material, with different goals. If you try any of this and find that something needs revising, I’d like to know.