How I work with AI as a developer: the daily loop that actually works

The first weeks with an AI coding assistant feel like magic. The next weeks feel like cleaning up after magic. What changed my results was not a better model, it was a better loop.

Write the problem down before you prompt

Before I open the assistant I write three lines: what should be true when this is done, what must not change, and how I will check it. Those lines become the prompt. If I cannot write them, I do not understand the task yet, and no tool will fix that.

Give context, not just instructions

A model that sees only the file you pasted will invent the rest. I give it the surrounding structure: how the project is organized, the naming rules, the component I want it to imitate. The closer the example, the less rewriting I do later.

Keep the steps small

Ask for one change at a time. A small diff is easy to read, easy to test and easy to revert. When I ask for a whole feature in one go, I get a result I can only accept or reject, never review.

Read every line you keep

This is the rule that matters most. If I would not be able to explain a line in a code review, it does not go in. AI makes typing cheap, which makes judgment the expensive part. That is where a developer earns their place.

Use it for the boring parts first

• Boilerplate, types and repetitive component variants.
• Explaining unfamiliar code before you change it.
• Drafting tests and documentation you then correct.
• Second opinions on naming and structure.

Keep learning on purpose

The risk of working with AI is not that you get replaced, it is that your own skills quietly fade. I still read documentation, I still write the hard parts myself, and I still debug without the assistant now and then. Treat the tool like a fast junior colleague: useful, tireless, and in need of review.

The developers who benefit most are not the ones who prompt the most. They are the ones who know what good looks like and can tell when the output is not it.