AI in everyday life: what I use it for and what I check

When someone asks whether we should be afraid of artificial intelligence, I first want to know which task we are discussing. Fixing punctuation in my notes and independently sending a quotation to a customer have very different consequences. Conversations about AI often put them in the same enormous bag. There is enough room in that bag for almost any argument.

I am more interested in everyday work: moving information between formats, improving a draft, testing an idea and reducing repetitive tasks. Those activities give me something concrete to evaluate. Either I finish sooner while maintaining quality, or I have added another window to an already crowded desktop.

Here I mainly mean generative AI: tools that produce content, including text, from instructions and context. I am not attempting to describe every application of machine learning. I want to show a way of working that transfers between models without requiring you to memorise the latest arrangement of buttons.

I start with a task whose result I understand

My first task for AI is usually quite boring. That is useful. If I can judge the answer myself, I can quickly see whether the tool helps. I might provide my own draft message, a list of ideas or some invented records to organise. I avoid beginning in an area where any plausible explanation sounds authoritative to me.

My rule is straightforward: the harder a result is to check and the greater the consequences of a mistake, the less independence I give the tool. Reordering bullet points might cost me a few minutes. Changing records in a shared system could create problems for other people. These tasks deserve different controls.

Before opening a chat, I write one sentence describing the expected result. For example: I want an expenses table that preserves every item and does not invent missing amounts. That sentence immediately gives me acceptance criteria. A general wish for AI to improve my productivity is much harder to evaluate.

I also ask whether I need a model at all. If a spreadsheet already has the right formula or an application offers a straightforward export, I use that. Moving every click into a conversation with AI can become a surprisingly time-consuming hobby. I choose the tool according to the work I need to finish.

I organise data without allowing invented details

Suppose I have a synthetic note containing five expenses. The format is inconsistent: sometimes the amount comes first, sometimes last, and one item has no amount. I want to turn it into a table. A model may help with this task, and I can verify the result without an advanced qualification in computer science.

My practice data contains coffee for PLN 12, a ticket for PLN 18, lunch for PLN 35, another coffee for PLN 12 and a book with no recorded price. The second coffee is a separate purchase. In real work, similar-looking records can describe two events rather than a duplicate that needs removing.

I would give an instruction like this:

Convert the following list into a table with columns for item number, description, amount in PLN and note. Preserve all five items in their original order. Do not merge similar purchases. Do not guess missing amounts. Mark a missing amount as MISSING and explain it in the note column. Show the table first, then list any uncertainties.

I expect five rows. The known amounts total PLN 77, but I do not know the complete cost of the purchases. If the model presents PLN 77 as total spending, it has lost an important qualification. If it supplies a price for the book, it has created data I never provided. A perfectly reasonable-looking price is still an invented price.

I therefore check the row count, both coffee purchases, the amounts and the missing-value marker. I calculate the sum independently in a spreadsheet or calculator. Asking the same model to confirm its answer is insufficient on its own. It may confidently repeat the same mistake, now with an additional paragraph about its confidence.

For a larger dataset, I include identifiers and compare the input with the output. Reviewing a few random rows helps, but does not establish completeness. I also need record counts, reconciliation totals and a list of exceptions. If the data is large and consistently structured, an ordinary script or import tool may be a better fit.

I edit writing while protecting the meaning

Writing is another useful application. I can ask for a shorter message, a clearer order of arguments or a list of passages that a reader might interpret differently from what I intended. I particularly like that last option because it makes me reconsider my own communication.

However, I do not want a model to alter my commitments. “I will try to prepare a draft by Friday” has a different meaning from “I will deliver the finished document on Friday.” The second sentence is cleaner. It also gives the recipient a very reasonable expectation of receiving a finished document.

My instruction identifies the reader, the purpose and the boundaries of the edit. I might ask for plain language and a first-person voice while preserving every number, deadline and qualification. When a sentence is ambiguous, the model should flag it rather than silently choose one interpretation.

For an important text, I want a short explanation of the proposed changes. Three specific suggestions are easier to assess than two long blocks of text compared from memory. I can also ask for comments without a rewrite. That keeps me in charge of the writing while giving me an additional reader.

Tone matters as well. A polished draft can lose the personality, detail and small amount of humour that made the original readable. If an ordinary message to a colleague starts sounding like the opening speech at a conference, I undo some of the improvements. The reader needs the information, not a ceremony announcing the attachment.

I write instructions as a clear brief

A useful instruction describes the task, the input, the constraints and the expected output. I do not treat prompting as an incantation powered by one secret word. It is closer to briefing someone who does not have access to everything in my head.

For a summary of meeting notes, I explain who will read it and what they need to do next. I ask the model to separate decisions from suggestions, assign an owner only when the notes identify one and mark missing deadlines. This reduces opportunities for the model to helpfully complete reality on my behalf.

One example of the desired result can help. If I want three columns and short sentences, I show that format. I still check the content because matching the appearance of an example says nothing about factual accuracy. A beautifully organised table can contain entirely invented agreements.

When the task is unclear, I first ask for questions or a statement of assumptions. I decide which assumptions are acceptable. This is particularly useful when I have used words such as “better,” “professional” or “brief.” To one person, brief means two sentences. To another, it means a presentation without the appendix.

I split larger tasks into stages when doing so helps catch mistakes earlier. First I might agree on categories, then review how information has been assigned and only afterwards generate the summary. I do not add ten steps for the pleasure of having a process. Each stage should make the result easier to assess.

I use AI for learning and keep doing the thinking

When learning, I can ask for another explanation of a concept, a tiny example or a question that checks my understanding. This is convenient when one sentence in the documentation blocks the rest of an exercise. Instead of skipping the difficult part, I can focus on that exact point.

