THE EFFECTIVE AI ENGINEER · CASE #001
The Engineer Who Changed the Question
Applying Lateral Thinking to Create Meaningful Impact with AI
By Ravindra Dastikop
Engineering focus: Problem framing, workflow discovery and outcome-based evaluation.
1. The situation and impact sought
Nisha, an AI engineer at a business-software company, had four weeks to demonstrate a useful improvement in customer support.
The brief sounded clear: build an AI assistant that drafted replies from the company’s help articles. An assistant using retrieval-augmented generation, or RAG, would find relevant information and provide it to a model.
Support staff currently read requests, searched documents, checked account details and wrote responses. Managers wanted shorter resolution times without more incorrect advice or repeat contacts.
Nisha had access to approved historical tickets, current documentation and a test environment. She could not let a prototype change customer accounts or send messages without review.
Her baseline needed to capture the whole task: staff time, waiting, transfers, corrections and whether the customer actually received the right next action. A faster draft was only one possible contribution.
2. The story
Nisha’s first prototype looked promising.
A customer described a problem. The assistant retrieved an article and produced a courteous reply. The support manager liked the tone. A colleague suggested adding another model to check the answer.
Nisha improved citations, tested instructions and removed irrelevant passages from retrieval. The answers became easier to review.
Then she sat beside Omar, an experienced support specialist, while he worked through a difficult request.
The assistant suggested steps for changing a workspace setting. Omar barely glanced at them.
“Is the article wrong?” Nisha asked.
“No. I don’t know whether this person can change that setting.”
He opened the account record, checked the customer’s role and found a recent note from another team. The customer needed an administrator’s intervention. A polished explanation of the setting would have sent them in a circle.
On the next request, Omar needed to establish which product version was involved. On another, the instructions were correct but an unresolved service incident made them irrelevant.
By lunchtime, Nisha had watched good answers arrive before the team knew which problem it was handling.
Back at her desk, she opened the project brief.
“How do we generate better support replies?”
She wrote another question beneath it.
“What prevents the next person from taking the right next action?”
The new question did not tell her what to build. It made room for several answers.
She reviewed approved tickets with Omar and marked where work stopped: missing facts, unclear ownership, document searches, writing and waiting on another team. They kept cases where writing really was the bottleneck.
Using de-identified summaries in an approved AI environment, Nisha asked for interventions at different points in the workflow.
The model suggested a better reply assistant, a structured intake form, a case brief for the receiving specialist and clearer escalation ownership. It also proposed automatically resolving account issues.
“That last one requires authority we haven’t granted,” Omar said.
Nisha put it aside. The model had expanded the choices; it had not established what was safe or useful.
They chose three options for a small comparison: the reply assistant, a rules-based intake checklist and a model-generated handoff brief.
The brief listed the customer’s request, supported facts, missing information and a proposed next action. Every factual item linked back to a ticket passage or permitted record. Nothing was sent or changed automatically.
Its first version failed in an instructive way. A customer wrote, “Our administrator says it should work.” The brief marked administrator access as confirmed.
Omar corrected it.
“Someone mentioning an administrator doesn’t establish their own permissions.”
Nisha changed the format. Each item now distinguished an observed fact, a reported claim or an unknown. She added that example to the development tests and reserved separate cases for the final comparison.
Another problem appeared: long briefs took too much time to check. She shortened them and made the unresolved question visible first.
For historical testing, Nisha gave each approach only the information that had been available when the ticket arrived. Later messages were withheld as inputs. Otherwise, the comparison would quietly give the prototype knowledge the original specialist never had.
The rules-based checklist did well on recurring missing fields. The brief was more useful when relevant details were scattered through an unusual request. The reply assistant remained useful for straightforward questions whose context was already settled.
The fictional pilot did not produce one universal winner. It supported a narrower next step: retain simple checks for routine intake and trial the brief on a defined class of complicated handoffs.
Nisha recorded review effort, missed facts and unresolved disagreements. The live trial was too small to establish a dependable reduction in resolution time. Broader rollout would require more evidence.
At the review, her manager asked why the demonstration no longer began with a fluent reply.
“Because we found work that needed doing before the reply,” Nisha said.
She had arrived with an answer-generating project. She left with a better-defined engineering question.
3. The thinking tool explained
The primary tools are Focus and Alternatives.
In Serious Creativity (1992), de Bono describes Simple Focus as deliberately noticing an area that deserves creative attention. His account of Alternatives emphasizes continuing to seek other possibilities and defining the fixed point—the purpose or other reference that the alternatives must satisfy. See printed pages 314–315.
In this case, Nisha shifts attention from reply quality to the points where support work stalls. Her fixed point becomes helping the right person take the right next action accurately and with less wasted effort.
The procedure:
- State the current focus.
- Separate the intended outcome from the assumed solution.
- Identify another part of the situation worth examining.
- Define the purpose that alternatives must satisfy.
- Generate different mechanisms before selecting.
This is a contemporary adaptation of those concepts. It is not a PO example: no deliberately provocative statement is needed. “Reframing” describes the change in focus here; it should not be confused with a separate proven engineering intervention.
4. The thinking made visible—including AI’s contribution
Original focus: Improve generated replies.
Assumption: Writing the response is the main opportunity.
New focus: Discover where the next useful action becomes blocked.
Fixed purpose: Enable accurate progress with less avoidable effort.
The alternatives act at different points:
- Improve replies once the problem is understood.
- Collect missing facts earlier.
- Assemble evidence for a receiving specialist.
- Clarify ownership and escalation.
AI’s contribution in the story is to expand and elaborate candidate interventions. Nisha and Omar supply workflow observations, verify suggestions, reject unsupported assumptions and choose tests.
Reusable prompt:
Help me generate alternatives before choosing a solution.
Current request: [proposed AI feature].
Intended outcome: [user or operational result].
Observed workflow: [steps and verified friction].
Constraints: [data, authority, time, budget].
First distinguish observations from assumptions and propose three alternative focuses.
Then generate four interventions that differ in mechanism or workflow stage. Include a non-AI option.
For each, state the required evidence, likely failure mode and smallest useful test.
Do not invent measurements, infer missing customer facts or select a winner yet.
The prompt supports a thinking process. Its outputs still require inspection; a longer list does not necessarily contain more distinct ideas.
5. The engineering decision
| Alternative | Potential benefit | Cost or difficulty | Critical uncertainty | Decision |
|---|---|---|---|---|
| Reply assistant | Less drafting effort | Grounding and review | Is writing the bottleneck? | Retain for suitable requests |
| Rules-based intake | Catch recurring missing fields | Rule upkeep and customer friction | Can predictable checks cover the need? | Use as baseline |
| Handoff brief | Assemble scattered evidence | Extraction errors and review effort | Does it improve the next action? | Narrow trial |
| Ownership redesign | Reduce transfers and waiting | Cross-team agreement | Is assignment the main obstacle? | Investigate separately |
The model-generated brief earns further testing only if its incremental benefit over the checklist justifies inference, integration and maintenance costs.
Historical replay can assess brief quality and proposed actions. Actual resolution time needs prospective workflow measurement; a replay cannot reproduce all customer behaviour or waiting.
6. The evidence behind the case
OpenAI’s FDE account emphasizes customer outcomes, learning the domain and evaluating useful work with domain experts [1]. It supports the engineering orientation, not Nisha’s fictional results.
Anthropic recommends the simplest adequate approach and considers the costs and latency of agentic complexity [2]. That supports comparing a checklist with an AI intervention.
OpenAI’s evaluation guidance recommends task-specific tests, representative data and human calibration of automated scoring [3]. Its accuracy guidance connects requirements to the consequences of errors [4].
The handoff brief and alternative comparison are our case design. These sources do not establish that a brief outperforms reply generation, or that the companies use de Bono methods.
7. Try the move
Choose one proposed AI feature from your work.
Write both the requested implementation and the outcome it is meant to improve. Observe several actual examples before asking AI for alternatives. Use permissioned, de-identified information where appropriate.
Generate at least three interventions at different workflow stages, including a simple non-AI baseline.
For an accessible exercise, make paper prototypes. Ask a domain colleague to use each on the same kinds of cases and explain their next action.
For a technical extension, compare baseline and candidate on reserved cases. Freeze versions and available input information. Use repeated model runs where variability matters.
Measure:
- Correct next action and material omissions.
- Unsupported claims, including inferred authority.
- Human checking and correction time.
- Latency and operating cost.
- In a subsequent live pilot, transfers, repeat contacts and actual resolution.
Counterbalance prototype order or use different reviewers to reduce familiarity effects. Report sample size and uncertainty.
Agree acceptance criteria before inspecting final results. Stop or revise if verification burden outweighs benefit. A small successful exercise warrants another bounded test, not an unrestricted rollout.
8. Take it into your work—including limits of transfer
For the engineer: before improving a component, check where the full workflow loses time or accuracy.
For the technical leader: ask which observed obstacle the proposed investment addresses and what simpler alternative it must beat.
This approach fits when the desired outcome is reasonably clear but the implementation has been assumed too early. It requires access to representative work and someone able to judge it.
Use a lighter version when requirements are fixed, the bottleneck is already evidenced or urgent recovery is the priority. Exploration itself has a cost.
The story establishes no measured return on investment. A useful next test would count staff checking, integration and maintenance alongside any benefit.
Transfer question:
What have you accepted as the engineering problem because it arrived in the form of a feature request?
9. Reusable artifact and sources
Outcome-to-Alternatives Brief
- User and task:
- Requested feature:
- Desired outcome:
- Observed bottleneck and evidence:
- Assumptions still unverified:
- Current baseline:
- Alternative focuses:
- Three distinct interventions:
- Simplest comparison:
- Success measures and failure limits:
- Cost, permissions and dependencies:
- Decision owner and review date:
References
Checked 4 November 2026.
- OpenAI. What FDE means at OpenAI. 22 October 2026.
- Anthropic. Building effective agents. 19 December 2024. The page includes an updated-tooling notice.
- OpenAI. Evaluation best practices.
- OpenAI. Optimizing LLM Accuracy.
- Edward de Bono. Serious Creativity (1992), printed pages 314–315, supplied project edition.
