How do we describe an idea to AI?

From an attractive sentence to an actionable task

“Make me a modern application” sounds like an understandable request. Yet modern could mean appearance, speed, or ease of use. The intended user and the job the application should do are also unspecified. An AI assistant may fill those gaps with assumptions. The output can look impressive and still miss the actual need. A good brief reduces uncertainty before it improves the wording. In this article, I build a task structure for explaining an idea to AI, using one hypothetical application to make the decisions concrete rather than leaving them as general advice.

The example is a reading list. A person saves a link with a title and a short note, then finds it again later. This is not an announcement of a completed SeTRoX product or a claim about my own habits. It is a scenario chosen to demonstrate brief writing. If the initial question is still unclear, where an idea begins discusses defining its first scope. Here the goal is to turn that selected question into work an assistant can implement and we can assess. A small output still deserves a clear description.

Purpose: what job should the person finish?

The first part of the brief can be a sentence: “A person should be able to save links they want to read later with a short explanation, and find them again when needed.” That states the job rather than naming the technology. The next line can give the situation: “The first version is a single-user browser experiment, with no sharing or membership.” The assistant then has no reason to add an account system or social features. Purpose and situation are distinct, but together they describe the direction of the task.

If several purposes are included, put them in order. Saving, editing, searching, and sharing together can quickly expand the first version. Choosing save and retrieval first, while explicitly postponing other behaviors, produces a more understandable request. “Only three fields and a list in this version” does not make the idea less valuable. It gives the learning exercise a boundary. Explain which need should be met before deciding every design choice for the assistant. That creates room for comparing alternatives without losing sight of the result the application needs to produce.

Context: show what already exists

State when the task is not starting from nothing. The language, framework, storage approach, and design rules of an existing project can affect the work. Instead of attaching everything, point to relevant paths and examples: use the existing form component, work in this directory, or do not add account fields to the record model. These directions reduce guesswork. Installed library versions matter, too. Sample code from a different version may look correct and still fail in the actual project. Context should describe the working environment the implementation will encounter, not a generic imagined one.

OpenAI’s Codex guide discusses context and structure. The brief format here is a practical editorial approach, rather than a mandatory formula. A relevant screen, a preserved decision, and a completion condition can be more useful than unrelated background. Choose the facts required for this task before adding more material.

Scope: the first version and the work that waits

The sample scope could read: “A link field, a title field, an optional note, a save button, a saved-items list, title or note search, and record deletion.” Then make later work visible: “No accounts, cloud synchronization, sharing, notifications, or automatic summaries in this version.” This second part is a version plan, rather than a defense of missing features. Not adding something can be the right decision. A requirement that does not help complete the first job adds work for both the assistant and the person reviewing its result.

Operating boundaries can sit alongside feature scope. For example: use only local sample data, do not request real account credentials, and do not change files in other projects. Explaining where an assistant may act is as important as describing what should appear on the screen. “Handle everything” is very broad. Separating the visible result from the permitted system changes makes the task more reliable. This is particularly useful for live site work. Updating an article does not inherently require changing administrator accounts or expanding permissions on the server hosting the site.

Provide an example input and an expected output

An example turns an abstract description into something concrete. A sample record could use the title “Introduction to web accessibility,” the link “https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Accessibility,” and the note “Return to the sections on form labels and keyboard use.” The resulting card should show the title, the short note, and an understandable action that opens the link. This is not a compulsory design to copy exactly. It demonstrates which information serves which job. Using an accessible reference rather than a fabricated domain also makes checking the output simpler.

Include an unsuccessful input, too. If the title is empty, do not add a record and show a helpful explanation close to that field. The brief now describes error behavior as well as the successful path. MDN's form validation guide provides useful material on validation and feedback. Specific choices will vary with the application. The important difference is between saying “there should be no errors” and explaining what should happen in a known error condition. The latter can be observed, discussed, and checked after implementation.

Acceptance criteria: the conditions for calling it complete

