How to stay captain of your own vessel and turn an LLM into a research assistant rather than an answer machine Most advice about AI teaches people how to speak to the machine. Be specific. Give examples. Define the tone. Break the task into steps. Ask it to act as an expert. That advice is useful, but it begins too late. The more important question is not: How should I prompt the AI? It is: What role have I given the AI inside my work? The same language model can be used as a shortcut around thinking, an answer machine, a ghostwriter, a coding assistant, a critic, a research partner, or part of a larger system. The model may be the same. The role changes everything. I do not experience working with an LLM as standing outside a machine and issuing commands to it. It feels closer to navigating a vessel from inside it. I hold a direction in my head. Often I do not yet know the final form of the thing, but I have a sense of where it is heading. I use the model to help carry the work in that direction while paying attention to how the system responds beneath my feet. The AI is the vessel currently carrying the work. The ideas, evidence, code, files, experiments and unfinished structures are the cargo. The wider environment is the sea: uncertainty, incomplete information, time, complexity and changing conditions.
I remain the captain. My job is not simply to point at a destination. My job is to choose routes the current vessel can survive. The same ocean is not the same problem for every vessel A small sailing boat and a cargo ship may cross the same ocean, but they do not experience the same hazards. A small vessel may be threatened by individual waves, sudden weather, exposure and limited supplies. A cargo ship may be threatened by inertia, turning radius, shallow water, structural loading and the difficulty of changing direction once committed. The obstacle is not simply the ocean. It is the relationship between: the environment; the vessel; the load; the destination; the available recovery options. The same is true of AI. A short chat is light and manoeuvrable. It can change direction quickly, but it carries little reliable state and loses continuity easily. A long-running research workflow can carry much more: documents; code; datasets; evidence; terminology; version history; decisions; unresolved questions. But it also develops inertia. A bad assumption introduced early can become embedded in later work. A private vocabulary can become difficult to translate. A model can become so fluent in the project’s language that it stops noticing the assumptions underneath it. As the vessel grows, the method of navigation has to change.
You cannot steer a cargo ship as though it were a canoe. I hold the direction, not a finished answer When I begin working with an LLM, I often do not hold a complete solution. What I hold is a directional model. I may sense that: a distinction matters; two parts of a system are related; a repeated failure is exposing a missing layer; the current explanation is too shallow; several different problems share a structural form; the work is moving towards something more precise. I then use the model to help travel towards that structure. This is different from asking the model to decide the destination. The model can suggest routes, expose contradictions, generate alternatives, write code, organise evidence and help build the vessel while it is already moving. But I remain responsible for deciding whether the work still points towards the thing I intended to make. That is where the human contribution sits. The originality is not simply in the final words. It lies in: the direction held; the distinctions selected; the standards imposed; the connections made; the failures recognised; the claims accepted or rejected. The model can help carry and shape the work. It does not inherit authorship merely because it helped produce the surface. Reading the vessel A captain does not steer only by looking at the horizon. They also read the vessel. They feel changes through the deck. They notice resistance in the water. They watch
the load shift and pay attention to the delay between turning the wheel and changing direction. I use an LLM in a similar way. I pay attention to: which concepts it repeatedly groups together; which distinctions it loses; where it becomes too confident; where explanation turns into analogy; where an implementation begins to sound more validated than it is; what it omits; when its language becomes smoother than the evidence; where it starts repeating my terminology without testing it. The answer is not only an answer. It is also feedback from the vessel. That does not mean every unusual phrase is meaningful. One strange word may be noise. A repeated wording pattern is weak evidence. A repeated structural failure is more useful. A failure that appears across controlled variations is something worth designing around. The aim is not to imagine that the model has hidden feelings or intentions. It is to inspect the behaviour of the system I am relying on. One voyage One of the clearest examples came from building a materials-engineering model-audit system. The initial idea was straightforward: instead of only asking whether a model predicts well, test whether the model’s important features remain stable when the data or descriptors are perturbed. The LLM helped me turn that idea into: an experimental plan; software architecture; perturbation logic; result formats; validation reports; technical documentation.
The work moved quickly. Too quickly in places. At one stage, the system architecture looked mature enough that the language around it began sounding as though the science had already been validated. It had not. Some parts were only specified. Some were scaffolded. Some had run on fixtures. Some had run on real native data. The model was not intentionally misleading me. It was doing what language models are very good at doing: completing the shape of the story faster than the evidence had completed the work. That failure changed the project. I began separating states explicitly: architecture defined; scaffold implemented; contract integrated; runtime executed; validated on native data; validated on official external data; publication ready; external-use ready. Those labels became waypoints. They stopped forward motion from being mistaken for arrival. The same process later shaped how I handled memory, authority, dataset size, crossdomain transfer and failure states. A weakness in the interaction became a design requirement. That is one of the most valuable things AI has given me. It does not only accelerate answers. It can reveal the hidden structure of the work, including the structure of its own failure. The logbook matters
A long conversation can feel like a stable workspace, but it is not a reliable database. Earlier decisions can be compressed. Boundaries can drift. The latest wording can quietly reshape the older work. So I began moving important state outside the chat. I use: specifications; versioned documents; software manifests; object registries; dataset records; evidence matrices; patch reports; file indexes; test outputs; decision logs. These are the ship’s logbook and cargo manifest. They record: what exists; where it came from; what changed; what has actually been tested; what remains unresolved; what the current work is allowed to claim. The model helps me operate against that external state. It is not expected to remember the entire voyage perfectly. This has been especially important because my health and available energy fluctuate heavily. There are days when I can produce a huge amount and days when simply re-entering the project is difficult. Externalising the work means I do not have to rebuild the whole world in my head every time I return. The vessel retains the cargo. The logbook tells me where I was. The model helps me get back on deck.