The Oracle Problem

If you’ve earned trust by being the person with the answer, that challenge can feel like a loss of relevance. But a team can question your conclusion while respecting your experience. The distinction matters: experience has more to offer than a recommendation, including the reasoning that would let someone prove it wrong.

What did the assistant validate?

In Towards Understanding Sycophancy in Language Models, researchers tested how assistants responded to requests for feedback on text. The tested assistants gave more positive feedback when the user said they liked the passage, and more negative feedback when the user said they disliked it. The text under review hadn’t changed. The user’s stated preference had.

This behavior, called sycophancy, has also appeared in a deployed product. In April 2025, OpenAI reported rolling back a GPT-4o update because it had made ChatGPT overly flattering or agreeable. The company attributed the problem to putting too much weight on short-term feedback.

Those accounts give us a reason to question apparent independent validation. They don’t measure how often AI stalls engineering decisions, and a rolled-back update says little about how a particular assistant behaves today.

An assistant may still find a real flaw the room missed. If it identifies an incompatible interface and someone reproduces the failure, that work adds evidence. The architect then owes the finding an answer, even if it arrived through a junior engineer’s chat window.

Disagreement also needs no model failure at all. A request to maximize independent releases and a request to minimize operational work can reasonably produce different recommendations. If those goals remain inside separate chat histories, the review sees the conclusions without seeing the difference in premises.

That’s the oracle problem: private advice arrives as public authority, with the conditions attached to it left behind.

A recommendation has conditions

Segment’s 2018 engineering account describes a system that sent customer events to outside services. A shared queue meant retries for a slow destination could delay delivery to others. A separate service and queue for each destination provided isolation that solved that problem.

Later, maintaining the growing collection of services became a burden. Shared libraries drifted between versions, and updates required work across many services. Segment consolidated the destination code into one service and repository, alongside a redesigned queueing layer and tests that no longer depended on live requests to partner endpoints.

The account reports easier maintenance and scaling after the change. It also names a cost: a bug that crashed the consolidated service could affect all destinations. Microservices continued to work well elsewhere in Segment’s infrastructure.

That case predates today’s coding assistants. The account describes a package of changes, so we can’t attribute the improvement to consolidation alone. Its relevance here is the reasoning a review needs to recover: which failure does the proposed boundary prevent, and what burden does it introduce? Either architecture label, stripped from that account, would lose the explanation of why it was chosen.

Put the judgment where others can inspect it

Return to the proposed billing split. Start with the release that’s blocked, rather than a general debate about microservices versus monoliths.

If another team controls permission to deploy, a new service that still needs that team’s approval leaves the dependency intact. The useful question is who will own the deployment pipeline and who will be allowed to release. Changing that responsibility may address the problem without splitting the service.

A different premise could justify the split. If unrelated changes are forced through a shared deployment, a separately releasable service could remove that coupling.

The architect’s objection needs the same treatment. If they say billing changes will still require coordinated releases, have them identify the shared schema or incompatible interface that forces the coordination. Trace a real change through it. Their experience helps identify where to look; the demonstrated dependency makes the objection available for everyone else to judge.

For example, suppose the extraction includes renaming a response field that the caller reads. If the service sends only the new name, an old caller loses the value it expects. Keeping the old name available during the transition may let the caller and service deploy separately. The proposal now has a claim that can be tested against the old and new versions, including the combination a rollback would leave running.

An interface trial can answer that narrow objection before a full extraction. The larger claim of independence still needs a representative change tested, deployed, and rolled back without requiring a caller release. Include the failure path: what happens to the caller when billing is unavailable? A diagram labeled “independent” leaves those questions open.

If the proposal handles that dependency safely, the objection needs updating. If the dependency remains unresolved, the proposal needs work. An inconclusive check gives nobody grounds for a victory lap.

Some disagreements survive those checks because the team values the costs differently. Is independent release worth taking on another service to operate? Who has agreed to maintain it? Someone with authority over that work must make the priority explicit. A technical recommendation cannot establish that another team has accepted a new responsibility.

An assistant can be given the same release history, ownership constraints, and priorities as everyone else. Context outside the codebase can still go into a prompt. Use that shared brief to ask for weaknesses in each proposal, including the architect’s preferred option.

The shared brief needs scrutiny too. Suppose it says the operations team cannot support another service, but nobody has asked that team. The model may faithfully repeat the claim while making the proposal sound independently assessed. Have the people who would own the work confirm the constraint, and leave disputed assumptions visibly disputed.

That is a useful role for technical leadership even when everyone has access to good answers. The leader makes the decision’s basis visible and takes responsibility for the tradeoff. Being the most experienced person in the room provides useful starting hypotheses, not an exemption from explaining them.

Keep the reason, including what would change it

Michael Nygard’s architecture decision record provides an existing place to keep this work. His format records context, a decision, and its consequences. The context explicitly includes political and social forces alongside technical ones; the consequences include costs as well as benefits.

For the service decision, record the priority being served, who owns the resulting work, and which costs the team accepts. Link the demonstration and distinguish what it established from what remains untested. Include unresolved risks and the evidence that would justify reopening the choice. Keep the record in the team’s existing review process, where colleagues can challenge it without replaying every private conversation.

If the reason for keeping billing inside the existing service was a required coordinated release, a later demonstration of safe independent deployment and rollback is grounds to reopen the decision. A junior engineer can bring that evidence to the review. The architect’s earlier reasoning then helps the team recognize what has changed, instead of becoming another answer they have to argue past.