How I Talk to AI

Since the emergence of large language models, prompt engineering has become a mainstream topic. People discuss how to write the perfect prompt, eliminate ambiguity, and extract the best possible result from an AI system.

Some of that advice remains useful. When an instruction is too vague, an AI may fill in the missing details according to its own assumptions. The result may be reasonable, but still different from what the user actually intended.

Yet the opposite can also become a problem.

When instructions are excessively detailed, AI agents may become overly attached to them. They can follow every sentence too literally, interpret minor suggestions as permanent requirements, and respond more strongly to the wording of the prompt than to the evolving needs of the project.

This is why original prompt-engineering advice does not always fit the way I work.

In many of my projects, I do not begin with a perfectly defined vision. I may understand the goal, but not yet know the best path toward it. I cannot always predict what the agent will discover after examining the codebase, testing an idea, or encountering the real constraints of the problem.

An approach that sounds correct at the beginning may later prove to be based on incomplete assumptions.

The difficulty is that an AI agent may continue following those early assumptions long after they should have been reconsidered. Instead of adapting to what it learns, it may remain loyal to the original prompt. At that point, the prompt stops guiding the work and begins limiting it.

I once tried to solve this by explaining my intentions to one AI agent and asking it to rewrite them according to prompt-engineering best practices. I carefully reviewed the resulting prompt before giving it to a coding agent.

Even after all that preparation, the outcome was still not as good as I expected.

The problem was not simply that the prompt needed more detail. In some ways, it already contained too much.

When Instructions Become Technical Debt

Long-term instruction files such as AGENTS.md can create a similar risk.

These files are useful for recording durable project knowledge, coding conventions, safety boundaries, architectural constraints, and operational requirements. They help an agent understand the environment without forcing the user to repeat the same context during every task.

However, they can also accumulate instructions that no longer deserve to be permanent.

A rule that was useful for one task may become irrelevant later. A rule may gradually prohibit the progress of the project without you noticing it. A workaround created for an earlier limitation may continue influencing the project even after that limitation disappears.

Over time, the instruction file can become a form of technical debt.

The agent may struggle to distinguish between:

a critical safety requirement,
a stable project convention,
a temporary development preference,
an outdated workaround,
and an idea that was never meant to become a rule.

The more these categories are mixed together, the more difficult it becomes for the agent to exercise sound judgement.

This is especially dangerous when the same instruction is repeated across system prompts, project files, task descriptions, and previous conversations. Repetition can unintentionally increase the perceived importance of a rule, causing the agent to behave too cautiously or too rigidly.

More instructions do not necessarily create more control. Sometimes they simply create more inertia.

Direction Without Micromanagement

For my projects, a better approach is usually to give the agent enough information to understand my intention while leaving room for it to investigate the problem.

The goal is not to provide no guidance.

The agent should still understand:

what outcome I want,
why the task matters,
what context is relevant,
which constraints are genuinely non-negotiable,
which actions require approval,
and what a successful result should look like.

What I try to avoid is prescribing every implementation decision before the agent has had the opportunity to examine the situation.

There is an important difference between defining the destination and dictating every turn along the road.

For example, instead of specifying an entire architecture in advance, I may ask the agent to inspect the existing system, identify the main weaknesses, propose an approach, and explain the trade-offs before making major changes.

This gives the agent room to discover information that I may not have considered.

In many cases, a capable agent already has a reasonable idea of how to begin. It may still make mistakes, but those mistakes can be observed and corrected during the process. That is often more effective than trying to anticipate and prevent every possible mistake through an enormous prompt.

Control Through Feedback

The most useful form of control is often not more detailed upfront instruction, but a better feedback loop.

Asking the agent to report after meaningful stages allows me to inspect the direction of the work, understand its decisions, and intervene before a small mistake becomes a large one.

The agent might first:

inspect the relevant code and documentation,
summarize what it found,
identify uncertainties and risks,
propose a direction,
implement a coherent portion of the work,
report the result and any new discoveries.

This creates visibility without requiring constant micromanagement.

The interaction becomes less like issuing a perfect command and more like steering an ongoing process.

That distinction matters because complex work rarely unfolds exactly as expected. New information appears. Assumptions fail. Constraints conflict. A good development process must be able to respond to those discoveries.

A rigid prompt attempts to control the future in advance.

A good feedback loop allows the work to improve as the future becomes clearer.

What Belongs in `AGENTS.md`

Files such as AGENTS.md should therefore be treated carefully.

They are best used for knowledge that is durable, broadly applicable, and important across many tasks. This may include:

the purpose of the project,
key architectural boundaries,
testing and validation expectations,
safety or security rules,
production restrictions,
repository conventions,
commands that must or must not be used,
and actions that require explicit approval.

They are less suitable for:

temporary preferences,
task-specific implementation ideas,
speculative architectural choices,
one-off debugging instructions,
repeated reminders already defined elsewhere,
or rules created only to compensate for a single past failure.

A useful test is to ask:

Should an agent still follow this instruction several months from now, across many different tasks?

When the answer is no, the instruction probably belongs in the current task or conversation rather than in the permanent project guidance.

Durable instructions should also be reviewed periodically. They should not become permanent merely because they were once written down.

Strict Boundaries Still Matter

None of this means that agents should always be given complete freedom.

Some boundaries must remain strict.

Safety, security, privacy, irreversible actions, production systems, financial operations, destructive commands, regulatory requirements, and critical project constraints may require explicit and non-negotiable rules.

