What Separates Companies That Do AX Well From Those Just Imitating It?
The difference comes down to how goals are set. The less experience an organization has with AI, the more it lingers on surface statements like "we adopted it too" or "our people use it a lot." Companies that do it well say instead, "we now do with AI what we couldn't before." AX is not the fact that a tool was brought in but a change in how work itself looks, and only when you can prove that change in numbers can you call it a real transition.
The most striking case was not a flashy tool but data cleanup. One organization was re-binding information that had been fragmented and duplicated across systems into a centralized document structure that AI could read well. They called it 'AI-readable data,' and despite the organization's size, every member took part in the work. Rather than leaning on a tool, they first laid the foundation on which AI could work.
Why Does Rushed Quantification Ruin AX?
AI costs money — subscriptions and token bills. Because money was spent, pressure builds that results must show, and that pressure turns real use into a performance for show. 'Token maxing' — handing developers a pile of coding tools and burning a year's budget in four months — is a scene that repeats not only at Uber but at Microsoft and Meta alike.
Yet this mistake is less a failure than a process nearly everyone goes through. Approach it with "let's just try it" and missteps inevitably follow, and from them you learn where it works and where it stalls. The problem is not the mistake itself but the impatience of trying to prove results too fast and drifting into showmanship.
What Does It Mean to Design the Environment Rather Than Train People?
The title Jeong Gi-su presented at a Ministry of Employment and Labor forum was "design the environment, not the training." Instead of leaving individuals to study on their own, the weight shifts to the organization laying down an environment where people can work well with AI. Because setting down existing work to learn something new is nearly impossible, results that motivated people create with extra hours must come with a reward design.
So who runs it is decisive. AX should not be owned by either the engineering org or HR alone; the two must merge. Rather than forcing one tool from the top, it is better to give choice by role. Even if developers converge on coding tools, forcing the same tools on content or document roles runs in the opposite direction.
Where Should an AX Talent Begin?
Two things to start with. First, try the well-known tools yourself to get a feel for what does what; then write down the daily, weekly, and monthly recurring tasks that annoy you and find which of them AI can solve. Trying to understand every update at 100 percent will wear you out. Knowing even 10 percent is enough to change how you work. In the end, the person who uses it more does it better.
To go a step further, you need to see AI as a colleague, not a tool. If a person designs everything and only hands off unit tasks like summarizing or searching, productivity does not rise much. Let certain tasks finish on their own without human intervention — but keep the human eye that judges whether the output is 'slop' with a blurred intent. A design that delegates work like a colleague without being dragged along by AI: that is the core competency of an AX talent.