Your first day with an AI tool

Nobody hands you a list on the first day. You open the tool, type something reasonable, and it works well enough that you keep going.

The trouble arrives later, and always the same way: money spent that nobody agreed, a file that came back changed in ways you never asked for, a job that ran an hour with nothing to show, or a confident sentence saying the work is finished when the work is not.

None of that is exotic. Forty-five habits cover almost all of it, and every one of them can be learned in an afternoon. What follows is those forty-five, in the order they tend to matter, each written out properly rather than as a slogan.

Read them as sentences you could say to the tool tomorrow morning. Every rule carries the reason behind it, the mistake it prevents, and the same request phrased two ways — one that works, and one that quietly does not.

Before you let it do anything that costs money, say a number out loud: stop and ask me before the total passes two dollars.

Paid work is charged per item, and nothing in the tool knows what counts as a lot for you. With no number in front of it, how much of your money gets spent is decided by whatever happens to be running.

Don't set the budget in feelings. Keep it cheap and don't go mad have no value anything can compare against, so nothing ever crosses a line.

When a message tells you money is being spent right now, treat the line as news rather than a question. Stop the job and make the decision again from the start.

You might think a notice in the present tense means the job is still open, but it actually describes something already finished. The right time for a yes was before the first call went out.

Don't reply fine, carry on because the work is already moving. Momentum is not a reason, and the spending continues while you are still reading the sentence about it.

Before anything runs more than a few times, ask for the arithmetic in one line: the cost of one item, the number of items, and the two multiplied.

The price of a single item is small enough to feel free, and the multiplication is the part nobody says out loud. A plan can grow ten times over without any single step looking expensive.

Don't accept a total with no working shown. A number on its own cannot be checked, and a wrong count is the commonest way a bill triples.

Say yes twice. Once for the small test, again for the full run, and treat the second yes as its own decision with its own number.

The test answered whether the work is right. Whether the size is right is a different question with a different bill, and nothing about a good sample of five makes nine hundred affordable.

Don't let one approval stretch across a change of scale. A go for five is not a go for nine hundred, however well the five turned out.

Set a hard stop at twice the estimate and let it end the job on its own. Don't wait to see where the number settles.

Runaway costs rarely arrive as one large charge. A step quietly repeats, so the number keeps climbing at the rate it has been climbing, and a rate is the thing that does not stop by itself.

Don't watch it pass the estimate and give it a little longer. Waiting has never once made the curve bend back down.

Putting a limit in the conversation is tempting, but the safer way is to add the limit inside the job itself, as a running total that halts the work the moment it is crossed.

Agreeing a number in chat does not create anything able to act on the number. Only something counting while the work runs can stop the work.

Don't treat a budget you have discussed as a budget that exists. A figure agreed in prose is a wish, and a wish has never stopped a single call going out.

When a cost arrives with a comparison attached, ask again for the number by itself: the figure, the unit, and where the price came from.

A comparison is an argument for yes. Well under your limit also hides repetition, because one cheap run says nothing about the forty more that will happen before the day ends.

Don't accept only, barely or well within as part of a price. Softeners belong to whoever is spending, never to whoever is paying.

For repetitive work such as sorting, tagging, renaming or reformatting, turn the model's extra thinking off before the run starts.

Some models work a problem through before answering, and that working is charged at the same rate as the answer while sharing the same space. On a long list the answer gets cut off partway, so the run has to be paid for twice.

Don't leave the setting alone and learn about it from the failures. Output that stops halfway down a list is the symptom, and by then the money has gone.

Make a copy of the file before the first change of any session, every session, without exception.

The copy you did not take is always the one you needed. A session that goes well never calls for it, and a session that goes wrong calls for it in the first ten minutes.

Don't lean on a copy from earlier in the day. Hours old means hours of work sitting outside anything you can get back.

Take a fresh copy right before you start work, not once at the beginning of the day.

A copy is only worth what it holds. One made six hours ago holds the file as it was six hours ago, so everything since then is work you would have to do again from memory.

Don't treat the age of a copy as a detail. An old copy gives you the same feeling of safety with none of the cover.

Copying both files in the same point is important because when two files work as a pair, missing one can break the link between, for example, a document and the sheet behind it.

Recovering one half while the other is gone is its own bad afternoon. The halves have to match, and a copy of one alone cannot put them back in step.

Don't call a copy of the visible half a backup. The part you never look at is usually the part that took longest to build.

Know that opening a file to write into it empties the file first, before a single character goes in.

If the writing then stops halfway, through a crash or a full disk or a job that got killed, you are left holding an empty file instead of your old one. From the outside an empty file and a saved file look the same.

Don't assume a failed save leaves the old version behind. Nothing warns you, and the failure is silent.

Write the new version to a temporary file, then replace the original with it in one move.

