A Good Prompt Doesn't Guarantee Correct Execution: The Missing Layer in AI Engineering

The conversation around AI productivity has become increasingly focused on prompt engineering. Developers are encouraged to write more detailed instructions, provide better context, define constraints, and break complex requests into smaller tasks.

These practices are useful. But they address only one part of the problem.

There is a fundamental difference between expressing an instruction, interpreting its intent, and executing it without violating its constraints.

I've encountered this distinction even in relatively simple tasks. For example, asking an image editor to remove a title while preserving the rest of the image can result in an entirely different composition. The instruction is clear, the requested modification is small, yet the output may change elements that were never supposed to be touched.

This isn't necessarily a prompt-writing failure. It exposes a limitation in how the model interprets and performs the requested operation.

The same problem becomes considerably more expensive when it appears in software engineering.

The Instruction Is Not the Operation

Consider a simple image-editing request:

"Remove the title from this image. Keep the background, typography, lighting, composition, and all other elements unchanged."

From a human perspective, this is a localized modification. The original image is the source of truth, and the title is the only element that needs to disappear.

However, many generative image-editing systems don't operate like traditional graphics editors.

Depending on the implementation, an editing request may involve inpainting, latent-space reconstruction, image-to-image generation, or a combination of these techniques.

Even when a mask identifies the intended modification area, reconstruction can introduce changes around the masked region. Some implementations may also alter unmasked areas because the model is generating a plausible image rather than performing a strictly deterministic pixel operation.

This distinction is important.

There is a difference between:

• Generating an image that resembles the original.
• Editing a specific region of the original.
• Preserving every pixel outside the requested modification.

A prompt can describe the third requirement perfectly without the underlying editing pipeline actually guaranteeing it.

If exact preservation is required, the workflow may need explicit masking, controlled compositing, and restoration of the original pixels outside the edited region.

In other words, better instructions cannot replace missing execution guarantees.

Prompt Interpretation Is Not the Same as Prompt Execution

A model can identify the general intention of a request and still fail to satisfy its actual requirements.

Consider a software engineering example.

A developer asks an AI agent to refactor a payment-processing service without changing its existing behavior.

The agent understands the request. It reorganizes the code, extracts methods, reduces duplication, and produces a cleaner implementation.

The resulting code may even pass the existing test suite.

But suppose the original implementation guarantees that repeated payment requests with the same idempotency key cannot create duplicate transactions.

During refactoring, the agent moves the idempotency check outside the database transaction.

Under concurrent requests, two workers can now observe that no previous transaction exists and both proceed to create one.

The refactored code looks cleaner, but an important behavioral guarantee has disappeared.

The problem isn't necessarily that the agent misunderstood the word "refactor."

It failed to preserve a constraint that was part of the original system's behavior.

A simplified illustration:

BEGIN;

INSERT INTO payment_requests (
    idempotency_key,
    status
)
VALUES (
    :key,
    'processing'
)
ON CONFLICT (idempotency_key)
DO NOTHING
RETURNING id;

-- Continue only if this request
-- successfully acquired the key.

INSERT INTO payments (
    request_id,
    amount
)
VALUES (
    :request_id,
    :amount
);

COMMIT;

The uniqueness constraint and transaction boundaries are part of the correctness mechanism. Moving or weakening them can change the behavior under concurrency even if ordinary unit tests continue to pass.

This is why code generation, code understanding, and behavioral preservation should be evaluated separately.

Complexity Is More Than the Length of a Prompt

A common assumption is that complex tasks can be handled by writing longer and more detailed prompts.

But prompt length is not a reliable measure of task complexity.

Consider two instructions:

Task A:

Change the button background color from blue to black without modifying its dimensions.

Task B:

Implement a payment workflow that supports retries, concurrent requests, partial failures, idempotency, refunds, audit logging, and backward-compatible API responses.

The second task isn't difficult simply because it contains more words.

Its complexity comes from the relationships between its requirements.

For example:

• A retry must not create another payment.
• A failed external request must not leave an inconsistent internal state.
• A refund must reference the correct original transaction.
• Concurrent requests must not violate balance constraints.
• Existing API consumers must continue receiving compatible responses.
• Audit records must accurately reflect state transitions.

