AX Success: Don't Delegate AI Transformation

The starting point for AX is not hiring experts, but for the person with the idea to express their thoughts in a working form.

“If we hire an expert who is good at AI, couldn't our company also do AX?”

Many CEOs and managers think this way these days. They hire an AI expert, explain the company's operations, and then ask them to build a system tailored to their organization.

Experts are necessary. Connecting data, designing security, controlling AI's permissions, and building a stable operating system are specialized areas.

But there's something that needs to be done before that. The person with the idea should directly explain their thoughts to the AI, whether it's a screen, a document, or a simple program,the act of first creating it in a working formis what's needed.

If you want to do AX, ultimately, you have to do it yourself.

AX is not a technical project that can be delegated.

The more times an idea is translated, the greater the distance between the initial objective and the actual outcome.

An AI expert can decide which model to use. They can also suggest how to connect internal data, which tasks to apply agents to, and which automation tools are suitable.

However, it's difficult for them to decide on behalf of the CEO the most important problems our company needs to solve, points of customer inconvenience, areas where human judgment is continuously required, acceptable errors, and success criteria. This is because these are management questions, not technical questions.

If the decision-maker doesn't use AI directly, the answers are conveyed through practitioners and external experts. The CEO's words become a project proposal, and the proposal then becomes a development specification. Only after multiple interpretations and the creation of the outcome does the phrase “This isn't what I had in mind” emerge.

Kai-Fu Lee expressed this directly: AI transformation is no longer something CEOs can simply delegate. This is because AI has begun to influence decision-making and organizational operating methods, beyond merely being added to specific functions.

Now, ideas must be communicated in a working form, not just words.

A prototype is not a finished product that demonstrates a complete idea, but rather a tool for concretizing vague thoughts.

“When a customer inquiry comes in, please analyze the content, find the responsible person, and recommend necessary materials.” While this sounds specific, a flood of questions arises once you start building it.

Where do inquiries come from? By what criteria is the responsible person determined? Can the AI respond directly to customers? Can it provide pricing or contract terms? Who corrects misclassified inquiries? Is the final output an email, a report, or a management screen?

If the CEO doesn't answer these questions, practitioners or developers fill in the blanks based on their own experience. Conversely, if the CEO converses with the AI and directly creates a simple prototype, the requirements change. For example, responses involving monetary values might be routed to an approval screen, the basis for agent recommendations might be displayed, and the original text and AI's judgment might need to be verified side-by-side.

Josh Elman of a16z explains that while AI has significantly lowered the cost of building products, it hasn't eliminated the cost of figuring out what to build. If the traditional sequence was ‘specification → scoping → implementation,’ the new sequence is closer to ‘build → use directly → redesign → launch.’

This does not mean the CEO must become a developer.

경영자가 목적과 권한 및 승인 기준을 정하고 전문가가 기술을 조립하는 장면

What a manager must undertake is not the entirety of implementation, but rather defining the purpose and boundaries.

The statement that a CEO should build prototypes themselves does not mean designing databases and deploying servers. What the CEO must do directly is not the entirety of implementation, but ratherthe concretization of intentitself.

They must directly define what problem is being solved, who uses it, what inputs it receives, what judgments the AI should make, what the final output is, where human approval is required, and what constitutes a failure.

An expert is not someone who defines the CEO's thoughts on their behalf. They are someone who develops the judgments expressed by the CEO into data structures, permissions, verification procedures, and operating systems.

Garry Tan of YC explains that AI and agent coding are significantly expanding individual execution capabilities. In this environment, the value of direct experience in building and verifying something oneself becomes greater than waiting for others' interpretations.

90% of what you want must be expressed by you.

업무 맥락과 우선순위 및 예외와 완료 기준이 AI 시스템에 입력되는 모습

While AI can assist with implementation, it won't define the company's objectives and judgment criteria for you.

C-level executives don't need to implement 90% of the system themselves. However, they must be able to express 90% of what they want directly.

Here, 90% does not refer to button placement or screen colors. It refers to the problem's context, objectives, priorities, constraints, exception cases, scope of responsibility, and completion criteria.

