The first useful conversation
“Why are customers receiving duplicate notifications?” is a reasonable question to ask an AI assistant. It is also a question with very little information in it.
A notification might be generated twice, published twice, consumed twice, or sent twice during one execution. A customer might have two subscriptions that happen to resolve to the same address. Each explanation suggests different code to inspect and a different fix.
An assistant can describe these possibilities without knowing anything about the application. That answer may help someone unfamiliar with background processing. For an engineer already investigating the service, the useful part begins when the conversation can distinguish between those possibilities.
This is a practical starting point for AI in an existing team. The engineer keeps control of the repository and execution environment. The assistant works with the evidence brought into the conversation. Its contribution is visible in the questions it helps resolve and the investigation it helps advance.
A symptom needs context #
Consider a simplified application where an API publishes an event to a queue and a worker sends an email. The worker acknowledges the message after the send operation completes. Customers occasionally report receiving two copies of the same email.
That description already improves the question. It identifies the components involved and the order of two important operations. It still leaves several explanations open.
Now add a small sample of sanitised logs. The field names here belong to the example application:
10:14:02 job=J42 message=M81 attempt=1 event=send_started
10:14:03 job=J42 message=M81 attempt=1 event=send_succeeded
10:14:33 job=J42 message=M81 attempt=2 event=send_started
10:14:34 job=J42 message=M81 attempt=2 event=send_succeeded
In this application, message identifies the queued message, and attempt increases each time that message is delivered to a worker. send_succeeded means the email provider returned a successful response. The sample contains no acknowledgement records.
Without definitions, the assistant has to guess whether message identifies a queue entry, a business event, or an email. A plausible interpretation of an unfamiliar log field can send the investigation in the wrong direction.
The question can now become more specific:
The same queued message was delivered twice, and both attempts received a successful response from the email provider. What could explain the second delivery? Which observation would distinguish the likely causes?
This gives the assistant a narrower problem. The sample supports repeated processing of one queued message. It leaves open why processing repeated and why a second send was allowed.
Useful hypotheses lead to different checks #
A response might suggest that the worker failed before acknowledging the first delivery, that acknowledgement failed, or that the message became available again while the original worker was still processing it. The delay between attempts may be relevant, but interpreting it requires the queue configuration and the worker's timing.
Each explanation points towards evidence. A worker restart would support an interruption. An acknowledgement error would support a failed acknowledgement. A long operation after the email was sent could explain why the worker had still not finished when another delivery became possible.
The value of the response lies in these connections. “Check retries” names a broad area. “Find whether the first worker was still running when the second delivery started” proposes an observation that can change the diagnosis.
The engineer can also challenge the response. If the assistant immediately recommends increasing a timeout, the next investigation step is what evidence makes the timeout responsible. A longer timeout may change when a duplicate appears while leaving the underlying failure possible.
At this point the conversation has produced a useful distinction: the reason a message was delivered again and the reason processing it again sent another email. Those questions concern different parts of the system. Resolving one may leave the other open.
Results should change the conversation #
Suppose further inspection shows that the first worker stayed alive, the message becomes eligible for redelivery after thirty seconds, and a slow audit write occurs between sending the email and acknowledging the message. During an affected run, that write took forty seconds.
These observations support a more specific explanation. The first delivery could still be waiting on the audit write when the message became available to another worker. The second worker could then send the email again before the first acknowledged it.
The assistant now has something concrete to reason about. Would moving the audit write change the application's guarantees? Can the worker extend the time available to finish processing? Does the email provider support an idempotency key, and what behaviour does its documented contract promise? What happens if the worker stops immediately after a successful send?
The conversation has moved from identifying a likely execution path to examining possible changes and their consequences. It can expose questions the team needs to answer before editing code.
Evidence can also reject the original explanation. If acknowledgement completed before the second delivery, the investigation needs to account for that fact. Keeping a concise account of what is observed, what is inferred, and what remains unknown helps prevent an early suggestion from becoming an assumption carried through every later answer.
The engineer still decides which checks to run and whether their results support the explanation. In this mode, the assistant sees the evidence supplied to it. It cannot establish that an unshared log entry exists or that an experiment was executed correctly.
Context takes engineering judgement #
The example uses a small amount of information: the processing sequence, a few log entries, the meaning of their fields, and the results of targeted checks. Each addition helps resolve a particular uncertainty.
Pasting the entire worker implementation at the beginning might reveal the slow audit write. It might also introduce unrelated branches and configuration that obscure the relevant path. The engineer's judgement remains useful in selecting the material that explains the behaviour under investigation. Source excerpts, configuration, and logs should be shared within the team's agreed data boundaries, with secrets and unnecessary customer information removed.
The wording of the question shapes the discussion too. “Our queue timeout is too short; how do we fix it?” presents a diagnosis as context. “We see a second delivery after thirty seconds; what could account for that?” preserves the uncertainty. The latter gives the conversation room to examine whether the proposed cause is supported.
This requires no elaborate prompt template. It requires care with the difference between what happened and what someone thinks happened.
What the team gains #
The useful output from this conversation could be a short investigation note: evidence of overlapping deliveries, the operation that delayed acknowledgement, the remaining failure cases, and the experiments needed to compare possible fixes.
That note belongs in the issue or technical discussion where others can inspect it. A reviewer should be able to understand why a change is proposed without reading the full chat history. The explanation also remains useful if someone later discovers evidence that contradicts it.
For a team beginning to use AI, this is a manageable form of collaboration. The assistant helps organise possibilities, question assumptions, and connect observations to experiments. The engineer contributes system knowledge and access to evidence, and remains responsible for the conclusions carried into the work.