When you already know how to code, your first attempt at working with a coding assistant can be frustrating. You could have opened the file and changed a few lines by now. Instead, you are explaining the task, clarifying details, and reading a long response. Code appears on the screen, along with a perfectly reasonable thought: “I could have done this myself already.”
Perhaps you really would have finished that particular task faster. But one attempt still leaves you wondering how to fit an assistant into your usual work. Handing over an entire application feels risky; asking it to finish an obvious line feels pointless.
I would start with a small change in a familiar project. Something where you can picture the result in advance and spot a mistake. That leaves you free to pay attention to the process itself: how to explain the task, what happens on the first attempt, and where your involvement is needed.
A small annoyance on a large screen
Imagine you have a personal blog. You usually open it on your laptop, and it looks fine. Then one day you open the page on a large monitor and notice that the article list has drifted apart. Titles sit far to the left, images stretch toward the right, and there is so much space between them that they no longer feel like parts of the same card.
Meanwhile, the header and author description look normal. Nothing is particularly bothersome on your phone, either. You do not want to redesign the whole site. You want to bring the wide layout together while preserving what already works.
This makes a useful first task. It has a visible defect and clear boundaries. You can decide what “done” means before you start: the list aligns with the rest of the content, images keep their proportions, titles remain readable, and the phone layout has no horizontal scrollbar.
That clarity will come in handy when the assistant announces that everything is fixed. You will have something to compare its answer against.
Before experimenting, save your current work in the usual way and create a separate branch. Being able to undo a change calmly makes it easier to try things without worrying about every unsuccessful attempt.
The conversation starts with what you see
The assistant needs the same material a colleague would find useful: the page, a screenshot of the problem, and a few words about what bothers you. If the tool can read your project, you can ask it to find the template and styles. In a regular chat, you will need to provide the relevant snippets yourself. Page code and a screenshot are enough to investigate the layout; credentials and user data have no role here.
An ordinary description is enough for the first request:
On my blog's author page, the article list spreads wider than the header and author description on a large screen. The titles and images end up too far apart. I am happy with the layout on smaller screens.
Find what controls the list's width, explain the cause, and suggest a small change. Do not edit any files yet. I have attached a screenshot and the page address.
You do not have to guess the cause or dictate which class to add in your first message. Describing what you observe and asking the assistant to investigate is enough. It also gives you a chance to check whether you understand the task the same way before changes appear in the project.
A useful explanation can be checked against the code. For example, the assistant might show that the header sits inside a container with a width limit, while the article list sits outside it. You open the template and see whether that is true. If the explanation does not match the file, it is better to discuss the discrepancy immediately.
At this point, it is worth asking which other pages use the same template or style. A small change can have neighbours: fixing the author page might also alter a category page without you noticing.
When the code arrives
Once the explanation makes sense, ask the assistant to apply the proposed change and show the diff. The work now becomes familiar: you have a set of changes to read.
It is tempting to glance at the browser and move on. But a few minutes with the changed lines help you understand what happened. Why was the width constraint added here? Was an existing container reused? Where did that change to the neighbouring block come from?
If the assistant also renamed classes, reformatted the whole file, and “improved” a couple of other things, ask why those changes are necessary. A compact diff is easier to connect to the original task. Anything unrelated can wait for a separate conversation.
There is no need to pretend you understand an unfamiliar construct. You can work through it, ask why it is needed, or suggest an approach already used in the project. After all, the code will still be in your repository after you close the chat.
A regular chat adds one manual step: copying the suggested snippet into the file. After that, the process is the same: inspect the diff and open the page.
The page needs to survive resizing
The blog may now look excellent on a large monitor. That is satisfying, but the task had another condition: preserving smaller screens.
I would open the page in a wide window, at a typical laptop width, and at a narrow phone width. Then I would simply drag the edge of the window. Sometimes the problem appears between your chosen sizes: a title suddenly wraps, an image becomes too narrow, or an unexpected gap appears.
If the change affects a shared template, check another page that uses it. The build and project checks are useful too, but they will not tell you whether a title is comfortable to read next to its image. It helps to ask what the assistant actually checked and what still needs your attention.
Suppose the wide layout looks good, but an extra gap has appeared on the left on mobile. That is a concrete observation you can bring back to the conversation:
The article list now aligns correctly on a wide screen. At a width of 390 pixels, there is an extra gap on the left. Here is a screenshot. Find which part of the last change introduced it and suggest a fix that preserves the wide-screen result.
A working rhythm gradually emerges. You point out a discrepancy, the assistant investigates, and you check the next version. If changes keep accumulating and the explanation stops matching the result, you can stop and return to the saved state. Sometimes restating a narrow task is easier than continuing a tangled chain of fixes.
After the first attempt
Once the page looks right, pause briefly before moving to the next task. Where did the assistant save time? What was difficult to explain? Which mistake did you catch yourself, and how did you resolve it?
Those answers are more useful than an overall feeling of liking or disliking the experience. Perhaps finding unfamiliar templates was quick, but discussing the design took too long. Or perhaps the code worked immediately, but you had to describe your acceptance criteria much more precisely than usual.
A small blog fix is enough for a first attempt. You can approach input validation or a report change in the same way: choose a familiar task, picture the right outcome, and work through to checking it.
One such change is enough to get started. Afterwards, you will have your own experience: useful wording, unnecessary edits, and places where work stalled without your understanding of the project. That gives you something to build on when choosing the next task.
I wrote about my attitude toward this way of working in “Yes, I Vibecode”.
Top comments (0)