Simply saying “Please create an AI sales system” is insufficient. You must express what constitutes a good customer, which projects are not accepted, what information must be verified, when prices can and cannot be quoted immediately, and the extent to which AI can directly interact with customers.

Greg Isenberg explains that while general models are created by AI companies, the specific tasks within an actual industry must be defined by those who understand the work. Front-line staff know better than general models when an insurance claim is completed, which documents are rejected, and where costs leak in a process.

When you build it yourself, the manager's thinking also changes.

Short iterations of building, using, and refining concretize a manager's judgments.

The purpose of a prototype is not solely to convey a fully formed idea. When you build it yourself, it often reveals that features you thought were important are actually unnecessary, or that seemingly minor exceptions determine the overall reliability of the service.

When a CEO uses a prototype, their questions also change. “Can we include this feature?” transforms into “Can we entrust this judgment to the AI?” “How quickly can we build it?” changes to “At what stage can we show this to customers?”

Keith Peiris, co-founder of Lightfield, explains that product transitions can be slow in organizations with overly separated roles. This means operating in a way where product, marketing, and customer success managers jointly own important problems, rather than just guarding their own domains. As AI lowers the boundaries of execution, it's becoming difficult for CEOs to remain solely in the realm of direction-setting and approval.

The first prototype does not need to be a finished product.

불완전한 작은 프로토타입에 실제 업무 사례를 넣어 안전하게 시험하는 모습

The purpose of the first prototype is not launch, but to verify ideas and judgment criteria.

When told to build it themselves, many managers first worry about completeness. However, the first prototype is not a finished product for public release to customers. It is an experiment to verify whether the CEO's ideas can actually work.

Some buttons don't need to work. You can use sample data instead of real data. A few screens and expected results are sufficient. What's important is to input real business cases, verify the AI's judgment, note the reasons for errors, and re-explain any missing criteria.

On the desk of a startup founder introduced by Paul Graham, two roles were written: one was ‘Build Stuff,’ and the other was ‘Talk to Users.’ The iterative process of building, talking to users, and rebuilding is no longer solely the work of development teams.

Related Evidence·Paul Graham — Build Stuff / Talk to Users

Experts are needed from that point onward.

Experts transform the judgments validated by the CEO into a reliable system for the organization.

The prototype created by the CEO should not be directly connected to the company's operating system. When customer data comes in, employees use it, and AI begins to act externally, security and liability issues arise.

From this point, the role of experts becomes crucial. They must design the data AI can read, the tools it can use, approval procedures before external dispatch and payment, judgment rationale and execution logs, shutdown and recovery in case of failure, and cost and quality management standards.

Greg Isenberg explains that the competitiveness of a harness lies in accumulating knowledge about specific tasks and human modifications as rules. General AI improving alone cannot reliably perform a specific company's work. What the company deems important must remain within the system.

Now, the CEO's words must work.

When the CEO's ideas take a working form, the organization can judge and improve while looking at the same object.

In the past, the CEO stated the direction, practitioners interpreted it, and developers implemented it. AI is significantly reducing the distance in this process. Now, the CEO can transform what they've said into a screen or workflow within hours, use it themselves, correct any errors, and then deliver it to the organization.

What's needed here is not professional coding ability. It's the ability to explain one's thoughts concretely, to input real-world examples, and to evaluate results and determine what went wrong. These are tasks that managers were always supposed to do.

Future AI-native companies will not solely mean companies with many AI experts. They will be closer to companies where the person with the idea first makes it work, the organization verifies it with actual tasks, and experts complete it into a safe system.

Before looking for an AI expert, first open up AI yourself. Describe one task you most want to solve and create a small output. If you don't like it, explain again why you don't like it.

Who should go first?
Ultimately, you, the person with the idea, must do it.

Sources and References
Lee Kai-Fu — AI transformation is no longer something CEOs can simply delegate
Josh Elman·a16z — Prototypes are cheap, judgment still matters
Garry Tan·a16z — AI is a multiplier on the individual
Keith Peiris·a16z — AI ends organizational swim lanes
Greg Isenberg — The general model is theirs, the specific jobs are yours
Greg Isenberg — Agent harnesses are the new GPT wrappers
Paul Graham — Build Stuff / Talk to Users

If you want AX, you ultimately have to do it.