At the table with AI: from an idea to a working project

The distance between an answer and a working project

Developing a project with AI is different from receiving a good answer to a question. An answer can be read in seconds. A working project needs to be assessed together with its files, data, links, tests, and deployment environment. A screen can look impressive while its buttons fail. Code can look plausible while being incompatible with the installed software version. Moving from an idea to a working project therefore involves a continuing process, rather than one elaborate prompt. I think of AI here as a tool that prepares and carries out work within that process.

For me, this means explaining an intention and continuing to look at the result. When developing an application, game, or website, we use suitable tools together with an assistant. That does not mean claiming personal expertise in every field those tools cover. Making a visual, changing software, and testing behavior are distinct tasks. Understanding how an output was produced and how far it was verified matters. The image of being at the same table comes from that connection: intention, implementation, and evaluation are separate steps that remain part of one conversation.

Start with the purpose and the boundaries

The first sentence of a task can describe the intended change instead of naming a technology. “Readers should be able to find the main menu on this article page” explains both a visual and a behavioral goal. Then identify the affected pages, the existing structure, and the parts that must be preserved. Without context, “fix the menu” can lead far beyond the actual need. If solving the problem does not require redesigning the whole page, saying so gives the implementation a useful boundary from the beginning.

A good task does not demand every detail at once. It makes the present goal, the acceptance criteria, and the important constraint visible. In describing an idea to AI, I build such a brief around an example. Here the focus is the cycle after that brief: how to read the plan, follow implementation, and establish that the result works. Initial clarity matters, but it cannot replace the rest of the process. An understandable request is a starting condition for useful collaboration, rather than a guarantee of a perfect output.

Build context from real files and the actual state

A conversational summary may not be enough for an assistant to understand a project. Files, project rules, installed versions, and earlier decisions matter, too. A document may describe a feature as future work even though it has already been installed. The plan and actual state need to be compared before making changes. Knowing which application and directory are involved prevents edits from being made in the wrong place. Project identity is especially important when several games or web projects share the same working environment and similar filenames.

OpenAI's guide to how its teams use Codex is an official reference that emphasizes structure, context, and room for iteration. I do not take that as a recipe for one magical prompt. The practical conclusion is that an assistant should establish relevant context rather than assume it. Copying every file into the conversation is not the answer either. Select the decisions and actual examples that matter to the target behavior. The accuracy and relevance of context are more important than simply increasing its volume.

Keep the plan small enough to make decisions

A plan is useful when it explains the work and the way the result will be checked, not when it is long. A menu task might involve identifying affected pages, attaching the shared header, and verifying navigation. Each stage needs a concrete outcome. “Make improvements” is not a meaningful stage; “the main menu appears on article and project details” is. Reading the plan at this level makes it possible to recognize early whether the implementation is still addressing the requested goal, before additional changes obscure the original problem.

Independent preparation can happen in parallel; dependent changes need their inputs first. Research and image preparation may overlap, while live content writes must wait for the data model. Do not delay independent work or begin dependent work too early. Recording dependencies makes progress, waiting, and repeated work easier to understand.

Inspect small changes through their actual result

After the first implementation, open the result rather than only reading the assistant's explanation. Is the menu visible on every relevant page? Is the text readable on a phone? Is there an understandable way back from a project detail? Those questions cannot always be answered from a code excerpt. Real browser flows matter particularly for interactive design. A still screenshot can show color and composition, but cannot establish motion, focus behavior, or transitions between pages. Visual review and usage review both need a place in the work.

Specific feedback makes an impression actionable. If text feels small, identify which text and viewport. If the menu appears to shake, identify the movement preceding it. If the return route is hard to find, name the page involved. These details do not diminish aesthetic judgment. They help turn it into an implementable correction. An unsatisfactory first result does not necessarily require restarting the whole project. A size adjustment, shared component, or navigation decision may be enough. Choosing the next change should also take account of the pieces already working well.