A swap either happens or does not. A crash during the writing damages only the temporary file, so the version you already had stays whole.

Don't write straight over the original to save a step. The step you saved is the one protecting everything that came before it.

Check there is free space on the disk before writing anything large.

A disk that fills partway through a write leaves a file of nothing and reports no error at all. The job says it finished, and the finishing is what emptied the file.

Don't file disk space under infrastructure. A full disk destroys data quietly, which is worse than destroying it loudly.

Treat a delete as final. A file removed from a command line has no recycle bin behind it and no undo.

Confirming costs you five seconds. Rebuilding what vanished costs hours, and sometimes the thing cannot be rebuilt at all because whatever produced it has moved on.

Don't approve a delete you have not seen listed. Anything that cannot show you the list first should not be running the delete.

Name the files you mean, and name the ones to keep. Say both out loud.

Everything except this one gets read more widely than you meant. Something you never mentioned goes, and finding out happens much later, usually when you go looking for it.

Don't describe a set by what it relates to. Related is a judgement, and the judgement being made is not yours.

Read where a test run writes its output before you start it. A test can overwrite the real thing.

Plenty of jobs write to the same place whether you asked for three items or three thousand. A small flag limits how much work is done, never where the work lands.

Don't let the word test carry the safety. Nothing about a smaller run makes the destination different.

Never empty a growing record in order to run it again.

A second run adds what is missing and skips what is already there. Emptying it first throws away everything the earlier runs collected, and those runs are the part you cannot repeat cheaply.

Don't clear a store to get a clean run. Clean is not the goal here; complete is.

Never let it start work you cannot interrupt. Everything runs in front of you, where one keypress stops it.

You might think you can stop any job you see, but a job that has detached keeps running where nobody can reach it. The only way left to stop it is by closing the window.

Don't accept work moved into the background so the chat stays responsive. A responsive chat is worth nothing once the work is out of reach.

Know that a job started from a shell dies when the shell closes, part-finished and reporting success.

A script stops at record 134 of 900 and exits cleanly. Success and silent death look identical from the outside, so the gap surfaces days later as missing rows.

Don't read an exit without errors as an exit with the work done. The two are unrelated.

Give every long job a time limit sized to that job.

With no limit, a job can run for hours after it stopped making progress. With a limit copied from habit rather than from the task, real work gets killed at fifty-five seconds while it is still going fine.

Don't reach for a standard number. A forty-second walk through a folder needs two minutes, not whatever cap you use for everything else.

Ask for one line of progress every few minutes, and for the work to carry on while you read it.

Silence for an hour costs you the hour. Stopping to ask permission at every step costs the same hour a different way, and leaves you deciding things you already decided.

Don't let a request for visibility turn into a request for approval. The rule is do not go quiet, never stop and check.

Anything you type while a job is running is an interruption, and it takes priority over the job straight away.

Having to close the window to get noticed means something went wrong long before you closed it. Your message is never background to a running task.

Don't wait politely for a job to finish before raising something. The waiting is the failure, and the failure belongs to the tool, not to you.

Have each result written to disk as it arrives, rather than collected up and saved at the end.

Collecting a thousand results in memory and writing once at the finish means a crash at nine hundred saves none of them. The work was done; the record of it was not.

Don't accept saving at the end because the code reads more tidily. Tidy is not a property you need here; recoverable is.

Run three items. Look at them properly. Then run the rest.

The first three decide the shape of all nine hundred, because everything after them is a copy of a choice already made. Reading three costs a minute, and finding the wrong shape at nine hundred costs the whole run.

Don't let a small batch go by without your eyes on it. A batch nobody read is not a test, only a delay.

Pointing at the exact file by name and path works better than describing it, because the wrong file is easy to copy when the details are not clear.

Make it like our other page hands the decision to whatever the model imagines. Open this file, copy the layout, change only the words puts your own work back at the centre of it.

Don't describe a style you already have a file for. A description is a second-hand account of something you could hand over directly.

Ask what it found in a file before you let it act on the file.

A confident acknowledgement costs nothing to produce and reads the same whether the reading happened or not. One question, such as what does the third section say, settles it in a line.

Don't take I've read it as evidence that reading occurred. The sentence is generated as easily as any other sentence.

Send the whole thought in one message. If more is coming, say hold first.

A model cannot see you typing. Work starts on your first line with no way to know that two more are on the way, so you get an answer to a question you had not finished asking.

Don't spread one instruction across three messages. Each one lands as a complete request and gets treated as one.

Count the items in the plan that comes back and compare that with the number in your request. More items means it drifted.

The cheapest test you own, and it takes five seconds. Four things asked for and eleven returned means seven of them belong to the model rather than to you.

Don't argue the extras one at a time. Send the plan back to the size of the ask, then discuss anything left over on its own.

