There is no "after AX." It is not a one-time project. What matters is the feedback loop, not maintenance, and handling failure cases must be designed into the AX system itself. The design scope runs all the way to: someone says "this report number looks off," an agent picks it up, fixes the system, and gets sign-off from a human. · Career Hacker Alex
Semantic
There is no "after AX." It is not a one-time project. What matters is the feedback loop, not maintenance, and handling failure cases must be designed into the AX system itself. The design scope runs all the way to: someone says "this report number looks off," an agent picks it up, fixes the system, and gets sign-off from a human.
AX에는 "이후"가 없습니다. 한 번 하고 끝나는 일이 아닙니다. 중요한 것은 유지보수가 아니라 피드백 루프이며, failure case의 처리까지 AX 시스템 안에 설계되어 있어야 합니다. 누군가 "리포트 숫자가 이상한데?"라고 말하는 순간 에이전트가 그것을 픽업해 시스템을 고치고 사람에게 결재를 받는 구조까지가 설계 범위입니다.
The phrase "after AX" is the first thing to question. AX is not something you do once. So what matters is the feedback loop, not maintenance; the question is how to build a system that improves itself.
Handling the failure cases that would count as "maintenance" must already be designed into the AX system. The moment someone says "this report number looks off," an agent picks it up, improves the system itself, and gets a human's sign-off. That is the design scope. When a model update collides with the existing harness, you re-carve the harness; a harness is a living system carved alongside the model.Also in Korean"AX 이후"라는 말부터 다시 보게 됩니다. AX는 한 번 하고 끝나는 일이 아닙니다. 그래서 중요한 것은 유지보수가 아니라 피드백 루프입니다. 스스로 개선해 나가는 시스템을 어떻게 구성할 것인가가 질문입니다.
"유지보수"에 해당하는 failure case의 처리도 이미 AX 시스템 안에 설계되어 있어야 합니다. 누군가 "여기 리포트 숫자가 좀 이상한데?"라고 말하는 순간, 에이전트가 그것을 픽업해서 시스템 자체를 개선하고 사람에게 결재를 받는 구조, 거기까지가 설계 범위입니다. 모델이 업데이트되어 기존 하네스와 부딪히면 하네스를 새로 깎습니다. 하네스는 모델과 함께 계속 깎아 나가는 살아 있는 시스템입니다.
