Is an AI Prompt a One-Time Setup? Why Iterative Verification is More Important Than Fixed Prompts

When introducing generative AI into workflows, many people’s first concern is the prompt.

They meticulously craft prompts, considering what role to assign, what format the answer should take, and what conditions must be included. There’s an expectation that a well-crafted prompt will consistently yield stable results in the future.

However, in practice, using LLMs reveals that fixing a prompt does not necessarily fix the output.

Even with the same prompt, the output can vary if the model or execution environment changes. Therefore, an iterative process of continuously verifying and refining results is more crucial than a one-time prompt creation.

Even if the Prompt is Fixed, the Output is Not

LLMs are not systems that always return the same result for a given command, unlike conventional programs.

Traditional programs generally return the same result when given the same input and execution conditions.

입력값 + 프로그램 로직 = 예측 가능한 결과

In contrast, LLMs generate responses by calculating the probability of the next token based on the input context and selecting appropriate tokens from them.

프롬프트
→ 토큰별 확률 계산
→ 다음 토큰 선택
→ 다시 확률 계산
→ 응답 완성

Therefore, even with the same prompt, the expression, structure, depth of explanation, or conclusion can vary depending on the generation conditions.

For example, let’s assume the same request is executed multiple times:

다음 시스템의 보안 위험을 분석하고 개선 방안을 제시하라.

One execution might focus on access control issues, while another might prioritize data leakage or input validation problems.

This is because, even with the same prompt, the flow of tokens selected during the model’s response generation process can differ.

When New Models Emerge, the Effectiveness of Existing Prompts Can Change

Even within the same model, outputs can vary, but if the model itself changes, the differences can be even greater.

New models have different trained parameters than older ones. Training data, training methods, model architecture, alignment strategies, tokenizers, and safety policies can also differ.

Because of this, even the same words or instructions can be processed differently internally by the model.

However, understanding this simply as “each word has a fixed weight that changes” is not accurate.

A model does not store just one importance value for a specific word. Input words are split into tokens, undergo embedding and calculations across multiple layers, and are transformed into an internal representation appropriate for the current context.

Even the same word can have different meanings and impacts depending on the surrounding sentences.

보안 정책을 우회한다.
도로를 우회한다.
질문에 직접 답하지 않고 우회한다.

The word ‘bypass’ used in these three sentences is the same expression, but the meaning the model must interpret differs depending on the context.

When a new model is released, the entire set of model weights used for such context processing changes, which can lead to different responses for the same prompt.

A Prompt is Not an Independent Rule Separate from the Model

If you think of a prompt like program source code, you might have the following expectations:

좋은 프롬프트를 만든다.
→ 프롬프트를 고정한다.
→ 언제나 일정한 품질의 결과를 얻는다.

However, in actual LLM systems, a prompt is not an independent rule separate from the model.

The effectiveness of a prompt is influenced by the following factors:

• The model and model version being used
• System prompt
• Previous conversations and current context
• Length and structure of input data
• Generation settings such as temperature, top-p, seed
• Results of external searches or tool calls
• Safety policies applied by the service provider
• Output length and context limits

In other words, fixing a prompt only fixes one element of the entire execution environment.

If the model changes or system guidelines are altered, the existing prompt may no longer deliver the same quality as before.

A Prompt is Closer to a Hypothesis Than a Definitive Answer

When writing a prompt, you establish a hypothesis that the desired outcome will be produced.

For example, you might create a prompt like this:

보안 전문가의 관점에서 다음 구성의 취약점을 분석하라.
각 취약점에 대해 위험도, 공격 가능성, 대응 방안을 작성하라.
확인할 수 없는 내용은 추측하지 말고 확인이 필요하다고 표시하라.

This prompt describes the behavior expected by the author.

However, whether it actually satisfies the following conditions must be verified through execution:

• Did it find all major vulnerabilities?
• Did it consistently assess risk levels?
• Did it avoid generating unsubstantiated content?
• Are the countermeasures specific?
• Did it adhere to the output format?
• Does it maintain quality even with different input data?

Therefore, a prompt is closer to a hypothesis that needs to be verified rather than a complete answer.

프롬프트 작성
→ 결과 생성
→ 기대한 동작과 비교
→ 문제점 확인
→ 프롬프트 수정

An Iterative Loop is More Important Than a Single Prompt

To refine AI results, you should not stop after a single prompt execution.

A more realistic approach is to iterate through generation, evaluation, modification, and re-execution.

요청 정의
→ 초안 생성
→ 결과 검토
→ 오류와 누락 확인
→ 보완 요청
→ 수정된 결과 생성
→ 최종 검증

For example, if you had an AI write a technical document, instead of using the first result immediately, you could add the following review steps:

1. Verify that all requirements have been met.
2. Check for any technically incorrect information.
3. Remove redundant or unnecessary explanations.
4. Request any missing items again.
5. Test code or commands in a real environment.
6. Have a human review the final result.

This iterative process is not merely about revising sentences multiple times.

It is a quality control process that manages the probabilistic output of LLMs to a level suitable for practical use.

Iteration Does Not Automatically Lead to the Correct Answer

While iteration is important, continuously querying the same model does not automatically lead to the correct answer.

An LLM can establish incorrect premises in its initial response. If you then request a review based on those premises, it might elaborate on the flawed content with more sophisticated justifications instead of correcting it.