Keep findings out of the work. Anything spotted along the way goes in one line at the end, and stays there until you pick it up.

Adjacent problems folded into the job make the inflated version the default, so you end up arguing your own request back down to the size it started at.

Don't accept a fix bundled with the thing you asked for. Bundling quietly removes your say over the second one.

Say that new means alongside. The old version stays until you say otherwise, in words.

Add and replace look similar in a summary and are nothing alike on disk. A version you approved is a standard, and a standard is not raw material for the next idea.

Don't let a rebuild absorb the thing being rebuilt. Anything about to be removed gets named first, in plain words.

When you ask for a report, expect a report and nothing else. No copying, no moving, no deleting.

Requests to look into something get carried out as instructions far more often than anyone expects. Look does not mean do, and the gap between the two can be a whole folder.

Don't leave the boundary implied. Say read-only out loud, and say stop once the report is written.

Never agree to delete work you paid for with money or time. Archive it and keep the door open.

Deleting keeps nothing and closes off whatever that work might still become. Judging it harshly and storing it anyway costs one folder.

Don't accept an offer to clear something out because nothing is using it. Unused is not worthless, and the reach for delete is itself the warning.

Count what came out, check the size, and hold it against what went in. Finishing without an error is not the same as being right.

A job can complete cleanly and produce an empty file, because an exit code reports whether the program ended and never whether the work is any good.

Don't accept ran successfully as a result. Ask what the result was, in numbers.

Ban the soft words. Should be fine, likely fixed and seems to work all go straight back.

Every one of those means nothing was checked. Hedging is how an unverified claim gets to sound like a finished one.

Don't let a hedge stand because the work probably is fine. Probably is the exact thing you cannot act on.

Treat I could not check this as a good answer, and a false done as a serious one.

Admitting the gap costs a minute. A completion that turns out to be imaginary costs a day, and every report after it has to be read twice.

Don't press for a yes when the honest answer is unverified. Pressure buys you the word, never the fact.

Ask which tool actually ran whenever something claims to have looked at a page. A model has no eyes without one.

Verified visually and looks right in the browser are sentences, not observations. With no browser tool nothing was seen, and the claim was assembled from the code.

Don't accept a screenshot described but never shown. A description of an image is not an image.

Look at pictures yourself. A model reads a drawing as a list of coordinates, never as an image.

Asked to describe artwork from its source, a model can call a drawing of a book a server rack, and say so with complete confidence. Nothing in the code carries what the picture looks like.

Don't ask for a quality judgement on anything visual. An answer will arrive, and the answer will be invented.

Restart the server after every change on the server side, before testing anything.

Code on disk means nothing until the running process loads it. Without a restart you are testing the old version and chasing a bug that was fixed ten minutes ago.

Don't debug across a restart you did not do. Hours go into a problem that no longer exists.

Fetching the live page and searching for a sentence you added helps confirm the file you edited is the one being served, which matters when edits do not show up as expected.

A whole session of edits can land in a path that nothing is serving, so everything looks right on disk and nothing at all changes on screen. The cause is a server pointed at the wrong folder.

Don't diagnose a missing change as a caching problem before checking which file is live. Wrong file is far commoner than wrong cache.

Say talk first, build after, and hold that line until you have agreed a plain description of what will be made.

Left to guess, a tool will build the same thing four or five times over before anybody says stop, and each rebuild feels like progress from the inside.

Don't let a question be answered with a file. An answer in prose can be corrected in a sentence; a file has to be argued with.

Ignore any estimate of time you did not ask for. Ask instead what is included, what is reused, and what is genuinely new.

A made-up duration is wrong in both directions by enormous margins, and gets read as a promise anyway. Scope is the real question underneath, and scope can be checked.

Don't plan around a made-up hour. Planning around one is easy, and the number becomes a real deadline the point you repeat it to somebody else.

Refuse invented risks and numbers with nothing behind them. No remaining risk is a legitimate answer.

Might use one or two gigabytes, with no measurement under it, is noise that buries the single real concern inside a list of imaginary ones.

Don't ask for risks as a formality. A padded list trains you to skim, and skimming is how the real one gets past you.

Make it name its own mistake accurately, in the word a person would use.

I volunteered an estimate means it made a number up. Gentle self-description turns a real failure into something that sounds routine, and the same failure comes back next week.

Don't accept a soft phrase for a hard event. Drifted, adjusted and got ahead of myself are all doing the same job.

Ignore anything it says about pacing your day. When to stop is not its call.

A model cannot see the deadline, the meeting, or the thing waiting behind this piece of work. A suggestion to rest arrives with none of the information that would make it a suggestion.

A pause after a failure may look like the tool is thinking, but actually, the point work goes wrong is when you must decide what happens next, not the tool.