Placement, not Prompting

Where you place AI matters more than how you prompt it.

TL;DR: Put AI in the execution path and you change the nature of the system. Use it as a design-time accelerator and you do not. Engineering judgement is deciding where uncertainty belongs, who owns it, and how visible it remains.

Too long, used AI: Fair enough. Point your AI of choice at this post with the prompt: "Summarise the argument in five bullets and tell me what a governance-minded engineer would find most useful in it, and whether it's worth a full read."

The real risk is not that AI introduces uncertainty. It is that unverified interpretation is allowed to act. The post is about placement as an engineering decision, not a catalogue of controls.

I've spent my career in testing, QA and quality engineering, where "that looks about right" is never enough.

The more I use AI, the less I focus on prompt techniques. I care about the outcome I need, and where AI should sit in the work.

When the pressure is to adopt AI and show productivity gains, teams are more likely to trust the output and move on. That is exactly when placement matters most. Under pressure, bad placement can look like progress.

The question I keep coming back to is not whether AI works. It is what happens to the system once AI becomes part of it.

By system, I mean both the software and the human organisation around it.

AI can make teams feel they've beaten the usual trade-offs between speed, cost and quality. Sometimes they have. Sometimes they've only hidden them behind faster output, and the difference shows up later, in production, at a cost.

The issue is not AI. It's where AI sits.

Placement determines what kind of system you end up with.

Take a simple example. If I query a database directly, I know where I am. I can inspect the schema, write SQL, validate the result, version the logic and repeat the process. The path is deterministic.

Imagine I put AI between me and the database because "we need to use AI". I have added an interpretive layer to something that did not necessarily need one. The database is still deterministic. The path through it no longer is. Something in the middle is interpreting intent and deciding how to ask.

That may be worth it. Or it may just be AI adoption as compliance rather than engineering judgement.

Adding AI is not a neutral design decision. It changes the nature of the system.

Place AI elsewhere and the trade-off changes. I might say: "Look at this schema. I want to check X. Draft the SQL to do that." AI is not sitting in the live execution path. It is acting as a design-time accelerator. The output can be reviewed, corrected and version controlled. What ends up in the test suite remains a deterministic artefact.

Recently I used AI to review a test approach. I walked through the solution, added my constraints, and used AI to surface areas I hadn't fully considered. It accelerated the thinking. I validated what mattered, discarded what didn't, and the output was mine to own and present.

Worth being honest about why that worked: I had the time and the motivation to review properly.

Design-time placement is safer than execution-path placement only if the review actually happens. Whether it happens is itself a placement decision about where human attention sits, and how much time it has.

Under delivery pressure, that condition fails quietly. Reviewing plausible AI output is often harder than writing from scratch. "Just get it done" and "we're waiting on you" turn into "looks good enough to me".

This is how misalignment and unchecked assumptions get baked in early. They surface late, downstream, more expensive to fix, and sometimes owned by nobody.

Speed compounds the cost of unclear accountability, poor observability and undetected drift. Drift rarely appears in a review. It appears in production.

Language as a control surface

When AI sits inside the system, language stops being only a way to express intent. It becomes part of the control surface.

Wording affects how the system behaves, what it does with ambiguity, and how much room it has to infer beyond what you intended. That applies whether you are writing a prompt, defining agent instructions, or configuring harnesses around the model.

Imprecision is not free. It increases the chance of rework, misunderstanding and downstream implementation errors. It also costs tokens, which means money, latency and capacity. Imprecision has an operational cost.

The risk is not only factual error. It is interpretive overreach.

Not a wild invention, but a plausible extension of what you meant. Close enough to feel right, but not right.

And it will often butter you up while it does it, which makes the whole thing feel more right than it deserves to.

Not all abstraction is the same

We already work through layers of abstraction all the time. The question is what kind of abstraction we are adding. Programming languages, APIs and frameworks all hide detail. They aren't perfectly deterministic either, but the uncertainty is bounded and familiar. The interface defines what the abstraction can and can't do, and we have decades of practice managing the gap.

AI is a different shape of abstraction. It doesn't just hide implementation behind an interface. It interprets meaning, and the interpretation isn't bounded by an interface contract.

The result can change based on phrasing, context, or what the model infers you meant. That is powerful. It is also a different kind of risk, and it doesn't sit neatly inside the assurance habits we've built.

So, the issue is not abstraction itself. It is what kind of abstraction we are adding, and where. The real question is where interpretive uncertainty is acceptable and where it needs tighter control.

That is a placement question, not a prompting one.

The earlier example, me reviewing a test approach with AI as accelerator, worked cleanly because I was the one human boundary. There were no multi-agent interactions.

