How AI has changed the way I work

AI has made it easier for me to move from an idea to something I can examine. I can research a subject, explore a few directions and build a first version while the idea still has my attention. That has opened up room for work I would previously have struggled to fit around everything else.

The first result is rarely the most valuable part. The real improvement comes from the process around it: keeping the project context available, reviewing what was produced, asking another model to challenge it and sometimes recognising that an idea is not ready—or simply is not right.

I am still refining that process, but a few practices are already making the work better and less repetitive.

Give the work a home

One of my recurring frustrations with AI has been explaining the same project again in a new conversation. What are we building? Where are the relevant files? Which decisions have already been made? What should never happen without my approval?

That repetition becomes much smaller when the work happens inside a project with its own codebase and context. The repository becomes more than a collection of source files. It also carries enough information for the next working session to understand where to begin.

This website is a simple example. Its README identifies where articles, application code, static assets, checks and generated files live. Separate documents explain the content and publishing workflow. The instructions for writing make it clear that a finished draft must remain private until I explicitly approve publication.

A new session does not need the full history of every conversation. It needs the current shape of the project, the decisions that still apply and a clear way to verify its work.

For readers working with AI on a codebase, I would start with four pieces of context:

1. A short project map: where the main kinds of work belong.
2. A few lasting rules: conventions, boundaries and actions that require approval.
3. The reason behind important decisions: enough to avoid casually undoing them later.
4. Verification commands: how to check that a change actually works.

The aim is not to document every file. It is to give the next session a reliable route into the project.

Separate project context from the current request

While preparing an earlier version of this article, the first draft was written in Bosnian. I had expected an English article, but that expectation existed in my head and in earlier discussion rather than as a clear rule available to the current task.

Asking for an English translation fixed that draft. It did not fix the underlying gap.

This is the distinction I now try to make: a request describes what I want done now, while project context preserves what should remain true across future tasks. “Rewrite this article in English” is a request. “Technical articles are normally written in English unless I say otherwise” is a lasting editorial rule.

The same applies to software work. A request may ask for a new feature. Project context should explain the architecture it must fit, the parts it must not expose and the checks it needs to pass.

Every rule also needs an appropriate scope. An instruction for technical articles should not silently govern a personal essay. A deployment rule should matter when publishing, without crowding the context of a small editorial change. Useful context is selected, not merely accumulated.

Use another model as a second opinion

I often take an idea or a result to another LLM and ask for its opinion. So far that has included the ChatGPT web app, Gemini and the free version of Claude Code. I use them mainly for ideation and review, rather than asking them to take over serious implementation work.

The value is not that one model always knows the answer the others missed. A fresh model starts from a different angle. It may question an assumption, notice a missing step or identify a detail that became invisible after a long iterative session.

I find this especially useful after a plan begins to feel complete. Instead of asking the second model to create another plan from scratch, I can give it the current proposal and ask focused questions:

• What assumptions am I making?
• Which steps are missing between this idea and a finished result?
• What is likely to fail in practice?
• What should I verify myself?
• Is there a simpler interpretation of the same goal?

The second opinion is still model output and needs judgment. Agreement between two models is not proof, and disagreement does not automatically mean the second one is right. Its role is to expose another path for review.

Let iteration change the decision

Iteration is often described as a straight path towards improvement: generate, review, revise and repeat until the result is finished. My experience has been less tidy and more useful.

Sometimes the “aha” moment is not a better implementation. It is realising that the current direction is not what I want. At other times the idea is good, but this is not the right moment to release it. The work may reveal a missing dependency, an unclear audience or a larger decision that needs to come first.

That happened while thinking about what to publish on this site. Several subjects were interesting and had enough material for an article, but writing about them now would reveal work I want to introduce properly later. The correct outcome was to keep the idea and change the publication plan.

This is an important use of AI for me. It helps make an idea concrete enough to judge. A discarded draft or postponed feature is not necessarily wasted work if it exposes the real decision before more time is spent building or publishing it.

It also means that “done” should not be defined only as a successful implementation. A good working process leaves room for three valid outcomes:

continue and improve
change direction
keep the idea, but stop for now

Ask what each check actually proves

Fast generation moves more of my attention towards evaluation. I need to read the text, inspect the change, try the behaviour and decide whether the result matches what I meant.

Technical checks help, but each one proves only part of the result. On this site, an article check can catch placeholder text, suspicious credentials or missing image descriptions. Content validation confirms that the Markdown collection is structurally valid. A full release check also builds and tests the generated site.

None of those checks can tell me whether an article sounds like me, whether the argument is worth publishing or whether the timing is right. A browser preview can help with reading and layout, but it does not prove that a production deployment succeeded.

I now want completion reports to be specific: which checks passed, what was inspected, what remains uncertain and which decision still belongs to me. “The task is complete” is less useful than evidence I can evaluate.

A small workflow readers can try

The practical version of this approach does not require a large agent platform. It can begin with one project and one task:

1. Write a short map of the project and point to the detailed documentation.
2. Record the few rules that should survive every new conversation.
3. Give the AI a concrete task and define how its result will be checked.
4. Review the output yourself, then ask another model to challenge the assumptions and missing steps.
5. Decide whether to continue, change direction or stop for now.
6. Preserve the decision and the next useful step in the project, instead of leaving them only in chat history.

The final step reduces the frustration of starting again. A useful handoff can be short: the current state, the relevant source, decisions that still apply, checks already run and the next unresolved question.

I do not yet have a perfect system for working with AI. What has changed is that I no longer see each conversation as a self-contained attempt to get an answer. The work improves when the project carries its own context, another perspective can challenge the current direction and iteration is allowed to end in a decision other than publication.

The model will change. The conversation will end. The useful part is what the project can carry into whatever comes next.