These constraints interact.

Changing the implementation of one component can affect the guarantees of another. An apparently correct local solution can therefore produce an incorrect system-level result.

A model that handles isolated instructions successfully has not necessarily demonstrated the ability to reason about these dependencies.

Why Passing Tests Doesn't Always Mean the Task Was Completed

There is another layer to this problem: verification.

AI-generated implementations are frequently evaluated using the tests available to the agent. But passing a test suite establishes only that the implementation satisfies the conditions covered by those tests.

It doesn't prove that every relevant requirement has been preserved.

Consider a test suite that checks:

it("creates a payment", async () => {
  const result = await createPayment({
    amount: 100,
    idempotencyKey: "request-123"
  });

  expect(result.status).toBe("success");
});

This test verifies a successful payment request.

It doesn't verify:

• Two simultaneous requests using the same key.
• A network timeout after the payment provider processes the transaction.
• A retry after the application crashes.
• A database commit failure.
• A duplicated callback from the payment provider.

These scenarios require different tests and different forms of verification.

Concurrency tests, fault injection, integration tests, contract tests, and database-level constraints can expose failures that ordinary happy-path tests miss.

The distinction is between producing an implementation that passes known examples and establishing that it satisfies the system's actual requirements.

Those are not equivalent achievements.

The Four Independent Dimensions of Working With AI

I think the discussion becomes more useful when we stop treating prompt engineering as a single skill.

There are four distinct dimensions:

1. Instruction Design

Can the user describe the desired result, specify boundaries, and communicate relevant constraints?

2. Interpretation Accuracy

Can the model correctly identify the intention behind the instruction, distinguish mandatory requirements from optional details, and understand what must remain unchanged?

3. Execution Reliability

Can the model perform the requested operation without introducing unrelated changes, omitting important steps, or violating existing behavior?

4. Task Complexity

Can the model handle dependencies, competing constraints, multiple execution stages, and failure conditions?

These dimensions influence one another, but success in one does not establish success in the others.

A highly detailed prompt can still be interpreted incorrectly.

A correctly interpreted instruction can still be executed poorly.

An operation that works reliably in isolation can fail when integrated into a larger system.

And a model's performance on a simple task tells us very little about its reliability on a task with substantially different engineering requirements.

Evaluate the Capability, Not the Demonstration

One reason AI demonstrations can create misleading expectations is that they often show the final output without exposing the conditions under which it was produced.

A generated interface may look convincing, but that doesn't establish accessibility, state consistency, responsive behavior, or maintainability.

A generated API may return the expected response, but that doesn't establish transactional correctness, authorization boundaries, or resilience to retries.

A generated image may look almost identical to its reference, but that doesn't establish that the requested region was the only region modified.

The evaluation criteria should reflect the actual operation.

For image editing, this could include:

• Preservation of unmasked regions.
• Pixel-level comparison where appropriate.
• Boundary artifacts and reconstruction quality.
• Consistency across repeated edits.

For software engineering:

• Behavioral equivalence.
• API and schema compatibility.
• Concurrency correctness.
• Failure recovery.
• Security properties.
• Regression coverage.

For larger systems, the evaluation must also consider interactions between components and the consequences of partial failure.

A successful demonstration proves that a particular result was achieved under particular conditions. It doesn't establish general reliability.

The Real Question Is Bigger Than Prompt Engineering

Prompt engineering is valuable. Clear instructions reduce ambiguity, and good context can significantly improve results.

But it is a mistake to assume that improving the input automatically solves the problems of interpretation and execution.

These are different capabilities, and they require different evaluation methods.

A model shouldn't be judged only by how convincingly it responds to an instruction. It should also be judged by whether it understands the constraints, performs the intended operation, and preserves the properties that the user explicitly asked it not to change.

This matters even when editing a single image. It matters considerably more when modifying production code or designing systems with interconnected components.

The ability to describe a task is not proof of the ability to perform it. And the ability to perform a simple task is not proof of the ability to engineer a complex one.

Perhaps the next stage of AI engineering should focus less on celebrating how impressive the generated output looks and more on measuring how reliably a model can preserve intent throughout execution.