Read the Vibes

Tools can build. Before building, read the vibes.

Vibe coding solved a real problem. A person has an idea but cannot write code. Now the machine does it. For an individual, this is power, which brings freedom.

But here is what I have been haunted by: why does vibe coding seem to make individuals so invincible, yet do so little for organizations?

Everyone can be Sisyphus who suffers brain fry over and over again on their weekend side project; and sometimes the project becomes the boulder to fight against the previous boulder.

The world, the press, the social media are inclined to tell stories. Stories sell better with a price tag.

---

I’m personally tired of the one-man show. Writing this is not to argue against vibe coding. I am empowered by generative AI and I encourage my colleagues to use it. But while one’s personal life can be exempted from trifles by all these fancy AI helpers, teamwork in the office is still stuck in a swamp and going nowhere. People will lose confidence and patience with collaboration. This is where the pain begins.

In an organization, the pain does not belong to anyone. It lives between the seams. The seams that departments, roles, and people are all trying hard to stitch with manuals and guidelines and policies, but in vain. Pain stays.

This realization came from two things happening at the same time.

The first was technical. I borrowed the concept of skill from Claude when I tried to extract tacit knowledge inside an organization through interviews with frontline workers. In Claude, a skill is a bounded unit of capability written as a structured document, also seen as prompts. It knows when it should be triggered. It knows what to do once triggered. It knows when the job is done. It is not intelligence. It is a clearly packaged ability that can be called upon when needed. Not because I suppose organizations should run like AI systems, but because it gave me a useful question: what can be packaged this way, and what cannot?

If someone can describe when something should happen, what steps to follow, and what done or done halfway looks like, it can become a skill. But a lot of what I encountered in my interviews could not even align on where it begins. People could not say when. They could not describe the trigger. The knowledge was there, somewhere, tangled in experience and context and instinct. No one had pulled it — the friction, the pain — apart yet. And I kept questioning: who is supposed to do that pulling?

The second was something I kept seeing in the field. Scenes repeated. Operations could not understand why business units kept asking the same questions when they had already provided a comprehensive manual. The business units could not know what rules or policies to comply with. Manuals existed. Symptoms existed. But without diagnosis, one could not reach the other.

Let me narrow down the scene. When a policy or directive came down, many people’s reaction was just: what does this have to do with me? And if that question had no answer, the policy did nothing. It got filed. It got forgotten. Not out of laziness or resistance, but because no one had translated it into something that touched their actual work.

When someone says he does not care about politics, I do not think he is indifferent. I think he lacks the chance to understand how he would be affected.

---

These two things pointed to the same gap.

Skills can handle what is known and definable. But helping someone see that a problem is their problem, that a policy touches their work, that the complaint from another department is actually about the same struggle — that cannot be packaged. It needs a person in the room to define the pain.

I thought of how medicine handles the pain. A patient walks in with a headache. She does not know she may have a tumor. The system does not expect her to figure that out. It gives her a general practitioner. The GP does not treat the tumor. The GP is someone with enough breadth to hear symptoms, form a rough judgment, and send the patient somewhere useful. The training is broad so that the routing can be precise.

I spent years doing exactly this work without knowing what to call it. My company had problems, but problems were not labeled. Something hurt, and it could have been HR, legal, finance, or something that did not belong to any department at all. I did what I could. I called friends. I guessed. I asked around. Honestly, I was groping in the dark with a fistful of symptoms, knocking on doors to see who would open.

In Japanese, there is a phrase: reading the air. It usually means knowing when to speak and when to shut up. Social awareness. I want to use it differently here. I mean the ability to walk into a room where everyone is describing a different problem and hear that they are describing the same one.

Collaborations demand more details.

---

I have never liked calling knowledge management SOP. SOPs work when the situation is predictable. Most situations are not. Manuals are a step better — they explain how rather than just prescribe what — but a manual assumes the reader already knows what to look for. Most people do not. And even when someone was taught a skill once, the next time it is needed might be a year later. The knowledge is gone. The organization says, we trained them and they still cannot do it. The training was not the problem. The container was.

Most organizations have neither layer. No skills. No one reading the air. What they have is a manual nobody opens at the right moment and a set of procedures that describe a world simpler than the one people actually work in.

So when everyone is talking about vibe coding, this is what I want to say. The coding will keep getting better. Skills will get easier to build and package. Agents will keep integrating. But the vibe — reading what is actually happening in a room, figuring out who needs what, turning the scattered and unspoken confusion of an organization into something actionable — that is still a human job.

Tools can build. Before building, read the vibes.