I've been working on harness recently, and I increasingly feel that many people's imagination about AI efficiency is wrong from the very beginning.

They think that so-called AI efficiency means giving everyone a chat window, buying a few model accounts, and then letting employees hand over their original tasks to AI. Ask it when writing a proposal, ask it when writing code, ask it when doing analysis. In the end, they find that the speed hasn't increased noticeably and the results are often wrong, so they conclude: AI isn't mature enough, our business is too complex, and it can't be used for now.

This argument sounds reasonable, but it is actually irresponsible. You can't throw a model that knows nothing into a chaotic organization and expect it to act like a veteran employee who has worked for years—finding materials on its own, understanding context, calling systems, judging results, and finally completing tasks steadily. Human employees can at least ask people around, observe the office atmosphere, and rely on experience to know which file can't be trusted and which colleague's words should be discounted. AI doesn't have these conditions; it can only use the context, tools, and rules you give it.

If these things don't exist at all, of course AI won't do a good job.

The prerequisite for AI efficiency is building the work environment

The word harness is very interesting. It's not simply adding a prompt to AI, nor is it switching to a larger model. It's more like building a working environment around AI, letting it know who it is, what it can do, where the materials are, when it should stop under what circumstances, and what kind of result counts as complete.

An AI that can truly work can't just answer questions. It must be able to read project materials, find relevant data, call tools, modify files, run tests, check results, and then continue adjusting based on feedback. If after doing all this it still requires humans to copy everything out again, manually check it, and then reorganize the results into another format, then it has only saved you a little input time—it can't be called real speedup.

So whether the tech stack is AI-friendly makes a huge difference. Whether the code can be started quickly, whether the project structure is clear, whether commands are unified, whether data interfaces are clearly documented, whether error messages are specific enough, whether tests can run automatically, whether the deployment process has a standard entry point—these sound like traditional engineering problems, but they directly determine whether AI can participate in execution. In a project with chaotic structure, scattered materials, inconsistent commands, and an unreproducible environment, even the strongest model can only fumble around. Every step it takes, it has to guess again.

Getting AI to work depends on callable information

Many teams think they have prepared their business materials well enough. Meeting notes, product docs, training materials—the company knowledge base looks full. But when it's actually time to let AI work, they discover that a lot of the content is outdated, duplicated, and contradictory, and important information is scattered across chat records, emails, personal notes, and the minds of a few employees.

Humans can barely cope with this environment. A veteran employee knows which document is newer, knows that although a process is written a certain way, actual operation requires an extra step, and knows that with a specific customer, normal rules should be bypassed. AI doesn't have this default experience; it can only judge based on what it can find. If you give it three conflicting documents, it won't naturally know which one is true.

This requires teams to reorganize their information. Not to stuff all materials into the knowledge base at once, but to give necessary information a clear location, a stable format, and a callable entry point. What is the project background, what is the goal, what is the current state, which tools can be used, which operations require confirmation, what should the output contain, what to do after a failure—these should all become context that AI can use directly.

Skills and templates are the executable version of team experience

I increasingly like to understand a skill as a kind of 'executable experience.' A document only tells you what something is; a skill tells AI under what circumstances to use this experience, what inputs to prepare, what steps to follow, what result counts as qualified, and when it must stop and ask a human for confirmation. It doesn't have to be long—it can even be very short—but it must be clear enough.

For example, for 'publishing a frontend project,' an ordinary document might just say: build the project, run tests, publish online. A truly useful skill would tell AI to first check the current branch and uncommitted changes, then install dependencies, which tests to run, what logs to look at if the build fails, which environment variables to confirm before publishing, which pages to visit after publishing, and under what circumstances it must not continue.

It turns a person's work habits into a process that machines can execute and humans can inspect. The same goes for templates. A good template isn't meant to make all outputs look neat; it's meant to reduce the cost of rethinking each time. A project kickoff template lets AI know what information needs to be collected; a code modification template lets it first explain the impact scope and verification method; a content production template lets it confirm the audience, goal, and publishing channel before writing.

The clearer these things are, the larger the scope of execution AI can take on. Conversely, if every time you have to spend half an hour explaining the project background to AI, then manually tell it where the tools are, how to open files, and what format the results should be delivered in, then you haven't actually established an AI workflow. You've just added an intern who needs training—and this intern won't proactively observe the environment, nor will it naturally remember lessons after making a mistake once.

Humans make judgments, AI pushes things forward

This doesn't mean that in the future everything will be handed to AI while humans just sit by and watch. Humans still need to be responsible for direction, boundaries, and final judgments. Should this requirement be done, can the risk be accepted, what problem does the user actually want to solve, which result looks correct but isn't suitable for release—these things can't simply be left to the model to decide. Especially when real users, real data, and real business consequences are involved, humans must retain the power of supervision and acceptance.

But the way people work will change. In the past, people might have to personally search for materials, modify files, organize results, repeatedly execute commands, and then connect all the steps. A more reasonable way in the future is for humans to issue instructions and check results, while AI continuously executes in a defined work environment. Humans tell it what goal to achieve, and AI finds relevant information, calls tools, and completes intermediate steps on its own; humans don't need to watch every mouse click, but they need to know what it did, why it did it, and whether the final result meets the standard.

Supervision isn't standing by watching AI type, and acceptance isn't just glancing at the output for typos at the end. True supervision requires a visible process, clear checkpoints, and reproducible results. You need to know which materials AI used, what tools it called, which files it modified, which tests it ran, where uncertainty appeared, and which parts were its own inferences. Only in this way can humans continue to be responsible for the results while efficiency improves.

AI is responsible for pushing things forward; humans are responsible for deciding whether this thing is worth pushing forward.

'Our business is complex' is often avoiding the real problem

Of course, many businesses are indeed complex. Some processes are hard to standardize, some judgments must rely on experience, and some areas are full of exceptions. But this doesn't mean nothing can be organized, nor does it mean AI can only stay at the stage of chatting and generating text.

At least you can first identify the stable parts. Which materials are fixed, which steps repeat every day, which checks must be done every time, which tools can be called uniformly, which errors always recur, which experiences have actually been reused by the team many times. Turn these parts into infrastructure that AI can understand, call, and verify, and efficiency will naturally grow bit by bit.

The most irresponsible approach is to face a pile of chaos and finally say only one sentence: 'Our business is complex, AI can't handle it.'

This sentence pushes all problems onto the business itself, but refuses to acknowledge that the real trouble may come from an unfriendly tech stack, unorganized materials, non-standardized processes, unaccumulated experience, unconnected tools, and no acceptance mechanism for results. You haven't even given AI a working environment, yet you demand that it prove it's worth using.

This is no different from hiring someone, then not giving them permissions, not providing materials, not introducing colleagues, and finally saying 'this person isn't capable.'

AI efficiency has never been just a model problem. It's more like an inspection of organizational infrastructure: can your code be understood, can data be found, can experience be called, can processes be executed, can results be verified.

If none of these things are done well, of course AI can only chat with you.

If this infrastructure is truly built, humans no longer need to spend time repeatedly moving information, manually executing processes, and constantly explaining background. Humans can put energy into goals, judgments, and responsibilities, while AI, within a sufficiently clear harness, pushes forward one by one the things that originally slowed everyone down.