An acceptance criterion describes behavior we will observe before considering the work complete. The first criterion could be that submitting a valid title and link adds a visible item. The second could be that the item remains after refreshing the page. A third could require a word from the note to find the record in search. A fourth could require a deleted item to stay deleted after refresh. These statements do not prescribe a particular architecture. They describe the outcome, so different implementations can still be evaluated against the same behaviors.

Add phone and keyboard use explicitly. The form should not cause horizontal overflow at a narrow viewport; fields should have meaningful labels; the save action should be reachable by keyboard. “Perfect on every device” is difficult to establish, while “the form does not overflow at 390 pixels” describes a concrete check. It still does not prove an ideal experience on every physical phone. Acceptance criteria are an agreement about the behaviors to investigate, not a guarantee covering everything. Report their results within the actual limits of the verification performed.

Think about empty and unsuccessful states early

The first design often looks full because it contains sample records. A new person's actual list may be empty. Include that state: show a short explanation and a clear route to adding the first item. A search with no results also needs an understandable message instead of an unexplained blank area. These explanations are there to help someone understand what happened, not teach them implementation details. The interface should describe its state clearly enough that the person does not interpret an ordinary empty list or failed action as their own mistake.

Should the form preserve its contents if saving fails? What happens if deletion was accidental? Not every question requires a large feature in the first version, but the behavior still needs a decision. Asking for confirmation before deletion and offering undo are different approaches. Choose according to the purpose and situation. “Show an appropriate error” leaves too much open. Explain which operation has failed and what option the person has next. That makes the eventual result easier to assess, and prevents successful-path screenshots from becoming the only definition of the application.

Mark uncertainty without turning every choice into a question

Not every decision is known at the start. If it is unclear whether records should live only in this browser or on a server, mark that as a decision: first explain the difference for this example, then implement the chosen approach. The assistant should not silently treat an assumption as an explicit requirement. On the other hand, every small color or spacing choice may not require a new question. Distinguish owner-dependent decisions from routine implementation judgments. That keeps useful autonomy while preserving control over choices that change the purpose or data behavior of the project.

Do not treat secrets as context. Passwords, access keys, and private messages should not be pasted into a prompt as project background. Use the relevant authorized connection instead. The official GitHub guidance on preventing data leaks offers a reference for investigating these boundaries. A brief explains the task and its limits; it is not a credential store. When a fact needs verification, an accessible official document is usually more useful background than copying sensitive account material into the same conversation as ordinary instructions.

Evaluate the first result against the brief

Once the output arrives, return to the brief rather than stopping at “looks good” or “does not work.” Is the purpose met? Does the example record appear correctly? Have the acceptance criteria been exercised? The official Playwright test-writing documentation offers a reference for automating selected browser behaviors. Save, refresh, search, and delete could be checked in this example. How the visual layout feels needs a separate review. An automated pass and satisfaction with the design provide different kinds of information, both of which can matter for the final decision.

Describe a gap with the same specificity: “Search works on titles but not notes; complete the third acceptance criterion.” That feedback does not discard the previous work. It identifies the missing behavior. At the table with AI examines the implementation and review cycle more broadly. A successful brief is not one that never needs a correction. It is one that makes the location and reason for a correction understandable. The brief therefore remains useful during evaluation, rather than becoming a document written once and forgotten after the first prompt.

A reusable outline for the next brief

For a new task, try this order: purpose, existing context, first-version scope, exclusions, sample input, expected behavior, empty and error states, acceptance criteria, and delivery format. The final item matters. Are we expecting a working link, changed files, a design image, or research notes? If delivery is unclear, an assistant may return a plan when we expected a running result. Using the same words does not always mean expecting the same output. Say what the reviewable artifact should be, and how it relates to the task's purpose.

A small correction may need two sentences; a larger project needs more context. SeTRoX.com’s story shows visual intent becoming clearer alongside content, domain, and publication decisions. The principle is to supply the information needed for implementation and evaluation, rather than simply more words. A brief makes an idea workable, reviewable, and easier to improve.