The important distinction is between strict outcome boundaries and unnecessarily rigid development procedures.

For example, it may be appropriate to require that an agent never push directly to a production branch, never delete user data, or never deploy without approval. Those are meaningful boundaries.

It may be less useful to prescribe every intermediate command, every implementation detail, or the exact order of all exploratory work when several safe approaches could achieve the same result.

Even in highly controlled projects, the development process should leave room for iteration.

A failed attempt should produce information that improves the next attempt. It should not force the agent to blindly repeat a frozen plan or discard every useful discovery because the initial implementation did not succeed.

Good governance should constrain dangerous outcomes without preventing learning.

The Best Practices Are Already Changing

This shift is not limited to my own workflow. It can also be seen in the guidance being developed for newer AI models.

Earlier prompt-engineering advice often encouraged users to be highly specific. Users were told to define the desired context, outcome, format, length, tone, style, and process in detail.

That guidance made sense for models that required more explicit scaffolding to reliably produce the intended result.

Newer models, however, are increasingly capable of inferring intent, examining context, selecting tools, and adapting their reasoning without having every intermediate step prescribed.

As models become more capable, excessive instruction can create new problems. Repeated rules, unnecessary examples, verbose tool descriptions, and overlapping constraints can consume context, introduce contradictions, and distract the model from the actual objective.

The emerging principle is not that prompts should be vague.

A lean prompt is not an empty prompt.

The model still needs domain context, hard constraints, approval boundaries, and clear success criteria. What becomes less necessary is dictating every intermediate action before the model has examined the problem.

The newer approach is closer to this:

Describe the destination clearly, establish the important boundaries, and allow the agent to determine the best route.

Examples and detailed style requirements still have value when they represent real product needs or when they correct a weakness that has actually been observed.

They are less valuable when they are included simply because more detail feels safer.

The same principle applies to tool descriptions. An agent should understand what a tool does, when it should be used, and what its important limitations are. It does not necessarily need a long explanation containing every imaginable edge case.

Likewise, autonomy and approval rules should be stated clearly and compactly. Repeating instructions such as “ask first,” “make no changes,” or “wait for approval” in several places can make an agent unnecessarily hesitant, even when it is performing safe and expected local work.

Each important rule should ideally have one clear source of truth.

Prompting Depends on the Model

Prompt-engineering practices are not universal laws. They depend on the capabilities and behaviour of the model being used.

A prompt that worked well for an older model may be excessive for a newer one. Scaffolding that once prevented mistakes may later interfere with the model’s ability to use its own judgement.

The opposite can also happen. A prompt designed for a highly capable model may be too sparse for a weaker or more specialized system.

Instructions should therefore be evaluated in relation to the model, the task, the tools, and the environment.

They should not be carried forward indefinitely simply because they once worked.

When the underlying model changes, the prompting strategy should be tested again.

This is particularly important for long-running projects. As models improve, instruction files may retain assumptions about weaknesses that no longer exist. The agent may be forced to follow cumbersome procedures that were originally created to compensate for limitations of an earlier generation.

Prompt maintenance should therefore be treated much like code maintenance.

Unused instructions should be removed. Repeated instructions should be consolidated. Conflicting rules should be resolved. Temporary workarounds should be retired. Important constraints should remain visible and precise.

Prompt Engineering Is Process Engineering

None of this means that prompt engineering is disappearing.

It is changing.

Prompt engineering is becoming less about crafting one perfect command and more about designing a reliable process around the model.

Engineering is rarely about producing a perfect design on the first attempt. It involves developing an initial understanding, building something, observing its behaviour, identifying weaknesses, and improving it through repeated iterations.

Working with AI should be approached in the same way.

The quality of the outcome does not come only from the first prompt. It comes from the entire system:

the initial direction,
the available context,
the tools the agent can access,
the agent’s discoveries,
the mistakes it makes,
the feedback it receives,
the evaluations used to judge its work,
and the adjustments made afterward.

This means prompt engineering should not be reduced to writing instructions.

It also includes testing those instructions, observing how the model responds, comparing different approaches, removing rules that no longer help, and preserving the ones that consistently improve results.

The prompt is only one component.

The conversation, memory, tools, project documentation, approval model, evaluation criteria, and feedback loop all shape the final outcome.

A prompt should therefore not be treated as a final specification that must anticipate every possible problem.

It is better understood as the beginning of a learning process.

My Current Approach

My current approach is simple:

Give the agent enough direction to begin, but do not unnecessarily complicate the task.

Explain the intention clearly. Provide the relevant context. Define the hard boundaries. Describe what success looks like. Then allow the agent to inspect the problem and form its own understanding.

Listen to what it discovers.

Ask it to report after meaningful stages.

Correct the direction when necessary.

Keep durable project knowledge in long-term instruction files, but avoid filling them with temporary preferences or overly specific procedures.

Review those instructions as the model and the project evolve.

Do not attempt to prevent every possible failure in advance. Design the process so that failures are visible, limited, and useful.

Most importantly, do not wait until you have written the perfect prompt.

Give the agent enough direction to start, observe what it does, and improve the work together.

The best prompt is often not the one you spend the longest preparing. It is the one that begins a productive feedback loop.

Prompt engineering is not disappearing. It is becoming less about composing a perfect command and more about creating a system in which the instructions, the agent, and the resulting work can continuously improve.