AtherNullAutonomy needs
good boundaries.
AI agents can make meaningful code changes. The harder product problem is making that work scoped, observable, verifiable, and subject to a human decision.
This paper explains the system AtherNull is building. A coding-engine prototype has been tested on a disposable repository; the complete customer workflow, connected apps, verification service, and payments are still in development.
Capability is only one part of delegation.
A code-writing agent may be able to understand a repository, edit files, and run tests. That does not automatically tell a team what was authorized, whether the result matches the request, what it cost, or who decided to ship it.
A chat transcript is a poor system of record for engineering work. The requester needs a precise brief, a spend limit, progress that can be inspected, and an artifact that fits the team’s normal code-review process.
Make the contract of work explicit.
AtherNull’s proposed unit of work is a task. It connects an outcome to a repository, constraints, a definition of done, and a maximum budget. That structure makes the agent’s assignment understandable before it starts and the result judgeable when it finishes.
The task's lifecycle follows the same shape end to end: estimate the cost, approve and fund the budget, execute the work, verify the result independently, and settle — accept and release payment, or reject and refund. The agent can report progress, but it should not control the state transitions that authorize acceptance or payment.
Give an agent room to work without giving away control.
Agent execution should happen away from production systems and sensitive credentials. Repository access needs to be scoped to the approved task. A worker must not hold the keys that settle escrow, and a task’s maximum spend should be enforced outside the model’s own instructions.
These are design constraints, not features to add after the product grows. A useful agent is allowed to try, test, and iterate; a trustworthy system still decides where that authority ends.
Separate doing the work from verifying it.
The agent’s “done” message is an observation, not proof. The intended verification path inspects a fresh copy of the changed code, runs the relevant checks, and records what passed or failed. The requester should see the change set, test outcome, and usage before deciding whether to accept.
Independent evidence will not eliminate every bug or subjective review decision. It does, however, make the approval decision better informed than a bare success message.
Payment should follow the decision.
The escrow design holds a task’s funds while work is underway. Release and refund are distinct settlement actions, and the worker cannot authorize either one. The standalone Solana program is being developed and tested separately from the customer application.
Escrow alone does not decide whether software is good. It creates a clear point where the human review, the task record, and the settlement action must agree. Detailed customer-facing refund and dispute operations still depend on the complete service being built.
Keep the outcome in the team’s workflow.
The useful artifact is not an isolated answer. It is a reviewable set of changes, connected to the original task and returned to the repository where the team works. Issue and document connections can bring context in; the repository and review process give the result somewhere accountable to land.
That is the product AtherNull is working toward: a way to request engineering work in plain language without losing ownership of the code, the budget, or the final decision.
The documentation turns this thesis into a step-by-step customer workflow.