From Solo Warrior To Team Thinking

May 22, 2026 · Personal Growth · 9 min read

Teamwork Vibe Coding Cognitive Shift

A cognitive sync on where I stand right now. Moving from super-solo-player to team thinking, from Vibe Coding to Vibe Research — there are some fundamental barriers I have to cross:

  • On “invisible intellectual arrogance” and disenchantment

As someone with strong individual combat ability, from freshman to junior year I focused exclusively on cultivating that skill. But I gradually realized that, to some extent, I harbored a kind of “invisible intellectual arrogance.” The stronger you are, the more likely you are to objectively feel that your time is worth more than others’. You think: I can do 120% of the work with 80% of the time — isn’t everyone else just adding trouble?

I used to think that way, one-sidedly. But this ignores the growth value of others. Even in the AI era, when solo capabilities are amplified many times over by AI, you can’t afford this mindset. It’s deeply harmful to team collaboration and output. In CS and AI, you must recognize that no matter how strong one person is, there are boundaries. Completing the disenchantment of yourself is incredibly important for technical people. One person having a strong engine isn’t real strength; making the entire team’s engine strong is real strength.

  • Five rules for the leap from individual thinking to team thinking

There are things I didn’t practice well before — that was my problem. Whether you are a leader or a member of a team, you should always live by these five rules:

When three walk together, there must be one who can be my teacher. This is intellectual humility. When you recognize that your own abilities have limits, the team’s vibe becomes right.

Replace commands with discussion. Don’t say “go do X.” Say “what do you think about X? What’s your view?” Let the team pool wisdom.

When things fail, internalize the blame first. Reflect from the heart. Say “if I had done better at X, things might have turned out differently.” Avoid passing the buck and build good vibe.

Create the conditions and confidence for others to rise. Don’t let your presence make others timid. Let everyone grow wildly in a comfortable, preferred vibe, unlocking each person’s potential.

Be grateful. If you feel pleasure and comfort, thank everyone for what they’ve sacrificed for you.

When other team members work with me and feel respected, heard, safe from blame when they make mistakes, supported in their growth, and appreciated for their sacrifices, they will unleash astonishing creativity. This is the critical leap from solo combat to team combat.

  • Behavioral convergence without losing inner edge

Truly practicing the two points above doesn’t mean losing your edge. It’s about channeling personal edge into the team’s edge — keeping the inner fire alive, but adding a layer of steadiness to behavior and reining in some of the blind, reckless sharpness.

  • Sync on personal connections

At this stage, my high-quality connections are still not enough. The people I meet, the friends around me, the communication I do — all insufficient. My aggressiveness in seizing opportunities is still lacking. Neither open-source influence nor academic influence has been established yet. I hope to accelerate on one hand, but on the other hand not be too eager for quick success; I need to be solid and steady.

  • Judgment on Vibe Research

Vibe research has become inevitable. My judgment is that vibe research is currently in the same state that vibe coding was in Q3 2024: phenomenal products have begun to emerge, but it hasn’t started to spread yet. The most important test is the agent’s long-horizon capability, and giving the agent a sufficiently complete execution environment.

  • Iteration of engineering collaboration models

The old model: the architect converts requirements into api.md, and engineers then split interface implementation and test implementation according to the Law of Demeter. The new model: the architect leads the team to collectively convert requirements into api.md, and engineers then allocate review, implementation, and testing work among themselves.

Six points above. Keep building, keep improving.

One more thought: on the road to success, there are too many points that can trip you up. Everything I said today — if a leader can’t do it, it’s not necessarily fatal. But it’s fair to say: successful people may not have done all of it, but they definitely didn’t step in all of the pitfalls.

星光降落 · 周浩洋