If I am studying SQL, I might request three rows of sample data and a query whose result I need to predict. I write my answer first, then execute the query. The gap between my prediction and the actual output teaches me more than reading another elegant explanation without trying anything.

I can also request a hint rather than a complete solution. Receiving finished code immediately makes it easy to confuse recognising syntax with being able to use it independently. A familiar query looks friendly. An empty editor provides a rather more demanding assessment of that familiarity.

I compare technical explanations with documentation and a working example. A model may mix SQL dialects or suggest a function unavailable in my version of an application. I provide the environment and check the result. My article on SQL JOIN types uses small datasets precisely because they make this kind of reasoning easier.

After an exercise, I explain the solution in my own words. If all I can do is paste the generated code, I return to the question of what it means. AI can accelerate access to an explanation. Understanding still requires work on my side of the screen.

I separate fluent answers from verified information

A model can generate a convincing response containing an incorrect detail, a nonexistent source or an unsupported conclusion. The NIST Generative AI Profile discusses confidently produced false or erroneous content as a significant risk. A reassuring tone does not remove that risk.

When I need current information about a product, a rule or a price, I open the relevant source. I check its date, its scope and whether the cited passage actually supports the answer. A link starts the verification process. It may lead to a real page making a much narrower claim.

When summarising a supplied document, I focus on fidelity to that document. Has the model preserved exceptions? Has a suggestion become a decision? Does the conclusion refer to an entire group when the evidence covers only part of it? These shifts can be less obvious than a visibly misspelled name.

For numbers, I want a calculation I can reproduce. For code, I want execution against test data. For an interpretation, I want to see the evidence supporting the conclusion. I match the check to the type of output instead of asking “Are you sure?” after every answer.

I also leave room for an unanswered question. If the material cannot establish why sales declined, I prefer hypotheses and a list of missing evidence to a confident diagnosis. More sentences do not create more evidence. That principle is useful in data analysis even when no AI system is involved.

I minimise data before sharing it

For practice, I use synthetic or public information. Real customer names and addresses are unnecessary when I am testing whether a model can organise five rows. At work, I use tools approved by the organisation and check the conditions governing data processing for that particular service.

Removing a name alone may be insufficient. A combination of job title, event and precise date can still identify a person. I ask which information is actually necessary for the task. Often, a table structure and a few invented records provide enough context to explain the problem.

Screenshots and attachments deserve the same attention. An email address might be visible in a corner, while another worksheet contains information I forgot about. I review the whole input before uploading it. This unglamorous step is generally more useful than solemnly adding the word “confidential” to the prompt.

If the task requires real protected information, I first establish the appropriate workflow within the organisation. I do not assume every service has identical terms, retention or settings. Having access to a convenient tool does not by itself establish what I may send to it.

I automate a process after I can describe it

Completing a task once and running it automatically are different problems. In an interactive conversation, I can notice a strange answer and correct it. A process running without me needs a defined response when information is missing, the format changes or a service fails to respond.

I first describe the input, the output and the exceptions. For a hypothetical note-processing workflow, I specify where files come from, which fields are required and where the result goes. If a deadline is missing, the process should record that fact. It should not choose next Friday because Friday sounds suitably businesslike.

I begin with a version that prepares a draft. I approve sending a message, changing a record or publishing content. After checking a range of cases, I may reduce manual involvement according to the consequences of an error. A collection of successful demonstrations still does not cover every exception.

I also need a record of what happened: which input was processed, when the run occurred and whether the output was approved. When data changes, a way to restore the previous state is useful. Otherwise, saving ten minutes can lead to a very long investigation later.

Finally, I check what happens when the process runs again. Will it create a duplicate record or send a second message? This problem often appears after a run stops halfway through. I would rather discover it using invented material than invite recipients to participate in my automation experiments.

I include review and correction in the time calculation

To assess usefulness, I count the whole task: preparing input, writing instructions, waiting, reviewing and correcting the result. Comparing generation time alone with the entire manual workflow produces an impressive number that explains very little.

For example, organising a note manually might take eight minutes. Working with a model might take two minutes of preparation and three minutes of review. In this synthetic example, I save three minutes. If reviewing the output takes ten minutes, the balance reverses, regardless of how quickly words appeared on screen.

I repeat the trial with several different inputs. One easy example can hide problems with missing values, long documents or ambiguous instructions. I also record output quality: omitted facts, required corrections and whether I can safely use the result for its intended purpose.

Only then do I decide whether to keep the instruction as a starting point for future work. A reusable prompt can help with similar tasks, but it still needs context. I do not expect one instruction to handle a household budget, a sales proposal and a complaints analysis equally well.

This also gives me a sensible stopping rule. If adapting the prompt and checking the result repeatedly costs more than completing the task directly, I change the approach. A tool does not have to help with every activity to be useful somewhere else.

I turn anxiety about work into a concrete experiment

I cannot honestly promise that AI will leave every job unchanged. I also cannot infer the disappearance of an entire profession from a single demonstration. I prefer to examine individual activities: what the tool handles well, where it needs supervision and who remains responsible for the outcome.

In data analysis, I still need to understand the question, the quality of the material and the meaning of the result. Faster query generation saves time only if I can judge the query. An incorrect JOIN does not become correct because it was written in five seconds. Responsibility for the report survives the prompt.

I would therefore develop both tool skills and subject knowledge. I would try one real problem using safe data, record the outcome and describe the limitations. That gives me useful information about my own work. Another hour reading predictions about the end of every profession rarely provides such a clear next step.

A good starting point is something that repeats each week. I would define the expected result, try completing it with and without AI, then compare time and mistakes. If the tool helps, I keep it in the process. If it creates more work, I change the task or the approach. I can run that experiment without either fearing every model or taking its answers on trust.