I removed the SSE (Server-Sent Events) implementation that I had spent several weeks painstakingly building. I was the one who first proposed SSE and started implementing it, and I was also the one who ultimately decided, after discussion, that we should remove it.
A teammate who worked with me summarized the technical decisions involved in introducing SSE and then switching to polling in the previous article.
This article follows the process that led to that decision and examines what was needed outside the loop while rapidly arriving at a complete answer together with AI.
AI quickly solves the given problem
Qra is a service that deploys applications on Vizend and displays their status. Deployment takes anywhere from several dozen seconds to several minutes. The problem I was given was to provide a feature that would allow users to check the deployment progress step by step. Remembering an experience from another project where I had visualized the progress of a long-running asynchronous task with SSE, I naturally thought I could solve this problem with SSE as well and proceeded in that direction.
At the time, our team worked with an AI agent to refine the workflow as we implemented, validated, and modified SSE. Although we had a succession of issues to resolve, from resource problems to choosing a frontend library, the SSE implementation reached staging without much difficulty. SSE seemed to be settling into place nicely.
As we repeated implementation and validation, SSE gradually became more stable.
Solving the problem does not initially prove that the original decision was right
Then, as we reviewed the production requirements again ahead of a regular review of the Vizend platform, we once more placed weight on the stateless architecture and horizontal scaling requirements that we had kept in mind from the beginning. In Qra, the instance that detected a change in deployment status could differ from the instance connected to the user via SSE, so a separate relay path was needed for immediate delivery. However, Qra was not a project tied to specific infrastructure; it was a platform service supporting multiple environments.
From the outset, Qra's requirement was ‘to let users check the deployment progress so that they can see it’, not ‘to deliverit via SSE in real time’. But after choosing SSE as our direction, I focused on how to implement that approach more reliably and did not think to reconsider the choice itself.
Viewed against that requirement, polling comes at the cost of delayed screen updates and an increased number of requests. However, the core purpose of this screen was to let users see how far the deployment had progressed and, if it had failed, when and why it had failed. Since a delay of a few seconds in updating the screen would not significantly affect the deployment itself or the user's next action, we judged that Qra could afford this cost.
In addition, I thought it was excessive to newly define a relay path, connection management, and common rules for the backend and frontend just to make a single screen update immediately. After discussing the matter with my teammate, the infrastructure team, and the Vizend platform team, we left platform-wide SSE standards in the backlog and removed SSE from Qra.
There were two questions at different levels on the way to this decision. ‘Does SSE work well?’ was something we could verify sufficiently through the AI execution loop. But ‘Is immediacy important enough for Qra to take on this operational responsibility?’ was a question that could not be answered within that loop, no matter how good the implementation result was.
During the retrospective, encountering the concepts of Single Loop and Double Loop in organizational learning theory made the distinction clearer. Single Loopcorrects errors within a given goal, while Double Loopreexamines the goal and its assumptions from the ground up. What I had been working on for several weeks was a loop for improving the completeness of SSE. But when I looked at it from one step outside, a second question remained: whether SSE itself was necessary for Qra.
The sense of what to prioritize
When we encounter a new problem, we abstract our past experiences and knowledge to find aspects similar to the problem at hand. After that, however, we need to increase the resolution again and examine the differences between the past and present situations.
In the previous project, I was able, as the lead, to set and drive standards suited to a defined environment. But in Qra, which is part of a platform that must account for multiple environments and teams, I could not establish those standards based solely on my own judgment. I did not place this difference sufficiently at the forefront of my decision-making.
When an approach has worked well once, we may become confident that it will be right this time too. The stronger that confidence is, the easier it is to miss the need to look again at the differences in the current situation at high resolution.
After finding similarities through abstraction and examining differences at high resolution, we need to decide what to prioritize. I see the ability to gauge the relative weight of multiple factors at this point as a kind of Taste. Taste here is difficult to explain solely as preference or discernment.
Regarding this sense, Andrew Ng described the human contribution that people call Taste as a contextual advantage. In other words, the information and experience accumulated close to the product and its users become the material for making new judgments.
It is difficult to include in advance, using only documents and feedback, all the material needed for judgment. New context may emerge as the work progresses, and even when considering the same facts, what should be regarded as more important may vary depending on the purpose, role, and responsibilities in that situation.
What changed in Qra was not the material for judgment, but the weight placed on that material.
The power to turn judgment into choice
The faster AI completed the answer I had chosen, the farther the initial question moved from being examined. Whether SSE worked properly could be verified quickly through the execution loop, but whether that approach should continue to be used remained a question to be asked outside the loop.
Whether the criteria are being met can be verified within the loop, but whether those criteria should continue to be applied must be reconsidered outside the loop.
Even while the work is in progress, people must continue to ask whether their initial judgment still fits the current purpose and role. Based on that, they must decide whether to continue with, adjust, or change the current approach.
Human Agency is revealed not in increasing the speed of execution, but in revisiting and taking responsibility for an answer that has already been chosen.
References
- HKK, Securing Real-Time Capability: From Introducing SSE to Returning to Polling (Nextree, 2026-05-07)
- Andrew Ng, The Batch Issue 359 (2026-06-26)
- Chris Argyris, Double Loop Learning in Organizations (Harvard Business Review, 1977-09)
TaeZ