Eleven months.

That is how long it has been since Opus 4.5 was released late last November. I remember that week as the real beginning of vibe coding. Describe something in words, and an app would appear. What I spent the night fixing would be running by morning. At that moment, execution was what mattered most.

Figure 01Source Telegram #233

Nitro’s first cohort, under its new name after Vibe Labs, began with that feeling. We believed that if AI took some of the weight out of implementation, one or two people could do what once took ten. We ran alongside five teams all spring, and that belief turned into numbers sooner than expected. One team received an investment from Hashed Venture Fund III and now brings in hundreds of millions of won in monthly revenue. Another grew revenue at remarkable speed, was acquired, and has already returned capital to investors. All within just a few months.

Then, before a year had passed, the air changed. Most services can be copied in under an hour. Screens, features, prompts—everything visible is becoming open source. Haven’t we all already felt how much easier building has become? Now that everyone can build, does simply building still matter? Where has the bottleneck moved?

Signals pointing in the same direction came from around the world. Onstage this spring, Karpathy admitted that he had never felt so far behind as a programmer. He drew a distinction between vibe coding and agentic engineering. If vibe coding means making prototypes quickly, agentic engineering means directing multiple error-prone agents while preserving correctness and taste.

Beijing released a city-level action plan to foster one-person companies. At a demo day in Tokyo, the top prize went to an AI employee that handles marketing for small and medium-sized businesses on its own. One American startup reportedly put its agent in charge of fundraising and had it respond to more than 130 investors. Sequoia predicted that the next trillion-dollar company would come from a service business that operates like software.

Put these signals together, and a paradox emerges. Once anyone could build a company with a few agents, being good at building alone was no longer enough to win. The ability to build became a public good, and competition came back to the organization.

F1 went through this first. Teams using the same engine fill the grid, but they do not all reach the podium. The difference comes from pit stops that take barely two seconds and decisions made on the pit wall. Radio connects those decisions. When a driver briefly reports that the front tires are slipping, an engineer checks that one remark against the data and changes the strategy for two laps later.

Models are now the engines everyone uses. In the agent-native teams I have been watching, radio was alive in two directions. Inside, context flows freely between people and agents. Outside, a single customer complaint changes the product, pricing, and messaging that same night. The easier building becomes, the more similar choices customers face, and the less clear their reason to choose us becomes. Teams with a refined approach to GTM find that reason in customer radio a lap earlier.

I keep coming back to the same question every day. What cannot be forked? Even ways of working are moving into a handful of publicly available prompts. Anything with an answer key will eventually be copied.

Let’s turn the question around. Some things do not come with the repository, even if you take the whole thing. A feel for why a customer left last month and returned this month. A team’s agreement, reached after countless arguments, on what not to do. The people who pick up the phone at two in the morning. And the reason a founder chose to stake their life on this particular problem. An organization is harder to copy than a product. A founder’s heart is harder to copy than an organization.

When the Nitro team sat down ahead of the second cohort, Steven, who had recently joined, asked a question. Is one person using agents well the same as a team using agents well? The first cohort’s teams produced remarkable numbers through individual speed. But we rarely saw that speed accumulate into a team’s capability. Most discoveries went cold inside one person’s laptop.

That question is also sitting on the desk of every developer and PM turning on an agent today. Put ten people together who each work ten times faster, and you do not get a hundredfold increase in speed. Usually, you get a hundred times more code and documents that no one has read to the end. When writing becomes free, a team’s speed is determined by how fast it can read and judge.

Agents pour out code all night without tiring. But deciding which of it to put your name on, and who takes responsibility when it is wrong, still falls to people. Developers become the people who set the standards agents must meet. PMs become the people who decide what to give up. More valuable than writing a standard once is the judgment to revise it in response to customers.

So these are the teams we want to meet in Nitro’s second cohort. Teams with a place for agents on their org chart, redrawing the boundary between people and agents every week. Teams that turn one person’s discovery into a lasting way of working together. Teams that are clear about who executes and who makes the call. Teams that relentlessly design a path from what they build quickly to customers and revenue. And teams that build something invisible every day in an age when everything visible can be copied. Even if you are on your own, if your agents share roles and context and work together, you are already a team.

For these teams, Nitro has decided not to follow the accelerator playbook. The familiar formula is to teach a curriculum over a fixed period, then graduate teams at a finish line called demo day. But in an age when models change every quarter, a curriculum from three months ago is already an outdated map. Nitro has radio instead of lectures, and another lap instead of graduation.

We call it our second cohort, but it is not a batch selected all at once on a fixed schedule. Applications are rolling, and teams enter the track on the day they are ready. Let me ask for your understanding in advance. Our goal is not to select many teams. For the radio to reach each team deeply, we need to keep the number of teams on the track small.

Nitro is a program for early-stage founding teams, so investment moves very quickly through a process separate from Hashed’s main fund. What stays the same is access to all of Hashed’s global network and resources. What we want to build together is a relationship in which we know one another’s problems and respond. Records can be exported, but the trust built through making decisions together cannot be forked.

We want to be engineers on the pit wall, looking at the same screen and holding the radio, not judges holding scorecards.

More than a thousand builders came through the various events Hashed held this year. But once each event ended, they scattered, with no reason to meet again. So we are building a radio network. It is a system where one team’s transmission reaches other teams, the developer community, and the Hashed team, then spreads to partners around the world, including co-investors and LPs. A few words from a garage in Seoul can reach a meeting room on the other side of the world and come back as an introduction to a first customer or the next funding round.

One Friday night, a founder in Seoul, wrestling with a problem alone with an agent, posts a single line about where they are stuck. A few minutes later, a developer from another team replies. We got stuck there too. The approaches that developer’s agent tried follow, and the next day, three teams work on a fix together. A place where a problem you carried alone becomes a problem to solve together. That is what Nitro will be.

Accelerators draw a finish line. Nitro builds a radio network. A year ago, the answer was execution. We do not yet know the whole answer for today. But we know this much: it lies somewhere among the things that cannot be forked, and the radio that helps us find it cannot be switched on alone.

The second lap has already begun. Now it is your turn to turn on the radio. We are listening on this frequency. On your side, all the way.

Nitro powered by Hashed — 혼자는 빨라졌다. 이제 팀이 멀리 간다한 사람이 에이전트와 함께 회사를 만드는 시대가 열렸습니다. 다음 랩은 사람과 에이전트가 한 팀으로 달리는 팀이 가져갑니다. 해시드는 그 팀의 첫 번째 그리드에 함께 섭니다.Nitro powered by Hashed · nitro.hashed.comOpen

Today, we are holding a Track Day meetup at the Hashed Lounge to introduce Nitro’s second cohort. Applications are open now, on a rolling basis.