While exploring collaborative development with AI Agents recently, I saw that OnlyDust announced it was shutting down.
OnlyDust’s original idea was straightforward: open-source projects posted tasks on the platform, developers picked work they could handle, and they received rewards after completing it.
Open-source projects need contributors; developers need income. Putting the two sides together looks like a reasonable business.
But when I saw this case, what stuck with me was not simply that “another development-task platform shut down.” It was another question:
When AI can already write code very quickly, who decides whether the result is actually acceptable?
That question may be more difficult than whether AI can code.
The Old Bottleneck Was That No One Could Do the Work. The New Bottleneck Is Knowing Whether It Was Done Right.
In the past, when a team needed a feature, it usually had to find an engineer, explain the requirements, estimate the work, and wait for development to finish. A product owner, senior engineer, or customer would then accept the result.
The process was not always fast, but everyone knew where the bottleneck was: engineers had limited time.
That made the value of task marketplaces easy to understand. They helped you find someone willing to do the work.
Now things are different.
One person can ask an AI Agent to read a codebase, break down requirements, write functions, add tests, and finally open a Pull Request. A first version may appear in tens of minutes.
The work does not disappear when generation gets faster. It simply moves downstream.
You still have to verify whether the code actually solves the original problem. Does it only work in a demo scenario? Does it break existing behavior? Are permissions and data handling safe? Where the requirements were unclear, did the Agent make the right assumptions?
AI can help run tests, find common vulnerabilities, and compare implementation against a specification. But a green test suite does not tell it whether the product is truly ready to ship.
Running Is Not the Same as Being Deliverable
This is one of the easiest mistakes to make with AI-generated code.
The files exist. The functions exist. There are even a few tests, and the UI may be interactive. To someone without a technical background, that can look “finished.”
But the most troublesome software problems are often not the ones that crash immediately.
A successful login does not mean there is no authorization vulnerability. An API returning data does not mean it will never return someone else’s data too. All tests passing does not mean those tests cover the scenarios that actually matter.
And many requirements are unclear from the beginning.
“Add an export feature.” Does that mean exporting the data currently on screen, or the entire database?
“Support collaboration.” Does that mean simultaneous editing, or simply seeing each other’s comments?
“Improve performance.” Does that mean making the home page one second faster, or preventing timeouts under peak load?
These are not syntax problems. No matter how strong the model becomes, it cannot decide for the team what “good enough” means.
Who Performs Acceptance Determines Whether This Market Can Work
What a task marketplace is really trading is not a piece of code.
The buyer is purchasing an outcome, and has to trust that the outcome has reached an acceptable standard.
That makes the acceptance reviewer a central role in the transaction, even though it is one of the easiest roles to overlook.
Having the buyer do acceptance is ideal. But many open-source projects, early-stage teams, and nontechnical founders outsource work precisely because they do not have enough engineering capacity to judge it themselves.
Could another developer review it? Yes, but that adds cost. Instead of paying only for implementation, you now pay for review as well, and the reviewer may not understand the product problem the work was meant to solve.
Could AI do it? AI can assist with checks, but it is difficult for it to take responsibility for the judgment, “Yes, this is safe to release.” When the specification is incomplete, it can only judge within the boundaries you wrote down.
Could a community vote? Voting distributes review, but voters may not have read the code and may not be willing to take responsibility for a wrong outcome.
A reliable task marketplace therefore has to answer at least three questions:
- Does the reviewer understand how the result will actually be used?
- Were the acceptance criteria defined before the task started?
- If the acceptance decision is wrong, who bears the consequences?
Without answers to those questions, the platform can introduce the two sides, but it cannot truly reduce transaction risk.
When an AI Agent Takes a Task, the Deliverable Cannot Be Code Alone
This changes the way we write tasks.
In the past, you could say, “Add a payment feature for me.”
For an AI Agent, that sentence is too vague. It may quickly build a payment page that works in a demo, but “safe to take real payments” contains many requirements that were never stated.
A better task description does not only say what must be built. It also says what must be proven.
For a payment flow, the deliverable should explain more than the code: how failed payments and duplicate charges are handled, what happens in each state, how sensitive data is protected, which existing flows are affected, and how a third party can reproduce the acceptance process.
These documents and tests may not look like the product itself, but they are what make the product trustworthy.
Code tells you “how it was written.” Acceptance evidence tells you “why it can be accepted.”
The Question OnlyDust Leaves Behind Is Bigger Than Whether One Platform Succeeded
OnlyDust’s shutdown should not be reduced to the conclusion that development-task platforms have no value. Open-source projects still need contributors, and developers still want to turn their skills into income.
The difficult part is turning vague, complex software work with highly variable quality into an order that strangers are willing to trade.
AI makes that problem harder.
A platform now has to do more than match “who has time to do this.” It has to handle questions such as: Is the request itself valid? Who can recognize polished but useless output? Who stands behind the acceptance decision? Under what conditions should payment be released automatically?
If a platform only brings people together and pushes the hardest judgments back to the buyer, the transaction does not become more reliable.
The Person Who Defines “Done” Will Become More Valuable
I do not think engineers will disappear, but the value of engineering work will be divided differently.
People whose only skill is translating requirements into code will be easier to replace. People who can clarify the problem, design boundaries, anticipate failure cases, build acceptance methods, and finally take responsibility for the result will become more important.
This challenge is not limited to engineers.
Product managers need more technical understanding so they can tell what is ready for acceptance. Technical leaders need more business understanding so they know which failures are unacceptable. Customers cannot simply say, “Make it like product X.” They need to define what outcome counts as complete.
Everyone will be able to produce a first version faster. The hard part is deciding who is willing to say that version is ready to deliver.
I still have not seen a very good answer. But I am convinced that the next problem for the AI development market is not how to find more people who can write code.
It is: who performs acceptance?