At last, there is a spare half hour in the evening. You could open that walkthrough of a new tool you saved: the tab has been waiting for a week. It will probably contain three more links, unfamiliar terms, and a suggestion to install a few things first. Then morning brings the usual work again: a service bug, a question from a colleague, and a task you promised to finish yesterday.
On an evening like that, it is easy to decide that getting properly acquainted with a coding assistant requires a holiday. Or at least a quiet week when nobody asks you for anything.
I would not wait for that week. It has an unfortunate habit of never arriving.
For a developer, some of the learning material is already sitting in the issue tracker. There are familiar tasks, clear constraints, and people who can tell you whether you delivered what was needed. All that remains is to choose a small piece of work where you can try a new technique and make sense of the result. You do not always need a separate practice project for that.
A familiar task gives you something to hold on to
In the previous two articles, we worked through a hypothetical example: an email sent after an order is completed. First, we found our way around the existing project, then checked the change before release. Imagine that work is finished. Another small task appears in the tracker: adjust the data in a similar notification.
Previously, I would have opened familiar files and started looking for the right place. Now I can hand part of that search to the assistant. Before making the first request, though, it helps to decide exactly what I want to try. Learning to get an explanation I can verify against the code, for instance.
That is a small enough goal for an ordinary working day. There is no need to learn a new editor, switch models, assemble a toolkit, and invent the perfect system of rules all at once. In a familiar part of the project, it is easier to notice where the assistant has found something useful and where it has confidently filled a gap in its knowledge.
For a first attempt, I would choose a task where I can judge the answer myself. If the tool, the language, and the domain are all unfamiliar, it is much harder to distinguish help from a convincing mistake. Too much has to be taken on trust.
I also need enough time to allow for an unsuccessful attempt. Restoring a service in a hurry is a poor moment to get acquainted with a new way of working. A small change I know how to make myself leaves me the option of stopping and finishing it the familiar way.
One question per attempt
Back to the email. Suppose I need to understand where the recipient's name comes from before it reaches the template. I already have a rough idea of the route, so I can compare the explanation with what I know.
The request can be very simple:
Find how the recipient's name reaches the email sent after an order is completed. Show the path through the files and functions. State separately what the code shows and what you are assuming. Do not change anything yet. I need to be able to follow this path myself using your answer.
That final sentence sets a fairly specific expectation. I need an answer that lets me open a few places in the project and understand how they connect.
The assistant might find the template quickly but miss the data transformation that happens before it. That is already a useful learning outcome: I can see where its search stopped and where I might have been too quick to agree. I can point out the omission and ask it to continue tracing the path. Or I might notice that the request was too broad and start with a particular handler instead.
Another time, the answer may be accurate but so long that reading it takes more time than finding the function myself. I would narrow the next request: only the key steps, with links to the code, without an explanation of every line.
That is how a personal understanding of the tool develops. It is made up of small observations: where to narrow a question, when to ask for evidence, which part of the context to supply at the outset. After a few attempts, these things begin to save attention.
Do not change everything at the first inconvenience
An unhelpful answer often makes you want to try another tool. Sometimes that really is sensible. But if you change the whole set of conditions every time, it becomes difficult to tell what you have actually learned.
Suppose the assistant proposes far too large a change. On the first attempt, I asked it to “tidy up the notifications.” On the second, I specified a particular field, ruled out changes to the shared sending mechanism, and described the expected result. If the second answer was more useful, I learned something about defining a task. That lesson will stay with me even if I switch tools.
So, for a few comparable tasks, I would keep my usual environment and change one technique. Today, I ask for the evidence behind a conclusion. Next time, I agree on a plan first. Later, I ask it to compare the completed change with the requirements. You can choose your own order; what matters is giving yourself time to notice what has changed in the work.
These attempts need a clear limit. If half an hour has gone into persuading the assistant to notice an obvious file, it is perfectly reasonable to stop. I would note what did not work and return to the task the usual way. A learning experience does not become more valuable because it derails the entire day.
Leave yourself a few lines
Once the email works, you want to close the task. That is precisely when it is easiest to lose the small discovery that made the whole exercise worthwhile.
I would leave a few lines alongside the task: what I tried, where the answer helped, what needed correcting, and what I will repeat next time. For example:
The assistant found the template but did not trace the data preparation. Asking for the full path from the event to the email exposed the gap. Next time, I will start with that path. I am keeping responsibility for checking the result.
A week later, a note like that is more useful than a collection of polished prompts without context. It shows which problem the technique addressed and why it helped. If a similar situation comes up, I will have somewhere to start.
When the same request comes up again and again, it can become a project rule or a small repeatable procedure. I arrived at this through my own repetitions: I did not want to explain the same constraints from scratch every time. But first, it helps to see how the rule works across several tasks. Otherwise, it is easy to spend an evening writing a lengthy instruction that nobody can confidently explain afterward.
A rule needs a reason that makes sense without the chat history. “Show me a plan before making changes” helps us agree on the scope. “Do not commit without a separate instruction” keeps the decision to record the changes under my control. Agreements like these are easy to carry between tasks because their purpose is clear.
How to notice an improvement
The initial impression of speed can be misleading: the code appeared in a minute, but then it took an hour to work out what it did. I would therefore look at the whole journey to a result I am willing to accept.
How much time went into explaining the task? Did it become easier to find the right place? How often did I have to bring the assistant back to the original constraints? Can I explain the change to a colleague afterward? These questions do not require a separate tracking system. Sometimes a short note beside the previous attempt is enough.
Comparisons also deserve care. One email may be assembled in a single file; another may pass through several services. If the second task took longer, that does not by itself mean the new way of working became worse. It is more useful to look for recurring observations across similar tasks: fewer unnecessary changes, faster discovery of context, less need to explain the boundaries again.
Sometimes the assistant does not make the work faster but does help me understand an unfamiliar part of the project. That counts as a result too, if that understanding was what I lacked. It is important to name it honestly, so I do not later promise myself time savings where I actually spent time learning.
What can wait
At almost any moment, there will be a new tool that looks interesting to try. But getting acquainted with it has to take time from somewhere. I would return to my setup when I can name a specific inconvenience in my work.
If the assistant keeps forgetting project constraints, there is a reason to look into rules. If it spends too long finding context, I can examine what it can access and how the material is organized. If I want to continue a task from another device, I can explore a remote workspace. Each next step gains a purpose that makes its result easier to assess.
Until then, some news can remain unread. Not every announcement needs to trigger a rearrangement of your working day.
If I were starting now, I would choose one small, familiar task for the coming week, one technique, and a short note after the attempt. Then I would try the same technique again. After a few cycles, I would have material for the next decision: what to keep, what to change, and what I do not need yet.
That spare half hour in the evening can still go toward an interesting walkthrough. Only now, it will be easier to recognize my own question in it. Why does the assistant lose the connection between the handler and the template, for example? Or how can I give it the constraints once instead of repeating them in every chat? Reading with a question like that is usually more useful than trying to learn everything just in case.
And in the morning, there will be another ordinary task in the tracker. That is where I can pick up again.
Top comments (0)