Vibe coding still needs open source
The case for sharing code, tests, and standards grows as more teams generate their own software.
Andrei MisiukevichCo-founder, Dealer Handshake
Vibe coding makes rebuilding somebody else’s project look tempting. Ask an agent for the features you need, generate the code, and change whatever annoys you. If you’re its only user, you can choose every convention yourself.
Once other systems depend on the result, the job includes preserving the behavior they expect. Rewriting the code also means taking responsibility for the decisions inside it. A maintained open-source project can give you an implementation, its bug history, and regression tests that record what previous failures taught its contributors.
The $24,900 problem
Give 10,000 dealerships a coding agent and each could build an inventory API. Suppose three of those APIs return $24,900 for comparable cars. One includes mandatory dealer charges. Another leaves out a $799 fee. The third has deducted a rebate the shopper may never qualify for. An assistant comparing the numbers could recommend a car on terms the buyer cannot get.
An agent could generate an adapter for each API. Somebody would still have to decide which amounts belong in the comparison, then maintain that decision as the feeds change. Across 100 shopping assistants, the same ambiguity creates work for team after team.
Teams can agree on a common definition through an open standard, then publish code, schemas, and tests that implement it. Every new implementation can reuse the definitions and their executable checks. Coding agents can read the specification, use its validator, and run the existing tests while building an integration.
A public repo can contain slop
Publishing code guarantees neither review nor correctness. An open project can contain broken assumptions, and AI can produce documentation and passing tests around those assumptions. Someone still has to report the missing case, review the fix, and maintain the release. With the work published under an open-source license, other teams can inspect the correction and incorporate it into their own systems.
AAP makes the agreement reusable
The Auto Agent Protocol defines five typed skills using A2A: dealer information, inventory filters, vehicle search, vehicle details, and lead submission. Its pricing rules require the advertised price to include mandatory dealer charges and exclude conditional rebates and government charges. Competing assistants implementing AAP can compare cars using the same definition of price.
When a shopper wants to contact a dealer, the lead request carries explicit consent and the permitted contact channels. An email-only request gives the receiving system a boundary it can enforce. The public repository supplies schemas, TypeScript types, validation code, and contract tests that developers and coding agents can use to build and check those requests.
Dealer Handshake already makes inventory from 300+ dealership locations available through AAP. We connect the feeds those dealerships operate and deliver consented inquiries to their CRMs.
A competing provider can use the same specification and validation code. Its next integration can start with the fee definitions and consent requirements already documented, and its developers can contribute corrections that we can adopt too.
Vibe coding gives more teams the ability to build a car-shopping agent that can reuse AAP’s definitions, run the published checks, and contribute a test for a case everyone missed. Each new implementation becomes another place to apply the same pricing and consent rules.