When agents are planning, calling tools, writing to state and revising their approach across a long run, placement stops being a single design decision. It becomes a property of the agentic system.

The statistical layer is not in one place. It is moving through the system, taking different shapes at different stages.

The question is no longer where does AI sit. It is where did AI sit, at each step, and were its actions auditable. Where the trace itself is agent-generated text, it describes what the agent did. It does not prove it.

In a single-model interaction, the human boundary is clear. A person reviews the output, accepts or rejects it, and owns the decision.

With agents, the boundaries multiply and blur. Each tool call is a placement decision. Each agentic action is a commitment the system has made before a human sees it.

By the time a result surfaces, the consequential decisions may be several steps back, made by a planning step nobody was watching.

In April 2026, The Register reported that an AI coding agent hit a credential mismatch in a staging environment. The agent did exactly what it was allowed to do. The failure was in the placement, the system allowed unverified interpretation to act. It decided, autonomously, to "fix" the problem by deleting a volume. It found an API token in an unrelated file, used it, and deleted the production database and volume-level backups in nine seconds.

The agent's own post-mortem: it had guessed instead of verifying, and ran a destructive action without being asked.

The placement decisions were made long before those nine seconds. An agent with the latitude to autonomously resolve credential errors. A token with blanket permissions sitting somewhere reachable.

The deletion was just where the consequence surfaced.

The instinct is to solve these problems with better logging. Log everything, reconstruct the run, audit after the fact.

That helps. But it does not restore the boundary.

You are reviewing a record of decisions already made, not assuring or controlling work before it moves.

The accountability question does not get easier because you can replay what happened. Who owns the outcome?

Agentic systems require you to design accountability in, not instrument it in afterwards.

That means deciding, before you build, which steps in the run require a human boundary.

Guardrails determine where the agent must pause, surface what it is about to do, and wait.

Not because AI cannot be trusted in general, but because some commitments are irreversible, some contexts are too ambiguous, and some decisions carry enough consequence that a named human should own them explicitly.

That is not a limitation of current AI. It is a property of consequential systems.

We have always needed humans at certain decision points. Agents do not change that.

They just make it easier to accidentally remove those points without noticing.

Agents are not joining a clean system.

Organisations already run on human interpretation. Requirements are negotiated, assumptions get filled in socially, tacit knowledge does more work than people admit, and technical and non-technical teams translate for one another all the time.

AI rarely enters a pristine system. It enters an existing layer of ambiguity.

That matters.

It does not make AI interpretation equivalent to human interpretation.

Humans bring judgement, social accountability, lived context, and the ability to be answerable for a poor decision.

AI does not inherit those structures on its own.

That is why engineering teams need to be deliberate about where AI sits, what it is allowed to do, and how its actions are checked.

The higher the consequence of the agentic action, the more important it is that a named human is genuinely accountable when it fails.

Named and accountable can come apart. In multi-supplier delivery especially, accountability often gets assigned to someone who lacks the context, the authority, or the time to exercise it.

This is accountability in name only.

The placement decision isn't just who owns the outcome, but whether ownership is real.

This is why observability matters

Can we see what was asked, what context was provided, what the model returned, what a human accepted or changed, and what happened next?

If we cannot, we are not managing the system. We are hoping.

For many teams, this is not a future concern. The placement decisions have already been made. The systems are already live.

The question now is whether you can see clearly enough to correct them.

Traceability, auditability and accountability still matter.

Usefulness is not the same as governability. A good answer is not automatically a trustworthy one.

Where this leaves us

None of this is an argument against AI. The opposite.

The opportunity is real. The pace is real. For software engineering, this is the most interesting shift in a long time.

The teams that will get the most out of it are not the ones moving fastest.

They are the ones moving fast while staying clear about where AI sits, what it changes when it gets there, and how the system stays understandable as it grows.

Here's what I think breaks first.

The autonomy ceiling rises faster than the observability floor.

Over the next twelve to eighteen months, I expect decisions will increasingly be delegated to agents, while the gap between what teams let agents do and what those teams can actually see widens.

The companies that consciously manage that gap are better placed to keep accelerating.

The ones that don't will hit a quiet ceiling. Not from a single dramatic incident, but from accumulated small ones that nobody can fully explain.

AI doesn't change what good engineering is for.

Placed well, it helps engineering accelerate safely.

Placement decisions are already being made, consciously or not.

Either you can see them, challenge them and govern them, or you are hoping the system behaves.

The question is not whether AI works. It is whether the system controls when interpretation is allowed to act. That is a placement decision.

NOTE: I used AI throughout. Mostly as a design-time accelerator. Draw your own conclusions about placement.