State what a test actually demonstrates

“Tested” should come with a description of what was checked. Type checking catches certain incompatibilities in code. A build demonstrates that a production package can be prepared. Browser tests can exercise selected user flows. None of them alone establishes a perfect experience on every device or the absence of every security risk. A passing button test should not become a claim that the entire site is accessible. The scope of the evidence should match the scope of the conclusion. A trustworthy working process preserves that distinction when reporting results.

The official Playwright documentation on writing tests explains how browser actions and assertions can be combined. That does not require turning every visual preference into test code. Critical publishing and navigation behavior may be suitable for automation; visual feel and real touch behavior still need separate inspection. The purpose of a test is to check what was promised to the user, rather than echo the implementation. Being clear about checks that were not performed also makes the completed checks easier to assess and more valuable as evidence.

Reproduce a problem before guessing at a correction

When a bug is reported, making a quick speculative fix can be tempting. A better first step is establishing the conditions in which the problem occurs. Can it be reproduced on the same page, language, link, and action? Does it arise from content, a browser preference, or the live environment? Separating those possibilities prevents changes in the wrong place. A page opening locally does not establish that it opens with the correct data in production. Name the environment as well as the symptom when investigating a problem.

Once the issue is reproduced, reduce the expected behavior to a sentence. Make the narrowest suitable change and run the same flow again. If a shared component caused the issue, inspect the related pages as well. That does not mean rerunning every unrelated system after each adjustment. The validation scope should reflect risk and dependencies. This method combines AI's capacity to produce changes quickly with measured verification. The goal becomes a prompt and explainable result, rather than merely a fast answer that sounds convincing before the problem has been observed.

Give tools and data the access the task requires

Developing a project does not require full access to every account. Editing content, creating an administrator, and changing a server are different permissions. The necessary access for each task should be clear. Putting credentials into a conversation or a project document is not an appropriate way to supply context. The official GitHub guidance on preventing data leaks offers a reference for protecting sensitive information. Useful project material and secrets need to be separated even when they happen to be stored near one another.

The same care applies to articles and images. A live screenshot can include private messages or administrator details. A file that appears to be a design asset can contain other data. Review the shareable result separately. An assistant finishing a task does not make every generated artifact automatically public. The distinction between public site content and the private administration area is a basic working boundary. A good delivery needs the correct sharing limits as well as the correct content. Those limits should remain visible throughout preparation, review, and publication.

Distinguish the prepared package from the live deployment

A successful build completes an important part of the work, but live publication is a separate step. Does the domain reach the correct application? Does HTTPS open? Do data and media remain after deployment? Those questions need checks in the publishing environment. The architecture story of SeTRoX.com describes actual decisions, including two language domains sharing one application and database. In such a structure, examining a local page is not sufficient evidence that both public domains behave correctly. The result needs to be observed where visitors will use it.

The delivery report should connect the change, the reason, and the verification. What was added, what need does it address, and how was it checked? It should also identify any owner-dependent action or later measurement. This does not require a long activity log. It requires enough evidence for the person evaluating the work. A link that opens, an observed behavior, and a completed test are more useful than “everything is great.” The quality of AI collaboration shows up in the concrete result before it shows up in the polish of the explanation.

The continuing cycle of making things together

A game such as Rivunox and this personal website are different projects, but both need a connection between intention, implementation, and review. Each round can make the goal clearer. Sometimes a new feature is needed; sometimes an existing part needs simplification. The availability of many tools does not require using every possibility. The project's need, the owner's intention, and the verified result provide the basis for the next decision. Maintaining that connection prevents production from turning into a collection of impressive but unrelated options.

Working with AI becomes valuable when a thought can be compared with a concrete result. Clear tasks, accurate context, and proportionate verification connect the work. An assistant can accelerate production; explaining the intention, giving feedback, and assessing evidence still matter. A working project grows through that cycle, with each next change grounded in what was actually observed.