How to Build Together When It’s So Easy to Vibe Code Alone

The Atomized Developer

Last month, RaidGuild conducted a series of fireside chats with people about how they are generally using AI in their work and personal life. Many common threads developed, but one most pertinent to RaidGuild is the growing prevalence of the atomized developer. This is the developer who codes alone on a highly specific project that only they, or a small handful of other people, will ever use. Nowadays, this mainly takes the form of a vibe-coded project, which is a type of project that lends itself even more to building alone.

Most of the time, these applications are quickly built and quickly deserted (not necessarily a bad thing), but when an app turns out to have real usefulness throughout the guild, a new issue emerges: usefulness is dispersed among many, but ownership is centralized to one person who has little incentive to maintain it. Little incentive because there is no direct and guaranteed way of making money off of a useful thing you built in the guild. You could write a proposal to get paid, but the headache in writing a draft, pushing people to read it, and negotiating a payout, is often not worth the squeeze.

What if there were a way to allow people to continue to build on their own (it's hard to see this trend going away with agentic coding), but once something useful is hit on, there is a standard way to build on someone's work while compensating them in the process?

Instead of building features on top of another person's application or infrastructure, a possible solution is to build on slices of their data. This doesn't make applications collaboratively owned at the code level. Instead, it creates a composable service layer through which independently owned applications can contribute data and functionality to one another.

Networked Data

The proposed solution is frankly not very technically complex, and there are various forms it could take. The minimum required steps are:

1. deploy a simple application registry
2. formalize a standard data provider middleware for x402 endpoints
3. deploy a simple payment router for x402 fees

An example of how this might look in action is as follows: Alice registers an internal service and publishes a paid endpoint. Bob’s agent discovers it, proves that Bob is authorized to access the requested information, and pays through x402. The payment is attributed to Alice’s service, routed through the guild’s accounting system, and may qualify for a matching reward.

Ultimately, what this system provides is a micro-market within an organization. Outside of firms, markets help price goods and services. Inside firms, the value of work is usually expressed less directly through managerial allocation, budgeting, negotiation, and organizational priorities. This system introduces an additional market-like signal for determining which internal tools are creating value.

Agent Registration

An agent registry is necessary for three reasons:

1. to make agents discoverable
2. to provide identity and delegation mapping, so the provider can enforce access controls
3. to track payment receipts for analytics

If the guild is going to allow for permissionless app and infrastructure creation, it also needs to allow for a permissionless and incredibly simple way to do so. At a minimum, this is sending one transaction onchain that maps your member address to an agent address (derived from a private key the agent holds). "Agent" here is a general term, which could be an application, web service, web worker, AI assistant, Discord bot, etc. It's simply the ID for the specific thing you built for the guild. We could also go a step further and include metadata through IPFS in order to make discoverability a bit easier. This discoverability layer could even be built by any number of members as their own "agent."

We also need a way to gate data that is retrieved, and to verify data that is fetched. By registering your agent, you are simultaneously delegating a scoped level of authorization rights to that agent, meaning that when it retrieves data from another agent, it is doing so at your behest, and thus is authorized. In the API middleware, this means verifying that the request was signed by an agent with delegated authority. On the flip side, you also want to be able to verify that an agent and its data actually came from a member. This means when you receive data, you should check that it was signed by an authorized agent. Of course, this doesn't mean that the data was correct, just that it came from a trusted source.

Finally, we need a way to track payment receipts for analytics, attribution, or any number of other reasons that aren't obvious now. While transaction receipts are of course already tracked onchain, we likely want payments to go to a central payment router first before being routed to members who built agents. This makes tracking and bookkeeping easier for members. It's unclear exactly how and when to post this data onchain, or even whose responsibility it is to do so (should the provider middleware post receipt metadata onchain?), but this will be explored more in the Payment Router section.

Standard Provider Middleware

The standard middleware is equally simple, and most requirements for it are already partially explained in the previous section. The provider middleware will need to:

1. authenticate and verify authorization of agents before sending a response
2. handle the x402 integration
3. potentially post data for the Payment Router

I don't think it's worth digging too much into any of these, since they've mainly been covered already. Authentication would only involve checking if the agent address is mapped to a member address in the Agent Registry, and then determining what that member is authorized to view.

An interesting bonus to this setup is allowing more granular authorization through Hats Protocol. Hats Protocol is an open source protocol for onchain roles and credentials. RaidGuild, in fact, already uses Hats for many of its own roles. With Hats, we could extend the Standard Provider Middleware further to optionally check onchain roles for any data that is scoped to those roles, whether for read or write actions.

Payment Router

The Payment Router is the trickiest component to all of this, and it could be completely avoided depending on an organization's situation. For RaidGuild, it may be ideal from an accounting perspective to route payments centrally, so that payouts to providers are issued from a single RaidGuild address. RaidGuild could also issue standardized payment statements to recipients, simplifying bookkeeping for members.

Additionally, this makes analytics and attribution a bit easier. Indexing and displaying this data could potentially be done via volunteers in the network, but it is likely best to start with a central location for this rather than wait for the goodwill of others to build it. If anyone wants to build a better dashboard for this data, they are more than welcome to do so too.

Finally, if attribution is automatically tracked with this system, we could distribute matching rewards automatically as well. In all likelihood, RaidGuild is not large enough to make these payments economically meaningful to members. Members are probably not willing to pay $20/month for 10 internal applications built by other members, and builders likely won't care to maintain a server that is only charging $0.10 per request. But the guild could automatically match payouts by something like 10×. "Your service received $100 in revenue this month, here's an additional $1,000." Of course, this would be easy to game if not tracked properly. To do this correctly, the system will need to flag certain patterns of bad behavior.

Demo

This framework doesn't yet officially exist in RaidGuild, but a few experiments have started. Right now, we have a Discord Bot (called Queen Raida, and built/maintained by just a couple people), which has loads of guild data that can be queried through natural language. But the bot does not have easy access to rich accounting data. Another member in the guild, though, has built a dashboard and API for collecting and surfacing that data for members, and the author can maintain and build out features for that service completely on their own.

So how did we allow a member in Discord to ask Queen Raida about accounting data? By exactly the framework above. The bot's background worker CRON's the accounting API with a delegated agent on a weekly basis, and integrates that into its own data warehouse, paying a small fee along the way.

We have this setup on a few disparate apps and services for now, but more are on the way. Check the YouTube link below to see some of these use cases in action.

https://www.youtube.com/watch?v=C-rQXjpAPus

See what else RaidGuild is up to: raidguild.org