The Reflection Prompt

One of the most useful prompts I give an AI coding agent is also one of the shortest:

Is there a better way?

The value is not in the wording. It is in the change of role.

Most coding tasks begin with a proposed solution. Add this service. Create this endpoint. Implement this epic. Change this query. The frame arrives pre-built, and everyone is keen to start hammering.

An agent is very good at accepting that frame and producing an implementation quickly. That is helpful, right up until it isn’t: it can also accelerate a poor idea into production before anyone has had second thoughts.

The reflection prompt interrupts that momentum. It is a small, deliberately Socratic nudge — less “write this” and more “should this be written at all?”

It asks the agent to stop behaving like a typist and start behaving like a reviewer.

A useful response may challenge the implementation:

• the new abstraction duplicates one that already exists three folders away;
• the query will not scale;
• the proposed cache creates an invalidation problem;
• the requirement can be met with a much smaller change.

A better response may challenge the task itself:

• the epic should begin as a proof of concept;
• the feature solves a symptom rather than the underlying problem;
• the data already exists elsewhere;
• a procedural rule is sufficient and AI adds precisely nothing.

This is where AI becomes more interesting as an engineering tool. Speed matters, but reflection may save more time than generation ever will.

The prompt works best after the agent understands the problem but before it has invested heavily in a solution — sunk cost afflicts language models too, in their own way. It can also be useful after implementation:

• What is fragile here?
• What did we make more complicated?
• Which assumptions should be tested?
• What would an experienced reviewer object to?
• Is there a smaller, reversible step?

The answers are not automatically correct. Agents can propose fashionable abstractions, overstate risks or generate alternatives that sound clever and are quietly worse in every way that matters operationally.

Reflection still requires judgement.

But it is usually easier to evaluate several competing approaches than to conjure them from nothing. The agent broadens the option space; the engineer chooses.

There is also a useful cultural lesson. Teams reward completion far more visibly than reconsideration. A developer who delivers the requested feature looks productive. A developer who spends an afternoon demonstrating that the feature should not be built at all may be saving the organisation a small fortune, yet somehow ends the day with nothing to demo.

AI can amplify either culture.

Used narrowly, it increases the rate at which tickets become code.

Used reflectively, it increases the rate at which weak assumptions are exposed before they calcify into architecture.

The question “Is there a better way?” should not be ritualised. Sometimes the current approach is already good. Sometimes delay is more expensive than elegance.

But the cost of asking is small.

The worst outcome is usually another paragraph to read.

The best outcome is discovering that the most efficient implementation is not to implement the original idea at all.

• #ai
• #software-engineering
• #thinking

@online{byatt2026-thereflectionprompt,
  author  = {Stephen Byatt},
  title   = {The Reflection Prompt},
  year    = {2026},
  date    = {2026-04-20},
  url     = {https://learningoutloud.stephenbyatt.com/blog/the-reflection-prompt/},
  urldate = {2026-04-20},
  note    = {Learning Out Loud}
}