If you are staffing an AI application business, do not copy a ten-person headcount straight from an interview headline. LatePost's headline says ten people are enough for an AI application business. Its introduction quotes Wei Xiaokang making a slightly different claim: a little over ten people proficient with AI can do work that previously took two hundred. The numbers differ, and the qualification about using AI well matters.
In the interview introduction published on November 12, Wei is identified as a former recruiting head at ByteDance and Meituan. He also defends the value of exceptional model researchers. These are his judgments, not a controlled demonstration of an appropriate staffing level for your business.
Measure accepted work, not generated code
Our recommendation is to turn the staffing claim into a limited delivery test. Choose a real requirement with clear boundaries, set the acceptance criteria in advance, and record the work from requirements confirmation through release approval. Include human review, testing and rework rather than timing only the tool's coding session.
Establish a baseline using previous delivery records or comparable tasks performed with and without AI. Check that task difficulty, staff experience and acceptance standards are reasonably matched, then compare total human working hours. Without that baseline, the exercise can identify bottlenecks but cannot estimate how many positions could be removed. Even measured time savings do not translate directly into dispensable roles.
The distinction matters. Producing more code does not establish that fewer employees can deliver the same result. Time saved on implementation may reappear as inspection work. If that happens, your constraint could be acceptance rather than authorship. Hire for the bottleneck you observe, not the organization chart you hoped to justify.
A practical warning about task selection comes from METR's February research update. Some developers avoided submitting tasks they did not want to attempt without AI. When designing your comparison, record excluded work and the reasons for excluding it, rather than testing only the tasks best suited to AI.
Keep review and failed attempts in the budget
Track more than subscription fees. Record model usage, retries and human corrections separately, then connect those costs to tasks that pass acceptance. A cheap generation step is not necessarily a cheap delivery process.
If a full comparison is impractical, keep the existing division of responsibility and start with work that is easy to check. That is a safer basis for learning than changing headcount to match an interview headline. Decide who must approve permissions, sensitive-data handling and production actions before delegating them. Technical capability is not authorization.
At the next hiring discussion, bring completed tasks, reasons for rework and total costs. Those records can distinguish a shortage of people who write code from a shortage of people who can judge whether it is ready to ship.