Keeping your judgment when creating with AI

A convincing answer is not a finished decision

Creating with AI can make the first draft of an idea easier to reach. Headings appear for an article, layouts for a website, or starter code for an application. Seeing something concrete is encouraging. But this is also the moment to make a small distinction: are we looking at a proposal we can evaluate, or a decision we have already accepted without quite noticing?

Generated does not mean chosen. A fluent explanation or polished image can make the original purpose slip out of view. The important questions remain: whose experience does this improve, what does it make unnecessarily difficult, and does it actually express what I wanted to say? This article is about keeping those questions present throughout production, rather than simply asking for more output. The aim is to make the tool useful while leaving the reasons for a choice understandable to the person making it.

Write your criteria before seeing the first result

Once a result exists, finding arguments in its favour is surprisingly easy. A brief set of criteria, written before requesting suggestions, provides a steadier reference. For a personal website, that might mean readable articles, clear navigation, comfortable phone use and motion that supports the content. Those expectations give you something consistent against which to assess an impressive new proposal.

Not every criterion needs a number. “This should feel like my own site” is meaningful, but it becomes more useful when unpacked. Does the wording sound natural? Are the images relevant? Can a visitor quickly understand where they are? Describing an idea to AI helps begin the conversation. Decision criteria help structure what happens after the first answer. They also make it easier to explain why a technically competent result might still be the wrong choice for this particular project.

Considering alternatives side by side — an AI-generated illustrative scene.

Ask for alternatives before polishing one option

Spending a long time adjusting the first result can create attachment to it. A new colour, a little spacing, a rewritten sentence: the original direction slowly becomes established without being questioned. Early in the process, it can be more informative to see two or three genuinely different approaches. That means different priorities, rather than the same layout in another colour. One option might begin with the writing, another with a short introduction, and another with the projects.

Do not limit the comparison to “Which looks most impressive?” Try the same small task in each version: finding an article, returning from a project, opening the menu on a phone. Write down one benefit and one cost for each approach. A larger image may create impact while pushing the introduction out of view. A shorter menu may look tidy while hiding a useful link. The value of alternatives is that they make the reasons for choosing visible.

Separate suggestions, interpretations and checked facts

An article can contain a stylistic preference beside a factual claim. “This heading feels warmer” is an interpretation. “This approach is faster on every device” is a claim that needs evidence. They should not be read with the same degree of confidence. Three simple labels can help during a project: preference, assumption and checked information. An uncertain detail then has less opportunity to disappear inside otherwise convincing prose.

NIST’s AI Risk Management Framework overview describes a voluntary framework for considering trustworthiness and risk in the design, use and evaluation of AI systems. The personal working suggestions here are neither an implementation of that framework nor evidence of compliance with it. Its broad framing is still a useful reminder: an output deserves consideration not just for its attractive result, but also for how it will be evaluated and where its limits lie.

Build a small experiment you can undo

You can try a design on one card before rebuilding an entire website. You can compare one section before rewriting a complete article. In code, observing one narrow behaviour is often a clearer starting point than trying to discover which part of a large change made the difference. None of this requires an elaborate testing system for every task. The size of an experiment should reflect the consequences of choosing badly.

Imagine considering an animation that moves article cards with the pointer. Try it on one card first. Can a keyboard user reach it? Does it create an obstacle on a phone? Is the title still comfortable to read? If those answers are weak, reducing the animation is reasonable even when the effect looks attractive. The story of building SeTRoX.com puts design and readability in the same conversation. When an effect competes with the purpose of a page, it deserves another look.

Keep the right to correct a suggestion throughout

Being able to intervene means more than saying “I dislike it” on the final screen. It includes changing direction halfway through, withdrawing an assumption, and asking why a detail was added. Questions such as “Why did you choose this?”, “Is there a simpler version?” and “Would the goal still be met without this feature?” can prevent unnecessary decisions from accumulating quietly around an otherwise straightforward task.

Microsoft Research’s work on human–AI interaction presents evaluated design guidelines for that relationship. The practical point I take into personal creative work is that changing or rejecting a suggestion should feel as ordinary as accepting one. Rejecting an output does not necessarily waste the experiment. Sometimes its most useful result is learning which direction you do not want to follow. That knowledge should be allowed to shape the next request instead of being treated as a failure to appreciate the previous one.

Keep a decision note, not a second full-time project

Writing pages of documentation for every small preference would be exhausting. For an important choice, three lines may be enough: what options did I consider, why did I choose this one, and what would make me review it? These notes separate your own thinking from the long conversation generated around it. A month later, you can recover the reason for the final file, rather than only the file itself.

For example: “I reduced the animation because it competed with the heading; I can review that when new artwork arrives.” There is a choice, a limit and a condition for reconsideration in one sentence. You do not have to turn every decision into a permanent rule. Circumstances change as a project develops. Consistency does not require never changing your mind; it requires understanding why you changed it. A brief note can preserve that understanding without making the process cumbersome.

Checking a small part before committing to the whole — conceptual illustration.

Match the depth of checking to the consequences

A punctuation preference and a command that deletes files do not carry the same weight. Deciding where to spend more attention is more useful than treating every output with equal suspicion until nothing moves forward. For a public factual claim, inspect the source. For personal information, use what its owner has actually supplied. For technical behaviour, choose an appropriate test. A clear explanation of an unfamiliar topic is not a substitute for checking it.

Before publication, look beyond the paragraphs. Does the linked page open? Does the image support the sentence beside it? Does the English or Turkish version carry the same idea naturally? These checks do not guarantee that every problem has been found. They make the boundary between knowledge and assumption easier to see. Recording that a check remains undone is more useful than quietly treating it as complete, especially when another person will rely on that claim later.

Try one decision on a concrete example

Imagine choosing an article headline. The tool suggests a more intriguing option, explaining that it may attract attention. The wording is lively, but it promises an answer the article does not provide. Appeal alone cannot settle this decision. A criterion established earlier—“The headline should accurately describe what readers will find”—now becomes useful. A quieter alternative may connect expectation and content more honestly. You do not need a large report to begin this comparison. Reading the headline beside the opening paragraph and asking whether its promise is fulfilled is a practical first step.

The same reasoning can apply to an interface. An attractive project image does not necessarily justify narrowing the space available for reading. First inspect the title, description and return path together on one screen. That small choice makes it possible to see where your criteria help. A broader experiment can follow if needed. Understanding a decision does not require changing the entire system at once.

If a claim cannot be supported by a source, asking for more confident wording will not resolve the gap. You can remove it, narrow it, or note that it remains unverified. Not every gap needs a definite answer. Sometimes a better publication comes from withholding a sentence you do not know enough to publish, rather than adding another paragraph. That is part of production too, rather than something that automatically makes the work incomplete.

How do you know the choice is still yours?

It is a good sign if you can explain why you selected a solution without merely repeating the tool’s wording. If you can name an alternative, describe what you gave up and identify a reason to reconsider, there is a considered relationship between you and the proposal. The result does not have to be perfect. Its reasoning needs to be understandable to the person taking responsibility for it.

Try this on one small task today: request a suggestion, ask for one meaningful alternative, then put your own criteria between them. Choose the version whose reasons you can explain, rather than automatically taking the brightest-looking one. Moving from an idea to a working project with AI is also about understanding the work well enough to make it your own. The tool’s contribution can grow while your space for judgment remains visible.