How to Sell Source Code to AI Companies

Your codebase can show an AI team how real engineering work gets done. The files show what you built. Issues, reviews, and tests explain what needed to change and how your team checked the result.

At HUD, we build tools that let agents practice work in software. A useful codebase can give a developer the starting point for those tasks. You can offer it through DataVendor without first turning every past bug fix into a training exercise.

Link issues to fixes

Choose a few examples from the project's history. For each one, find the issue, the code before the change, the fix, the review notes, and the tests.

A buyer might use the earlier code to ask an agent to solve the same problem. The original fix can serve as a reference, while tests check whether the agent's new solution works.

Explain what has been checked. A merged pull request shows that the team accepted a change. You still need to test the scoring method before calling it a ready-made training task.

Example of a coding task

The following task-building checks apply when your offer includes runnable exercises. For a repository-only offer, document the records and working examples you already have; the buyer may build its own tasks.

Imagine a scheduling app that sometimes books the same room twice. The issue report describes the problem, and a later code change fixes the overlap check. This could give a buyer a starting point for a task about handling booking conflicts.

The task would need the earlier code, a clear request, and test records that reproduce the problem. The agent would then change the code. A separate check would test whether the new version handles overlapping bookings correctly without breaking valid bookings.

Keep the full reviewed history in the buyer’s archive, but give the agent a workspace that cannot expose the original fix. Check later commits, branches, tags, issue comments, and attached patches as well as visible source files. Keep the final scoring checks outside the files the agent can modify, so changing a test cannot substitute for fixing the bug.

This example also shows why the history matters. The final code tells a buyer how the system works now. The earlier state, request, and tests help it recreate a problem for an agent to solve. Describe which of those pieces you have before promising a complete task.

Check that the code runs

Try setting up the project from scratch. Record the software versions, commands, and known failures. List any private packages or outside services the buyer will need.

If an old version no longer builds, say so. Its history may still be useful, but a buyer who wants to run tasks needs to know what must be repaired.

For a working example, check that the old code has the bug and that a known fix passes the tests. Look for checks that depend on unrelated settings or let an agent pass without fixing the problem. Our verifier guide explains how these checks affect training.

Test the scoring

A task can fail even when the agent has done good work. The setup might be broken, or the scoring code might expect one exact answer when several are valid. A buyer needs to know how you separated those problems from real mistakes by the agent.

For the scheduling example, try a few small cases. A known broken version should fail on overlapping bookings. A correct version should pass both the overlap test and valid bookings. Also try an incomplete fix, such as blocking every booking. It should not receive full credit just because it prevents double bookings.

Record what each check covers. If the task does not test time zones or recurring events, say so. You can add those cases later if the buyer needs them, rather than implying that one small exercise covers the whole product.

Try more than one valid fix where practical. This can reveal scoring rules that depend on a particular code style or implementation. The goal is to check the requested result in a way the buyer can understand and repeat.

Include a short record of these checks with the example. Note the code version, the test inputs, the expected results, and what actually happened. If a test sometimes fails for reasons outside the task, explain that too. This gives the buyer a repeatable starting point and helps it decide which parts need further review.

Define what is included

You can offer the code and its history or do more work to create tasks and environments. Describe those parts separately so the buyer knows what the price covers.

Agree on the buyer's needs before taking on extra engineering work. A team buying raw code may have its own plan for building tasks.

Review the files

Check rights assignments from founders, employees, and contractors, and the rights of customers and anyone else whose work appears in the project. Search the code history and related systems for passwords, personal details, and confidential records.

Make a reviewed copy for delivery and note what you removed. Leave out access to live systems. Before sharing samples, resolve questions about what you can license and who can approve it.

Prepare the buyer handoff

Use the package table above as your handoff checklist. Include a project summary, setup notes, and the example used to check the package. For ready-made tasks, add the scoring checks and results. For an environment, explain resets and outside dependencies. State which parts still need work.

Avoid bundling unknown maintenance work into a simple handoff. Say who will answer questions about the setup, how long that help lasts, and what happens if a buyer wants to use a different software version. Those choices affect both the price and the effort after delivery.

Keep a copy of the exact package you send. If a buyer reports a problem, you can check the same version and decide whether the issue is a missing promised item, a setup error, or a request for something new.

Offer your code to buyers

Describe what the software does, its history, how it runs, and a few useful examples. State which uses you are willing to allow and what extra work you could do. Compare offers on payment, preparation, support, and whether you can sell to other buyers.

To offer existing code, add it to DataVendor Inventory. If a buyer needs tasks that agents can run, HUD provides tools to build the environment. Agree on that added work as part of the deal.

Frequently Asked Questions

Why do AI teams value a codebase's history?

The files show what you built. Issues, reviews, and tests explain what needed to change and how your team checked the result. A buyer might use the earlier code to ask an agent to solve the same problem, with the original fix as a reference and tests to check the agent's new solution.

Do I need to turn my code into training tasks before selling it?

No. You can offer it through DataVendor without first turning every past bug fix into a training exercise. For a repository-only offer, document the records and working examples you already have; the buyer may build its own tasks.

How do I test the scoring for a coding task?

A known broken version should fail, and a correct version should pass. An incomplete fix should not receive full credit. Try more than one valid fix where practical, and record the code version, test inputs, expected results, and what actually happened.

What if an old version of the code no longer builds?

Say so. Its history may still be useful, but a buyer who wants to run tasks needs to know what must be repaired.

What should I include in the buyer handoff?

Include a project summary, setup notes, and the example used to check the package. For ready-made tasks, add the scoring checks and results. For an environment, explain resets and outside dependencies. State which parts still need work.