잘못된 초안
→ 동일한 전제를 기반으로 검토
→ 잘못된 설명을 보강
→ 더 그럴듯한 오답 생성

Therefore, an iterative loop should include not only simple re-querying but also independent verification methods.

Calculation results should be verified with a calculator or code, and technical facts should be compared with official documentation. If it’s code, actual tests should be run, and structured outputs can be subjected to schema validation.

LLM 결과
   ├─ 사실 확인 → 공식 문서·검색·RAG
   ├─ 계산 확인 → Python·계산기
   ├─ 코드 확인 → 테스트·정적 분석
   ├─ 형식 확인 → JSON Schema
   └─ 최종 판단 → 사람의 검수

While LLMs can handle both generation and review, critical results should not be finalized solely based on the LLM’s judgment.

The Human Role is Not Merely That of an Approver

In the iterative process of AI utilization, humans do not merely act as final approvers of results.

Humans assess what the AI got wrong and decide which aspects need to be improved in the next iteration.

For example, if a critical access control issue was omitted from an AI-generated security analysis, you could specifically request a revision as follows:

이전 분석에서는 인증과 입력값 검증을 다뤘지만,
사용자별 권한 분리와 리소스 소유권 검증이 빠졌다.

다음 항목을 추가로 분석하라.

1. 다른 사용자의 리소스에 접근할 가능성
2. 객체 식별자를 변경했을 때의 권한 검증
3. 관리자 기능의 서버 측 접근통제
4. 각 문제에 대한 검증 방법과 대응 방안

In this process, a human doesn’t simply ask, “Please rewrite it.”

They identify missing areas, precisely specify shortcomings, and guide the AI to re-execute in a verifiable manner.

As human intervention is repeated, the results increasingly align with actual requirements.

From Prompt Engineering to Evaluation Engineering

In the early stages of generative AI adoption, the skill of crafting good prompts was emphasized.

Of course, prompt quality remains crucial. Clearly defining roles, requirements, output formats, and constraints can improve response quality.

However, in the actual operational phase, how prompts are evaluated and managed becomes more important than the prompts themselves.

프롬프트 작성
→ 테스트 데이터 준비
→ 결과 측정
→ 실패 유형 분류
→ 프롬프트와 워크플로 수정
→ 회귀 테스트

From an evaluation engineering perspective, the following questions are necessary:

• By what criteria will accuracy be evaluated?
• How will omissions be measured?
• What are unacceptable errors?
• Does the quality remain consistent when the model changes?
• Which results require human approval?
• How will failed results be incorporated into the next improvement cycle?

Ultimately, what’s important is not creating the most elaborate prompt.

It’s about establishing a system to continuously verify that AI results meet the required standards.

Prompts Should Be Version Controlled Like Software

If prompts are used in a professional context, it’s better to manage them as system components rather than simple text files.

At a minimum, the following items should be recorded together:

model: example-model-v2
prompt-version: 1.4
temperature: 0.2
top-p: 0.9
system-prompt-version: 2.1
evaluation-dataset: security-review-v3
updated-at: 2026-07-17

Saving only the prompt makes it difficult to reproduce the same environment.

It’s essential to manage which model and parameters were used, what test data was used for evaluation, and what improvements were made compared to previous versions.

Especially when changing models, regression tests should be performed using existing test data.

기존 모델 + 프롬프트
→ 기준 성능 측정

새 모델 + 기존 프롬프트
→ 동일한 평가셋으로 비교

성능 저하 또는 동작 변화 확인
→ 프롬프트와 워크플로 수정

A new model having higher performance does not always guarantee better results with existing prompts.

If the model’s interpretation of instructions and output tendencies change, expressions that previously worked well might become unnecessary or even have a negative impact.

What Needs to Be Fixed is Not the Prompt, But the Quality Standards

Continuously modifying prompts does not mean they should be written spontaneously every time.

Base prompts should be standardized and version-controlled. However, they should not be considered permanently unchanging definitive answers.

What needs to be fixed are the quality standards that the results must meet, rather than the prompt text itself.

For example:

• Distinguish between facts and speculation.
• Explicitly state unconfirmable content.
• Do not omit essential items.
• Adhere to the specified output format.
• Obtain human approval for security-critical actions.
• Provide verifiable evidence for technical claims.

It is appropriate to first define these standards and then continuously adjust prompts and execution procedures to suit the currently used model and workflow.

Conclusion

Fixing a prompt does not fix the AI’s output.

Even with the same model, results can vary depending on generation conditions, and when new models are released, the learned weights and context processing characteristics change, which can alter the effectiveness of existing prompts.

Therefore, to reliably utilize generative AI, one should not rely on a single, well-written prompt.

While base prompts should be standardized, actual results must be continuously verified, deficiencies re-requested, and adjustments made in response to changes in models and environments.

Ultimately, the quality of AI utilization is not determined by a single perfect prompt.

프롬프트
→ 생성
→ 평가
→ 검증
→ 수정
→ 재실행
→ 사람의 최종 판단

This iterative structure evolves AI results into a more accurate and complete form.

A prompt is not the answer, but the starting point.

And the quality of AI is not established at the moment a prompt is fixed, but through the continuous process of verifying and improving results.